bicameral_critique

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implicitly discloses non-mutating behavior ('before anything is edited') and implies the critique output guides revisions. However, it doesn't describe the output format, whether the critique is blocking, or any other side effects. For a tool with zero annotation coverage, more explicit behavioral context would be valuable.

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 zero waste. The purpose is front-loaded, the critique criteria are enumerated compactly, and the routing instruction ('Same arguments as bicameral_begin', 'then call bicameral_begin') closes the loop. Every sentence 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?

Given the output schema exists and the nested StepInput is well-documented in the schema, the description is reasonably complete for a critique tool. The top-level parameters are undocumented in the schema, but the 'same arguments as bicameral_begin' pointer mitigates this. An explicit note on what the critique response contains would push this to 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?

Schema description coverage is 0% for the top-level parameters (task, workspace, editor_model, task_kind, summary, steps, verify_command have no descriptions), but the nested StepInput type has rich per-property descriptions in the schema itself. The description compensates somewhat by stating 'Same arguments as bicameral_begin', routing the agent to another tool for parameter details. This is adequate but not exemplary.

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 ('Ask the editor model to critique'), a specific resource ('your draft plan'), and enumerates exactly what the critique covers (under-specified steps, wrong files, missing steps, unverifiable acceptance criteria). It distinguishes itself from sibling tools by positioning as a pre-edit review and naming bicameral_begin as the follow-up, so an agent can tell them apart without opening any schemas.

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 timing context ('before anything is edited') and a post-call action ('Revise where it is right, then call bicameral_begin'). It references 'Same arguments as bicameral_begin' for routing. It doesn't explicitly state when to skip the critique and go straight to execution, which would strengthen the guidance.

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