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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the paid nature, the two-call payment flow, the fact that figures are computed from recorded rows with no projections, and the history depth accrual date. It doesn't describe pagination or error behavior, but the annotations carry the safety burden and the description adds meaningful operational context.

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 a single dense paragraph that front-loads the most important facts (paid, deep report, verdict/history/trend) and then explains the payment flow. It's longer than ideal but every sentence earns its place: cost, report contents, data source, history start date, and the two-call payment mechanism. The structure could be improved with line breaks, but it's not bloated.

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 paid tool with a two-step payment flow, the description covers the critical operational context: cost, payment requirements, and the need to call twice. The output schema is absent, but the description enumerates the report's components (verdict, history, trend block) so an agent knows what to expect. Minor gaps: no mention of rate limits or what happens on payment failure, but the core calling contract is fully specified.

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%, so the schema already documents all four parameters. The description adds context for x402_payment (the two-call flow) and mentions limit's default (365) implicitly through the schema. It doesn't add much beyond the schema, but the baseline 3 is appropriate when the schema does the heavy lifting.

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 clearly states the tool's purpose: a paid deep HostDeFi report that returns a current A+-F verdict, full dated safety history, and a derived trend block. It distinguishes itself from siblings by naming the specific report type and the unique history/trend components, so an agent can tell it apart from token_report and token_risk_verdict.

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 provides explicit usage guidance: call once without x402_payment to get payment requirements, then pay and call again with x402_payment set. It also states the cost ($0.25/call) and the condition that you are only charged when a result comes back. This is clear when-to-use and how-to-use guidance, including the two-step payment flow.

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