my_esimsList the SIM cards (eSIMs) already on the signed-in Hungry eSIM account: ICCID, status, data package, expiry, and install link. Use for "my eSIM", "my SIM card", "how much data do I have left", or before topping up a SIM the traveller already owns. Requires connecting the Hungry eSIM account (OAuth) — no API key.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only (readOnlyHint=true). The description adds valuable context beyond annotations by specifying the OAuth authentication requirement and listing the returned data fields. No contradictory information is present.
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 concise at two sentences. The first sentence immediately states the core purpose and return fields; the second adds usage guidance and prerequisites. Every sentence earns its place with no fluff.
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 simple, parameterless, read-only tool, the description covers purpose, usage scenarios, returned fields, and authentication. Minor gaps: it doesn't explicitly state that the result is an array of objects or describe error handling, but these are not critical given the 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?
The tool has zero parameters, so the input schema provides complete coverage (100%). Per the guidelines, 0 parameters earns a baseline of 4. The description does not need to add parameter semantics, and it does not introduce any irrelevant information.
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 clearly states the tool lists eSIMs on the signed-in account, specifying the exact fields returned (ICCID, status, data package, expiry, install link). It also distinguishes from siblings like topup_esim and list_esim_topups by focusing on existing SIMs rather than topups or orders.
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 gives concrete use cases ('my eSIM', 'my SIM card', 'how much data do I have left') and advises using it before topping up a SIM. It also mentions the OAuth requirement, providing clear context for when to invoke. However, it does not explicitly state when not to use it or compare to alternatives.
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.