
Xdebug
io.github.kpanuraghPublished by GitHub account kpanuraghv1.2.1Updated Oct 24, 2026
MCP server for PHP Xdebug debugging with breakpoints, stepping, and variable inspection
Overview
Lets an AI assistant debug PHP applications through Xdebug's DBGp protocol, setting breakpoints, stepping through code, and inspecting variables.
- What you can do
- Runs a local MCP server that listens for Xdebug connections from PHP and exposes around 41 tools for debugging. It supports line, conditional, exception, and function-call breakpoints, execution control (step into, over, out, continue, stop, detach), variable and stack inspection, expression evaluation, watch expressions, logpoints, memory profiling, code coverage, request-context capture, step filters, debug profiles, and session export.
- When to use it
- Use it when you want an AI assistant to help debug PHP code interactively: setting breakpoints, stepping through execution, inspecting variables, or profiling a running script. It is aimed at local PHP development, including PHP running in Docker containers.
- Requirements
- A local Node.js runtime to run the npm package xdebug-mcp (or npx). PHP with the Xdebug extension configured for step debugging, pointing at the server's host and port. Optional environment variables include XDEBUG_PORT, XDEBUG_HOST, XDEBUG_SOCKET_PATH, PATH_MAPPINGS, COMMAND_TIMEOUT, MAX_DEPTH, MAX_CHILDREN, MAX_DATA, and LOG_LEVEL; proxy mode also uses DBGP_PROXY_HOST, DBGP_PROXY_PORT, and DBGP_IDEKEY.
Installation
In SourceWeft
- Open Xdebug in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
Xdebug MCP Server
An MCP (Model Context Protocol) server that provides PHP debugging capabilities through Xdebug's DBGp protocol. This allows AI assistants like Claude to directly debug PHP applications.
Features
Core Debugging
- Full Debug Control: Step into, step over, step out, continue, stop
- Breakpoints: Line breakpoints, conditional breakpoints, exception breakpoints, function call breakpoints
- Variable Inspection: View all variables, get specific variables, set variable values
- Expression Evaluation: Evaluate PHP expressions in the current context
- Stack Traces: View the full call stack
- Multiple Sessions: Debug multiple PHP scripts simultaneously
- Docker Support: Works with PHP running in Docker containers
Advanced Features
- Watch Expressions: Persistent watches that auto-evaluate on each break with change detection
- Logpoints: Log messages without stopping execution using
{$var}placeholders - Memory Profiling: Track memory usage and execution time between breakpoints
- Code Coverage: Track which lines were executed during debugging
- Request Context: Capture
$_GET,$_POST,$_SESSION,$_COOKIE, headers automatically - Step Filters: Skip vendor/library code during stepping
- Debug Profiles: Save and restore breakpoint configurations
- Session Export: Export debug sessions as JSON or HTML reports
Installation
From npm (Recommended)
From Source
MCP Server Configuration
For Claude Code
Add the xdebug-mcp server to your MCP configuration (.mcp.json or Claude settings):
Using npm global install:
Using npx:
With Path Mappings (for Docker)
When debugging PHP in Docker containers, you need path mappings to translate container paths to host paths:
With DBGp Proxy Registration
If you already use a DBGp proxy, keep mcp-config.example.json as the default direct-listener example and start from mcp-config.proxy.example.json for proxy registration.
Proxy mode requires:
- TCP listener mode for
xdebug-mcp(notXDEBUG_SOCKET_PATH) - a unique callback port such as
9006,9007, or9008forXDEBUG_PORT DBGP_PROXY_HOST,DBGP_PROXY_PORT, andDBGP_IDEKEY
See the DBGp Proxy Registration Guide for the full setup, multi-agent examples, and PHP/Xdebug proxy configuration.
PHP/Xdebug Configuration
php.ini (or xdebug.ini)
Docker Compose
Using Unix Domain Sockets
For improved performance and simplified setup on local systems, you can use Unix domain sockets instead of TCP. Unix sockets eliminate network stack overhead and are ideal for debugging on the same machine.
Benefits:
- ⚡ Lower latency (no TCP/IP stack overhead)
- 🔒 Better security (file permissions instead of port binding)
- 📦 Simpler setup (no port management)
- 🚀 Faster communication for local debugging
MCP Configuration (Unix Socket):
PHP/Xdebug Configuration:
Socket File Permissions:
The socket file is created with default permissions. To restrict access, you can:
Automatic Cleanup:
When XDEBUG_SOCKET_PATH is set, the server will:
- Listen on the specified Unix socket instead of TCP port
- Automatically clean up stale socket files on startup (prevents "address in use" errors)
- Automatically clean up socket files on shutdown
- Use the same debugging tools and features as TCP mode
When to Use Unix Sockets:
- ✅ Local PHP development (best performance)
- ✅ Same-machine debugging
- ✅ High-frequency breakpoint hits
- ❌ Remote debugging (use TCP instead)
Unix socket support requested in Issue #1 by @dkd-kaehm
Available MCP Tools (41 Total)
Session Management
Breakpoints
Pending Breakpoints: You can set breakpoints before a debug session starts. These are stored as "pending breakpoints" and automatically applied when a PHP script connects with Xdebug. This is useful for setting up breakpoints before triggering a page load or script execution.
Execution Control
Inspection
Watch Expressions
Logpoints
Profiling
Code Coverage
Debug Profiles
Additional Tools
Usage Examples
Setting a Breakpoint
Conditional Breakpoint
Watch Expression
Logpoint
Inspecting Variables
Capture Request Context
Environment Variables
Connection Modes: TCP vs Unix Socket
Quick Decision Guide:
- 🏠 Local development? → Use Unix socket for best performance
- 🐳 Docker on same machine? → Use Unix socket with volume mount
- 🌐 Remote server? → Use TCP
- 🚀 Maximum speed? → Use Unix socket
- 📝 Don't know? → Start with TCP (default), switch to Unix socket if needed
How It Works
- MCP Server starts and listens for Xdebug connections (TCP port 9003 or Unix socket)
- PHP script runs with Xdebug enabled
- Xdebug connects to the MCP server via DBGp protocol
- AI uses MCP tools to control debugging (set breakpoints, step, inspect)
- DBGp commands are sent to Xdebug, responses parsed and returned
Connection Options:
- TCP (Default):
xdebug.client_host=127.0.0.1+XDEBUG_PORT=9003 - Unix Socket:
xdebug.client_host=unix:///tmp/xdebug.sock+XDEBUG_SOCKET_PATH=/tmp/xdebug.sock
Troubleshooting
No debug sessions appearing
- Check that Xdebug is installed:
php -vshould show Xdebug - Verify Xdebug config:
php -i | grep xdebug - Ensure
xdebug.client_hostpoints to the MCP server - For TCP: Check firewall allows connections on port 9003
- For Unix socket: Verify socket path exists and has correct permissions:
ls -la /tmp/xdebug.sock - Check MCP server logs:
LOG_LEVEL=debugfor verbose output
Connection issues with Docker
- For Linux, add
extra_hosts: ["host.docker.internal:host-gateway"] - Verify container can reach host:
curl host.docker.internal:9003 - Check xdebug logs in container:
docker logs <container-id> | grep xdebug
Unix socket issues
- "Address already in use": Socket file wasn't cleaned up
- Remove manually:
rm -f /tmp/xdebug.sock - MCP server will clean up automatically on next start
- Remove manually:
- "Permission denied": Check socket file permissions
- List socket:
ls -la /tmp/xdebug.sock - Run as same user as PHP:
ps aux | grep php
- List socket:
- Socket path in php.ini:
- Correct:
xdebug.client_host=unix:///tmp/xdebug.sock - Wrong:
xdebug.client_host=unix:/tmp/xdebug.sock(missing one/)
- Correct:
Breakpoints not hitting
- Ensure file paths match exactly (use container paths for Docker)
- Check breakpoint is resolved:
list_breakpoints - Verify script execution reaches that line
- Check that
xdebug.start_with_request=yesis set - Try a simple file to verify basic setup works
Performance issues
- If experiencing slow stepping, increase
COMMAND_TIMEOUT:- Default: 30000ms (30 seconds)
- Try:
COMMAND_TIMEOUT=60000for slower systems
- For Unix sockets, verify socket is on fast filesystem (not network mount)
- Check system load:
top- excessive context switching slows debugging
Server won't start
- Port in use (TCP):
- Find process:
lsof -i :9003 - Kill it:
kill -9 <pid>
- Find process:
- Bad config:
- Validate environment variables:
echo $XDEBUG_SOCKET_PATH - Check for typos in path names
- Validate environment variables:
- Permission denied:
- For Unix socket, ensure write permission to parent directory
- Example:
mkdir -p ~/.xdebug && chmod 700 ~/.xdebug
Contributing
Contributions are welcome! Please feel free to submit a Pull Request.
License
MIT
Source: README.md at commit 8e7b574
Tools
0Version history
1- v1.2.1LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts