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

Goes well beyond the annotations: it discloses that form validation runs before anything is queued or billed, that failures return per-field rules by name, that valid listings enter the same review queue as web submissions with hourly publication, and that the call is metered at 0.10 USDC on Base with 10 signed-wallet free calls per 30 days plus an X-Wever-Wallet-Proof binding requirement. It does not contradict readOnlyHint=false or idempotentHint=true, though it never explicitly restates idempotency behaviour beyond the schema note about resubmitting with the same name and email.

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 well front-loaded: purpose and inputs first, then validation behaviour, then queue/publishing, then pricing and return shape. It is long and reads as a wall of clauses with endpoints and links trailing the prose, but almost every sentence carries operational weight rather than repeating schema text.

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 7-parameter write tool with no output schema, the description supplies everything an agent needs: required versus optional fields, validation and billing failure semantics, the review-queue outcome, the signed receipt containing submission_id and status queued, and auth/payment mechanics. Nothing material about invoking it correctly is left to inference.

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 baseline is 3, but the description earns a notch by clarifying that category is 'the directory layer' with concrete layer-style examples and that access is free/freemium/paid, plus flagging that the contact email stays private and that mcp_url is optional and gets an anonymous initialize plus tools/list check. It also explains how field-level validation errors surface, which the schema cannot express.

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: listing a server or tool in the Wever agent directory, invoked from the agent itself, and enumerates exactly which form fields constitute the listing. An agent can tell this is the submission step and not a status/lookup operation 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?

Usage context is implied rather than stated: the agent learns the validation-then-queue flow and that a paid call costs 0.10 USDC, so it can judge cost, but there is no explicit guidance on when to prefer this over the sibling wever_directory-status for checking an existing submission, nor a stated precondition (e.g. must have a live HTTPS site).

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