get_plan_detailsGet everything about one eSIM data plan: which countries the SIM roams in, data volume, validity in days, speed and fair-use throttling, and price. Use after search_esim_plans or find_cheapest_plan when the traveller asks what exactly a plan includes before buying.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | ISO currency, default USD | |
| variant_id | Yes | Variant id from search_esim_plans |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds value by listing typical return fields (countries, data volume, etc.) but does not go into detail about edge cases (e.g., what happens if variant_id is invalid or if a plan has no throttling). For a read operation with good annotations, this is adequate but not exceptional.
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 exactly two sentences: the first lists what the tool returns, the second gives precise usage context. No redundant words, no padding. Every sentence is essential and front-loaded.
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 that the tool has 2 parameters with full schema coverage, a readOnlyHint annotation, and no output schema, the description covers purpose, usage guidance, and key return fields. It is missing a complete enumeration of all fields (e.g., does it return the plan name? provider?), but the listed fields cover the most critical aspects. Overall, the description is nearly complete for the tool's simplicity.
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%; both parameters have clear descriptions in the schema (currency: ISO currency default USD; variant_id: from search_esim_plans). The tool description adds no new information about parameters beyond the schema. Baseline score of 3 is appropriate because the schema already carries the semantic load.
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 uses a specific verb 'Get' and clearly identifies the resource as 'one eSIM data plan'. It enumerates the key details returned (countries, data volume, validity, speed, throttling, price), which distinguishes this tool from siblings like search_esim_plans (list/search) and find_cheapest_plan (price comparison). The purpose is unambiguous and well-scoped.
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?
The description explicitly states when to use: 'Use after search_esim_plans or find_cheapest_plan when the traveller asks what exactly a plan includes before buying.' This provides clear workflow context. It does not mention when not to use or list alternative tools explicitly, but the workflow implication is strong enough to guide correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The tools are mostly distinct: search/check/find for discovery, get/list for details, create/topup for purchase, and order/esim management. The only mild overlap is between check_destination_coverage and find_cheapest_plan, but the description clarifies when to use each. Overall clear boundaries.
All tool names follow a consistent verb_noun pattern: check_destination_coverage, find_cheapest_plan, search_esim_plans, get_plan_details, create_checkout, get_order_status, list_esim_topups, topup_esim, my_esims, my_orders. The 'my_' prefix for account-specific lists is a clear, consistent exception that serves its purpose.
Ten tools is an ideal count for an eSIM travel data server. Each tool covers a necessary step in the user journey: discovery (search, check, find), details (get_plan_details), purchase (create_checkout), post-purchase (get_order_status, my_orders), and management (my_esims, list_esim_topups, topup_esim). Nothing feels redundant or missing.
The tool surface covers the full lifecycle: searching/checking coverage for a destination, getting plan details, purchasing, checking order status, viewing purchased eSIMs, topping up, and listing orders. No obvious gaps—this covers everything a traveller would need from planning to refilling data.