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

Annotations are absent, so the description carries the full behavioral burden and delivers only "append", which establishes write semantics but nothing else. It does not say whether the note persists, who or what reads it back (agents? the router?), whether notes are ordered or mutable, whether repeat calls duplicate, or whether any permission is needed. For a mutation into shared "routing memory", these omissions matter.

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 — verb and resource come first. It is arguably too terse for a tool with zero annotation and zero schema coverage, but nothing in it 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?

The tool is simple (2 flat params, one enum, no nesting) and there is no output schema to explain, so the bar is modest. Still, with no annotations at all the description should have covered what a call returns or confirms and whether the note is readable later — a real gap for an append-to-shared-memory operation.

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, and it partly does: "free-form delegation note" maps to the required `text` param and "project or user" maps directly to the `scope` enum's two values. However it adds no format, length, or content conventions for `text`, and does not state that `scope` is optional or what the default is.

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 ("Append") plus resource ("delegation note") plus destination ("project or user routing memory") — an agent knows the operation and target without opening the schema. It does not differentiate from any sibling, but none of the listed siblings (spawn_agent, send_message, record_outcome, etc.) overlap as note-writing tools, so ambiguity risk is low. "Routing memory" is jargon that is never defined, which keeps it below 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 never says when to use this tool, when not to, or what the alternative is. There is no guidance on choosing between a project-scoped vs user-scoped note — the only plausible decision point in the tool — and no mention of prerequisites or a prior step (e.g. spawn/delegate) that makes a note appropriate.

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 behavioral burden. It does disclose the most important trait—the branch survives the removal—which is real value. But it omits whether the worktree directory deletion is irreversible, what happens to untracked/uncommitted files implicitly covered by "clean", and what error surfaces when preconditions fail.

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; the preconditions and the branch-retention guarantee are packed efficiently into one clause structure. Nothing could be removed without losing signal.

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 one-param tool with no output schema the description covers the core action and the key side effect, but leaves the ambiguous parameter and the failure/dirty-worktree behavior unexplained. Adequate to attempt a call, not adequate to predict outcomes confidently.

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 the single parameter is named only "agent", which is ambiguous on a worktree-management tool—agent name, ID, or worktree owner? The description provides no clarification of what this identifier refers to or its accepted format, so the ambiguity is unresolved anywhere.

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 ("Remove ... managed worktree") qualified by two preconditions (inactive, clean) and one postcondition (branch retained). That is enough for an agent to know exactly what the tool affects. No sibling tool is named, but the sibling list contains nothing worktree-related, so differentiation is largely moot.

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 adjectives "inactive" and "clean" imply the preconditions under which the tool applies, but the description never says so explicitly, nor what to do instead when a worktree is active or dirty. An agent must infer when-not-to-use it from the adjectives alone.

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 does disclose genuinely non-obvious behavior: currentSequence is always returned even when events is empty, hasMore/nextSequence define pagination, and the agent is identified by both name and agent_id. It still never states that reading is non-consuming/idempotent (i.e., that polling does not advance a cursor) or what happens for an unknown agent, which is the main risk for a 'buffered log'.

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 what the tool is and its polling role, then layers pagination and naming guidance. Dense but nearly every clause carries information; the quoted "now" phrasing is slightly chatty but not wasteful.

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, so the description correctly takes on the return-shape explanation (currentSequence, events, hasMore, nextSequence), which is the right call for a polling tool. Gaps remain around read side effects, event ordering guarantees, and failure behavior when the agent does not exist.

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 only 33% (only limit is documented there), but the description compensates: it explains limit as a per-call cap plus the hasMore/nextSequence relationship, reframes since as a sequence seek point, and clarifies that agent may be given as name or agent_id. That is real added meaning beyond the bare string/integer 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?

States a specific resource (a buffered, normalized event log for one agent) and a concrete mode of use (background polling), which separates it from the blocking wait_for_agents and from get_agent_result. It never names a sibling explicitly, so sibling differentiation is implied rather than stated.

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 background polling" and "reliable floor for progress" imply when to reach for it, and the currentSequence note tells the agent how to jump to now rather than bisect. There is no explicit guidance on when NOT to use it versus wait_for_agents, get_agent_result, or list_agents, so the agent must infer the boundary.

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 two useful behavioral traits: results are persisted (durable across reconnect) and turn history is paginated. It says nothing about whether the call blocks, whether the agent must be finished, what error occurs for an unknown agent, or what the response payload 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?

One front-loaded sentence with no filler and no restatement of the tool name. It is efficient, though the brevity contributes to the specification gaps elsewhere rather than resolving them.

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 4-parameter tool with zero annotation coverage, no output schema, and zero schema description coverage, the description does far too little. An agent must still guess what a result object contains, how turn/limit/offset interact, and whether calling mid-run returns partial data.

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?

