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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial beyond-schema behavior: a $0.001 USDC x402 charge per successful call, the Solana payment rail, an equivalent HTTPS endpoint, and QuantLib parity as the reference implementation. Cost and payment mechanics are exactly the kind of hidden trait an agent needs before invoking.

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?

Purpose is front-loaded and there is no filler — every clause maps to a capability or constraint. It is, however, a single very long run-on sentence that could be split into mode-specific structure for faster scanning.

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 nine parameters, no output schema, and read-only annotations, the description usefully implies return values (days, year fraction, accrued days, accrued interest per face amount, previous/next coupon dates). Remaining gaps are date formatting and per-mode parameter applicability, which matter for correct invocation.

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?

At 44% schema coverage the description carries real weight and does explain convention coverage, per-face-amount principal, simple interest rates, and coupon/settlement concepts. But it never names parameters or states the accepted date format (10-char strings) or which of start/end/settlement apply in each mode, leaving gaps the schema text does not fill.

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 precisely what the tool computes: day counts and year fractions under named conventions, accrued interest, and coupon-schedule/accrued figures in coupon mode. The resource and verb are unambiguous. It does not, however, differentiate itself from plausible neighbours in the catalog (bond_calc, prorate, compound_interest, date_calc), which keeps it from a 5.

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 clearly delineates the two operating modes — 'between' for date-pair day counts and simple interest, 'coupon' for fixed-coupon bond schedule/accrual around a settlement date — so an agent can pick the right mode. It stops short of naming alternatives or any when-not-to-use condition.

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