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

Goes well past the annotations (which only say read-only/idempotent) by disclosing the all-or-nothing error contract, the validation rules applied (each rule exactly once, valid status/confidence, version matched, quotes verbatim), and the fact that output is advisory with evaluation_source "client" and authoritative false. The consequence — it cannot authorise publication on the directory — is exactly the kind of behavioral fact an agent must not assume.

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 core purpose and the advisory caveat are front-loaded and each block is relevant, but the hard-wrapped prose and editorial asides ('Say so when you report it', the bare 'Advisory.') add friction without adding callable information. Slightly tighter phrasing would lose nothing.

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 naming the result's shape (score, gate, gate.missing, decision, evaluation_source, authoritative) and its trust level. Remaining gaps — the exact failure payload and full result fields — are minor for an advisory aggregation call, though richer than zero.

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 carry the load, and it does: verdicts are constrained by the ruleset (one per rule, valid status/confidence, judged at the supplied version), ruleset_version must match the version judged at, brief quotes must be verbatim, and directory_context=false drops directory-only policy rules. Every parameter gets semantics beyond its name.

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 transformation: model verdicts in, the bar's score/gate/decision out, via validation plus the same engine the service uses. That is far more than a restated name and lets an agent tell it apart from prompt/ruleset fetchers. It does not explicitly contrast itself with siblings like check_brief, which keeps it off 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?

Implied sequencing is clear: you have verdicts, you want an advisory score, and 'Any error means no score — fix and resend' plus 'Fix gate.missing first' tells the agent what to do on failure. What is missing is an explicit statement of when to prefer this over check_brief or the service-side scoring path; the exclusions are left to inference.

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