Skip to main content
Glama
debugmcp

MCP Debugger

by debugmcp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_debug_session

Starts a new debugging session for supported languages, either by launching a program or attaching to a running process for breakpoints and step-through debugging.

Instructions

Create a new debugging session. Provide host and port to attach to a running process; omit them for launch mode. Attaching pauses the target unless stopOnEntry is false

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostNoHost to attach to for remote debugging (optional, triggers attach mode)
nameNoOptional session name
portNoDebug port to attach to for remote debugging (optional, triggers attach mode)
timeoutNoConnection timeout in milliseconds for attach mode (default: 30000)
languageYesProgramming language for debugging
stopOnEntryNoAttach mode only: same as attach_to_process.stopOnEntry — omitted means true, the target is paused after attach (possibly late, reported as pending:true). Pass false to attach to a live service without stopping it
adapterConfigNoAttach mode only: adapter-specific attach configuration merged into the attach config (see attach_to_process)
verifyTimeoutNoAttach mode only: how long to wait (ms) for the debugger to report at least one thread after attaching before failing the attach (default: 20000, max: 600000)
executablePathNoPath to language executable (optional, will auto-detect if not provided)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.25.1
    • addedInput schema / properties / adapterConfig
      Added value: +{
+  "additionalProperties": true,
+  "description": "Attach mode only: adapter-specific attach configuration merged into the attach config (see attach_to_process)",
+  "type": "object"
+}
    • changedInput schema / properties / language / enum
      Previous value: -[
-  "mock",
-  "python",
-  "javascript",
-  "rust",
-  "go",
-  "java",
-  "dotnet"
-]New value: +[
+  "mock",
+  "python",
+  "javascript",
+  "ruby",
+  "rust",
+  "go",
+  "java",
+  "dotnet",
+  "cpp",
+  "cobol"
+]
    • addedInput schema / properties / stopOnEntry
      Added value: +{
+  "description": "Attach mode only: same as attach_to_process.stopOnEntry — omitted means true, the target is paused after attach (possibly late, reported as pending:true). Pass false to attach to a live service without stopping it",
+  "type": "boolean"
+}
    • addedInput schema / properties / verifyTimeout
      Added value: +{
+  "description": "Attach mode only: how long to wait (ms) for the debugger to report at least one thread after attaching before failing the attach (default: 20000, max: 600000)",
+  "type": "number"
+}
  2. Changed4 schema fields changedv0.20.0
    • addedInput schema / properties / host
      Added value: +{
+  "description": "Host to attach to for remote debugging (optional, triggers attach mode)",
+  "type": "string"
+}
    • changedInput schema / properties / language / enum
      Previous value: -[
-  "mock",
-  "python",
-  "javascript",
-  "rust"
-]New value: +[
+  "mock",
+  "python",
+  "javascript",
+  "rust",
+  "go",
+  "java",
+  "dotnet"
+]
    • addedInput schema / properties / port
      Added value: +{
+  "description": "Debug port to attach to for remote debugging (optional, triggers attach mode)",
+  "type": "number"
+}
    • addedInput schema / properties / timeout
      Added value: +{
+  "description": "Connection timeout in milliseconds for attach mode (default: 30000)",
+  "type": "number"
+}
  3. First observed

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It usefully discloses that attaching pauses the target unless stopOnEntry is false, but says nothing about what the session creation returns (session id?), permission requirements, or failure behavior on connect timeout — meaningful gaps for a stateful tool with 9 parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences, zero filler, with the highest-value information (the two modes) front-loaded and the pause behavior trailing. Nothing to trim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description never indicates what a created session yields or how to reference it in later calls (e.g., list_debug_sessions, close_debug_session). Given 9 parameters, nested adapterConfig, and no annotations, the behavioral surface is only partially covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 cross-parameter semantics (host+port jointly trigger attach mode), but the schema already labels each of those fields as 'triggers attach mode', so the incremental value is modest.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a new debugging session') and immediately distinguishes two operating modes (attach vs launch). It does not, however, differentiate itself from close siblings like start_debugging and attach_to_process, which appear to overlap with its functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear intra-tool rule: supply host/port to attach, omit them to launch. What it never says is when to pick this tool over start_debugging or attach_to_process, which is exactly the ambiguity an agent faces with 27 sibling tools on offer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools