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

With no annotations present, the description carries the full burden and does meaningfully more than restate the name: it discloses the computation method ('exact BigInt exponentiation') and two hard input rejections (p below 3, even p). It stops short of saying what error surfaces on rejection, whether p must be an odd prime for the result to be meaningful, or any rate/cost behavior beyond the free-trial note.

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?

Everything useful is packed into a single front-loaded sentence, with the tool's name leading and the result domain following immediately; the trailing free-trial blurb is boilerplate rather than padding of the core content. Semicolon structure keeps it tight, though the promo emoji adds no informational value.

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 two-parameter math tool with no annotations and no output schema, the description covers the computation, result values, and input validation, which is much of what an agent needs. It still leaves the argument encoding, the effect of a composite p, and the error path on rejection unspecified.

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% and neither 'a' nor 'p' is described in the schema, so the description must compensate. It clarifies that p is the modulus and must be odd and at least 3, and that a is taken modulo p, but it never explains the string encoding for these BigInt arguments (decimal string? hex?) or whether a is reduced before computation.

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 states a specific verb and resource — 'Computes the Legendre symbol of a modulo p' — and even pins the output domain to '1, 0 or -1,' so an agent knows exactly what comes back. It does not, however, differentiate itself from near-neighbors in the huge math sibling set such as x402-is-quadratic-residue or x402-is-prime, which is what a 5 would require.

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 mathematical domain rather than stated. The description gives rejection conditions ('rejects p below 3 or an even p'), which partly functions as a when-not rule, but it never says when to pick this over alternatives like x402-is-quadratic-residue or a Jacobi-symbol-style sibling, and it doesn't state the primality prerequisite.

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