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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety and repeatability profile is covered. The description's 'deterministic descriptors' echoes idempotence, while 'fresh availability' adds some behavioral context about current state, but it does not disclose edge cases or workspace identity requirements.

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; every word contributes meaning. The description is appropriately short for a simple read-only listing tool with rich structured metadata.

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 one required parameter, complete annotations, and an output schema available, the description covers the essential operational context. The main gap is the absence of usage guidance, but the structured metadata compensates enough to make the tool invocable and understandable.

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%, and the workspace parameter is documented as 'Reference to exactly one durable workspace identity.' The description adds no parameter-level detail, so the baseline score 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?

The title clearly names the resource ('Agent Backends') and the description provides a verb ('Return') and scope ('for a workspace'), so the core action is knowable. However, 'deterministic descriptors' is abstract and the description does not explicitly distinguish this from conceptually related siblings like agent_status or agent_list.

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 about when to choose this tool over alternatives, no exclusions, and no mention of sibling tools. 'For a workspace' provides minimal context but not a decision rule or boundary for appropriate use.

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

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

Annotations already mark the operation as destructive and idempotent, and the description echoes 'idempotent' while adding the 'authorized' qualifier. It does not describe what cancellation actually does to the job or what state changes occur, so added transparency beyond annotations is limited.

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 concise sentence with no filler or repetition. It front-loads the key action and object, making it quickly scannable for an agent.

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, idempotent operation with two required parameters including a nested workspace object, the one-sentence description is minimal. The output schema and annotations help, but the description still leaves gaps around authorization, failure behavior, and what cancellation implies for the job's lifecycle.

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 only 50%; workspace has a description but job_id does not. The tool description does not explain either parameter in detail, nor does it connect 'one ... durable job' to job_id or workspace meaning, so it fails to compensate for the low 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 states a specific action ('Request idempotent cancellation') and a clear resource ('one authorized durable job'). The verb 'cancel' distinguishes this tool from sibling agent_* tools such as agent_start, agent_status, and agent_continue.

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 intended use is implied: cancel a durable job. However, the description does not explicitly say when to use this tool versus alternatives like agent_fork or agent_continue, and it does not mention prerequisites or conditions for cancellation.

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

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

Beyond the annotations, the description adds useful behavioral context: the turn is 'queued' (asynchronous/non-blocking) and 'durable' (persistent), and the session must be 'authorized' beforehand. It does not elaborate on the destructive behavior implied by destructiveHint=true, but the annotation already covers that signal, so the description adds meaningful context without contradicting the annotations.

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 front-loaded sentence with no filler or repetition. Every word contributes meaning: the action is 'Queue,' the target is a 'durable turn,' and the precondition is an 'existing authorized session.'

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 7 parameters, nested objects, an output schema, and several closely related siblings, this one-sentence description is not complete enough for reliable invocation. It omits guidance on configuration, file references, idempotency, and context, and does not clarify how this differs from agent_respond or batch_prompt.

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 only 14%, so the description needed to compensate by explaining key parameters, but it only hints at session_id via 'existing authorized session.' It says nothing about workspace, prompt, config, context, file_refs, or idempotency_key, leaving the agent to infer their roles from the bare 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 names a specific verb ('Queue') and resource ('a durable turn against an existing authorized session'), which clearly communicates that this tool continues an already-running agent session rather than starting a new one. It distinguishes from siblings like agent_start and agent_fork, though it does not name them and 'durable turn' is somewhat jargon-heavy.

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 'existing authorized session' implies the tool should be used when a session already exists and is authorized, which provides some usage context. However, it gives no explicit guidance about when to prefer this over agent_respond, agent_fork, batch_prompt, or prompt, and lists no alternatives 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?

