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

With no annotations, the description carries the full burden and does unusually well by disclosing the internal checks performed. It leaves one meaningful gap: a writability probe may touch the filesystem, and the description never states whether the tool is side-effect-free or how failures are surfaced.

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

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

Two sentences, zero filler, with the diagnostic scope front-loaded before the usage trigger. Every clause carries information an agent needs.

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

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

For a zero-param tool with no output schema, the description implies a diagnostic report but does not say what form it takes or whether an unhealthy result surfaces as an error versus a report body. Given the low complexity, this is a minor rather than blocking gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter claims are made that could conflict with the empty 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?

Enumerates the specific checks performed (binary resolution, workspace allowlist, state directory writability, concurrency, metrics), which is far more informative than a generic 'health check'. It is distinguishable from bridge_stats and bridge_shutdown by scope, though it does not name those siblings explicitly.

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

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

'Run this first when a task fails for unclear reasons' gives a concrete triggering condition and ordering priority. It stops short of naming alternatives (e.g. when to prefer bridge_stats) or stating when not to run it.

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

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

With no annotations at all, the description carries the full burden, and it does disclose the primary effects: in-flight jobs are cancelled and state is flushed before exit. It omits whether the shutdown is irreversible, what happens to results of cancelled jobs, whether the process can be restarted, and whether any permissions are required — significant gaps for a destructive/terminal operation.

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

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

Two short sentences, zero filler, purpose front-loaded ahead of the usage note. Efficient, though the second sentence could have carried the grace-period detail at no cost to length.

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

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

For a no-annotation, no-output-schema shutdown tool, the description covers what it does and one usage context, but leaves the single parameter and the irreversibility/permission story unexplained. An agent could call it, but not confidently predict the consequences of graceMs or of a mid-flight job.

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

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

There is one parameter, graceMs, with 0% schema description coverage and no mention anywhere in the description. Since the schema provides nothing, the description needed to explain what the grace period governs (drain time before hard kill?) and its default; it does neither.

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

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

States a specific verb and effect: 'Cancel all in-flight jobs, flush state and exit' — an agent knows exactly what the call does to the bridge. It stops short of distinguishing itself from the sibling cursor_cancel, which also plausibly cancels jobs, so the boundary between 'cancel one job' and 'shut down everything' is only implied.

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

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

Gives a concrete triggering condition: use before restarting the bridge to avoid orphaned Cursor processes. However, it names no alternatives (e.g. cursor_cancel for partial cleanup) and gives no 'do not use during X' exclusions, so an agent must infer the safety envelope itself.

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

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

With no annotations, the description must carry the full behavioral burden. 'Counters' implies a read-only, non-mutating call and the enumeration of metric categories gives some idea of the payload, but nothing states whether the read is non-destructive, whether it is cached or point-in-time, or what a single row/record looks like.

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

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

A single front-loaded sentence with no filler, and the metric scope is stated before the purpose. It is efficient but perhaps under-specified for a stats endpoint an agent will need to interpret.

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

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

There is no output schema and no annotations to carry return-shape or safety information, so the description should say more about the structure of the counters (unit, aggregation window, dimensions). It names the metric families but leaves format and semantics of the returned values unspecified.

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

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

The tool takes zero parameters, so the schema carries no semantic load and the baseline of 4 applies. The description adds no misleading parameter implications.

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

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

States a specific resource (counters/metrics) and enumerates what is measured: job outcomes, tier mix, and duration. That is well beyond a restatement of the name. It does not, however, differentiate itself from the closest sibling bridge_health, which an agent might reasonably confuse it with.

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 trailing phrase 'for capacity planning' implies the intended use case, but there is no explicit guidance on when to call this versus bridge_health, nor on how often or in what context to refresh the counters. Usage is only inferred.

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

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

With no annotations, the description carries the full burden; it does valuable work by disclosing that cancellation kills the entire process tree, i.e. that this is destructive and broader than a single process. It omits irreversibility, whether confirmation is required, and behavior when the job is already finished or unknown.

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 with the destructive scope front-loaded; there is no filler and 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?

With no annotations and no output schema, the description should explain the sole required parameter and the effect of an unsuccessful cancel. It covers the destructive scope well but leaves the parameter entirely undocumented, which is the main gap for a one-parameter mutation tool.

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

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

Schema description coverage is 0% and the single parameter 'jobId' has no description in the schema or the description text. The agent is not told where to obtain a jobId (presumably from cursor_run or cursor_list) or whether partial IDs are accepted.

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 ('Cancel') and resource ('a running job') and adds scope ('entire process tree'). It is clearly distinct from siblings like cursor_run or cursor_status, though it never names them explicitly.

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

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

The phrase 'a running job' hints that the target must be active, but there is no explicit when/when-not guidance, no mention of alternatives such as cursor_status for checking state first, and no prerequisites or confirmation expectations.

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

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

With no annotations provided, the description must carry the behavioral burden. It conveys that this is an inspection/read operation with optional raw patch inclusion and paging, but it does not disclose whether the job must be finished, error behavior for invalid job IDs, authentication requirements, or output size limits beyond the patch parameter.

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

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

