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

The description explains the phased behavior in detail: it starts with stack and small locals, expands only when symbols/exception state/variables are insufficient, and finishes with a full runtime report when needed. Since annotations already mark it read-only and idempotent, the description adds meaningful behavior context beyond static hints.

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

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

Three sentences with no filler: behavior, usage condition, and exclusion are each covered in a focused, front-loaded manner. Every sentence 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?

With full schema parameter coverage, an output schema, and strong annotations, the description provides the missing behavioral and usage context. An agent has everything needed to decide when to call it and understand how it behaves.

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 covers 100% of parameter descriptions, including forceFull, sessionId, and maxVariables. The description does not add parameter-level detail, but because the schema is complete, 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 identifies a specific verb and resource: 'Collect runtime evidence' in progressively richer bounded phases. It also explicitly contrasts itself with requesting a maximal snapshot and with deliberate deep inspection, which distinguishes it from sibling tools like debug_snapshot and debug_runtime_report.

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 explicit guidance on when to use the tool ('when token/DAP cost matters or the amount of evidence needed is unknown') and when not to use it ('Do not use it to replace deliberate deep inspection when the required evidence is already known'). This is direct and actionable.

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 carry destructiveHint=true, and the description adds meaningful behavior beyond that: the mechanism (combining a stopped snapshot with repeated watchpoint tracing, which implies resuming the target), the bounded stop budget, and the epistemic caveat that an observed writer is not automatic proof of root cause. No contradiction with the annotations; this context is genuinely additive.

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

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

Three sentences with the core purpose front-loaded, followed by usage criteria, then exclusions and a result-interpretation caveat. Every sentence earns its place; there is no filler and no repetition of what the schema or annotations already declare.

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 tool with a full output schema, 100% parameter coverage, and annotations, the description covers purpose, mechanism, usage window, hard exclusions, and a caveat about interpreting results. The only minor gap is that side effects beyond 'unsafe-to-resume' are not elaborated, but destructiveHint already flags the safety profile.

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 all five parameters (name, maxDepth, maxStops, sessionId, timeoutMs) are fully documented in the schema. The description adds no per-parameter semantics beyond the schema, which meets the stated baseline of 3 but earns no extra credit.

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 pair ('Build a bounded consumer-to-writer evidence chain for one suspicious debugger-visible value') that is more precise than the title. It distinguishes the tool from siblings through its scope (bounded, single value, watchpoint-based writer tracing) and usage context (post-crash or differential evidence), so an agent can tell it apart from debug_find_writer or debug_this_crash without inspecting schemas.

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 an explicit when-to-use trigger ('after crash or differential evidence identifies a value whose runtime producers matter') and explicit exclusions ('Do not use it for frozen dumps or unsafe-to-resume targets'). It stops short of naming which sibling tools to use in those exclusion cases, so it is clear but not fully prescriptive about 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?

The description adds meaningful behavioral context beyond the readOnly/idempotent/non-destructive annotations: it discloses that comparison is semantic, that stack/locals/registers/exception/symbol/module evidence is compared, and that 'non-null raw address-only changes are marked unstable rather than causal evidence.' This tells the agent how results should be interpreted and reinforces that the tool observes rather than mutates sessions.

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

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

The description is three focused sentences. The first states purpose, the second gives usage context and the comparative scope, and the third provides an exclusion and directs preparation. Every sentence earns its place with no repetition of schema or annotation 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?

Given the rich input schema, output schema, and annotations, this description is complete for safe and correct invocation. It covers when to use, what is compared, how unstable address-only changes are treated, and what the tool must not be used for. No critical operational knowledge 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 description coverage is 100%, with both required session parameters and the nested snapshot object clearly documented. The prose description adds contextual framing but does not materially expand on the parameter meaning already present in the schema, so it stays at the baseline for high-coverage schemas.

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: 'Compare bounded runtime evidence from two existing stopped DAP sessions.' It then distinguishes the tool from single-session diagnostics by framing it for 'baseline or known-good versus candidate or failing differential debugging,' which cleanly separates it from sibling tools like debug_snapshot and debug_diagnose_stop.

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

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

It explicitly states when to use the tool: for differential debugging 'after both sessions have reached comparable stops.' It also gives clear when-not guidance: 'Do not use it to launch, resume, or alter either target; prepare both runtime states with the normal lifecycle tools first.' This directs the agent to alternative lifecycle tooling without ambiguity.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the bar is lower. The description adds value beyond those by stating that it 'does not change execution state', that it returns both a bounded snapshot and a derived diagnosis, and that it discloses collection limitations when optional debugger evidence is unavailable. This gives useful behavioral context beyond the structured 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 tightly structured: it front-loads the core purpose, lists the derived outputs, routes to the sibling alternative, and closes with read-only behavior and output scope. Every clause contributes, and there is no redundant repetition of the tool name or schema contents.

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 tool with 11 parameters, nested objects, no required parameters, and an output schema, the description covers the key operational context: the precondition ('already stopped'), the read-only guarantee, the distinction from debug_snapshot, and the bounded/limited nature of results. It does not enumerate parameter details, but the input schema fully covers those, so the description is sufficiently 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 schema already documents every parameter in detail. The description does not add parameter-specific semantics, but it does contextualize the optional evidence gathering and bounded results, which relates to the parameters. Baseline 3 is appropriate because the schema carries 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?

The description names a specific verb ('Diagnose'), a precise resource ('already stopped live or postmortem debug session'), and a concrete set of outputs (project-frame selection, crash classification, bindings, provenance, ranked hypotheses, fix plan). It also explicitly differentiates itself from debug_snapshot, so an agent can distinguish it from siblings without opening schemas.

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 a clear when-to-use condition ('when a debugger has captured the failure and you want...') and names the alternative (debug_snapshot) with the condition that selects it ('when only raw evidence is needed'). This is explicit routing guidance rather than 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.

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

Annotations already mark the tool as destructive, but the description adds valuable context: it ends the session, stops the adapter process, may terminate a live target with terminateDebuggee=true, and explicitly warns that runtime state can be destroyed. This meaningfully exceeds the annotation signal.

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

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

Three sentences, each earning its place: the first states the core operation, the second provides usage guidance, and the third warns about destructive behavior. No filler or redundant restatement.

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 two well-documented optional parameters, an output schema, and annotations already covering safety traits, the description covers purpose, appropriate usage, and destructive consequences. Nothing needed to invoke the tool 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?

Schema description coverage is 100%, so both parameters are already documented. The description adds some interpretation around terminateDebuggee's destructive potential, but the schema already explains the detach/preserve behavior, so the description provides only marginal added value.

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 ('End') and resource ('active DAP session') plus the local adapter process, making the operation's scope unambiguous. It is clearly distinct from siblings like debug_continue or debug_snapshot even without naming them.

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

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

The description gives explicit when-to-use and when-not-to-use guidance: use when debugging is finished or must be reset, and do not call when more runtime evidence is needed. It does not name an alternative tool, so it stops short of a full 5.

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 goes well beyond the annotations by explaining that the tool temporarily creates a watch, removes only that watch, never automatically continues through unrelated stops, and uses different mechanisms for DAP vs GDB 14/15. This gives the agent a clear model of side effects and safety boundaries.

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 three sentences with no filler: the first front-loads the core action, the second gives usage boundaries, and the third explains protocol behavior and cleanup guarantees. Every sentence adds distinct, necessary 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?

The description is complete for a complex tool with 11 parameters: it covers purpose, safe usage, exclusions, protocol differences, cleanup behavior, and the nature of the resulting stop. The schema and output schema fill in remaining structured details, leaving no critical gap for an agent deciding whether and how to call it.

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

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

Schema coverage is 100%, so the schema already documents all parameter meanings. The description adds protocol-level context such as DAP vs GDB behavior and the bounded watch fallback, but most individual parameter semantics are already fully captured in the input schema itself.

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 chain: temporarily watch a variable/expression, resume the target, and capture the first stop to identify the immediate writer candidate. It clearly distinguishes this from sibling tools by framing it as the corruption-provenance diagnostic and explicitly separating it from crash-dump use.

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 explicit when-to-use guidance: after a stopped-state diagnosis suggests corruption and runtime provenance is needed. It also provides explicit when-not-to-use guidance: not for crash dumps or when resuming is unsafe, though it does not name a specific sibling alternative to use instead.

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

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

The description adds important behavioral context beyond the annotations: it starts only the debugger adapter, never launches or resumes the crashed program, treats the dump as read-only, and returns a bounded initial snapshot. This complements the readOnlyHint/idempotentHint annotations and gives the agent a clear 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?

The description is compact and front-loaded: the action comes first, followed by usage context, safety behavior, and return scope. Every sentence earns its place with no filler or repetition.

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

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

For a 14-parameter tool, the description covers the key decision points: when to use it, what it does not do, what it returns, and how it differs from live-debugging siblings. The output schema and rich input schema cover the remaining detail, so 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?

Schema description coverage is 100%, so the schema already documents every parameter in detail. The description adds some high-level context about adapters, modules, and disassembly, but it does not substantially go beyond what the input schema already 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 states the specific action: opening a local core/minidump with a local debugger adapter and capturing bounded postmortem evidence. It also explicitly distinguishes this tool from live-debugging siblings like debug_run_to_stop and debug_this_crash, so an agent can select it confidently.

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 when-to-use guidance: use it when the failure is already recorded and no target process should execute. It also names alternatives for live reproduction, leaving no ambiguity about when this tool is appropriate versus 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 destructiveHint=true, and the description elaborates on the safety profile by warning that sampling perturbs scheduling and that results are not proof of application-level progress. This is valuable behavioral context beyond 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?

Three sentences with no filler: the first states what the tool does, the second gives the trigger condition, and the third gives the exclusion and caveat. Every sentence 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 probe tool with a rich output schema and annotations, the description covers what it does, when to use it, when not to, and its limitations. Nothing essential is missing for an agent 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?

Schema description coverage is 100%, so the schema already documents samples, threadId, sessionId, and intervalMs. The description reinforces the meaning of 'samples' and 'intervalMs' through 'resume/pause intervals', but it does not add substantial parameter-level detail beyond the schema.

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

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

The description starts with a specific verb and resource ('Sample a live target') and states the diagnostic goal: distinguishing no observed progress, same-frame execution movement, and probable busy loops. It clearly separates this probe tool from snapshot/hang-analysis siblings by framing it as a resume/pause sampling technique.

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 an explicit use case ('when a process appears hung but a single thread snapshot cannot distinguish blocking from spinning') and an explicit contraindication ('Do not use it when resuming the target is unsafe'). It also sets expectations that sampling perturbs scheduling and is not proof of progress.

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 cover read-only, idempotent, non-destructive safety. The description adds meaningful behavioral context: it requires a stopped target, includes normalized crash fingerprinting and Symbol Doctor status, correlates sanitizer stderr, and warns that heuristic outputs are not standalone proof.

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

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

Front-loaded with the verb, object, and scope, followed by a compact feature list a usage boundary, and a reliability caveat. Every sentence earns its place with no filler or redundancy.

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

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

Given a fully documented input schema, an output schema, and safety annotations, the description covers purpose, scope, usage constraints, and heuristic caveats. An agent has enough information to select and invoke 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 fully documents all parameters and defaults. The description does not add parameter-specific semantics beyond referencing related report components, matching the baseline for schema-heavy definitions.

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 action ('Create a shareable structured report'), a specific resource ('current stopped target'), and enumerates the report components. The detailed list clearly differentiates it from diagnostic siblings like debug_this_crash or debug_causal_trace.

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 clear context: 'Use it only for evidence-driven triage and issue handoff' and a strong boundary about not treating heuristic findings as proof. It does not explicitly name a sibling alternative, which keeps it just below a 5.

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?

It discloses target side effects beyond what annotations state: 'normal target side effects may occur before the stop,' and it explains the difference between launch and attach behavior. It also sets a boundary on the snapshot ('bounded snapshot only when a stopped event is captured') and states the 'already initialized DAP adapter' prerequisite. This aligns with and enriches the destructiveHint=true annotation.

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

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

Four sentences, each earning its place: core action, selection guidance, side-effect warning, and return summary. The most important information is front-loaded before the exclusion and return-value details.

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 tool with 6 parameters, nested schema, and an output schema, the description covers the action, prerequisites, side effects, return categories, and exclusions. Missing details such as individual parameter bounds are already covered by the schema, so no critical selection or invocation context is absent.

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?

With 100% schema description coverage, the schema already documents the parameters, so the baseline is 3. The description adds operational meaning for the request parameter (launch executes code, attach changes debugger control) and clarifies that snapshots are only produced on a stopped event, which is useful beyond the raw 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 states a specific action ('Run one live launch or attach... until the first stopped, exited, or terminated event'), identifies the resource (already initialized DAP adapter), and scopes the use case to deterministic runtime evidence. It clearly contrasts with postmortem dumps, distinguishing it from sibling debug_open_dump.

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 explicitly says when to use ('when you need deterministic runtime evidence from a reproduction') and when not to use ('do not use it for a postmortem dump or when executing/attaching to the local target is not authorized'). It does not name a specific alternative tool, but the postmortem exclusion effectively routes the agent away from debug_open_dump.

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 carry readOnlyHint=false and destructiveHint=true, so the description does not need to restate mutation/destruction. It adds useful behavioral context about session isolation and default-session backward compatibility. It does not spell out that closing can terminate the debuggee, but the schema's terminateDebuggee parameter covers that detail.

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 tight sentences with no filler. The first sentence names the actions and context; the second adds the critical sessionId routing caveat. 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?

Given 100% schema coverage, an output schema, and annotations covering the destructive profile, the description is sufficient for an agent to select and invoke the tool correctly. The only behaviors not described in prose are already captured in the structured fields.

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%, with meaningful descriptions for action, sessionId, and terminateDebuggee. The tool description adds routing context but no new parameter-level semantics, 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 ('list, create, or close'), a specific resource ('isolated DAP sessions'), and positions the tool as the session-lifecycle manager that must be used before routing other debugger tools. This clearly distinguishes it from sibling debugger tools like debug_continue or debug_source_disassembly.

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

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

It explicitly says when to use the tool (managing DAP sessions before other tools), and gives concrete exclusion guidance: omit sessionId only for the backward-compatible default session and avoid a global session selector for concurrent work. The description tells the agent how to route between this and the other debug tools.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful behavioral context: it is read-only with respect to the debuggee, returns best-effort evidence, and includes collection errors for optional data an adapter cannot provide. This clarifies failure behavior and optionality beyond what annotations express.

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

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

Three sentences with no wasted words: the first states the core action and constraint, the second gives usage routing, and the third discloses read-only, best-effort, and error behavior. Information is front-loaded and every sentence 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 tool with 10 optional parameters and an output schema, the description covers the essential decision factors: what it returns, when to use it versus the closest sibling, that it is read-only, and how optional failures are reported. Return-value details are rightfully left to the 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 description coverage is 100%, so the schema carries full parameter documentation. The description adds conceptual grouping by naming the kinds of evidence collected (stack, locals, registers, exception details, modules, nearby instructions), which maps to several parameters, but it does not add per-parameter semantics beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb ('Capture'), a specific resource ('bounded evidence from the current stopped debug state'), and a key constraint ('without resuming execution'). It also distinguishes itself from debug_diagnose_stop by describing the division of labor, so an agent can tell them apart without inspecting schemas.

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 when to use: when raw stack, locals, registers, exception details, modules, or nearby instructions are needed. It also names the alternative (debug_diagnose_stop) and gives the condition that should route to that sibling (ranked crash hypotheses and project-frame selection). No inference is required.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, but the description adds meaningful behavior beyond that: it explicitly states the tool does not resume the target and describes what it returns, including frame-selection reasoning, correlations, operand bindings, and best-effort collection errors. 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?

Three sentences pack the core action, usage conditions, explicit alternative, side-effect guarantee, and return-value summary with no filler. The most differentiating information is front-loaded, and every sentence 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?

The description is complete for an agent deciding whether and how to invoke this tool: it gives scope, use context, a sibling alternative, side-effect safety, and an outline of the return payload. Since an output schema exists, detailed return documentation is not required here.

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 input schema fully documents all six parameters. The description itself adds little parameter-level semantics, but that is acceptable because the schema carries the weight; 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 names a specific verb ('Correlate'), a precise resource set (source locations, disassembly, registers, pointer-like locals), and the frames involved (raw fault frame and first likely project-controlled frame). It explicitly distinguishes itself from debug_diagnose_stop, making the tool's niche clear.

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 second sentence states exactly when to use this tool ('when a crash is already stopped and instruction/operand provenance matters') and names the preferred alternative for broader ranked diagnosis ('prefer debug_diagnose_stop'). This is explicit routing guidance with both inclusion and exclusion criteria.

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, idempotentHint, and destructiveHint, but the description adds valuable context: it specifies what is inspected (lifecycle state, stop, DAP events, bounded stderr) and explicitly confirms no target execution change. The word 'bounded' also hints at output limits. This goes well beyond the structured 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 sentences cover the full scope and intended usage with no filler. The first sentence front-loads the inspection target and side-effect-free nature, and the second provides concrete use cases and exclusions. Every clause adds value.

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, rich annotations, an existing output schema, and a description that explains both the contents inspected and the intended decision-making context, nothing essential is missing. The agent can safely call this tool based on the description alone.

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

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

The tool has zero parameters, so there is no parameter semantics to clarify. The baseline of 4 applies because no parameter documentation is needed at all, and the description correctly omits any irrelevant parameter talk.

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 ('Inspect') with an explicit resource list: debugger lifecycle state, selected stop, recent DAP events, and bounded adapter stderr. It also contrasts the tool with action-oriented siblings by stating it does not resume, launch, attach, or terminate, making its role within the sibling set clear.

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 guidance on when to use the tool: to determine session state before choosing another debug tool. It also states what it is not for ('does not resume, launch, attach, or terminate'), but it does not name specific alternative tools, relying on 'another debug tool' as a generic reference. This is clear context with no named alternatives, so it fits a 4.

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?

Beyond the destructiveHint=true annotation, the description discloses mode-specific side effects: codelldb/lldb-dap/gdb/live 'can run application code and cause its normal side effects, while current/dump only inspect stopped evidence.' It also states the deterministic outcomes (fixed/blocked/budget-exhausted), which is valuable behavioral context an agent cannot infer from the schema alone.

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 about five dense sentences, each carrying a distinct job: purpose, mode routing, safety exclusion, workflow stage selection, and return content. It is front-loaded with the core purpose and avoids restating schema details, making it very efficient for a tool with 19 parameters and nested objects.

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 highly complex tool, the description covers the key decisions an agent must make: which mode to select, when execution is unsafe, which workflow stage to use, and what the tool returns. The remaining parameter details and return shape are handled by the rich input and output schemas, so 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?

Schema description coverage is 100% and the parameter descriptions in the schema are already rich, so the baseline is 3. The tool description adds high-level grouping around mode safety and workflow stages but does not add meaningful per-parameter semantics beyond what the schema already 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 tool as a 'preferred high-level native crash workflow' and enumerates the concrete modes (current, dump, codelldb, lldb-dap, gdb, live), so an agent knows what operation it performs. It does not explicitly differentiate itself from sibling tools like debug_open_dump or debug_diagnose_stop by name, which keeps it from a 5.

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

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

The description gives explicit routing guidance for every mode, including an explicit exclusion: 'Do not use codelldb/lldb-dap/gdb/live when executing or attaching to the target is not authorized.' It also explains why those modes are risky and why current/dump are safer, and maps workflow.stage to diagnose, verify, and autonomous behaviors.

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 carry destructiveHint=true, so the destructive nature is known. The description adds meaningful behavioral context beyond that: it can pause a running live target, launches or attaches via several adapters, observes for a bounded interval, and explicitly warns that generic DAP cannot prove lock ownership. This is valuable operational disclosure that annotations do not provide.

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 every sentence earns its place: the first sentence states purpose and trigger conditions, the second explains mode behavior, the third states a safety exclusion, and the fourth adds an important epistemic caveat about lock-cycle interpretation. Content is front-loaded and 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 tool this complex—20 parameters, nested objects, five modes, output schema present, and rich annotations—the description covers the essential workflow, mode distinctions, and safety boundaries. It could be more complete by explicitly contrasting with debug_this_crash, but an agent has enough to call it correctly given the exhaustive input schema and 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 description coverage is 100%, with each parameter already documented in detail. The description adds workflow-level context but no per-parameter meaning beyond the schema, so the baseline 3 is appropriate: the structured field descriptions do the heavy lifting.

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

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

The description states a specific verb and resource: a 'high-level native hang workflow for all-thread triage.' It immediately names the triggering conditions (stuck, deadlocked, waiting forever, spinning) and the deliverable (bounded stacks from every thread, wait-state/deadlock heuristics, Pointer-Provenance v2), which clearly distinguishes it from the sibling crash-focused tools like debug_this_crash.

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 when-to-use criteria ('Use it when a live process appears stuck...') and a clear exclusion: do not use executable/attach modes when target execution or debugger control is not authorized. It does not explicitly name which sibling to use instead for crash triage, so it falls just short of full alternative routing, but the context is otherwise strong.

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 meaningful behavioral details beyond the annotations: it uses the current snapshot, sanitizer/runtime output, bounded forward writer tracing, and optional reverse stepping. It also warns about the safety implications of forward tracing on frozen dumps or unsafe resume conditions. This complements the destructiveHint annotation rather than merely restating it.

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 three sentences with no wasted words. It front-loads the core action, then gives usage guidance, and ends with a critical safety exclusion. Every sentence adds distinct value.

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 moderately complex tool with six parameters and a present output schema, the description covers the essential context: what it traces, why an agent would choose it, and an important safety constraint. The presence of a full output schema and 100% parameter schema coverage means the remaining details are already available without burdening the 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?

Schema description coverage is 100%, with each parameter already well documented (e.g., direction explains forward vs. reverse, maxStops explains the bound). The tool description adds contextual phrases like 'bounded forward writer tracing' but does not materially add parameter-level meaning beyond what the schema already provides. 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 clearly identifies a specific verb and resource: 'Trace lifetime evidence for one debugger-visible pointer or object handle.' It also names concrete use cases such as use-after-free and stale ownership, making the purpose actionable. However, it does not explicitly differentiate itself from sibling tools like debug_find_writer or debug_trace_value by name.

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

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

The description provides explicit guidance on when to use the tool: 'suspected use-after-free, stale ownership, or unexpected pointer replacement.' It also gives a clear exclusion: 'Do not use forward tracing on a frozen dump or when resuming the target is unsafe.' It stops short of naming alternative sibling tools or explaining when those alternatives should be preferred.

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 substantial behavioral detail beyond the annotations: it installs one temporary breakpoint/watchpoint at a time, resumes to the next confirmed writer, captures bounded evidence, removes only its own watch, and repeats. It also reveals a key limitation: the tool stops on unrelated debugger events rather than continuing through them. The destructiveHint and openWorldHint annotations are consistent with this live-target mutating 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 dense but efficient, front-loading the core purpose, then usage context, then operational behavior, then exclusions. Every sentence earns its place, and no content is repeated from 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?

Given the tool's complexity, the description covers the essential operational model, safety preconditions, limitations, and unsupported uses. An output schema exists, so the description does not need to explain return values. The combination of schema, annotations, and description gives an agent enough context to decide when and how to invoke 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%, and each parameter already has a meaningful description, including defaults, bounds, and semantics such as aggregation deadline and per-stop timeout. The tool description reinforces general concepts like 'bounded' and 'writer stops' but does not add significant parameter-level meaning beyond what the schema already 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 opens with a specific verb and resource: 'Build a bounded temporal write timeline for one debugger-visible variable or expression.' This directly states what the tool does and differentiates it from broader debugging or dump-analysis tools by focusing on a single variable/expression and a timeline of writes.

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 when-to-use guidance: after differential or crash evidence identifies a suspicious value and live-target resume is safe. It also gives clear when-not-to-use conditions: crash dumps, unsafe-to-resume targets, and as root-cause proof. However, it does not name alternative sibling tools to use in those excluded cases, so it falls one step short of the strongest guidance.

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