Annotations state destructiveHint=true, readOnlyHint=false, and idempotentHint=false, indicating a mutating, non-idempotent operation. The description adds the word 'Queue', implying the diagnostic is submitted asynchronously, but it does not disclose what side effects the diagnostics have (e.g., does it modify backend state, send telemetry, or run commands?). It also does not clarify the meaning of 'without conditionally hiding the tool' in behavioral terms. No contradiction with annotations, but the description adds minimal behavioral context beyond what annotations already cover.

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 short sentence with no filler, so it is structurally concise. However, it is under-specified to the point of being unhelpful. The phrase 'without conditionally hiding the tool' appears to be an instruction about tool visibility rather than functionality, wasting space. A useful description would need more detail to meet the minimum viable standard.

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 complex schema (nested config with 7 subfields, workspace object, idempotency_key) and its destructive, asynchronous nature, the description is far from complete. It does not explain what 'backend diagnostics' are, what the tool returns (output schema exists but is not referenced), or any required setup. Sibling tools like agent_status and agent_backends likely have overlapping functions, and without context the agent cannot reliably choose this tool. The description leaves too many unknowns.

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 description provides zero information about the parameters (backend, workspace, config, idempotency_key). While the schema includes descriptions for some fields (config and workspace), schema description coverage is only 25%, meaning most parameters lack explanation. The description does not compensate for this gap, leaving agents to guess the purpose and format of the config object and idempotency key.

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 mentions 'Queue backend diagnostics', which gives a verb and a resource, indicating the tool queues diagnostics for the backend. However, it does not elaborate on what 'diagnostics' entails, whether it runs tests, collects logs, or checks health. It also does not distinguish it from sibling tools like agent_status or agent_review, which might also involve diagnostic checks. The phrase 'without conditionally hiding the tool' is confusing and does not clarify the tool's 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?

No guidance is given on when to use this tool versus alternatives. The description does not mention any prerequisites, conditions, or scenarios that call for diagnosing a backend. There is no mention of alternatives or exclusions, leaving the agent without direction on selection.

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

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

Annotations already mark the operation as destructive and not idempotent; the description adds the backend-capability prerequisite, which is genuine behavioral context. It does not go deeper into what forking does to the original session, whether config is copied, or what makes it destructive, but the annotation coverage lowers the burden somewhat.

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 front-loaded sentence with no wasted words, and the key scoping detail ('existing session', 'backend advertises that capability') comes early. It could carry a bit more operational context, but as a concise statement it is effective.

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 has seven parameters, a nested config object, destructive annotations, and no usage guidance in the description. An output schema exists, which covers return shape, but the description leaves important gaps around when to fork versus start/continue, parameter roles, and behavioral consequences.

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 only 14%, and the tool description adds no parameter-level meaning. Most parameters like prompt, context, file_refs, session_id, and idempotency_key are left for the agent to infer from names alone, and the nested config object is only explained inside the schema, not in the tool 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 clearly identifies the action ('Fork') and the resource ('an existing session'), and adds a meaningful condition ('when its backend advertises that capability'). This distinguishes it from agent_start and agent_continue, though it does not explicitly name those siblings, so it stops short of a top score.

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 'when its backend advertises that capability' gives a condition for using the tool, which is useful context. However, there is no explicit guidance on when not to use it or which sibling tool should be used instead, so usage routing is left mostly to inference.

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

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

Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond those annotations by noting that only one page is returned and that jobs are durable. There is no contradiction between the description and the annotations.

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 front-loaded sentence beginning with the verb 'List', and each phrase adds either scope, resource type, or a pagination constraint. It is concise and easily parsable, with no redundant 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?

Given four parameters, a nested workspace object, and many sibling agent_* tools, the definition is only minimally complete. It conveys pagination only through the word 'page', leaves the states filter to be inferred from the schema enum, and does not differentiate usage from agent_status or agent_result. The presence of an output schema reduces the need to describe return values, but key guidance is still missing.

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

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

Schema description coverage is only 25%, with only the workspace object receiving a description. The tool description alludes to pagination ('one page') and workspace scoping, but does not explain limit, cursor, or states, and therefore does not compensate for the low schema 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-resource pair ('List ... durable jobs') and adds a mandatory scope ('for an explicit workspace'), making the operation distinct from sibling tools such as agent_start, agent_status, and agent_result. The phrase 'authorized page' is slightly opaque, but the core purpose is 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?

