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

With no annotations, the description carries the full burden. It discloses the destructive nature ('kill the consultant process and everything it spawned') and the group behavior, which is significant and goes beyond what would be assumed. However, it does not address reversibility, side effects on data, or permission requirements, but for a cancel operation, the key behaviors are adequately covered.

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

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

The description is extremely concise—two sentences—with the primary action front-loaded. It includes the essential parameter guidance without extraneous detail, making it efficient and easy to parse.

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 two-parameter tool with no output schema and no annotations, the description covers the purpose, the parameter semantics, and the key behavioral trait (killing spawned processes). It does not address edge cases like providing both parameters or neither, but these are not critical for typical usage and the description is sufficiently complete for an agent 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?

Schema coverage is 0%, so the description must compensate. It clearly explains the semantic difference between job_id (single job) and group_id (fan-out group), which is critical for correct usage. It does not specify that both are optional or what happens if neither is provided, but the core distinction is well conveyed.

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, specific action: stop a running consultation and kill the consultant process. It explicitly mentions the spawned processes, making it distinct from the sibling tools (consult_get, consult_start, consult_record, consult_export, consult_list), which all serve different purposes.

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 guidance on parameter usage ('Pass group_id instead of job_id to stop every consultant in a fan-out'), but it does not explicitly address when to use this tool versus alternatives. It does not mention any sibling tools or conditions for selection, so the when-to-use context is only 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?

With no annotations, the description carries full behavioral disclosure and succeeds: it states the output format (Markdown), what is included, what is excluded ('Nothing is summarised... nothing is scored'), that the operation is non-writing ('returned, not written'), and that it reads on-disk history. This is far beyond a minimal 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 front-loaded with the core action and then adds details in a logical order; every sentence contributes either behavioral scope, content expectations, or usage guidance. Despite being three sentences, it is efficient for the information it must convey without annotations or output schema.

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

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

Given two simple optional-looking parameters, no annotations, and no output schema, the description covers output format, contents, non-mutation, and data source. The main missing piece is an explicit statement of the required/forbidden parameter combination (exactly one of chain_id/group_id), which prevents full completeness.

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

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

Schema coverage is 0%, so the description must explain chain_id and group_id. It does: chain_id selects a consultation, group_id selects a fan-out. It stops short of stating whether exactly one is required or what happens if both/neither are provided, which leaves some ambiguity for invocation.

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: 'Render one consultation (chain_id) or one fan-out (group_id) as Markdown.' It details the exact contents of the output (brief, answers, verdicts, unchecked marks) and distinguishes itself from write-oriented siblings by saying 'The text is returned, not written.'

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 provides clear context for when the tool is appropriate: to export a consultation/fan-out as a decision record in the repository, and it notes that on-disk history lets earlier sessions be exported. It does not explicitly name alternative sibling tools or call out when-not-to-use conditions, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden and does well: it explains blocking behavior, the 45-second cap, the expectation of multiple calls, failure kinds, and the distinction between failure and thin evidence. It does not cover auth or rate limits, but the core behavior is well disclosed.

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

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

The description is a single dense paragraph, but every sentence adds value—blocking, failure kinds, fan-out. It is front-loaded with the core purpose and then elaborates. Slightly long, but not padded.

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 no annotations, no output schema, and three parameters, the description covers the essential behavioral and semantic ground. It mentions the structured answer and failure.kind, hinting at response fields. It could add more about edge cases (e.g., invalid job_id) or the exact response shape, but it is adequate for an agent to call the tool correctly.

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

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

Schema coverage is 0%, so the description must explain parameters. It does: wait_ms is detailed (blocking, cap, purpose), group_id is explained as fan-out, and job_id is implied as the primary identifier. This goes beyond the bare schema and compensates for the lack of parameter 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 tool fetches the state of a consultation, which is a specific verb-resource pair. It does not explicitly contrast with sibling consult_list, but the purpose is unambiguous and distinct from starting or canceling consultations.

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

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

Provides concrete guidance on when to use wait_ms (to block instead of polling), how long consultations take, and when to pass group_id for fan-out. It does not explicitly name alternative tools, but the situational guidance is clear and 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?

