标签：#xdebug

For a while now I have used LLMs to automate parts of my work. One of those parts is debugging hard problems with Xdebug. Before, I set the breakpoints by hand and built complicated requests to see what happens inside. It usually took a few requests, and I had to move the breakpoints again and again. Then I found that PhpStorm has Xdebug in its MCP server. For simple GET requests, that is enough. But it fails on endpoints that need authorization, and on any method other than GET. So I did not wait for JetBrains. I wrote my own small MCP server, and it makes this work much faster. I share this tool with you, and I hope it helps you too — especially if you work with Docker. TL;DR Tired of reading, and you have not started yet? Fair enough. Straight to setting up the MCP server in PhpStorm , or straight to installing xdbg . AI agents are good at debugging from code alone — until the bug lives in runtime state. Then you need Xdebug, and every existing Xdebug tool is built for humans clicking through a GUI. PhpStorm ships an MCP server since 2025.2, but it is GET-only, has no headers, no path for CLI in Docker, and no control over Xdebug inside the container. So I built xdbg : an MCP server that gives an agent the full loop — enable Xdebug, set a breakpoint, fire a real request, step, inspect, detach. MIT licence, one-line install, works with Claude Code, opencode, Cursor and any MCP-capable client. Source: github.com/crazy-goat/xdbg Written against xdbg v0.1.1 (Go 1.26), Docker 29.7.2 / Compose 5.5.0, and any PHP 8 image with Xdebug 3. PhpStorm checked on 2025.2 and again on 2026.2.1. The mighty duo: var_dump and die This is the standard. You need to check something fast, so you print the value and stop the script. It is quick, it always works, and it needs no setup. function add ( int $a , int $b ): int { $result = $a + $b ; var_dump ( $result ); die (); } It also has costs. You are editing the code in order to debug it, and you only see the one place you thought to pr