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

Annotations only declare openWorldHint=false and idempotentHint=true, so the description carries most behavioral disclosure. It explains that allow=true runs the pending tool call, allow=false tells the sub-agent the user declined it, and that decided is false when the handle is unknown or no pending approval exists.

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

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

The description is dense but front-loaded: the primary action and condition come first, followed by discovery guidance and return semantics. Every clause contributes useful information without wasted setup.

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 output schema and sparse annotations, the description supplies the missing context: how to find waiting runs, what the two allow outcomes mean, and how to interpret the returned decided flag. Nothing essential for correct 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 coverage is 100%, so the schema already defines both parameters. The description still adds meaning by explaining the downstream effect of allow=true versus allow=false on the sub-agent and by clarifying that handle refers to a waiting run.

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 (answer a run waiting with status AwaitingApproval) and distinguishes the approval case from elicitation-based approval. It also names the discovery siblings (await, status) for finding waiting runs, so an agent can tell it apart from those tools.

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

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

It gives a clear condition for use (run is waiting with AwaitingApproval and the client was not asked through elicitation) and points to await or status for locating waiting runs. It stops short of explicitly naming the decide sibling and when that alternative should be used 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?

Annotations only declare openWorldHint=false and destructiveHint=false; the description goes well beyond them by disclosing what is returned (every known handle's state, same fields as status), that in-progress runs are still included after timeout, that unknown handles are silently omitted, and that a run nearing a destructive call blocks for approval with a specific AwaitingApproval/pendingApproval contract. That is unusually rich disclosure for a non-mutating 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 waiting behavior and mode semantics are front-loaded where they matter most, and the sentences are dense with distinct facts rather than filler. It runs long and the failedToolCalls/toolCalls explanation is a slight tangent for a wait tool, but nothing is padded.

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 output schema, the description carries the return-shape burden and does so by referencing status's fields and enumerating the special cases (unknown handles, in-progress runs, pendingApproval). The one gap is that "same fields as status" forces the agent to consult a sibling tool to know the actual field list.

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 baseline would be 3, but the description adds genuine meaning by explaining what mode=all and mode=any actually do behaviorally rather than just restating the enum values. It also clarifies that timeoutSeconds ends the wait without ending the runs, which goes beyond the schema's "Longest time to wait".

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?

"Wait for runs to finish" states a specific verb (wait) and resource (runs), and the description immediately differentiates itself from the sibling `status` by contrasting blocking vs looking. An agent can distinguish `await` from `status`, `run`, and `spawn` 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?

It names the alternative explicitly ("use status to look without waiting") and gives the condition that selects each mode (all vs any), plus a follow-up path (`approve`) for the approval case. What it does not cover is when to prefer awaiting versus polling with status repeatedly, or how to pick a timeoutSeconds value, leaving that 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 declare destructive and idempotent, and the description corroborates and deepens them: cascade to descendants, irreversibility with no answer produced, and a precise explanation of why re-calling is harmless (cancelled=false when handle unknown or already finished). That is context structured fields cannot convey.

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 tightly packed sentences: action and scope first, then irreversibility, then return semantics and the harmless-retry note, then the alternative. No sentence is 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, and the description compensates by specifying the return shape ({handle, cancelled}) and the meaning of each value. Combined with the follow-up pointer to status/await, an agent has everything needed to call and interpret 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?

Only one parameter with 100% schema coverage ('Handle returned by spawn'), so the schema already carries the semantics. The description adds no format or sourcing detail beyond what the schema states, making baseline 3 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 ('Stop') and resource ('a run and every run spawned under it'), including the cascade scope. An agent can distinguish it from status/await/approve siblings 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?

Explains the consequence (cannot be undone, runs end as Cancelled) and redirects to 'status or await' for reading final state. No explicit when-not-to-use case, but the destructive framing plus the alternative pointer covers most routing decisions.

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 readOnlyHint and openWorldHint; the description adds substantive behavior beyond that: the two inference paths, that scoring is by logprob of the model's first answer token, and what is returned (labels with probabilities). With no output schema, this return-value disclosure carries real weight. It doesn't cover limits such as cost, latency, or what happens with an oversized label set.

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 that front-load what the tool returns, then the two operating modes. No filler, no restatement of the tool name, and the parallel 'Without labels / With labels' structure makes the branch scannable.

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

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

For a three-parameter read-only classifier with a fully documented schema and no output schema, the description supplies the one thing the schema can't: the shape of the result and the inference mechanism. Minor gaps remain around probability normalization and edge cases (label count limits, model behavior), but nothing blocks correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining the consequence of supplying versus omitting labels — the semantic switch that the schema only states mechanically. It adds the mechanism behind the model default rather than repeating the schema text.

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?

"One-pass typed decision: returns labels with probabilities for the input" gives a specific verb (classify/decide) and an explicit return shape, which none of the siblings (status, run, cancel, await, approve, spawn, tools) provide. It doesn't explicitly say it differs from those siblings, but no sibling is a classifier so confusion is unlikely.

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

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

The description clearly branches on the labels parameter: omit labels for the single-pass model's own label set, supply labels to have a generative model score them. That is real mode-selection guidance. It stops short of stating exclusions (e.g., when not to use this versus a heavier job-running tool), so it isn't 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?

The annotations only cover openWorldHint/idempotentHint/destructiveHint, so the description carries the interesting burden and does so well: blocking semantics, cancellation propagation ('cancelling the call cancels the run'), and the fallback behavior of returning status AwaitingApproval when elicitation is unavailable. It leaves the shape of the returned run object implicit by deferring to await.

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 but front-loaded: the primary action and blocking behavior lead, followed by the Tasks-client variant, the approval path, and cancellation. Every clause carries distinct operational information, though the middle sentences pack three separate client-behavior branches into a single paragraph.

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 13-parameter orchestration tool with no output schema and thin annotations, the description covers the hard parts an agent would otherwise get wrong — that the call blocks, that cancellation propagates, and that approval may surface as either an input request or an AwaitingApproval status. The composition of the returned run is left to the await sibling rather than spelled out.

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% across all 13 parameters, so the schema does the heavy lifting for task, model, tools, budgets, and serviceClass. The description adds nothing parameter-specific beyond 'takes the same arguments as spawn', which is the correct baseline when the schema is fully documented.

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 compound action — spawn a sub-agent run and block until it finishes — and immediately positions it against siblings by noting it takes spawn's arguments and returns what await returns. An agent can tell this apart from spawn and await 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?

Clearly frames this as the combined spawn+wait path and explains that MCP-Tasks-opted clients instead get a pollable task, which is real routing guidance. It stops short of explicitly telling the agent when to prefer bare spawn (fire-and-forget) or await over this call.

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 annotations (openWorldHint, non-idempotent, non-destructive), the description discloses behavior the agent cannot get from structured fields: the call is non-blocking, a run can park in AwaitingApproval, an unknown parent handle or invalid arguments fail synchronously, and a run that later fails or exceeds budget keeps its handle and reports Failed/Cancelled with an error. Parent cancellation propagation is also stated.

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 non-blocking return and the `run` contrast are front-loaded in the first sentence, and each subsequent sentence carries distinct lifecycle or failure information. It is dense and long-sentenced for a 13-parameter tool, but almost no clause is redundant.

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 an asynchronous, 13-parameter orchestration tool with no output schema, the description covers the return value ({handle}), the approval pause path, budget and cancellation semantics, and the error modes. An agent has enough to invoke it correctly and to know which sibling handles the next step.

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 baseline is 3, but the description adds cross-parameter meaning the schema does not: budget exhaustion cancels the whole subtree, approval pausing ties to approveTools, and parent linkage determines cancellation. It does not walk through individual parameters such as maxTokens or serviceClass, so it stops short of a 5.

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 a sub-agent run') plus its defining property: it returns {handle} immediately instead of blocking. It explicitly names the sibling `run` as the blocking alternative, so the agent can discriminate between the two 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?

Gives an explicit when-to-use/when-not rule ('use run instead to start one and block until it finishes') and then maps the rest of the lifecycle onto named siblings: collect with `await`, inspect with `status`, stop with `cancel`, list tool servers with `tools`, answer approvals with `approve`. 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?

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds real value on top: the full return payload, the meaning of each status value, and the exact failure shape for an unknown handle. Minor gap: no mention of timing/consistency or cost of polling repeatedly.

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, front-loaded with purpose and the await alternative before the return enumeration. The long comma-separated field list is dense but every item is load-bearing given there is no output schema; bullets would read better.

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 output schema, the description correctly enumerates the return fields and conditional fields (answer on Completed, pendingApproval on AwaitingApproval). Success and error paths are both covered for a one-parameter read 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 100% and defines the single required handle parameter, so the baseline is 3. The description goes beyond it by specifying the error contract for an unknown handle ('{handle, error: "unknown handle"}'), which changes how an agent should handle bad input.

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 ('Read one run's current state') plus the key behavioral qualifier ('at once, without waiting'), and explicitly contrasts itself with the await sibling. An agent can distinguish it from await/spawn without reading 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?

Gives an explicit rule: use this for non-blocking reads, use await to block until runs finish. That names the alternative tool and the condition that selects it, leaving nothing 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 declare readOnlyHint and idempotentHint, so safety is covered; the description adds genuinely new behavioral context by disclosing that results include server provenance and are intended as input to spawn. It omits output shape (flat list? grouped by server?) and any size/truncation behavior, which is the only remaining gap.

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, front-loaded with what is returned, followed by the actionable use. No filler, no restatement of the tool name.

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 output schema, the description carries the burden of describing returns and does so at a high level (names + originating server). For a zero-parameter listing tool this is nearly sufficient; only the exact return structure is left 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?

Zero parameters, so the baseline is 4; the schema is empty and fully described by construction. The description's only parameter-adjacent content explains how the returned values feed spawn(tools: [...]), which is useful consumption semantics rather than input-parameter 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?

Specific verb 'List' plus a precisely scoped resource ('the tools sub-agents can use'), and it states what each entry carries ('with the server each comes from'). It also separates itself from the sibling spawn by naming it and describing the relationship, so an agent can tell the two apart 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?

Explicitly states the follow-up action: pass the returned names to spawn(tools: [...]) to restrict a run, which effectively identifies the alternative/next step in the workflow. It stops short of when-not-to-use guidance (e.g., that spawn without this list runs unrestricted), but the context is clear.

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