No annotations are provided, so the description carries the burden. It discloses ordering (newest first) and that results include status and summary, which is useful. However, it doesn't disclose whether this is a read-only operation, whether it reflects only the current session, or what happens when there are no consultations. The 'from this session' scoping is a meaningful behavioral detail.

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

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

A single, front-loaded sentence that conveys the resource, scope, ordering, and included fields with zero waste. 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?

For a simple list tool with one optional parameter and no output schema, the description is nearly complete. It could mention that the output is a list of consultations with status and summary, but that's already implied. The main gap is not explaining the 'limit' parameter, though the schema covers it.

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

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

Schema description coverage is 0%, so the description must compensate. It doesn't explain the 'limit' parameter at all, but the schema itself defines it as an integer with min/max, which is self-explanatory. The description adds no meaning beyond the schema for the parameter, but the parameter is simple enough that this is a minor gap.

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

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

The description states a specific verb ('List'), a clear resource ('recent consultations from this session'), and adds ordering ('newest first') plus included fields ('status and one-line summary'). This clearly distinguishes it from siblings like consult_get (single consultation retrieval) and consult_start (initiating a consultation).

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 this is for browsing recent session consultations, which is distinct from consult_get (retrieving a specific one) and consult_cancel (cancelling). It doesn't explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to select it appropriately.

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

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses that the server stores entries, overwrites on duplicate ids, never infers verdicts, and persists to ~/.severally/history, enabling cross-session recording. This goes well beyond the schema.

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

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

The description is long but information-dense. Each sentence contributes to understanding the tool's behavior, id conventions, verdict meanings, and storage details. It is front-loaded with the core purpose and avoids fluff, though it could be slightly tightened without losing value.

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

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

Given the tool's complexity (nested entries, reflection object, multiple verdicts, no output schema), the description covers all necessary details: id format, verdict semantics, overwrite behavior, persistence location, cross-session support, and reflection conditions. Nothing an agent needs 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?

Schema coverage is only 33% (only reflection has a description). The description compensates fully by explaining what entries contain, the meaning of each verdict value, what effect and note represent, and when reflection should be used. It adds meaning that the schema omits.

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 action (write a verdict), the resource (points of an answer), and the context (after checking them in the repository). It differentiates from siblings by explicitly noting that predictions belong in consult_start, not here.

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

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

The description explains when to use the reflection parameter (when started with a prediction) and explicitly excludes writing predictions here, pointing to consult_start. It also indicates the id source from the result. It doesn't explicitly contrast with consult_get or consult_export, but the usage context is fairly 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that work runs asynchronously, the consultant starts in an empty working directory and is not told the repo location, model/permissions/timeouts are fixed, same-vendor calls are annotated with a caveat, and prediction is never sent to the consultant and cannot be rewritten afterward.

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

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

The description is long, but the tool is genuinely complex with nested parameters, three modes, fan-out, model suffixes, and privacy behavior. The structure is front-loaded with the key contract, then organized by parameter, and nearly every sentence carries operational value.

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

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

Given the high parameter complexity, no output schema, and no annotations, the description is remarkably complete. It covers return values, how to poll via consult_get, mode preconditions, unavailable targets, same-vendor caveats, prediction privacy, and environment constraints that would otherwise be invisible to an agent.

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 parameter documentation burden falls entirely on the description. It compensates thoroughly: target/targets semantics, followup_to restrictions, caller/caller_model intent, prediction shape and immutability, and mode-specific requirements for context.proposal.

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 precise verb and resource: 'Start a consultation with another agent (or several, via targets)' and states the immediate return contract (job_id/group_id, background execution). It clearly distinguishes consult_start from its siblings by framing it as the initiation step and explicitly referencing consult_get and consult_record for follow-up actions.

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

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

The description gives explicit when-to-use guidance for each mode: explore requires empty proposal, review requires proposal, debate requires both proposal and counterpoints. It also names alternatives and exclusions: targets is mutually exclusive with target, follow-ups never fan out, unavailable consultants are refused up front and should not be retried, and a model suffix should only be passed when the user asked for one.

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