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

With no annotations, the description carries the full burden and does valuable work: it declares cancellation is terminal, that it does not archive the agent, and that it returns the run's actual post-cancel state. It omits idempotency/error behavior (e.g. cancelling an already-finished run) and any auth requirements, so it is strong but not complete.

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

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

Three tight sentences with the terminal-cancellation fact front-loaded and no redundant restatement of the name or title. Every sentence adds a distinct behavioral fact.

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

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

For a mutation tool with no annotations and no output schema, the description covers lifecycle effects and even the return value. The remaining gap is parameter semantics, which are left entirely to bare schema titles.

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%; both required params (agent_id, run_id) have only bare titles. The description never explains what these parameters identify or their format, so it fails to compensate for the coverage gap. The names are somewhat self-evident, keeping this above a 1.

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 (the active run), and implicitly differentiates from the cursor_followup sibling by noting that continuing the conversation requires a follow-up that starts a new run. An agent can distinguish this from cursor_launch/cursor_followup without opening a schema.

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

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

Gives a clear when-to-use (cancelling the active run) and routes the continuation case to follow-up, which selects the alternative sibling. It does not address edge conditions such as calling when no run is active or the run has already completed, so it stops short of the explicit when-not guidance a 5 requires.

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

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

With no annotations, the description carries the full burden and does well: it discloses that a NEW run is started, that the old run_id becomes stale, that a run_id is returned for polling, and that concurrent calls fail with 'agent is busy'. It stops short of stating permissions/auth or confirming the mutation/reversibility profile, so 4 rather than 5.

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

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

Three tight, front-loaded statements: what it does, what it returns and how to poll it, and the guard condition. No filler; 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?

No output schema exists, but the description compensates by explaining the return (run_id for polling) and the stale-run caveat. Usage context is complete; the only shortfall is the absence of any parameter-level detail for a 0%-coverage 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 0%, so the description should compensate, but it never explains agent_id or prompt beyond their self-evident names. The 'prompt' meaning (the follow-up text) is inferable and the run_id detail relates to output rather than input, so this is minimally viable rather than strong.

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

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

Specific verb ('Send a follow-up prompt to an agent') plus resource (agent), and it immediately clarifies that this starts a NEW run rather than continuing the old one. This distinguishes it cleanly from cursor_launch and cursor_status without opening any 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?

Explicitly states the precondition ('Only call when the previous run is terminal') and the failure mode if violated ('agent is busy'), then names the alternative to use first ('poll cursor_status'). This is textbook when-to-use/when-not-to guidance.

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

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

No annotations exist, so the description carries the full burden and does so well: it warns the call can take minutes, explains the 'unknown' status ambiguity and reconciliation strategy, and states that idempotency replays are safe and never duplicate. This is exactly the operational context an agent needs before calling a long-running launcher.

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

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

