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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the grounding source: answers come from CurrencyGuard's 'approved product and FAQ content', which tells an agent the output is curated/authoritative rather than generated. It does not mention rate limits or response shape, but for a zero-parameter read tool that is minor.

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?

Two sentences, front-loaded with the core action, with the covered topics enumerated compactly. The topic list is the item most open to trimming, but it does usefully signal the breadth of answerable questions rather than padding.

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 parameterless, read-only informational tool with no output schema, the description supplies everything needed to invoke it correctly: what it explains, what content grounds it, and what topic range it covers. The only gap is the unaddressed boundary with compare_guard_with_forward, which matters given the overlapping comparison topic.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a 0-param tool is 4. The topic list in the description is input-adjacent guidance rather than parameter documentation, so it cannot be credited as parameter semantics.

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 (explain) and resource (the Guard product), then enumerates the question topics it answers, so an agent knows exactly what this tool is for. It is not fully differentiated from siblings: it claims to cover 'how it compares to forwards or options' while a dedicated compare_guard_with_forward tool exists, leaving a routing ambiguity.

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 is implied — reach for this on conceptual/FAQ questions about the Guard rather than pricing or rate lookups — but there is no explicit when-to-use statement or exclusion. Critically, it never tells the agent when to prefer compare_guard_with_forward over this tool for comparison questions, despite the overlapping scope.

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