Skip to main content
Glama
wallter

smart-xdebug-mcp

by wallter

start_debug_session

Initiates a PHP debugging session by executing a command and listening for XDebug connections to pause execution at breakpoints, entry points, or exceptions.

Instructions

Starts a new PHP debugging session by listening for XDebug connections and executing a trigger command.

WORKFLOW - Call tools in this order:

  1. get_session_status - Check if a session is already active

  2. set_breakpoint - Set breakpoints at locations you want to inspect

  3. start_debug_session - Start the session with your trigger command

  4. 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:

HOW IT WORKS:

  1. Starts listening on port 9003 (or XDEBUG_MCP_PORT)

  2. Executes your trigger command in a subprocess

  3. Waits for XDebug to connect (timeout: 30s)

  4. 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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commandYesThe 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_entryNoIf true, pauses at the very first line of execution. Use when you dont know where to set breakpoints.
stop_on_exceptionNoIf true, pauses automatically when an Error or Exception is thrown. Recommended for debugging crashes and 500 errors.
working_directoryNoWorking directory for the trigger command. Defaults to project root.
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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