Retrieve key details of an active debug session: PID, status, executable path, and command line. Use this to inspect the current state of a target process during debugging.
Get debug session information including PID, status, executable path, and command line.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Debug session ID |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is an information-retrieval operation and lists the returned fields, implying a read-only action. It does not disclose behavior for invalid or stale session IDs, or explicitly state that no state is modified.
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, well-structured sentence with zero filler. It front-loads the action and resource, then immediately enumerates the meaningful return fields, earning every word's 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 simple one-parameter read-only tool, the description is largely complete: it names the tool's purpose and return content. It could be improved by mentioning that session IDs come from debug_list_sessions, but the core information needed to invoke and interpret the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because session_id is described as 'Debug session ID'. The description does not add extra detail about session_id format, how to discover valid values, or failure behavior, but the schema already documents the parameter adequately, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('debug session information') and enumerates the exact data returned: PID, status, executable path, and command line. This clearly distinguishes it from sibling tools like debug_get_threads or debug_get_backtrace, which target different aspects of a 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?
The description implies when to use the tool: when an agent needs details about an existing debug session identified by session_id. However, it does not explicitly mention alternatives, exclusions, or the prerequisite of first listing sessions via debug_list_sessions to obtain a valid session ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.