Visa & entry requirements for 199 passports, cited to official sources and re-verified daily.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: single entry check, multi-passport trip evaluation, and dataset metadata. There is no overlap in functionality, making selection unambiguous.
All tools follow the verb_noun format in snake_case: check_entry_requirements, evaluate_trip, get_dataset_info. The naming pattern is uniform and predictable.
With only 3 tools, the server is tightly scoped to visa checking. Each tool covers a distinct need without redundancy, and the count feels appropriate for the purpose.
The core visa-checking workflow is well covered, including single-entry checks and complex trip evaluation. A minor gap is the lack of a tool to list available countries or passport types, though dataset info partially addresses this.
check_entry_requirementsCheck entry requirementsAWhether a passport holder can enter a destination country: visa-free, visa on arrival, e-visa, eTA, or visa required — with allowed stay, official application portal, extended rules (passport validity, onward ticket, yellow fever, transit-without-visa) and source citations. Free tier: rate limited per caller (see /auth.md to register for a larger quota, or use the x402-paid HTTP API for unlimited access).
| Name | Required | Description | Default |
|---|---|---|---|
| purpose | No | Travel purpose (default: tourism) | |
| transit | No | Optional transit country, ISO 3166-1 alpha-3 | |
| passport | Yes | Passport country, ISO 3166-1 alpha-3 (e.g. NLD) | |
| visas_of | No | Issuers of visas held (ISO3 or SCHENGEN/EU/GCC) | |
| destination | Yes | Destination country, ISO 3166-1 alpha-3 (e.g. JPN) | |
| residence_permits_of | No | Issuers of residence permits held (ISO3 or SCHENGEN/EU/GCC) |
| Name | Required | Description |
|---|---|---|
| apply | No | Official government application/information portal when action is required |
| request_id | No | Unique id for reproducibility |
| entry_rules | No | Destination entry rules: passport_validity, blank_pages, onward_ticket, yellow_fever, other_health, twov (transit-without-visa), residence_permit_exemptions, official_links, purpose_scope — each non-null field cites its official source {name, url, retrieved_at}, plus last_verified and coverage (extended|basic). |
| requirement | No | visa_free | visa_on_arrival | e_visa | eta | visa_required | no_admission | unknown | needs_review |
| dataset_version | No | Base-matrix revision (YYYY-MM-DD) |
| defaults_applied | No | Assumptions applied to answer (e.g. purpose=tourism, ordinary passport) |
| allowed_stay_days | No | Maximum stay in days when the verdict grants one |
| requirement_label | No | Human-readable verdict |
| verdict_verification | No | Provenance of the visa verdict itself — always derives from an aggregated secondary matrix (status secondary_source_only or needs_review), never claimed officially verified |
| entry_rules_verification | No | Provenance of the curated entry-rules layer: verified_official_sources | stale | not_curated | needs_review, with last_verified and staleness_days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds valuable behavioral context: the free tier is rate limited, larger quotas require registration via /auth.md, and an x402-paid API offers unlimited access. It also mentions source citations, giving insight into reliability. No contradictions found.
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 long and front-loads the core purpose, followed by practical authentication/quota information. Every clause is informative, and there is no redundancy or filler.
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 presence of a rich output schema and full schema parameter coverage, the description needs only to clarify purpose, scope, and operational constraints. It covers visa categories, extended rules, source citations, and rate limits, making it complete for an agent to decide when and how to invoke the tool.
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 covers 100% of parameters with descriptions, so the description does not need to repeat parameter meanings. It adds minimal extra parameter-related context beyond the schema, such as the mention of transit-without-visa rules related to the transit parameter, but this is indirect. 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 explicitly states the tool's function: determining whether a passport holder can enter a destination country, listing visa categories (visa-free, visa on arrival, e-visa, eTA, or visa required) and additional details like allowed stay and official portals. This clearly distinguishes it from siblings like evaluate_trip and get_dataset_info.
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 clearly implies the tool is for entry-requirement queries for a specific passport/destination combination, and it provides context about rate limits and authentication needs. However, it does not explicitly mention alternatives or when-not-to-use, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evaluate_tripEvaluate a full trip (paid)APremium evaluation of a whole trip in one call: multiple passports (best passport per leg), documents held, multi-leg itineraries with transit legs, dates and purpose — with structured why[] explanations, conditions[], and verification states per decision. PAID endpoint: the call returns HTTP 402 x402 payment instructions unless the request carries an x402 payment header; any x402-capable client settles in USDC on Base and retries.
| Name | Required | Description | Default |
|---|---|---|---|
| trip | Yes | The itinerary to evaluate, in travel order | |
| traveler | Yes | The traveler's documents |
| Name | Required | Description |
|---|---|---|
| legs | No | One decision per leg: requirement, best_option (which held passport/document wins), why[] explanations with sources, conditions[] (validity, onward ticket, yellow fever, stay-duration fit), and a verification state |
| error | No | Present on the unpaid path: 'payment_required' |
| trip_summary | No | Aggregate outcome |
| x402_requirements | No | x402 v2 payment requirements (decoded from the PAYMENT-REQUIRED header): pay in USDC on Base and retry the same call |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the payment requirement (HTTP 402, x402 header, USDC on Base) which annotations do not cover. It also previews the output structure and the 'best passport per leg' behavior, adding substantial context beyond the annotations' readOnly/idempotent hints. 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 two sentences, the first quickly communicates the core evaluation scope and the second concisely explains the crucial payment flow. No filler; each clause adds distinct value, and the primary purpose is front-loaded before the cost implication.
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 complex tool with a rich input schema and an output schema, the description covers the essential context: scope, paid status, payment flow, and output structure. Combined with 100% schema coverage and the output schema, the description leaves little ambiguity for an agent to decide when and how to invoke it.
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 100% coverage with detailed field descriptions, so the baseline is 3. The description adds meaningful high-level semantics, particularly 'best passport per leg', which explains how the tool optimizes the passports array across legs. This goes beyond the schema's raw field descriptions.
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 evaluates a whole trip, enumerating specific inputs (multiple passports, documents, multi-leg itineraries with transit legs, dates, purpose) and outputs (structured why[], conditions, verification states). It explicitly differentiates from sibling tools by emphasizing the full-trip, multi-passport scope, making it distinct from a simple entry check.
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 sets a clear context: use this when you need a premium whole-trip evaluation with multiple passports and structured explanations. It does not explicitly name alternatives or state when not to use it, but the emphasis on 'whole trip' and 'one call' implicitly contrasts with simpler per-entry checks like check_entry_requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dataset_infoDataset & pricing infoACoverage and freshness of the underlying visa-requirements dataset, plus endpoints and x402 pricing for the unlimited paid tier.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | No | |
| docs | No | LLM-facing documentation URL |
| transparency | No | Data-quality metrics URL |
| free_endpoint | No | The free rate-limited check endpoint |
| paid_endpoints | No | x402 pay-per-request endpoints (USDC on Base, no account) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior, so the description adds meaningful context about the specific information returned (coverage, freshness, endpoints, pricing). No contradictions and no missing side-effect warnings needed.
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 single concise sentence that front-loads the key content (coverage, freshness, endpoints, pricing). Every element is informative and there is zero 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?
For a no-parameter info tool with a rich output schema and strong annotations, the description adequately conveys the tool's purpose and scope. The complexity is low, and the description covers all necessary 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?
The tool has zero parameters, and schema coverage is 100%. The description is not required to explain parameters, and no parameter information is needed. A baseline of 4 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 what the tool provides: coverage, freshness, endpoints, and x402 pricing for the dataset. This distinguishes it from sibling tools like check_entry_requirements and evaluate_trip, which focus on actual visa checks and trip evaluation rather than dataset metadata.
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 this tool (to learn about dataset coverage/freshness or pricing) and clearly separates it from siblings. It lacks explicit 'when not to use' or named alternatives, but the context is clear enough for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
