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

No annotations are present, so the description carries the behavioral burden. It discloses the core computation and the input/output relationship, but it omits edge-case behavior such as series length under two, division by zero, or whether percentages are returned as decimals or formatted values.

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 description is compact, with the purpose stated first and input/output semantics in the second sentence. The leading 'Returns:' fragment is slightly redundant, but there is otherwise no filler or unnecessary detail.

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 no annotations, no output schema, and an empty input schema, the description must do the full explanatory work. It covers the high-level formula, but it does not specify return shape, percentage formatting, edge behavior, or how the promised 'values array' maps to actual tool arguments, leaving the definition not fully actionable.

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?

The description adds a useful parameter hint by instructing the caller to 'provide values array,' which is absent from the empty input schema. However, because the schema defines no properties, an agent cannot confirm a valid call shape from the structured definition, and the element type and minimum length remain implicit.

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 ('Calculate') and resource ('price series'), and explicitly defines the output as 'percentage changes between consecutive items.' This clearly distinguishes the tool from siblings like x402-log-returns, which computes log returns rather than simple period-over-period percentage changes.

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?

There is no guidance on when to use this tool versus the many related return/change tools, such as x402-log-returns, x402-percent-change-array, or x402-holding-period-return. The description only says what to provide, not when this tool is the right choice or when to prefer an alternative.

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