Read-only travel eSIM plan lookup (USD prices) that links buyers to shibaSIM checkout.
Scored across 3 tools
The three tools map to a clean browse → search → detail funnel: list_destinations enumerates where plans exist, search_plans filters plans for one destination, and get_plan expands a single plan id from search results. No two tools could plausibly be chosen for the same request.
All three follow a strict verb_noun snake_case pattern (list_destinations, search_plans, get_plan) using standard read-verb vocabulary. Fully predictable and readable.
Three tools is on the thin side but justified for a read-only affiliate catalog where purchase happens via an external checkout_url. Each tool earns its place in the discovery funnel with no filler.
The surface covers the full read path: destination discovery, filtered plan search, and per-plan detail including coverage, speed caps, and pricing. Gaps are minor — no cross-destination or multi-plan comparison, and no plan listing without first picking a destination, but agents can work around these.
Full details of one plan by id (from search_plans): data, validity, daily cap and reduced speed, covered countries, hotspot, top-up availability, verified network facts, USD price and checkout_url.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Plan id returned by search_plans. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuine value by disclosing the response payload contents — including USD price and checkout_url — which is important behavior an agent cannot infer from annotations.
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?
A single sentence, front-loaded with the verb and resource, with the payload list following. Every item roughly earns its place given no output schema, though 'verified network facts' is vague enough to be near-filler.
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?
With one parameter, full schema coverage, rich annotations, and no output schema, the description covers purpose, id provenance, and returned fields — enough to call it correctly. Only minor gaps remain, such as error behavior for an unknown id.
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 the id property already says 'Plan id returned by search_plans', so the description's '(from search_plans)' merely restates it. No added syntax, format, or edge-case meaning beyond the schema.
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+resource+scope: 'Full details of one plan by id'. It also names the sibling (search_plans) as the source of the id, so the agent can distinguish this point-lookup from the sibling search tool without opening either schema.
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 parenthetical '(from search_plans)' makes the intended workflow clear: search first, then fetch details. It does not spell out when not to use this tool (e.g. when list-level data suffices), so it falls short of full explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List destinations (countries and multi-country regions) with eSIM plans on shibaSIM: code, name, ISO country codes covered, plan count and cheapest USD price.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional name/ISO filter, e.g. 'japan' or 'JP'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the output shape: code, name, ISO codes covered, plan count, and cheapest USD price. Since no output schema exists, this return-value disclosure is genuinely useful and goes beyond structured fields, though pagination or result-size behavior remains unstated.
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?
One front-loaded sentence with zero filler, and the field enumeration is information-dense rather than redundant. It reads slightly as a run-on, but every clause carries meaning.
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 one-optional-parameter read tool with no output schema, listing the returned fields is exactly the compensating context an agent needs. Only minor gaps remain: no guidance on how the filter behaves or whether the full catalog is always returned.
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% and the single `query` parameter is fully documented in the schema with examples ('japan', 'JP'). The description adds no matching semantics (substring vs exact ISO, case sensitivity), so this is the baseline case where the schema does all the work.
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?
Uses a specific verb ("List") on a precisely scoped resource ("destinations (countries and multi-country regions) with eSIM plans on shibaSIM") and enumerates the returned fields, which implicitly separates it from the plan-level siblings get_plan and search_plans. It stops short of naming those siblings, so the differentiation is inferred rather than stated.
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 only implied: the agent can infer this is the catalog/discovery call that precedes search_plans or get_plan, but the description never says so, nor does it state any when-not-to-use condition. No mention of the optional query parameter as a narrowing mechanism either.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search shibaSIM travel eSIM plans for one destination with factual filters. Prices are USD. Each result has a checkout_url that sends the buyer to shibaSIM. Per-day plans are filtered on GB/day, fixed plans on total GB.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | cheapest = lowest price; value = lowest USD per GB. | |
| limit | No | Default 10. | |
| five_g | No | true = only plans where 5G is verified on shibaSIM. | |
| hotspot | No | true = only plans that allow hotspot/tethering. | |
| data_type | No | Only daily-allowance plans or only fixed total-data plans. | |
| destination | Yes | Destination name, ISO country code or destination code from list_destinations, e.g. 'Japan' or 'JP'. | |
| min_data_gb | No | Minimum GB (GB per day for per-day plans, total GB for fixed plans). | |
| max_price_usd | No | ||
| min_validity_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, non-destructive safety profile, so the description focuses on added context: prices are in USD, results carry a checkout_url that sends the buyer to shibaSIM, and how the data filter behaves for per-day versus fixed plans. That is genuine behavioral value beyond the structured fields.
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?
Four short sentences, front-loaded with purpose and followed by the facts an agent needs (currency, checkout_url, filter semantics). 'With factual filters' is the only slightly soft phrase, but there is no 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 9-parameter search tool with no output schema, the description supplies the essentials: result currency, the presence of checkout_url in each result, and the data-filter interpretation. The gap is that two parameters (max_price_usd, min_validity_days) remain unexplained anywhere.
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 78%, so the baseline is 3; the description earns an extra point by clarifying that prices are USD (not stated for max_price_usd) and by restating that min_data_gb interprets as GB/day for per-day plans and total GB otherwise. It still says nothing about min_validity_days, which is undocumented in both places.
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 and resource ('Search shibaSIM travel eSIM plans') plus a scoping constraint ('for one destination'). It does not explicitly name get_plan or list_destinations to differentiate itself, so it lands just short of a 5.
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 single-destination scope implies this is the browsing/filtering entry point versus a detail lookup, but the description never says when to prefer it over get_plan or when to call list_destinations first. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_planlist_destinationssearch_plansSearch travel eSIM plans, compare current USD prices, and get checkout links. No API key required.
Search & buy travel data eSIMs for 70+ destinations — pay by Stripe link, get the eSIM QR. USD.
Find public eSIM plans by destination, trip length, data needs, currency, and locale.
Travel eSIM catalog: search plans, check availability, and get exact quotes with checkout links.
Add one secure layer between your agents and this server.
