Quartermaster eSIM

Search eSIM plans

search_plans

Read-only

Find eSIM data plans for a destination, with final prices in minor units. Use it first, when a traveler needs mobile data abroad: filter by country (ISO code), region, minimum data, validity and price, then compare. Returns results (each with id, title, countries, regions, data_gb or "unlimited", validity_days, price_final {amount_minor, currency, tax_included}, availability, delivery, refund_rule and constraints such as hotspot, network types and operators), total_matches, sort and excluded_suppliers. Defaults: in-stock plans only, cheapest first, 10 results. Read-only and free; pass a result's id to get_quote. Suppliers below the trust threshold are excluded and listed in excluded_suppliers. Example: {country: "JP", min_data_gb: 5, max_validity_days: 30, sort: "price"}.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_plans"
  }
}

Input Schema

Name	Required	Description
`sort`	No	price (default, cheapest first), price_per_gb (best value per GB) or validity (longest first)
`limit`	No	How many plans to return, 1-50 (default 10)
`region`	No	Coverage region (EUROPE, ASIA, MIDDLE_EAST, NORTH_AMERICA, LATIN_AMERICA, OCEANIA, AFRICA or GLOBAL); use country for one destination
`country`	No	Destination country as an ISO 3166-1 alpha-2 code, for example JP, US, GB or TH
`agent_id`	No	Your agent id (or X-Agent-Id header)
`category`	No	Product category; only esim is sold
`agent_key`	No	Secret returned by register_agent (or X-Agent-Key header)
`min_data_gb`	No	Minimum data in GB; unlimited plans always qualify
`principal_id`	No	The principal you act for (or X-Principal-Id header)
`unlimited_only`	No	true: only unlimited-data plans
`max_price_minor`	No	Highest acceptable final price in minor units (1500 = 15.00 USD)
`max_validity_days`	No	Longest acceptable validity in days, for example 30
`min_validity_days`	No	Shortest acceptable validity in days, for example 7
`include_out_of_stock`	No	true: also list plans that are out of stock (default false)

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedNov 9, 2026

changedInput schema / properties / category / description

Previous value: -"Product category"New value: +"Product category; only esim is sold"

changedInput schema / properties / country / description

Previous value: -"Destination country, e.g. JP"New value: +"Destination country as an ISO 3166-1 alpha-2 code, for example JP, US, GB or TH"

addedInput schema / properties / include_out_of_stock / description

Added value: +"true: also list plans that are out of stock (default false)"

addedInput schema / properties / limit / description

Added value: +"How many plans to return, 1-50 (default 10)"

addedInput schema / properties / max_price_minor / description

Added value: +"Highest acceptable final price in minor units (1500 = 15.00 USD)"

addedInput schema / properties / max_validity_days / description

Added value: +"Longest acceptable validity in days, for example 30"

addedInput schema / properties / min_validity_days / description

Added value: +"Shortest acceptable validity in days, for example 7"

changedInput schema / properties / region / description

Previous value: -"Commercial coverage region"New value: +"Coverage region (EUROPE, ASIA, MIDDLE_EAST, NORTH_AMERICA, LATIN_AMERICA, OCEANIA, AFRICA or GLOBAL); use country for one destination"

addedInput schema / properties / sort / description

Added value: +"price (default, cheapest first), price_per_gb (best value per GB) or validity (longest first)"

addedInput schema / properties / unlimited_only / description
```
Added value: +"true: only unlimited-data plans"
```

Changed3 schema fields changedNov 4, 2026
- addedInput schema / properties / agent_id / pattern
```
Added value: +"^[A-Za-z0-9._:-]{3,128}$"
```
- addedInput schema / properties / agent_key / maxLength
```
Added value: +256
```
- addedInput schema / properties / principal_id / pattern
```
Added value: +"^[A-Za-z0-9._:@-]{3,128}$"
```
First observedNov 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations only declare readOnlyHint, so the description carries most of the behavioral load and does so well: it discloses defaults (in-stock only, cheapest first, 10 results), states the call is free, and explains that suppliers below a trust threshold are filtered out and reported in excluded_suppliers. It stops short of covering rate limits or failure modes, which keeps it off a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause and the follow-on sentences are sequenced sensibly: filters, then return shape, then defaults, then the get_quote handoff and example. The long parenthetical enumeration of returned fields is dense but earns its place because no output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 14 parameters, no output schema and minimal annotations, this description does the work those fields cannot: it enumerates the returned fields (id, price_final, availability, refund_rule, constraints), the envelope fields total_matches/sort/excluded_suppliers, and the default behavior. An agent can select and call this tool correctly without opening any other document.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3; the description earns above that by restating the operative defaults for sort and limit and by giving a concrete call example that shows how filters compose. It adds little on auth or pagination semantics, so it is not a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource ('Find eSIM data plans for a destination') and immediately scopes the capability ('with final prices in minor units'). It also explicitly contrasts itself with the sibling get_quote by naming it as the next step once an id is known.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Says to use it first when a traveler needs mobile data abroad, then spells out the filter dimensions and the handoff ('pass a result's id to get_quote'). That is an explicit when-to-use plus a named alternative, leaving nothing to inference.

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

All Quartermaster eSIM tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.