Buy and manage travel eSIM data plans in the conversation. Pay by card (Stripe) or USDC over x402.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | order_id of the order to cancel |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Start a purchase — the step after the user picks a plan from search_esim_plans.
Call it with that plan's plan_id (get_plan_details shows the current price first). Returns an order_id and where to pay, on the rail you asked for: 'card' (the default) returns a checkout_url — a hosted Stripe page for a human to open in a browser; once they say they've paid, call get_order_status to confirm and carry on to the QR code. 'x402' returns an x402_url for a wallet to settle in USDC, with no browser step — only choose it if you actually hold a wallet.
Never accepts payment details — a card is entered on the hosted page, and a wallet signs for itself. Calling it again for the same plan reuses the pending order (reused: true) instead of creating a duplicate.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | Yes | plan_id from search_esim_plans | |
| pay_with | No | How the buyer intends to pay. 'card' returns a hosted checkout link for a human to open in a browser. 'x402' returns an x402_url for a wallet tool to settle in USDC, with no browser step — only choose it if you have a wallet. An order keeps the rail it was first given: to pay an existing card order in USDC instead, cancel it and start a new one, so there are never two live ways to pay it. | card |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: 'Never accepts payment details,' the reuse behavior ('Calling it again for the same plan reuses the pending order (reused: true) instead of creating a duplicate'), and the distinction between card (hosted page) and x402 (wallet). It also clarifies output structure (order_id, checkout_url/x402_url) without contradicting 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?
The description is well-structured and front-loaded with the core purpose. Each sentence adds value: the invocation context, parameter guidance, return values, rail-specific behavior, and edge-case reuse. It is appropriately sized for the tool's complexity, with no filler or redundancy.
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?
Given the tool's complexity (2 params, enum, output schema), the description is complete: it covers the full purchase flow (before and after this step), alternatives (cancel_order, get_order_status), constraints (no payment details), and edge cases (reuse, rail switching). The output schema is present, so the description need not enumerate return fields, but it does explain their meaning and next steps.
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?
While schema coverage is 100%, the description adds significant meaning: plan_id is sourced from search_esim_plans, pay_with has an elaborated default ('card') and a clear condition for x402 ('only choose it if you actually hold a wallet'). It also explains the implication of choosing a rail (browser vs. no browser), which is not explicit in the schema alone.
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?
The description clearly states the tool's function: 'Start a purchase — the step after the user picks a plan from search_esim_plans.' It specifies the primary action (create checkout) and the scope (for a selected plan), distinguishing it from siblings like cancel_order or get_order_status by placing it within the purchase flow.
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?
Explicit when-to-use guidance is provided: 'the step after the user picks a plan... get_plan_details shows the current price first' and 'once they say they've paid, call get_order_status.' It also gives conditional advice for the x402 rail ('only choose it if you actually hold a wallet') and how to handle rail switching ('cancel it and start a new one'), naming the alternative cancel_order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy more data for an eSIM the user already has — the step after list_topup_options.
Call it with the order_id of the fulfilled eSIM and a plan_id chosen from list_topup_options. The top-up lands on the existing eSIM: same QR code, nothing to re-install. Returns a new order_id and where to pay, exactly like create_checkout: 'card' returns a checkout_url for a human to open, confirmed via get_order_status; 'x402' returns an x402_url for a wallet to settle in USDC.
Never accepts payment details — a card is entered on the hosted page, and a wallet signs for itself.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | Yes | plan_id from list_topup_options | |
| order_id | Yes | order_id of the eSIM to add data to | |
| pay_with | No | How the buyer intends to pay. 'card' returns a hosted checkout link for a human to open in a browser. 'x402' returns an x402_url for a wallet tool to settle in USDC, with no browser step — only choose it if you have a wallet. An order keeps the rail it was first given: to pay an existing card order in USDC instead, cancel it and start a new one, so there are never two live ways to pay it. | card |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it creates a new order (since it returns a new order_id), explains the payment flow (hosted checkout or x402), and that it does not accept payment details. This adds transparency beyond the 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?
The description is well-structured, leading with the purpose and then detailing usage and return behavior. It is somewhat verbose but remains focused and concise.
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?
The description covers the purpose, usage, return information, and payment options, providing sufficient context for the agent to use the tool effectively.
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?
The input schema already provides detailed descriptions for all parameters, and the description largely restates this information without adding significant new meaning.
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?
The description clearly states the tool's function: buying data for an existing eSIM, positioning it as the step after list_topup_options. It distinguishes itself from create_checkout by focusing on top-ups for existing eSIMs.
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?
It explicitly instructs to call with the order_id and plan_id, and explains the return type and how to confirm via get_order_status. It also notes that payment details are never accepted, clarifying when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the QR code and activation details for a purchased eSIM.
Not read-only: like get_order_status, an order that is not ready yet is advanced first, so this can change the order's state.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | order_id of a fulfilled order |
| Name | Required | Description |
|---|---|---|
| iccid | Yes | The eSIM's ICCID |
| order_id | Yes | The order this eSIM belongs to |
| expires_at | Yes | When the plan expires, in the provider's own format |
| qr_code_url | Yes | Image URL of the activation QR code |
| instructions | Yes | How to install the eSIM |
| smdp_address | Yes | SM-DP+ server address, for manual install |
| activation_code | Yes | LPA activation string, for manual install |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining that the operation is not read-only and can change the order's state by advancing it if not ready. This is a non-obvious behavioral trait not captured by readOnlyHint=false, adding real value.
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?
The description is two short sentences with no filler. The main purpose is front-loaded, and the critical caveat about side effects is placed clearly without excess wording.
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 single-parameter tool with an output schema and complete annotations, the description fully covers what the agent needs: what it does, the side-effect warning, and the input type. No critical information is missing.
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% for the single order_id parameter, which already states 'order_id of a fulfilled order'. The description adds no additional semantic detail beyond the schema's text, so it stays at the baseline.
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?
The description clearly states it retrieves 'the QR code and activation details for a purchased eSIM'. This is a specific verb+resource combination that distinguishes it from sibling tools like get_esim_usage and get_order_status.
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?
It provides explicit context: states the tool is not read-only and can advance an order's state, comparing it to get_order_status. This informs when to use it and warns about side effects, though it doesn't explicitly list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How much data an active eSIM has used, and how much is left.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | order_id of a fulfilled order |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, providing a safe read profile. The description adds useful behavioral context: it specifically notes 'active eSIM', implying it will not work for inactive eSIMs, and clarifies that it returns both used and remaining data. This goes beyond the structured annotations and adds meaningful constraint information.
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?
The description is a single concise sentence: 'How much data an active eSIM has used, and how much is left.' It is front-loaded with the core query, contains zero filler, and every word contributes to the meaning. This is an exemplary level of conciseness.
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?
Given the tool's simplicity (one parameter, read-only, with output schema), the description is adequate. It clearly states what the tool returns (used and remaining data) and the condition ('active eSIM'). No additional information like error handling or return format is strictly necessary, as the output schema exists. A minor gap is the lack of mention of what happens if the eSIM is not active, but this is a small omission for an otherwise complete description.
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?
The input schema already provides full coverage (100%) for the single required parameter, order_id, with the description 'order_id of a fulfilled order'. The tool description adds no additional meaning about the parameter, so it does not improve upon the schema's documentation. This aligns with the baseline score for high schema coverage.
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?
The description clearly explains the tool's purpose: showing how much data an active eSIM has used and how much remains. It distinguishes this from sibling tools like get_order_status and get_plan_details by focusing specifically on data usage. While it lacks an explicit verb, the title 'Check data usage' and the description together convey the action clearly.
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 description implies this tool should be used to query data usage for an active eSIM, but it does not explicitly state when to use it over alternatives. No exclusions or alternative tool names are mentioned, leaving the agent to infer the appropriate context from the description and sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an order. Call this after the user says they've paid.
Not read-only: an order still in progress is advanced first — payment is confirmed and the provider order placed or collected — so the status can change as a result of calling this.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | order_id from create_checkout |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a critical non-obvious behavior: the tool is not read-only, and it advances the order by confirming payment and placing/collecting the provider order. This adds significant context beyond the readOnlyHint=false annotation and clarifies the side effects. It is consistent with all 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?
The description is two concise sentences, front-loaded with the purpose and immediately followed by usage timing and the critical behavioral warning. Every sentence adds value with no filler or redundancy.
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?
The tool is simple with one parameter, has an output schema, and annotations cover safety traits. The description supplies the key missing context about the state-changing effect, making it complete for invocation. No critical information is absent.
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?
The input schema has one parameter with a clear description ('order_id from create_checkout'), giving 100% schema coverage. The tool description does not add any parameter-specific information beyond what the schema already provides, so the baseline score of 3 is justified.
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?
The description clearly states the tool checks an order and gives the specific context of payment confirmation. This distinguishes it from list_my_orders, but it does not explicitly name sibling alternatives, so it falls short of the highest score.
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?
Explicitly instructs to call the tool after the user says they've paid, which is a clear usage trigger. It also warns about the state-changing nature. However, it does not mention when not to use it or reference alternative tools, so a score of 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full details of one eSIM plan, including current price.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | Yes | plan_id from search_esim_plans |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the context that it returns 'current price', but it does not disclose other behavioral aspects like response size, error conditions, or freshness guarantees. With annotations present, this meets the minimum viable bar.
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?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the key action ('Full details') and the object ('one eSIM plan'), making it immediately scannable.
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?
This is a simple, read-only get-details tool with one well-documented parameter, an output schema to describe return values, and annotations declaring its non-destructive nature. The description, combined with structured data, provides enough context for an AI agent to select and invoke this tool correctly.
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?
The schema provides 100% coverage for the single parameter, identifying plan_id and instructing that it comes from search_esim_plans. The description's phrase 'one eSIM plan' loosely reinforces the singular nature of the parameter, but adds no substantive meaning beyond what the schema already gives. Baseline 3 is appropriate.
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?
The description 'Full details of one eSIM plan, including current price' clearly identifies the action (retrieve full details), the resource (eSIM plan), and the scope (one plan). It is specific enough to distinguish from sibling tools like search_esim_plans, which lists plans rather than returning details for a single one.
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 description implies the tool is for fetching details of a specific plan, and the schema's plan_id description ('plan_id from search_esim_plans') provides a useful prerequisite by indicating where to obtain the identifier. However, it does not explicitly state when not to use this tool or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List this account's eSIM orders, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true and destructiveHint false, so the safety profile is known. The description adds valuable behavior beyond annotations by specifying the ordering ('newest first') and the account scoping, which helps the agent understand what to expect.
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?
The description is a single, clear sentence that front-loads the main action and resource, with no filler or redundant information. It earns its place entirely.
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 simple, read-only list tool with no parameters and an output schema present, the description fully covers what the tool does. It includes scope and ordering, which is complete for the tool's complexity.
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?
There are zero parameters, so the schema trivially covers everything. The description adds no parameter detail because none is needed. The baseline of 4 for zero-parameter tools applies here.
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?
The description clearly states the verb 'List', the resource ('eSIM orders'), and the scope ('this account's'), plus the ordering ('newest first'). It effectively distinguishes from siblings like get_order_status (which implies a single order) and list_topup_options (which lists topup options).
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 description gives context that this lists all orders for the account, but it does not explicitly state when to use this versus alternatives like get_order_status. No exclusions or alternative tool mentions are provided, leaving the usage to be implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Data top-ups that can be added to an eSIM the user already has.
A top-up extends the existing eSIM — same QR code, nothing to re-install. Not every plan is reloadable; this returns an empty list when none apply.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | order_id of a fulfilled eSIM to add data to |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by explaining top-up semantics (extends existing eSIM, same QR code, no re-install) and the edge case that not all plans are reloadable, resulting in an empty list. This goes beyond the safety 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?
The description is two concise sentences, front-loaded with the core purpose and followed by valuable behavioral context. No redundant information or fluff.
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 single-parameter listing tool with an output schema and safety annotations, the description covers the core concept, the meaning of a top-up, and the empty-result edge case. It does not mention error handling for invalid order_id, but that is not critical given the schema and annotations.
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 parameter description already specifies 'order_id of a fulfilled eSIM'. The description adds no new syntax or format details 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (list) and resource (data top-ups for an existing eSIM), distinguishing it from sibling tools like create_topup_checkout by focusing on available options. It also clarifies scope by stating top-ups extend the existing eSIM and that the list may be empty.
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?
Clear usage context: use when you need to see top-up options for an already-owned eSIM. It implicitly differentiates from create_topup_checkout (which likely creates the purchase) but does not explicitly state when to prefer this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pay for an order in USDC over x402, without opening a browser.
Only for an MCP client that signs x402 payments itself: call it once for the payment requirements, then repeat the call carrying the signed payment in _meta['x402/payment'] and it settles and starts the eSIM. If your wallet is a separate tool, make an x402 request to the order's x402_url instead — this tool cannot take a payment on a wallet tool's behalf.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | order_id from create_checkout |
| Name | Required | Description |
|---|---|---|
| error | No | How to pay, for the 402 case |
| result | No | |
| status | No | |
| accepts | No | x402 payment requirements to satisfy |
| order_id | No | |
| next_step | No | |
| paid_with | No | |
| transaction | No | On-chain transaction hash |
| x402Version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, but the description adds important behavioral context: it requires a two-step process, uses _meta for the payment, and settles and starts the eSIM after payment. It also notes a critical limitation with wallet tools. No contradiction with 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?
The description is compact and well-structured, with three sentences covering purpose, usage, and a critical caveat. Each sentence adds necessary information without redundancy. Front-loaded with the core purpose.
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?
Given the tool's complexity (two-step payment process, meta usage), the description fully covers the workflow and constraints. It also clarifies the environment where it works, which is critical for the MCP client. The output schema exists, so return values don't need explanation. The description is complete for an agent to invoke correctly.
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?
The only parameter, order_id, is already described in the schema as 'order_id from create_checkout', which is clear. The description doesn't add much beyond that, but since schema coverage is 100%, additional description isn't necessary. The description does reinforce that order_id comes from create_checkout, which is helpful.
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?
The description clearly states the tool's purpose: 'Pay for an order in USDC over x402' and distinguishes it from siblings by noting it's for MCP clients that sign x402 payments themselves. It also differentiates from create_checkout and other order-related tools.
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?
Provides explicit usage guidelines: call once for payment requirements, then repeat with signed payment in _meta. Also tells when NOT to use it (if wallet is a separate tool, use x402_url instead), and mentions a key limitation: cannot take payment on behalf of a wallet tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find travel eSIM data plans available for a destination.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country or region name, or ISO 3166-1 alpha-2 code | |
| min_data_mb | No | Only plans with at least this much data | |
| max_duration_days | No | Only plans lasting at most this many days |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds little beyond the purpose—no mention of result ordering, pagination, or filtering behavior. It simply restates the search scope, which provides some context but not rich behavioral detail.
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?
The description is a single, concise sentence that immediately conveys the tool's purpose. No wasted words, perfect front-loading.
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 an output schema present and full schema documentation for parameters, the description is largely complete for a search tool. However, it could have added a note about what constitutes a 'destination' (e.g., country name or code) or how results are ordered, but the schema already covers the country format. Overall, sufficient but not exhaustive.
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%; all three parameters (country, min_data_mb, max_duration_days) have descriptive text. The tool description does not add extra parameter semantics beyond what the schema already provides, so the baseline 3 is appropriate.
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?
The description clearly states the action (Find), the resource (travel eSIM data plans), and the scope (available for a destination). This distinguishes it from sibling tools like get_plan_details, which focuses on a single plan's details.
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 description implies usage: when you need to find plans for a destination. However, it does not explicitly mention when not to use it or provide alternatives, such as using get_plan_details for a specific plan's details. The context is clear but the guidance is not fully explicit.
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. Dates show when Glama detected each change.
pay_order1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Without a payment: the x402 payment requirements (accepts, error). With one: the settled order (transaction, next_step), or the unchanged order plus `result` when it was no longer awaiting payment.",
+ "properties": {
+ "accepts": {
+ "description": "x402 payment requirements to satisfy",
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "error": {
+ "description": "How to pay, for the 402 case",
+ "type": "string"
+ },
+ "next_step": {
+ "type": "string"
+ },
+ "order_id": {
+ "type": "string"
+ },
+ "paid_with": {
+ "type": "string"
+ },
+ "result": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "transaction": {
+ "description": "On-chain transaction hash",
+ "type": "string"
+ },
+ "x402Version": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+}cancel_ordercreate_checkoutcreate_topup_checkoutget_esim_activationget_esim_usageget_order_statusget_plan_detailslist_my_orderslist_topup_optionspay_ordersearch_esim_plansClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Travel eSIMs for 197 destinations and airtime top-ups in 150+ countries, paid in USDC via x402
Search, recommend & buy travel eSIM data plans for 190+ destinations via AI agents.
Search & buy travel data eSIMs for 70+ destinations — pay by Stripe link, get the eSIM QR. USD.
Search travel eSIM plans for 150+ countries and buy via Stripe link; eSIM QR delivered by email.
Add one secure layer between your agents and this server.
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).
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.
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.
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.
