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

With no annotations, the description fully carries the behavioral burden. It discloses that the session and its history are KEPT for inspection or resume, that the bridge will never re-prompt an aborted session, and contrasts with end_task's destructive behavior. This gives an agent a solid mental model of side effects.

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 sentences, each earning its place: purpose, persistence behavior, usage trigger, and sibling distinction. No filler or repetition. The structure is front-loaded with the core action and then adds necessary context.

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 one-parameter tool with no output schema or annotations, this description is remarkably complete. It covers what the tool does, when to use it, what happens to the session/history, and how it differs from its closest sibling. An agent has enough context to select and invoke it correctly.

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 explain the parameter. It does so implicitly by repeatedly referencing 'delegation session' and 'session,' making it clear that the required session_id identifies the delegation session whose round is being aborted. The format is not detailed, but the meaning is clear.

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 opens with a specific verb and resource: 'Abort the round running in a delegation session.' It clearly distinguishes itself from the sibling tool end_task by stating 'Not the same as end_task, which deletes the session.' This makes the purpose unambiguous and distinct.

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 provides an explicit usage condition: 'Use it when two spaced task_progress checks show no growth AND the worktree is unchanged.' It also identifies the alternative (end_task) and explains the key difference, giving clear when-to-use and when-not-to-use guidance.

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?

Despite having no annotations, the description thoroughly discloses behavior: the two spaced reads to prevent dying instances from passing, the deep mode running a real MCP call through a disposable delegation and deleting the session, and the token cost warning. This goes beyond what structured data provides.

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

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

The description is dense but every sentence earns its place: it lists the checks, explains deep mode, gives usage guidance, and warns about tokens. The structure is logical and front-loaded with the core purpose.

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 covers behavior, parameters, and usage thoroughly, which is impressive without annotations or an output schema. The only gap is that it doesn't explicitly describe the return value or response format, which would be helpful for an agent interpreting the health check results.

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% with descriptions for both parameters. The description adds semantic depth by explaining that deep=true triggers a real MCP call on the cheapest model and that the model parameter controls the probe model, tying it to the configuration's cheapModel default.

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 purpose: 'Check the whole delegation chain in one call' and enumerates the specific checks performed (credential file, server stability, auth, provider models, skills). It distinguishes itself from sibling task-management tools by presenting a distinct health-check role.

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?

Explicit usage guidance is provided: 'Run it with deep=true before a batch of delegations and whenever the environment smells broken' and 'Do not run deep=true in a loop: it spends tokens.' This tells the agent when and when not to use the tool, fulfilling the dimension fully.

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 carries the full burden of behavioral disclosure. It discloses that full history is preserved, inherits monitoring guarantees from delegate_task (hard wait ceiling, error propagation), queues a second prompt if used while a round is running, and explains that a session is bound to its original model. These are non-obvious behaviors that the agent needs to know before invoking the 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 three paragraphs, but every sentence earns its place. It front-loads the core action, then uses explicit USE IT FOR and DO NOT labels for scannability. It avoids fluff while covering purpose, usage, warnings, and parameter quirks. The structure is exemplary for an agent-facing tool description.

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 has no output schema, no annotations, and four parameters, the description is remarkably complete. It covers what the tool does, when to use it, when not to use it, behavioral guarantees, and parameter caveats. It even references delegate_task for shared guarantees, which is appropriate given the sibling context. An agent has sufficient information to decide when and how to invoke this tool correctly.

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 provides descriptions for model and effort, but prompt and session_id have no schema description. The description compensates by framing prompt as the 'follow-up message' and session as the 'existing delegation session,' which clarifies their roles. It also adds critical context for the model parameter: 'Only needed if the session predates a bridge restart' and 'Must be the SAME model the session was created with.' This goes beyond the schema, though it does not mention the effort override, which is already covered by 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 opens with a specific verb and resource: 'Send a follow-up message to an existing delegation session.' It clearly distinguishes itself from sibling tools by stating it is for continuing an existing session, and even contrasts with delegate_task, which is for launching a new session. This is not a tautology; it adds actionable specificity.

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 provides explicit USE IT FOR scenarios: 'iterating on work that came back good' and 'asking for the final summary when the answer came back empty.' It also gives clear DO NOT usage rules: avoid using while a round is running (check task_progress) and avoid switching models (use delegate_task instead). This is exemplary when/when-not/alternative guidance.

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 carries the full transparency burden and delivers richly: it discloses the agentic loop with MCP servers and skills, the SSE-with-poll-fallback monitoring and hard ceiling (OPENCODE_MAX_POLL_MS, default 45 min), automatic retries of empty responses, error mapping ('a session that ends in error comes back as an error, not as an empty success'), server restart behavior, and the critical trap that the model may still be running after a timeout — instructing the agent to check task_progress before continue_task.

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 long but justified for a high-complexity tool, and it is well-structured with scannable labeled sections (USE IT FOR / AVOID IT FOR / TRAP / CHOOSING THE MODEL - MANDATORY / RETURNS). The opening sentence front-loads the core purpose, and while the absolute-path requirement is repeated, it is deliberate emphasis on a critical failure trap rather than waste.

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 high-complexity tool with no annotations and no output schema, so the description must cover behavior, failure modes, and return values on its own — and it does. It explains the returns via session_id linked to sibling tools, documents timeouts, retries, error semantics, server restart, the model-selection process, and the still-running risk. There are no significant gaps for an agent to fall into.

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

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

