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 one meaningful behavioral trait: 'Makes no model calls' tells the agent the call is side-effect-free and incurs no model cost. However, it says nothing about permissions, whether it reflects live or cached state, freshness, or return shape.

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

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

Two tight clauses, no filler, and the content list is front-loaded. It is terse to the point of under-specification, but nothing in the text is wasted.

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

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

No output schema and no annotations exist, so the description must do more than enumerate fields. It omits how the 'runtime' filter behaves and what the response looks like for an agent that must parse it, leaving the definition underspecified for even a simple 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 description coverage is 0%, so the description is responsible for explaining the single 'runtime' parameter, yet it never mentions it. The enum values (claude, codex, antigravity) are visible in the schema, but whether 'runtime' filters the result and what happens when it is omitted is unexplained.

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 enumerates the data the tool exposes (runtimes, accounts, login state, usage, cooldowns) but uses a bare noun phrase with no verb, so it never explicitly says it retrieves/lists this state. The resource ('accounts' of runtimes) is inferable from the name and content list, and it is distinguishable from the subagent_* action siblings, but the operation itself is left implicit.

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

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

There is no statement of when to call this versus the sibling tools (subagent_status, subagent_list, etc.), nor any prerequisites or exclusions. The only hint is 'Makes no model calls', which implies a cheap inspection call but does not route the agent explicitly.

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 but only discloses one behavioral trait: the cascading termination of every process the job started, which is genuinely useful and non-obvious. It omits permissions required, what occurs if the job already finished, reversibility, and return 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?

One sentence, front-loaded with the action and extended only with the scope detail that matters. 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?

A destructive single-param tool with no annotations and no output schema. The cascade behavior is covered, but the description should say what a successful cancellation returns and what happens on an already-completed or unknown job_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 single parameter is fully documented in the schema ('Job ID returned by subagent_start'). The description adds no syntax, format, or sourcing detail beyond the schema, so the baseline of 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?

Specific verb ('Stop') plus resource ('a running job') and it clarifies scope by noting it also terminates child processes the job started. An agent can distinguish it from siblings like subagent_status or subagent_wait, though it never names an alternative explicitly.

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

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

No guidance on when to cancel versus letting a job finish, checking subagent_status first, or whether cancellation is safe/needed after subagent_result. The description assumes the agent already knows it wants to cancel.

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

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

No annotations are provided, so the description carries the full burden, yet it discloses nothing about pagination, result count, whether the list is bounded, or error behavior. Only the sort order 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?

It is short and front-loaded, and "newest first" is a genuinely useful ordering fact. However, the brevity comes from omission rather than efficiency — the sentence is a fragment that leaves the core action unstated.

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 listing tool with no annotations and no output schema, the description should at minimum explain what a 'job' is, how many are returned, and what the limit controls. None of that is present, leaving the agent unable to call it correctly with confidence.

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 parameter 'limit' is never mentioned in the description, and schema description coverage is 0%. The schema does supply a default (20) and a maximum (100), which is the only constraint information available, so the description adds no semantic value.

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 is a noun fragment ("Recent jobs, newest first.") with no verb and no explicit statement that it lists subagent jobs. It conveys return ordering but an agent cannot distinguish it from siblings like subagent_status or subagent_result based on this text.

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

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

There is no guidance on when to call this versus subagent_status, subagent_result, or subagent_wait. No prerequisites, no exclusions, no alternatives named.

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 disclose the non-obvious dual-mode semantics: same tool either injects into a live job (requiring reply_to when answering) or spawns a continuation job after completion, returning that job. It omits what the live-path call returns, queueing behavior, and error cases, which keeps it from 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 clauses, front-loaded with the verb and resource, then the two timing branches. Telegraphic fragments ('While it runs:', 'After it finished:') are slightly rough but every clause carries 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 3-parameter tool with no annotations and no output schema, the description covers timing and continuation behavior but leaves the live-path return value and failure modes unstated. An agent can call it, but cannot predict the response shape in the while-running case.

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%; the description adds real meaning beyond the schema by tying reply_to to answering a question and by explaining that job_id refers to a running subagent in one branch and a finished one in the other. Only 'text' is left entirely 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?

States a specific verb and resource ('Send a message to a subagent') and then characterizes two distinct behaviors, which separates it from siblings like subagent_start. It doesn't explicitly name an alternative tool, but the mode descriptions make the distinction inferable.

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 state-based guidance: use it while the subagent runs for a follow-up or to answer a question, and after it finishes to continue the conversation as a new job. No explicit exclusions or named alternatives, so it stops short of 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?

No annotations are provided, so the description carries the full burden. It discloses the return contents but says nothing about failure modes—e.g., behavior when the job is not yet finished, whether it blocks, or error/auth requirements—which is a meaningful gap for a result-retrieval tool.

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

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

A single short fragment with no wasted words, but its brevity reflects under-specification rather than efficient front-loading. It is not a sentence and carries no lead action verb.

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

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

