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

Annotations already declare readOnly=true, destructive=false, openWorld=true, so the safety profile is covered. The description adds genuinely useful context beyond that: it draws on many data sources, takes 10-60 seconds (latency expectation), and requires an API key (auth prerequisite). It doesn't describe the shape of the returned answer, but for a read-only tool this is solid.

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?

Three tight sentences with zero filler. The core purpose leads, followed by scope, then the operational facts (latency, auth) that an agent needs before invoking.

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 no-output-schema, read-only analysis tool, the description covers the essentials: what it does, latency, and auth requirements. It stops short of explaining the answer's format or whether follow-up context persists, which is a minor gap given idempotentHint=false.

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 both parameters are already documented (question up to 1,000 chars; wallet for resolving 'my PnL'). The description adds no syntax, format, or example detail for either parameter, so 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?

States a specific verb (ask) and resource (Chord's analyst) in plain language, plus the domains covered (markets, tokens, wallets, perps, macro). The 'plain language' framing implicitly separates it from the structured-data siblings like chord_token or chord_trades, but it never names an alternative, so sibling differentiation is left to inference.

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?

Usage context is implied: use this for open-ended natural-language questions across the listed domains. However, it gives no explicit when-to-use/when-not guidance and never points to the specific chord_* tools for structured queries, which is the key routing decision among 17 siblings.

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