severally

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

The annotations already declare that this is a mutating but idempotent operation, and the description adds useful behavioral context: other servers receive a stop request, the process tree is signalled where permitted, and Windows descendants may survive if the CLI already exited. It does not describe permissions or partial-failure responses, but the added distributed cancellation caveat is meaningful 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 three compact sentences with the action and target types front-loaded. The remaining sentences add distributed-stop and platform-caveat details without unnecessary preamble.

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 cancellation tool with annotations covering mutation and idempotency, the description provides the key operational context: what is stopped, that other servers are notified, and the platform limitation on descendants. It leaves some gaps around return behavior and exact identifier requirements, but is largely complete for this complexity level.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It usefully maps job_id to a running consultation and group_id to a fan-out, and "or" implies choosing one, but it does not explicitly state that exactly one identifier is required, whether both may be supplied, or what happens if neither is provided.

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

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

The description states a specific verb and resource: "Stop a running consultation" or "fan-out". It clearly distinguishes cancellation from sibling operations such as consult_start, consult_get, consult_record, consult_export, and consult_list by describing the terminating action and the two target types.

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

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

The description implies when to use the tool by mapping job_id to stopping a consultation and group_id to stopping a fan-out. However, it does not explicitly state prerequisites, when not to use it, or which sibling tools should be used to find the relevant identifiers.

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 and openWorldHint=false, and the description adds real value on top: it does not write files, it can read earlier sessions, it omits inferred adoption or scoring, and it specifies the document's opening section. Missing only pagination/size behavior, which is minor for a render 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?

Roughly 60 words, front-loaded with the action and output format, then usage, then the history-reading caveat. Dense but nearly every clause carries information; the 'no inferred adoption or scoring' clause is the only slightly tangential bit.

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, the description does the necessary work by describing the Markdown layout and its leading verified/unverified summary. The one remaining gap is the chain_id-vs-group_id selection rule, which an agent would need in order to call it unambiguously.

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

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

Schema coverage is 0%, so the description must compensate, and it does explain what each id means: chain_id = a single consultation, group_id = a fan-out. However, it never states whether the two are mutually exclusive or that one must be supplied despite required=0, which is the key ambiguity an agent faces 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?

The description names a specific verb (render) and resource (one consultation or fan-out) and enumerates the payload: brief, answers, verdicts. It implicitly separates itself from consult_get by promising Markdown text rather than structured data, though it never names a sibling explicitly, which keeps it just shy of a 5.

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

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

'The text is returned, not written: put it beside the code the decision is about' tells the agent the intended use and that no artifact is created, while 'Reads the history, so an earlier session's consultation can be exported' clarifies it works on past sessions. No named alternatives or explicit when-not conditions are given.

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 substantial behavior beyond the read-only/open-world annotations: default wait time, 45s cap, 15s progress updates, completed vs failed payload differences, group comparison fields, truncation markers, and detail mode behavior. It is strong for a polling tool, though it does not cover error behavior or invalid-id handling.

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

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

The description is compact and front-loads the polling behavior before covering result shapes and follow-up workflow. It is dense and somewhat telegraphic, with several fragmented clauses, but most sentences earn their place and give actionable 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 five-parameter polling/result tool with no output schema and low schema description coverage, the description covers the main states, result fields, waiting behavior, detail mode, and follow-up workflow. It is nearly complete, with minor gaps around error cases, combining job_id and group_id, and fallback behavior for invalid inputs.

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 20%, so the description carries most of the burden and does so effectively. It explains wait_ms defaults and polling with 0, the job_id vs group_id distinction, the detail: full option, and the ids behavior including job_id + ids versus job_id alone. This meaningfully compensates for the sparse schema descriptions.

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 core operation: waiting/polling on a job_id or group_id until completion, then returning consultation status or results. It distinguishes job and group result shapes and mentions specific states like completed and failed. It does not explicitly contrast itself with sibling tools such as consult_list, which keeps it from a 5.

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

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

It gives practical usage guidance: repeat while running, use wait_ms: 0 to poll, check deciding claims, batch checked entries in consult_record, and report afterward. It also explains how to retrieve missing or shortened deciding points with job_id plus ids. The main gap is that it does not say when to choose this tool over consult_list or other alternatives.

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 and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: newest-first ordering, the exact field set returned, the fact that filters are applied before the limit, and the nuance that usage_totals includes retries while unreported figures appear under not_reported rather than as zero. It stops short of describing default limit behavior or the shape of a paginated/empty result.

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 what the tool returns, then filters, then the usage_totals caveat — a sensible ordering. Every sentence carries information, though the dense run-on phrasing around the filters and usage_totals requires a second 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?

