Search BuyUKeSIM travel/data eSIM plans for a country. Returns plan name, data amount, validity days, USD price, and package code. Pass a 2-letter ISO country code (e.g. GB, US, TR, JP). Omit country to get popular/featured plans.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max plans to return (1-50). Default 20. | |
| country | No | 2-letter ISO country code, e.g. GB, US, TR, JP. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return fields, the optional country behavior, and the 'popular/featured' fallback. It does not mention authentication, error handling, or rate limits, but these are less critical for a read-only search 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 two sentences, front-loaded with the purpose first, then return details, then parameter usage. Every sentence adds value and there is 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 search tool with 2 optional parameters, the description is complete: it explains the purpose, return fields, how to use both modes (with/without country), and what to expect. Given no output schema, explicitly listing the return fields is a significant strength.
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% and already describes both parameters (limit and country). The description mostly repeats the country instructions and adds the 'omit country' behavior, but provides no additional semantics for the 'limit' parameter.
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 searches BuyUKeSIM travel/data eSIM plans for a country, with a specific verb 'Search' and resource 'eSIM plans'. It also lists the return fields (plan name, data amount, validity days, USD price, package code) and distinguishes this from sibling tools like purchase_esim.
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 provides clear usage context by instructing to pass a 2-letter ISO country code and noting that omitting the country returns popular/featured plans. However, it does not explicitly name alternatives or exclusions, relying on the sibling list to imply the search vs. purchase distinction.
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.
Each product area (wallet, eSIM, UK number, VPN) has clearly separated read and action tools, so most tools are easy to tell apart. The only mild ambiguities are generic order-status lookup vs one-time-code polling, and UK-number coverage vs travel-eSIM country coverage, though the descriptions do draw clear lines.
All tool names follow a consistent snake_case verb_noun pattern. Read operations use check/get/list/search while purchase/wallet operations use create/purchase, making the tool surface predictable and easy to navigate.
17 tools is slightly above the ideal 3-15 range, but the breadth is justified by three purchasable products plus wallet management and product research. No tools feel redundant, though the set could be tightened by consolidating some informational lookups.
The core lifecycle is covered: wallet creation/funding/balance, product search/purchase, VPN config retrieval, and order/status checks. Missing pieces include the inability to purchase the described bundle through the API and no way to re-fetch a lost QR or order payload beyond a bare status check, but these are minor for the main workflows.
