Integrates with GitHub Copilot in VS Code to provide breakpoint-based Python debugging capabilities, allowing AI assistants to set breakpoints, inspect local variables, and perform step execution through natural language commands.
Provides advanced Python debugging capabilities using debugpy and the Debug Adapter Protocol (DAP), enabling breakpoint management, step execution (step-in, step-over, step-out), variable inspection, and isolated process debugging for Python scripts.
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., "@Debug-MCP Set a breakpoint at line 25 in main.py and show me the local variables"
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.
A Python debugging tool that exposes breakpoint-based debugging capabilities through a clean API and CLI, designed for integration with AI assistants and development tools.
English | 日本語
Advanced Debugging via DAP: Production-ready debugging using Microsoft's debugpy
Breakpoint Debugging: Set breakpoints and inspect local variables at runtime
Step Execution: True step-in, step-over, step-out operations
No Corruption: Isolated process execution prevents sys.modules issues
Environment-aware: Automatically uses target project's Python interpreter
Session Management: Isolated debug sessions with timeout protection
Dual Interface:
CLI: Interactive debugging with beautiful table output
MCP Server: Official MCP SDK-based integration for AI assistants
Safe Execution: Sandboxed subprocess execution with configurable limits
Type Safety: Pydantic v2 schemas for request/response validation
Async Support: Built on MCP SDK with full async/await support
Comprehensive Testing: 254 tests (119 unit + 122 integration + 13 exploration) covering DAP workflows, session management, and edge cases
Legacy Compatibility: Optional bdb mode for backward compatibility
Related MCP server: mcp-debugpy
# Clone repository
git clone https://github.com/your-org/Debug-MCP.git
cd Debug-MCP
# Create virtual environment
uv venv
# Install with CLI support
uv pip install -e ".[cli]"To use this tool with GitHub Copilot in VS Code, set up the MCP server configuration.
See VS Code Setup Guide for detailed instructions.
Quick Setup (Using from Debug-MCP repository):
Create MCP config directory (macOS/Linux):
mkdir -p ~/Library/Application\ Support/Code/User/globalStorage/github.copilot-chatEdit mcp.json file:
{
"mcpServers": {
"python-debug": {
"command": "uv",
"args": ["run", "mcp-debug-server", "--workspace", "${workspaceFolder}"],
"env": {"PYTHONUNBUFFERED": "1"}
}
}
}Restart VS Code
Using from Another Repository:
When using this tool from a different repository, specify the Debug-MCP installation path:
{
"mcpServers": {
"python-debug": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/Debug-MCP",
"run",
"mcp-debug-server",
"--workspace",
"${workspaceFolder}"
],
"env": {
"PYTHONUNBUFFERED": "1"
}
}
}
}Replace /absolute/path/to/Debug-MCP with the actual path to your Debug-MCP installation.
Using Copilot Chat:
@workspace Set a breakpoint at line 42 in src/main.py and
show me the local variables at that point.See mcp-config-example.json for a complete configuration example.
# Start a debug session
SESSION_ID=$(uv run mcp-debug start-session src/app.py | jq -r .sessionId)
# Run to breakpoint and inspect locals
uv run mcp-debug run-to-breakpoint $SESSION_ID src/app.py 42 --format table
# Continue to next breakpoint
uv run mcp-debug continue $SESSION_ID src/app.py 100 --format table
# Check session state
uv run mcp-debug state $SESSION_ID --format table
# End session
uv run mcp-debug end $SESSION_IDSee Quickstart Guide for more CLI examples.
from pathlib import Path
from mcp_debug_tool.sessions import SessionManager
from mcp_debug_tool.schemas import StartSessionRequest, BreakpointRequest
# Initialize
workspace = Path.cwd()
manager = SessionManager(workspace)
# Create session
req = StartSessionRequest(entry="src/main.py", args=["--verbose"])
session = manager.create_session(req)
# Run to breakpoint
bp_req = BreakpointRequest(file="src/main.py", line=15)
result = manager.run_to_breakpoint(session.sessionId, bp_req)
if result.hit:
print(f"Paused at {result.frameInfo.file}:{result.frameInfo.line}")
print(f"Locals: {result.locals}")
# Continue execution
continue_result = manager.continue_execution(
session.sessionId,
BreakpointRequest(file="src/main.py", line=42)
)
# Cleanup
manager.end_session(session.sessionId)Timeout: 20 seconds per breakpoint operation (configurable)
Output Capture: 10MB maximum per session
Variable Depth: Max 2 levels of nesting in local variable inspection
Collection Size: Max 50 items shown in lists/dicts
String Length: Max 256 characters before truncation
Path Validation: Only project-relative paths allowed (no .. traversal)
Subprocess Isolation: Debuggee runs in isolated subprocess
Working Directory: Locked to workspace root
No Network: Debuggee has no special network access (app code may still use network)
⚠️ Important: The debugger executes user code with minimal restrictions. Only debug trusted code.
Debug-MCP now uses DAP (Debug Adapter Protocol) via debugpy for production debugging:
┌─────────────────────────────────────────────────┐
│ MCP Server (server.py) │
│ - Official MCP SDK (async) │
│ - Tool registration & routing │
└────────────────┬────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ Session Manager (sessions.py) │
│ - Lifecycle management │
│ - DAP/bdb mode selection │
└────────────────┬────────────────────────────────┘
│
▼ (DAP mode - default)
┌─────────────────────────────────────────────────┐
│ DAPSyncWrapper (dap_wrapper.py) │
│ - Synchronous DAP interface │
│ - Event queue management │
│ - Timeout handling │
└────────────────┬────────────────────────────────┘
│ DAP Protocol (JSON-RPC)
▼
┌─────────────────────────────────────────────────┐
│ debugpy Server (separate process) │
│ - Microsoft's official DAP implementation │
│ - Handles breakpoints, stepping, variables │
│ - Manages target script execution │
└────────────────┬────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ Target Python Script │
│ - Runs in isolated process │
│ - Full access to target dependencies │
│ - No sys.modules corruption │
└─────────────────────────────────────────────────┘Why DAP (debugpy)?
✅ No sys.modules corruption - Runs in separate process
✅ True step execution - Maintains execution state across steps
✅ Automatic environment handling - Uses target Python interpreter
✅ Industry standard - Microsoft's battle-tested implementation
✅ Rich features - Step in/over/out, conditional breakpoints, watch expressions
✅ Future-proof - Easy to extend with advanced debugging features
Communication Flow:
MCP Client (VS Code Copilot) → MCP Server (tool call)
Server → SessionManager (sync method via async wrapper)
SessionManager → DAPSyncWrapper (manages DAP session)
DAPSyncWrapper ↔ debugpy Server (DAP protocol over socket)
debugpy captures locals → DAPSyncWrapper → SessionManager → Server → Client
The bdb-based implementation is still available for compatibility (useDap=false):
SessionManager → runner_main.py (subprocess) → DebugController (bdb)However, DAP is now the default and recommended for all use cases. The bdb mode has known issues:
sys.modules corruption with multiple runs
No true step execution (replay-based)
Complex PYTHONPATH management
Active Files (Production):
✅ server.py - MCP SDK server
✅ sessions.py - Session lifecycle management
✅ dap_wrapper.py - DAP synchronous wrapper (PRIMARY)
✅ dap_client.py - Low-level DAP protocol client (PRIMARY)
✅ schemas.py - Pydantic models
✅ utils.py - Variable repr helpers and path utilities
Legacy Files (Compatibility):
⚠️ debugger.py - bdb-based engine (legacy, use useDap=false)
⚠️ runner_main.py - bdb subprocess runner (legacy)
Removed Files:
runner.py
See docs/development.md for detailed setup instructions.
Quick commands:
# Run all tests (254 tests: 119 unit + 122 integration + 13 exploration)
uv run pytest
# Run only unit tests
uv run pytest tests/unit/
# Run only integration tests
uv run pytest tests/integration/
# Run tests with coverage
uv run pytest --cov=src/mcp_debug_tool --cov-report=html
# Lint
uv run ruff check .
# Format
uv run ruff format .
# Auto-fix lint issues
uv run ruff check --fix .Debug-MCP/
├── src/
│ ├── mcp_debug_tool/ # Core debugging engine
│ │ ├── server.py # MCP SDK-based server (v2.0+)
│ │ ├── sessions.py # Session management (DAP/bdb mode selection)
│ │ ├── dap_wrapper.py # DAP synchronous wrapper (PRIMARY)
│ │ ├── dap_client.py # DAP protocol client (PRIMARY)
│ │ ├── debugger.py # bdb-based debugger (LEGACY, use useDap=false)
│ │ ├── runner_main.py # bdb subprocess runner (LEGACY)
│ │ ├── schemas.py # Pydantic models
│ │ └── utils.py # Variable repr helpers
│ └── cli/
│ └── main.py # Typer CLI
├── tests/
│ ├── unit/ # Unit tests (debugger, schemas, DAP, sessions)
│ └── integration/ # Integration tests (DAP workflows, bdb compat)
├── specs/
│ └── 001-python-debug-tool/ # Specification documents
└── docs/ # Additional documentation
├── dap-phase*-*.md # DAP integration documentation
└── roadmap.md # Future enhancementsVS Code Setup Guide - How to use MCP tool with VS Code Copilot ⭐
Quickstart Guide - CLI and API usage examples
Specification - Complete feature specification
Data Model - Entity schemas and validation rules
Research - Design decisions and rationale
Development Guide - Setup and contribution guide
Performance Tuning - Timeout and resource configuration
Roadmap - Planned v2 features
v2.0 Released! DAP Integration Complete 🎉
✅ Phase 1: Foundation (Complete - 6/6 tests passing)
✅ Phase 2: Core Logic (Complete - 28/28 tests passing)
✅ Phase 3: Session Lifecycle (Complete - 29/29 tests passing)
✅ Phase 4: Breakpoint Operations (Complete - 41/41 tests passing)
✅ Phase 5: Error Visibility (Complete - 71/71 tests passing)
✅ Phase 6: MCP SDK Migration (Complete - SDK-based server with async support)
✅ Phase 7: DAP Integration (Complete - Production-ready debugpy integration)
What's New in v2.0:
DAP (debugpy) is now the default - No more sys.modules corruption!
True step execution - Step in, step over, step out all working
Automatic environment handling - Uses target project's Python interpreter
Industry-standard protocol - Microsoft's battle-tested implementation
Enhanced reliability - Isolated process execution prevents crashes
Backward compatible - Legacy bdb mode still available with useDap=false
Migration from v1.x:
Existing code works as-is (DAP is opt-in by default)
To explicitly use bdb: StartSessionRequest(entry="...", useDap=False)
Recommended: Let it default to DAP for best results
Script entry only: No module (python -m) or pytest target support (planned for v2.1)
Single-threaded: No support for multi-threaded debugging (planned for v2.1)
Line breakpoints: Conditional breakpoints not yet exposed via MCP (DAP supports it)
✅ Resolved from v1:
No stepping → Now available: Step in, step over, step out
sys.modules corruption → Fixed: DAP uses isolated processes
Python environment mismatch → Fixed: Uses target interpreter
See docs/roadmap.md for planned v2.1+ enhancements.
Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Make your changes with tests
Run tests and linting (uv run pytest && uv run ruff check .)
Commit changes (git commit -m 'Add amazing feature')
Push to branch (git push origin feature/amazing-feature)
Open a Pull Request
MIT License - see LICENSE file for details
Built with:
debugpy - Microsoft's Python debugger (DAP implementation)
MCP SDK - Model Context Protocol Python SDK
bdb/pdb - Python's standard debugger framework (legacy mode)
Pydantic - Data validation using Python type annotations
Typer - CLI framework built on Click
Rich - Beautiful terminal formatting
pytest - Testing framework
Run to a breakpoint and capture local variables
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The debug session ID | |
| file | Yes | Project-relative file path | |
| line | Yes | Line number (1-based) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action and outcome but lacks details on permissions, side effects (e.g., whether execution pauses or resumes after), error handling, or rate limits. For a debugging tool with potential mutation effects, this is a significant gap in transparency.
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 a single, efficient sentence that front-loads the core action and outcome without unnecessary words. Every part of the sentence earns its place by clearly conveying the tool's purpose, making it highly concise and well-structured.
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 a debugging tool with no annotations and no output schema, the description is minimally adequate. It states what the tool does but lacks details on behavioral traits, return values, or error conditions. For a tool that interacts with debug sessions, more context on execution flow and results would improve completeness.
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 description coverage is 100%, so the input schema already documents all parameters (sessionId, file, line) with clear descriptions. The description does not add any additional meaning, syntax, or format details beyond what the schema provides, resulting in a baseline score of 3 where the schema handles the parameter documentation adequately.
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 specific action ('Run to a breakpoint') and the outcome ('capture local variables'), distinguishing it from sibling tools like sessions_continue (continue execution) or sessions_step_* (step through code). It precisely defines what the tool does without being vague or tautological.
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 implies usage in a debugging context to stop at a specific breakpoint and gather variable data, but it does not explicitly state when to use this tool versus alternatives like sessions_step_over (step over a line) or sessions_continue (resume execution). No exclusions or prerequisites are mentioned, leaving usage context inferred rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Continue execution to the next breakpoint
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The debug session ID | |
| file | Yes | Project-relative file path | |
| line | Yes | Line number (1-based) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't explain what happens during execution (e.g., whether it runs until a breakpoint is hit, what occurs if no breakpoint exists, or if it requires specific permissions). For a debug operation with potential side effects, this lack of detail is a significant gap.
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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and easy to parse, making it highly concise and well-structured for quick comprehension by an AI agent.
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 a debug operation (with no annotations and no output schema), the description is incomplete. It lacks details on behavioral outcomes, error conditions, or what the tool returns, which are critical for an agent to use it effectively. The high schema coverage doesn't compensate for these missing contextual elements.
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 input schema has 100% description coverage, clearly documenting all three required parameters (sessionId, file, line). The description adds no additional parameter semantics beyond what the schema provides, such as explaining how these parameters interact during continuation. This meets the baseline for high schema coverage but doesn't enhance 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 the action ('Continue execution') and the target ('to the next breakpoint'), which is specific and unambiguous. It distinguishes itself from siblings like sessions_step_in/out/over by focusing on continuation to breakpoints rather than stepping through code. However, it doesn't explicitly mention debugging context, which is implied but could be more explicit.
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 no guidance on when to use this tool versus alternatives like sessions_step_in, sessions_step_over, or sessions_step_out. It doesn't mention prerequisites (e.g., requires an active debug session), nor does it clarify scenarios where continuing to a breakpoint is preferred over stepping. This leaves the agent without clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new debug session for a Python script
| Name | Required | Description | Default |
|---|---|---|---|
| entry | Yes | Project-relative path to Python script | |
| pythonPath | Yes | Absolute path to Python interpreter (must have debugpy installed) | |
| args | No | Command-line arguments for the script | |
| env | No | Environment variables |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Create') but doesn't describe what happens after creation, whether the session starts automatically, what permissions are needed, or any side effects. This leaves significant gaps for a creation tool.
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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded with the core functionality.
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 creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a 'debug session' entails, what gets returned, or any behavioral context beyond the basic creation action, leaving important gaps in understanding.
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 description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description doesn't add any additional meaning about parameters beyond what's in the schema, which meets the baseline expectation when schema coverage is high.
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 specific action ('Create a new debug session') and the target resource ('for a Python script'), distinguishing it from sibling tools like sessions_breakpoint or sessions_end which operate on existing sessions rather than creating new ones.
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?
No guidance is provided on when to use this tool versus alternatives. While the description implies this is for initial session creation, it doesn't specify prerequisites, timing considerations, or contrast with other session management tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End a debug session and clean up resources
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The debug session ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'clean up resources', hinting at a destructive action, but doesn't specify if this is irreversible, what resources are cleaned up, or any side effects (e.g., terminating processes). This is inadequate for a tool that likely performs a mutation with potential impacts.
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 a single, efficient sentence that is front-loaded with the core action ('End a debug session') and includes a useful outcome ('clean up resources'). There is no wasted verbiage, making it highly concise and well-structured.
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 ending a debug session (a likely destructive operation), no annotations, and no output schema, the description is incomplete. It lacks details on behavior, error conditions, or what happens post-execution, leaving significant gaps for the agent to understand the tool's full context.
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 input schema has 100% description coverage, with the parameter 'sessionId' clearly documented. The description adds no additional meaning beyond the schema, such as format examples or constraints, so it meets the baseline of 3 where the schema does the heavy lifting.
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 with a specific verb ('End') and resource ('a debug session'), and it adds the outcome ('clean up resources'). However, it doesn't explicitly differentiate from sibling tools like sessions_continue or sessions_state, which might also affect session states, so it's not a perfect 5.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active session), exclusions (e.g., not for paused sessions), or refer to sibling tools like sessions_create for starting sessions, leaving the agent with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current state of a debug session
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The debug session ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool 'gets' state, implying a read-only operation, but doesn't clarify if this requires specific permissions, what data is returned, or any side effects. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, clear sentence that front-loads the core purpose without unnecessary details. It efficiently communicates the tool's function in minimal words, earning its place with zero waste.
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 low complexity (one parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose but lacks context on usage, behavioral traits, or output format. For a debug session tool, more detail on what 'state' includes would be helpful, though the simplicity keeps it minimally viable.
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 description coverage is 100%, with the single parameter 'sessionId' documented in the schema. The description doesn't add any meaning beyond the schema, such as explaining session ID format or where to obtain it. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
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 with a specific verb ('Get') and resource ('current state of a debug session'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'sessions_create' or 'sessions_end', which would require mentioning this is a read operation versus creation/termination tools.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing session), exclusions, or comparisons to siblings like 'sessions_breakpoint' for debugging control. Without this context, users must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step into the next function call (requires active breakpoint)
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The debug session ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions the breakpoint requirement. It doesn't disclose other behavioral traits like whether this is a read-only operation, what happens if no breakpoint is active, error conditions, or side effects. More context is needed for a mutation tool.
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 a single, efficient sentence with zero waste. It's front-loaded with the core action and includes a crucial prerequisite, making it appropriately sized and well-structured.
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 no annotations and no output schema, the description is incomplete for a debugging tool. It lacks details on return values, error handling, and full behavioral context, which are essential for an agent to use it correctly in a session management context.
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 the schema fully documents the 'sessionId' parameter. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline for high coverage.
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 action ('Step into') and target ('next function call'), specifying it's for debugging with a breakpoint requirement. It distinguishes from siblings like 'step_over' or 'step_out' by focusing on entering functions, though it doesn't explicitly name alternatives.
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 implies usage context ('requires active breakpoint') but doesn't explicitly state when to use this versus alternatives like 'step_over' or 'continue'. It provides a prerequisite but lacks clear differentiation from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step out of the current function (requires active breakpoint)
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The debug session ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the requirement of an 'active breakpoint', which adds useful context about preconditions. However, it lacks details on what 'step out' entails (e.g., does it exit to the caller, affect session state, or have side effects?), making it insufficient for a mutation tool in debugging.
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 a single, efficient sentence that front-loads the core action ('step out of the current function') and includes a crucial precondition ('requires active breakpoint') without any wasted words. Every part earns its place by providing essential information concisely.
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 (a debugging operation with mutation implications), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and a key precondition but lacks details on behavior, error cases, or return values, leaving gaps for an agent to understand full usage.
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 input schema has 100% description coverage, with the parameter 'sessionId' documented as 'The debug session ID'. The description does not add any meaning beyond this, as it doesn't explain parameter usage or constraints. Baseline score of 3 is appropriate since the schema handles the parameter documentation adequately.
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 action ('step out of') and the context ('current function'), which is a specific debugging operation. It distinguishes from siblings like 'step_in' and 'step_over' by implying movement out of a function rather than into or over lines. However, it doesn't explicitly name the resource (e.g., debug session) beyond the parameter, keeping it from a perfect score.
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 implied usage context by stating 'requires active breakpoint', which suggests when to use this tool (during debugging with a breakpoint set). However, it doesn't explicitly differentiate when to use this vs. alternatives like 'sessions_continue' or 'sessions_step_over', nor does it specify prerequisites beyond the breakpoint requirement, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step over the current line (requires active breakpoint)
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The debug session ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the prerequisite of an active breakpoint, which is useful context, but doesn't describe what 'step over' entails (e.g., whether it executes the current line and moves to the next, or skips function calls), potential side effects, error conditions, or response format. This leaves significant gaps in understanding the tool's 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 a single, efficient sentence that directly states the action and prerequisite without any unnecessary words. It is front-loaded and appropriately sized, making it easy for an agent to parse quickly.
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 a debugging operation with no annotations and no output schema, the description is incomplete. It lacks details on what 'step over' means behaviorally, potential outputs, error handling, or how it differs from sibling tools. This makes it insufficient for an agent to fully understand the tool's context and usage.
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 input schema has 100% description coverage, with 'sessionId' clearly documented as 'The debug session ID'. The description adds no additional parameter information beyond this, so it doesn't compensate or add meaning. According to the rules, with high schema coverage, the baseline is 3, which is appropriate here.
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 action ('Step over the current line') and specifies the prerequisite ('requires active breakpoint'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'sessions_step_in' or 'sessions_step_out', which likely have similar debugging functions, so it doesn't reach the highest score.
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 implies usage context by stating 'requires active breakpoint', suggesting when this tool is applicable. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'sessions_continue' or other step-related siblings, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
sessions_breakpointsessions_continuesessions_createsessions_endsessions_statesessions_step_insessions_step_outsessions_step_overEach tool has a clearly distinct purpose within the debug session lifecycle: create, end, state, breakpoint, continue, and three distinct step types. The descriptions specify unique actions like 'step into' vs 'step over', eliminating any ambiguity between tools.
All tools follow a perfect 'sessions_verb' pattern (e.g., sessions_create, sessions_step_over). This consistent naming convention makes the tool set predictable and easy to understand at a glance.
With 8 tools, this server provides a well-scoped set for debugging operations. It covers the essential debug session lifecycle (create, state, end) and core execution control (breakpoint, continue, step variations) without being overwhelming or sparse.
The tool set offers complete coverage for a debug session domain: creation, state monitoring, execution control (breakpoint, continue, step in/out/over), and cleanup. There are no obvious gaps; agents can fully manage debug sessions from start to finish.
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.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kaina3/Debug-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
