The MCP Debugger is a multi-language debugging server that enables AI agents to perform step-through debugging through the Debug Adapter Protocol (DAP). It provides structured API calls with JSON responses for debugging Python, JavaScript/Node.js, Rust, and Go, with a mock adapter for testing.
Core Capabilities:
Session Management: Create, list, and close independent debugging sessions for different languages and projects
Breakpoint Control: Set breakpoints at specific file paths and line numbers with support for conditional breakpoints and AI-aware intelligent placement
Execution Control: Start debugging scripts with custom arguments and adapter-specific launch configurations, then step over/into/out, continue execution, or pause (pause currently not implemented)
State Inspection: Retrieve stack traces with optional filtering of internal frames, examine variable scopes (Locals, Globals, etc.) for any frame, and access variables using variablesReference numbers or quickly get local variables for the current frame
Expression Evaluation: Evaluate arbitrary expressions in the debug context to read or modify program state (currently defined but not implemented)
Source Context: Retrieve code snippets around specific lines for better debugging visibility
Language Discovery: List all supported debugging languages with their metadata
Key Features:
Auto-detection of language executables (debugpy for Python, js-debug for Node.js, CodeLLDB for Rust) with optional manual path specification
Handles both absolute and relative file paths with validation to prevent crashes
Optional filtering of special variables and internal stack frames for cleaner output
Clean adapter architecture supporting dynamic loading and future language support (Ruby, C/C++)
Flexible deployment via npm, npx (zero-runtime dependencies), or Docker with STDIO and SSE transport modes
Enables step-through debugging for JavaScript applications with tools for managing breakpoints, stack traces, and variable scopes.
Supports debugging of Node.js applications, providing tools to control execution and inspect program state through the Debug Adapter Protocol.
Provides debugging capabilities for Python code, including setting breakpoints, inspecting variables, and stepping through execution using debugpy.
Supports debugging Rust programs and Cargo projects, enabling variable inspection and source context tracking via CodeLLDB.
Provides debugging support for TypeScript projects, allowing for interactive code execution and inspection within the MCP environment.
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., "@MCP Debugger debug this Python script and show me the variables at line 15"
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 headless, agentic debugger over MCP — let your AI agents debug running programs in eight languages.
mcp-debugger is a Model Context Protocol (MCP) server that exposes step-through debugging as structured tool calls. It lets AI agents set breakpoints, inspect variables, evaluate expressions, and step through running programs across eight languages — driving real language debuggers through the Debug Adapter Protocol (DAP).
No IDE required. mcp-debugger runs anywhere Node.js runs: CI runners, Docker containers, Kubernetes pods, SSH boxes, and the sandboxes that cloud coding agents live in. It's the debugger for where IDEs can't go.
Microsoft's DebugMCP exposes VS Code's debugger over MCP and is a good choice when your agent works inside a running VS Code. The two projects make different structural trade-offs:
mcp-debugger | microsoft/DebugMCP | |
Runs headless (CI, containers, k8s, cloud agents) | ✅ standalone Node process | ❌ requires a running VS Code |
Transports | stdio + Streamable HTTP | Streamable HTTP (localhost) |
Distribution | npx, npm, Docker image | VS Code Marketplace extension |
Remote attach without an IDE | ✅ debugpy / rdbg / JDWP, incl. pods via port-forward | ❌ |
Per-session process isolation | ✅ one proxy process per session | shares the VS Code instance |
Java hot-swap ( | ✅ | ❌ |
Debuggee output as subscribable MCP resource | ✅ | ❌ |
In-IDE debugging UX alongside the agent | ✅ read-only IDE mirror ( | ✅ native |
Logpoints without pausing (prod-safe value watching) | ✅ via VS Code | |
Content/function-addressed breakpoints ( | ✅ agent-native addressing that survives edits | — |
Secret redaction on by default | ✅ variable/evaluate/output masking + least-privilege mode | — |
Kubernetes ephemeral debug sidecar (native attach-by-PID) | ❌ | |
C/C++ | ✅ via CodeLLDB (launch + attach-by-PID) | ✅ via VS Code extensions |
PHP | ❌ | ✅ via VS Code extensions |
Languages | Python, JS/TS, Ruby, Rust, Go, Java, .NET, C/C++ | Python, JS/TS, Ruby, Rust, Go, Java, .NET, C/C++, PHP |
If your agent runs in a terminal, a pipeline, or a cloud sandbox — or needs to attach to a process on another machine — you want mcp-debugger.
🆕 v0.24.0 — C/C++ debugging lands (CodeLLDB: prebuilt binaries, auto-compiled single sources, attach by PID), alongside statement/function-addressed breakpoints, logpoints,
restart_debugging, breakpoint management tools, bufferedget_output, break-on-uncaught-exceptions by default, a read-only IDE mirror (expose_session), default-on secret redaction, and a multi-language Docker image (Python, JS, Java, Rust, C/C++ native; Ruby attach). See the CHANGELOG for the full release history.
Related MCP server: cdp-tools-mcp
🌐 Multi-language support – Clean adapter pattern for any language
🐍 Python debugging via debugpy – Full DAP protocol support
💎 Ruby debugging via rdbg – Launch and attach workflows, including remote attach to containers and Kubernetes pods
🟨 JavaScript (Node.js) debugging via js-debug – VSCode's proven debugger
🦀 Rust debugging via CodeLLDB – Debug Rust & Cargo projects (Linux/macOS; Windows needs the GNU toolchain — see Rust on Windows)
🐹 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
⚙️ C/C++ debugging via CodeLLDB – Launch prebuilt binaries or lone source files (auto-compiled), attach by PID; core dumps and gdbserver/rr targets via config pass-through
🧪 Mock adapter for testing – Test without external dependencies
🛰️ Out-of-IDE & remote attach – Attach over host/port to a process on another machine or inside a container (Python via debugpy, Ruby via rdbg, JavaScript via the V8 inspector, Java via JDWP) with source-path mapping, or by PID for native code (C/C++). Python and Ruby attach direct-connect — the debug engine already runs inside the target, so no local Python or Ruby is needed; JavaScript, Java, .NET and C/C++ spawn a local adapter instead; of those, only Java (a JDK) and .NET (netcoredbg) need a toolchain you install, since the JavaScript and C/C++ debug engines ship with the package. list_supported_languages reports per-mode availability with reasons
🎯 Breakpoints that survive edits – Address by content (statement: "total = sum(prices)"), by symbol (function: "main"), or assert line content with expectedContent; anchors re-resolve across restart_debugging and weak matches warn loudly
🪵 Logpoints – set_breakpoint with logMessage: "x={x}" streams interpolated values into get_output without pausing — prod-safe value watching on hot paths
🧰 Full breakpoint lifecycle – list_breakpoints / remove_breakpoint / clear_breakpoints work live mid-run; restart_debugging relaunches with the same config and re-applies everything in one call
📡 Buffered program output – get_output returns debuggee stdout/stderr with a cursor, and each session exposes its transcript as a subscribable MCP resource
💥 Crash-state debugging by default – Launch sessions pause on uncaught exceptions with stack and locals live (breakOnExceptions; exception class/message surfaced via lastStop)
🪞 Read-only IDE mirror – expose_session opens a loopback, token-gated DAP endpoint so a human's IDE can inspect the agent's live session without taking control
☸️ Kubernetes debugging – port-forward attach for interpreted runtimes, kubectl debug --target + attach-by-PID for native processes (recipe, turnkey manifests)
🔌 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
🐳 Docker and npm packages – Deploy anywhere
🤖 Built for AI agents – Structured JSON responses for easy parsing
🔒 Secret redaction on by default – Credential-shaped values (API keys, tokens, private keys) are masked as labeled placeholders in variable, evaluate, and output results before they reach the agent (details; opt out with DEBUG_MCP_NO_REDACT=1)
🛡️ Path validation – Prevents crashes from non-existent files
📝 AI-aware line context – Intelligent breakpoint placement with code context
✅ Comprehensive test suite – unit, integration, and end-to-end coverage across every adapter (CI status)
Tools tell an agent what it can do; a skill teaches it how to debug well. This repo ships an agent skill covering the session golden path, root-cause discipline (bisection over line-by-line stepping), attach/remote recipes, and per-language quirks:
# Claude Code (user-level)
cp -r skills/debugging ~/.claude/skills/mcp-debugger
# Cross-agent directories (Copilot CLI and friends)
cp -r skills/debugging ~/.agents/skills/mcp-debuggerThe server also serves condensed guidance in-band: MCP instructions on connect, plus a debugging-workflow prompt any MCP client can request. See skills/debugging/README.md for details.
Auto-debug failing CI tests – a composite GitHub Action that launches mcp-debugger + an agent on a test failure and posts the root-cause analysis
Sick pod walkthrough – attach to a misbehaving Python service in Kubernetes via port-forward (tutorial)
Native sick pod – same story for compiled code: ephemeral debug sidecar + attach-by-PID, no in-process agent required
Requirements: Node.js 22+ for the server. Each language you debug also needs its own toolchain installed (Python + debugpy, Ruby + the
debuggem /rdbg, Node.js, Go + Delve, JDK 21+, .NET SDK, the Rust toolchain, or a C/C++ compiler — g++/clang++, only needed for source-file launch). Not sure what's installed? Runnpx @debugmcp/mcp-debugger doctorfor a per-adapter toolchain report.CodeLLDB platform note (npx/npm installs): the CodeLLDB debug engine ships as per-platform optional dependencies (
@debugmcp/codelldb-win32-x64,-darwin-x64,-darwin-arm64,-linux-x64,-linux-arm64) — npm installs exactly the one matching your platform, so Rust and C/C++ debugging work out of the box everywhere npm serves. If you install with--omit=optional, setCODELLDB_PATHto a CodeLLDB release binary instead, or use the Docker image.
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"]
}
}
}Register the published stdio server with the Codex CLI:
codex mcp add mcp-debugger -- npx -y @debugmcp/mcp-debugger stdio
codex mcp listCodex stores this entry in ~/.codex/config.toml. The ChatGPT desktop app, Codex CLI,
and Codex IDE extension share that configuration when they run on the same Codex host.
Restart the active desktop client or IDE extension (or start a new CLI session), then use
/mcp to confirm that mcp-debugger is connected. See the official
Codex MCP documentation for configuration and
troubleshooting details.
Developing mcp-debugger itself? Use the restartable source dev proxy instead of the published package.
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 -i --rm -v $(pwd):/workspace debugmcp/mcp-debugger:latestThe Docker image debugs Python, JavaScript, Java, Rust, and C/C++ natively (toolchains + a shared vendored CodeLLDB are included), plus the mock adapter. Ruby is attach-only in the image (the adapter ships without a Ruby runtime — attach to any
rdbg --openprocess, local or remote). Only Go and .NET are disabled in the container — run those via npm/npx next to your local toolchain. Host-built Rust/C++ binaries debugged in the container get an auto-derived source map back to/workspace.list_supported_languagesreports per-mode availability (modes.launch/modes.attach) with reasons. See Docker support.
npm install -g @debugmcp/mcp-debugger
mcp-debugger --helpOr use without installation via npx:
npx @debugmcp/mcp-debugger --helpstdio is the default and is what most clients want. When the server has to run somewhere else
— a CI runner, a container, a Kubernetes pod — start it on a port instead:
mcp-debugger http --port 3001 # or: node dist/index.js http -p 3001and point the client at it:
{
"mcpServers": {
"mcp-debugger": {
"type": "http",
"url": "http://127.0.0.1:3001/mcp"
}
}
}Each HTTP client gets its own isolated server: debug sessions are never visible to another
client. A client that disconnects without DELETE /mcp keeps its debug sessions — and any
paused attach target — alive until the server reaps it: 2 minutes after its SSE stream
dropped (MCP_HTTP_STREAM_LOST_SESSION_MS), or 30 minutes idle if it never opened one
(MCP_HTTP_STALE_SESSION_MS). GET /health lists what each session is holding.
The port defaults to 3001. GET /health on the same port answers a liveness check. The legacy
sse subcommand still exists but is deprecated — use http.
mcp-debugger exposes debugging operations as MCP tools that can be called with structured JSON parameters:
// Tool: create_debug_session
// Request:
{
"language": "python", // or "ruby", "javascript", "rust", "go", "java", "dotnet", "cpp", 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"
}All 28 tools below are implemented — see the tool reference for parameters and response shapes.
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 |
| List a session's breakpoints with verified state | ✅ Implemented |
| Remove a breakpoint by id or file+line | ✅ Implemented |
| Remove all breakpoints (optionally per file) | ✅ Implemented |
| Start debugging a script | ✅ Implemented |
| Relaunch with the same config, breakpoints re-applied | ✅ Implemented |
| Attach debugger to a running process | ✅ Implemented |
| Detach debugger from a process | ✅ Implemented |
| Open a read-only DAP mirror endpoint so an IDE can attach and inspect | ✅ Implemented |
| Close the mirror endpoint and disconnect IDE clients | ✅ 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 |
| Read captured debuggee output (stdout/stderr) | ✅ Implemented |
| Close a session | ✅ Implemented |
| Hot-swap changed Java classes into a running JVM (Java only) | ✅ Implemented |
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 ││Ruby ││JavaScript││Rust ││Go ││Java ││.NET ││C/C++ ││Mock │
│Adapter ││Adapter ││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": "C:\\path\\to\\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": "C:\\path\\to\\buggy_swap.py"
}
// Response:
{
"success": true,
"state": "paused",
"message": "Debugging started for C:\\path\\to\\buggy_swap.py. Current state: paused",
"data": {
"message": "Debugging started for C:\\path\\to\\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
}🗺️ Roadmap – Path to 1.0: stability criteria, near-term themes, non-goals
📘 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
🔄 CHANGELOG – Release history and upgrade notes
🐍 Python Debugging Guide – Python-specific features
💎 Ruby Debugging Guide – Ruby debugging with rdbg, including remote attach
🔬 Case Study: the initialize response that never came – mcp-debugger debugging itself to root-cause a Ruby launch stall
🔬 Case Study: attaching the debugger to itself – live-patching a running mcp-debugger through its own evaluate_expression to catch a race strace couldn't see
🔬 Case Study: the pause that always succeeded – reading js-debug's own CDP trace to catch its smart-stepper eating user pauses on idle servers
🔬 Case Study: the trace that couldn't name its socket – measure-fix-measure on the diagnostics themselves: one scripted attach run, before and after, as the acceptance test
🟨 JavaScript Debugging Guide – JavaScript/TypeScript features
🐹 Go Debugging Guide – Go debugging with Delve
☕ Java Debugging Guide – Java debugging with JDI bridge
🔷 .NET Debugging Guide – .NET/C# debugging with netcoredbg
⚙️ C/C++ Debugging Guide – CodeLLDB launch, auto-compile, attach-by-PID, core dumps, remote stubs
🦀 Rust Debugging Guide – CodeLLDB setup (Windows specifics)
🐳 Docker Support – Container languages, attach modes, host-binary source mapping
☸️ Kubernetes Debugging – Turnkey attach recipes: registry-free manifests, per-language presets, ephemeral debug sidecar
🚑 JIT Diagnostics Tutorial – Debug live services in Kubernetes, incl. the ephemeral-sidecar flow for compiled code
🤖 Agent Debugging Guide – Correct tool usage patterns for AI agents
⚠️ Known Issues – Current caveats and workarounds
🩺 Diagnostics – mcp-debugger doctor, per-language prerequisites, failure signatures, env-var reference
🔧 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
# Vendored debug engines (Microsoft's js-debug; CodeLLDB, shared by Rust and C/C++)
# are downloaded automatically and verified against committed SHA-256 digest pins
# 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 & C/C++: Download a single shared copy of CodeLLDB for the current platform (packages/codelldb-common)
Integrity: Every download is verified against the pinned SHA-256 digests in the packages' vendor-manifest.json; mismatches fail the build
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.24.0 with eight language adapters, 28 tools, and polished multi-language distribution
✅ Clean architecture with a dynamic adapter pattern
✅ Python · Ruby · JavaScript/TypeScript · Go · Java · .NET/C#: Full step-through debugging
🦀 Rust: Full support on Linux/macOS/Windows (Windows requires the GNU toolchain; MSVC is not supported by CodeLLDB)
⚙️ C/C++: Full step-through debugging via CodeLLDB (launch + attach-by-PID; on Windows prefer MinGW/DWARF — MSVC PDB fidelity is partial)
🟢 Runtime: Node.js 22+
📈 Active Development: Regular updates and improvements — see the Roadmap for the path to 1.0
mcp-debugger is stewarded by Sycamore LLC and led by John Franklin (@debugmcpdev). The project uses an agent-first development model with human accountability: AI agents write most of the code; a human maintainer makes every merge, release, and security decision. See MAINTAINERS.md, GOVERNANCE.md, and SUPPORT.md (including commercial support).
Supply-chain posture: pinned CI actions, OIDC trusted publishing, sigstore provenance on every npm package, SBOMs attached to releases, and an OpenSSF Scorecard score we actively maintain — details in SUPPLY-CHAIN-SECURITY.md. Report vulnerabilities via SECURITY.md.
MIT License - see LICENSE for details.
@Poyraxx — Ruby adapter (rdbg)
@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
debug for Ruby debugging
Give your AI agents a real debugger — 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
