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 that the tool does not take ownership, that disconnect merely detaches and leaves the process running, and how breakpoint paths resolve against the server cwd. What is missing is any note on failure modes (e.g. what happens if nothing is listening on the port).

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 tight sentences, front-loaded with the connection requirement, then lifecycle behavior, then a path-resolution caveat. No filler and nothing that repeats the name or title.

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 tool with no annotations and no output schema, the description covers the important operational facts: how to connect, that it is non-owning, and detach semantics. It is nearly complete; only connection-failure behavior is unaddressed.

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 33% (just ws_url), so the description has to compensate and partly does by stating the default 127.0.0.1:9229 address, covering host and port. However, those defaults are also already declared in the schema, so the added meaning is marginal and ws_url's fallback semantics are left entirely to 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 (attach) and resource (a Node process already running under --inspect/--inspect-brk), and the phrase 'already started' cleanly separates it from the sibling launch, which presumably starts a new process. An agent can pick between attach and launch without opening either 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?

Gives a clear precondition for use: the target process must already have been started with `node --inspect` or `--inspect-brk`, with the default endpoint spelled out. It stops short of naming launch as the alternative when no such process exists, so it is clear context rather than a full when/when-not routing 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 meaningful work: it discloses that this call blocks for up to wait_ms, enumerates what counts as a new pause (breakpoint, exception, debugger statement), and gives the fallback return value "running". It does not cover error cases such as being called when the process is not paused, or whether "running" means still executing versus terminated.

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

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

Two sentences, zero waste. The action is stated first and the return contract (next pause vs "running") follows immediately; every clause 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 single-optional-parameter tool with no annotations and no output schema, the description covers the essential contract: what it does, that it blocks, and what it returns. The main gap is state/prerequisite handling (behavior when the target is not paused), which is the one thing an agent could get wrong.

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% and the wait_ms schema description already explains the timeout semantics, so the description repeats rather than extends that meaning. Baseline 3 is appropriate since the schema does the heavy lifting and the description adds only the framing of the wait as a blocking behavior.

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 pairs a specific verb ("Resume") with a specific resource ("the paused process"), so an agent knows this continues full-speed execution. It does not explicitly distinguish itself from the step_over/step_into/step_out siblings, which also advance a paused process, so the differentiation is implicit 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?

"Resume the paused process" implies the prerequisite state (process must be paused) but never states it as a condition, and gives no guidance on choosing this over step_over/step_into/step_out or wait_for_pause. Usage is therefore inferable but not 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?

With no annotations present, the description carries the full burden and does a solid job: it discloses that a launched process is killed while an attached one is merely detached and resumed if paused, plus that breakpoints persist across sessions. It does not cover state-loss risk, required session preconditions, or whether the tool errors when no session exists, 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?

A single tight sentence plus a short persistence note; the mode distinction is front-loaded and every clause carries information an agent needs (kill vs detach, resume behavior, breakpoint retention). 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 zero-parameter session-teardown tool with no output schema, the description covers the important behavioral outcomes and persistence of breakpoints. It omits edge cases such as calling it when no session is active, but nothing essential to invoking it 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 tool takes zero parameters, so per the rubric the baseline is 4. The description correctly introduces no parameter concepts, since there is nothing to configure, and the mode behavior is determined by session context rather than arguments.

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?

Names the specific action (ending a debug session) and splits it into its two real behaviors: killing a launched process vs detaching from an attached one. The mode-dependent framing tells the agent it is a terminal session operation, distinct from siblings like pause, continue, or set_breakpoint.

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

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

The description implies this is the way to end a session, but it never states when to call it versus siblings (e.g. does the agent need pause/continue first, or is it valid at any time?). Usage is inferable from the teardown semantics 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?

With no annotations, the description carries the full burden and delivers: it discloses that side effects are allowed and state can be mutated, that promises are awaited, that `require` paths are relative to the process cwd, and that a breakpoint hit inside the expression reports a pause and leaves the process paused. These are exactly the non-obvious behaviors an agent needs before invoking an eval 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?

Three dense sentences, no filler, with the core verb front-loaded and the paused/running distinction organized in parallel clauses. It is information-rich rather than padded, though the single paragraph is heavy for a two-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?

For a debugger eval tool with no annotations and no output schema, the description covers scope, side effects, async behavior, and nested-pause semantics thoroughly. It stops short of describing what happens when the expression throws or what the result payload looks like, which is the remaining gap given no output schema exists.

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%: `expression` has no schema description at all, so the description must compensate, and it does by explaining what the expression sees in each execution mode. It also adds the default frame value ('innermost') that the schema's bare 'Frame index to evaluate in (paused only)' does not provide.

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 opens with a specific verb+resource ('Evaluate a JavaScript expression') and immediately characterizes the execution context, which is the crux of the tool. It never names or contrasts with the closely related siblings (get_properties, get_scopes, get_output), so an agent must infer the boundary itself, keeping it below 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?