The description implies when to use the tool: to enumerate durable jobs for an explicit workspace, with only one page returned at a time. It does not name alternatives or provide exclusions, so an agent must infer when agent_status or agent_result would be more 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?

Annotations already provide idempotentHint=true and readOnlyHint=false, so the description does not need to restate mutation safety. It adds some scoping context with 'pending' and 'durable job', but it does not explain side effects, lifecycle changes, or what happens after resolution. No contradiction with annotations.

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 with no filler or redundant restatement of field names. It front-loads the core action and scope, making it easy to scan. Every word contributes to the meaning.

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 complex: four required parameters, a nested oneOf response schema, and a workspace object. The description offers almost no lifecycle context, such as how to discover the pending input_id or what 'provider interaction' means in practice. While an output schema exists, the description still lacks enough context for confident invocation.

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

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

Schema description coverage is only 25%, and the description does not compensate. It never explains job_id, input_id, workspace, or how to construct the response field. The schema's oneOf block documents acceptable response shapes, but job_id and input_id remain opaque, and 'typed provider interaction' is too indirect to substitute for real parameter guidance.

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 ('Resolve') and clearly defines the resource as 'one pending typed provider interaction for a durable job.' The title 'Respond to Agent Input' reinforces the purpose. This is specific enough to distinguish the tool from siblings like agent_start or agent_continue.

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 clear context for when to use the tool: when a pending typed provider interaction for a durable job needs to be resolved. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5, but the intended usage is unambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds genuine behavioral context beyond those annotations by disclosing that the call can return a 'pending' variant — signaling the job may not be finished yet — as well as terminal states. It does not cover error or not-found behavior, but with the annotation bar lowered, the added variant context earns a 4.

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 12-word sentence with no filler, front-loading the verb and resource immediately. Every word earns its place; brevity here is achieved without redundancy, even though it sacrifices some contextual richness that other dimensions capture.

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?

An output schema exists (covering return values) and annotations fully cover the safety profile, so the description need not repeat those. However, it leaves the relationship to agent_status unexplained, uses the undefined term 'durable result variant', and gives no hint about how to obtain job_id or handle a pending result — clear gaps for a tool with a required nested workspace object.

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 only 50%: workspace has a schema description, but job_id has none, and the tool description adds nothing about either parameter. job_id is a required, unformatted string whose provenance (e.g., from agent_start) is never explained, and the description does not compensate for this gap. The workspace object is at least partially covered by the schema, but the critical job_id parameter remains semantically undocumented.

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 ('Return') and resource (the durable result variant of an agent job) and enumerates the four possible variants (pending, succeeded, failed, cancelled), which helps distinguish it from siblings like agent_status. However, the phrase 'durable result variant' is internal jargon and the description never explicitly says it is fetching the outcome/payload of a job started by agent_start, so it stops 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?

There is no guidance on when to call this tool versus its natural alternatives among the siblings, particularly agent_status (which presumably reports job state) and agent_list. The description neither states when polling is appropriate, how the 'pending' state should be handled, nor when another tool should be chosen instead. Usage is only weakly implied by the name and title.

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

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

The description adds a small behavioral note about queueing and a support condition, but does not elaborate on side effects (e.g., destructive behavior) or delivery mechanics. Annotations already declare destructiveHint: true and readOnlyHint: false, so the description contributes limited extra context beyond what is already structured.

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, front-loaded sentence with no fluff. It clearly states the action and a condition, achieving excellent conciseness and structure.

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 tool with nine parameters, nested objects, and an output schema, this one-line description is severely under-specified. It provides no guidance on constructing the workspace, configuring the review, or interpreting the output, making correct invocation highly unlikely.

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 description does not explain any of the nine parameters. It alludes to 'target and delivery' but provides no semantics for them. With schema description coverage at only 22%, this is a significant gap that the description fails to compensate for.

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

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

The description states a specific action ('Queue a typed review') and a condition ('when the session backend supports its target and delivery'), clearly identifying the tool's core purpose without being a tautology. However, it does not explicitly differentiate from sibling tools like agent_session_review, so it falls 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?

