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

The description adds real behavior beyond the annotations: per-call pricing (0.10 USDC on Base), a rolling 30-day free-call allowance, that the 402 body carries x402 terms, that credentials/mandates/action grants are still required, and that the adapter grants no authority and holds no server credentials. It also notes durable records, which partly reconciles the destructiveHint=true / idempotentHint=false annotations for a call that appears to be pure evaluation. It does not explain retry/duplicate behavior for idempotency_key or what is retained in the durable record.

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 most important sentence (what the tool does) is preceded by a pricing paragraph and buried inside a block that also carries a POST path, an operations-contract pointer, and a credentials disclaimer. Every piece is individually defensible, but the ordering means an agent skimming the first line gets cost, not capability.

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 nested schema with no output schema and no parameter descriptions, the definition leaves key gaps: the meaning of usage=synthetic vs operational, how weights and direction interact, and what the response packet contains beyond the one-line 'scores alongside missing evidence, failed constraints and tied alternatives'. The pointer to /api/operations-contract offloads schema detail to a document the agent may not be able to read.

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% on a 7-required-parameter, deeply nested schema, so the description must carry the load. It names 'alternatives, criteria, weights and constraints' but says nothing about the 'usage' enum (synthetic vs operational), the fixed 'mode' const, or what idempotency_key governs. Direction, min/max bounds, and the 16-option/16-criterion caps are entirely undocumented outside the schema.

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 core sentence is specific: 'Evaluate supplied alternatives against explicit weighted numeric criteria and constraints,' naming the verb, the input artifacts, and the outputs (scores, evidence gaps, ties). This is enough to separate it from payment/work-order rails like wever_payout-authorize or wever_workorder-create. It stops short of naming which sibling (e.g. wever_agent-trust-scorecard, wever_agent-decision-packet-rail vs. diligence rail) to pick when the task is scoring rather than settlement.

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?

'Operating boundary: Submit alternatives, numeric criteria, weights and constraints. Read the resulting scores...' describes the input/output contract of the call but not the conditions that select this tool over a sibling. No exclusion criteria are given, and the only usage signal is the pricing note (10 free calls / 30 days), which tells the agent about cost rather than fit.

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