Four parameters at 0% schema description coverage, and the description never mentions any of them. 'agent', 'turn', 'limit' and 'offset' have self-explanatory names, but nothing clarifies whether 'turn' selects a single turn or a starting point, or what limit/offset window over.

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 (retrieve) plus two concrete resources (persisted results, paginated turn history), which is enough to separate it from get_agent_events and wait_for_agents in spirit. It stops short of naming a sibling or scoping what a 'result' is versus an 'event', so it is clear but not sharply differentiated.

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 'after reconnect or resume' gives a genuine usage condition, which is more than nothing. However it offers no exclusion or alternative — an agent cannot tell from this why it would call get_agent_result instead of get_agent_events, list_agents, or wait_for_agents.

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 disclosure burden, yet it never confirms this is a read-only/non-mutating operation, nor whether it requires a running agent session, nor what the result contains. 'Discover' implies a lookup but nothing about caching, side effects, or scope is 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?

A single compact sentence with no filler and no repetition of the title. It is front-loaded on the verb, though the trailing noun list reads as an unstructured enumeration rather than prioritized 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?

For a zero-parameter read tool with no output schema, the description should at least frame what comes back; the four enumerated item types gesture at the return payload but remain undefined terms ('pinned options', 'backend capabilities'). It is minimally adequate but leaves the agent guessing about the result shape.

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 baseline of 4 applies and there is nothing for the description to disambiguate. No parameter-related gap exists.

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 verb 'Discover' plus an enumerated list of item kinds gives a rough idea that this returns available configuration/capability information, but the phrasing 'callable configs, source files, pinned options and backend capabilities' is a grab-bag that never says what a 'config' is or what relation it has to agents. It does not distinguish itself from siblings such as list_models or list_agents, which an agent could easily confuse with it.

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 statement of when this tool should be called, no prerequisites, and no reference to any alternative among the many sibling list_* tools. The agent must infer usage from the name alone.

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 it does disclose concrete return content: lifecycle state, human-memorable name, timeout_seconds, concurrency cap, active count, and pending spawn count. It says nothing about pagination behavior, ordering, or how many results come back by default, which matters for a list tool with a cursor.

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

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

Three sentences, front-loaded with the resource and scope; every sentence adds something. Slightly padded by the return-field enumeration, but 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, so explaining returns is genuinely useful, and the description does that reasonably well. However, it leaves the entire filtering and pagination surface unexplained, which is a real gap for a five-parameter list 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 five parameters (limit, cursor, states, backend, updated_since) are completely undocumented in the schema. The description only gestures at state via "lifecycle state" and never mentions filtering by backend, timestamp, or how to page.

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 agents tracked by this host") and names the distinguishing detail of including agents restored after a reconnect. An agent can tell this is a host-scoped enumeration rather than an event or result fetch, though it doesn't call out a specific sibling by name.

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

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

"Refer to agents by name in later tool calls" gives downstream guidance, which implies this is a discovery step before spawn/send_message/get_agent_result. But it never states when to prefer this over list_agent_configs or get_agent_events, so the routing signal is only implied.

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 behavioral burden and does add meaningful context: it reports counters, allowance remaining, concurrency cap, active agents, and queued spawns. It does not explicitly state read-only safety or permission requirements, but the detailed output disclosure is substantial for a listing 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 description is front-loaded with the core resource and then enumerates the supporting counters in a compact, information-dense sentence. It is appropriately sized, though the long list of counters is slightly heavy for a single sentence.

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 must explain return values, which it does thoroughly for a listing tool. Its main gap is the unmentioned optional backend filter, but overall it gives an agent enough context to understand what will be returned and why the tool matters.

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 optional parameter (backend) with an enum of five values, and schema description coverage is 0%. The description never mentions this filter parameter or explains how the results change when a backend is supplied, so the parameter semantics are not compensated for in the description.

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 resource (config-sourced model roster) and the additional reporting it includes (usage counters, allowances, concurrency cap, active agents, waiting spawns). This clearly separates it from sibling tools like list_agents or list_agent_configs, though it does not explicitly name a sibling or exclusion.

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 explicit 'use this when' or 'do not use this when' guidance. The intended use is strongly implied by the content (model roster and usage/capacity reporting), but an agent must infer it rather than being told.

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 behavioral burden. It usefully discloses that the outcome feeds future routing decisions (i.e., the write is persistent and consequential), but it omits whether repeated calls overwrite an existing record, whether the verdict is required for routing to function, and what is returned.

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 tight sentence with no filler, and the core action is front-loaded. It is efficient but leaves no room for the missing usage and parameter detail.

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 mutation tool with zero annotation and zero schema-description coverage and no output schema, one sentence is not enough. The agent cannot tell how to fill score versus verdict or what the persistence semantics are.

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% for four parameters, so the description must compensate and largely does not. 'verdict' is hinted at by 'subjective verdict', but nothing explains 'agent' (name vs. ID), 'notes', or the 0-1 'score' and how it relates to the categorical verdict.

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 ('record') and resource ('subjective verdict on a completed delegation') plus the downstream purpose ('future routing decisions'). It is clearly distinct from the sibling set (stop_agent, resolve_approval, get_agent_result), though it never explicitly names a contrasting sibling.

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?

