AI-powered eSIM recommendation agent for travelers. Provides real-time coverage checks, package search by country, and pricing across 190+ destinations via structured tool calls.
Tools available:
list_countries - full list of supported destinations
check_coverage - network operators by country code
search_packages - filter eSIM plans by country
get_package_details - pricing and data specs
create_checkout - generate payment link for purchase
No auth required for search tools. Ideal
Scored across 7 tools
Each tool targets a distinct aspect of the eSIM purchasing workflow: coverage, device compatibility, country listing, package search, package details, checkout creation, and order status. There is no overlap between tools.
All tools follow a consistent verb_noun pattern using snake_case (check_, create_, get_, list_, search_). The verbs are specific to the action and nouns describe the resource, creating a predictable pattern.
Seven tools is well within the ideal range for a domain-specific server. Each tool covers a step in the journey from discovery to delivery, with no redundant utilities.
The tool set covers the entire eSIM purchase lifecycle: discovery (list_countries, search_packages, get_package_details), compatibility verification (check_device_compatibility), coverage assessment (check_coverage), payment (create_checkout), and order tracking (check_order_status). No obvious gaps exist for the intended use case.
Check network coverage and operators for a country. Pass package_id and customer_country to get a ready-to-use checkout follow-up step.
| Name | Required | Description | Default |
|---|---|---|---|
| package_id | No | Optional: the package the customer is considering, so the response can suggest checkout directly. | |
| country_code | Yes | ISO country code | |
| customer_country | No | Optional: customer's billing ISO country code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so no contradiction. The description adds that the output is a 'ready-to-use checkout follow-up step,' but it does not elaborate on response shape, data freshness, or any external data caveats beyond the annotation hints.
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?
Two short sentences, front-loaded with the core function, then a targeted usage hint. Every clause earns its place and there is no redundant phrasing.
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 read-only, idempotent tool with 3 well-described parameters, the description provides enough context for an agent to invoke it correctly. The main gap is the absence of an output schema and no explanation of the 'checkout follow-up step' format, but annotations compensate for safety-related context.
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%, so the schema already documents all three parameters. The description adds a small amount of purpose-semantics by linking package_id and customer_country to the checkout outcome, but it does not add detail beyond the schema.
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?
Description states a clear verb ('Check') and resource ('network coverage and operators') scoped to a country, which distinguishes it from siblings like check_order_status and check_device_compatibility. The mention of a checkout follow-up further clarifies its role in 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?
The description implies when to use the tool—when coverage/operators for a country are needed and optionally to prepare a checkout—but it does not explicitly contrast it with alternatives or state exclusions. Sibling names like get_package_details and search_packages suggest overlap, yet no routing guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a device supports eSIM. Search by device name, model, or vendor (e.g. 'iPhone 15', 'Samsung Galaxy S24', 'Pixel 8'). Optional - useful to verify before purchase.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Device name, model, or vendor to search (e.g. 'iPhone 15', 'Samsung', 'Pixel') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds search behavior ('Search by device name, model, or vendor') and example values, but it does not disclose the output format or what a negative match looks like. This is acceptable given annotations carry the main behavioral burden.
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?
Two sentences, front-loaded with the core action and scope. The examples earn their place by clarifying acceptable input formats. The phrase 'Optional - useful to verify before purchase' is slightly vague ('Optional' what?) but still concise and adds usage context. No wasted bulk.
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 single-parameter read-only tool, the description covers what the tool does, what input it accepts, and when to use it. Since there is no output schema, a brief note on what the result indicates would improve completeness, but it is not essential for correct invocation. Overall adequate.
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% and the query property is already well-described in the schema. The description adds some extra layering through examples and the phrase 'device name, model, or vendor', but this is mostly redundant with the schema. Baseline 3 applies since the schema does the heavy lifting.
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?
Description uses a specific verb ('check'), clear resource ('device'), and precise scope ('supports eSIM'). It distinguishes itself from siblings like check_coverage or check_order_status by focusing on device capabilities. The examples further disambiguate its domain.
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 phrase 'useful to verify before purchase' gives a concrete when-to-use context. It doesn't explicitly name alternatives or exclusions, but among the sibling tools none overlaps directly, so the guidance is sufficient for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a Stripe checkout session created by create_checkout. You MUST call this after sending payment_url to the user; never trust the user's word that they paid. Returns a status (awaiting_payment | paid_processing | delivered | failed). Safe to poll every few seconds while waiting for paid_processing -> delivered. When status is delivered it also returns an esim block (package, activation code / LPA string, qr_code_image_url, iOS/Android install links, activation mode) plus install_instructions - show these to the customer directly in the chat, the email is only a backup. No payment or billing data is ever returned. If failed, give them the escalation block returned by this tool verbatim.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Stripe checkout session id returned by create_checkout (starts with 'cs_'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent/non-destructive. The description adds valuable behavioral context: safe polling, status transitions, exact returned payload, and a clear statement that no payment or billing data is ever returned. This goes well beyond the annotation baseline.
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 dense but every sentence contributes: purpose, mandatory sequencing, trust boundary, polling guidance, return payload, customer-facing instructions, and failed-case handling. It is well-organized and 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?
With no output schema, the description carries full responsibility for explaining return values, and it does so thoroughly: status values, the esim block, install_instructions, escalation block, and the absence of payment data. All necessary behavior is covered.
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% and already explains that session_id is the Stripe checkout session id returned by create_checkout, including the 'cs_' prefix. The description reinforces this provenance but does not add meaningfully new parameter-level detail, so 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 states a specific action and resource: check the status of a Stripe checkout session created by `create_checkout`. It clearly distinguishes this tool from siblings by focusing on order status polling and explicitly references the related creation tool.
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 explicit when-to-use guidance: MUST be called after sending payment_url, never trust user claims of payment, safe to poll, and what to do with delivered/failed results. This is direct operational guidance that leaves little ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Stripe checkout link for an eSIM package. MANDATORY PRE-STEP: before calling this tool you MUST know the customer's BILLING/RESIDENCE country (not the travel destination). If you don't have it from the conversation, ASK the user explicitly and WAIT for the answer - do NOT guess from destination, IP, or language. Pass it as customer_country (ISO-3166-1 alpha-2). The optional activation_mode field uses internal API values only. NEVER show NOW, FIRST_USE, ON_DEMAND, activation_mode, or similar technical identifiers to the customer. Use these customer-facing names instead: Activate now, Activate on arrival, Manual activation. If the customer has not already said when they want validity to start, ask naturally: 'Would you like to activate it right now, or when you land? There is a manual option available too, but you will need to access AskMia.app settings to activate.' Use Activate now only if the customer is already at the destination, Activate on arrival for automatic activation when the phone connects at the destination, and Manual activation only if the customer explicitly wants control from AskMia.app. IMPORTANT: Worldwide/global plans do not support Activate on arrival; ask whether the customer prefers Activate now or Manual activation. MANDATORY POST-STEP: relay the returned tax_note, activation_note and post_payment_note verbatim before they click pay. AFTER sending payment_url you MUST STOP, then call check_order_status with the returned session_id; do not assume the eSIM is ready based on the user saying 'I paid'. Open access (2/min per IP), or pass a Bearer API key for 60/min.
| Name | Required | Description | Default |
|---|---|---|---|
| package_id | Yes | eSIM package ID from search_packages | |
| customer_name | No | Customer name (optional) | |
| customer_email | Yes | Customer email for eSIM delivery | |
| activation_mode | No | Internal API value. Never repeat these codes to the customer. NOW maps to Activate now; FIRST_USE maps to Activate on arrival and is the default; ON_DEMAND maps to Manual activation. | |
| customer_country | No | REQUIRED IN PRACTICE. Customer's BILLING/RESIDENCE country as ISO-3166-1 alpha-2 (e.g. 'DE', 'US', 'IT') - NOT the travel destination. Drives checkout currency (EUR for EU-27) and lets Stripe compute VAT correctly. If unknown, ASK the user before calling this tool - do not infer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already mark the operation as non-read-only and not idempotent, the text adds crucial behavior: the tool has side effects (creates a checkout), requires relaying returned notes verbatim, must be followed by order-status verification, and has rate limits. It also warns against assuming fulfillment based on the user's claim of payment.
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 text is long but organized into labeled mandatory sections and front-loads the most critical rule at the top. There is slight repetition of schema-provided enum mapping, but the operational details justify the length.
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 prerequisites, exact conversational prompts, parameter semantics, post-call verification, output fields to relay, and rate limits. Since there is no output schema, the mention of payment_url, session_id, and the three notes provides the necessary contract for the caller.
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?
Although schema coverage is 100%, the description meaningfully extends the schema: it clarifies customer_country means billing/residence country, not destination, and instructs the agent to ask rather than guess. For activation_mode, it provides the customer-safe labels and the exact natural-language question, which is far more actionable than the raw enum 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 opening sentence, 'Create a Stripe checkout link for an eSIM package', names a specific verb, object, and resource, which is enough to separate this from the sibling tools. It is not a tautology and clearly identifies the tool's core action.
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 a mandatory pre-step (ask for customer_country), detailed rules for choosing activation_mode including the worldwide-plan exception, exact user-facing language, and a mandatory post-step to call check_order_status. It explicitly tells the agent what to ask, when to wait, and not to assume payment means the eSIM is ready.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed info about a specific eSIM package, including pricing, VAT/tax note and activation behavior. Pass customer_country to get the correct display currency and VAT flag.
| Name | Required | Description | Default |
|---|---|---|---|
| package_id | Yes | Package ID | |
| customer_country | No | Customer's billing/residence ISO country code (e.g. 'DE'). Drives EUR pricing and VAT flag for EU customers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint: false. The description adds meaningful behavioral context beyond those annotations by revealing country-dependent pricing/currency/VAT behavior and the types of details returned. There is no contradiction with 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 two sentences with no filler. The core purpose is front-loaded, and the only added usage nuance (customer_country) is introduced in the second sentence. Every part earns its place.
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 two-parameter tool with rich annotations and no output schema, the description adequately explains what the tool does and the key parameter behavior. The phrasing 'activation behavior' is slightly vague, but this is a minor gap given the tool's low 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?
Schema coverage is 100%, so the baseline is 3, but the description adds value by explaining that customer_country drives the correct display currency and VAT flag and framing package_id as targeting a specific package. This complements the schema's explanations rather than merely repeating them.
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 names a specific verb and resource: 'Get detailed info about a specific eSIM package.' It also lists the key content areas (pricing, VAT/tax note, activation behavior), which clearly distinguishes it from siblings like search_packages or check_* 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?
The description provides clear usage context, especially the instruction to pass customer_country for the correct display currency and VAT flag. It does not explicitly name alternatives or state when not to use the tool, but the intended use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all countries where eSIM data plans are available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds no extra behavioral detail such as pagination, ordering, or response structure, but for a simple list operation with no parameters this is acceptable.
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 with no filler, and its subject-object structure is easy to parse quickly.
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 has no parameters, a simple read-only purpose, and no output schema, the description is nearly complete. It only lacks explicit mention of the response format, but the stated purpose strongly implies a country list.
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 tool has zero parameters, so the schema requires no documentation. The description sufficiently explains the meaning of the operation despite having no parameters to clarify.
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 a clear resource ('countries where eSIM data plans are available'), which precisely distinguishes this tool from siblings like check_coverage or search_packages. There is no ambiguity about what the tool returns.
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 when the agent needs a list of all countries with eSIM plan availability. It does not explicitly mention when not to use it or provide alternatives, so some inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search eSIM data packages by country code. Optionally filter by minimum data size (min_data_gb) and validity window (max_validity_days, validity_days). Pass customer_country (ISO code, e.g. 'DE') to get prices in EUR with VAT note for EU customers. Returns up to limit packages (default 10, max 50) ordered by price, plus total_available for pagination via offset. Each package includes network_count (number of supported networks across the destination region).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max packages to return (default 10, max 50). | |
| offset | No | Pagination offset (default 0). | |
| min_data_gb | No | Minimum data in GB | |
| country_code | Yes | Destination ISO country code (e.g. US, FR) | |
| validity_days | No | Only return plans with exactly this validity in days (e.g. 7, 15, 30). Overrides max_validity_days. | |
| customer_country | No | Customer's billing/residence ISO country code. Used to pick display currency (EUR for EU-27) and to flag VAT. | |
| max_validity_days | No | Only return plans whose validity is at most this many days (e.g. 7 for a week-long trip). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds valuable behavior beyond that: results are ordered by price, limited and paginated via limit/offset/total_available, and each package includes network_count. It stops short of stating the ordering direction (ascending vs descending) but still provides substantial transparency.
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?
A four-sentence description with every sentence earning its place: main search action, optional filters, customer_country behavior, and return/pagination contract. It is front-loaded with the most important information and avoids filler or restatement of the schema.
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 required country_code, all optional filters, the customer_country effect, return limits, pagination, total_available, and network_count. Minor gaps remain, such as the exact ordering direction and behavior when customer_country is omitted, but the tool is invocable correctly based on this description alone.
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?
With 100% schema coverage, the baseline is 3, but the description clearly exceeds it by explaining the semantic intent of filters ('validity window'), giving a concrete customer_country example ('DE') with a currency/VAT consequence, and defining network_count as supported networks across the destination region. It adds meaning beyond the raw parameter names.
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?
States a specific action ('Search') on a specific resource ('eSIM data packages') with a clear primary key ('by country code'). The filtering and return-behavior details make it distinct from siblings like get_package_details or list_countries.
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 clear context for when the tool is appropriate: searching packages by destination country, optionally narrowing by data/validity, and retrieving EU-specific pricing via customer_country. It does not explicitly name alternatives or exclusion criteria, but the use case is directly and concretely described.
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.
create_checkout1 field changedInput schema / properties / activation_mode / descriptionPrevious value: -"When the validity countdown starts. NOW = right now (customer already at destination). FIRST_USE = when the device first connects to a network at the destination (default, safest for planned travel). ON_DEMAND = customer manually activates later from AskMia.app My Account. Defaults to FIRST_USE if omitted."New value: +"Internal API value. Never repeat these codes to the customer. NOW maps to Activate now; FIRST_USE maps to Activate on arrival and is the default; ON_DEMAND maps to Manual activation."create_checkout1 field changedInput schema / properties / activation_mode / descriptionPrevious value: -"When the validity countdown starts. NOW = at purchase (customer already at destination). FIRST_USE = on first network connection in destination (default, safest for planned travel). ON_DEMAND = customer manually activates later from AskMia.app My Account (max flexibility, requires Wi-Fi/Internet to trigger). Defaults to FIRST_USE if omitted."New value: +"When the validity countdown starts. NOW = right now (customer already at destination). FIRST_USE = when the device first connects to a network at the destination (default, safest for planned travel). ON_DEMAND = customer manually activates later from AskMia.app My Account. Defaults to FIRST_USE if omitted."check_coverage2 fields changedInput schema / properties / customer_countryAdded value: +{
+ "description": "Optional: customer's billing ISO country code.",
+ "type": "string"
+}Input schema / properties / package_idAdded value: +{
+ "description": "Optional: the package the customer is considering, so the response can suggest checkout directly.",
+ "type": "string"
+}check_order_statuscreate_checkout1 field changedInput schema / properties / customer_country / descriptionPrevious value: -"REQUIRED IN PRACTICE. Customer's BILLING/RESIDENCE country as ISO-3166-1 alpha-2 (e.g. 'DE', 'US', 'IT') — NOT the travel destination. Drives checkout currency (EUR for EU-27) and lets Stripe compute VAT correctly. If unknown, ASK the user before calling this tool — do not infer."New value: +"REQUIRED IN PRACTICE. Customer's BILLING/RESIDENCE country as ISO-3166-1 alpha-2 (e.g. 'DE', 'US', 'IT') - NOT the travel destination. Drives checkout currency (EUR for EU-27) and lets Stripe compute VAT correctly. If unknown, ASK the user before calling this tool - do not infer."create_checkout1 field changedInput schema / properties / activation_modeAdded value: +{
+ "description": "When the validity countdown starts. NOW = at purchase (customer already at destination). FIRST_USE = on first network connection in destination (default, safest for planned travel). ON_DEMAND = customer manually activates later from AskMia.app My Account (max flexibility, requires Wi-Fi/Internet to trigger). Defaults to FIRST_USE if omitted.",
+ "enum": [
+ "NOW",
+ "FIRST_USE",
+ "ON_DEMAND"
+ ],
+ "type": "string"
+}search_packages4 fields changedInput schema / properties / limitAdded value: +{
+ "description": "Max packages to return (default 10, max 50).",
+ "type": "number"
+}Input schema / properties / max_validity_daysAdded value: +{
+ "description": "Only return plans whose validity is at most this many days (e.g. 7 for a week-long trip).",
+ "type": "number"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Pagination offset (default 0).",
+ "type": "number"
+}Input schema / properties / validity_daysAdded value: +{
+ "description": "Only return plans with exactly this validity in days (e.g. 7, 15, 30). Overrides max_validity_days.",
+ "type": "number"
+}create_checkout3 fields changedInput schema / properties / customer_country / descriptionPrevious value: -"Customer's billing/residence ISO country code (e.g. 'DE'). Used to pick currency (EUR for EU-27) and pre-fill billing country so Stripe computes VAT correctly."New value: +"REQUIRED IN PRACTICE. Customer's BILLING/RESIDENCE country as ISO-3166-1 alpha-2 (e.g. 'DE', 'US', 'IT') — NOT the travel destination. Drives checkout currency (EUR for EU-27) and lets Stripe compute VAT correctly. If unknown, ASK the user before calling this tool — do not infer."Input schema / properties / customer_email / descriptionPrevious value: -"Customer email for delivery"New value: +"Customer email for eSIM delivery"Input schema / properties / package_id / descriptionPrevious value: -"eSIM package ID"New value: +"eSIM package ID from search_packages"create_checkout1 field changedInput schema / properties / customer_countryAdded value: +{
+ "description": "Customer's billing/residence ISO country code (e.g. 'DE'). Used to pick currency (EUR for EU-27) and pre-fill billing country so Stripe computes VAT correctly.",
+ "type": "string"
+}get_package_details1 field changedInput schema / properties / customer_countryAdded value: +{
+ "description": "Customer's billing/residence ISO country code (e.g. 'DE'). Drives EUR pricing and VAT flag for EU customers.",
+ "type": "string"
+}search_packages2 fields changedInput schema / properties / country_code / descriptionPrevious value: -"ISO country code (e.g. US, FR)"New value: +"Destination ISO country code (e.g. US, FR)"Input schema / properties / customer_countryAdded value: +{
+ "description": "Customer's billing/residence ISO country code. Used to pick display currency (EUR for EU-27) and to flag VAT.",
+ "type": "string"
+}check_device_compatibilitycheck_coveragecreate_checkoutget_package_detailslist_countriessearch_packagesClaiming 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!
