Skip to main content
Glama
wallter

smart-xdebug-mcp

by wallter

set_breakpoint

Set a breakpoint at a local file and line number to pause execution during a PHP debugging session. Optionally add a condition to break only when a PHP expression is true.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileYesLOCAL file path relative to project root. Example: "app/Http/Controllers/UserController.php". Do NOT use container paths like /var/www/html/...
lineYesLine number to break at. Use the line with the code you want to inspect.
conditionNoPHP expression - break only if true. HIGHLY RECOMMENDED for loops. Examples: '$user->id === 5', '$i > 100', 'count($items) > 0'
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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