Schema coverage is 100%, so the baseline is 3. The description nevertheless adds genuine value: the MANDATORY model-selection protocol (do not pick a model on your own; call list_models; propose ONE model with a one-line reason; ask user to confirm; reuse the choice for subsequent delegations) goes well beyond the schema's 'Ask the user when they have not chosen one.' It also reinforces the absolute-path trap for prompt/directory beyond the schema's own wording.

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 first sentence states a specific verb+resource+target: 'Delegate a coding task to an external model running in OpenCode.' It distinguishes from siblings by clarifying 'it is a full worker, not a single completion call' and linking the returned session_id to the sibling tools (continue_task, task_progress, abort_task, end_task), which makes the tool's role in the family unambiguous.

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?

Provides explicit when-to-use and when-not-to-use guidance: 'USE IT FOR: an atomic task whose design is already decided in the prompt. AVOID IT FOR: open design decisions... and long build/run loops.' It also names alternatives and prerequisites, telling the agent to 'Run bridge_health first when in doubt' and to 'Call list_models' before choosing a model.

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 carries full behavioral disclosure. It clearly states the destructive and irreversible nature ('DELETE', 'no recovery afterwards'), which is the key behavioral trait for a tool like this. The mention of 'clearing this bridge's registry' adds useful context about what gets modified server-side.

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 three sentences with no fluff. The main action is front-loaded, followed by critical usage context and a direct alternative. 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?

For a simple 1-parameter destructive tool, the description covers the essential context: action, timing, irreversibility, and alternative. It does not mention return values or error behavior, but with no output schema and a straightforward operation, these omissions are not critical.

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. However, it does not mention the session_id parameter or explain how to identify the delegation session. The parameter is self-explanatory from its name and schema, but the description adds no meaning beyond the input 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 clearly states the tool's action: 'End and DELETE a delegation session on the server, clearing this bridge's registry for it.' It uses specific verb-resource language and distinguishes itself from the sibling abort_task by explicitly noting the difference in recovery.

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 provides explicit when-to-use guidance: 'Use it once the work is accepted.' It also names an alternative for a different scenario: 'to stop the work but keep the history, use abort_task instead.' This makes the appropriate context unmistakable.

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?

Discloses that output is capped, always reports how many models matched and were left out, and warns not to assume missing models are absent. With no annotations, this is essential behavioral context.

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 paragraphs with no filler. Every sentence adds meaningful information about purpose, usage, or behavior.

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?

Despite no output schema or annotations, the description explains the return content, output cap, count reporting, and usage context with delegate_task, covering all needed information for a 4-param, zero-required 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 covers all 4 parameters with descriptions, so baseline is 3. The description adds context on using query/provider to narrow and limit to raise, which enriches parameter usage 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 clearly states it lists what the opencode server offers: providers/models, effort levels, context window, reasoning, and aliases. It explicitly positions itself relative to delegate_task, distinguishing it from sibling 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?

Explicitly instructs to use before delegate_task when the user hasn't named a model, and to find valid effort values. Also provides guidance on narrowing results with query/provider or raising limit.

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 carries the full transparency burden, and it delivers. It reveals that sessions survive bridge restarts, that the GET /session endpoint is directory-scoped, that the tool sweeps multiple scopes, that it prints swept scopes, and that a restarted bridge may miss sessions unless a directory is passed explicitly. This is rich, non-obvious behavioral context.

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 purpose, then uses a clearly labeled IMPORTANT block for critical behavioral caveats. Every sentence contributes essential information, and the length is justified by the complexity of the scoping behavior.

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 moderately complex behavior and the complete absence of annotations or an output schema, this description provides enough information for an agent to use the tool safely and effectively. It covers the main use case, edge cases, and how to work around bridge restarts, making it complete for its context.

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 input schema already describes the directory parameter in detail (including why it exists and how to use it), so schema coverage is 100%. The description adds a little extra context by mentioning the restart scenario, but it does not substantially go beyond what the schema already states. 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 clearly states a specific verb and resource: 'List delegation sessions from the SERVER'. It also distinguishes itself from nearby tools by framing the primary use case as recovering a session_id after a failed delegate_task, making its role unique among siblings like task_progress or bridge_health.

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 gives explicit when-to-use guidance: 'Use it to recover a session_id when a delegate_task failed without returning one.' It also explains the directory-scoped behavior and how to handle a restarted bridge. However, it does not explicitly name alternative tools or say when not to use this tool, so it stops short of a perfect 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 provided, the description fully discloses behavioral traits. It explicitly states the tool does not interrupt the delegation, that the todo list may not update during work, that the tool-call count is the reliable liveness signal, and what the tool does not answer. This is exactly the kind of contextual behavior an agent needs to correctly interpret results.

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 well-structured: a clear opening statement, followed by a labeled 'HOW TO READ IT' section that earns its length. Every sentence adds practical value, and the key message is front-loaded.

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?

Despite having no output schema, the description fully covers what the tool returns (tool-call count, last tools, todo list) and how to interpret those signals. It also addresses edge cases (stalled todo list) and exclusions (not progress estimation). For a single-param inspection tool, this is 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 description coverage is 0%, so the description must compensate for the sole required parameter session_id. However, the description never explains what session_id is, how to obtain it, or how it relates to the 'running delegation' mentioned. The phrase 'running delegation' implies the session context but does not add explicit parameter-level meaning beyond the schema's name.

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 opens with 'Inspect a running delegation without interrupting it', a specific verb+resource that clearly distinguishes this from mutating siblings like abort_task, continue_task, and end_task. It also enumerates the specific data it returns (tool-call count, last tools, todo list), further clarifying its purpose.

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 provides explicit guidance on how to interpret the tool's output, clearly stating when it should and should not be used: 'This answers alive vs stalled, never how much is left'. It also tells the user not to abort based on a stalled todo list and recommends an alternative ('git status --short') for ground truth on files. This goes beyond simple clarity.

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