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

With no annotations, the description carries the full behavioral burden and mostly does not: it omits that this is a pure computation with no side effects, says nothing about output shape (a series of percentages? aligned to input indices?), and gives no limits or error behavior. The one genuine behavioral addition is the commercial note about 5 free trial calls per signed wallet, which tells the agent about an auth/payment gate but nothing about the operation itself.

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 core definition is front-loaded in a single efficient sentence and all three elements (what it computes, how it is defined, what to supply) are present. The emoji pricing tag is low-value noise but small, and 'Provide values array' reads awkwardly.

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 deterministic calculation with no output schema, the mathematical definition is adequate to understand the result. The missing piece is the input encoding for 'values', which is exactly the information an agent needs to make a successful call and which no structured field supplies.

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 the single parameter 'values' is an untyped-by-description string, yet the description calls it an 'array', leaving the actual encoding (comma-separated string, JSON array literal, newline-delimited) undefined. With one undocumented parameter, the description needed to specify the input format and does not.

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 a specific verb and resource ('Calculate the drawdown series of an asset's price') and even defines the computation as 'the percentage decline from its running peak', so the operation is unambiguous. It stops short of distinguishing itself from the very close sibling x402-max-drawdown, which an agent must infer from the name alone.

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?

No when-to-use or when-not-to-use guidance is given, and no alternative is named even though x402-max-drawdown is an obvious near-duplicate in the sibling list. 'Provide values array' hints at the required input but is not a usage condition, and nothing states what kind of price series (returns? raw prices? sorted by time?) is expected.

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