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

With no annotations, the description carries the burden and discloses key constraints: it is a one-shot direct API call, returns a raw response, the model has no file access and cannot take actions. It also warns that a cheap model may be less reliable than the agent itself. It does not cover cost, rate limits, timeout, or error behavior, which keeps it from a 5.

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

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

The description is a compact paragraph with no wasted sentences. It front-loads the purpose, then adds behavioral constraints, exclusions, and the default-model note in a logical order.

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 simple three-parameter tool, no annotations, and no output schema, the description covers what the tool does, what it returns (raw response), and its key limitations. It is nearly complete, though it does not address failure modes or cost/timeout behavior.

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 schema already documents all three parameters including the model format and default behavior. The description restates the default-model behavior but adds no meaningful parameter semantics beyond what the schema provides; 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?

States a specific verb and resource: it gets a second opinion from a different model via a one-shot prompt. It explicitly contrasts itself with the sibling `delegate` for file-touching tasks, so an agent can distinguish them without opening either schema.

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

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

Gives clear when-to-use conditions (second opinion on design/approach/snippet, or when the user requests it) and explicit when-not-to-use guidance (don't ask for syntax/API details you already know). It names the alternative tool (`delegate`) for file-related work and explains how to use the default 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?

No annotations are provided, so the description carries the disclosure burden and does well: it names the three terminal statuses, the elapsed-time and session-id returns, the 8,000-character output truncation, and the context cost of each poll. It stops short of stating auth requirements or backing-store behavior.

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

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

Three short sentences, each doing distinct work: payload contents, polling discipline, and the id-omitted mode. No filler, and the core return contract 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?

With no output schema and no annotations, the description compensates by explaining exactly what comes back (status, elapsed, session id, truncated output) and how to poll responsibly. Nothing an agent needs to invoke it correctly is 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 coverage is 100% and the single parameter's description already says 'Omit to list all jobs'. The description repeats that hint but adds no format or validation detail beyond the schema, so baseline 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?

States a specific verb (check) on a specific resource (a delegation started with background:true). It clearly distinguishes itself from the sibling delegate tool by framing itself as the poller, not the starter, and notes the no-id listing mode.

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

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

Gives concrete operational guidance: wait between polls instead of tight-looping, and omit the id to list all jobs. It doesn't explicitly name a sibling alternative for starting a job, but the when/how is well covered.

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, so the description carries the full burden and does well on several fronts: context isolation, inline-vs-background execution, the 2-minute host-specific timeout, and job-id polling. It is weaker on the mutation side — it never says the agent will edit files in the working tree or that those edits are not reversible, and the approval risk is only implied by 'Review what comes back before reporting it done'.

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

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

Front-loaded with the core purpose, then trigger conditions, then runtime behavior, then invocation tips. Despite its length, every clause is a distinct decision input — no restatement of the name or filler prose.

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 9-parameter, no-output-schema delegation tool this is thorough: it covers what the remote agent does with your repo, how the call returns (inline vs job id), how to resume a session, and which params to leave alone. Nothing needed to invoke it correctly is 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 coverage is 100%, so the baseline is 3, but the description adds real operational guidance: 'Name file paths in task; never paste their contents', 'model/directory/agent/autoApprove default from config — omit them', and that continue_session came from a previous delegation's result. It supplies decision rules the schema alone does not.

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

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

States a specific verb and resource ('Hand a coding task to another AI model running as a full agent') and immediately characterizes the mechanism ('reads the project, explores, and writes the code in its own tool loop, none of which enters your context'). This distinguishes it cleanly from ask_model and from doing the work in-context.

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?

Enumerates eight concrete trigger conditions ('tests for code that already exists', 'mechanical refactor', 'lint/type/build errors', 'same edit repeated across 3 or more files'), and explicitly says to use it 'instead of writing the code yourself'. It also routes to siblings: poll check_delegation for background jobs, use continue_session rather than re-exploring, and omit config-defaulted params.

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

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

No annotations are provided, so the description carries the full burden, and it does signal a side-effect-free read and discloses the shape of what comes back (config keys, version, auto-update status). It doesn't mention auth requirements, failure modes, or whether secrets are redacted, which would round it out.

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, zero filler, with the returned field list front-loaded and the usage triggers appended. The field enumeration is long but earns its place because there is no output schema.

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

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

With no output schema, annotations, or parameters, the description is the sole carrier of information — and it fully covers what is returned plus when to reach for it. Nothing an agent needs in order to call this correctly is 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?

Zero parameters, so there is nothing to disambiguate; baseline applies. The description spends its words on return values instead, which is the right allocation here.

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

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

Specific verb ('Read') plus a named resource ('forge-delegate configuration'), followed by an enumeration of exactly which keys are returned. The read framing cleanly separates it from the write counterpart set_delegate_config without needing to name it.

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

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

Explicitly names two triggering situations: checking what defaults will be applied when a model/directory is omitted, and answering version questions. It doesn't explicitly exclude or route to siblings like set_delegate_config, but the read-only framing makes the boundary obvious.

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

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

With no annotations, the description carries the full disclosure burden, and it does useful work: it names the model source categories and clarifies that ordinary delegation resolves via the configured default, so the agent understands this call is informational rather than part of the delegation path. It stops short of describing the return shape (names vs. identifiers), which matters because the stated use case includes changing the default model.

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, both load-bearing: the first defines what is listed, the second routes usage. The trigger and the exclusion are front-loaded before the explanatory clause, so an agent can act on the first read.

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

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

For a zero-param listing tool with no output schema, the description covers what is enumerated and when to call it, which is nearly everything an agent needs. The one gap is that with no output schema, nothing states whether the returned models come back as display names or as identifiers accepted by set_delegate_config — relevant given the 'change the default model' use case.

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

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

The tool takes zero parameters, so there are no semantics to explain and the baseline of 4 applies. The description correctly refrains from inventing parameter guidance where none exists.

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

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

States a specific verb and resource ('List the models available for delegation') and then enumerates the three model categories returned (local/keyless, direct-API from opencode logins, agentic from the local install). This lets an agent distinguish it from ask_model and delegate without opening any schema.

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

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

Gives an explicit positive trigger ('when the user asks what's available or wants to change the default model') and an explicit negative one ('not before an ordinary delegation'), plus the reason those cases differ. This is exactly the when/when-not/alternative structure the top score requires.

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

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

With no annotations, the description carries the full burden and does well: it discloses merge semantics ('Only provided keys change; others are preserved'), deletion via null, and whole-object replacement for profiles. It does not say whether changes are persisted across restarts or what confirmation the call returns, which matters for a runtime mutation.

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

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

Front-loaded with purpose, then constraints, then the parameter set, then merge/clear rules. Every sentence conveys an operational rule; nothing is padding despite the density.

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 7-parameter mutation tool with a nested object and no output schema, the description covers behavior and mutation semantics well. Missing are the persistence/scope of changes and any auth or permission requirement, which an agent would want before altering global delegation config.

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 baseline is 3, but the description adds semantics the schema does not: null clears a field, profiles must be passed whole and a null profile deletes it, and unspecified keys are preserved. That is real added meaning for the trickiest parameters (profiles, nullable defaults).

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

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

States a specific verb and resource ('Change forge-delegate configuration at runtime') with a useful qualifier ('no reinstall'). It implicitly contrasts with the reader sibling get_delegate_config, but never names it, so the differentiation is left to inference.

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 policy: 'Only change settings when the user asks; never raise defaultModel to a premium tier on your own' tells the agent when not to act and what not to escalate. It lacks a pointer to get_delegate_config for reading current values before mutating, which is the obvious companion step.

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