It gives a conditional prerequisite regarding session backend support, which hints at when the tool is appropriate. But it does not name alternatives or specify when to use this tool instead of batch_prompt or agent_session_review, leaving usage guidance only partially developed.

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

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

The annotations already signal destructiveHint=true, idempotentHint=false, openWorldHint=true, and readOnlHint=false. The description adds that the session is 'durable' and requires an explicit workspace, which is useful context, but it does not explain what resources are created, what side effects may occur, or what 'durable session' entails.

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 no filler. It front-loads the action and the most important constraint, making it easy to parse quickly.

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 complex tool with 8 parameters, 3 required, and destructive/open-world annotations, yet the description provides almost no workflow context, no explanation of what a 'durable session turn' means, and no guidance relative to sibling tools. The output schema and annotations help, but they do not make up for the missing high-level usage semantics.

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 only 13% and eight parameters, the description needed to compensate by explaining key parameters like backend and prompt. It only reinforces the workspace concept and leaves required fields and config, context, file_refs, access_policy, and idempotency_key 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 names a specific action ('Start'), a specific resource ('a durable session turn'), and a scope ('in an explicitly selected workspace'). It clearly distinguishes this from continuation tools like agent_continue and one-shot prompt tools, though it does not name any sibling 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?

The phrase 'Start a durable session turn in an explicitly selected workspace' implies this tool is for beginning a new persistent agent run in a chosen workspace, contrasting with continuing or responding to an existing session. However, it gives no explicit when-to-use or when-not-to-use guidance and does not name alternative tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds modest context with 'authorized' and 'durable', implying access requirements and persistence, but does not explain behavioral details like consistency, blocking, or failure modes.

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 concise sentence with no filler and it front-loads the action. It loses a point for the jargon-heavy phrase 'status projection', which could be clearer.

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 an output schema, strong safety annotations, and only two required parameters, the tool is reasonably simple. However, the description provides no rationale for selecting this tool over status/result siblings and only vaguely hints at authorization, leaving the context 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 description coverage is only 50%; job_id is undocumented and the description does not explain either parameter. The workspace object has a schema-level description, but the description text adds no parameter semantics, so it does not 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 uses a specific verb ('Return') and identifies a singular resource ('one authorized durable job status projection'), making the core function clear. It also distinguishes from sibling tools by emphasizing 'one' status versus agent_list or agent_result, though the term 'projection' is somewhat vague.

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 given about when to choose this tool over sibling tools such as agent_list, agent_result, or agent_cancel. The description only states what it returns and leaves all usage-context decisions to the agent.

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

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

Beyond the annotations (destructiveHint=true), the description adds meaningful behavioral context: it discloses server-side fan-out with asyncio.gather and a semaphore, explaining true parallel execution within a single MCP call. It also notes that single-task usage is valid, which is a non-obvious trait. This adds transparency without contradicting the annotations.

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 compact and well-structured. The first sentence states the primary purpose, the second provides behavioral context, and the third gives routing guidance. Every sentence contributes essential information with 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?

Given the tool's complexity (parallel fan-out, concurrency limits, multiple options), the description covers the core behavior and usage distinction. An output schema exists, so return values are handled. It could mention potential failure modes or concurrency limits, but the max_concurrency parameter description already covers that. Overall, it is sufficiently complete for an agent to call 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?

The schema already covers 67% of parameters (tasks and max_concurrency have descriptions). The tool description adds little parameter-level detail; it references parallelism and concurrency but does not elaborate on individual fields. With high schema coverage, the baseline of 3 applies, and the description does not meaningfully raise it.

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 multiple prompts to CLI runners in parallel.' It explicitly labels itself as the 'primary tool' and distinguishes it from the sibling 'prompt' for single-task convenience, making the tool's role immediately clear.

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 usage guidance: it states when to use this tool (multiple prompts, parallel execution) and when to use the alternative (single task: 'use prompt for convenience'). This directly routes the agent to the correct sibling without ambiguity.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds behavioral context by explaining that it reverts to per-call defaults and returns a confirmation string, clarifying the meaning of 'destructive'.

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 extremely concise (two sentences), front-loaded with the purpose, and includes the return type. Every word is 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?

