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

Annotations already declare this a safe, idempotent read, so the bar is lower, yet the description still adds substantial behavior: terms past 15 digits come back as a decimal string, a zero modulus is rejected, n is clamped to 0..8192, and each successful call costs $0.001 USDC via x402 on Solana. It also gives the equivalent HTTPS endpoint, which matters for an openWorldHint 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?

Front-loads the definition and recurrence, then bounds, then output format, then operational facts in one dense block with no filler. The pricing and URL sentences are operationally necessary for a paid x402 tool rather than padding.

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 only two params, no output schema, and annotations covering safety, the remaining burden is output shape and cost, both of which are addressed (decimal string past 15 digits, $0.001 per successful call). Minor gaps are the exact return type below the 15-digit threshold and the behavior of edge moduli.

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% (bare integer and pattern-constrained string), so the description has to carry the load, and it does explain that n is the term index bounded at 8192 and that mod optionally reduces the result. It omits details like whether mod is a digit string, what a mod of 1 returns, or the shape of the small-value (non-string) result.

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 verb+resource ('nth Perrin number') and pins the sequence down with seed values R0=3, R1=0, R2=2 plus the Padovan recurrence, which is what distinguishes it from sibling padovan/padovan_step tools. It stops short of naming those siblings explicitly, so the disambiguation is implicit rather than spelled out.

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 implied rather than instructed: the description explains what the tool computes but never says when to pick it over padovan, perrin_divide, or the other sequence tools. The rejection of zero for mod and the n bounds are constraints, not guidance on tool selection.

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