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 mechanism (SIGTERM), which suggests graceful termination, but it doesn't explain side effects like cleanup, reversibility, or behavior when the subagent isn't running. Basic info is present but not comprehensive.

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 a single, focused sentence with zero wasted words. It communicates the action and key detail (SIGTERM) without fluff.

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 simple process-control tool with one parameter and no output schema, the description is reasonably complete. It covers what the tool does and how (signal). It lacks explicit mention of return values or error scenarios, but these are less critical for such a straightforward 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?

With schema description coverage at 0%, the description adds no explicit parameter guidance. However, the single run_id parameter is self-explanatory as an identifier, and its type is a simple string. The low complexity reduces the need for additional semantic exposition.

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 clearly states a specific action ('Terminate') and resource ('running subagent'), and the signal (SIGTERM) adds precision. This distinguishes it from sibling tools like spawn_subagent or list_subagents, which serve different purposes.

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

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

The description implies clear usage context: use when a subagent is running and needs to be stopped. The word 'running' implicitly excludes finished subagents, providing a basic exclusion, though no explicit alternatives are mentioned.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It adds value by revealing the output format (NDJSON) and the polling/catch-up use case, but it leaves gaps: it doesn't explain ordering, the inclusive/exclusive semantics of since_event_id, default limit behavior when limit is omitted, or what happens when no events exist.

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 focused sentences. The first sentence states the core functionality and key parameter; the second gives usage context. No fluff, no repetition.

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 relatively simple and the description covers its purpose, output format, and intended usage. However, with no output schema and no annotations, it should more thoroughly explain run_id semantics and limit behavior, and how run_id relates to other subagent tools. The absence of these details leaves an agent guessing on how to correctly construct a 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 description coverage is 0%, so the description must compensate, but it only hints at since_event_id ('since a given event id'). It doesn't explain run_id (how to obtain it, that it identifies the subagent) or limit (pagination/result size). The schema provides types and constraints but not semantic meaning.

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 clearly states the action ('Fetch'), the resource ('NDJSON events emitted by a subagent'), and the key scope ('since a given event id'). It also naturally distinguishes this tool from sibling tools like get_subagent_status and get_subagent_result by focusing specifically on the event stream.

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 explicitly identifies when to use the tool: for polling or catching up after a notifications/resources/updated ping. This gives clear contextual guidance, though it doesn't explicitly mention when not to use it or name alternative tools for exclusions.

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 must disclose behavioral traits. It does reveal an important constraint (only terminated runs produce a result), but it does not mention what happens for running runs, error behavior (e.g., run not found), or whether this is a read-only operation. It gives partial transparency.

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 a single, tightly worded sentence. It front-loads the action ('Return the final structured completion payload') and immediately follows with the condition for use. No wasted words.

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?

This is a simple tool with one parameter and no output schema. The description covers the core behavior (returns final payload), the applicable statuses, and the structured nature of the output. It does not detail return values, but given the simplicity and sibling context, the description is sufficiently complete.

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

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

Schema coverage is 0% and the description does not elaborate on the run_id parameter. It only appears in the schema with a type and required flag. The parameter name is self-explanatory, but the description adds no additional meaning (e.g., format, how to obtain it), and the low coverage requires compensation that is absent.

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 clearly states the tool's function with a specific verb ('Return') and resource ('final structured completion payload for a terminated run'). It also specifies the exact statuses that qualify, effectively distinguishing it from sibling tools like get_subagent_status and get_subagent_events.

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

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

The description implies when to use the tool: after a run has terminated (status in the listed set). It provides clear context for the expected state of the run, though it does not explicitly name alternative tools or explicitly state 'use this instead of get_subagent_status'.

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. It merely says 'Return the current status' without disclosing whether this is read-only, whether it polls, what constitutes 'status', or any side effects. The safety profile is implicit at best.

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 a single, efficient sentence with no filler. Every word earns its place.

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

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

For a simple tool with one parameter and no output schema, the description is minimally viable but incomplete. It does not describe the format or possible values of the 'status' return, nor does it offer usage guidance. It is adequate but leaves gaps.

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 schema has 0% description coverage, but the single parameter 'run_id' is semantically clear from its name and the phrase 'subagent run'. The description does not explicitly map run_id to the identifier, but context makes it obvious. It adds minimal value beyond 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 clear verb ('Return') and resource ('the current status of a subagent run'). It communicates the core function, though it does not explicitly distinguish itself from sibling tools like get_subagent_result or get_subagent_events.

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 is provided on when to use this tool versus alternatives (e.g., get_subagent_result or get_subagent_events). There are no mention of prerequisites, context, or exclusions.

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 only states 'List subagent runs known to this harness,' implying a read-only operation but giving no details about scope, pagination, result format, or any side effects. The phrase 'known to this harness' is vague and unexplained.

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 one short sentence with no filler words. It conveys the core action efficiently and earnestly.

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 simple list tool, the description is under-specified. It does not clarify the return value (e.g., run IDs, statuses, timestamps) or any filtering behavior beyond what the schema hints at. Without an output schema, this lack of context makes the tool's behavior ambiguous.

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

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

