council

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 'Read-only' and describes the merged output shape (each verdict, agreements, disagreements), but says nothing about cost, latency, or auth implications of fanning out to three model families. Adequate but with real gaps.

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?

Compact and mostly front-loaded: the mechanism and merge structure come first, then the use contexts, then the read-only note. No wasted sentences, though the opening could lead with the outcome rather than the process.

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 14-parameter tool with no output schema, the description covers the core purpose and describes what comes back (verdicts, agreement findings, disagreements). The tier/cost and path guidance lives in the schema. The main omission is any note on the expense or latency of a multi-family call.

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

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

Schema description coverage is 100%, so the schema already documents all 14 parameters in detail. The description adds no parameter-level syntax or format beyond mentioning the three families, which the lanes enum already conveys. 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 states a specific mechanism: the same question dispatched to Codex, Gemini and GPT-OSS in parallel and merged into a consensus verdict. This distinguishes it from single-model siblings like codex_review and gemini_review without naming them explicitly. Clear but not maximally differentiated.

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 use contexts: risky changes, security-sensitive code, or a design you are unsure of. However, it offers no when-not guidance and does not route the agent away from overlapping siblings such as security_audit or plan_critique, so the alternative-selection guidance is incomplete.

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