Given the tool has 0 parameters and annotations cover safety traits, the description is complete: it states what it clears, the effect, and the return value. No gaps for invoking 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?

With 0 parameters and 100% schema coverage (vacuously), the description adds no parameter information beyond the schema. Baseline for 0 params is 4.

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 'Clear' and resource 'persistent preferences', and distinguishes it from siblings like 'set_preferences' by stating it reverts to per-call defaults.

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 no guidance on when to use this tool versus alternatives like 'set_preferences'. It lacks context about prerequisites or appropriate scenarios.

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 takes on the burden of revealing behavior. It explicitly discloses the GET /find and GET /file/content call chain and the max_files limit, indicating a read-only operation. It does not discuss rate limits or edge cases, but the core behavior is transparent for a simple search 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 two short sentences with no wasted words. The main purpose is front-loaded, and the endpoint chain is presented succinctly in the second 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?

The tool is simple with only two parameters and an output schema, so the description does not need to explain return values. It covers the core operation, the endpoint chain, and the max_files behavior adequately, though examples or query format hints would make it 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 is expected to explain parameters. It does clarify that max_files limits the number of results, but query is only implied by the phrase 'Search project files' and not given explicit semantics such as search syntax or scope. This is partial compensation for the low schema 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 clearly states that the tool searches project files and returns matching results, which is a specific verb and resource. It does not explicitly differentiate from sibling tools, but the focus on file search is distinct from the agent and configuration siblings listed.

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 clear context for when to use the tool: whenever you need to search project files and retrieve matching file contents. It does not mention exclusions or alternatives, but none of the sibling tools appear to perform a similar file-search function.

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, and it provides strong transparency by spelling out the ordered chain of GET endpoints: session, message, diff, and todo. This makes the read-only, multi-call nature clear, though auth requirements and failure behavior are not disclosed.

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

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

Two sentences with no wasted words. The purpose is front-loaded, and the endpoint chain is compactly listed in one line, making the behavioral flow immediately readable.

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 captures the full endpoint flow and the single required input, and an output schema exists so return-value documentation is not needed. It could add guidance on when to prefer this over agent_review or agent_diagnose, but as a standalone review action it is 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 description coverage is 0%, so the description must compensate. The path template 'GET /session/{id}' embeds the single parameter and conveys that session_id is the session path identifier, which is enough despite not specifying format or length.

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 a concrete operation—'Review a session's messages and file changes'—with a clear resource and outcome. The GET /session/{id} chain reinforces the exact scope, and the session-scoped phrasing distinguishes it from sibling agent_* review/diagnose 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?

No explicit when-to-use guidance, exclusions, or alternatives are provided. The description only implies this is for reviewing a session, which does not help an agent choose between this and similarly named tools like agent_review or agent_diagnose.

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

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

Annotations already indicate this is a non-read-only, non-destructive, idempotent operation. The description adds no behavioral detail beyond the act of setting credentials, such as whether existing credentials are overwritten, how credentials are stored, or whether any validation occurs.

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, front-loaded sentence with no filler. It is efficient, though it is so brief that it leaves useful operational guidance 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 an auth-setting tool with minimal schema parameter documentation, the description is too thin. It lacks usage boundaries, side-effect disclosure, and parameter detail, leaving an agent without enough context to confidently invoke it correctly among related configuration 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?

The schema has 0% parameter description coverage, so the description must compensate. It relates provider_id and credentials to the overall purpose, but does not explain acceptable credential shapes, required fields, or how provider_id should be specified.

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 and target: 'Set authentication credentials for a provider.' This clearly communicates the tool's core purpose and distinguishes it from generic configuration operations. Some ambiguity remains with opencode_update_config, but the credential-specific focus is strong enough.

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 given about when to use this tool versus siblings like opencode_update_config, set_preferences, or clear_preferences. There are no preconditions, exclusions, or alternative tool mentions, so an agent must infer usage context 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?