It clearly states the two contexts of use and what each implies: paused runs in the chosen frame (default innermost) with locals visible, running executes in global scope with `require` available. That is real when-to-use guidance, but there are no exclusions or explicit 'use X instead' routing against siblings like get_properties.

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 disclose two behaviors an agent needs: ordering ('newest last') and the seq-based incremental retrieval mechanism. It omits whether output is bounded/truncated and whether the call blocks, which are relevant for an output-retrieval tool, but the core behavioral traits are present.

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

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

Two sentences, front-loaded with what is returned, followed by the ordering guarantee and the incremental-retrieval hint. No filler, every clause carries information.

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

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

For a 4-parameter, no-required, no-annotation, no-output-schema read tool, the description covers content, ordering, and return shape (lines with seq), which substitutes for the missing output schema. The remaining gaps are limit defaults and truncation/buffering behavior.

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%: grep and since_seq are documented in the schema, while source (an enum) and limit are not. The description restates since_seq semantics but adds nothing for grep, source, or limit, so it 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 names a specific resource (process output) and enumerates exactly what is captured: stdout, stderr, console.* calls, and uncaught exceptions. That enumeration distinguishes it from siblings like get_stack, get_scopes, and get_properties without needing to name 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?

It gives one concrete usage pattern, 'pass since_seq to get only new lines,' which implies incremental polling. But it never states when to call this versus alternatives, nor any exclusions or prerequisites (e.g., whether the process must be paused/running), leaving usage largely inferred.

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 behavioral burden. It usefully discloses lazy expansion behavior ('nested objects get their own refs'), telling the agent the tool does not deep-traverse. But it says nothing about read-only safety, whether property access can trigger side effects (e.g. getters), depth or size limits, or the shape of the returned property list.

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, both front-loaded with the essential action and input provenance, and zero filler. The second sentence carries a distinct behavioral fact rather than restating the first.

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 must cover both behavior and results. It adequately covers input provenance and expansion semantics, but leaves the return value format (names/types/values) and any safety or side-effect considerations unstated for a debugger property-inspection call.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description goes slightly beyond the schema by identifying the concrete origin of the 'ref' value (the ⟨ref …⟩ markers emitted by get_scopes or evaluate), which is actionable provenance the schema's generic wording does not supply. It adds nothing for 'own_only', which the schema already documents including its default.

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 ('List the properties of an object') and names the two siblings that produce the required ref (get_scopes, evaluate), which lets an agent place it in the debug-inspection workflow. It stops short of explicitly contrasting itself with other inspection tools like get_output or get_stack.

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

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

