Skip to main content
Glama

doctorSIM

create_esim_order

Alias of create_order with type=esim (kept for existing connectors). Guest / consumer: call without Authorization as soon as the plan is chosen — preview is optional. Show the buyer only payment_link and order_id when one exists. Never display checkout_hash (machine id for get_order_status). Buyer types email on the doctorsim.com checkout page and receives the eSIM by email after payment — do not promise an in-chat QR for guests. PRO OAuth: preview first, then create — debits prepaid credits and returns order_id, status, credits_used. Pass a unique idempotency_key per create. If the result lacks order_id, call list_orders / get_order_status — never re-create. Confirmation is emailed to the titular account when one is linked. Sandbox keys create a fake eSIM order (sandbox_esim_{id}, no credit debit, no ticket).

Input Schema

NameRequiredDescriptionDefault
langNo
currencyNo
catalog_idYes
price_tokenYes
checkout_modeNoOptional. Omit for the default doctorsim.com hash payment_link. stripe_link returns a Stripe Checkout Session URL when agentic_stripe_link is ON.
idempotency_keyNoRequired for safe retries. 1-128 printable ASCII. Same key + same account returns the original order (no second charge). Use a NEW key for each distinct SKU / denomination.

Output Schema

NameRequiredDescriptionDefault
codeNo
typeNotopup | giftcard | esim
statusNo
paymentNoNested gateway / provider receipt details. Never the sole success signal.
currencyNo
order_idNoShow this to the buyer when present (PRO credit checkout, or after payment).
expires_atNo
environmentNoproduction | sandbox
credits_usedNoDecimal amount, normally a string, e.g. "21.98"
payment_linkNoThe only URL to show the buyer. Guest / consumer pay on doctorsim.com.
show_to_userYesFields the assistant may show the buyer.
checkout_hashNoMachine identifier for get_order_status. Never show or read aloud.
checkout_modeNocredits (PRO credit checkout) | payment_link (guest / consumer pays on doctorsim.com) | stripe_link (opt-in Stripe Checkout Session URL when requested and agentic_stripe_link is ON).
checkout_hash_usageNomachine_only
assistant_instructionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond annotations, it discloses that PRO creates debit prepaid credits, return order_id/status/credits_used, email confirmation behavior, sandbox fake-order behavior, and checkout display constraints. It also explains idempotency safety and discourages promising an in-chat QR for guests.

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?

The description is dense but front-loads the alias and guest/PRO workflow, and most sentences carry operational value. A slightly clearer structural separation between usage, output display, and retry guidance would improve 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?

For a financial order-creation tool, it covers guest vs PRO flows, preview behavior, idempotency, error recovery, sandbox behavior, and customer-facing output constraints. With an output schema available, it does not need to restate return structures.

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

Parameters2/5

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

Schema description coverage is only 33%, and the description does not explain the critical required catalog_id or price_token parameters, nor lang/currency usage. It adds some practical context for idempotency_key, but does not compensate for the undocumented required inputs.

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 states a specific create action for an eSIM order and explains it is an alias of create_order with type=esim. This clearly distinguishes it from sibling preview/order-status tools while acknowledging its legacy connector role.

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 explicit routing: guests can call without Authorization after choosing a plan with optional preview, while PRO OAuth users should preview first then create. It also names fallback siblings list_orders/get_order_status when order_id is missing and warns never to re-create.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources