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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the description doesn't need to restate safety. It adds genuinely useful context beyond annotations: per-call pricing ($0.001 USDC via x402 on Solana) and an equivalent HTTPS endpoint, which matters for cost and transport decisions.

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?

The definition is front-loaded and each sentence carries information: purpose, worked examples, domain bound, pricing, and alternate endpoint. The example list is slightly verbose but serves as a correctness check, not filler.

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 one-parameter pure math tool with no output schema, the description supplies definition, examples, valid range, cost, and an alternate endpoint. The main gap is a precise statement of what n means and what shape the response takes, but the math definition plus examples largely cover it.

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 0%, so the description should compensate, but it only repeats the schema's min/max range ('n runs from 0 to 80'). It never explains what n represents semantically or what the returned value is for a given n, leaving the single parameter under-specified relative to the low coverage.

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 names the specific operation (cumulative sum of plane partition numbers through n) and gives concrete example values (1, 5, 24, 48) that let an agent verify the semantics. It implicitly distinguishes itself from the sibling plane_partition by emphasizing 'sum ... from 0 through n', though it never explicitly names the sibling as an alternative.

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 name and definition: an agent can infer this is for cumulative totals rather than individual values. There is no explicit 'use this instead of plane_partition when...' routing statement, and no when-not guidance.

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