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

Adds substantial context beyond the annotations: pricing (0.10 USDC on Base, 10 signed-wallet free calls per rolling 30 days), the 402 body for x402 terms, and the explicit statement that it "grants no authority and never supplies server credentials." It also reconciles the non-read-only/non-idempotent hints by explaining the call is paid, and the side-effect-free nature of the evaluation itself is clearly noted; only latency/error behavior is left unstated.

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?

Front-loads the paid-call terms, then the purpose, then the operating boundary in a tight sequence with no redundant sentences. Every clause (pricing, boundary, credential disclaimer, computation scope) carries distinct information for a complex tool.

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?

The description signals that the response contains "the preview and reasons" but no output schema exists and the structure of reasons or decision fields is never described. For a 13-parameter, all-required evaluation tool with zero schema descriptions, the definition is adequate but leaves the agent guessing about the result shape and limit-interaction semantics.

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 description coverage is 0% across 13 required parameters, so the description carries the burden. It partially compensates by naming the conceptual inputs (scope, budget, usage, expiry, fee limits) that map to allowed_product_keys/requested_product_key, budget_minor/spent_minor, used_runs/max_runs, expires_at/as_of and requested_fee_minor/max_fee_minor, but it never explains minor units, the currency constraint, or how as_of anchors expiry.

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: "Preview whether an action fits the supplied scope, budget, usage, expiry and fee limits," which lets an agent tell this is a policy-fit evaluation rather than a mutation. It does not differentiate itself from closely overlapping siblings such as wever_agent-budget-guard or wever_agent-permission-ledger, leaving the boundary ambiguous.

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?

"Supply the policy, usage and proposed action. Read the preview and reasons" implies the pre-flight usage pattern, and the role split (agent prepares next request, human adjusts policy or approves) is genuinely useful. However, there is no explicit when-not-to-use guidance or named alternative among the many budget/permission siblings.

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