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

Annotations already declare the full safety profile (readOnly, idempotent, openWorld, non-destructive), so the description's job is to add beyond that. It does: it enumerates the returned data categories, and it discloses a concrete cost of $0.008 per successful request, which is real behavioral context an agent can budget against. It stops short of noting rate limits or response size for a data-heavy call.

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?

One front-loaded sentence that leads with the action and follows with the returned payload; the pricing block is boilerplate but clearly delimited. The parenthetical 'etc.' lists are slightly bloated but still earn their place by conveying return scope.

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 values need not be explained, and annotations plus a 100%-covered 2-param schema leave little uncovered. The description adds the useful payload preview and cost. The remaining gap is disambiguation from the many overlapping CoinGecko siblings, which is the only material omission.

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% — both id (asset platform, pointing at /asset_platforms) and contract_address are documented in the schema itself. The description merely restates these inputs in prose without adding format, casing, or lookup guidance, so the baseline 3 applies.

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?

Specific verb (query) plus a concrete resource scope: metadata (image, websites, socials, contract address) and market data (price, ATH, tickers) keyed on asset platform + contract address. An agent can see exactly what payload this returns. It never distinguishes itself from near-neighbours like get_coingecko_coins_id or get_coingecko_simple_token_price_id, which is the only thing keeping it from a 5.

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 phrase 'based on an asset platform and a particular token contract address' describes the input basis rather than when to reach for this tool over its 27 siblings. There is no statement of when-not-to-use or which alternative to pick when only a price or only metadata is wanted.

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