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

Goes well beyond the annotations: it discloses that a cancellation of an already-finished task still returns a result (reinforcing idempotentHint), that prior CLI side effects are NOT undone (clarifying the destructiveHint), and that finished invocation handles expire after seven days. These are exactly the behavioral facts an agent cannot infer from the structured fields.

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

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

Three short sentences plus a lifecycle note; the routing hint to wait_agent comes first and nothing is padded or repeated.

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?

Covers purpose, the sibling alternative, the mutation's limits, and the handle lifecycle, while an output schema already documents return structure. Nothing an agent needs to invoke this 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% and the single parameter's description already points back to start_agent, so the schema does the heavy lifting. The description only restates that the task is keyed by invocation_id, adding no new format or constraint detail.

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 ('Stop a task') plus the keying parameter (invocation_id), and immediately contrasts with the sibling wait_agent. An agent can distinguish it from wait_agent and cancel_round 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?

Explicitly names the alternative ('use wait_agent to observe without stopping') and the condition that selects it, so the stop-vs-observe choice is fully resolved in the description.

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

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

Annotations declare destructive=true, idempotent=true, readOnly=false, but the description adds substantially more: running seats are cancelled and recorded absent, unstarted serial seats are skipped, already-succeeded answers are kept and committed, and CLI side effects are not undone. That is exactly the 'what gets destroyed and what survives' detail an agent needs before invoking a destructive tool.

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

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

Three short sentences, front-loaded with the core action and outcome, then the retention rule, then the caveat about CLI side effects. Nothing is redundant and each sentence carries distinct 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?

An output schema exists, so return values need not be explained, and the annotations plus description jointly cover the safety profile and per-seat cancellation semantics. The only real gap is usage guidance relative to wait_round and cancel_agent.

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 round_id parameter is never mentioned in the description, so there is no format, source, or lookup guidance to compensate. The parameter name is largely self-explanatory given the tool name, which keeps this from being 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 precise verb+resource ('Stop a round') and immediately scopes what stopping means at seat level, which clearly separates it from run_round and wait_round. It never names a sibling or the alternative action, so it lands at 4 rather than 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 implies the usage context (you cancel a round that is running) and even sketches what happens to different seat states, but it never states when to prefer this over waiting for a round or cancelling at the agent level. Guidance is implied rather than explicit.

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

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

Annotations already declare readOnly/idempotent/non-destructive/non-open-world, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it explicitly denies side effects (no CLI launch, no install/login check), which prevents an agent from over-interpreting the call as a liveness probe.

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

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

Three short sentences with zero filler, and the core purpose is front-loaded before the caveats. Nothing 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?

With an output schema present, return-value detail is unnecessary, and annotations cover safety. The description supplies the scope caveats and sibling relationship an agent needs. It stops just short of stating the intended call order (describe_provider before start_agent), a minor residual 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?