With no output schema, the description correctly takes on the job of enumerating return fields and their ordering, which it does well. Filter-vs-limit ordering and the not_reported convention round it out. The main residual gap is the unexplained 'target' filter, which matters for a tool with four optional parameters.

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 full burden. It meaningfully explains 'question' as a case-insensitive substring filter, states that filters (target, question, chain_id) apply before limit, but leaves 'target' and 'chain_id' semantically opaque — an agent cannot tell what a target is or what a chain groups. Three of four parameters get some treatment, but the coverage gap is not fully compensated.

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 resource (recent consultations) and enumerates the returned fields (ids, status, summary, verdicts, latest_completed_job_id, rounds_remaining) plus ordering (newest first). The parenthetical '(this_session is false)' clarifies it spans earlier sessions, which implicitly distinguishes it from a single-session view. It never names a sibling tool like consult_get to draw the boundary explicitly, so it falls short of a 5.

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

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

Usage is implied by the listing nature and by 'filters apply before limit', but there is no explicit statement of when to choose this over consult_get (single record) or consult_export. No when-not guidance and no prerequisites are given. An agent can infer the selection rule, but must infer it.

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?

Goes well beyond the annotations by disclosing failure semantics ('invalid jobs/IDs prevent every write; write failures appear per job in results'), persistence ('saved history survives restart'), and downstream propagation ('only verdict/effect go to follow-ups'). It also disambiguates the verdict semantics ('Confirmed is not adoption'), which the annotations cannot convey.

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 primary action and token vocabulary, then layered with semantics, batching, and failure behavior in a tight ~110 words. The telegraphic clauses ('Confirmed is not adoption', 'Invalid jobs/IDs prevent every write') are dense but each carries distinct information rather than waste.

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

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

For a 4-parameter tool with nested objects, no output schema, and a write annotation set, the description supplies the missing behavioral and failure context an agent needs. Return-value shape is only loosely gestured at ('write failures appear per job in results'), which keeps it from a 5.

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?

At 75% schema coverage the schema already documents job_id, id, note, effect, and reflection fields; the description still adds real meaning by defining effect as 'decision impact' and note as 'checked evidence', and by explaining verdict values inline. It does not cover limits like maxItems 100 entries or 9 records, so it falls short of full compensation.

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 ('Save checks against point IDs') and immediately grounds it in the sibling that produces those IDs (consult_get), with concrete token formats f1/u1/c1. An agent can distinguish this from consult_get, consult_list, or consult_export 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 clear operating rules: 'Record only checked points' and 'same ID replaces its entry', plus a routing rule that fan-out batches go through 'records' rather than job_id/entries. It names consult_get as the upstream source but does not explicitly state when NOT to record or how this relates to consult_cancel/consult_list, so no true 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 only flag non-readOnly, openWorld and non-idempotent; the description adds substantial behavior the agent could not otherwise know: read-only file copies with secrets masked, skipped symlinks/protected paths, hard caps (20 entries, 500 files, 5 MB), one concurrency seat per consultant, operator-owned models/limits, and the local-only nature of the prediction field. It also clarifies that network:on/off controls web access rather than model submission.

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 purpose is front-loaded in the first sentence, but the remainder is a dense telegraphic wall of semicolon-chained fragments with parenthetical asides. Almost every line carries information, yet the lack of structure (no grouping of targeting vs context vs retry fields) makes it hard 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 single-object-param tool with a deep nested schema, no output schema and no param descriptions, the description supplies most of what an agent needs to call it correctly, including the immediate return identifiers. It still omits several request fields (objective, question, constraints, success_criteria, artifacts) and does not say how to inspect the resulting job beyond navigational advice.

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

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

With 0% schema description coverage the description must carry all parameter meaning, and it does for the high-risk ones: target vs targets, followup_to inheritance and replacement semantics, retry_of replay behavior, mode defaults, expose_diff/expose_paths/expose_from_parent, caller/caller_model/initiator, and prediction. It leaves objective, question, constraints, success_criteria and artifacts undescribed, so coverage is good but incomplete.

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 opening sentence states a specific verb and resource ('Start one consultant (target) or several (targets)') and even gives the return value ('returns job_id or group_id immediately'). It does not explicitly name the sibling tools, so an agent must infer that consult_get/consult_list are for polling rather than starting.

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 routing rules: use followup_to for a completed job/group, use retry_of only for a failed job, and 'retry only failed members after fixing auth/quota causes'. It also explains targets:["all"] and the mode defaults (facts=explore, proposal=review, proposal+counterpoints=debate). What is missing is any explicit statement of when NOT to start a consultation or which sibling to use instead.

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