The description implies the usage path (you must first obtain a ⟨ref …⟩ from get_scopes or evaluate, then call this), and the note about nested objects getting their own refs hints at recursive expansion. However, it never states when not to use it or what alternatives exist for viewing object state, so guidance remains implied rather than explicit.

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 must carry the full behavioral burden. It usefully discloses the return shape (variables with values, object values as expandable ⟨ref⟩), but it does not say the operation is read-only, that it has no side effects, or how include_global affects output size (that detail is left to 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 sentences, front-loaded with the core resource and scope enumeration, then the ref-expansion tip. No filler; every clause adds information.

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

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

For a simple two-parameter getter with no output schema and no annotations, the description is largely complete: it says what variables are returned, that values are included, and how object refs work. It could be fuller about read-only behavior and the optional global-scope expansion, but the schema covers the parameter details.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both the frame and include_global parameters are already fully documented in the schema. The description adds no parameter-level meaning beyond that, 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?

The description states a specific resource ('all variables visible in a frame') and enumerates the scope types (local, closure, block, module, plus `this`). It also distinguishes itself from the sibling get_properties by pointing to ref expansion, so an agent can tell what it retrieves without opening 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 gives clear workflow context: the frame index comes from get_stack, and object refs are expanded with get_properties. However, it does not explicitly state when to prefer get_scopes over a sibling like evaluate for inspecting values, nor does it name any when-not conditions.

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 does disclose the key trait — the result is only meaningful 'at the current pause' — which is real context beyond the schema. It says nothing about failure behavior when not paused, whether the result is a structured array or formatted text, or ordering (top frame first vs. last).

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 compact sentences: the first defines the payload and its fields, the second explains how the output is consumed. Nothing is padded and the core content is front-loaded.

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 must describe the return shape, and it does so concretely (frame index, function name, file:line:col) while flagging the pause precondition. The remaining gap is edge-case behavior when the debugger is not paused, which is minor for a no-argument read of current debugger state.

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 the baseline is 4 and there is no parameter semantics to document or omit. The description correctly adds nothing here rather than inventing inputs.

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 the exact resource (the full call stack) and enumerates the returned fields (frame index, function name, file:line:col), with the scope condition 'at the current pause'. This is enough to distinguish it from sibling readers like get_scopes, get_properties, and get_output, though the distinction is inferred from content rather than stated as an explicit contrast.

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 'at the current pause' implies the tool only makes sense while execution is stopped, and naming get_scopes/evaluate as consumers of frame indices hints at the downstream workflow. However, there is no explicit when-to-use statement, no stated prerequisite that the debugger must be paused, and no guidance on what to do if it is not.

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 the pause-at-first-line handshake, the resume condition tied to stop_on_entry, and the destructive side effect that any previous session is torn down. It stops short of stating permission requirements, whether existing breakpoints survive the teardown, or what a caller gets back.

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 tight sentences, each earning its place: the invocation form first, then the pause/resume lifecycle, then the teardown warning. Nothing is padded and the most important operational fact is front-loaded.

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 6-parameter, no-output-schema, unannotated launch tool, the description covers the launch and pause lifecycle well enough to call it correctly. The main residual gap is that with no output schema and no annotations, it never hints at the returned session state or how the torn-down previous session affects existing breakpoints.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so cwd, env, args, script, node_args and stop_on_entry are already fully documented in the schema, making 3 the baseline. The description echoes script, args and stop_on_entry but adds no syntax, defaults, or constraints beyond what the schema states.

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 concrete verb+resource ('Start `node <script> [args]` with the inspector attached') and the title reinforces the scope ('Launch a Node script under the debugger'). The word 'Start' implicitly separates it from the sibling 'attach', which implies binding to an already-running process.

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 context is implied by the lifecycle statement ('Any previous session is torn down first'), which signals that this is not additive to an existing session, but the description never explicitly says when to prefer launch over attach or when it is inappropriate to call. No exclusions or named alternatives are 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the shape of the returned records (ids, locations, conditions, resolution state, hit counts), which is the key behavioral question for a list tool, but says nothing about read-only nature, ordering, or whether disabled/unresolved breakpoints are included.

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 compact sentence that front-loads the resource and lists the returned fields. It is a fragment rather than a full sentence, which is terse but not wasteful.

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 parameters, no annotations, and no output schema, the description compensates by enumerating the returned fields, which is exactly what is missing structurally. It is close to complete for such a simple tool, though it omits any note on ordering or scope of results.

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 the baseline is 4. The description correctly implies an unfiltered, argument-free call, leaving no parameter ambiguity to resolve.

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 the resource (breakpoints) and enumerates what is returned, making the operation clearly distinguishable from siblings like set_breakpoint, remove_breakpoint, and set_exception_breakpoints. It lacks an explicit verb ('List'/'Return'), which keeps it 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?

There is no statement of when to use this tool versus alternatives, nor any prerequisites or exclusions. The operation is inferable from the name and the mutation-oriented siblings, but the description itself provides no routing 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?

No annotations are provided, so the description carries the full disclosure burden. It does add real behavioral detail beyond the name: the node: internals exclusion and the 'so far' temporal limitation. However, it never states that this is a read-only listing that does not mutate debug state, nor what the returned entries look like (paths only vs. ids).

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 resource and scope, followed by the motivating use case. No wasted words, though the second sentence could be tighter.

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

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

For a simple read-only listing tool with one fully documented parameter and no output schema, the description covers scope, exclusion rules, and purpose adequately. The main missing piece is confirming the read-only nature, which matters in a live-debug session.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the single 'filter' regex parameter is fully documented in the schema. The description adds nothing about parameter behavior, which is the correct baseline when the schema already does the work.

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 resource (source files the process has loaded) with a clear scope qualifier (excluding node: internals). This distinguishes it from sibling tools like get_stack and list_breakpoints, which report different runtime state, without needing to open 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?

The description gives one implied use case ('find the right path for a breakpoint'), which ties the tool to the set_breakpoint workflow, but names no alternatives and states no when-not-to-use condition.

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. It usefully discloses the trigger semantics (next JS execution) and that the result reports the stop location, but says nothing about timeout/error behavior, what happens if the process is already paused or not running, or any auth/permission requirements.

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 with zero filler, front-loaded on the action and the trigger point, with the outcome appended. Nothing to trim.

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

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

For a simple one-optional-param tool with no output schema, the description covers the action and the result ('report where it stopped'). It is nearly complete; only the precondition (a running process) and timeout outcome are unstated, though the timeout behavior is partly implied by the schema's wait_ms description.

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 a single optional parameter and schema description coverage is 100%, so the schema already documents wait_ms and its default/max plus the 'running' return on timeout. The description adds nothing about it, which matches the baseline 3 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?

States a specific verb ('interrupt') plus the resource and the exact trigger point ('at the next JS execution'), and adds a result ('report where it stopped'). It is clear enough to distinguish from stepping tools, but it never names or contrasts the near-identical sibling wait_for_pause, so the differentiation is only partial.

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 'at the next JS execution' implies the situation in which this tool applies, but there is no explicit when-to-use, no stated precondition (process must be running), and no routing to alternatives such as continue, step_over, or wait_for_pause.

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 of behavioral disclosure. 'Remove' implies mutation, but it says nothing about whether the debugger must be paused, what happens with an unknown or stale id, whether removal is idempotent, or what error/return behavior to expect.

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 waste; the essential contract is stated 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 one-parameter debugger mutation with no output schema, the description gives the core contract but omits failure modes and prerequisites. Adequate to invoke correctly in the common case, thin on edge behavior.

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 schema only declares an integer, so the description's statement that the id is 'returned from set_breakpoint' adds genuine semantic value about provenance. It stops short of describing id validity or lifecycle, but meaningfully compensates for 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 specific verb (Remove) and resource (breakpoint), and names set_breakpoint as the origin of the id, which separates it from siblings like list_breakpoints and set_breakpoint. Clear and unambiguous, though it doesn't explicitly contrast with list_breakpoints as an alternative source of ids.

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 mention that the id comes from set_breakpoint implies the workflow context, but there is no explicit when-to-use guidance, no note on how to discover ids (e.g., via list_breakpoints), and no exclusions 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 discloses non-obvious behavior: the breakpoint may be set on an unloaded file and resolves lazily, and the tool returns an id for later removal. It does not cover permissions, error cases, or required debug session state, but it adds meaningful context beyond 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?

Three tight sentences, front-loaded with the core action, followed by important behavioral notes and return information. No wasted words.

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

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

For a 3-parameter debugger tool with no output schema and no annotations, the description covers the essential behavior (deferred resolution) and return value, which compensates for the missing output schema. Minor gaps remain around error conditions and debug session prerequisites.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already defines file, line (1-based), and condition. The description adds little parameter-specific meaning beyond restating 'optionally conditional' and 'file:line', so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Set') and resource ('breakpoint at file:line'), making the tool's purpose immediately clear. It also references the complementary remove_breakpoint tool for the returned id, helping distinguish it from sibling breakpoint-management 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?

Usage is implied by the purpose and the note that 'The file may not be loaded yet; the breakpoint resolves when it is,' but there is no explicit when-to-use versus alternatives (e.g., set_exception_breakpoints) or exclusions. The return-value workflow with remove_breakpoint is helpful but narrow.

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 a genuine behavioral trait not present in the schema: the default mode of 'uncaught'. However, it omits whether a call replaces or adds to existing exception-breakpoint state, whether it affects all scripts, and what happens to a currently paused 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?

Two short sentences with the purpose front-loaded and the default surfaced immediately after. 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 single-parameter control tool with no output schema or annotations, the description covers purpose and default but leaves gaps: per-enum semantics and the replace-vs-accumulate behavior of repeated calls. Adequate but not 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?

There is one enum parameter with 0% schema description coverage, so the description must compensate. It explains the parameter's axis (pause on exception thrown) and reveals the default value 'uncaught', which the schema enum alone does not convey, but it never spells out what 'none' versus 'all' versus 'uncaught' each mean beyond the obvious naming.

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 ('Control') and resource ('whether the debugger pauses when an exception is thrown'), which is clearly distinguishable from the sibling set_breakpoint (line breakpoints). It does not explicitly name or contrast itself with that sibling, so it falls 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 note 'Default is uncaught' gives implied usage context, but there is no explicit when-to-use guidance, no statement of when to prefer this over set_breakpoint, and no mention of prerequisites or side effects on running sessions.

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. It discloses that this is a passive read of session state and enumerates the state dimensions returned, which is useful, but says nothing about error conditions (e.g., no active session) or whether the call blocks/waits.

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 tight sentence with no filler, and the most important dimension (active/paused state) is front-loaded. It reads as a return-value list rather than a purpose statement, but 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?

There is no output schema, so the description must describe returns — it does so by enumerating the state fields. For a zero-argument status tool this is nearly complete; only the no-session/error case and relationship to sibling getters are unaddressed.

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 the baseline is 4. The schema is empty and there is nothing parameter-related the description needs to compensate for.

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?

Names the resource (session) and enumerates the specific state it reports — active/attached, paused/running, breakpoint count, current stack. That is concrete enough to distinguish it from focused siblings like get_stack or list_breakpoints, though the phrasing is a noun list rather than a clear verb+resource statement.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as get_stack, get_scopes, or list_breakpoints even though the status output overlaps with them. The agent must infer context from the description alone.

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 behavioral burden. It does disclose a real trait beyond the schema — that async calls are followed — but says nothing about what happens when the current line has no callable function, what error/return state results, or that the target must be 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?

One sentence, front-loaded with the action, with the async caveat tucked into a parenthetical. Every word 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 single-parameter stepping command with no output schema and full schema coverage, the description supplies the one non-obvious behavioral fact (async following). The missing precondition about being paused is 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?

Schema description coverage is 100% and the single wait_ms parameter is fully documented in the schema, including its bounds and the 'running' return case. The description adds nothing about it, 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?

Specific verb plus resource: 'step into the function called on the current line' states exactly what happens, and the parenthetical clarifies the async case. Against siblings like step_over and step_out, the verb alone unambiguously separates the three stepping modes.

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 semantics of stepping into a call, but the description never states preconditions (the process must already be paused at a call site) or when to prefer step_over/step_out instead. No alternatives or exclusions are named.

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 discloses the core behavior (run to return and pause in caller) but omits edge cases such as what happens at the top frame, what is returned, or whether the process may remain running; the wait_ms schema partially covers the 'running' outcome.

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 front-loaded sentence with no wasted words. It is efficient, though its brevity leaves some behavioral gaps that a slightly longer description could close.

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 low-complexity stepping tool with full schema coverage, the description covers the essential action. However, with no annotations and no output schema, it could reasonably mention error conditions and the return behavior to be fully self-contained.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the single wait_ms parameter is already well documented in the schema, including its default, bounds, and 'running' return implication. The description adds no parameter meaning beyond that 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?

The description states a specific debugger behavior: run until the current function returns and pause in the caller. This is clear enough to distinguish it implicitly from step_over and step_into, though it does not name or contrast those siblings 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 usage is implied by the definition of stepping out of a function, but there is no explicit guidance on when to choose this over step_over, step_into, or continue, nor any caveats such as being at the top of the call stack.

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 core behavior (executes a line, pauses at the next line in the same frame). It omits the prerequisite paused state, what happens if the process is not paused, and the timeout/running-return semantics implied by wait_ms.

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; every word contributes to describing the stepping behavior.

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 and no annotations, so the description must stand alone, yet it omits precondition (must be paused), error/edge behavior, and the wait/timeout outcome. For a simple debugger step the core is conveyed, but a few operational gaps remain.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single wait_ms parameter is fully documented in the schema (including default and min/max). The description adds nothing about the parameter, so the baseline 3 for high coverage 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: executes the current line and pauses on the next one, with the scoping qualifier 'in the same frame' that behaviorally distinguishes it from step_into/step_out. It does not name those siblings explicitly, so an agent must infer the contrast from 'same frame' rather than being routed.

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 'same frame' phrasing implicitly signals this is the step that does not descend into calls, which is a useful usage cue. However, there is no explicit when-to-use/when-not guidance and no reference to alternatives like step_into, step_out, or continue, leaving 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. It does disclose the key behavior (blocking for up to wait_ms until a breakpoint/exception), which is useful, but it omits whether the call mutates any state, what happens if the process is not running, and any concurrency caveats.

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 that front-loads the core behavior (block up to wait_ms) and appends the triggering example. 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 single-parameter, no-annotation tool whose return semantics ('running' vs pause) live in the schema, this is nearly complete. Minor gaps remain around edge cases (process not running, repeated calls), but nothing critical to invoking it 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% and there is a single parameter fully documented with default, min, and max. The description only references wait_ms by name and adds no syntax or format detail beyond the schema, so the baseline 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 (block/wait) and resource (process pause/breakpoint or exception), and the name matches. It implicitly distinguishes itself from the sibling 'pause' (which actively pauses) by describing passive waiting, 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?

Provides a concrete usage scenario ('after you trigger an HTTP request against it from elsewhere'), which gives implied guidance. However, it offers no exclusions and does not contrast with alternatives like polling 'status' or the active 'pause' tool, leaving the choice to inference.

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