There is a single parameter with 100% schema description coverage ('Provider whose permitted status and options to return'), so the schema already carries the meaning. The description adds no syntax, format, or defaulting detail beyond that, leaving this at the baseline-for-full-coverage score.

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 (read one provider's permitted status and supported options) with no tautology. It also pins the tool's scope relative to siblings, noting that the 'permitted' result is only relevant to start_agent and that open_group accepts every provider, so an agent can separate it from the start/run/wait family 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?

It gives clear exclusions ('does not launch a CLI or check installation/login') and ties its output to a concrete downstream decision ('permitted applies to start_agent'). The positive trigger — call this first to decide whether start_agent will succeed — is strongly implied but never stated as an explicit 'use when' rule.

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 the safe-read profile (readOnly, idempotent, non-destructive, closed-world), but the description adds real behavioral context beyond them: metadata-only with no prompt/reply/tool data, oldest-first ordering, expiry of finished entries, and lifecycle semantics (active entries carry phase; finished ones hold a fixed elapsed_ms and a non-empty session_id). Field-by-field notes partially overlap with the output schema, keeping this short of a 5.

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

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

Three tight sentences plus a routing clause; scope and ordering are front-loaded, and every sentence adds information (scope, data exclusions, field semantics, alternative routing) 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?

With an output schema present, the description need not explain return values, yet it still supplies the scope, ordering, expiry behavior, and data-exclusion guarantees an agent needs to call and interpret this correctly. Nothing material is missing.

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

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

The tool takes zero parameters, so the schema imposes no semantic burden and the baseline is 4. The description correctly spends no words on 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?

Specific verb (List) plus resource (this server's invocations) with a precise scope: active entries plus finished ones not yet expired, ordered oldest first. It is clearly separable from wait_agent/wait_any, which are for reading results rather than enumerating invocations.

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 final sentence explicitly routes the agent: 'Use wait_agent or wait_any to read results,' which implies list_invocations is for metadata enumeration only. It gives the alternative and the condition that selects it, but never states a positive when-to-use case or any exclusion for this tool 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?

Annotations only declare it is non-readonly, non-destructive, non-idempotent and closed-world. The description goes well beyond that by disclosing the in-memory lifecycle ('Nothing is saved'), that each seat retains its own native session across rounds, and that host exclusions do not apply to seats — all behavior an agent could not derive from structured fields. It stops short of covering failure modes or cleanup semantics, so not a 5.

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

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

Three short sentences, front-loaded with the core action and scope, then the persistence caveat, then seat behavior. No filler. Minor density issue in 'native tools and permissions, the given cwd, explicit options', which is terse to the point of ambiguity.

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?

An output schema exists, so return values (presumably a group handle) need no explanation here. Given the tool's moderate complexity, the description covers the essential mental model — ephemeral grouping, seat count, per-seat session persistence. It omits what happens if a seat id collides or how a group is closed, which a mutation-style tool could reasonably state.

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

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

Schema description coverage is only 50%, so the description has to compensate. It does partially: 'the given cwd' and 'explicit options' map to the cwd/provider_options fields, and '2–6 CLI seats' restates the array bounds. But the seat 'id' pattern and provider enumeration get no added meaning, leaving the low-coverage half only loosely covered.

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 with scope baked in: 'Create an in-memory group of 2–6 CLI seats for collaborative rounds.' An agent can tell this is a grouped-seat primitive distinct from a single-agent start. It does not, however, name any sibling (e.g. start_agent or run_round) to anchor the contrast, so it falls short of the top tier.

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?

'For collaborative rounds' implies the use case, and 'Nothing is saved' signals a session-style tool rather than a persisted one. But there is no explicit when-to-use rule, no when-not condition, and no pointer to alternatives such as start_agent for a single seat. Usage 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?

Annotations only say destructive/non-idempotent/open-world; the description goes well beyond them by disclosing what seats see, that parallel answers commit together while serial ones commit one-by-one, that failed/blocked/cancelled seats are recorded as absent with serial rounds continuing, and that there are no retries or per-seat deadlines.

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 action and the wait_round handoff before any behavioral detail, which is the right ordering. It is dense but every sentence carries behavioral content; the later sentences are long and run together, slightly taxing to parse.

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

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

Covers execution semantics, failure handling, and the round_id return path, and an output schema exists so return values need no elaboration. It omits prerequisites such as whether the group must be opened first and how this interacts with cancel_round, the one gap for a 5-parameter mutating orchestration 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 80%, so the baseline is 3, but the description adds interpretive meaning to the `order` parameter by explaining the commit timing consequences of parallel vs serial that the schema only sketches. It does not clarify group_id or the privacy semantics of `instructions` beyond what the schema states.

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

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

States a specific verb+resource ('Start one round') and immediately distinguishes itself from the sibling wait_round by naming it and the round_id handoff. An agent can select it against open_group/wait_round/cancel_round 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?

Gives explicit sequencing guidance: run non-blocking, then call wait_round with the returned round_id. It does not cover when-not-to-use or the relationship to cancel_round/open_group, so it stops short of full routing.

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 declare destructiveHint=true and openWorldHint=true; the description adds real value beyond them by disclosing there is no runtime deadline, that provider-native limits still apply, that returned settings are requests rather than confirmed effective settings, and that active invocations reject messages. It notably never addresses the destructive risk implied by the annotations (the CLI runs against a real cwd), which is the one behavioral gap for a mutation 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?

The output contract (invocation_id) is front-loaded in the first clause, followed by lifecycle routing, then caveats. Six short sentences, each carrying a distinct point; only 'Provider-native limits still apply' feels like 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 an output schema, full param coverage, and safety annotations already present, the description covers the lifecycle and the settings-inheritance semantics an agent needs. It stops short of describing failure modes or the practical consequence of running a destructive CLI in cwd.

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 cwd, prompt, provider, session_id, and provider_options thoroughly. The description's parameter-related content (requested vs. effective settings, session continuation) largely restates what the schema already says, so the baseline 3 applies.

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

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

States a specific verb and resource ('Start one CLI invocation') and immediately names its return value (invocation_id), which distinguishes it from siblings like wait_agent. An agent can tell this is the entry point of the agent lifecycle 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 routes to alternatives: 'use wait_agent for the result' and 'use cancel_agent to stop work explicitly.' It also states the continuation rule (pass a finished invocation's native session_id to a new start_agent call), covering both when to use this tool and how it relates to the rest of the lifecycle.

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 readOnly/idempotent/non-destructive, yet the description adds substantial behavior beyond them: a fixed five-minute window with early return, the shape of a running response (reply tail capped at 1000 chars plus its age), execution_blocked semantics and per-invocation blocker waking, one-shot blocker categories, the warning that failures/retries/silence are not proof of a stall, and seven-day handle expiry. That is exactly the kind of context annotations cannot carry.

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 wait window and early-return conditions, then layered with edge cases. It is dense and a few clauses (e.g. final-reply wording, the 7-day expiry line) could be tightened, but nearly every sentence carries distinct behavioral information rather than restating the schema.

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 an output schema present, the description need not define return values, yet it usefully characterizes running vs finished vs execution_blocked states. Coverage of continuation, expiry, and blocker behavior is strong; it is only slightly short on what happens for an unknown/expired/foreign invocation ID.

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

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

Schema coverage is 100% and the schema already says invocation_id comes from start_agent, so the baseline is 3. The description still adds meaning by stressing that the same ID is reused across successive waits and cancel calls, clarifying that it is a persistent handle rather than a one-shot token.

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 (wait on a subagent invocation) and immediately scopes it. It is distinguishable from siblings: start_agent produces the ID, cancel_agent is the alternative exit path, and the last line explicitly rules out that this is a background notification subscription.

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 clear operational context: call repeatedly with the same ID to continue after expiry, and cancel with the same ID if desired. It also draws an explicit boundary ('request/response waiting, not a background notification subscription'), though it never enumerates a when-not-to-use case against a named sibling beyond the implicit cancel path.

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 the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely useful behavior beyond them: the five-minute ceiling, that finished invocations remain ready on every call, that only returned blockers are consumed while the rest survive, and that the call fails fast on empty/repeated/unknown/expired IDs. Minor tension with readOnlyHint exists in the 'consumes' semantics, but consumption is scoped to unread blocker markers rather than the invocations themselves.

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 purpose is front-loaded and each subsequent clause carries a distinct, actionable fact (timeout, consumption, retry behavior, error handling) with no filler. It is dense and slightly run-on, but nothing reads as redundant padding.

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 an output schema present the description need not detail return fields, yet it still points to wait_agent's shape and explains the ready vs wait_elapsed snapshots. Combined with the annotated safety profile and fully documented single parameter, the definition is sufficient; only the missing 'reason' selector keeps it short of 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 coverage is 100% for the single parameter, so the baseline is 3. The description adds real meaning over the schema: the all-or-nothing validation rule ('reject the whole call before waiting') and the constraint that IDs must be known/distinct. It does reference a 'reason=ready'/'reason=wait_elapsed' selector that does not appear in the input schema, which slightly muddies the parameter story.

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 opening sentence names a specific verb and resource and pins the scope precisely: 'Wait up to five minutes for the first of several invocations to finish or report a blocker.' The 'several'/'first' framing implicitly separates it from the single-invocation wait_agent sibling, but no sibling is named as an alternative, so differentiation is left to inference.

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

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

Usage is implied by the semantics ('reason=ready returns every listed invocation that is finished...; reason=wait_elapsed returns a running snapshot'), so an agent can infer which mode yields which behavior. However, there is no explicit when-to-use/when-not guidance and no routing against wait_agent, wait_round, or list_invocations, all of which overlap.

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 establish the safe, idempotent, non-destructive read profile, and the description adds real behavior beyond that: the five-minute ceiling, early return on completion or blocker, the fact that a blocked seat stays running, and that include_output=false loses nothing because later calls with true return full answers. It does not cover auth requirements, rate limits, or concurrency 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?

Front-loaded with the timeout and return condition, then the blocker workflow, then the output toggle. Dense and useful, though the reply-tail concept is restated in two sentences where one would suffice.

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?

An output schema exists, so return shape need not be explained; the description covers the asynchronous waiting semantics, blocker handling, and the include_output tradeoff well. The remaining hole is round_id semantics and the relationship to wait_agent, which an agent must guess.

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%: include_output is documented in the schema, while round_id has no description anywhere. The description adds useful semantics for include_output (data is not lost, later true calls return full answers) but contributes nothing about round_id's format or provenance, so it only partially compensates for the gap.

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

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

The description names a specific verb ('Wait'), the resource ('round'), and the bounded scope ('up to five minutes') with the early-return conditions. It implicitly separates itself from wait_agent by operating on a round rather than a single agent, but it never explicitly contrasts the two sibling wait tools, so the differentiation is left partly to inference.

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

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

It gives clear operational context: call it while a round is running, keep waiting or use cancel_agent when a blocker appears, and set include_output=false when only status is wanted. It stops short of stating when to prefer wait_round over wait_agent or when not to call it at all.

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