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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, and the description reinforces this with 'reads only the material in the call: no network request, fetch, money movement, message, sharing, configuration change or external write.' It adds pricing (0.10 USDC x402 exact on Base), the 10 free signed-wallet calls per rolling 30 days, the X-Wever-Wallet-Proof binding requirement, and an Ed25519 signed receipt. Apart from error/failure modes, the behavioral profile is well covered.

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?

The purpose is front-loaded, but the core sentence is a long comma-chained run-on that forces the reader to parse field lists inline. Most content earns its place, yet the same semantics could be carried in noticeably fewer words.

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 carries return-value burden and does so by enumerating what the signed report flags (rules written nowhere, held only in live config, owned by no one or by an agent, reviewed before the last toolset change, naming retired tools). The contract and human page URLs are given for deeper detail; only error/edge-case behavior is left unaddressed.

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 description compensates by spelling out the meaning of each nested rule field — where it is written (including 'code only or nowhere'), owner and owner type (including agent and vendor default), last changed and reviewed, review-on-toolset-change, and covered tools — plus the toolset's changed date and current tools. It adds interpretive meaning (e.g. 'still naming retired tools') rather than restating schema text.

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 opening states a specific verb and resource: submit the gateway/policy rules with their written location, ownership, review dates and covered tools, plus the toolset. It also names the exact verdict set (unwritten_rules, rule_gaps, rules_unverified, rules_governed), so the agent knows precisely what is being evaluated.

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 routes explicitly to siblings: route reach is wever_gateway-coverage-check and single-action precedence is wever_policy-precedence-check, with a free sample via wever_gateway-rules-sample. That is a clear when-to-use-which map plus a low-cost trial path.

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