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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, and the description goes well beyond that: no network request, fetch, money movement or external write; pricing at 0.10 USDC per call via x402 with a 10-call free tier; X-Wever-Wallet-Proof binding to the exact JSON arguments; and an Ed25519 signed receipt. It also enumerates the verdict values (mutation_reachable, boundary_unverified, read_only), which the agent otherwise could not predict.

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?

Purpose is front-loaded, but the single long paragraph then mixes audit logic, sibling routing, verdict values, endpoint path, pricing, wallet-proof binding, receipt format and two URLs. Several clauses are awkward and overlapping ('with the writes hiding inside query-shaped tools listed apart'), and the mutation-path list is repeated in near-duplicate form, costing readability for little added information.

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 nested-schema tool with no output schema, the description is unusually complete: it explains the required inputs, the three possible verdicts, the signed receipt, payment mechanics and authentication binding. Remaining gaps are minor, such as how the report is structured or whether a mutation_reachable verdict blocks anything.

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 67% and the schema already carries descriptions for the important nested fields (accepts, operations, described_as, query_access, side_effects, methods). The description's enumeration of those same fields largely restates them rather than adding syntax or interpretation rules. The one genuine addition is the rationale that query-shaped tools can hide writes, which explains why operations and query_access must be supplied separately.

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 action and target: submit an agent plus every tool it can call, and receive a signed report naming every mutation path. It distinguishes itself from related checks by naming wever_authority-scope-check (reachable actions against an authority grant) and wever_escape-path-check (sandbox routes into production). The opening phrasing ('submit an agent meant to investigate and change nothing') is slightly indirect, but the intent is recoverable without opening the schema.

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 a clear use condition (an agent that is supposed to read and change nothing) and explicitly routes adjacent concerns to two named sibling tools. What is missing is an explicit when-not-to-use statement, e.g. for agents that are legitimately allowed to mutate, which would sharpen selection further.

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