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

Goes well beyond the annotations: enumerates the four verdicts (not_disclosed, understated, disclosed, nothing_to_disclose), lists exactly what the report answers, and states that it reads only the material in the call with no network, wallet, merchant lookup, order, or external write. It also discloses the pricing model (0.10 USDC on Base via x402 exact with 10 signed-wallet free calls per 30 days), the X-Wever-Wallet-Proof binding requirement, and the Ed25519 signed receipt — none of which the annotations convey.

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 purpose and scope in the first two sentences, then moves to verdicts, side-effect guarantees, payment, and endpoints in a sensible order. It is a single dense block with some enumerated negations ('no network request, fetch, wallet or merchant lookup, order, payment or external write') that could be compressed, but virtually every sentence carries information.

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 nested, three-required-parameter tool with no output schema, the description covers the return surface (report contents plus signed receipt), the verdict vocabulary, the payment and auth requirements, and the endpoints. An agent has enough to call it correctly and interpret the result without further reference.

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?

Adds meaning beyond the 75% schema coverage by explaining the commercial_terms structure in prose: affiliate commission with its rate or amount, paid placement, sponsorship, or none, which maps the kind enum to its rate/amount fields. Placement and recommendation text are also paraphrased, though the nested seller/product fields and the label parameter are not elaborated.

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 action and artifact: submit one recommendation with its commercial terms and placement, and get back a signed report on whether the commercial interest is disclosed. It also draws a hard scope boundary ('Disclosure only; the merit of the recommendation is outside the report'), which separates it from evaluation-style siblings such as fair-value or the various evidence-check tools.

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?

Makes the input condition explicit (one recommendation, its terms as they stand, and where it will appear) and names the exclusion (merit is out of scope). It stops short of naming an alternative tool or telling the agent when to skip the check entirely, so it is clear context without explicit routing.

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