Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@smart-xdebug-mcp Set a breakpoint in PaymentService.php line 127 and inspect $user"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Let AI debug your PHP code.
Smart XDebug MCP connects Claude to your PHP application's debugger, enabling AI-assisted debugging that actually understands your code at runtime.
Debugging PHP applications traditionally requires:
Manually setting breakpoints in an IDE
Stepping through code line by line
Remembering to check the right variables at the right time
Context-switching between your AI assistant and your debugger
When you ask an AI to help debug, it can only see your code statically. It can't see what's actually happening when your code runs—what values variables hold, where execution flows, or why that exception was thrown.
Related MCP server: DebugMCP
Smart XDebug MCP gives Claude direct access to your PHP debugger. Instead of guessing what might be wrong, Claude can:
Set breakpoints at suspicious locations
Run your code and pause at those breakpoints
Inspect variables to see actual runtime values
Step through execution to understand the flow
Track variable changes over time with built-in history
It's like pair programming with a debugger expert who never gets tired and can analyze complex state instantly.
Faster debugging — Describe the bug, let AI investigate
Better insights — AI can correlate patterns across variables you might miss
Learning tool — Watch how an experienced debugger approaches problems
Runtime context — See actual values, not just code structure
Surgical precision — Request only the data needed, preventing context overload
Time-travel — Query what variables were at previous breakpoints
You: "My /api/orders endpoint returns empty for user 42, but they have orders in the database"
Claude: *Sets breakpoint in OrderController*
*Triggers the API request*
*Inspects $user, $query, $results at the breakpoint*
Claude: "Found it. The query filters by user_id but $user->id is null here
because the auth middleware isn't running on this route."No manual stepping. No guessing. Just answers.
npm install -g smart-xdebug-mcpAdd to your MCP settings (~/.config/claude/settings.json or project .mcp.json):
{
"mcpServers": {
"xdebug": {
"command": "npx",
"args": ["smart-xdebug-mcp"]
}
}
}Ensure your PHP environment has XDebug configured:
xdebug.mode = debug
xdebug.start_with_request = trigger
xdebug.client_host = host.docker.internal ; For Docker
xdebug.client_port = 9003Ask Claude to debug your PHP code:
"Set a breakpoint at app/Services/PaymentService.php line 127,
then run: curl 'http://localhost/api/checkout?XDEBUG_SESSION=mcp'"Feature | What It Does |
Natural Language Debugging | Tell Claude what to debug in plain English |
Smart Variable Inspection | AI requests only relevant data, not full dumps |
Time-Travel Queries | See what variables were at previous steps |
Automatic Path Mapping | Works with Docker without manual configuration |
Exception Detection | Auto-pause when errors occur |
Session History | Review what happened in past debug sessions |
"Why is this returning null?" — Trace execution to find where values disappear
"This loop seems slow" — Set conditional breakpoints to inspect specific iterations
"The API works locally but fails in Docker" — Debug the containerized app directly
"I inherited this codebase" — Let AI explore and explain runtime behavior
Node.js 18+
PHP with XDebug 3.x configured for remote debugging
Claude Code or another MCP-compatible AI assistant
Environment variables for advanced configuration:
Variable | Default | Description |
|
| XDebug listener port |
|
| Connection timeout (ms) |
|
| Auto-terminate idle sessions (5 min) |
Path mappings are auto-detected from .vscode/launch.json or docker-compose.yml.
Smart XDebug MCP acts as a bridge:
Claude ←→ MCP Protocol ←→ Smart XDebug MCP ←→ DBGp Protocol ←→ XDebug ←→ PHPThe server translates high-level debugging intent into DBGp commands, handles the complexity of the protocol, and returns clean, AI-friendly responses.
Contributions are welcome! See CONTRIBUTING.md for guidelines.
Copyright 2026 Tyler Wall
Licensed under the Apache License, Version 2.0. See LICENSE for details.
Keywords: PHP debugging, AI debugging, Claude MCP, XDebug integration, autonomous debugging, Model Context Protocol, PHP development tools, AI-assisted development, remote debugging, Docker PHP debugging
Controls the debugger's execution flow. Use to step through code or end sessions.
ACTIONS:
step_over: Execute current line, pause at next line in same scope. Use when: Line calls a function you don't need to debug. Example: Skip framework internals, focus on your logic.
step_into: Step INTO the function call on the current line. Use when: You need to debug inside a called function. Example: Debug why UserService::create() fails.
step_out: Run until current function returns to its caller. Use when: Done debugging a function, want to return to caller. Example: Finished debugging a helper, return to controller.
continue: Run until next breakpoint or exception. Use when: Skip to the next interesting point. Example: Jump from authentication to order processing.
stop: Terminate the debug session immediately. Use when: Done debugging, or session is stuck/errored. IMPORTANT: Always stop sessions when done to free the port.
REQUIRES:
Any action: Session must be active
step_over/step_into/step_out/continue: Session must be paused
AFTER STOP: You can start a new session with start_debug_session.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The action: 'step_over' (next line), 'step_into' (enter function), 'step_out' (exit function), 'continue' (run to breakpoint), 'stop' (end session) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the transparency burden. It explains the behavior of each action (e.g., step_over executes current line and pauses next, stop terminates session) and includes important notes like freeing ports after stop. This provides clear expectations of tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for ACTIONS (each with concise description, use case, example), REQUIRES, and AFTER STOP. Every sentence adds value, and the format is easy to scan. It is appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and only one parameter, the description is complete. It covers all actions, prerequisites, and post-stop behavior. It also addresses potential errors implicitly by requiring paused state for stepping actions. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema. While the schema describes each enum value, the description provides use cases and examples (e.g., 'Skip framework internals' for step_over, 'Debug why UserService::create() fails' for step_into), enriching parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Controls the debugger's execution flow. Use to step through code or end sessions.' It lists specific actions that distinguish it from sibling tools like start_debug_session, set_breakpoint, etc., making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance for each action (e.g., 'Use when: Line calls a function you don't need to debug.' for step_over) and states prerequisites (session must be active, paused for stepping/continue). It also advises to always stop sessions to free ports, covering both when and how to use the tool effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current debug session status. Call this FIRST before starting a new session.
WHEN TO USE:
Before start_debug_session: Check if a session is already active
During debugging: See current location and available actions
After errors: Diagnose session state
RETURNS:
active: Whether a session exists
status: Current state (see below)
location: Current file and line when paused
available_actions: Valid control_execution actions
breakpoints: List of registered breakpoints
SESSION STATES:
"initializing": Starting, waiting for XDebug connection
"listening": Listening for connections (XDebug not connected yet)
"connected": XDebug connected, execution starting
"paused": Stopped at breakpoint - can inspect variables and step
"running": Code executing, waiting for breakpoint
"stopped": Session ended
"error": Session in error state
STUCK SESSION RECOVERY: If status is "initializing" for >30 seconds, the connection likely failed. Use control_execution with action="stop" to reset, then check your XDebug configuration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fully discloses return fields (active, status, location, available_actions, breakpoints), session states, and recovery steps. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (WHEN TO USE, RETURNS, SESSION STATES, STUCK SESSION RECOVERY). Every sentence adds value, and it is concise without being terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of debug session status, the description is very complete. It includes all return fields, session states, and recovery instructions. No output schema exists, but the description compensates fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema coverage is 100%. Baseline for 0 parameters is 4. The description adds value by explaining the output, though not required for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the current debug session status and specifies it should be called first before starting a new session. It distinguishes itself from sibling tools by being a read-only status check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHEN TO USE' section provides explicit contexts: before start_debug_session, during debugging, after errors. It also includes a 'STUCK SESSION RECOVERY' section with actionable steps, giving clear guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspects a PHP variable's value at the current breakpoint. Only works when session is PAUSED.
WHEN TO USE:
After hitting a breakpoint (status="paused")
To examine specific values causing bugs
To understand object structure before filtering
CONTEXT EFFICIENCY - Full dumps are expensive. Use JSONPath filters: BAD (returns thousands of lines): inspect_variable("$order") GOOD (returns only what you need): inspect_variable("$order", "$.total") inspect_variable("$order", "$.items[*].sku") inspect_variable("$request", "$.input.email")
Without a filter, returns structure only (keys/types, no values).
JSONPATH EXAMPLES:
'$.property' - Single property
'$.items[0]' - First array element
'$.items[*].id' - All IDs in items array
'$.user.profile.name' - Nested property
REQUIRES: Session must be paused. Call get_session_status to verify.
COMMON VARIABLES:
'$this' - Current object instance
'$request' - HTTP request (Laravel)
'$_GET', '$_POST', '$_SERVER' - PHP superglobals
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | PHP variable name including $. Examples: '$this', '$request', '$user', '$_SERVER' | |
| depth | No | Recursion depth for nested objects. Default 1, max 3. Higher values return more data but cost more context. | |
| filter | No | JSONPath to filter results. Examples: '$.email', '$.items[0].price', '$.user.name'. Omit for structure-only view. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits such as returning structure only without a filter, the expensiveness of full dumps, use of JSONPath filtering, recursion depth limits, and the requirement for a paused session. No annotations are present, so the description carries the full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear section headers (WHEN TO USE, CONTEXT EFFICIENCY, JSONPATH EXAMPLES, REQUIRES, COMMON VARIABLES). It is front-loaded with the core purpose and each section provides relevant, non-redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a debugging tool with parameters for filtering and depth, and no output schema, the description is complete: covers prerequisites, usage guidelines, efficiency tips, examples, and common variable names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant context: explains the filter parameter with JSONPath syntax and examples, depth with context cost implications, and name with common variable examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Inspects a PHP variable's value at the current breakpoint.' It specifies the context (session paused) and distinguishes from sibling tools by focusing on inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'WHEN TO USE' section specifying appropriate scenarios (after hitting a breakpoint, to examine values, to understand object structure) and a 'REQUIRES' condition (session paused) with a suggestion to verify via get_session_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query past variable values from the session recorder (time-travel debugging).
WHEN TO USE:
To see how a variable changed over execution steps
To compare values between steps without re-running
To understand state progression leading to a bug
DOES NOT REQUIRE PAUSED STATE - can query history anytime during an active session.
RETURNS: Array of historical values with step numbers and timestamps, showing how the variable changed over time.
LIMITATION: Only variables that were inspected via inspect_variable are recorded. If you didn't inspect a variable at a step, it won't have history for that step.
EXAMPLE USAGE: "What was $user->status 3 steps ago?" query_history("$user->status", steps_ago=3)
"Show me the last 10 values of $total" query_history("$total", limit=10)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of history entries to return. Useful for seeing variable progression over time. | |
| steps_ago | No | How many steps back to look. 0 = current step, 1 = previous step, 2 = two steps ago, etc. | |
| variable_name | Yes | PHP variable name to query history for. Example: '$user', '$status', '$order->total' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly explains behavior: it returns an array of historical values with step numbers and timestamps, can be used anytime during an active session, and discloses the key limitation that only variables inspected via inspect_variable are recorded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headers, bullet points, and an example. Every sentence contributes meaningful information without redundancy, and it is concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of time-travel debugging, no output schema, and full schema coverage, the description is complete: it explains the return format, usage context, limitations, and provides examples. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. However, the description adds value by explaining parameter semantics beyond the schema: it includes concrete examples (e.g., 'What was $user->status 3 steps ago?') and clarifies behavior (e.g., limit helps see progression). This justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries past variable values from a session recorder for time-travel debugging, with a specific verb ('query') and resource ('past variable values'). It is distinct from siblings like inspect_variable (current value) and control_execution (execution control).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' section with three bullet points for appropriate contexts, plus a note that it does not require a paused state and a clear limitation about variable tracking, leaving no ambiguity about when to use or not use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sets a breakpoint at a specific file and line. Breakpoints persist until the session ends.
WHEN TO USE:
BEFORE calling start_debug_session to set initial breakpoints
DURING a paused session to add additional breakpoints
PATH FORMAT - Use LOCAL paths relative to your project root:
Correct: "app/Http/Controllers/UserController.php"
Correct: "src/Services/PaymentService.php"
Wrong: "/var/www/html/app/..." (don't use container paths)
The tool automatically translates local paths to container paths using mappings from .vscode/launch.json, docker-compose.yml, or XDEBUG_MCP_PATH_MAPPINGS env var.
CONDITIONAL BREAKPOINTS - For loops, ALWAYS use conditions:
'$i > 100' - Break when loop counter exceeds 100
'$user->id === 42' - Break for specific user
'count($items) > 0' - Break when array has items
RETURNS:
breakpoint_id: Unique identifier
remotePath: The translated container path (verify this matches your container)
warning: Included if local file doesn't exist
AFTER SETTING: Call start_debug_session to begin debugging.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | LOCAL file path relative to project root. Example: "app/Http/Controllers/UserController.php". Do NOT use container paths like /var/www/html/... | |
| line | Yes | Line number to break at. Use the line with the code you want to inspect. | |
| condition | No | PHP expression - break only if true. HIGHLY RECOMMENDED for loops. Examples: '$user->id === 5', '$i > 100', 'count($items) > 0' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that breakpoints persist until session ends, path translation from local to container paths, and return values including warning if file doesn't exist. However, it doesn't explicitly mention any side effects or potential failures beyond file existence. No annotations provided, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear headings (WHEN TO USE, PATH FORMAT, CONDITIONAL BREAKPOINTS, RETURNS, AFTER SETTING). Each section is relevant and concise, though somewhat lengthy. First paragraph directly states purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 3 parameters, no annotations, and no output schema, the description is exceptionally thorough. Covers purpose, usage timing, path format, conditional expressions, return values, and next steps. Leaves no important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 3 parameters with descriptions (100% coverage). The description adds significant value with path format examples, condition expression examples, and usage context (e.g., 'HIGHLY RECOMMENDED for loops'). Exceeds schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Sets a breakpoint at a specific file and line' with a specific verb and resource. It distinguishes from sibling tools like start_debug_session by explaining when to use it (before or during debugging).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN TO USE section: before start_debug_session for initial breakpoints or during a paused session. Also provides path format guidance and conditional breakpoint recommendations, and tells the agent to call start_debug_session after setting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Starts a new PHP debugging session by listening for XDebug connections and executing a trigger command.
WORKFLOW - Call tools in this order:
get_session_status - Check if a session is already active
set_breakpoint - Set breakpoints at locations you want to inspect
start_debug_session - Start the session with your trigger command
inspect_variable / control_execution - Debug at breakpoints
BEFORE CALLING:
Call get_session_status first. If a session is active, use control_execution with action="stop" to end it.
Set breakpoints BEFORE calling this (unless using stop_on_entry or stop_on_exception).
XDEBUG TRIGGERING: For xdebug.start_with_request=trigger (common in Docker), append the trigger to your URL:
Query param: ?XDEBUG_SESSION=1
Example: curl 'http://localhost/api/users?XDEBUG_SESSION=1' The trigger is NOT auto-added - you must include it in your command.
HOW IT WORKS:
Starts listening on port 9003 (or XDEBUG_MCP_PORT)
Executes your trigger command in a subprocess
Waits for XDebug to connect (timeout: 30s)
Pauses when a breakpoint is hit, exception thrown, or entry reached
LIMITATIONS:
Only one session can be active at a time
Only listens on one port (cannot debug multiple services simultaneously)
COMMON ERRORS:
"SESSION_ALREADY_ACTIVE": Call control_execution with action="stop" first
Timeout: Ensure XDebug is configured and ?XDEBUG_SESSION=1 is in your URL
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The command to trigger PHP execution. IMPORTANT: Include ?XDEBUG_SESSION=1 in URLs for trigger mode. Examples: 'curl http://localhost/api/users?XDEBUG_SESSION=1' or 'php artisan test --filter=UserTest' | |
| stop_on_entry | No | If true, pauses at the very first line of execution. Use when you dont know where to set breakpoints. | |
| stop_on_exception | No | If true, pauses automatically when an Error or Exception is thrown. Recommended for debugging crashes and 500 errors. | |
| working_directory | No | Working directory for the trigger command. Defaults to project root. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels. It details the internal process (listening on port 9003, executing command, waiting 30s timeout, pausing at breakpoints), limitations (single session, single port), and common errors (SESSION_ALREADY_ACTIVE, timeout). This fully discloses behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-structured with clear sections (WORKFLOW, BEFORE CALLING, XDEBUG TRIGGERING, HOW IT WORKS, etc.). Every section provides necessary context. It could potentially be slightly shorter, but the structure justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema), the description is remarkably complete. It covers preconditions, workflow, triggering mechanics, limitations, common errors, and parameter details. No gaps remain for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100%, the description adds significant meaning: it emphasizes adding ?XDEBUG_SESSION=1 in the command parameter, explains stop_on_entry and stop_on_exception usage, and notes working_directory defaults. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb-resource statement: 'Starts a new PHP debugging session by listening for XDebug connections and executing a trigger command.' It distinguishes from siblings like set_breakpoint and control_execution by outlining a workflow and stating its role in the sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call this tool (after get_session_status and set_breakpoint), when not to (if a session is active, use control_execution stop first), and alternative actions. It also provides a numbered workflow and common errors, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a unique, non-overlapping purpose: session start, breakpoint setting, variable inspection, execution control, status checking, and history querying. No ambiguity between them.
All tool names follow a consistent verb_noun snake_case pattern (e.g., start_debug_session, set_breakpoint), making them predictable and easy to understand.
With 6 tools, the set is well-scoped for a debugging server. Each tool is essential, covering the full debugging workflow without unnecessary bloat or shortage.
The tool set covers the core debugging lifecycle: start, breakpoints, inspect, control, status, and history. Minor gap is the lack of a tool to remove individual breakpoints without ending the session, but the set is otherwise complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live browser debugging for AI assistants — DOM, console, network via MCP.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wallter/smart-xdebug-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
