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

Annotations already mark this as destructive, but the description adds useful behavioral detail: it can enable the inspector via pid, runs the target as the MCP user, enforces loopback, and returns a sessionId. This goes beyond the annotation flags and helps the agent understand the side effects and safety boundary.

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 compact and front-loads the essential action and return value. Each sentence contributes: attachment mode, side-effect caveat, tool distinction, and security constraint. The mention of evaluate is somewhat adjacent to debug_attach but still helps clarify the tool's boundary.

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 five optional parameters, 100% schema coverage, no output schema, and no required fields, the description covers the key operational details: what it returns, how to specify a target, loopback enforcement, and the trust requirement. It could state the selection precedence among wsUrl, host+port, and pid more explicitly, but it is largely 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?

Schema description coverage is 100%, so the parameters are already well documented. The description adds some grouping value by naming the three attachment modes (wsUrl, host+port, pid), but it does not need to repeat schema details. This is a solid baseline-3 score for parameter semantics.

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 action ('Attach to an existing Node inspector'), the target resource, the loopback scope, and the return value ('return a new sessionId'). It also references sibling tools like launch and evaluate in a way that distinguishes this attachment action from process launch and JS evaluation.

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 clearly frames when this tool applies: when there is an existing Node inspector to attach to, and it lists the accepted attachment routes. It contrasts with launch and evaluate, which helps route to siblings, though it does not explicitly say 'use debug_launch when you need to start a new process' as a direct exclusion.

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?

Annotations already indicate this is not read-only, and the description adds useful behavioral detail: it returns immediately and behaves differently based on the target state. It does not describe what happens if the target is in neither state or what the return value means, but the non-blocking behavior is a meaningful 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?

Three short sentences deliver the action, the return behavior, and the follow-up tool recommendation with no wasted words. The most important behavior 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 simple debugger continuation tool, the description covers the start/resume distinction, immediate return, and the next step. Minor gaps like error handling and return value format are left out, but the schema and annotations already cover enough 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?

Schema coverage is 100%, and the sessionId parameter already has a full description in the schema. The tool description adds no parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool starts an isolate in 'awaiting_start' or resumes a paused target, so the agent knows the core action and resource. However, it does not distinguish itself from the sibling debug_resume, which likely also resumes paused targets.

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 tells the agent when to call it ('if still awaiting_start' or 'resume a paused target') and gives a direct follow-up instruction to use debug_wait_for_pause after an expected breakpoint. It does not explicitly contrast it with debug_resume or other alternatives.

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?

Annotations already indicate destructive, non-read-only, and idempotent behavior. The description adds nuance by explaining exactly what gets killed and under what conditions (launch vs attach, terminate flag), going beyond the raw annotations without contradicting them.

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 concise sentences with the primary action ('Close one session, or all sessions if all=true') front-loaded, followed by the key behavioral nuance. No redundant phrasing.

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 all critical aspects: single vs all sessions, default termination behavior, and the terminate flag. The sessionId requirement is already in the schema. Adequate for a 3-parameter tool with no output schema.

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 parameters are already documented. The description adds value by explaining the default for terminate (true for launch, false for attach) and clarifying the all flag, which enriches understanding beyond the schema's descriptions.

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 tool's function: 'Close one session, or all sessions if all=true.' It also distinguishes behavior for launched vs attached processes, which differentiates it from sibling debug tools that pause, step, or continue.

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 provides context on default behavior (kills launched processes, leaves attached running unless terminate=true), which guides when to use it. However, it does not explicitly name alternative tools or state when NOT to use it, though the context makes the purpose evident.

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?

Annotations already state destructiveHint=true and readOnlyHint=false, and the description adds meaningful behavior beyond that: expression evaluation runs as the MCP user, the inspector is bound to 127.0.0.1, and evaluation switches call-frame vs runtime mode depending on paused state. This gives useful context for safety and invocation without contradicting the annotations.

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 compact and front-loaded with the core operation before switching to mode details. Each sentence earns its place: the mechanics, the security warning, and the launch comparison all add distinct value without 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?

The description and schema cover invocation constraints well, and the security caveat is valuable. However, there is no output schema and no description of what the tool returns for a successful evaluation, exception details, or error shape, which is especially relevant for an expression evaluator. This is a clear gap, but it is partially mitigated by the surrounding annotations and schema coverage.

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 explains sessionId, expression, and callFrameId. The description does not add significant parameter-level meaning beyond matching callFrameId to the paused-mode behavior. Baseline 3 is appropriate because the structured schema carries most of the parameter documentation burden.

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?

It does not repeat the tool name or rely on the title alone; the description gives a concrete operation and differentiates the tool's core purpose.

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 explicit routing context: it says "Uses Debugger.evaluateOnCallFrame when paused, otherwise Runtime.evaluate," which tells the agent when one mode is used. It also gives a clear safety constraint: "Only use on a trusted local workspace." It does not enumerate all sibling exclusions, but it names launch as the alternative for running a full process.

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?

Annotations already signal read-only/non-destructive behavior, lowering the bar. The description adds useful behavioral context: output is captured across stdout, stderr, and console API entries, and reads are cursor-based for incremental retrieval. No contradiction with annotations and no hidden side effects suggested.

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 convey the tool's purpose and the key incremental-read mechanism. Every clause is informative; no filler or repeated schema content.

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 tool with 2 optional parameters, fully documented schema, and no nested objects, the description plus schema provides all needed information. It defines what is read, how to paginate via cursor, and the sessionId condition is covered by the schema. An output schema is absent, but the return contents ('entries') and cursor semantics are sufficiently clear.

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%: both cursor and sessionId already explain their meaning. The description adds only that the cursor comes from a previous response, which modestly supplements the schema without needing to repeat parameter details.

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 identifies a specific verb ('Read'), a clear resource ('captured stdout, stderr, and Runtime.consoleAPICalled entries'), and the unique role of the tool among the sibling debug_* tools. It is not a tautology and tells an agent exactly what output stream it retrieves.

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 clear context: it is the tool for reading captured program output. It also states how to do incremental reads by passing the cursor from the previous response. It does not name an alternative or explicitly say when not to use it, but the resource definition makes the use case unambiguous alongside 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 annotations already marking this as read-only and non-destructive, the description adds minimal extra behavioral context. It does add the requirement for a paused target and the 1-based line numbering convention, but it does not clarify failure modes (e.g., what happens if no target is paused) or whether the stack is returned in any specific order. This is adequate but not 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?

The description is extremely concise: two short sentences that are front-loaded with the core purpose ('Return the current call stack'), followed by essential usage conditions. Every sentence earns its place, and there is 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 simple inspection tool with a single optional parameter, the description is nearly complete. It covers the purpose, the key precondition (paused target), and a detail (1-based lines) that could affect interpretation. It doesn't explain return format or error conditions, but given the lack of an output schema and the simplicity, it provides enough for an agent to use it 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?

The schema already fully describes the only parameter ('sessionId'), so the description doesn't need to elaborate. However, the description provides useful context that the session must be paused, indirectly clarifying that the sessionId must refer to a paused session. This adds value beyond the schema's field-level description.

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 tool returns the current call stack, a specific resource, and includes a critical prerequisite (requires a paused target) and a key detail (1-based lines). This distinguishes it from sibling tools that manipulate execution or breakpoints, and the purpose is immediately clear even 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?

The description provides a clear prerequisite ('Requires a paused target'), which implicitly tells the agent when to use it (after a pause) and when not to (during running execution). It does not explicitly name alternatives, but given the many sibling tools, this context is sufficient, as it directly implies the tool is for inspection during paused states only.

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?

Annotations already mark the tool as read-only and non-destructive, and the description adds substantial behavioral detail: default 32-property preview, cursor pagination, overflow/已折叠 truncation markers, [Circular]/已回环 cycle markers, and scope omission behavior. This is exactly the kind of context agents need beyond annotations.

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 dense but well-organized, front-loading the core action and then efficiently covering preview behavior, expansion, scope limitations, and the paused-target requirement. Every sentence contributes actionable information without 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 read-only inspection tool with optional parameters and no output schema, the description covers the critical behavior: what it inspects, how previews work, how to page/expand, scope omissions, and the paused-target precondition. An agent has enough context to select and invoke it 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?

All 7 parameters are documented in the schema, so the baseline is 3. The description adds value beyond the schema by explaining cursor paging, preview truncation behavior, expansion via objectId from previous results, and how includeGlobal/scopeIndex affect scope inclusion.

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

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

The description uses a specific verb and resource: 'Inspect locals/closures on a paused frame, or expand an objectId from a previous result.' This clearly distinguishes the tool from related siblings like debug_evaluate and debug_get_stack by describing exactly what it operates on.

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 clear context and conditions: it requires a paused target, and it explains that global/script scopes are omitted unless includeGlobal or scopeIndex is set. It does not explicitly name sibling alternatives or when-not conditions, but the intended usage is clear.

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?

Annotations already indicate destructiveHint=true, and the description adds substantial context: 'Runs the target as the MCP user,' 'Inspector is bound to 127.0.0.1,' and 'User code does not run until...' It also discloses auto-attach of children. No contradiction with annotations; the description enriches the safety and behavioral profile beyond the structured metadata.

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 dense yet efficient. It front-loads the core action, then covers cwd behavior, execution gating, breakpoint advice, module injection, child attachment, parallel usage, user context, differentiation from evaluate, security, and inspector binding—each sentence adds value with no fluff.

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 complex tool with 12 parameters, nested objects, and no output schema, the description explains the workflow, return value (sessionId), security constraints, and execution semantics. It could mention how to retrieve output (via debug_get_output) but that is a sibling tool and not strictly necessary. Overall, it is complete enough for correct usage.

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 parameters are well-documented. The description adds minimal param-specific meaning beyond the schema; for example, it restates the cwd default already present in the schema and mentions require/import/loader injects but does not explain syntax or resolution beyond schema descriptions. 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?

The description opens with a clear verb and resource: 'Spawn a Node program under --inspect-brk=127.0.0.1:0 and return a new sessionId in awaiting_start.' It also explicitly differentiates itself from debug_evaluate ('launch executes a process; evaluate runs JavaScript inside it'), making it unambiguous among 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?

The description provides clear usage context: it states the execution is paused until debug_continue/resume/wait_for_pause, advises setting breakpoints before continuing, and mentions parallel launches. It cautions 'Only use on a trusted local workspace.' However, it does not explicitly contrast with debug_attach (for existing processes), relying on the verb 'spawn' to imply new-process 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?

The description is consistent with the readOnlyHint=true and destructiveHint=false annotations. It adds no behavioral detail beyond the annotations, such as what is returned or whether the session must be paused, but for a simple read-only listing operation the annotations already cover the core safety profile.

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 short sentence that front-loads the operation and object; there is no redundant restatement of the tool name or title. 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?

Given the low complexity, a single optional parameter, and annotations that establish the read-only behavior, the description is largely sufficient. The main omission is that it does not describe the shape of the returned breakpoint list, and there is no output schema to fall back on.

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 sessionId parameter is already documented with its source ('from debug_launch/debug_attach') and when it is required ('when more than one session is live'). The description adds no parameter-level meaning, so it stays at the 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 verb ('List) and resource ('breakpoints in a session'), so the tool's purpose is unambiguous. It doesn't explicitly differentiate from sibling list tools like debug_list_scripts or debug_list_sessions, but the named resource is distinct.

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 such as debug_list_scripts or debug_list_sessions, and no exclusions or prerequisites. The session context is only implicit in the phrase 'in a session'; the schema's note about multiple sessions is not part of the 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?

Annotations already indicate read-only, non-destructive behavior, so the description's addition of what 'parsed' includes (entry modules, required modules, Babel plugins, node internals) adds meaningful behavioral scope beyond the structured data. No contradiction exists.

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 compact and front-loaded, with the core purpose in the first sentence and a practical usage hint in the second. Every phrase adds value and there is no redundant or filler content.

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 optional parameter, the description is complete: it defines what is listed, explicitly mentions the file-url use case, and annotations cover the safety profile. No output schema exists, but the purpose and expected utility are clear enough 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 optional parameter sessionId is fully documented in the schema with its own description. The tool description does not add further parameter guidance, which is acceptable given 100% schema coverage, so the 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?

The description clearly identifies the action ('List scripts') and the specific resource ('scripts the inspector has parsed'), with concrete examples of script categories. This distinguishes it from sibling debug tools like debug_list_breakpoints or debug_list_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?

Explicitly states a concrete use case: 'Use this to find the file URL to break in an extension.' This gives an agent clear context for when to invoke the tool, though it does not discuss when not to use it or name alternatives.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context: it scopes the listing to 'this MCP connection' and enumerates the output fields, which helps the agent understand what to expect. It doesn't describe pagination or ordering, but for a simple list operation that's acceptable.

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, tightly packed sentence that front-loads the action and scope, then lists the output fields. No filler or redundancy. 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 parameterless, read-only list operation, the description provides all essential information: what it lists, the connection scope, and the fields returned. Annotations cover the safety aspect, and there is no output schema to require return-type documentation. Nothing essential 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 has zero parameters, so the schema is trivially 100% covered. The description adds value by listing the returned fields, which serves as implicit documentation of the output. This exceeds the baseline expectation for a no-parameter tool.

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 'debug sessions', and specifies the exact fields returned (sessionId, state, pid, program, label). This unambiguously distinguishes it from sibling tools like debug_list_breakpoints or debug_list_scripts, which target different resources.

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 implicitly signals this is the go-to tool for enumerating sessions on the MCP connection. It doesn't explicitly name alternatives or exclusions, but given the sibling set and the tool's straightforward purpose, the usage context is self-evident. A brief mention of when to use it over other list tools would elevate it, but the intent is clear.

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 adds some behavioral context beyond the annotations by noting the snapshot-return behavior when already paused and the action of requesting a pause. However, it does not disclose whether the tool waits for the pause to happen, what happens when the target is not already paused, or the role of timeoutMs in the waiting behavior.

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 two short sentences with no filler. The core purpose is front-loaded in the first sentence, and the second sentence adds a distinct behavioral detail that is not redundant with the schema or annotations.

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 tool with fully documented optional parameters, the description is minimally adequate. However, there is no output schema, and the description only specifies the return value in the already-paused case, leaving the non-paused behavior and waiting semantics implied. It also lacks routing guidance among the many debugger sibling tools.

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

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

The input schema already documents both sessionId and timeoutMs with clear descriptions, and schema coverage is 100%. The description adds no additional parameter-level meaning, so the baseline score 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 action and resource: 'Request Debugger.pause.' It also adds a useful behavioral detail about returning the current snapshot if already paused. It does not explicitly differentiate from siblings like debug_wait_for_pause or debug_resume, so it misses the top score.

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 no explicit guidance about when to use this tool versus alternatives such as debug_wait_for_pause or debug_resume. The phrase 'if already paused' hints at a state condition but does not explain when an agent should choose this tool over its 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?

Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds that the id is returned from debug_set_breakpoint, which is useful context but does not disclose additional behavioral traits like what happens if the id doesn't exist or whether the operation is reversible beyond what annotations imply.

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 conveys the action, the resource, and the key detail about the id source. No wasted words, and the most important information 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 simple tool with two parameters and annotations covering idempotency and destructiveness, the description provides the essential context (id origin). It doesn't address error handling or return values, but given the low complexity and the lack of an output schema, the definition is sufficiently complete for an agent to call it 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 100%, so both parameters are documented. The description adds meaningful context for the id parameter by specifying its source (from debug_set_breakpoint), which helps the agent understand how to obtain a valid value. No extra semantics for sessionId, but it's already well-described in 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?

The description clearly states the action (Remove) and resource (breakpoint), and specifies the id comes from debug_set_breakpoint, distinguishing it from sibling tools like debug_list_breakpoints or debug_set_breakpoint. The purpose is unambiguous.

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

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

The description implies the tool is for removing a breakpoint by its id, but it does not explicitly state when to use it versus alternatives, nor does it mention conditions like sessionId requirements or cases where removal might not be appropriate. The id source is a helpful hint, but no exclusion criteria 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?

Annotations already indicate destructive behavior, but the description adds substantial detail: it kills the debuggee, disconnects/reconnects CDP, reapplies breakpoints, and preserves both sessionId and the MCP connection. This goes well beyond the annotation and gives the agent a precise mental model of side effects.

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 concise sentences capture all essential behavior without repetition or filler. The mode-specific breakdown is front-loaded and easy to parse.

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 destructive restart operation, the description fully covers both launch and attach paths, explains reapply behavior, and clarifies what persists. No output schema is present, but the description provides the critical state-preservation context needed to call the tool 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 description coverage is 100%, so the schema already documents sessionId and notes when it is required. The description's mention that sessionId is unchanged is useful state information, but it does not add meaning to the parameter itself beyond what the schema provides.

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 identifies the operation as restarting the debuggee and explicitly breaks down what happens in launch mode versus attach mode. This distinguishes it from sibling commands like debug_launch, debug_attach, and debug_disconnect because it names concrete sub-actions.

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 explicitly name alternatives or state when not to use the tool, but the 'For launch:' and 'For attach:' structure gives clear contextual guidance. The statement that sessionId is unchanged and the MCP connection stays up also helps differentiate this from a full disconnect/relaunch flow.

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?

Annotations already indicate a non-read-only, non-destructive operation. The description adds valuable state-specific behavior: from awaiting_start it starts the isolate, and it waits for the next pause. It does not cover return behavior or side effects, but with annotations present, this is adequate.

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 concise sentences with the core action front-loaded. The state-specific note is useful and compact, with no redundancy or fluff.

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?

Despite having no output schema, the description does not hint at return behavior or disambiguate from closely related siblings like debug_continue and debug_wait_for_pause. The operation is explained, but the sibling ambiguity leaves an agent unsure about correct tool selection.

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 both sessionId and timeoutMs are fully documented in the schema. The description adds no parameter-specific meaning, so the baseline score of 3 is appropriate.

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

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

The description states the tool starts or resumes execution and waits for the next pause, which is a clear action. It does not explicitly distinguish from similar siblings like debug_continue or debug_wait_for_pause, so it lacks sibling differentiation, but the core purpose is specific.

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 provides a clear context: 'Use for scripted stepping through breakpoints.' This is explicit usage guidance. However, it gives no alternatives or exclusions, leaving the decision between debug_resume, debug_continue, and debug_wait_for_pause somewhat ambiguous.

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?

Annotations only state readOnlyHint=false and destructiveHint=false, so the description legitimately carries the burden of explaining semantics. It adds real behavioral detail beyond the schema: source-map remapping behavior, 1-based line/column convention, and the fact that logMessage interpolates {expr} and does not pause. There is no contradiction with annotations.

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 compact and front-loaded with the core action, then packs high-value details into a few short sentences. Nothing is redundant or filler, though the density of the source-map sentence could be streamlined. It earns a strong score without being maximally minimal.

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 debugging tool with full schema coverage and no output schema, the description plus schema are sufficient for an agent to call the tool correctly. It covers the non-obvious file resolution rule, source map remapping, coordinate base, and logpoint behavior. It only lacks an explicit note about when sessionId is required, but that is already in the schema.

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 baseline is 3. The description does restate some schema details (file resolution, 1-based line) but adds minimal new parameter semantics beyond what the schema already documents. It does not explain the condition parameter or sessionId semantics beyond the schema, so it stays at the 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 opens with a specific verb and resource: 'Set a line breakpoint with Debugger.setBreakpointByUrl.' It clearly distinguishes this from siblings like debug_remove_breakpoint and debug_list_breakpoints by scoping to line breakpoints and explicitly mentioning the CDP method. The file resolution model and logpoint variant add further precision.

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

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

The description implies when to use the tool – when you need to set a line breakpoint or a logpoint, and it gives useful context about file paths, package specifiers, source maps, and 1-based coordinates. However, it never explicitly contrasts itself with alternatives such as conditional breakpoints vs. debug_pause/debug_continue, or when sessionId is needed. Usage guidance is clear but not explicit about when-not-to-use.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds concrete behavioral details about the return payload (pid, WebSocket URL), which is valuable beyond the annotation. It does not contradict the read-only nature.

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 primary action and outputs. No wasted words or redundancy with schema/annotations. Efficient and 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?

For a read-only status retrieval with one optional parameter and no output schema, the description covers the essential return fields and parameter logic. It lacks explicit error-handling notes, but given simplicity and annotation coverage, it is sufficiently complete for an agent to invoke 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 100%, and the schema already describes sessionId as 'Session id from debug_launch/debug_attach. Required when more than one session is live.' The description adds a practical tip ('Omit sessionId if only one session is live') that complements the schema, providing extra context for parameter usage.

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 tool returns a single session's status with specific fields (idle/connecting/paused/running/closed, pid, inspector WebSocket URL). It distinguishes its role from debug_list_sessions by focusing on details of one session, though it doesn't explicitly name an alternative. The verb and resource are specific.

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 a conditional usage instruction ('Omit sessionId if only one session is live') which is helpful for parameter handling, but it does not explain when to choose this tool over sibling tools like debug_list_sessions or debug_get_stack. Usage context is implied but not 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?

Annotations already indicate readOnly=false and destructive=false. The description adds that the tool advances into the current call and returns a new pause snapshot, which is useful behavioral context. However, it does not disclose preconditions, side effects on execution state, or potential blocking behavior when the target is not paused.

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

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

A single sentence with no filler: "Step into the current call and return the new pause snapshot." The core action is front-loaded and every word adds meaning.

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 the core action and the returned pause snapshot, and sessionId is adequately documented in the schema. However, with no output schema and no description of timeoutMs behavior or the requirement to be in a paused state, the definition is not fully complete for reliable invocation in all cases.

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%: sessionId is documented in the schema, but timeoutMs is not. The description does not explain the timeoutMs parameter or clarify when sessionId is required, so it fails to compensate for the missing schema documentation.

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

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

The description uses a specific verb and resource: "Step into the current call," and specifies the result: "return the new pause snapshot." This clearly conveys what the tool does and differentiates it from siblings like debug_step_over and debug_step_out based on the stepping semantics.

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 given about when to prefer debug_step_into over debug_step_over or debug_step_out, and no exclusions or alternative suggestions are mentioned. The intended usage is only implied by the tool name and the phrase "step into," leaving the agent to infer the decision context.

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?

Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool is known to be non-read-only and non-destructive. The description adds that it 'return[s] the new pause snapshot,' which implies execution pauses, but it does not disclose side effects such as whether stepping out will terminate if already at top level, or whether the session state changes beyond the snapshot. Some behavioral context is provided, but not comprehensive.

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 that front-loads the primary action ('Step out of the current function') and states the return value. There is no filler or redundancy. It is appropriately sized for a simple debug operation.

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

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

The tool has no output schema, so the description should explain the return value in more detail. 'Pause snapshot' is vague; an agent might not know its structure or content. It also does not mention that a debug session must be active or that it applies to the currently paused frame. Given the low complexity (2 optional params) and minimal annotations, the description is adequate but leaves key operational details implicit.

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 schema covers sessionId (with a description) but leaves timeoutMs undocumented (50% coverage). The tool description does not mention either parameter, so it adds no semantic value beyond the schema. Since timeoutMs is not described anywhere, the description fails to compensate for the schema gap, leaving the agent to guess its meaning or default 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 states a specific verb ('Step out') and resource ('current function'), and clearly indicates the outcome ('return the new pause snapshot'). It is distinct from sibling tools like debug_step_over and debug_step_into because 'out' implies exiting the function, which is unambiguous. No tautology; it adds meaningful information.

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 no guidance on when to use this tool versus alternatives like debug_step_over or debug_step_into. It does not mention conditions, prerequisites (e.g., an active debug session), or when not to use it. The usage context is only implied by the name and sibling set, which is insufficient for an agent to choose correctly.

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?

Annotations already indicate a non-read-only, non-destructive operation. The description adds a useful detail by stating the result is a 'new pause snapshot' and that lines are 1-based, but it does not disclose timeout behavior, effects on breakpoints, or what happens if the target exits.

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 delivers the core behavior and return value, with the line-numbering note added as a compact clarification. There is 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 state-changing debugger control with two optional parameters and no output schema, the description covers the operation and return snapshot adequately. It could be more complete about what the snapshot contains and timeout/session behavior, but those are partially covered by the schema.

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 only 50%: sessionId is documented in the schema but timeoutMs is not, and the description contributes no parameter semantics. It does not compensate for the missing timeoutMs explanation.

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

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

The description clearly names the operation ('Step over the current statement') and what it returns ('the new pause snapshot'). It does not explicitly differentiate from the sibling debug_step_into/debug_step_out tools, so it misses the top criterion for 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 behavior of stepping over a statement is implied, but there is no explicit guidance on when to prefer this over debug_step_into or debug_step_out, and no exclusions or prerequisites are stated.

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 discloses blocking behavior and the single-waiter constraint, which is useful. However, the readOnlyHint=true annotation contradicts the description's explicit action of starting the isolate and registering a waiter, both of which are state-mutating side effects.

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 concise sentences efficiently present the conditional state machine first, then the critical constraint. There is no filler; every clause contributes operational guidance.

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 core state-machine behavior is described, but for a blocking tool with no output schema it omits important details: timeout failure behavior, the structure of the 'current snapshot', and what happens if a second waiter is attempted. These gaps leave an agent uncertain about return values and error cases.

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 schema already provides 100% parameter documentation for sessionId and timeoutMs, including defaults and conditions. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description defines a state-dependent wait operation with explicit branches for awaiting_start, paused, and running, specifying the action for each. It clearly identifies the tool's role relative to debugger control, though it does not explicitly name sibling 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?

It explains when to call based on the current debugger state and adds practical guidance such as setting breakpoints before starting the isolate and noting the single-waiter-per-session constraint. It does not explicitly contrast with alternative tools, but the state-based conditions give clear context.

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