Annotations already indicate the operation is not read-only, is idempotent, and is non-destructive, so the description adds no extra behavioral context. It does not explain whether the update merges or replaces the existing configuration, whether a restart is needed, or what side effects may occur.

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 short sentence with no fluff. It front-loads the verb and resource, making it easy to parse quickly.

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 complex because its only input is an open-ended config object, yet the description provides no detail about what fields or settings can be included. Although an output schema exists and annotations are present, the description still leaves a significant gap for the agent to understand how to construct a valid config and what the tool's effective scope is.

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 only parameter, 'config', is an arbitrary object with no property descriptions in the schema and a schema description coverage of 0%. The description merely says 'configuration', which adds minimal semantic value beyond the parameter name. It provides no examples, keys, format, or constraints.

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 names the action ('Update') and the resource ('OpenCode server configuration'). It is a meaningful statement rather than a tautology, and 'server configuration' hints at a broader scope than sibling tools like set_model_tiers or set_preferences. However, it doesn't explicitly differentiate itself from those siblings.

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 about when to use this tool versus alternatives such as opencode_set_provider_auth, set_model_tiers, or set_preferences. An agent reading this alone cannot determine whether to use this tool or a more specific one.

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

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

Annotations already indicate destructiveHint=true, but the description adds valuable behavioral details: returns immediately with task ID, client polls, prevents timeouts, and specifies YOLO mode duration. This exceeds annotation-only info.

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 with no wasted words. Front-loaded with core action, followed by async behavior and benefit. Highly concise and structured.

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 (11 parameters, async, destructive), the description covers the key workflow (async polling, timeout). Output schema exists, so return format is covered elsewhere. Missing minor details like polling mechanism, but sufficient.

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 91% schema coverage, the description adds minimal parameter detail beyond the schema. It mentions YOLO mode and timeout but does not explain individual parameters further. 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 it sends a prompt to a CLI runner as a background task, returns immediately with a task ID, and prevents timeouts. This distinguishes it from siblings like batch_prompt (batch) and preference 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?

The description explains the async nature and timeout prevention, providing clear context for use. However, it does not explicitly contrast with sibling tools like batch_prompt or state when not to use.

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

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

The description explicitly states it overwrites previously saved tiers entirely, adding behavioral context beyond annotations. Annotations already indicate idempotence, but the description clarifies the overwriting behavior. No contradiction with annotations.

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 efficient sentences: first states purpose, second explains process, third details effect. No wasted words, and critical information 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?

The tool is simple with one parameter, full schema coverage, and an output schema. The description covers the key behavior (overwrite) and is complete for this complexity level, though it omits error handling details.

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 schema already describes the tiers parameter as a mapping to allowed tier values. The description adds no further meaning, so baseline score 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 the tool saves model tier classifications, using a specific verb (Save) and resource (model tier classifications). It distinguishes from sibling tools like prompt and set_preferences, which deal with prompts and preferences.

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 explicit guidance on when to use vs. alternatives. The context implies it is for persisting model tiers after sampling/benchmarks, but lacks explicit when-not-to-use or comparison with siblings.

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

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

Annotations already indicate idempotency ('idempotentHint': true) and non-destructiveness. The description adds value by explaining persistence across sessions and the update semantics. No contradictions found.

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?

Well-structured with three concise paragraphs: purpose, persistence, and example usage. No unnecessary words, every sentence adds value.

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 tool with 24 parameters (none required) and an output schema, the description covers the key behavioral aspects: persistence, update, clearing, and relation to sibling tools. The output schema handles return values, so no further detail needed.

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 58% with descriptions for most fields. The description explains the overall pattern of using 'None' to retain values and 'clear_*' flags to reset, which adds context beyond individual parameter descriptions but does not detail every parameter.

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 verb ('Set'), resource ('persistent preferences'), and scope ('apply to subsequent prompt/batch_prompt calls'). It effectively distinguishes from sibling tool 'clear_preferences' by mentioning its specific function.

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 guidance on when to use (set preferences for future calls), persistence across sessions, update behavior, and how to clear fields individually using 'clear_*' flags. Also names 'clear_preferences' as alternative for resetting all fields.

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