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

With no annotations, the description carries the full burden and does well: it discloses Pro-tier access, that outcomes are measured at +4h/+24h with worst drawdown, and that outcomes are never re-scored after the fact. This gives the agent an honest integrity-oriented picture, though it does not cover ordering or rate-limit behavior.

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 front-loaded with the core purpose and keeps the detail organized. The sentence about get_rejection_funnel's sibling REST endpoint is awkward and slightly tangential, but overall the text is compact and information-dense without redundancy.

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?

An output schema exists, so return-value structure is covered elsewhere. The description documents the single parameter, clarifies the data fields, states the access tier, and gives an alternative access path. Minor details like sorting or pagination are absent but not critical for this simple tool.

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 schema only provides an integer limit with a default and no description. The description's Args section adds real meaning: 'Number of recent signals to return (1–200, default 20)' gives a range and semantics that the schema lacks, fully compensating for the 0% schema coverage.

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 opens with 'Recent calls and what Bitcoin did next (Pro tier)', naming a specific resource, time scope, and what the data enables. It clearly distinguishes this signal-history tool from the market-data siblings like get_fee_histogram or get_mempool_stats.

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?

It gives clear context: use it to verify rather than trust, and it notes that a keyless public track record exists on the website/REST endpoint as an alternative. It could be more explicit about when not to use this tool versus sibling tools, but the Pro-tier gating and public alternative serve as practical guidance.

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