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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add behavior. It does: results are tri-state (mapped / ambiguous with candidates / missing), which is important for the agent to handle correctly, and it implies the correct follow-up action. It does not expand on what causes ambiguity or missing entries, or on pagination.

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 short sentences plus a compact example, with no redundant filler. Slightly output-first rather than action-first, but the example earns its place by anchoring the required parameter, so it stays tight overall.

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 an output schema present the description need not explain return fields, and full schema coverage handles parameters. The tri-state result summary plus the trade-the-mapped-symbol guidance cover the essentials for a 5-parameter read tool; only the relationship to the sibling list_instruments is left unstated.

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 the schema already documents limit, query, cursor, account_id, and response_format thoroughly (including the note that account_id is not the MT5 login). The description's example only spotlights account_id and query, adding no new semantics. 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?

The title and first sentence make the resource and transformation clear: it resolves each instrument's symbol on a specific account's broker, classifying results as mapped, ambiguous (with candidates), or missing. That is a distinct operation from the sibling list_instruments, but the description never names that sibling or explicitly contrasts the two, so 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?

'Trade the mapped symbol' gives one concrete downstream usage hint, which is genuinely helpful. However, there is no guidance on when to reach for this tool versus list_instruments or get_symbol_snapshot, and no exclusions or preconditions stated beyond the account_id requirement.

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