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

Adds substantial context beyond the annotations: it confirms no network request, fetch, money movement, message, sharing, configuration change or external write occurs; discloses pricing (0.10 USDC on Base via x402 exact, 10 free signed-wallet calls per rolling 30 days); states the X-Wever-Wallet-Proof binding requirement; and notes the return includes an Ed25519 signed receipt. It also enumerates the four verdicts the tool can return.

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 and payload are front-loaded, but the body is a single dense run-on built from semicolon chains, mixing scope, report logic, sibling routing, verdicts, pricing, auth and contract links. The operation list duplicates the schema enum, and the pricing/legal footer could be trimmed or split for scanability.

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?

There is no output schema, so the description carries the return-value burden and does: it describes exactly what the signed report names (endpoints that can delete, administer, move money or reach sensitive data and are exposed without a recorded decision, by generation/passthrough alone, without a named decider, or contrary to a withholding decision) plus per-item fixes and the verdict set. Nothing an agent needs to call it correctly is missing.

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 baseline is 3, but the description goes further by explaining the semantic payload of each endpoint entry: operations, most sensitive data handled, agent callability, provenance of tool creation, and the decision with outcome, named decider and date. It ties those fields to the report logic (e.g., a decision that names no decider is flagged), which adds meaning beyond the raw enum lists.

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: submit an API inventory and receive a signed report on agent-exposed endpoints. It explicitly distinguishes itself from three siblings (wever_exposure-cap-check for spending caps, wever_authority-scope-check for agent authority, wever_mcp-server-check for client MCP configuration), so an agent can route without opening any 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?

Names three alternative tools and the condition each covers, which is strong routing guidance. It does not frame an explicit trigger ('use this when auditing your API surface for undecided agent exposure'), leaving the when-to-invoke inference to the agent from the purpose sentence.

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