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

With no annotations, the description carries the full burden and does: the thread-polling verification handshake, the ~20s verifyTimeout failure path that tears down the proxy, and the pending:true / 'running' state that only a late stop event transitions to 'paused.' It also discloses that unrecognized adapterConfig keys are forwarded and reported in a response warning, and that js-debug pins its own orchestration keys.

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?

Purpose is front-loaded in the first clause, and every subsequent sentence carries real behavioral content with no filler. The dense em-dash-heavy sentences and nested parentheticals make it harder to scan than it needs to be, keeping it from a 5.

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 an 11-parameter, nested-object tool with no annotations and no output schema, the description covers the failure mode, the asynchronous state model, and the follow-up tool an agent must call. Nothing needed to invoke it correctly or interpret a pending response is missing.

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, but the description adds meaning the schema doesn't: the interaction where a late stop yields pending:true with the target still freezing on next dispatch, and the timeout-vs-verifyTimeout precedence. That extra state semantics is enough to lift it above baseline.

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?

Opens with a specific verb+resource: 'Attach to a running process for debugging,' which implicitly contrasts with the launch path (start_debugging) among the siblings. It does not explicitly name a sibling or state the attach-vs-launch decision, 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?

Gives concrete routing guidance: it names wait_for_stop as the tool to call when the post-attach pause lands late, and warns that stopOnEntry must be false 'when attaching to a live service.' It never states when to choose attach over start_debugging, so it lacks a full when/when-not framing.

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 does disclose two genuinely useful behavioral traits: idempotency ('Clearing zero breakpoints is success') and immediate effect regardless of run state ('Takes effect immediately while the program is running or paused'). It omits error conditions, required session state, and return shape.

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?

Three short sentences, front-loaded with the core action and scope, followed by the two behavioral notes. 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?

For a mutation tool with no annotations and no output schema, the description covers purpose, scope, idempotency, and timing adequately. It stops short of stating error cases or whether the session must be active, which would complete the picture.

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%: the 'file' parameter is already documented in the schema, while the required 'sessionId' has no schema description. The description only vaguely covers session scope ('in a session') and adds little beyond the schema, so it only partially compensates 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?

States a specific verb and resource (remove all breakpoints) plus the scope options (entire session vs one file). The word 'all' implicitly distinguishes it from the singular remove_breakpoint sibling, but it never names that sibling explicitly, so an agent must infer the boundary.

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 scope phrasing ('all breakpoints in a session, or all breakpoints in one file') implies when this bulk-clear is appropriate versus the singular remove_breakpoint, but there is no explicit when-to-use/when-not guidance or named alternative. Usage 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 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.

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

With no annotations, the description carries the full burden and usefully discloses that the tool returns immediately after adapter acknowledgment and does not wait for the next stop. It also explains how to block or inspect the stop without waiting. It does not describe error behavior or exactly what the immediate return contains, leaving a modest 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 front-loaded with the core action and its non-blocking behavior, then gives alternatives in a compact form. The middle sentence is dense and slightly ambiguous with 'show the same without waiting,' but overall it is appropriately sized.

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 covers execution behavior, stopping semantics, and output-reading routing well, which is useful given there is no output schema. However, it omits the required sessionId parameter and does not describe failure cases or what acknowledgment means, leaving the definition incomplete for correct 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?

The single required parameter 'sessionId' has 0% schema description coverage, and the description never mentions it. The name is somewhat self-explanatory, but the description does not clarify session selection, required state, or identifier format, so it does not 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?

The description states a specific verb and resource ('Continue execution') and immediately distinguishes the operation from blocking alternatives such as wait_for_stop. An agent can tell what this tool does and how it differs from siblings without consulting other definitions.

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 explicitly routes the agent to wait_for_stop when it needs to block until the next stop, and to list_debug_sessions or get_stack_trace for non-blocking stop inspection. It also points to get_output for stdout/stderr. The guidance is strong, though it does not explicitly contrast continue_execution against stepping tools.

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 exist, so the description bears full disclosure burden. It does surface a real side effect ('Attaching pauses the target unless stopOnEntry is false') and the mode-selection semantics, but says nothing about session lifecycle, failure behavior, or what a created session yields, which matters for a 13-param stateful tool.

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?