Front-loaded with the core action, then organized by parameter group and finally by return/polling behavior, with no filler sentences. It is on the long side, but nearly every sentence carries a constraint or warning that an agent would otherwise get wrong.

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 and no annotations, the description explains the return values (agent_id AND run_id) and the follow-up action required, plus failure-mode handling. Nothing essential for a correct first invocation 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 0% across 8 parameters, yet the description documents prompt content, repo_url format (GitHub https URL), starting_ref semantics (branch or SHA, omit for repo default, don't assume 'main'), model id sourcing, model_params shape ({key, value} dicts restricted to cursor_models options), mode values ('agent'/'plan'), and idempotency_key behavior. Only 'name' is unaddressed, which is a minor omission given the depth elsewhere.

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 ('Launch a Cursor cloud agent and enqueue its first run'), which precisely identifies this as the agent-creation entry point distinct from cursor_status, cursor_followup, and cursor_list mentioned elsewhere in the text.

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 explicit routing: repo-less launches are for research/reviews/writing, pass repo_url when the agent should write code, call cursor_models first for model ids, and poll cursor_status with the returned ids. It also names the recovery path (cursor_list, idempotency_key retry) when status is 'unknown', leaving little to inference.

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

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

With no annotations, the description carries the full burden; it does disclose scope ('your agents') and ordering ('newest first'), and the reconciliation hint implies returned fields (name, creation time). It says nothing about pagination, what the default limit does, or the shape of results, which is a real gap for a list tool with no output schema.

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

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

Two tight sentences, purpose and ordering front-loaded before the usage scenarios, with no filler.

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

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

Purpose and usage are adequately covered, but with no annotations, no output schema, and an undocumented parameter, an agent still lacks the return shape, pagination behavior, and limit semantics needed to call it precisely.

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 'limit' parameter has 0% schema description coverage and the description never explains it or its default. At best, 'newest first' implies which end truncation applies to, but the semantics of the parameter are left 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 and resource ('List your agents') plus the ordering ('newest first'), which makes the operation unambiguous. However, it never names or contrasts with siblings like cursor_status or cursor_result, so differentiation from them is only implicit.

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

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

Provides two concrete when-to-use scenarios: reconciling after a launch reports 'unknown' (with a matching method) and locating a lost agent. It stops short of explicit negatives or naming an alternative tool for those cases, so it is clear context but not full routing guidance.

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

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

With no annotations, the description carries the burden and does disclose key behaviors: ids are not guessable, model entries carry params/variants, and only combinations from this list are accepted. It does not mention auth requirements, rate limits, or result size, so it falls short of fully transparent.

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

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

Three tight sentences, front-loaded with what the tool returns, then the required call ordering. Every sentence earns its place with no filler.

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

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

No output schema exists, but the description compensates by naming the returned content (ids, parameters, variants). For a zero-param discovery tool this is largely complete, though pagination or auth prerequisites are unmentioned.

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. It still adds useful context about the parameter structure of the returned models (e.g. reasoning effort), which is not a schema concern here.

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

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

States a specific verb+resource: 'List available Cursor models with their ids, parameters, and variants.' The listing/discovery role is clearly distinguished from action siblings like cursor_launch and cursor_result without needing to open any 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?

Explicit sequencing guidance: 'Call this before cursor_launch and pass the id verbatim — ids are not guessable.' It also explains the consequence of ignoring it ('only valid id/params combinations from this list will be accepted'), which is a clear when/when-not signal.

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 mostly succeeds: it discloses the server-side polling model, the timeout clamp to 5 minutes, timeout recovery behavior, truncation signaled via truncated=true, and retry-with-backoff on 429/5xx. It omits whether the call blocks the agent for the full timeout window and any sensitivity/permission considerations, but the operational profile is unusually well documented.

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

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

Front-loaded with the core behavior, then tight clauses for timeout, fallback, truncation, and retries. Every sentence carries an actionable fact; the line wrapping is cosmetic and no content is wasted.

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

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

No output schema exists, so the description appropriately covers the return surface (the run's result, plus truncated=true when large). Combined with the timeout and retry details, an agent has enough to call it correctly, though parameter-level detail on agent_id/run_id is thin.

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%, so the description must compensate. It explains timeout_s well (clamped to 5 min) and implies run_id identifies the run for subsequent cursor_status polling, but agent_id and the concrete run_id semantics are never described. Partial compensation for the coverage gap.

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

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

States a specific verb and resource ('Wait for a run to finish... and return its result') and explicitly positions itself against a sibling ('Convenience wrapper over cursor_status for when you just want the final answer'). An agent can distinguish it from cursor_status without opening either schema.

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

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

Explicitly names the condition for choosing this tool ('when you just want the final answer'), names the alternative (cursor_status), and even prescribes the fallback path on timeout ('keep polling with cursor_status using the returned run_id'). Nothing about selection is left to inference.

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

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

No annotations exist, so the description carries the full burden and does well: it discloses polling cadence, the default-run fallback, and the meaning of terminal=true plus what result holds when terminal. It doesn't cover auth requirements or what non-terminal status values look 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?

Three tight sentences, front-loaded with the purpose and the key semantic caveat, then operational guidance, then the terminal/result contract. 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?

With no annotations and no output schema, the description still supplies the polling contract and the terminal/result contract, which is the core of what an agent needs. It stops short of describing the status payload itself or possible status values.

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% across 2 parameters, so the description must compensate. It explains run_id's default/omit behavior but says nothing about agent_id beyond its presence as required, leaving half the 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 ('Check a run's status') and sharpens it by disambiguating run status from the agent's ACTIVE/IDLE lifecycle status. It doesn't explicitly name a sibling like cursor_result or cursor_list, so the differentiation is conceptual rather than explicit.

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

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

Explicit operational guidance: poll every 10-30 seconds, never sleep inside a tool call, and omit run_id to fall back to the agent's latest run. It tells the agent both how to use the tool and the anti-pattern to avoid.

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

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

No annotations are provided, so the description carries the full burden. It discloses the notable behavioral trait that the underlying activity 'costs real money', framing this as a cost-auditing read, but never states read-only safety, auth needs, rate limits, or whether the result is cached/live.

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

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

Two short sentences, front-loaded with the resource and followed by the motivational cue. Every clause carries information; only the slightly informal tone keeps it from a 5.

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

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

For a two-parameter read tool with no output schema, the description covers what is returned (token usage and cost) but not the shape of the return, units, or how cost is attributed across runs. Adequate but with clear gaps for a cost-reporting 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% and neither parameter is described in the schema, but the phrase 'an agent (or one run)' maps agent_id to the broad scope and run_id to the narrow one-run scope, adding genuine meaning. It does not explain accepted ID formats or the empty-string default on run_id.

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 (token usage and cost) and scope (an agent, or one run), which is clearly distinct from siblings like cursor_status or cursor_result. It lacks an explicit verb (e.g., 'retrieve'), but the intent 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?

Gives one usage cue ('check this when a run felt expensive'), which is a real trigger condition but no explicit alternatives or when-not guidance. An agent can infer usage but is not routed against sibling cost/status tools.

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

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

No annotations are provided, so the description carries the burden; it discloses the observable effect (key validation result and the bound identity) and implies a harmless read-only call. It does not explicitly state there are no side effects, no rate-limit behavior, or the exact response shape, which keeps it out of the top score.

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, with the primary purpose front-loaded ahead of the recovery guidance. Every clause earns its place.

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

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

For a zero-param, no-output-schema identity check, the description covers what it does and when to reach for it. It could add a note that it is side-effect-free and requires no arguments, but nothing essential is missing 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 tool takes zero parameters, so there is nothing to disambiguate; baseline for a no-arg tool applies. The description correctly does not invent 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 ('verify') plus two concrete resources ('API key', 'identity'), which is distinct from every sibling (launch/status/followup/result/cancel/list/models/usage). An agent can tell exactly what this tool returns without opening a schema.

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

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

Gives an explicit trigger condition: call this first when other tools fail with auth errors. That is actionable routing guidance. It stops short of naming which error classes qualify or an alternative diagnostic, so it is clear context without full when-not coverage.

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