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

Annotations already cover readOnly/idempotent/openWorld, but the description goes further by disclosing that the endpoint is public read-only, that meta.billing is x402-ready, that /mcp requires X-API-Key or Bearer auth and REST can settle x402 after a 402, and that live pricing must be read from meta.billing rather than hard-coded. That is genuine operational detail beyond the annotations. It is undercut by mixing in dynamic-pricing guidance for meteora_brief, a different tool, which muddies rather than clarifies this tool's 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 purpose and sibling routing are front-loaded correctly, but the body is a dense run-on mixing REST MIME types, dual-auth mechanics, a signup URL, and dynamic pricing that belongs to another tool. Several clauses (the vnd.agentshare.compact+json media type, the pricing URL, the meteora_brief price range) do not earn their place in this tool's description.

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 three-parameter, optional-argument read tool with full schema coverage and no output schema, the definition covers what the data is, where it comes from, and how to reach it. What it never describes is the return shape — what a 'verdict/risk envelope' actually contains or how highlights_only changes the response — which is the main 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 coverage is 100%, so the schema already documents limit, compact and highlights_only — baseline 3. The description adds little: it repeats the limit guidance but with a conflicting range ('prefer small limit (3–5)' vs the schema's 'prefer 5–10' and default of 15), and its ?format / ?fields / ?simple notes describe REST query strings rather than the MCP parameters.

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 the resource and scope precisely: protocol-level Solana DEX metrics (24h volume and change) sourced from DefiLlama, plus a verdict/risk envelope. It explicitly carves out the pool-level case and names the two Meteora siblings, so an agent can distinguish it from meteora_brief and meteora_pool_detail. The only weakness is that there is no crisp leading verb — the purpose statement is a noun phrase competing with billing/auth boilerplate.

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?

Gives explicit routing guidance for the closest Meteora alternatives ('For pool-level Meteora DLMM use meteora_brief or meteora_pool_detail') and a latency tip ('prefer small limit'). It says nothing about when to choose this over its other DEX siblings such as dex_overview or dex_top_movers, which are arguably equally close alternatives, leaving a real gap in the when-to-use story.

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