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

No annotations are supplied, so the description carries the full burden, yet it only states the connection target. It says nothing about whether attaching suspends the target process, what happens on timeout, whether the attached session must be stopped with debug_stop, or how connection failures surface.

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 front-loaded sentence with no filler, and the essential concept (attaching to an existing adapter) comes first. It is arguably too terse for a four-parameter tool, but nothing in it is wasted.

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 stateful tool that connects to a live debug adapter, with no annotations, no output schema, and zero parameter documentation, the definition leaves too much unknown. An agent would need to guess at timeout behavior, path mapping semantics, and how the resulting session is torn down.

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% across four parameters, so the description must compensate and largely does not: it gestures at 'localhost or another explicit host' but never explains port, the connection timeout default, or what localRoot/remoteRoot path mappings do and why they matter for breakpoints.

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 gives a specific verb plus resource ('Attach to an already-listening debugpy adapter'), which cleanly separates it from the sibling debug_launch and from session tools like debug_continue. It does not explicitly name those siblings, but the attach-vs-launch distinction is inferable from the wording.

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?

'already-listening' implies the precondition (an adapter must be running and waiting), which is the key when-to-use signal. However, it never names debug_launch as the alternative for starting a new process, and gives no guidance on what to do when no adapter is listening or which sibling to call afterwards.

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

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

With no annotations, the description carries the full burden, and it does disclose the terminating conditions, which is genuinely useful behavioral context. However, it omits whether the call blocks until one of those conditions occurs, what it returns (e.g., stop reason), and what happens if the session is not paused.

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 front-loaded sentence with the action first and the stop conditions enumerated. No filler or redundant restatement of the tool name.

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 annotations, no output schema, and no parameter descriptions, so the description must do more than it does. An agent still cannot tell what the call returns, how sessionId is obtained, or how timeout expiry is reported.

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% for two parameters. The description alludes to 'timeout' as a stop condition but never explains its units, default of 15, or behavior on expiry, and it says nothing about sessionId, which is the required parameter.

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?

States a specific verb ('Continue execution') and enumerates the exact conditions that end the resume: next breakpoint, exception, process exit, or timeout. This contrasts implicitly with debug_step, though it never names that sibling explicitly.

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?

There is no explicit guidance on when to use this versus debug_step or debug_launch, nor any stated prerequisites (e.g., that a session must be paused at a breakpoint). Usage is only inferable from the word 'continue'.

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

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

With no annotations, the description carries the burden and does surface the key risk that this executes code in the target process. It omits other behavioral facts: whether the process must be halted, side effects on state, failure behavior, and no output schema to explain results.

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 short sentences, purpose first and the safety caveat second. Nothing is wasted.

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 side-effecting tool with four undocumented parameters, no annotations, and no output schema, the description leaves too much unexplained: frame selection defaults, what 'context' changes, and what the evaluation returns.

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% across four parameters, and the description adds nothing about sessionId, expression, context (defaulting to 'repl'), or which frame is used when frameId is omitted. It only vaguely gestures at 'paused frame' without tying it to frameId.

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?

States a specific verb and resource: evaluating an expression in a paused frame. It is distinguishable from read-only siblings like debug_variables and debug_scopes, though it doesn't name them explicitly.

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 phrase 'in a paused frame' implies a prerequisite state, but it never says what to do when not paused or when to prefer debug_variables/debug_scopes instead. Usage is implied rather than spelled out.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It does say the return is 'concise guidance', which is real information about cost and output shape, but it does not state that the call is side-effect free, that it requires no active debug session, or that it is safe to call repeatedly.

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 front-loaded sentence with no filler. 'for coding agents' is mildly redundant given the tool is exposed to an agent, but nothing is wasted and the purpose arrives immediately.

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 zero-parameter, no-annotation, no-output-schema tool in a crowded family of eleven debug siblings, the definition is adequate but thin. It does not say what topics the guidance covers, whether it reflects the current debug session, or how it relates to the individual debug_* tools.

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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description adds only that no argument is needed to obtain the 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?

States a specific verb and resource: returns guidance about the debugger MCP tools. It is clearly a meta/help tool, which distinguishes it from the action siblings (debug_launch, debug_step, debug_evaluate, etc.), but it never names those siblings or says explicitly that it covers them.

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 phrase 'when and how to use the debugger MCP tools' implies this is the entry point to consult before or instead of guessing at the action tools, but the guidance is only implied. There is no explicit 'call this first' or 'use when unsure which debug tool applies' instruction and no stated exclusions.

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

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

With no annotations, the description carries the full behavioral burden. It discloses one important trait—execution halts before user code so breakpoints can be set—but says nothing about the 15s timeout and what happens on expiry, whether the process persists across later debug_* calls, or how launch failures surface.

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 tight sentence with the verb and the key behavioral constraint front-loaded; nothing redundant. It is efficient but so short that concision shades into under-specification.

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 7-parameter launch tool with no annotations and no output schema, a single sentence is not enough. The agent lacks lifecycle, timeout, failure-mode, and parameter-role information needed to invoke this correctly within a multi-step debug workflow.

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 only 57%, leaving args, timeout, and stop_on_entry undocumented anywhere. The description does not compensate, and it never clarifies the interaction between its 'pause before user code' claim and the stop_on_entry flag, which is a likely source of confusion.

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?