'on a completed delegation' implies the trigger condition, but there is no explicit when-to-use versus alternatives, no statement about whether it is required after every delegation, and no exclusions. An agent must infer that this is called after get_agent_result rather than instead of 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?

No annotations are supplied, so the description carries the full burden; it does disclose the most important trait — that the call blocks — and that it returns the agent's next state. However, it says nothing about whether a decision is final/irreversible, what 'allow_for_session' scopes to or how long that session lasts, or any permission requirements for resolving someone else's approval.

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 tightly written sentences, front-loaded with the action and followed immediately by the blocking behavior and return shape. No filler or restatement of the title.

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 3-parameter mutation-ish tool with no annotations and no output schema, the description covers the return state well (completed, another needs_approval, running) but leaves the decision semantics and the idempotency/irreversibility of resolving an approval unexplained. It is adequate to attempt a call but not complete enough to call confidently in edge cases.

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 only 33%: `message` is documented in the schema, while `request_id` and `decision` have no field descriptions at all. The description hints that request_id comes from a needs_approval result but never explains the three enum values (allow, allow_for_session, deny) or the consequence of each, so the most decision-critical parameter remains opaque.

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 ('Decide a parked approval request') and anchors it to the exact upstream trigger (spawn_agent/send_message's needs_approval result), which separates it cleanly from all listed siblings. It also previews the outcome space, so an agent knows this is the human-in-the-loop unblock step.

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 when a prior spawn_agent or send_message returned needs_approval. That is clear 'when to use' guidance with no ambiguity, but it never states exclusions or what to do if no approval is pending, so it falls short of a full 5.

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

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

With no annotations, the description carries the full burden and does so: blocking semantics, Codex uncached full-thread replay, a warning in the result, idle-time refusal (default 30 minutes, configurable via codexResumeIdleSeconds in models.yaml), the allow_expensive_resume escape hatch, and single-slot message queuing. These are exactly the non-obvious traits an agent needs before invoking a costly 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?

It is dense but front-loaded: the core action and its blocking nature come first, followed by the Codex caveats and then the queuing fallback. A few clauses are packed tightly, but every sentence carries operational 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?

For a 6-parameter mutation-like tool with no annotations and no output schema, the description covers the major risks (cost, refusal, blocking, queuing) thoroughly. It leaves run_in_background and effort unexplained, which is a modest gap given the otherwise rich behavioral detail.

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 67%, so the schema already documents agent, effort, timeout, and allow_expensive_resume. The description adds real context only for the idle-limit default behind allow_expensive_resume and restates timeout's echo behavior. It says nothing about effort or run_in_background, leaving those to the schema.

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

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

The description states a specific verb and resource: 'Resume a completed agent by ID or name, preserving its full history.' This is much clearer than the ambiguous tool name send_message / title 'Resume subagent', and it explains the mid-turn queuing case. It compares itself to spawn_agent ('Blocks like spawn_agent') but only for behavior, not to differentiate when to choose one over the other.

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 clearly frames the two usage modes: resuming a completed agent, and queuing a message when the agent is mid-turn, and it names list_agents/get_agent_events as the way to check delivery. It never explicitly says when to prefer spawn_agent over this tool, so the guidance is strong but not exhaustive.

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 the child starts with no parent context, that the call blocks by default until finish or approval, that it returns a resumable agent_id plus name and timeout_seconds, that a full concurrency cap waits rather than fails, and that model is mandatory unless the agent config pins one. Gaps remain around the approval handoff (which sibling resolves it) and what happens to worktree state after completion.

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?

Purpose and blocking behavior are front-loaded, and each sentence carries operational detail. The closing advisory-output paragraph is valuable policy but sits apart from the invocation mechanics, making the block slightly longer than strictly necessary.

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 15-parameter tool with a nested permission object and no output schema, the description covers returns, blocking/concurrency, timeouts, and model requirements well. It leaves group_id, max_turns, depends_on ordering semantics, result_schema validation, and permission handling to the schema, which is reasonable given high coverage.

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 87%, so baseline is 3, but the description adds real semantics: the timeout cap defaults to the agent config and is echoed as timeout_seconds, name is auto-assigned when omitted, and model has no default at any layer. It also flags that subagent output should be treated as advisory. Minor redundancy with schema text keeps it below 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 (delegate/spawn) and resource (fresh subagent), enumerates the supported backends, and explicitly frames itself as mirroring the native Agent tool. An agent can distinguish this from stop_agent, send_message, or get_agent_result without opening the 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 rule (implementation work needing search, iteration, or verification should go to a subagent rather than inline) and describes the default blocking behavior versus run_in_background. It does not name sibling tools (wait_for_agents, get_agent_result, resolve_approval) as explicit alternatives, which keeps it from 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?

With no annotations, the description carries the full burden and does well: it discloses that the signal reaches the entire process group so child shells/builds (cargo, check_task) are killed, and that the call is idempotent. It omits what happens to the agent's recorded state/result after the kill and whether permissions are required.

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 front-loaded sentence with no filler; the core action comes first and the process-group consequence and idempotency follow compactly.

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 single-parameter destructive control action with no annotations or output schema, the description covers the key risk (collateral process-group kill) and repeat-call safety. Only post-condition state and return behavior are left unstated, which is minor.

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 'agent' parameter is fully documented in the schema ('Agent ID or name'), so the baseline is 3. The description adds no further semantics about how the identifier is resolved when both an ID and a name could match.

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 ('Interrupt') plus resource ('running or approval-parked agent') and an explicit scope (the whole process group). It does not name the plural sibling stop_agents, so an agent must infer the difference between stopping one agent and stopping several.

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?

'Running or approval-parked agent' implies the applicable state, but there is no explicit when-not guidance, no prerequisites (permissions, whether the agent must be idle), and no mention of the alternative stop_agents for multi-agent cases.

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 must carry the behavioral burden. It discloses that queued tasks are cancelled and active agents interrupted, but says nothing about permissions, reversibility, partial failures, or what happens when both agents and group_id are supplied.

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 with zero wasted words; the action is front-loaded and the parameter note follows directly.

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 destructive batch operation with no annotations, no output schema, and 0% schema description coverage, the description is too thin. It omits batch/group semantics, conflict behavior, and failure handling that an agent would need to invoke it safely.

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 clarify the two parameters. It names both and indicates an either/or relationship, which adds some meaning, but it does not explain that agents is an array of IDs, what group_id represents, or how the two interact.

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 specific verbs ('cancel', 'interrupt') and resources ('queued tasks', 'agents'), and the plural/group framing distinguishes it from a single-agent stop. It does not explicitly name the sibling stop_agent, so it stops short of full sibling differentiation.

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 only says to supply 'agents or group_id'; that is parameter mechanics, not guidance on when to use this tool instead of stop_agent or other alternatives. There are no prerequisites, exclusions, or contextual triggers.

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 does the useful work of disclosing that waiting does not terminate agents and that the call is bounded at 60 seconds, which is real behavioral context. However, it says nothing about what the call returns, whether it blocks or polls internally, or what happens when the timeout elapses (empty result? error?) – all essential for a blocking tool with zero annotation coverage.

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 clauses with the key semantic (non-terminating join) front-loaded and no filler. It is arguably too telegraphic for a blocking tool, but nothing is wasted or buried.

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, no annotations, and 0% schema parameter descriptions mean the description carries the full burden, yet it never explains what a successful return contains (completed agent list? statuses? results?) or the timeout outcome. For a join/wait primitive whose entire utility is the value returned, that is a substantial 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?

Schema description coverage is 0%, so the description must compensate, and it partially does: "any/all" maps to the `mode` enum and "Maximum 60 seconds" restates the `timeout_seconds` bound. The required `agents` array – the most important parameter – gets no semantic treatment (are these IDs, names, spawned handles?), and default timeout behavior is unstated.

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?

"Event-driven join; returns on any/all completion, approval, or timeout" gives a specific operation (wait/join) and the conditions that end it, and "without stopping agents" distinguishes it from the stop_agents/stop_agent siblings. It lacks a plain statement of the resource being waited on (the agents in the `agents` param), so it falls just short of a 5.

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

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

The phrase "without stopping agents" implies this is the non-destructive way to wait rather than the termination path, which is useful routing. But there is no explicit guidance on when to prefer this over get_agent_result, get_agent_events, or repeatedly calling list_agents, and no mention of whether waiting is required before reading results.

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