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

With readOnlyHint=true and destructiveHint=false already in annotations, the description adds value by disclosing the return type ('response is markdown text from the eSIM Finder knowledge base') and a data-freshness trait ('the regions topic is generated live from the current catalog'). This goes beyond what annotations alone communicate, though it does not address concerns like rate limits or auth — minor for a read-only KB retrieval tool.

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 description is long, but the length is earned: purpose is front-loaded in the first sentence, followed by usage criteria, then per-topic expansions each carrying selection-relevant detail. Minor redundancy exists — the enum values are restated from the schema and the closing 'prefer this tool over guessing' repeats earlier guidance — so it is not perfectly lean, but no sentence is wasted.

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?

Given an output schema exists (so return structure need not be explained), annotations cover the safety profile, and the single required parameter is fully documented by both schema and description, nothing an agent needs to select or invoke this tool is missing. The description even covers edge routing like troubleshooting and post-purchase questions, which is complete for a knowledge-base retrieval tool.

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 baseline is 3, but the description dramatically expands every enum value beyond the schema's one-line listing. Each topic is annotated with the actual content it returns — e.g., compatibility covers per-device install steps and specific error messages like 'This Code Is No Longer Valid,' travel-pass includes the full 130-destination list, regions enumerates all 14 current bundles. This is far beyond baseline and materially improves correct topic selection.

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 description opens with a specific verb-resource pair — 'Retrieve detailed narrative information about the eSIM Finder product and connector' — and explicitly scopes itself as 'beyond what the search/checkout tools surface,' cleanly differentiating it from its siblings (search_esims, create_checkout_url, get_plan_details). The purpose is unmistakable even before reading the parameter details.

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?

Provides explicit usage routing: 'Use this for any question that is NOT a price/plan search' states the exclusion, while concrete question patterns ('how do I...', 'what is...', 'my eSIM is not working', 'what do I do after buying') tell the agent exactly when to reach for it. It also closes with a directive to prefer the knowledge base over guessing, which is actionable routing guidance.

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