States a specific verb and resource ('Launch a Python program under debugpy') plus a scope detail (pause before user code). It implicitly separates launch-vs-attach from the sibling debug_attach, but never names that alternative explicitly.

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 choose this over debug_attach or debug_python_repro, nor any stated prerequisites (debugpy installed, target being a script vs module). The implied usage is 'starting a new debug session,' but nothing tells the agent when not to call it.

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

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

No annotations are provided, so the description carries the full burden, and it discloses only the happy-path sequence. It omits critical behavior: what happens on timeout (default 20s), whether a debugpy server or child process is left running or cleaned up, what is returned when a breakpoint is never hit, and the cost or side effects of spawning a process. "Launch...under debugpy" hints at a side effect but nothing about lifecycle or failure modes is stated.

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 tightly packed sentences with the routing directive front-loaded and zero filler. Every clause carries information an agent needs.

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 10-parameter tool with a nested breakpoint object, no annotations and no output schema, the description is too thin. It should explain the session lifecycle (interaction with keep_session), timeout semantics and what a returned stack looks like, since none of that is recoverable from structured fields alone.

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 a middling 60%, and the description adds no parameter-level meaning beyond loosely implying stop_on_entry ("continue to the first stop") and locals_limit ("top-frame locals"). Undocumented parameters such as args, timeout, locals_limit and stop_on_entry are left entirely to the schema, so the coverage gap is not compensated.

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 names a specific verb set and resource: launch a Python script under debugpy, set breakpoints, continue to the first stop, and return the stack plus top-frame locals. "Use this first for a reproducible Python bug" also distinguishes it from the sibling debug_launch/debug_attach tools, so an agent can pick it without opening a schema.

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?

It gives clear entry-point guidance ("Use this first") and states the triggering condition (a reproducible Python bug). It never names the alternatives or gives exclusions, such as what to use when the bug is not reproducible or the process is already running, so an agent gets context but no comparisons.

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

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

With no annotations provided, the description carries the full disclosure burden. It does add real value by revealing that the response contains variablesReference handles, which tells the agent this is a read-side enumeration feeding debug_variables. However it says nothing about read-only safety, behavior on a stale or invalid frameId, or whether sessionId must be an active session.

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 front-loaded sentence with the verb, resource, scope, and payload all present; no filler or repetition. It is efficient, though the terseness leaves no room for the usage or parameter detail the tool needs.

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 2-parameter read tool with no output schema and no annotations, the description is only partially sufficient. It covers what is returned but omits the sessionId concept, the prerequisite frameId source, and the handoff to debug_variables, leaving meaningful gaps an agent must guess at.

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% for both required parameters. The description implies frameId is a stack-frame identifier, but adds no format, origin, or validity guidance, and completely ignores sessionId (whether it is a debug session handle, how to obtain it, or whether it must be active). Well below the point where the schema could compensate.

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?

States a specific verb and resource ('Return debugger scopes for a stack frame'), which is clearly distinct from debug_stack (frames) and debug_variables (variable values). It also names the key output artifact, variablesReference handles, giving an agent a concrete reason to call it. It stops short of explicitly contrasting itself with siblings, so not a 5.

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

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

There is no statement of when to call this versus debug_variables or debug_stack, and no mention that frameId must come from a prior debug_stack call. The only usable hint is implicit: scopes are per-frame and yield variablesReference handles. An agent must infer the workflow entirely.

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

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 does not say whether new breakpoints replace or accumulate with existing ones, whether the file must already be loaded in a stopped session, whether line numbers are 1-based, or what happens on an invalid line or missing file — all material for a debugger mutation.

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 front-loaded sentence with no filler, which is structurally clean. However, the brevity is achieved by omitting essentials rather than by tight editing, so it reads as under-specified rather than 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 tool has 4 parameters, three required, zero schema descriptions, no annotations, and no output schema. A one-sentence description leaves an agent unable to determine path resolution, session requirements, or breakpoint-replacement semantics before invoking it.

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% across 4 parameters. The description only indirectly illuminates 'lines' (line breakpoints) and 'file' (Python source file); it says nothing about sessionId (the target debug session) or cwd (path resolution base), both of which are ambiguous without explanation.

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?

States a specific verb ('Set') and resource ('one or more line breakpoints') plus the target ('Python source file'), which is enough to distinguish it from debug_continue, debug_step, or debug_evaluate. It does not explicitly contrast with the closest sibling behaviors, so it stops short of 5.

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

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

There is no guidance on when to use this versus alternatives, and no prerequisites stated (e.g., that it requires an active debug session identified by sessionId, or that it should precede debug_launch/debug_attach in a workflow). The agent must infer placement in the debug workflow entirely from the sibling names.

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

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