With no annotations and no output schema, the description must cover behavior and returns; it lists return contents but omits preconditions (job must be finished), failure behavior, and the meaning of max_chars. For a 2-parameter result tool this is inadequate.

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 50%: job_id is documented ('Job ID returned by subagent_start'), but max_chars has no description despite default/min/max constraints. The description adds no parameter meaning (no mention of truncation via max_chars), so it fails to compensate for the coverage gap.

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

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

The description names what the tool returns (final answer, outcome, account, session, cost) and scopes it to a 'finished job,' which distinguishes it from status/wait siblings that deal with in-progress jobs. It lacks an explicit verb, reading as a noun-phrase fragment, but the resource and scope are inferable.

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 when-to-use, when-not, or alternative named. The phrase 'finished job' hints that the job must be complete, but the description never says to call subagent_wait/status first or what to do if the job is still running.

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 substantial work: it discloses the background/async nature, the immediate job_id return (or inline result under wait_seconds), inherited account/plugins/MCP context, and that the host enforces account limits with a suggested action on refusal. It leaves gaps on timeout expiry behavior and resource consumption, but the return contract and account-limiting semantics are genuinely useful additions.

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?

Four dense sentences, front-loaded with what the tool does and its return contract, then the task-authoring guidance. Every sentence carries information, though the enumeration of shared resources ('MCP servers, plugins, skills and settings') is slightly 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?

For a 12-parameter launch tool with no annotations and no output schema, the description covers the essentials: it explains the return value (job_id or inline result), the background execution model, and the failure path. It is missing only ancillary behaviors like what happens at timeout_seconds or how the delegated job is monitored, which the sibling tools imply.

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% and the schema itself already documents the meaningful parameters (access trade-offs, resume_job, wait_seconds, cwd, add_dirs). The description only indirectly touches account ('under one of your accounts') and adds no syntax or semantics for model, effort, runtime, max_turns or timeout_seconds, so baseline 3 is 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?

The description gives a specific verb and resource ('Start a subagent') and immediately clarifies what that means operationally: another installed agent CLI runs one task in the background with shared MCP servers, plugins and settings. It doesn't explicitly name sibling tools to contrast with (subagent_wait, subagent_result), but no sibling could be mistaken for this launcher.

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 real task-authoring guidance ('complete, self-contained task: goal, scope, files, and how to check the result') and hints at the wait_seconds trade-off, plus what to do if a start is refused. However it never says when to use this versus kicking off and polling via the sibling tools, or when resume_job is the right entry point 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?

With no annotations, the description carries the full behavioral burden and largely drops it: it never states that this is a non-mutating read, whether the call blocks, what states a job can be in, or how often it can be called. The polling remark hints at the blocking semantics of wait_seconds but does not explain them.

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

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

Two short sentences, zero filler, with the resource identified up front and the operational tip second. It is efficient, though the terse noun phrase trades clarity for brevity.

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 is the only source for what a status response contains and how it relates to the five sibling job tools. It leaves the agent guessing about job state vocabulary and about when subagent_wait or subagent_result would be the better call.

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 both parameters are fully documented in the schema, and the description adds only a usage rationale for wait_seconds (avoid tight polling loops) rather than new format or constraint detail. Baseline 3 applies when the schema does the heavy lifting.

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 phrase 'State and progress of a job' identifies the resource but supplies no verb, so the agent must infer that this is a read/status-retrieval operation. It is not obviously differentiated from siblings like subagent_wait or subagent_result, which plausibly also report job state.

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?

'Use wait_seconds instead of polling in a tight loop' is real usage guidance, but it is guidance about how to call the tool, not about when to choose it over subagent_wait, subagent_result, or subagent_list. No when-not conditions or alternatives are named.

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

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

No annotations exist, so the description carries the full burden and does well: it discloses the dual wake conditions (job completion or subagent message/question) and the Claude Code behavior where long waits background themselves and notify on return. It does not disclose what happens when the wait times out or any error 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?

Two tight sentences with the core behavior front-loaded and the operational guidance second. The Claude Code backgrounding note earns its place by explaining why blocking here is safe, though it is slightly environment-specific.

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 must carry the return contract, and 'return what happened' is only a gesture at it. It also omits timeout semantics entirely, which matters for a tool with a 30-minute default and a 1-hour cap. Adequate but with a real gap for an agent that needs to know what a timeout yields.

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 2 params. 'One of the given jobs' usefully clarifies that job_ids is an any-of set rather than an all-of set, which the schema does not state. However, timeout_seconds (default 1800, max 3600) is never mentioned, leaving half the parameters undocumented in both description and 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 verb (wait) and resource (given jobs/subagents) plus the return condition: one job finishes or a subagent sends a message/question. It implicitly separates itself from the polling siblings via 'instead of polling', but never names subagent_status or subagent_result, so the sibling differentiation is inferred rather than explicit.

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

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

Gives a clear directive: 'call this after starting jobs instead of polling', which tells the agent both the trigger (jobs already started) and the anti-pattern to avoid. It stops short of naming the alternative tools it replaces, but the when/when-not is unambiguous.

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