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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds genuine UI behavior beyond that — the card is interactive, the user can switch between all fifteen markets inside it, and a button links out to the heatmap on swiftedge.uk (a user-initiated link, not a tool-side external fetch, so no annotation contradiction). It stops short of saying whether the figures are a one-shot snapshot at call time or keep streaming.

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 names the deliverable before listing contents, and a second sentence gives the trigger. The content list is dense but every item describes a distinct card element; 'the free live order book heatmap on swiftedge.uk' is the only phrase that leans promotional rather than informational.

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?

With no output schema, the description carries the burden of explaining what comes back, and it does so thoroughly by enumerating the card's contents and interactions. What remains unstated is refresh behavior (live vs. snapshot at invocation) and how this card relates to the raw data siblings, which matters given twelve alternatives.

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% and the single parameter is a fully enumerated enum, so the schema already carries the parameter meaning. The description only adds the fact that the card lets the user switch among all fifteen markets, which is a UI property rather than guidance on the `market` argument itself. 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 and resource ('show an interactive live card for one market in the chat') and enumerates exactly what the card renders: price, UTC range, order book walls within 1% of price, nearest key levels, and a heatmap button. That is far more specific than a snapshot or raw order book tool, though it never names the sibling it replaces, so the boundary with get_market_snapshot and get_order_book must be inferred.

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?

'Use it when the user wants to see, watch or check a market' is an explicit trigger, but it is broad enough to cover most of the sibling catalog (snapshot, overview, order book, key levels) with no exclusions or named alternatives. The agent gets a positive cue but no routing rule for choosing this card over the underlying data tools.

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