Two compact sentences, front-loaded with the core purpose and followed by the key paging behavior. 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 four-parameter inspection tool without an output schema, the description is mostly complete: it names the main return components (changed files, diffstat, optional raw patch) and explains paging. It leaves minor gaps around job state requirements and error behavior, but nothing critical 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 description coverage is 50%, with limit and includePatch documented in the schema. The description adds meaning for offset/limit as paging controls for large patches, but it does not explain the offset semantics or clarify that jobId refers to an execute job beyond the phrase 'execute job changed'.

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 clear verb and resource: inspect what an execute job changed, including changed file list, diffstat, and raw patch. It does not explicitly differentiate from siblings like cursor_status or cursor_run, but the 'execute job changed' scope is specific enough for an agent to identify the tool.

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 implies usage after an execute job and explicitly says to use offset/limit when paging through a large patch. However, it does not state when to use this tool versus cursor_status or cursor_run, nor does it mention prerequisites such as the job needing to be complete.

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

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

With no annotations, the description carries the full burden; "List" implies a read, and it usefully names the returned fields and that results are "recent" (implying recency ordering). It omits the default/max result behavior, ordering guarantees, whether filtering by status still returns recent jobs only, and pagination, so it falls short of full disclosure for an unannotated tool.

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

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

A single front-loaded sentence with no filler. It is economical, though the terseness is part of why usage and parameter guidance are missing.

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, unannotated two-optional-param read tool with no output schema, naming the returned fields covers the main gap. Still missing are the default limit, result ordering, and any differentiation from cursor_status, but the core call path is 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 coverage is 50%: `limit` is documented in the schema while `status` relies entirely on a self-explanatory enum. The description adds nothing about the parameters — it mentions "status" only as a returned field, not as a filter — but for a two-parameter tool with a clear enum, the schema does most of the work.

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

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

States a specific verb and resource ("List recent jobs") plus the fields returned (status, tier, duration), so the agent knows what it gets. It does not, however, distinguish this from the sibling cursor_status, which an agent could plausibly confuse with a per-job status lookup.

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

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

There is no when-to-use guidance: nothing says whether to call this to discover job IDs before cursor_status, or to poll for completion. No alternatives (cursor_status, cursor_list vs. run) are named, and no prerequisites or exclusions 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?

With no annotations, the description carries the burden and discloses meaningful behavior: same job id and thread preserved, the state transition (input-required -> working -> completed), and a cancel prerequisite. It does not say whether the child follow-up inherits permissions or what the response looks like, but the core behavioral model is well conveyed.

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?

Dense and front-loaded: the primary verb+resource leads, then the two behavioral branches, then the cancel caveat. Nearly every clause earns its place, with only mild repetition.

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

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

No output schema exists, so returns are less critical, and the behavioral logic is covered. But with 4 uncovered parameters/enum values and no annotations, the definition leaves the agent guessing on parameter semantics and the meaning of tier — a real gap for a 3-param tool.

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

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

Schema coverage is 0%, so the description must compensate, but it says nothing about jobId, prompt, or the tier enum (consult/plan/execute). 'input' and 'job id' are mentioned only in passing, leaving all three parameters undocumented.

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

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

States a specific verb+resource ('Send input to a job') and then differentiates two distinct behaviors: resuming a paused task vs. spawning a child follow-up job. This is clear and specific, though it never names a sibling tool directly.

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 the condition that selects the resume path ('paused in the A2A input-required state') versus the child-job path, and adds a precondition ('Cancel a running job before replying'). Lacks an explicit tie to cursor_cancel by name, but the guidance is 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?

With no annotations, the description carries the full burden and does well: it discloses asynchronous non-blocking behavior and that execute is isolated in a git worktree. It does not cover failure modes, timeouts, or authentication/workspace-root requirements beyond what the schema states.

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

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

Front-loads the key fact (dispatch and return immediately, never blocks) and follows with polling instruction and tier semantics. Every sentence adds information; 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?

There is no output schema, but the description states the return is a job id, which is the essential return value. It lacks detail on what happens on failure or how cursor_reply/cursor_cancel interact, but an agent has enough to 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 coverage is 80%, so the baseline is 3, but the description adds substantial meaning for the tier enum (read-only vs. write-capable, worktree isolation) that the schema enum alone does not supply. model and timeoutSec are left entirely to the schema, so it does not fully compensate.

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

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

States a specific verb and resource ('Dispatch a task to the Cursor sub-agent') plus the immediate return ('job id'). It distinguishes itself from the sibling query tools by emphasizing that it never blocks and defers results to cursor_status.

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 tells the agent to poll with cursor_status because a real task takes minutes. It also gives selection guidance among the tier options: consult/plan are read-only Q&A/planning, execute may write files.

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

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

No annotations are provided, so the description carries the full behavioral burden. It mentions blocking briefly until the job settles and cursor-based event filtering, but it omits important behavior such as timeout handling, error cases, permissions, and what the response contains.

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

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

Two short sentences, front-loaded with the core action. Every sentence provides useful invocation detail without waste.

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

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

There is no output schema and no annotations, so the description should explain what polling returns. It explains how to call the tool but not what job status or events the agent will receive, leaving a significant gap for a status-check tool.

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 documents since and waitSeconds, and the description reinforces their meaning. However, jobId is undocumented in both the schema and the description, and the description adds little beyond the schema for the two described parameters.

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

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

States a specific verb and resource: 'Poll a job.' This distinguishes it from sibling tools like cursor_run, cursor_cancel, and cursor_list. It does not explicitly name alternatives, but the purpose is clear enough to select the tool.

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 usage through 'Poll a job' and explains how to use waitSeconds and since. However, it gives no explicit when-to-use guidance, no exclusions, and no comparison to alternatives such as cursor_list or cursor_diff.

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