Quartermaster eSIM

Troubleshoot an eSIM

troubleshoot

Read-only

Get step-by-step fixes to relay to the traveler when an eSIM will not install or has no data. Use it when a delivered order's traveler reports a problem, before regenerate_activation or request_refund. Example: {order_id: "ord_...", device: {os: "ios", model: "iPhone 15"}, symptom: "no_data"}. Returns ordered steps for an order's eSIM that does not install (cant_install_qr) or does not work (no_data, no_signal, slow), worded for the phone (device.os ios or android, device.model if known): eSIM compatibility and carrier lock, install by QR or manual entry (SM-DP+ address and activation code), data roaming on the eSIM line, the eSIM as the data line, the APN when the plan has one, airplane-mode toggle and restart, then the escalation (regenerate_activation, request_refund with reason not_working and the evidence to include, or order_status for a code not delivered yet). Also returns the order's status and the plan's APN, networks and network types (plan_facts); activation and usage only as the supplier reports them. Read-only: it reissues nothing and opens no dispute. Any agent of the order's principal may call it; other principals get ORDER_NOT_FOUND. A refunded or failed order gets no steps.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "order_id": "<order_id>",
      "device": "<device>",
      "symptom": "<symptom>"
    },
    "name": "troubleshoot"
  }
}

Input Schema

Name	Required	Description
`device`	Yes	The traveler's phone: os (ios or android) and, if known, model
`symptom`	Yes	What the traveler sees: cant_install_qr (the eSIM will not install), no_data (installed but no internet), no_signal (no network) or slow
`agent_id`	No	Your agent id (or X-Agent-Id header)
`order_id`	Yes	Order id from purchase (order.order_id) or from an earlier order_status call
`agent_key`	No	Secret returned by register_agent (or X-Agent-Key header)
`principal_id`	No	The principal you act for (or X-Principal-Id header)

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 9, 2026

addedInput schema / properties / device / description

Added value: +"The traveler's phone: os (ios or android) and, if known, model"

addedInput schema / properties / device / properties / os / description

Added value: +"The traveler's phone operating system: ios or android"

addedInput schema / properties / order_id / description

Added value: +"Order id from purchase (order.order_id) or from an earlier order_status call"

changedInput schema / properties / symptom / description

Previous value: -"no_data, cant_install_qr, no_signal or slow"New value: +"What the traveler sees: cant_install_qr (the eSIM will not install), no_data (installed but no internet), no_signal (no network) or slow"

AddedNov 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond readOnlyHint=true, it discloses that nothing is reissued and no dispute is opened, the authorization model (any agent of the order's principal may call it; other principals get ORDER_NOT_FOUND), and the failure case for refunded/failed orders. It also notes a data-provenance caveat: activation and usage are reported only as the supplier reports them.

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, usage, and exclusions are front-loaded, and every section carries information. The middle enumeration of returned steps is dense and run-on, reading as one long block rather than structured clauses, which slightly hurts scanability.

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?

There is no output schema, so the description carries the full burden of describing return values, and it does: ordered steps keyed by symptom and device, order status, and plan_facts (APN, networks, network types). Nothing an agent needs to call this correctly or interpret the response is missing.

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 100%, so the baseline is 3, but the description adds meaning beyond the schema by showing a full example payload and explaining how device.os/model and symptom shape the returned steps (wording tailored to the phone, symptom-specific branches). It does not explain the auth parameters (agent_id, agent_key, principal_id) beyond what the schema already says.

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?

The opening states a specific verb and resource: 'Get step-by-step fixes to relay to the traveler when an eSIM will not install or has no data.' It explicitly separates itself from sibling tools (regenerate_activation, request_refund, order_status), so an agent can distinguish it without opening any schema.

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?

It gives a precise trigger ('when a delivered order's traveler reports a problem') and an explicit ordering constraint ('before regenerate_activation or request_refund'), then maps escalation paths by situation. It also states an exclusion: a refunded or failed order gets no steps.

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.