Purpose is front-loaded in the first clause, followed by the mode rule. The long nested parenthetical listing debugger URIs is dense but each clause carries real information; nothing is filler.

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 13 parameters, no annotations, and no output schema, the description covers mode selection but not the return value (presumably a session reference used by list_debug_sessions/close_debug_session) or error/pending outcomes beyond a brief nod to pending:true in the schema. Adequate but notably thin for a tool this complex.

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 every parameter is already documented (including 'triggers attach mode' and stopOnEntry's default). The description's added value is the cross-parameter synthesis — grouping port/processId/adapterConfig as the attach trigger set and noting host alone is insufficient — plus the Flutter deviceId example, but most individual claims restate 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?

States a specific verb+resource ('Create a new debugging session') and explains the two modes (launch vs. attach) that the tool spans. It names attach_to_process as the related sibling and clarifies that this tool can do attach in one call, but it never contrasts with start_debugging, so the launch-mode boundary is left implicit.

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?

Explicit trigger rule: supplying port, processId, or a target-naming adapterConfig selects attach mode; omitting them selects launch mode, and 'host alone does not' trigger attach. What's missing is when to call create_debug_session instead of attach_to_process or start_debugging directly — the alternative is referenced but never routed to.

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 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.

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

With no annotations, the description carries the full burden and largely meets it: it warns that expressions can read and modify program state, discloses automatic thread switches or hidden paused frames via anchorNote, and states frame naming on both success and failure. It does not cover error semantics beyond the frame name or any permission/authorization context, so a 5 is not warranted.

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 purpose is front-loaded in one sentence, and each following clause adds distinct information (frame adoption, anchorNote disclosure, frame naming, wait default). The embedded em-dash aside about breakpoints and hidden frames is convoluted enough to slow parsing, costing it the top score.

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 4-parameter, no-output-schema, no-annotation tool, the description compensates well by describing anchorNote, frame naming, and side-effect capability that an output schema would otherwise convey. Missing detail on failure modes other than frame naming and on timeout-expiry behavior (which is only in the schema) keeps it from 5.

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%: frameId and timeout are already documented in the schema. The description usefully restates the no-frameId fallback behavior and the default wait, but adds nothing for sessionId or expression. Against the coverage baseline this lands at 3.

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 ('Evaluate expression in the current debug context') and immediately distinguishes itself from sibling read tools by explaining that absent a frameId it adopts the same top frame as stack and locals. An agent can tell it apart from get_variables/get_stack_trace 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?

Explains the key routing decision: pass an authoritative frameId from get_stack_trace to suppress automatic frame/thread selection, otherwise the adopted top frame is used. It implies but never explicitly says 'use this instead of locals when you need to compute or mutate an expression,' so it stops short of a full when/when-not statement.

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 does so: read-only enforcement, idempotency ('calling it again returns the same endpoint'), token requirement, and the full closure lifecycle (unexpose_session, close_debug_session, restart, debuggee exit). This is unusually complete behavioral disclosure for a mutation-adjacent tool.

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?

It is longer than most descriptions but every sentence carries distinct information (capability, token, rejection semantics, lifecycle). The core purpose is front-loaded, though the density is high for a single-parameter tool.

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?

Even without an output schema, the description explains the return values (host, port, session token) and the attach configuration requirement, and it covers lifecycle and control restrictions. An agent has everything needed to invoke and reason about the result.

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?

There is one required sessionId parameter at 0% schema coverage, so the description must compensate. It implies an active session is needed and describes the returned token/host/port, but never states which session identifier to pass or how to obtain it, leaving the single parameter under-specified.

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 a specific verb (Expose) and resource (a debug session) and defines the concrete output form: a read-only DAP mirror endpoint on 127.0.0.1. It clearly distinguishes itself from siblings like unexpose_session and close_debug_session by naming the lifecycle boundary.

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 states the exact use case (let an IDE attach as a second debug client), prerequisites (requires an active launched/attached session), and the when-not case (the mirror never drives execution; continue/step/pause and breakpoint changes are rejected). It also names the counterpart tool unexpose_session.

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 does substantively: it discloses frameless-thread handling, sibling preference/adoption with disclosure in a note, anchor semantics at breakpoints, and the empty-with-guidance fallback for JS frames. It omits error cases, permissions, and pagination specifics, but the edge-case disclosure is above average.

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?

Front-loads the purpose in the first sentence, which is good, but the following sentences are long and built on undefined jargon ('shared inspection anchor', 'note'), which reduces readability. Every sentence is doing work, but the density hurts comprehension.

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 annotations and no output schema, the description should explain the response shape and key concepts, yet 'anchor' and 'note' are never defined and the return structure is only partially implied. It covers edge cases adequately but leaves the agent guessing on core semantics.

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%, with names and includeSpecial already documented in the schema. The description adds one genuine insight beyond the schema — that names:[...] is the workaround for size-guarded responses — but does not clarify sessionId or the broader fetch semantics. Baseline 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?

States a specific verb+resource (get local variables) and adds a distinguishing scope concept ('shared inspection anchor') that separates it from the sibling get_variables/get_scopes. However, it never names or contrasts those siblings explicitly, so differentiation is implied rather than stated.

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?

Gives behavioral context for specific situations (frameless thread, pause inside an internal frame, JS frame with no Local scope), which is useful guidance. But it never says when to call this tool versus get_variables or get_scopes, so routing to alternatives 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 and does well: it discloses per-launch buffering, the 1000-entry cap, telemetry/DWARF-noise filtering, and lifecycle limits. It omits permission or concurrency considerations, but the behavioral picture is otherwise rich.

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?

Four sentences, each earning its place: purpose first, then buffering behavior, then lifecycle window, then the pagination how-to. No filler or repetition.

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, and the description compensates by naming the cursor field (nextSince) used for continuation and implying the entry-list return. Combined with the limit/hasMore schema text, an agent has enough to call and page correctly.

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%, and the description meaningfully compensates by explaining the cursor contract ('pass since=nextSince from the previous response to fetch only new output'), which ties into the pagination semantics. limit and sessionId remain schema-documented only.

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 (Get) and resource (debuggee output: stdout/stderr/console) scoped to a session. Clearly distinguished from siblings like get_variables or get_stack_trace, which retrieve different data.

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?

Explains the temporal window ('works while running and after it finishes, until the session is closed') and how to page with since=nextSince, but gives no explicit when-not guidance or named alternative. Usage is implied by the output-retrieval framing rather than stated as a choice among siblings.

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 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.

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.

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

With no annotations, the description carries the behavioral burden and does substantial work: it explains default filtering of internal/runtime frames, hiddenFrames and note reporting, pausedFrame handling when the paused frame is internal, stale-build disclosure, and implicit thread adoption. It does not explicitly state that the operation is read-only or side-effect-free, which keeps it from a 5.

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 front-loaded with the core action, but it becomes a dense paragraph of debugging jargon such as "implicit frameless stopped thread" and "policy-recognized user frames." Much of the content earns its place, but the structure could be clearer and more scannable.

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?

Because there is no output schema, the description usefully explains return fields like stopReason, hiddenFrames, note, and pausedFrame. However, it omits basic operational context such as the required sessionId and when to choose this tool over related debugging 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?

Schema coverage is 67%, with threadId and includeInternals documented in the schema. The description adds some meaning around internal-frame filtering and hidden-frame reporting, but sessionId is not described in either the schema or the description, and the description does not clarify its required role.

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 opening sentence gives a specific verb and resource: "Get stack trace." It also says the response includes stopReason, clarifying the debugging context. It does not explicitly differentiate itself from nearby siblings such as get_scopes or get_variables, so it stops short of 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?

The description does not say when an agent should call get_stack_trace versus alternatives like list_threads, get_scopes, or get_variables. It mentions one internal edge case involving an implicit frameless stopped thread, but that is response behavior rather than user-facing usage guidance.

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 behavioral burden and discloses important traits: responses are size-guarded, oversized values are cut with truncated:true, and very large scopes return a capped list with a truncation notice. It stops short of documenting permissions, error cases, or the notFound behavior that only appears in the schema.

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 dense sentences with no filler; the core purpose and scope come first, followed by the truncation behavior and the names escape hatch. The em-dash-heavy phrasing is compact but still readable.

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 read tool with no annotations and no output schema, the description covers the key operational risk (truncation) and the mitigation (names), which is exactly what an agent needs to avoid misreading results. The undocumented sessionId and lack of explicit sibling routing are minor 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 coverage is 67%, and the schema itself documents names (including notFound) and scope thoroughly; the description largely restates scope and the names workaround. sessionId remains undocumented in both, so the description does not fully 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?

States a specific verb+resource ("Get variables") and pins the scope to a variablesReference number, so an agent knows exactly what is retrieved. It does not, however, distinguish itself from close siblings like get_local_variables or get_scopes, which also return variable data.

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?

Provides a concrete usage hint — pass names:[...] to fetch specific variables in full when the scope is capped — which tells the agent how to work around truncation. It gives no explicit when-to-use/when-not guidance versus the sibling variable tools (get_local_variables, get_scopes, evaluate_expression), leaving tool selection 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 and does most of it: state survives, breakpoints are re-planted and re-resolved, a reload to a paused program lands on resume, and a breakpoint in build() surfaces as the stop with location and snapshot. It does not address permissions/authorization or whether a failed partial swap can leave the program inconsistent, so it stops short of a 5.

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?

Front-loaded with the core purpose and state-preservation claim, then split cleanly by language. It is dense and long, but nearly every clause conveys behavior an agent needs given two distinct implementations; only the parenthetical about breakpoints in build() is slightly overloaded.

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?

There is no output schema, and the description compensates by stating what is returned: which classes were redefined, the newest file timestamp, and anchorResolution reporting moved/stale breakpoints. Combined with the per-language prerequisites and refusal behavior, an agent has enough to call this correctly.

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 75%, with timeout, classesDir, and sinceTimestamp already documented, so baseline is 3. The description adds real value beyond the schema by explaining the classesDir scanning semantics (files modified after sinceTimestamp) and the incremental pattern of feeding back the returned newest timestamp, though sessionId remains undocumented in both places.

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 effect ('apply changed code to the running program and keep its state') and then specializes it per language: Flutter SDK hot reload and Java JDI HotSwap class redefinition. No sibling tool does this, and the description makes that unambiguous, including naming the deprecated alias redefine_classes.

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?

Explicit about when it applies (Flutter and Java), when it is refused ('refused by name on the other languages'), and prerequisites ('the app must have started'). It also gives operational guidance like increasing timeout for many classes and passing the returned timestamp as sinceTimestamp for incremental updates.

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 does well: it discloses that unverified/queued breakpoints report verified=false, that function breakpoints surface separately as functionBreakpoints, and that they are omitted when filtering by file. It stops short of error or auth behavior, but the return-shape disclosure is valuable given no output schema.

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?

Three sentences, no filler, and the core purpose plus return contents are front-loaded before the state/edge-case details. 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 two-parameter read tool with no output schema and no annotations, the description covers what is returned, how function breakpoints are grouped, and the session states in which it works. Error handling is not covered, but the operational picture is otherwise complete.

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 'file' parameter is documented in the schema, and the description adds useful behavior around it (functionBreakpoints omitted under file filtering). 'sessionId' is undocumented in both places, matching the 50% coverage; the description implies session scoping but adds no format detail.

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 (list) and resource (breakpoints) scoped to a session, and adds what is returned (verified state, adapter-assigned ids). It is clearly distinguishable from siblings like set_breakpoint, remove_breakpoint, and clear_breakpoints.

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?

Explains the temporal context in which it is valid (before launch, while running/paused, after exit) and notes the file-filtering mode. It does not explicitly name alternatives, but the read-vs-mutate distinction against the breakpoint siblings is clear from the name and description.

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 provided, so the description carries the behavioral burden. It discloses an important trait: paused sessions include lastStop with a reason (breakpoint vs exception), which is useful non-obvious context. However, it doesn't state whether this is a read-only operation, pagination behavior, or how it interacts with session lifecycle.

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, front-loaded with the purpose, then a detail about paused session shape. No waste.

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 no-param, no-output-schema list tool, the description covers what it returns (including lastStop for paused sessions) adequately. Lacks only pagination/activation caveats, but those are minor.

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?

Zero parameters, so baseline is 4. No parameter info is needed or provided, and the description correctly stays silent on 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?

States a specific verb (list) and resource (active debugging sessions, with detail on paused sessions). Clear enough to distinguish from sibling create_debug_session or close_debug_session, but doesn't explicitly contrast with other list_* 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?

No explicit when-to-use guidance or alternatives. Usage is implied by 'List all active debugging sessions' — an agent would infer this is for enumerating sessions, but there's no mention of when to prefer this over create_debug_session or other tools.

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 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.

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.

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

With no annotations, the description carries the full burden and does so: it discloses the ~5s timeout, the pending:true partial-success state, the reasons a stop may not be observed (native code, idle server), the async semantics of the session reporting "paused" later, the returned fields (stopReason, location, note), the thread-frame fallback logic, and the actionable-error case. This is unusually complete 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?

The purpose is front-loaded in the first clause, but the remaining text is a dense run-on with stacked parentheticals (the thread-frame explanation is nearly unparseable on one read). The information earns its place, but the packaging makes it harder to extract than necessary.

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?

There is no output schema, so the description rightly explains the return shape (stopReason, location, note, pending) and the error path — a real strength. The only gap is the undocumented sessionId, which is likely conventional across all sibling debugger 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?

Schema coverage is only 50% — threadId is documented but sessionId has no description anywhere. The description adds no parameter-level meaning at all: it never mentions sessionId, and it does not restate the important "omit threadId to pause all threads" behavior, so the agent gets nothing 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?

States a specific verb and resource ("Pause a running program") and immediately differentiates itself from the sibling wait_for_stop by explaining which case calls for which. An agent can distinguish it from continue_execution, step_over, and wait_for_stop 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 a clear trigger (a running program), a fallback path ("call wait_for_stop to block until then"), and a failure condition (no debuggable target). It does not explicitly exclude anything, but the routing to the alternative covers the main ambiguity.

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 does meaningful work: it discloses the destruction scope ('removes all breakpoints at that location') and the lifecycle window in which the removal is honored. It omits failure behavior, e.g. what happens when no matching breakpoint exists or the id is stale.

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 dense sentences with zero filler; the primary addressing mechanism and the immediate-effect semantics are front-loaded before the secondary lifecycle note.

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 mutation tool with no annotations and no output schema, the definition covers targeting and effect timing well enough to call it correctly. The remaining gap is the absence of error/confirmation behavior when no breakpoint matches.

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 80%, so the schema already documents each addressing field, including the function-name rewrite details and breakpointId precedence. The description restates the three modes but adds no syntax or edge-case detail beyond the schema, so the baseline of 3 applies.

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 (remove a breakpoint) and enumerates three distinct addressing modes with their resolution sources, so an agent knows exactly what the call does. It references siblings set_breakpoint and list_breakpoints as id sources but never distinguishes itself from clear_breakpoints, which is the closest alternative for bulk removal.

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?

Gives clear operational context: the removal takes effect immediately while running or paused, and also works after the program exits but before a relaunch. It does not say when to prefer this over clear_breakpoints or how to choose among the three targeting modes when more than one applies.

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 does so: it discloses that the current program is terminated, that breakpoints are re-applied automatically, and that the get_output buffer resets so reads must start at since=0. It also documents the response shape (mirrors start_debugging, can return pending:true) and the session-type restrictions.

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?

Front-loaded with the core action and side effects before the edge cases, and virtually every sentence carries needed information. The final clause about answering 'like start_debugging, including "running" with pending:true' is nested and slightly dense but still earns 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 one-parameter tool with no annotations and no output schema, the description covers side effects (program termination, breakpoint re-application, buffer reset), valid session states, invalid session types, and the response handoff to wait_for_stop. Nothing an agent needs to call this correctly is missing.

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 description never mentions it explicitly. Its meaning is largely self-evident from the surrounding session-oriented tools, so the gap is minor, but the description adds nothing beyond the schema here.

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 (restart) and resource (the debuggee), then immediately defines the mechanics: terminate and relaunch with the same configuration as the last start_debugging. That framing cleanly distinguishes it from start_debugging and create_debug_session among the 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?

Explicitly gives the positive conditions (works while running, paused, or after the program has exited) and the exclusions (not available for attach sessions or sessions never launched). It also names the follow-up tool: call wait_for_stop when the relaunch returns running with pending:true.

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 disclosure burden, and it does little: one caveat about non-executable lines causing unexpected stepping behavior. That caveat is already essentially duplicated in the `line` parameter's schema description, so it adds no new information beyond structured data. Nothing about permissions, duplicate breakpoints, error behavior, or what a successful call yields.

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 with the core action front-loaded and the caveat second; there is no filler. The brevity is efficient, though it shades into under-specification rather than being a model of tight structure.

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?

This is a 10-parameter tool with no annotations and no output schema, yet the description says nothing about return values (e.g., a breakpoint id the agent needs for remove_breakpoint), failure modes, or how the four address modes interact. The rich schema compensates somewhat, but the description is far too thin for the tool's complexity.

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 90%, so the parameter meanings are already thoroughly documented in structured data (file vs FQCN, statement match semantics, logpoint interpolation, suspendPolicy adapter support). The description adds no parameter-level meaning beyond restating the non-executable-line caveat. Baseline 3 is appropriate when the schema does the heavy lifting.

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 a specific verb and resource ("Set a breakpoint"), which unambiguously identifies a debugger breakpoint-creation operation. It does not distinguish this from sibling tools like remove_breakpoint, clear_breakpoints, or list_breakpoints, nor does it hint at the addressing modes (line, statement, function) that define this tool's actual surface.

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 versus alternatives: nothing about choosing between line, statement, or function addressing, when to prefer a logpoint, or how it relates to start_debugging/pause_execution. The only usage-ish content is a warning about non-executable lines, which is a caveat rather than a when-to-use rule.

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 delivers the most important behavioral fact: this call waits only briefly and answers in one of three states ('paused', 'stopped', 'running' with pending:true). It also discloses that the short hold cancels nothing and keeps breakpoints armed, and that stopOnEntry has its own answer. It does not mention side effects on an existing process or error behavior against an invalid 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?

The purpose is front-loaded, but the body is a single semicolon-chained sentence that is hard to parse, packing return states, hold semantics, and follow-up routing into one run-on clause. There is little filler, but the structure undercuts the density.

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 nine-parameter, nested-schema launch tool with no annotations, the description covers the async return contract, which is the piece an agent most needs and which the schema cannot express. Missing pieces are error and failure behavior, and whether a debug session must be created first, although the required sessionId hints at 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 78%, so the schema largely documents the parameters itself, and testRunner, testTarget, dryRunSpawn, breakOnExceptions and the dapLaunchArgs sub-keys each have rich descriptions. The tool description adds almost nothing parameter-specific beyond the stopOnEntry note, so the baseline applies.

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 opening sentence gives a specific verb and resource: 'Start debugging a script'. It also distinguishes itself from wait_for_stop by naming that tool as the blocking follow-up. However, it never explicitly contrasts with the other obvious siblings in this list, attach_to_process and restart_debugging, so the agent must infer that boundary from the 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 states a clear usage rule for the alternative: 'The hold is not a limit on the program... call wait_for_stop to block until the program stops or ends', even giving the server-specific case of sending a request first. It stops short of naming when not to use this tool, such as why to choose attach_to_process or restart_debugging instead.

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 does so well: it discloses the ~5s wait, the possibility of returning success while still executing, the 'running' state plus pending:true, and the later transition to 'paused'. It also points to wait_for_stop for blocking behavior — rich, non-obvious behavioral context.

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 dense sentence that front-loads the core action and then explains the timeout/state behavior. It's information-packed without waste, though the parenthetical about wait_for_stop is slightly cramped.

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 one parameter, no output schema, and no annotations, the definition covers the essential async semantics an agent needs to call and interpret the result. It stops short of describing error conditions or the full returned payload, but the critical behavior 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 coverage is 0% and the single sessionId parameter is never mentioned in the description. Because the parameter is self-explanatory in context, the cost is small, but the description adds no meaning beyond the bare 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?

States a concrete debugging action ('Step into the current call') with a specific verb and resource. It's clearly distinguishable from siblings like step_over and step_out by standard debugger semantics, though the description never explicitly contrasts itself with 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?

Usage is implied by the nature of step-into, and it does name wait_for_stop as the follow-up to block until the step completes. However, it never states when to choose step_into over step_over/step_out, leaving that inference to the agent.

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 delivers real behavioral detail: a ~5s wait, a success response with state "running" and pending:true, and the eventual transition to "paused" when the step finishes. It omits error behavior (no active session, not stopped, invalid frame) and any permission/session-state prerequisites.

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 action is front-loaded in the first sentence, and the remaining clauses cover timeout behavior and the follow-up tool with no filler. The nested em-dashes and parentheticals make it dense and slightly harder to scan than necessary.

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?

Return-state semantics are well covered despite the absence of an output schema, which is a meaningful strength. However, for a code-execution mutation with no annotations and no documented parameter, missing prerequisites (session must exist and be paused) and failure modes leave gaps an agent would need at call time.

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% — sessionId is a bare string with no documented meaning — and the description never mentions the parameter at all. The agent must infer that sessionId identifies the debug session to step, which is plausible but unstated.

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?

Opens with a specific verb+resource: "Step out of the current function," which is inherently distinct from step_over/step_into/continue_execution siblings. It never explicitly contrasts itself with those siblings, so the agent must rely on debugger knowledge to confirm the distinction.

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?

Gives concrete context for use (stepping out of a possibly long-running function body) and names the alternative for blocking behavior — "call wait_for_stop to block until then." It does not state preconditions such as requiring the session be paused in a frame, nor when to prefer step_over/step_into.

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 so well: it discloses the ~5s wait, the success-with-state-'running'/pending:true return on timeout, the fact that the step remains in effect, and the session transition to paused on completion. It omits prerequisites (e.g. session must be paused) and error behavior for invalid sessions.

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 core action is front-loaded in the first clause, followed by the timeout caveat and recovery options. The parenthetical is dense but every part addresses a real agent decision; no filler.

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 one-parameter stepping tool with no annotations or output schema, the description covers the main behavioral edge case (long-running step) and the resulting session states. It lacks only precondition and failure-mode information.

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%, so the description should compensate, but it never mentions sessionId. The single parameter is self-descriptive by name, which limits the harm, but the description adds no meaning 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?

States a specific verb and resource ('Step over the current line'), which an agent can map to standard debugger semantics. It does not explicitly contrast with siblings like step_into or step_out, so the key distinction (not entering function calls) is left implicit.

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 implied by the debugger stepping context, and it names wait_for_stop and pause_execution as alternatives when a step is pending. It does not say when to choose step_over over step_into, step_out, or continue_execution, nor what session state is required.

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 does meaningfully disclose idempotent behavior ('succeeds as a no-op if not exposed') and an important destructive side effect (disconnecting IDE clients). It does not cover permissions, error cases, or return behavior, so it stops short of full transparency.

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 tight sentences, front-loaded with the primary action before the idempotency caveat. Every clause earns its place with no filler.

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 single-parameter tool with no annotations and no output schema, the effect and no-op guarantee are covered, but parameter meaning and error/return behavior are absent. Adequate but with clear 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% and the description never mentions sessionId or its expected format/source. It must compensate for the coverage gap and does not, leaving the single parameter entirely defined by the bare schema 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?

States a specific verb (close) and resource (the session's DAP mirror endpoint), plus a concrete side effect (disconnecting attached IDE clients). It is implicitly the inverse of the sibling expose_session, so an agent can place it immediately.

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: the no-op note tells you it is safe to call regardless of state, but there is no explicit when-to-use framing or reference to expose_session as the counterpart. It does not state prerequisites or when to prefer an alternative.

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 exist, and the description carries the full burden well: it explains immediate-return cases (already paused, already terminated with exitCode), the meaning of the 'note' field, and that a timeout returns state 'running' with pending:true while nothing is cancelled and breakpoints/exception filters stay armed. That is exactly the behavior an agent needs to reason about retry loops.

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 core purpose is front-loaded, but the body is a dense run-on paragraph with nested parentheticals (state, lastStop, note clauses) that is harder to parse than it needs to be. The information mostly earns its place, but the packing reduces scannability.

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 output schema and no annotations, the description supplies the return-state vocabulary (paused/running/terminal, pending, note, exitCode, location) and the timeout contract. Only the sessionId parameter is left unexplained, which is a minor gap.

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%: the timeout parameter is documented in the schema itself, and the description reinforces its meaning ('if neither happens within the timeout it answers state running with pending:true'). sessionId is undocumented in both places, though it is self-evident in a debug-session API. Adequate but not compensating 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?

States a specific verb and effect: 'Block until the session next pauses or ends, then say why and where.' This is clearly a blocking wait, distinguishable from continue_execution (which does not wait), pause_execution, and list_debug_sessions by name.

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?

Explicit when-to-use: after continue_execution and whenever a tool answers pending:true. Explicit when-not: don't poll list_debug_sessions. Also names the alternative (pause_execution) for interrupting a still-running session.

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