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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'No model calls' and the fact that it checks installation/login state, which is not redundant with annotations. It also implies a read-only status check without additional risk disclosure, but the annotations cover the safety profile.

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 fluff. The core purpose is front-loaded, and each sentence adds value: what it lists, when it applies, and what it does not do. Efficient and well-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?

For a simple status tool with one optional boolean and no output schema, the description fully explains the output (which CLIs, login status, login command) and its usage context. An agent has everything needed to 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?

The only parameter, 'refresh', is fully described in the schema with its default and meaning. The description does not need to add parameter details since schema coverage is 100%. The description's mention of caching is only implied via the parameter, not the main text.

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 lists which AI CLIs are installed and logged in, plus the login command for each. It names specific CLIs, distinguishing it from generic status or model tools. The phrase 'No model calls' further clarifies its scope.

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 says 'Account providers are used before per-token APIs,' implying when to check account status. However, it does not explicitly name alternatives or conditions for not using this tool, leaving some inference 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, the description discloses that provider credits may be consumed and that omitting project_id/mission_id silently routes results to project 'default' under a new random mission that mission_status and memory_checkpoint will not find. This is exactly the side-effect information an agent needs 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?

Three short sentences: core function first, cost second, and state-routing consequences third. Every sentence earns its place and there is no repetition of schema detail.

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 17-parameter tool with no output schema, the description names the expected returns (responses, observed diversity, optional synthesis) and covers the critical side effects around cost and mission/project routing. It is adequate but not exhaustive; output shape and specific failure modes are left to the schema, which is fully documented.

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 baseline is 3. The description adds meaningful cross-parameter context by instructing the agent to reuse the current task's project_id and mission_id and explaining the failure mode when they are omitted, which is not inferable from individual schema fields.

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 concrete action, 'Ask 2-5 independent reviewers', and names the deliverables: responses, observed diversity, and an optional heuristic synthesis. This distinguishes consensus from sibling tools like delegate and swarm_run by focusing on independent reviewers and diversity reporting.

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 clear operational context: when you want multiple independent reviews with diversity and optional synthesis, and it flags that provider credits may be consumed. It also gives explicit guidance to reuse the current project_id and mission_id and warns about the consequences of omitting them, though it does not explicitly contrast consensus with delegate or swarm_run.

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, idempotentHint, openWorldHint, and destructiveHint. The description adds meaningful behavioral context beyond those: it returns an 'upper bound,' depends on DZ23_PRICES_FILE for cost, and makes no provider calls. 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 whole description is a single, dense sentence. It front-loads the key output ('Upper bound of calls, tokens and cost'), then states the scoped tools, the timing, and the condition regarding DZ23_PRICES_FILE. There is no filler or redundancy.

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

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

The description adequately conveys the tool's purpose and caveats for a pre-run estimate. However, with 8 parameters, no output schema, and very low schema coverage, it leaves much about how to configure the estimate and what the response contains unexplained.

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 13% (only 'prompt' is described), and the description does not explain how roles, models, synthesis, task_type, max_agents, or prompt_chars affect the estimate. The only implicit parameter mapping is the mention of delegate/consensus/swarm_run to the 'tool' enum, which is insufficient given 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 ('Estimate') and resource ('call cost'), and explicitly scopes the tool to delegate, consensus, or swarm_run. It clearly distinguishes this tool from those execution siblings by framing it as a pre-run estimator.

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 states when to use the tool: 'before running it.' It also adds a useful exclusion, 'No provider calls,' clarifying that the estimator makes no external provider requests. It does not explicitly name alternatives, but the intended context is clear.

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 discloses behavior beyond annotations: 'May consume provider credits' and 'bounded retries, failover and mission context'. It also explains the consequence of omitting mission/project IDs, which is useful side-effect information. No contradiction with readOnlyHint=false or openWorldHint=true.

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 filler: the core action and caveats are front-loaded, followed by the crucial ID-reuse guidance. It avoids repeating schema information and every clause 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 16-parameter tool with nested objects and no output schema, the description covers the essential operational context: task delegation, retries/failover, credit consumption, and mission/project routing. The schema covers parameter-level details, leaving only secondary gaps such as return shape and retry specifics.

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 parameters are already documented. The description adds meaningful semantics by connecting project_id and mission_id to the current task's source (project_init / memory_checkpoint) and clarifying that omitted values produce a mission that status tools cannot find, going 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 opens with 'Delegate one advisory text task with bounded retries, failover and mission context', naming a specific verb, resource, and key characteristics. It is clear enough to separate this from review/monitoring tools, though it does not explicitly name sibling tools like swarm_run or consensus.

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 explicit operational guidance: reuse the project_id and mission_id from project_init / memory_checkpoint, and warns that omitting them routes results to project 'default' with a new random mission that status tools won't find. It lacks an explicit contrast with alternatives, but the context is actionable.

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 read-only and non-destructive behavior. The description adds caching TTL ('cached five minutes') and the important caveat that catalog presence does not guarantee inference access, which is useful beyond 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?

Two sentences, front-loaded with the core action and resource, followed by a concise caveat. No wasted words.

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

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

For a simple discovery tool with optional parameters and safety covered by annotations, the description covers cache behavior and a critical semantic caveat. It doesn't explicitly address sibling distinctions (list_models/verify_model), but that is a minor gap.

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 all parameters are documented in the schema. The description adds little beyond the schema, except reinforcing the five-minute cache context, which the schema already mentions. 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?

Description states a specific verb (query) and resource (provider /models catalogs) and includes a key semantic caveat about inference access, which distinguishes it from siblings like list_models and verify_model.

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 clearly implies the tool is for querying provider catalogs, and the caveat about inference access hints that verification is separate (suggesting verify_model), but it does not explicitly name alternatives or exclusion conditions.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the output is a compact Markdown briefing for another harness, which is useful context beyond the annotations, but it does not disclose what the briefing contains or whether any state is consumed.

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. Every word contributes to identifying the tool's action and output, and it avoids repeating schema or annotation information.

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

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

For a simple two-parameter, read-only, idempotent tool, the description plus schema and annotations is mostly sufficient. However, the lack of an output schema means the description should say more about what the briefing includes, and it does not explain when to choose this over sibling tools.

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

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

Schema description coverage is 100%, and the schema already explains mission_id and project_id including the authorization note. The tool description adds no parameter-specific meaning or interaction details, so it does not improve on the schema.

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

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

The description states a specific action ('Return') and resource (a compact Markdown briefing for another harness), making the tool's export purpose clear. It does not explicitly differentiate from sibling tools like mission_status or delegate, but the intended audience and output format are specific 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?

The phrase 'for another harness' implies the use case of handing off mission context to another agent, but the description gives no explicit when-to-use guidance, prerequisites, exclusions, or comparisons to sibling tools. Some usage context is present, but it is mostly implicit.

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 non-read-only and non-idempotent behavior, and the description adds meaningful context: it performs a real generation, runs in parallel, targets every eligible target, and may consume provider quota or credits. This makes the side-effect profile clear, and there is no contradiction with 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 two sentences with no filler. It front-loads the core action and scope, then states the prerequisite and consequence. Every clause 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 one-parameter billable tool, the description covers the action, scope, prerequisite, and side effects, which is largely sufficient for correct invocation. The main gaps are that 'eligible target' is not defined and there is no output-schema or return-value description, though these are not critical for 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 coverage is 100% and the sole parameter confirm_billable is already described as 'Must be true: acknowledges one billable call per eligible target.' The description repeats the requirement but does not add new semantic detail beyond what the schema already provides.

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 ('Run a tiny real generation') and scope ('on every eligible target in parallel'), so an agent can understand what the tool does. However, it does not explicitly contrast itself with sibling tools like verify_model or discover_models, so sibling 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?

The description gives a hard prerequisite ('Requires confirm_billable=true') and a caution ('may consume provider quota or credits'), but it offers no guidance on when to choose this tool over alternatives or when not to use it. The intended usage context is only implied by the name and billing note.

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, idempotentHint, and destructiveHint, so the description does not need to restate safety. It adds genuine behavioral context by stating that no network calls are made and that results are limited to configured, policy-eligible targets, which is beyond what annotations or the empty schema provide.

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 sentence contains the core purpose, the scope, the output content, and the key side-effect characteristic ('No network calls'). Every clause earns its place and there is no 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?

For a parameterless, read-only list operation with strong annotations and no output schema, the description captures enough: what is listed (routing targets), filter state (configured/policy-eligible), and returned capability info. It could additionally mention response shape or empty-list behavior, but the invocation surface is minimal and clear.

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 has zero parameters, so the description cannot add parameter-level meaning. Baseline 4 is appropriate because there is nothing for the agent to misinterpret when invoking.

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?

Description uses a specific verb ('List') with a well-defined resource: 'configured, policy-eligible routing targets', and specifies the returned detail ('tier and adapter capabilities'). This clearly differentiates it from siblings like provider_inventory and discover_models, which imply broader or network-dependent exploration.

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 'No network calls' and the modifier 'configured, policy-eligible' imply a local, low-cost read path, giving an agent context for when to call it. However, it never explicitly names an alternative or states when NOT to use it, so the usage guidance is left 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?

Beyond the annotations (which already indicate this is not read-only), the description discloses the meaningful side effect that the mission is created when absent. This is useful behavioral context an agent would not get from the schema alone. It does not detail overwrite semantics or lease requirements, but those are covered in the schema and annotations do not contradict the description.

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 tight sentences with no filler. The primary purpose is front-loaded, and the ID reuse instruction earns its place by directly aiding correct invocation.

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 20-parameter tool with nested objects and no output schema, the description is adequate but leaves important context implicit. It explains the handoff purpose and ID provenance but does not address what happens on update, how checkpoints relate to sibling handoff/export tools, or what a successful call returns. The schema fills many gaps, but a tool this complex could use more orientation.

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 adds real semantic value for the two required parameters by instructing the agent to reuse the IDs from delegate, consensus, and swarm_run. However, with 20 parameters and only 55% schema description coverage, the description does not compensate for the many undocumented fields or summarize the checkpoint payload, leaving most parameter meaning to the schema.

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

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

The description opens with a specific verb-resource pair ('Persist a structured handoff checkpoint') and clearly scopes the target ('for another harness or agent'). The added note that it 'creates the mission when absent' distinguishes it from read-only status tools like mission_status and from mission_start, making the resource and intent unmistakable.

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 contextual guidance: use this tool when persisting a handoff checkpoint, and reuse the same project_id and mission_id from delegate, consensus, and swarm_run. It does not explicitly name sibling alternatives or state when not to use it, but the context is specific enough to guide correct 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 only convey read-only/idempotent/destructive hints; the description adds that finished jobs are unaffected by cancellation, which is meaningful behavioral context. It does not detail resulting status values or reversibility, but this is sufficient for a simple cancel operation.

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 concise sentences with no filler. The main action and scope are front-loaded, and the edge case about finished jobs is stated in the second sentence without unnecessary detail.

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 one-parameter mutation tool with no output schema, the description covers when cancellation is valid, what happens to finished jobs, and the primary resource involved. No critical information needed for correct invocation 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 only parameter, job_id, is already described in the schema as 'Job id.' The description adds no additional parameter-level meaning, so the baseline score of 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 uses a specific verb ('Cancel') and resource ('job'), and immediately scopes the action to 'running or paused' jobs. The second sentence contrasts with finished jobs, which clearly distinguishes this from siblings like mission_pause, mission_resume, and mission_status.

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 explicitly states when to cancel (running or paused) and when not to (finished jobs keep their final status), giving clear usage context. It does not name alternative tools, but the scope statement is enough to guide tool 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?

The annotations only convey mutating, non-idempotent, non-destructive intent. The description adds real behavioral detail: live-lease token requirements, mission_busy for other operations, renewal semantics, and the non-authentication caveat.

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, each earning its place: the core action, the operational consequences, and the critical caveat. The most decision-relevant fact 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?

For a five-parameter tool with no output schema, the description covers the full lifecycle: claiming, expiry, token usage, renewal, and non-authentication. The schema fills in remaining parameter constraints, so nothing needed to call 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?

With 80% schema coverage, the baseline is 3, but the description adds meaning to lease_token by explaining renewal and frames identity as a cooperating harness. It does not elaborate on lease_ms, though the schema already supplies its bounds and 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 opens with 'Claim a mission for one harness with expiry,' a specific verb, resource, and scope. It also distinguishes this tool from mission_start by explaining that the lease token is required by several downstream operations.

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

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

It explicitly names which operations require the token (memory_checkpoint, delegate, consensus, swarm_run, mission_start), says others receive mission_busy, and explains renewal by claiming again. It also gives a key when-not: leases are coordination, not authentication.

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 covered. The description adds that it returns the same data as MCP resources, which is useful behavioral context. It doesn't disclose pagination behavior (cursor-based) or that limit has a maximum of 200, but those are in the schema. 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 that front-loads the key content (what fields are returned) and adds a useful note about MCP resources equivalence. It's compact and every clause earns its place. Could be slightly more structured with a second sentence for usage guidance, but it's efficient.

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 read-only list tool with no output schema, the description covers the return content well. However, it lacks guidance on pagination (cursor), the limit parameter's role, and how this relates to sibling tools like mission_status. The MCP resources note is helpful but doesn't fully compensate for missing usage context. Given the tool's simplicity and annotation coverage, this is adequate but not 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 33% (only project_id has a description). The description doesn't explain limit or cursor semantics beyond what the schema provides. However, the description's mention of 'loop/graph progress and resource URI' gives context about what the returned data contains, which indirectly helps understand the tool's purpose. The description doesn't add meaning to the parameters themselves, so baseline 3 is appropriate given partial 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 the tool lists missions and enumerates the fields included (status, goal, next action, loop/graph progress, resource URI). It also distinguishes itself from MCP resources by noting it provides the same data for harnesses without resource support. However, it doesn't explicitly differentiate from sibling tools like mission_status or mission_status_job, which could also be mission-related list/status 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 implies usage context: use this when you need mission data and don't have MCP resources support. It doesn't explicitly state when to use this vs alternatives like mission_status or mission_status_job, nor does it mention the optional project_id filter or pagination. The 'same data as MCP resources' note gives some context but no explicit exclusions or alternative routing.

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 behavioral information beyond annotations: it states the pause is a request, takes effect after the current iteration, and that the job can be resumed. This is valuable because annotations only indicate it is a non-readonly, non-idempotent, non-destructive operation; the timing and resumability are not in the structured data.

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, front-loaded with the core purpose (request a pause) and followed by two key behavioral details. No unnecessary words or repetition.

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

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

For a one-parameter tool with no output schema, the description covers the essential behavior (what happens after pause, resumability). It does not mention prerequisites (e.g., job must be running) or what the response might be, but these are not critical for a tool of this simplicity. Overall it is adequate.

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, job_id, is already fully described in the input schema ('Job id.'), and the description adds no additional meaning or context. With 100% schema coverage, the baseline of 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 the tool's function: requesting a pause for a job, with the specific behavior that it stops after the current iteration and remains resumable. This distinguishes it from mission_cancel (permanent stop) and mission_resume (restart), making the purpose 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 usage for temporarily halting a running job and notes the job can be resumed, but it does not explicitly name alternatives or conditions for choosing this over mission_cancel or mission_resume. There is no 'when to use' or 'when not to use' guidance, only an implied scenario.

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 only state negative hints (not read-only, not idempotent, not destructive), so the description carries the burden of explaining behavior. It merely restates that a lease is released and mentions the token origin; it does not disclose side effects, failure behavior, or whether the token is invalidated.

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

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

One sentence, no filler, and the most important usage detail is front-loaded: the token source. Every word earns its place.

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

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

The tool is simple and the schema documents all parameters, so the description is mostly adequate. However, there is no output schema and no mention of what happens after release, such as whether the lease becomes available again or how invalid tokens are handled. For a state-changing operation, that is a noticeable gap.

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 adds meaningful semantics to the token parameter by specifying it is the token returned by mission_claim, which helps an agent know where to obtain it. The other parameters are already well described in 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 uses a specific verb and object ('Release a lease') and adds valuable provenance by saying the token comes from mission_claim. It is clearly distinct from similar sibling actions like mission_cancel, though it does not explicitly name alternatives.

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 usage context: this tool is for releasing a lease using the token returned by mission_claim. It implies when to call it, but it does not provide explicit exclusionary guidance such as 'use mission_cancel instead for missions that are not leased'.

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 readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds meaningful behavioral context: resuming creates a new job_id rather than continuing the old one, and it preserves the goal, roles, criteria, and remaining iterations. This is valuable beyond 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, focused sentence that front-loads the key behavior (resume) and then specifies what is preserved. No wasted words.

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

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

