Xpress Flow Systems

create_esim_order

Start an eSIM purchase for a person. Phone-number plans need name, accept_aup: true and a real (not temporary) email, and are limited to 3 numbers per person. Any number past 3 needs customer_phone and id_document and waits for an ID check (status pending_payment with no payment_url yet, nothing charged) before payment_url is given. This does not charge anyone: it returns payment_url (card, bank transfer or crypto) for the person to pay, in US dollars outside Nigeria and in naira in Nigeria. After a verified payment the eSIM is delivered by email. Poll get_order_status with reference and status_token. The buyer can ask for a full refund before delivery. Use plan_code and location from search_esim_plans, or phone_plan_code from search_phone_plans.

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": {
      "email": "<email>",
      "accept_terms": "<accept_terms>"
    },
    "name": "create_esim_order"
  }
}

Input Schema

Name	Required	Description
`name`	No	With phone_plan_code: the person's full name (first and last).
`email`	Yes	Required: the person's email, for their receipt and order details (the eSIM).
`country`	No	Optional: the payer's two-letter country. Outside Nigeria (NG) they pay in US dollars. Defaults to where the request comes from.
`currency`	No	Optional: USD or NGN. By default prices are in US dollars outside Nigeria and in naira inside Nigeria, from where the request comes from.
`location`	No	Destination code from search_esim_plans, for example US. Not needed with phone_plan_code.
`plan_code`	No	plan_code from search_esim_plans.
`accept_aup`	No	Required true with phone_plan_code: your user agreed to the Acceptable Use Policy (/acceptable-use): no spam, scams, impersonation, bulk SMS or robocalls; a violation cancels the number with no refund.
`id_document`	No	Only when asked (VERIFICATION_REQUIRED): data URL (data:image/jpeg;base64,... or application/pdf) of a passport, driving licence or national ID, under 3 MB. Kept private.
`accept_terms`	Yes	Set true only if your user agreed to the Terms of Use and Privacy Policy on this website.
`customer_phone`	No	Only when asked (VERIFICATION_REQUIRED): the person's own phone number.
`phone_plan_code`	No	plan_code from search_phone_plans, for an eSIM with a phone number.
`email_verification_token`	No	verification_token from verify_email_code for this email (required while email checks are on).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 24, 2026

addedInput schema / properties / customer_phone

Added value: +{
+  "description": "Only when asked (VERIFICATION_REQUIRED): the person's own phone number.",
+  "type": "string"
+}

addedInput schema / properties / id_document

Added value: +{
+  "description": "Only when asked (VERIFICATION_REQUIRED): data URL (data:image/jpeg;base64,... or application/pdf) of a passport, driving licence or national ID, under 3 MB. Kept private.",
+  "type": "string"
+}

Changed2 schema fields changedOct 23, 2026

addedInput schema / properties / accept_aup

Added value: +{
+  "description": "Required true with phone_plan_code: your user agreed to the Acceptable Use Policy (/acceptable-use): no spam, scams, impersonation, bulk SMS or robocalls; a violation cancels the number with no refund.",
+  "type": "boolean"
+}

addedInput schema / properties / name

Added value: +{
+  "description": "With phone_plan_code: the person's full name (first and last).",
+  "type": "string"
+}

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / email_verification_token

Added value: +{
+  "description": "verification_token from verify_email_code for this email (required while email checks are on).",
+  "type": "string"
+}

Changed2 schema fields changedOct 22, 2026

changedInput schema / properties / email / description

Previous value: -"Optional: the person's email, for the receipt and the eSIM."New value: +"Required: the person's email, for their receipt and order details (the eSIM)."

changedInput schema / required

Previous value: -[
-  "accept_terms"
-]New value: +[
+  "email",
+  "accept_terms"
+]

First observedOct 22, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations only say the call is not read-only, not destructive, not idempotent, and open-world; the description adds far more: nothing is charged now, it returns a payment_url (card, bank transfer, crypto), currency is USD outside Nigeria and NGN inside, the eSIM is emailed after verified payment, and full refunds are available before delivery. It also discloses the pending_payment state with no payment_url during ID checks. It stops short of describing response fields (reference/status_token shape) or what a failed/duplicate call returns.

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?

Front-loaded with purpose then conditions, payment, delivery, and follow-up in a logical sequence; nearly every sentence carries unique information. The prose is dense and occasionally run-on (the ID-check sentence packs state, charge status, and payment_url into one clause), and the currency rule is restated in a way that overlaps the schema.

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?

For a 12-parameter, non-idempotent creation tool with no output schema, the description supplies the full lifecycle: inputs by plan type, the ID-verification branch, that no money moves at creation, what is returned (payment_url), currency behavior, delivery, refunds, and the exact next call. Nothing an agent needs to invoke this correctly 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 conditional logic the schema does not express: name/accept_aup/real-email are required specifically with phone_plan_code, customer_phone and id_document only appear past the third number, and plan_code/location are irrelevant for phone plans. That is meaningful cross-parameter semantics beyond the field-level text.

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+resource ("Start an eSIM purchase") and immediately splits the two supported paths, phone-number plans versus data plans, naming the sibling search tools that supply each code. An agent can distinguish this from create_cart_order, create_proxy_order, and create_domain_order 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?

Explicitly routes the agent: use plan_code and location from search_esim_plans, or phone_plan_code from search_phone_plans, then poll get_order_status with reference and status_token. It also states the preconditions for the phone-number path (name, accept_aup: true, real email, 3-number cap) and what happens past the cap, so the agent knows when the call will succeed versus land in ID check.

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

All Xpress Flow Systems 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?