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

With no annotations supplied, the description carries the full burden. It does usefully disclose the commercial/access model ("5 free trial calls per signed wallet"), which tells the agent a signed wallet is required and that calls are metered, and it implies a pure computation with no side effects. It does not state whether inputs are decimal fractions or whole percentages, nor whether missing inputs cause errors or defaults — a material gap for a no-annotation tool.

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?

Three short, front-loaded fragments: purpose, inputs, pricing note. Nothing is padded and the key verb appears in the first clause. The emoji is cosmetic but does not impede parsing.

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?

There is no output schema and no annotations, so the description must cover purpose, inputs, and access model — and it does all three in three sentences. For a deterministic arithmetic tool with five scalar inputs, this is close to the complete set of information an agent needs, with only the unit-convention ambiguity remaining.

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 0%, so the schema gives five bare string fields with no meaning. The description compensates partially by naming the five inputs and marking taxRate as optional, which resolves requiredness that the schema leaves ambiguous (required: none). However, it never specifies units or scaling — whether debt/equity are amounts or weights, and whether costEquity/costDebt and taxRate are 0.08 or 8 — which is the single most likely source of a wrong call.

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 description uses a specific verb-and-resource framing ("Calculate Weighted Average Cost of Capital") and states the return form ("as a percentage"), so an agent knows exactly what comes back. It does not contrast with near-neighbours like x402-weighted-average or x402-weighted-mean, but WACC is distinct enough in the catalogue that no confusion is likely.

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 is only implied by the domain: no statement of when a WACC calculation is appropriate, no prerequisites, and no mention of alternatives. The line "Provide equity, debt, costEquity, costDebt, and optional taxRate" gives input expectations but not selection guidance.

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