SimFuse eSIM Storefront

List top-up options

list-topup-options

Read-onlyIdempotent

Data top-ups that can be added to an eSIM the buyer already has, narrowed to what its network will actually accept. Identified by the order id and the email that bought it, plus the ICCID. Read-only: a top-up is bought in the SimFuse app, not through this server, and the response carries the link that opens this eSIM there. Do not pass these package ids to create-checkout-session, which would buy a separate new eSIM rather than add data to this one.

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>",
      "email": "<email>",
      "iccid": "<iccid>"
    },
    "name": "list-topup-options"
  }
}

Input Schema

Name	Required	Description
`email`	Yes	The email address the order was bought with.
`iccid`	Yes	The ICCID of the eSIM to top up, as returned by get-order-status.
`currency`	No	Three-letter currency code for the prices (e.g. "USD", "EUR"). Defaults to EUR.
`order_id`	Yes	The order id from the buyer's confirmation email or order page.

Output Schema

Name	Required	Description
`iccid`	Yes	The eSIM these options apply to.
`options`	Yes	Top-ups the eSIM's own network will accept against this profile. EMPTY means it cannot be topped up at all, and more data means a new eSIM.
`currency`	Yes	ISO 4217 code every price below is quoted in, e.g. "EUR".
`purchase`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds valuable context beyond annotations: it discloses that a top-up is purchased outside this server (in the SimFuse app) and that the response carries a link to open the eSIM there. This clarifies the operational boundary and expected response content. It does not detail rate limits or error behavior, keeping it at a strong 4.

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

Conciseness5/5

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

Four sentences, front-loaded with purpose and scope, then identity, then the read-only boundary, then the sibling warning. No filler or repetition. Every sentence contributes a distinct, actionable fact.

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?

Given the tool's moderate complexity (4 params, output schema present), the description covers the essential gaps: what the tool returns conceptually (network-filtered top-up options plus an app link), the read-only boundary, and a critical sibling misrouting hazard. An output schema exists, so return structure need not be explained. Nothing an agent needs to call correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters (email, iccid, currency, order_id) with examples and sourcing hints. The description mentions the identity trio (order_id, email, ICCID) but adds no syntax, format, or validation details beyond what the schema provides. Baseline 3 is appropriate.

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?

Specific verb (list) and resource (top-up options) with scope: 'Data top-ups that can be added to an eSIM the buyer already has, narrowed to what its network will actually accept.' This is clearly distinct from list-plans or create-checkout-session, and the network-filtering detail prevents confusion with generic plan listing.

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?

Explicitly states when to use this tool (add data to an existing eSIM identified by order_id, email, ICCID) and includes a critical when-not: 'Do not pass these package ids to create-checkout-session, which would buy a separate new eSIM rather than add data to this one.' This directly routes the agent away from a sibling that would produce the wrong outcome.

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

All SimFuse eSIM Storefront 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.

Resources

Need Help?