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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false, idempotentHint=false), and the description adds real context by explaining the effect: it does not mutate the law, does not feed other tools' answers, and lands in the server log. However, 'the entry goes into the server log' sits in mild tension with readOnlyHint=true and the description never reconciles that the call does create a persisted record — an agent could read this as a purely side-effect-free operation. Useful added context, but the write-to-log vs. readOnly framing is left slightly ambiguous.

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?

Front-loaded with the core definition, then constraints, then the operational requirement (address + callId) and the log destination. It is dense but almost every clause carries information; the only soft spots are the somewhat rhetorical framing ('a report is a hypothesis for triage by a formaliser') and run-on enumeration.

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 must say what comes back, and it doesn't — the agent learns only that an entry goes into the server log, not whether it receives a report id, echo, or rejection on a bad address. It does cover the required address, the categories, and the dispute workflow, so for a 7-parameter diagnostic tool the coverage is adequate but leaves the response contract and error behaviour unexplained.

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 100%, so the schema baseline is already met, and the description adds meaning on top: package/fragment/predicate form an address checked against the catalogue, fragment is a StableId drawn from law_sources, and callId is the X-Law-Call-Id of the disputed answer. That cross-references sibling tools and supplies validation semantics absent from the schema. It does not explain how category affects triage or whether expected/observed need article citation, so not a 5.

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 and resource: 'A REPORT of a divergence between the formalisation and the source', then enumerates the divergence kinds (contradiction, missing norm, label mismatch, broken address). It also clarifies the artifact's standing relative to siblings ('never reaches the answers of the other tools'), so an agent can tell this apart from law_explain/law_argue, though it never routes to a named alternative.

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?

Gives clear trigger conditions (you disagree with an answer; you found a norm in the source not expressed as a rule; an address cannot be found) and a strong usage constraint ('it does NOT change the law', 'not derived does not become derived'). It also states the filing prerequisite: an address validated against the catalogue, plus callId from the disputed answer. No explicit 'do not use this for X, use sibling Y instead', so it stops 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.