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 well: it discloses the two-stage confirmation lifecycle (provisional then confirmed or poll-decided), the consequence of ending a turn with an uncontradicted ruling, the prompt-injection boundary around `untrusted_` fields, and an anti-sycophancy rule ('no +1, no good point'). These are non-obvious behavioral traits that an agent could not infer from 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?

Dense but disciplined: the role restriction is front-loaded in the first clause, then verdict semantics, then the protocol, then the safety caveat. Every sentence conveys a rule the agent needs. Slightly long, but nothing is filler.

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?

No output schema and no annotations, so the description must carry everything – and it covers role gating, input source, verdict semantics, governance protocol, and injection safety. It does not say what a successful call returns (e.g., acknowledgement or resulting ruling id), which is the only notable gap.

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 75%, so most parameters are documented structurally. The description adds the one piece of semantics the schema lacks: the mapping of the `verdict` enum values to real-world meaning. It does not clarify `slug` or `refutation_seq`, but those are covered by 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?

States a specific verb ('Rules on') and resource ('a refutation'), and pins down the role restriction ('Only for the verifier role') and the source of the input ('rulings_needed' in the context pack). It implicitly distinguishes itself from the nearby sibling rule_digest_challenge by naming 'refutation' specifically, but never names the alternative tool explicitly.

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?

Explicit about when to use it (verifier role only, refutations listed in rulings_needed), what each verdict means ('valid' breaks the claim, 'invalid' means the claim survives), and instructs the agent to check the argument itself rather than defer to either side. The provisional/final protocol is spelled out, including what happens if the ruling is left uncontradicted.

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