No annotations are supplied, so the description carries the full burden, yet it only restates that frames are returned. It does not disclose pagination/truncation behavior, whether it is a pure read, whether it fails when not stopped, or anything about the shape of the returned frames.

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-formed sentence, front-loaded with the verb and result. It is efficient, though the terseness crosses into under-specification rather than economy.

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?

With no annotations, no output schema, and zero schema description coverage on all three parameters, this tool needed the description to explain state prerequisites and parameter meaning. It does far too little for a debugger tool where an agent must know the target is stopped and what 'levels' controls.

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% across three parameters, and the description only indirectly hints that threadId is optional ('current stopped thread'). It adds nothing about the 'levels' depth parameter (default 20) or what sessionId refers to, so it fails to compensate for the schema 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?

States a specific verb ('Return') and resource ('stack frames') with a clear scope qualifier ('current stopped thread'). An agent can tell this apart from sibling readers like debug_scopes and debug_variables by the returned artifact, though no sibling is named explicitly.

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 phrase 'current stopped thread' implies the debuggee must be paused, which is a mild state prerequisite, but there is no guidance on when to pick this over debug_scopes or debug_variables, no exclusions, and no statement of what happens if the process is running.

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

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

With no annotations, the description carries the full behavioral burden and only partially delivers: it discloses the 'thread must be stopped' precondition. It says nothing about what happens after the step (does the thread stay paused?), what the 15-second timeout governs, or how a failure is surfaced.

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-formed sentence with the modes front-loaded and zero filler. It is efficient, though the parallel structure ('over the next line, into a function, or out of the current function') could be tightened slightly.

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 three-parameter debugger control tool with no annotations and no output schema, the definition covers the core action but leaves the agent guessing about timeout behavior and what state the debugger returns to. Adequate to call it, incomplete for calling it confidently.

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%, so the description must compensate. It does explain the three enum values of kind in plain language (over a line, into a function, out of a function), which is the highest-value parameter here, but sessionId and timeout receive no explanation beyond their names and defaults.

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?

States a specific verb (step) plus the resource (stopped thread) and enumerates the three modes, which maps directly onto the kind enum. It implicitly distinguishes itself from debug_continue by scoping to 'the next line' rather than resuming execution, but never names a sibling explicitly.

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 phrase 'the stopped thread' implies the debuggee must already be paused, giving an implicit precondition. There is no explicit guidance on when to prefer stepping over debug_continue, debug_stack inspection, or when to use each of the three modes.

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

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

With no annotations, the description carries the full disclosure burden and does surface the most important trait: the debuggee is terminated by default, which is a destructive side effect. It omits error behavior for an invalid/stale sessionId and does not describe the result of the disconnect operation.

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 front-loaded sentence with zero filler; the destructive default is stated up front rather than buried.

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 two-parameter session-control tool without an output schema this is close to adequate, but with no annotations and no schema descriptions, more is needed on sessionId sourcing and on what the caller sees after the session ends.

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%, so the description must compensate. It explains the semantic effect of terminate_debuggee via the 'by default' clause, but sessionId — the required parameter — receives no explanation of what form it takes or where it comes from.

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?

States a specific verb (disconnect/terminate) and resource (debug session), which is clearly the counterpart to the debug_launch/debug_attach siblings in the list. It does not explicitly name a sibling, but the operation is 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?

Usage is only implied: an agent can infer this ends an active session. There is no statement of prerequisites (e.g., requiring a live sessionId) or of alternatives such as detaching without terminating, so the when-to-use boundary is left to inference.

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

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

With no annotations, the description carries the full burden yet never states that this is a read-only inspection operation, or what happens on an invalid/expired reference. The presence of start/count hints at pagination or truncation of large collections, but the description says nothing about result limits, and it does not mention that expansion may be shallow and produce further nested references.

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 front-loaded sentence with no filler, and the key object of the operation comes early. It is efficient but so terse that the brevity costs information rather than reflecting it.

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 annotations, no output schema, and 0% schema coverage on four parameters means the description is the only documentation, and it omits return shape, paging behavior, session binding, and error cases. For a debugger inspection tool that returns arbitrary nested data structures, this leaves material gaps.

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% for 4 parameters, so the description must compensate. It clarifies variablesReference only obliquely ('a debugger variablesReference') and says nothing about sessionId, start, or count, leaving the paging semantics of collections entirely undocumented.

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?

Uses a specific verb ('Expand') on a specific resource ('variablesReference') and enumerates what the expansion yields (locals, globals, objects, lists, dicts), which separates it from debug_evaluate and debug_scopes. It does not say where the variablesReference originates, so the sibling relationship is only partly disambiguated.

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?

Usage is only implied: an agent can infer it should call this after obtaining a variablesReference from a stack/scope call, but no sibling is named and there are no exclusions or preconditions stated. There is no guidance on when to prefer this over debug_evaluate or debug_scopes.

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