For a single-parameter tool with full schema coverage and no output schema, the description is largely complete. It explains the key side effect (new job_id) and what is carried over. It could mention that the original paused job remains unchanged or that the new job must be tracked, but this is a minor gap.

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 the job_id parameter. The description doesn't add additional parameter-level detail beyond what the schema provides, but it does clarify that the job_id refers to a paused job. 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 the verb 'Resume' and the resource 'a paused job', and it specifies that it creates a new job_id with the same goal, roles, criteria, and remaining iterations. It distinguishes itself from mission_pause and mission_cancel, though it doesn't explicitly name a sibling alternative.

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 the tool is for resuming paused jobs, which is clear context. However, it doesn't explicitly state when to use this tool versus alternatives like mission_claim or mission_release, nor does it mention prerequisites such as the job being in a paused state.

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 are minimal (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the description carries the full burden. It discloses that it may consume provider credits, explains state management (progress saved in dag_state/loop_state, never in status/next_action/goal), completion criteria (only when memory_checkpoint records new passing tests, else awaiting_acceptance), retry and skip behavior on failure, and the routing-strategy switch on near-identical results. This is rich behavioral detail far beyond what annotations provide.

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 action and immediate return. Each subsequent sentence adds necessary detail for a complex tool: the two modes, state management, completion condition, credit consumption, and parameter reuse guidance. No filler; every clause earns its place. The length is justified by the tool's complexity.

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 10 parameters, a nested plan object, and no output schema, the description covers all critical aspects: execution semantics, failure handling, state location, completion criteria, cost implications, and parameter reuse. An agent would understand exactly how to invoke it correctly and what to expect. Nothing essential 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 70%, so the description compensates for the 30% gap (roles, max_iterations, routing_strategy lack schema descriptions). It adds meaning for plan (task graph, depends_on, retries, resume_plan), mission_id/project_id reuse, lease_token requirement, and the semantics of acceptance criteria via the completion logic. It does not explicitly describe roles or max_iterations, but these have enums/defaults in the schema. Overall it adds substantial value over 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: 'Start a mission in the background and return a job_id immediately.' It clearly distinguishes two execution modes (with plan = task graph, without plan = loop), which differentiates it from sibling tools like swarm_run or delegate. The purpose is unambiguous and the scope is precisely stated.

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 strong contextual guidance: it explains when to use the plan-based mode vs the loop mode, and explicitly instructs to reuse project_id and mission_id from project_init/memory_checkpoint, warning that omitting them creates a mission that mission_status and memory_checkpoint cannot find. It does not explicitly name alternative tools or state 'use this instead of X', but the async and orchestration nature is implied by 'background' and the two modes. This is clear usage context but lacks explicit 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 already cover read-only, idempotency, and non-destructive nature. The description adds the preview behavior and the size caveat for include_outputs, which is marginally useful, but doesn't elaborate on response format or potential pitfalls like large responses even with previews.

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 purposeful. The preview behavior is front-loaded, though the sentence could be clearer about the condition for previews vs full outputs.

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 a read-only tool with 4 params and full schema coverage, the description is adequate but not complete. It doesn't specify default event limit or what constitutes 'recent' events, and doesn't hint at potential size issues even with previews, for example with very large journals.

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 parameters are already well-documented. The description adds the context that include_outputs controls preview vs full, which is also in the schema. It adds no new semantic depth 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?

Clearly states the tool reads mission state and journal events. However, it doesn't distinguish from the sibling 'mission_status_job', leaving ambiguity about which to use for job-specific status.

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?

Implies read-only usage and describes a key option (include_outputs), but offers no explicit guidance on when to use this versus 'mission_status_job' or when to set include_outputs to true.

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, idempotentHint, and destructiveHint, so the description does not need to restate safety. It adds value by explaining the orphaned-after-restart behavior, which is not visible in the schema or annotations. It stops short of describing the full set of possible status values in the response.

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

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

The description is two sentences with no filler. The core purpose is stated first, followed by the key edge-case behavior, and every clause contributes useful information.

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

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

For a simple read-only status tool with full schema coverage and safety annotations, the description is mostly complete. The main gap is that it does not enumerate the possible status results or clarify how mission_status_job differs from mission_status, but the essential calling behavior is covered.

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 parameters are already documented by name and purpose. The description adds meaning beyond the schema by explaining when project_id and mission_id should be supplied, tying them to the persisted-status/orphaned case.

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 the tool reports the status of a mission job, which is clear and specific. However, it does not explicitly distinguish itself from the sibling tool mission_status, so an agent may need to inspect both schemas to choose between them.

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 concrete usage context: after a server restart, pass project_id and mission_id to identify orphaned jobs. It does not provide when-not-to-use guidance or name alternatives, but the special-case instruction is actionable and specific.

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 establish this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail beyond those annotations: listing versus rendering depending on parameters, and the fallback/harness compatibility note.

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 short sentences, fully front-loaded with the conditional behavior and with no filler. Each sentence contributes either behavioral or contextual information.

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

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

Given the tool's low complexity, no output schema, and strong annotations covering safety, the description is mostly complete. It could mention what happens when a name is provided without arguments or what an invalid name returns, but the core calling pattern is sufficiently clear.

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 carries the burden of explaining the parameters. It states that 'name' selects a playbook and 'arguments' are used to render instructions. It does not specify optionality or detailed argument formats, but it provides enough meaning for an agent to understand both parameters.

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 behavior for two modes: listing playbooks without a name and rendering instructions with a name and arguments. It also clarifies the resource as MCP promptsarenas, which is distinct from the mission/delegation 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?

The description gives clear context for when the tool is intended: 'For harnesses without MCP prompts support.' It does not explicitly name alternative tools or state when not to use it, but the usage context is recognizable.

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 cover readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context by clarifying that it never clones or reads the repository and that it performs create-or-update semantics. It does not describe auth or persistence details, but the annotations carry the safety profile.

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

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

Two short sentences front-load the action and scope, then give the critical ID-stability instruction. There is no filler or 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?

For a low-complexity init tool with idempotentHint=true and no output schema, the description covers purpose, boundaries, and the key usage rule. It could be slightly more explicit about update/overwrite behavior, but 'create or update' plus the schema's parameter descriptions make it adequate.

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 baseline is 3. The description adds extra meaning for project_id by requiring one stable ID per repository and reuse across later calls, which is not fully captured in the schema. Other parameters are already well-documented 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 uses a specific verb phrase, 'Create or update shared project metadata,' and immediately clarifies what it does not do: 'Does not clone or read the repository.' This clearly identifies the tool's resource and action while distinguishing it from repository-access tools.

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

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

It gives concrete guidance to use one stable project_id per repository and pass it to every later tool call, and it states a key exclusion (does not clone or read the repo). It does not explicitly name alternatives, but the negative boundary plus the ID convention provides sufficient usage context.

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 cover readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds critical context: 'never credential values' (privacy guarantee) and 'No network calls' (performance and side-effect guarantee). These go beyond annotations and are directly useful for agent decision-making.

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 fluff. The verb and resource are front-loaded, and the exclusions and behavioral notes are concise. Every word earns its place.

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

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

The tool is simple (no params, no output schema), and the description fully covers purpose, scope, exclusions, and behavioral traits. An agent knows exactly what to expect and how to invoke it correctly. Nothing 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?

The tool has zero parameters, so schema coverage is 100% and there's nothing to document. The description correctly doesn't mention parameters. Baseline for 0-param tools is 4, and the description adds no unnecessary noise, so this 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 verb 'inventory' and resource 'every registered provider', specifying what it includes (configuration status and credential source) and excludes (credential values). It distinguishes itself from sibling tools like list_models and discover_models, which deal with models, not providers. The purpose is unambiguous and specific.

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 makes it clear that this tool is for provider inventory, so an agent would naturally choose it when needing that. However, it doesn't explicitly mention when not to use it or name alternative tools. There's no explicit routing to siblings, but the context is sufficient for correct selection in most cases.

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 readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context: it explicitly states 'No provider calls' (consistent with readOnly) and lists the factors considered (cost tier, eligibility, cooldowns, success/latency, quota from provider headers), which gives insight into what affects the result. It does not contradict 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, well-structured sentence that front-loads the core purpose and then lists the factors considered. There is no wasted wording; it is concise and informative.

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 read-only, idempotent tool with no output schema, the description covers the main purpose and behavioral constraints but lacks details on the output structure and parameter semantics for role and target. It is adequate for basic understanding but not fully complete for correct invocation without additional inference.

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 explain the parameters. It only mentions 'task type' (which maps to task_type) but gives no information about role or target parameters. The description does not compensate for the lack of schema descriptions; an agent would be unsure what role and target do or how they affect the routing explanation.

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

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

The description states a clear purpose: it returns the ordered list of models the server would use for a given task type right now, with reasons for skipping others. It differentiates itself from siblings like list_models and provider_inventory by focusing on the routing decision and explicitly noting 'No provider calls'.

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 usage: it is for explaining current routing decisions and does not make external calls. However, it does not explicitly state when to use this tool versus alternatives (e.g., list_models, discover_models) or provide any exclusion criteria. The context is clear but not explicit about alternative 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?

It adds valuable behavioral context beyond the annotations: 'May consume provider credits and take minutes' warns about cost/latency, and the mission/project default behavior tells the agent that omitted IDs create undiscoverable state. No contradiction with readOnlyHint=false or openWorldHint=true.

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 filler: action, cost/time warning, and the critical ID caveat are front-loaded. It avoids repeating schema details despite the large parameter surface.

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 19-param tool with no output schema, the description covers high-level orchestration and the most important default behavior, and the schema covers the rest. However, it does not describe the return value or when to choose this over delegate/consensus, which are non-trivial gaps for a complex tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds useful cross-tool semantics for project_id/mission_id, such as sourcing them from project_init/memory_checkpoint and the unfindable-mission consequence of omission, which the schema alone does not convey. Other parameters are appropriately left to the schema.

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

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

The description names a specific action and resource: 'Run up to seven advisory specialists in parallel, then one integrating reviewer.' This clearly conveys the orchestration role and distinguishes it from single-agent tools like delegate, though it does not explicitly name sibling alternatives.

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 only usage guidance is the warning to reuse project_id/mission_id and the consequence of omission. It does not state when to prefer swarm_run over delegate/consensus or give exclusion criteria, so selection context is only implied by 'parallel specialists.'

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 indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, so description doesn't need to restate those. It adds extra value by disclosing 'may consume credits', 'never runs automatically, never retries or fails over', and 'non-sensitive generation' – all beyond annotations. There is no contradiction with 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 entire description is a single, dense sentence that front-loads the purpose and then packs in the key constraints (billable, automatic, retry/failover) with no filler. Every clause earns its place, and the structure makes it easy to scan.

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 verification tool with no output schema and full parameter descriptions, the description covers the critical behavioral context: cost, non-automatic execution, and no retries. It does not specify what the tool returns (e.g., generated text or success/failure), but the purpose 'prove access' implies a result. Given the low complexity, this is sufficient, though an explicit return description would be a nice addition.

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 all parameters are already described in the schema. The description repeats the confirm_billable requirement and adds 'may consume credits', which gives business context to that parameter, but does not enrich the other parameters beyond schema. This meets the baseline of 3 for full 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 ('Run'), a clear resource ('provider:model'), and states the goal ('prove inference access'). It distinguishes itself from siblings like health_check (which likely checks connectivity without generating) and list_models/discover_models (which are about discovering models, not verifying inference). The phrase 'one minimal, non-sensitive generation' clarifies scope and differentiates from a full test.

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: it's used to prove inference access to a specific provider:model and requires confirm_billable=true. It also states it 'never runs automatically, never retries or fails over', which are important usage constraints. However, it does not explicitly mention when not to use (e.g., for non-billable checks) or name alternatives, though that is inferable from the 'prove access' purpose.

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