MCP server for multi-language debugging – give your AI agents debugging superpowers 🚀
mcp-debugger is a Model Context Protocol (MCP) server that provides debugging tools as structured API calls. It enables AI agents to perform step-through debugging of multiple programming languages using the Debug Adapter Protocol (DAP).
🆕 Version 0.19.0: Java debugging via JDI bridge with launch and attach modes! Plus Go debugging with Delve.
🆕 Version 0.17.0: Rust debugging support! Debug Rust programs with CodeLLDB on Linux/macOS, including Cargo projects, async code, and full variable inspection—plus step commands now return the active source context so agents keep their place automatically.
🔥 Version 0.16.0: JavaScript/Node.js debugging support! Full debugging capabilities with bundled js-debug, TypeScript support, and zero-runtime dependencies via improved npx distribution.
🎬 Demo Video: See the debugger in action!
Recording in progress - This will show an AI agent discovering and fixing the variable swap bug in real-time
Related MCP server: cdp-tools-mcp
🌐 Multi-language support – Clean adapter pattern for any language
🐍 Python debugging via debugpy – Full DAP protocol support
🟨 JavaScript (Node.js) debugging via js-debug – VSCode's proven debugger
🦀 Rust debugging via CodeLLDB – Debug Rust & Cargo projects (Linux/macOS/Windows with GNU toolchain)
🐹 Go debugging via Delve – Full DAP support for Go programs
☕ Java debugging via JDI bridge – Launch and attach modes with JDK 21+
🔷 .NET/C# debugging via netcoredbg – Debug .NET applications with full DAP support
WARNING: On Windows, use the GNU toolchain for full variable inspection. Run
mcp-debugger check-rust-binary <path-to-exe>to verify your build and see Rust Debugging on Windows for detailed guidance. NOTE: The published npm bundle ships the Linux x64 CodeLLDB runtime to stay under registry size limits. On macOS or Windows, point theCODELLDB_PATHenvironment variable at an existing CodeLLDB installation (for example from the VSCode extension) or clone the repo and runpnpm --filter @debugmcp/adapter-rust run build:adapterto vendor your platform binaries locally.
If you're on Windows and want the quickest path to a working GNU toolchain + dlltool configuration, run:
pwsh scripts/setup/windows-rust-debug.ps1The script installs the stable-gnu toolchain (via rustup), sets up dlltool.exe (preferring MSYS2/MinGW when available, falling back to rustup's self-contained copy), builds the bundled Rust examples, and runs the Rust smoke tests by default. Add -SkipTests to opt out of running tests. Add -UpdateUserPath if you want the dlltool path persisted to your user PATH/DLLTOOL variables.
The script will also attempt to provision an MSYS2-based MinGW-w64 toolchain (via winget + pacman) so cargo +stable-gnu has a fully functional dlltool/ld/as stack. If MSYS2 is already installed, it simply reuses it; otherwise it guides you through installing it (or warns so you can install manually).
🧪 Mock adapter for testing – Test without external dependencies
🔌 STDIO and Streamable HTTP transports – Works with any MCP client (legacy SSE transport is deprecated)
📦 Zero-runtime dependencies – Self-contained bundles via esbuild + tsup
⚡ npx ready – Run directly with npx @debugmcp/mcp-debugger - no installation needed
📊 1266+ tests passing – battle-tested end-to-end
🐳 Docker and npm packages – Deploy anywhere
🤖 Built for AI agents – Structured JSON responses for easy parsing
🛡️ Path validation – Prevents crashes from non-existent files
📝 AI-aware line context – Intelligent breakpoint placement with code context
Add to your MCP settings configuration:
{
"mcpServers": {
"mcp-debugger": {
"command": "node",
"args": ["C:/path/to/mcp-debugger/dist/index.js", "stdio", "--log-level", "debug", "--log-file", "C:/path/to/logs/debug-mcp-server.log"],
"disabled": false,
"autoApprove": ["create_debug_session", "set_breakpoint", "get_variables"]
}
}
}For Claude Code users, we provide an automated installation script:
Prerequisite: The Claude CLI must be installed and available on your PATH before running the installation script. See Claude Code documentation for installation instructions.
# Clone the repository
git clone https://github.com/debugmcp/mcp-debugger.git
cd mcp-debugger
# Run the installation script
./scripts/install-claude-mcp.sh
# Verify the connection (use 'claude mcp list' if claude is on your PATH)
claude mcp listImportant: The stdio argument is required to prevent console output from corrupting the JSON-RPC protocol. See CLAUDE.md for detailed setup and troubleshooting.
docker run -v $(pwd):/workspace debugmcp/mcp-debugger:latest⚠️ The Docker image ships Python, JavaScript, Go, Java, and .NET adapters. Rust debugging requires the local, SSE, or packed deployments where the adapter runs next to your toolchain. Note: adapters are loaded dynamically at runtime — only those whose toolchain is installed and detected will be reported as available by
list_supported_languages.
npm install -g @debugmcp/mcp-debugger
mcp-debugger --helpOr use without installation via npx:
npx @debugmcp/mcp-debugger --help📸 Screenshot: MCP Integration in Action
This screenshot will show real-time MCP protocol communication with tool calls and JSON responses flowing between the AI agent and debugger.
mcp-debugger exposes debugging operations as MCP tools that can be called with structured JSON parameters:
// Tool: create_debug_session
// Request:
{
"language": "python", // or "javascript", "rust", "go", "java", "dotnet", or "mock" for testing
"name": "My Debug Session"
}
// Response:
{
"success": true,
"sessionId": "a4d1acc8-84a8-44fe-a13e-28628c5b33c7",
"message": "Created python debug session: My Debug Session"
}📸 Screenshot: Active Debugging Session
This screenshot will show the debugger paused at a breakpoint with the stack trace visible in the left panel, local variables in the right panel, and source code with line highlighting in the center.
Tool | Description | Status |
| Create a new debugging session | ✅ Implemented |
| List all active sessions | ✅ Implemented |
| Show available language adapters | ✅ Implemented |
| Set a breakpoint in a file | ✅ Implemented |
| Start debugging a script | ✅ Implemented |
| Attach debugger to a running process | ✅ Implemented |
| Detach debugger from a process | ✅ Implemented |
| Get the current stack trace | ✅ Implemented |
| List all threads in the debug session | ✅ Implemented |
| Get variable scopes for a frame | ✅ Implemented |
| Get variables in a scope | ✅ Implemented |
| Get local variables in current frame | ✅ Implemented |
| Step over the current line | ✅ Implemented |
| Step into a function | ✅ Implemented |
| Step out of a function | ✅ Implemented |
| Continue running | ✅ Implemented |
| Pause running execution | ✅ Implemented |
| Evaluate expressions in debug context | ✅ Implemented |
| Get source code context | ✅ Implemented |
| Close a session | ✅ Implemented |
| Hot-swap changed Java classes into a running JVM (Java only) | ✅ Implemented |
📸 Screenshot: Multi-Session Debugging
This screenshot will show the debugger managing multiple concurrent debug sessions, demonstrating how AI agents can debug different scripts simultaneously with isolated session management.
Version 0.10.0 introduces a clean adapter pattern that separates language-agnostic core functionality from language-specific implementations:
┌─────────────┐ ┌────────────────┐ ┌──────────────┐ ┌─────────────────┐
│ MCP Client │────▶│ DebugMcpServer │────▶│SessionManager│────▶│ AdapterRegistry │
└─────────────┘ └────────────────┘ └──────────────┘ └─────────────────┘
│ │
▼ ▼
┌──────────────┐ ┌─────────────────┐
│ ProxyManager │◀─────│ Language Adapter│
└──────────────┘ └─────────────────┘
│
┌──────────────┴──────────────────────────────────────────┐
│ │
┌───────────┼───────────┬───────────┬───────────┬───────────┐ │
│ │ │ │ │ │ │
┌─────▼────┐┌─────▼────┐┌─────▼────┐┌─────▼────┐┌─────▼────┐┌─────▼────┐
│Python ││JavaScript││Rust ││Go ││Java ││Dotnet ││Mock │
│Adapter ││Adapter ││Adapter ││Adapter ││Adapter ││Adapter ││Adapter │
└──────────┘└──────────┘└──────────┘└──────────┘└──────────┘└──────────┘└──────���───┘Want to add debugging support for your favorite language? Check out the Adapter Development Guide!
Here's a complete debugging session example:
# buggy_swap.py
def swap_variables(a, b):
a = b # Bug: loses original value of 'a'
b = a # Bug: 'b' gets the new value of 'a'
return a, b// Tool: create_debug_session
// Request:
{
"language": "python",
"name": "Swap Bug Investigation"
}
// Response:
{
"success": true,
"sessionId": "a4d1acc8-84a8-44fe-a13e-28628c5b33c7",
"message": "Created python debug session: Swap Bug Investigation"
}// Tool: set_breakpoint
// Request:
{
"sessionId": "a4d1acc8-84a8-44fe-a13e-28628c5b33c7",
"file": "buggy_swap.py",
"line": 2
}
// Response:
{
"success": true,
"breakpointId": "28e06119-619e-43c0-b029-339cec2615df",
"file": "C:\\path\\to\\buggy_swap.py",
"line": 2,
"verified": false,
"message": "Breakpoint set at C:\\path\\to\\buggy_swap.py:2"
}// Tool: start_debugging
// Request:
{
"sessionId": "a4d1acc8-84a8-44fe-a13e-28628c5b33c7",
"scriptPath": "buggy_swap.py"
}
// Response:
{
"success": true,
"state": "paused",
"message": "Debugging started for buggy_swap.py. Current state: paused",
"data": {
"message": "Debugging started for buggy_swap.py. Current state: paused",
"reason": "breakpoint"
}
}First, get the scopes:
// Tool: get_scopes
// Request:
{
"sessionId": "a4d1acc8-84a8-44fe-a13e-28628c5b33c7",
"frameId": 3
}
// Response:
{
"success": true,
"scopes": [
{
"name": "Locals",
"variablesReference": 5,
"expensive": false,
"presentationHint": "locals",
"source": {}
},
{
"name": "Globals",
"variablesReference": 6,
"expensive": false,
"source": {}
}
]
}Then get the local variables:
// Tool: get_variables
// Request:
{
"sessionId": "a4d1acc8-84a8-44fe-a13e-28628c5b33c7",
"scope": 5
}
// Response:
{
"success": true,
"variables": [
{"name": "a", "value": "10", "type": "int", "variablesReference": 0, "expandable": false},
{"name": "b", "value": "20", "type": "int", "variablesReference": 0, "expandable": false}
],
"count": 2,
"variablesReference": 5
}📸 Screenshot: Variable Inspection Reveals the Bug
This screenshot will show the TUI visualizer after stepping over line 4, where both variables incorrectly show value 20, clearly demonstrating the variable swap bug. The left panel shows the execution state, the center shows the highlighted code, and the right panel displays the incorrect variable values.
📘 Tool Reference – Complete API documentation
🚦 Getting Started Guide – First-time setup
🏗️ Architecture Overview – Multi-language design
🔧 Adapter Development – Add new languages
🔌 Dynamic Loading Architecture – Runtime discovery, lazy loading, caching
🧩 Adapter API Reference – Adapter, factory, loader, and registry contracts
🔄 Migration Guide – Upgrading to v0.15.0 (dynamic loading)
🐍 Python Debugging Guide – Python-specific features
🟨 JavaScript Debugging Guide – JavaScript/TypeScript features
🐹 Go Debugging Guide – Go debugging with Delve
☕ Java Debugging Guide – Java debugging with JDI bridge
Rust Debugging on Windows - Toolchain requirements and troubleshooting
🔧 Troubleshooting – Common issues & solutions
We welcome contributions! See CONTRIBUTING.md for guidelines.
# Development setup
git clone https://github.com/debugmcp/mcp-debugger.git
cd mcp-debugger
# Install dependencies and vendor debug adapters
pnpm install
# All debug adapters (JavaScript js-debug, Rust CodeLLDB) are automatically downloaded
# Build the project
pnpm build
# Run tests
pnpm test
# Check adapter vendoring status
pnpm vendor:status
# Force re-vendor all adapters (if needed)
pnpm vendor:forceThe project automatically vendors debug adapters during pnpm install:
JavaScript: Downloads Microsoft's js-debug from GitHub releases
Rust: Downloads CodeLLDB binaries for the current platform
CI Environment: Set SKIP_ADAPTER_VENDOR=true to skip vendoring
To manually manage adapters:
# Check current vendoring status
pnpm vendor:status
# Re-vendor all adapters
pnpm vendor
# Clean and re-vendor (force)
pnpm vendor:force
# Clean vendor directories only
pnpm clean:vendorWe use Act to run GitHub Actions workflows locally:
# Build the Docker image first
docker build -t mcp-debugger:local .
# Run tests with Act (use WSL2 on Windows)
act -j build-and-test --matrix os:ubuntu-latestSee tests/README.md for detailed testing instructions.
✅ Production Ready: v0.19.0 with six language adapters and polished multi-language distribution
✅ Clean architecture with adapter pattern
✅ JavaScript/Node.js: Full debugging loop via js-debug
✅ Go: Full debugging support via Delve DAP
✅ Java: Launch and attach modes via JDI bridge
🦀 Rust: Full support on Linux/macOS/Windows (Windows requires GNU toolchain; MSVC is not supported by CodeLLDB)
📈 Active Development: Regular updates and improvements
MIT License - see LICENSE for details.
@swinyx — Go adapter (Delve)
@roofpig95008 — Java adapter (JDI bridge)
Built with:
Model Context Protocol by Anthropic
Debug Adapter Protocol by Microsoft
debugpy for Python debugging
Give your AI the power to debug like a developer – in any language! 🎯
Attach to a running process for debugging
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Debug session ID | |
| port | No | Debug port to attach to | |
| host | No | Host to attach to (default: localhost) | |
| processId | No | Process ID (for local attach, language-specific) | |
| timeout | No | Connection timeout in milliseconds (default: 30000) | |
| sourcePaths | No | Source paths for code mapping | |
| stopOnEntry | No | Stop on entry after attaching | |
| justMyCode | No | Only debug user code (skip library code) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'attach to a running process' without disclosing side effects (e.g., does it pause execution? What happens if process not found? Are permissions needed?). Parameters like 'stopOnEntry' hint at behavior but are not explained in description. Critical behavioral traits are missing.
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 sentence with no wasted words. However, given the tool's complexity (8 parameters), it is slightly underspecified but still concise.
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?
The description omits placement in the debugging workflow. It does not mention that a debug session is required (sessionId is required), nor how this tool relates to siblings like 'create_debug_session' or 'start_debugging'. For a tool with many parameters and a specific role, more contextual information is needed.
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 baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions. It does not explain relationships between parameters (e.g., sessionId vs processId) or when host/port are needed.
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: 'Attach to a running process for debugging'. It uses a specific verb ('attach') and resource ('running process'), and distinguishes well from sibling tools like 'create_debug_session' (creating vs attaching) and 'detach_from_process' (opposite).
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 (e.g., 'create_debug_session', 'start_debugging'). It lacks context on prerequisites, such as requiring an existing debug session, and does not mention when to choose attach over other debugging tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close a debugging session
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It states the action but fails to mention side effects, error conditions, or any impact on the session state.
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 very concise (one sentence, four words) and front-loaded. However, it may be too terse for completeness, but conciseness itself is a strength.
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 simple interface (1 required param, no output schema), the description lacks enough context to be fully self-contained. With many sibling tools, additional usage context would be helpful.
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 single parameter 'sessionId' has 0% schema description coverage, and the tool description adds no explanation about its meaning, source, or format. The schema only specifies type and requiredness.
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 (close) and the resource (a debugging session), directly distinguishing it from sibling tools like create_debug_session or list_debug_sessions.
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, prerequisites (e.g., session must exist), or alternatives. The agent is given no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Continue execution
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. However, it simply repeats the tool name without disclosing behavioral traits such as whether execution resumes until next breakpoint or program end, or any side effects.
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 extremely short, but this is under-specification rather than conciseness. It fails to provide essential information and does not earn its place.
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 debugging tools, numerous siblings, no annotations, no output schema, and a single required parameter, the description is completely inadequate. It leaves major 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?
The only parameter 'sessionId' is undocumented in both schema (0% coverage) and description. The description adds no meaning beyond the schema, leaving the agent to guess its purpose.
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 'Continue execution' is a tautology of the tool name and provides no specific verb or resource. It fails to distinguish from siblings like step_over or step_into, leaving the agent uncertain about what 'continue' means.
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 on when to use this tool versus alternatives. The sibling list includes many stepping commands with no differentiation, and the description offers no context about appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new debugging session. Provide host and port to attach to a running process; omit them for launch mode
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | Programming language for debugging | |
| name | No | Optional session name | |
| executablePath | No | Path to language executable (optional, will auto-detect if not provided) | |
| host | No | Host to attach to for remote debugging (optional, triggers attach mode) | |
| port | No | Debug port to attach to for remote debugging (optional, triggers attach mode) | |
| timeout | No | Connection timeout in milliseconds for attach mode (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions creation and mode choice, lacking information on side effects, permissions, session limits, or error 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?
Two sentences: front-loaded with main purpose, then mode explanation. Each sentence is essential and concise.
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?
No output schema, yet description omits return value, success/failure indications, and error scenarios. For a tool with 6 parameters, more behavioral context is needed.
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?
With 100% schema coverage, baseline is 3. The description adds value by explaining the dual role of host/port parameters and the omission trigger for launch mode, going 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 clearly states that it creates a debugging session and distinguishes between attach mode (with host/port) and launch mode (omit host/port). This differentiates it from sibling tools like attach_to_process and start_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?
The description provides clear guidance on when to use attach vs launch mode, but does not explicitly compare with alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detach from the debugged process without terminating it
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Debug session ID | |
| terminateProcess | No | Whether to terminate the process on detach (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States the key behavioral trait (no termination) but does not disclose other effects (e.g., session validity, resource cleanup). Adequate but not exhaustive.
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?
Single sentence, no redundant words, front-loaded with action and key constraint. Highly concise.
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?
Simple tool with 2 params and no output schema. Description covers core action but lacks pre/post-conditions (e.g., must be attached) and return value. Acceptable for a straightforward operation.
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%; both parameters documented. Description adds minimal new meaning beyond confirming the 'without terminating it' behavior aligns with default of terminateProcess. Baseline score 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?
Description uses a specific verb ('Detach') and resource ('debugged process') with a clarifying condition ('without terminating it'). Clearly distinguishes from sibling tools like terminate or close.
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 explicit guidance on when to use versus alternatives like close_debug_session or terminate. The condition 'without terminating it' is present but not framed as a decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate expression in the current debug context. Expressions can read and modify program state
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ||
| expression | Yes | ||
| frameId | No | Optional stack frame ID for evaluation context. Must be a frame ID from a get_stack_trace response. If not provided, uses the current (top) frame automatically |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that expressions can modify state, but does not mention failure modes, return values, or side effects beyond modification (e.g., if expression crashes).
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?
Two concise sentences with no filler. Every word adds value: 'Evaluate expression in the current debug context' sets purpose, and 'Expressions can read and modify program state' adds behavioral context efficiently.
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 expression evaluation and the absence of an output schema, the description lacks details on how results are returned, error handling, or limitations. With 20 sibling tools, more context would help differentiate 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?
Schema description coverage is only 33% (only frameId has a description). The tool description does not compensate by explaining sessionId or expression parameters, leaving their meaning and constraints unaddressed.
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 verb 'Evaluate' and the resource 'expression in the current debug context'. It also notes that expressions can read and modify program state, which distinguishes it from read-only sibling tools like get_variables or get_local_variables.
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 for both inspection and modification of program state, but does not explicitly compare to sibling tools or provide guidance on when to use evaluate_expression over alternatives like get_variables or set_variable analogs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get local variables for the current stack frame. This is a convenience tool that returns just the local variables without needing to traverse stack->scopes->variables manually
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ||
| includeSpecial | No | Include special/internal variables like this, __proto__, __builtins__, etc. Default: false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently describes the tool as a convenience wrapper that returns only local variables, which is sufficient for a simple retrieval tool without side effects.
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?
A single, well-structured sentence that front-loads the core purpose and adds explanatory context without extraneous 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 straightforward retrieval tool with no output schema, the description adequately explains what it returns and why it is useful, covering all necessary 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 50%, with only includeSpecial having a description. The tool description does not add additional meaning for sessionId or the parameters beyond what the schema provides.
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 retrieves local variables for the current stack frame, distinguishing it from get_variables by noting it avoids manual traversal of stack, scopes, and variables.
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 indicates this is a convenience tool for fetching local variables without manual traversal, implicitly suggesting when not to use it (e.g., when broader scope traversal is needed). However, it could more explicitly specify alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get scopes for a stack frame
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ||
| frameId | Yes | The ID of the stack frame from a stackTrace response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior, but it only states 'Get scopes'. It does not mention side effects, authentication needs, rate limits, or what the return value represents. The tool's read-only nature is implied but not confirmed.
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 very short (one sentence) and concise, but it is too brief to be informative. It is not verbose, but the minimalism comes at the cost of completeness.
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 no output schema and no annotations, the description is insufficient. It does not explain prerequisites (e.g., having a stack trace), return values, or how it differs from similar tools. The complexity of the debugging context demands more detail.
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 50% with only frameId having a description. The tool description adds no extra meaning to the parameters, and sessionId remains undocumented. The description does not compensate for the coverage gap.
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 (Get) and resource (scopes) with a specific context (for a stack frame), distinguishing it from sibling tools like get_stack_trace or get_variables. However, it does not explicitly differentiate itself from siblings.
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 like get_local_variables or get_variables. The description lacks any context about prerequisites or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get source context around a specific line in a file
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ||
| file | Yes | Path to the source file. Use absolute paths or paths relative to your current working directory | |
| line | Yes | Line number to get context for | |
| linesContext | No | Number of lines before and after to include (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must bear the full burden of behavioral disclosure. It does not state whether the tool is read-only, what happens on invalid file/line, or what errors occur. The behavior is minimally implied but not explicitly described.
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?
A single sentence that is front-loaded and clear. It is concise but at the expense of missing important details like output format and usage context.
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?
No output schema exists, yet the description does not mention what the tool returns (e.g., source lines, snippet). It also does not explain how it fits with sibling debug tools or any session requirements beyond the required sessionId parameter.
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 75%, so baseline is 3. The tool description adds no additional meaning beyond the schema; it does not elaborate on sessionId or clarify parameter interactions. However, the schema already provides good descriptions for file, line, and linesContext.
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 'Get source context around a specific line in a file' clearly states the action (get) and the resource (source context) with specificity. It distinguishes from sibling debug tools, which focus on session management, breakpoints, stepping, etc., by focusing on source code retrieval.
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 like get_local_variables or evaluate_expression. There is no mention of prerequisites (e.g., active debug session) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stack trace
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ||
| includeInternals | No | Include internal/framework frames (e.g., Node.js internals). Default: false for cleaner output. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not state that the tool is read-only, idempotent, or describe any side effects. While reading a stack trace is inherently read-only, this is not explicitly conveyed.
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 phrase lacking proper sentence structure. It is concise but at the expense of clarity and utility. Every word should add value, but this description under-specifies the tool's 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?
Given the complexity of debugging contexts and the presence of many sibling tools, the description is severely incomplete. It fails to mention output format, relation to other tools, or any contextual details necessary for correct 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?
Schema description coverage is only 50% (includeInternals has a description, but sessionId does not). The tool description adds no parameter details, failing to compensate for the missing schema descriptions. The agent gains no additional semantic understanding 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?
Description is a tautology: 'Get stack trace' merely restates the tool name without specifying what kind of stack trace (current thread? all threads?) or any additional context. It provides no differentiation from sibling tools like get_local_variables or get_scopes.
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 usage guidance whatsoever. There is no indication of when to use this tool over alternatives such as get_local_variables or evaluate_expression, nor any prerequisites or caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get variables (scope is variablesReference: number)
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ||
| scope | Yes | The variablesReference number from a StackFrame or Variable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, side effects, required permissions, or error conditions. The description is too minimal to inform the agent about 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 single sentence is short but under-specified. It does not earn its place by providing useful information beyond the name. True conciseness would pack more meaning into few words.
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 lack of annotations, output schema, and minimal description, the tool definition is incomplete. It fails to explain return values, required context (e.g., active session), or usage constraints.
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 50% (scope has description). The description adds a redundant note about 'variablesReference: number' for scope, but no additional meaning for sessionId. The description does not compensate for the missing parameter documentation.
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 states 'Get variables', which is a verb+resource, but it is vague and does not clarify what 'variables' refers to in the debug context. The parenthetical note is confusing and fails to distinguish this tool from siblings like get_local_variables or get_scopes.
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 such as get_local_variables or evaluate_expression. The description does not mention prerequisites like an active debug session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active debugging sessions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'list all active', lacking details like what 'active' means, whether sessions are scoped, or if pagination exists. Minimal behavioral disclosure.
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?
One sentence, no filler, appropriately concise for a simple list operation. Could be slightly more informative without becoming verbose.
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 output schema, the description should hint at return values (e.g., session IDs, names). It doesn't, leaving ambiguity. Adequate for a simple tool but lacks 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?
The tool has zero parameters, so the schema coverage is 100%. The description adds no parameter info because none are needed, meeting the baseline for 0-parameter tools.
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 'List all active debugging sessions' clearly states the verb (list) and resource (active debugging sessions), distinguishing it from sibling tools like 'create_debug_session' or 'close_debug_session'.
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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives, such as when to list sessions versus attach to or create one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all supported debugging languages with metadata
| 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 the full burden. It only states the tool lists languages but discloses nothing about side effects (e.g., it is read-only, non-destructive), data freshness, or performance. For a simple list, this is a notable 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 sentence, which is maximally concise. It is front-loaded with the verb 'List' to immediately convey the action. Every word earns its place, with no filler or redundancy.
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 simplicity (no parameters, no output schema), the description is minimally adequate. However, it lacks details on the return format or what 'metadata' includes, which would help an agent understand the output. It is complete enough for basic usage but not rich.
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 zero parameters and schema coverage is 100% (empty). Per guidelines, baseline for 0 params is 4. The description does not need to add parameter information since there are none, so this score 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 'List all supported debugging languages with metadata' clearly states the action (list), the resource (supported debugging languages), and that metadata is included. It distinguishes from sibling tools, which are all action-oriented debugging operations, making the 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 no guidance on when to use this tool versus alternatives. With 20 sibling tools like 'start_debugging' or 'create_debug_session', it would be helpful to mention that this tool is useful before initiating debugging sessions to discover available languages, but no such context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all threads in the debugged process
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only listing operation. With no annotations, it provides minimal behavioral insight but does not contradict any known 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 a single concise sentence with no unnecessary words. It efficiently conveys the tool's 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?
While the description is adequate for a simple list operation, it lacks information about the output format (no output schema) and does not elaborate on what a 'thread' means in this context, which could be helpful given the absence of annotations.
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 single parameter 'sessionId' is not described beyond the schema. Schema description coverage is 0%, and the description adds no meaning about its purpose or format.
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 verb 'list' and the resource 'all threads in the debugged process'. It is specific and distinguishable from sibling tools like set_breakpoint or step_into.
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 like get_stack_trace or get_variables. There is no mention of context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause a running program
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ||
| threadId | No | Thread ID to pause. If omitted or 0, pauses all threads. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states the action without detailing behavioral traits. It does not clarify if pausing is temporary, whether it can be resumed, or if there are side effects.
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 sentence, which is concise, but it sacrifices necessary detail. It is adequate but could be more informative without being verbose.
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 output schema and no annotations, the description fails to cover important context like return values, error states, or required conditions (e.g., active session).
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 50% (threadId has a description, sessionId does not). The description adds no extra meaning, failing to explain the role of sessionId or the effect of omitting threadId.
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 'Pause a running program' clearly states the action on a resource. It aligns with the debugging context, distinguishing it from sibling tools like 'continue_execution' or 'step_into'.
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 on when to use this tool versus alternatives, such as stepping or continuing. No mention of prerequisites like having an active debug session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hot-swap changed Java classes into a running JVM. Scans a classes directory for .class files modified after sinceTimestamp, matches them against loaded classes in the target JVM, and redefines them using JDI. Returns which classes were redefined and the newest file timestamp (pass as sinceTimestamp on next call for incremental updates). Only works with Java debug sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ||
| classesDir | Yes | Absolute path to compiled classes directory (e.g. build/classes/java/main/) | |
| sinceTimestamp | No | Unix timestamp (ms). Only redefine .class files modified after this time. 0 or omitted = all files. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the hot-swap mechanism, file scanning based on timestamps, matching against loaded classes, and the return format. It also describes the incremental update pattern. It does not mention limitations like redefinition failures or performance impacts, but the disclosure is solid.
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 two sentences, front-loaded with the main purpose. Every sentence adds necessary information without redundancy. It is highly efficient.
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 has three parameters, no output schema, and no annotations, the description explains the process, return value, and usage pattern adequately. It mentions the scope (Java debug sessions) and how to use incrementally. It does not cover error conditions, but for an agent deciding whether to call this tool, it provides sufficient 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 67% (two of three parameters have descriptions). The tool description adds the incremental update pattern for sinceTimestamp and gives an example for classesDir. However, it does not add substantial meaning for sessionId beyond what the schema implies. Baseline is 3 due to moderate schema coverage, and the description provides marginal extra value.
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: hot-swap changed Java classes into a running JVM. It specifies the action (redefine), resource (Java classes), and mechanism (scan directories, match against loaded classes). This clearly distinguishes it from sibling tools which are debug session management and stepping operations.
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 states 'Only works with Java debug sessions,' providing clear context. It does not explicitly give when-not-to-use or name alternatives, but the sibling tools list makes the differentiation obvious. Some guidance on prerequisites could improve this score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a breakpoint. Setting breakpoints on non-executable lines (structural, declarative) may lead to unexpected behavior
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ||
| file | Yes | Path to the source file or Java FQCN. For Java, passing a fully-qualified class name (e.g. "com.example.MyClass" or "com.example.Outer$Inner") is preferred — it works reliably with all classloaders including custom classloaders. Alternatively, use absolute file paths. | |
| line | Yes | Line number where to set breakpoint. Executable statements (assignments, function calls, conditionals, returns) work best. Structural lines (function/class definitions), declarative lines (imports), or non-executable lines (comments, blank lines) may cause unexpected stepping behavior | |
| condition | No | ||
| suspendPolicy | No | Suspend policy when breakpoint is hit: "all" suspends all threads (default), "thread" only suspends the event thread. Only supported by the Java/JDI adapter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden for behavioral disclosure. It warns about unexpected behavior on certain lines, which adds transparency. However, it does not detail other behaviors like what happens when a breakpoint is hit or whether it can be removed.
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 sentence that is front-loaded with the purpose. It contains no extraneous words and is highly concise.
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 debugger tool with 5 parameters and no annotations, the description is insufficient. It does not explain return values (there is no output schema), how to use the 'condition' parameter, or the effect of 'suspendPolicy'. The schema covers some parameter descriptions, but the description itself lacks 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 coverage is 60%, which is below the 80% threshold. The description does not add any meaning beyond the schema for the 5 parameters (e.g., it doesn't explain 'sessionId', 'condition', or 'suspendPolicy' in the description text). The schema itself provides some descriptions for 'file' and 'line', but the description fails to compensate for the 40% undocumented 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 the action ('Set a breakpoint') and the resource (a breakpoint). It is distinct from sibling tools like 'step_into' or 'continue_execution', as setting a breakpoint is a different operation.
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 warning about setting breakpoints on non-executable lines, which provides usage guidance. However, it does not offer broader context on when to use this tool versus alternatives (e.g., when to set a breakpoint vs. stepping through code).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start debugging a script
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ||
| scriptPath | Yes | Path to the script to debug. Use absolute paths or paths relative to your current working directory | |
| args | No | ||
| dapLaunchArgs | No | ||
| dryRunSpawn | No | ||
| adapterLaunchConfig | No | Optional adapter-specific launch configuration overrides |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'start debugging' but does not disclose side effects (e.g., process spawning, resource allocation), authorization requirements, or whether the tool is idempotent. The minimal description leaves behavioral traits opaque.
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 sentence, which is concise but not optimally structured. It lacks front-loading of critical information or any hierarchical formatting. While not verbose, it could be expanded without losing conciseness to include more actionable details.
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?
The tool has 6 parameters, nested objects, and many sibling tools. Without annotations or an output schema, the description should provide more context on usage flow, prerequisites (e.g., sessionId must refer to an existing debug session), and expected outcomes. The current description is insufficient for an agent to correctly invoke the tool.
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 33%, with only 'scriptPath' and 'adapterLaunchConfig' having descriptions. The tool description itself adds nothing about the parameters. Key parameters like 'sessionId', 'args', 'dapLaunchArgs', and 'dryRunSpawn' remain unexplained, and the description does not compensate for the low 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 'Start debugging a script' clearly states the verb (start) and resource (debugging a script), but does not differentiate from sibling tools like 'create_debug_session' or 'attach_to_process'. It is specific to script-based debugging but lacks context on how it differs from other debug initialization 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. For example, it does not mention that a session must be created first via 'create_debug_session', nor does it indicate whether this tool is for single-file scripts or complex projects. No exclusion criteria or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step into
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral insight beyond the name. An agent cannot infer side effects, required permissions, or safety profile from this description alone.
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 extremely short but lacks necessary information, which is under-specification rather than effective conciseness. It does not earn its place as a helpful description.
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 sibling tools (multiple debugger actions), this description is completely inadequate. Without output schema or annotations, it fails to provide essential context for correct tool selection and invocation.
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 0%, and the description does not explain the 'sessionId' parameter's purpose, format, or constraints. The agent has no information beyond the parameter name and type.
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 is a single word 'Step into' that merely restates the name, providing no specificity on what resource or action is involved. It does not distinguish this tool from siblings like step_over or step_out.
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 on when to use this tool versus alternatives such as step_over, step_out, or continue_execution. Lacks any context about prerequisites or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step out
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but says nothing about what the tool does (e.g., resumes execution until the current function returns) or its side effects (e.g., stopping at the caller line). No behavioral disclosure.
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?
While very short, the description is under-specified rather than concise. It fails to convey essential information, making it insufficiently informative.
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 debugging tools (21 siblings) and no output schema or annotations, the description is completely inadequate. It provides no details about return values, prerequisites, or the effect of the action.
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 0% and the description does not explain the 'sessionId' parameter. No indication of what it represents or how to obtain it, leaving the agent with no guidance.
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 'Step out' is a tautology of the tool name. It does not clarify that this is a debugger action to step out of the current function, especially confusing given siblings like 'step_into' and 'step_over'.
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 guidelines are provided about when to use step_out versus similar tools like step_over or step_into. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step over
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as state changes, side effects, or required session prerequisites. The agent gets no information beyond the tool name.
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 extremely terse (two words) but sacrifices clarity for brevity. It is not front-loaded with useful information and does not earn its place.
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 debugger step command, the description is completely inadequate. It omits requirements (active session), behavior (execution advance), and output, given no output schema or annotations.
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 single parameter 'sessionId' is not described in the description. With 0% schema coverage, the description adds no meaning to the parameter, leaving the agent without guidance.
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 is a tautology, restating the tool name 'step over' without specifying the action on a resource. It does not distinguish from sibling tools like step_into or step_out.
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 such as step_into or step_out. The description lacks any context for appropriate usage.
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.
v0.20.0attach_to_processcreate_debug_session4 fields changedInput schema / properties / hostAdded value: +{
+ "description": "Host to attach to for remote debugging (optional, triggers attach mode)",
+ "type": "string"
+}Input schema / properties / language / enumPrevious value: -[
- "mock",
- "python",
- "javascript",
- "rust"
-]New value: +[
+ "mock",
+ "python",
+ "javascript",
+ "rust",
+ "go",
+ "java",
+ "dotnet"
+]Input schema / properties / portAdded value: +{
+ "description": "Debug port to attach to for remote debugging (optional, triggers attach mode)",
+ "type": "number"
+}Input schema / properties / timeoutAdded value: +{
+ "description": "Connection timeout in milliseconds for attach mode (default: 30000)",
+ "type": "number"
+}detach_from_processlist_threadspause_execution1 field changedInput schema / properties / threadIdAdded value: +{
+ "description": "Thread ID to pause. If omitted or 0, pauses all threads.",
+ "type": "number"
+}redefine_classesset_breakpoint2 fields changedInput schema / properties / file / descriptionPrevious value: -"Path to the source file. Use absolute paths or paths relative to your current working directory"New value: +"Path to the source file or Java FQCN. For Java, passing a fully-qualified class name (e.g. \"com.example.MyClass\" or \"com.example.Outer$Inner\") is preferred — it works reliably with all classloaders including custom classloaders. Alternatively, use absolute file paths."Input schema / properties / suspendPolicyAdded value: +{
+ "description": "Suspend policy when breakpoint is hit: \"all\" suspends all threads (default), \"thread\" only suspends the event thread. Only supported by the Java/JDI adapter.",
+ "enum": [
+ "all",
+ "thread"
+ ],
+ "type": "string"
+}close_debug_sessioncontinue_executioncreate_debug_sessionevaluate_expressionget_local_variablesget_scopesget_source_contextget_stack_traceget_variableslist_debug_sessionslist_supported_languagespause_executionset_breakpointstart_debuggingstep_intostep_outstep_overEach tool has a clearly distinct purpose, covering session management, execution control, variable inspection, breakpoints, and more. The only potential overlap (get_local_variables vs get_variables/get_scopes) is clarified in the descriptions.
All tool names follow a consistent verb_noun pattern with underscores (e.g., attach_to_process, create_debug_session). Even though a few are verb-only (step_into, step_out), they are standard debugging terms and the pattern remains predictable.
21 tools is well-scoped for a debugging server, covering essential operations without being overwhelming. The count fits within the typical 3-15 range (slightly above but still appropriate).
The tool set covers most debugging workflows: session lifecycle, execution control, variable inspection, stack trace, threads, expression evaluation, source context, and hot-swap for Java. However, explicit tools for managing breakpoints (list, remove) are missing, which is a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent Replay Debugger MCP — record every agent step + deterministic replay. Step-debugger for
Live browser debugging for AI assistants — DOM, console, network via MCP.
Shared debugging memory for AI coding agents
Production-readiness for your AI coding agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/debugmcp/mcp-debugger'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
