eSIM Tabby

Cancel and refund an order

cancel_order

Destructive

Cancel an order and refund it. Only possible while the eSIM is uninstalled.

Once the profile has been installed on a device the provider refuses to take it back, and this returns an error instead — send the user to support.

Card payments refund automatically. A USDC payment has no on-chain refund rail, so the order becomes refund_pending and support returns the money by hand.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`order_id`	Yes	order_id of the order to cancel

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.7/5.0

Behavior5/5

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

The description goes far beyond the annotations. It discloses the refund behavior for card vs. USDC payments, explains the 'refund_pending' state, and warns about the error after installation. This is highly informative and adds context the annotations don't cover.

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?

The description is four sentences but each sentence is essential: purpose, condition, failure behavior, and refund nuance. It is front-loaded with the core action and efficiently structured with no fluff.

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?

The tool has complex behavior (conditional cancellation, refund differences, error paths) and the description covers all key edge cases. The output schema exists, and the description complements it with the procedural context needed to use the tool correctly.

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?

The input schema already fully describes the only parameter `order_id` with 100% coverage. The description doesn't add new meaning beyond what the schema provides, so the baseline score of 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?

The description clearly states the tool's verb ('Cancel') and resource ('an order'), and specifies that it also refunds. This distinguishes it from sibling tools like get_order_status or pay_order, making its purpose obvious.

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 a precondition ('Only possible while the eSIM is uninstalled') and a clear exclusion ('Once the profile has been installed... this returns an error instead — send the user to support'). This tells the agent when to use and when not to use the tool, and even where to redirect the user.

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

All eSIM Tabby tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool serves a distinct purpose: planning, ordering, payment, activation, usage, top-up, and cancellation. No two tools overlap in functionality; even create_checkout and pay_order are distinct (one initiates and returns a payment URL, the other handles x402-only payment).

Naming Consistency5/5

All 11 tools follow a consistent verb_noun snake_case pattern (e.g., cancel_order, get_esim_activation, search_esim_plans). The variety of verbs (create, get, list, search, cancel, pay) is appropriate for the actions represented, and there are no naming inconsistencies.

Tool Count5/5

The server has 11 tools, well within the ideal 3-15 range. Each tool covers a necessary step in the eSIM lifecycle without redundancy, making the toolset appropriately scoped and manageable.

Completeness5/5

The toolset covers the full eSIM workflow: plan discovery (search, get details), purchasing (create_checkout), top-ups (create_topup_checkout, list_topup_options), payment (pay_order), order tracking (get_order_status, list_my_orders), activation (get_esim_activation), usage (get_esim_usage), and cancellation (cancel_order). No critical gaps are apparent.

Resources

Need Help?