Schema description coverage is 0%, and the description adds no meaning to the parameters. The 'since' parameter's semantics (since what? timestamp? run index?) are unclear, and 'status' only lists enum values in the schema without explanation. The description fails to compensate for the lack of schema description coverage.

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 uses a specific verb 'list' with a clear resource 'subagent runs', making the tool's purpose immediately clear. It also distinguishes from siblings like get_subagent_status, which targets a single subagent, and prune_subagents, which implies removal.

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 use this tool versus alternatives. It does not mention alternatives, exclusions, or typical use cases. The description merely states what it does without contextual direction.

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

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

No annotations are provided, so the description carries the burden. It explicitly discloses the destructive nature ('delete'), explains the default retention behavior, and highlights the dry_run safety feature. Some details like permanence or confirmation are missing, but the description is more informative than typical mutation tools.

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 two sentences, front-loaded with the core action and quickly moves to overrides and dry_run. Every clause is meaningful and there is no redundancy.

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 description gives a good high-level understanding but lacks parameter-level detail and expected output/return behavior. Since there is no output schema, more explanation could help. However, the core purpose and safety preview are covered, making it minimally complete.

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

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

Schema coverage is 0%, so the description must compensate. It only explains dry_run and the concept of overrides, but does not clarify the meanings of keep_last, max_age_days, or compress_after_days. This leaves significant ambiguity for parameter usage.

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 clearly states the tool's action ('Compress / delete') and resource ('old terminal runs'), which is specific and distinguishes it from sibling tools focused on subagent lifecycle. It also mentions the retention config, adding context about default behavior.

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 explains when to use the tool (for cleanup based on retention config) and when to use overrides or dry_run. It does not explicitly name alternatives, but no direct alternative exists among siblings, so the context is clear enough.

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 must disclose behavior itself. It adds useful constraints such as 'resumes the same chat' and 'errors if a turn is already in flight', which go beyond the schema. However, it does not explicitly state side effects (e.g., that it mutates the subagent's conversation state) or any permissions 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?

The description is a single sentence that is front-loaded with the action and resource. Every word adds value, with no repetition of schema or redundant details.

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 simple two-parameter send-message tool, the description covers the core behavior, the key error case, and the effect ('resumes the same chat'). No output schema exists, but the description does not need to explain return values. The main gap is lack of explicit permission or side-effect notes, but the tool's simplicity keeps it reasonably complete.

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

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

Schema coverage is 0%, so the description must compensate. The description mentions 'running subagent', which hints that run_id refers to that subagent, and message is the follow-up text. However, it does not explicitly map parameters to their roles, and the parameter names are already fairly self-explanatory.

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 clearly states the action ('Send a follow-up message'), the target ('a running subagent'), and the effect ('resumes the same chat'). It is distinct from sibling tools like spawn_subagent or cancel_subagent, which handle different lifecycle operations.

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

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

The description implies use when you need to continue an existing conversation with a subagent. It does not explicitly name alternative tools, but the context ('running subagent') makes it clear this is for follow-ups, not initial spawns or status checks.

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 transparency burden. It honestly explains the immediate return with a run_id, asynchronous execution, allowlist requirement, and how to observe progress. This provides strong behavioral context beyond a simple launch statement.

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 short, purposeful sentences with no filler. The most important facts (launch, async, run_id) are front-loaded, and observation guidance is given next. Every sentence earns its place.

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

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

Given the tool's complexity (8 params, async behavior, no output schema), the description covers the key elements: what it does, return value, allowlist, and how to track progress. It doesn't detail every side effect, but it's sufficient for effective use alongside the schema and sibling tools.

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

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

Schema description coverage is 100%, so the parameters are well-documented elsewhere. The description adds only a small amount of extra meaning (e.g., prompt, allowlist) but mostly doesn't need to, hence the baseline score.

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

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

The description uses the specific verb 'Launch' with resource 'Cursor subagent' and 'give prompt', clearly stating the tool's core function. It also notes the asynchronous return of a run_id, which distinguishes it from sibling event/status/result 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 implicitly establishes this as the tool to create subagents among siblings that manage them. It gives follow-up guidance ('Use get_subagent_events or subscribe...') and a precondition ('Model must be in the allowlist'), but lacks explicit 'when not to use' or alternative scenarios.

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