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

Adds real behavior beyond the annotations: the server repeats the computation and explicitly refuses on hash mismatch, nodeId output is capped at 24 KB with an explicit refusal beyond that, answerResource mode avoids recomputation and client page loading, and the default is proofRef-chain only. The annotations only cover read-only/destructive/idempotent/openWorld, so this failure-mode and limit disclosure is genuinely additive.

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?

Information-dense and front-loaded with the purpose, but written as telegraphic fragments ('The compact input: question..., resultHash and codeHash from the provenance of the answer.') that blend parameter semantics with behavioral constraints in run-on sentences. Size is reasonable for a 6-parameter multi-mode tool, but scanability suffers.

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?

An output schema exists, so return values need not be described, and the description covers mode selection, verification semantics, size limits, and node-scoped selection. Given the nested-object oneOf schema, this is close to complete; the only loose end is the unexplained proofHash/scope references that do not map to schema properties.

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?

With only 50% schema description coverage, the description still accounts for all six parameters: question (original law_ask arguments), resultHash and codeHash (from the answer's provenance), evaluation (from law_ask proof=true), answerResource (fullAnswer.uri of a stored proof=true answer), and nodeId (selects one node plus its premises). It also conveys the mutual exclusivity of the oneOf modes, though it mentions proofHash and scope, which do not appear in the schema properties, adding slight ambiguity.

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 (unfold/explain) and resource (the proof of a law_ask answer) and even names the output shape, the 'rule ← premises → conclusion' chain. It anchors itself to the law_ask sibling as the producer of its inputs, so an agent can place it in the workflow, though it never contrasts itself against an alternative tool.

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 conditional context for the three input modes: pass question/resultHash/codeHash to have the server recompute and verify, pass the evaluation from law_ask(proof=true), or use answerResource to explain a stored snapshot without recomputing. There are no explicit exclusions or sibling alternatives, but the mode-selection guidance is concrete.

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