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

Annotations already cover the read-only/idempotent/non-destructive safety profile, but the description adds real value beyond them: per-call pricing ($0.001 USDC via x402 on Solana), an alternate HTTPS endpoint, and the specific rounding rule (half away from zero to the cent). It doesn't mention validation failures or what happens on malformed strings, keeping this from a 5.

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-loaded with the core purpose and each subsequent sentence adds a distinct mode or a pricing/rounding fact; no filler. It is denser than ideal — the chained 'Or ... or ... or' structure plus endpoint/pricing detail makes it a single long paragraph — but nothing is redundant.

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?

With 6 optional parameters, 17% schema coverage and no output schema, the description does the heavy lifting: it explains each mode's formula, the rounding behavior, and that results are in exact cents. The remaining gap is that it never states which parameters are required per mode or the shape of the returned values, which an agent must infer.

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 only 17%, so the description must carry the load and largely does — it defines what margin, markup, marginPct, markupPct, discounts and price/cost mean and how they relate mathematically. It omits the string encoding conventions (decimal strings with maxLength 20/12) and the exact mode-name-to-field mapping, which keeps it from being fully self-sufficient.

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 specific verbs and resources up front: 'Price, margin and markup in exact cents', then names the four computations (analyze, from-margin, from-markup, discount). An agent can distinguish this from nearby finance siblings like unit_economics or invoice_total 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?

The description gives explicit mode-selection logic by embedding the formulas each mode implies ('set a price from a cost and a margin percent', 'or from a markup percent', 'or walk a list of successive discounts'), so the agent knows which inputs trigger which behavior. It stops short of naming exclusion cases or alternative sibling tools, so it lands at 4 rather than 5.

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