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

Goes far beyond what readOnlyHint=true, openWorldHint=true, and idempotentHint=true provide. It discloses that this is a paid endpoint, the exact cost ($0.002 USDC via x402), the fact that without payment a 402 challenge is returned, and that the fiatdock-mcp npm package pays automatically. There is rich detail about parameter semantics and failure behavior — even though the `payment` param documentation covers the mechanics, the description states that nothing is charged for the 402 and that failed calls settle nothing. Consistent with and additive to the annotations.

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?

Every sentence earns its place. The cost stamp comes first, then the data returned, then the use case, then the payment behavior. It covers pricing, protocol, data shape, target audience, and failure mode in roughly five sentences without fluff. The structure is perfectly front-loaded and wastes zero tokens.

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 an output schema present, the description doesn't need to document return values. Given that 0 params are required, 100% schema coverage exists, and annotations are comprehensive, nothing essential is missing. The only slight gap is that the use case is narrowly scoped to a treasury/payments agent as opposed to other potential consumers, but that's not a completeness issue — it's the description's strongest differentiating feature.

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 100%, placing the baseline at 3 per the rubric. The description meaningfully adds value by explaining the two-phase payment exchange at the tool level ('Without payment this returns the 402 challenge; the fiatdock-mcp npm package pays automatically'), which contextualizes both the `asset` and `payment` parameters without duplicating the schema's own documentation. It reinforces when to send the `payment` parameter without restating its exact payload format, so there's a clear division of labor.

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?

States a specific verb+resource and enumerates the exact data points returned: total circulating supply, peg deviation from $1.00, peg mechanism, per-chain breakdown on Base with share, top chains by supply. The 'PAID ($0.002 USDC via x402)' prefix unambiguously signals the billing model, distinguishing it immediately from the 17 sibling tools, especially token_price, token_metadata, and token_report. It leaves no ambiguity about what an agent gets by calling this tool.

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?

The description explicitly names the target use case — 'A treasury/payments agent uses it to check its settlement asset is healthy' — which helps an agent decide when this is the right tool. However, it does not name alternative sibling tools or state when NOT to use it. There is clear context but no exclusion, which fits the level 4 definition.

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