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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is low, but the description adds genuinely new context: the result is returned as a reduced fraction, and the call costs $0.001 USDC per successful invocation via x402 on Solana. That payment/auth detail is exactly the kind of operational trait annotations cannot express. It stops short of covering failure/refund behavior.

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 formula, followed by the domain, then pricing and the HTTPS mirror. Every element is useful, though five enumerated examples is more than the minimum needed to pin down the mapping and slightly dilutes the front-loading.

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 one required parameter and no output schema, the description must supply input domain, output representation, and invocation cost — and it does all three ('reduced fraction', 'n runs from 0 to 15', per-call price plus alternate endpoint). Nothing an agent needs in order to call it correctly is missing.

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 carries the burden: it defines n as the upper summation index ('from k=0 through n'), restates the legal range, and maps five concrete n values to their expected fractions. That gives the agent both semantics and a sanity-check oracle. Minor deduction because the range restatement duplicates the schema's min/max rather than adding syntax.

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 gives a precise mathematical definition (partial sum of 1/k! from k=0 through n) plus worked examples, so an agent knows exactly what is computed. It does not name or distinguish itself from nearby siblings such as e_convergent, e_cf_sum, or e_cf_prefix, which is the only thing keeping 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?

Usage is implied by the formula and the explicit domain n = 0..15, and the pricing line tells the agent this is a paid call. There is no explicit when-to-use / when-not guidance and no routing to alternative e-related tools (e_convergent, e_cf_prefix), so the agent must infer selection from the math.

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