Skip to main content
Glama
MattJeff

orizn-visa-mcp

by MattJeff
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Orizn Visa API MCP Server

Orizn Visa API MCP Server is a Model Context Protocol (MCP) server that gives an AI assistant the visa and entry requirements for any passport/destination pair, answered in 15 languages.

Coverage grows: rather than print a number here that goes stale, the get_coverage_stats tool reads it live from the API (also public at https://visa.orizn.app/api/v1/visa/stats).

npm version License: MIT MCP Compatible

It answers questions like "do I need a visa to go from France to Japan", "what documents does a US citizen need for China", "can I leave the airport during a layover in Istanbul on an Indian passport" — with data, not a guess.

Compatibility

The server speaks MCP over stdio and runs on Node.js 18 or later. It works with any MCP client that can launch a stdio server, including Claude Desktop, Claude Code and Cursor. The configuration block below is the same for all of them.

Related MCP server: @transita/mcp-server

Install

npx orizn-visa-mcp

Nothing to build, nothing to clone. Add it to your MCP client config:

{
  "mcpServers": {
    "orizn-visa": {
      "command": "npx",
      "args": ["-y", "orizn-visa-mcp"]
    }
  }
}

Restart the client, then ask: "Do I need a visa to go from France to Japan?" — that works with no API key, 10 checks a day.

For everything else (documents, fees, processing times, transit rules, 15 languages), add a free key:

{
  "mcpServers": {
    "orizn-visa": {
      "command": "npx",
      "args": ["-y", "orizn-visa-mcp"],
      "env": {
        "ORIZN_API_KEY": "orizn_visa_..."
      }
    }
  }
}

The key can also be passed as an argument, which takes precedence over the environment variable:

npx orizn-visa-mcp --api-key orizn_visa_...

Example questions

  • "Do I need a visa to travel from France to Thailand?"

  • "What documents do I need as a US citizen visiting China?"

  • "Compare Thailand, Vietnam and Indonesia for a Brazilian passport."

  • "Can I leave the airport during a 12h layover in Istanbul on a Chinese passport?"

  • "How much does a Schengen visa cost for a Filipino passport holder?"

  • "Which vaccinations do I need to enter Brazil with a French passport?"

  • "What's the fine if I overstay my Thai visa by 3 days?"

  • "Does Portugal have a digital nomad visa, and what does it cost?"

  • "Réponds en français : ai-je besoin d'un visa pour le Japon avec un passeport marocain ?"

Tools

Tool

Arguments

What it returns

Plan

check_visa_requirement

passport, destination, lang

Full entry requirements for one passport into one destination: requirement type, days allowed, documents, application steps, fees, processing times, passport validity, photo specs, vaccinations, insurance, safety advisory, overstay penalties, entry by air/land/sea, remote-work visa, extension and minor rules, embassies.

Any key

quick_visa_check

passport, destination

One line: the requirement code, the number of visa-free days, and the date the pair was last verified. No documents, no fees, no translation.

None — 10/day keyless, unlimited with any key

compare_destinations

passport, destinations (1–25), lang

Up to 25 destinations for one passport side by side: requirement, visa-free days, description, passport validity, fee, safety, health, vaccinations, insurance, entry by mode, remote-work visa. Each destination returned counts as one request.

Starter or above

check_transit_visa

passport, transit_country, lang

Layover rules only: whether the traveller may stay airside or leave the airport while connecting, and how many free transit hours the main hubs grant.

Starter or above

get_coverage_stats

none

Size of the database: pairs, passports, destinations, translations, languages, and the distribution of requirement types. Says nothing about a specific pair.

None

get_recent_changes

passport, destination, since, limit (all optional)

Visa rules that changed recently, with the source that reported them and the date. The feed is currently off — see below.

None

Country codes are ISO 3166-1 alpha-3 (FRA, JPN, USA), not alpha-2.

requirement is one of visa_free, visa_required, e_visa, visa_on_arrival, eta, no_admission, plus the rarer partial_restrictions, admission_refused, not_applicable and special.

Resource

visa://supported-languages — the 15 codes accepted by lang, available on every plan including free: en fr es pt de ja ko zh ru it ar hi th vi tl.

get_recent_changes returns nothing on purpose

Orizn's policy-change feed is switched off. It was serving inconsistencies detected between two internal Orizn tables as if they were official policy changes, so it now returns HTTP 503 and this tool degrades to:

{ "status": "unavailable", "changes": [], "do_not_conclude": "This is NOT evidence that no visa rules changed..." }

The tool is shipped in this state deliberately: an empty, clearly-labelled answer is the honest one, and the tool starts returning real entries the day the feed runs on verified official sources — at which point entries without a named source and a date are withheld rather than shown.

Authentication and free tier

quick_visa_check, get_coverage_stats and get_recent_changes work with no API key at all. Keyless quick_visa_check is capped at 10 checks per day — the same allowance visa.orizn.app gives an anonymous visitor. Past that the tool says so and points at the free key rather than failing silently. The cap is per running server process and resets at 00:00 UTC.

The other three tools need an API key, sent as the x-api-key header to https://visa.orizn.app/api/v1/visa.

Get a free one at visa.orizn.app/visa-api — no credit card. The free tier is 100 requests/month (5 until you confirm your email address) and includes the core fields and all 15 languages. On the free plan the deeper fields — fees, processing days, photo specs, vaccinations, insurance, transit visas, entry by mode, overstay penalties, remote-work visas, embassies — come back as an {"upgrade": "..."} placeholder, and compare_destinations and check_transit_visa are gated.

Starter is $49/month for 30,000 requests and unlocks all of it, with a commercial licence: upgrade. Higher-volume plans are listed on the pricing page.

Pass the key in the env block of the MCP config — MCP clients do not inherit your shell environment, so exporting ORIZN_API_KEY in a terminal is not enough.

Check a key without any MCP client:

curl -H "x-api-key: $ORIZN_API_KEY" \
  "https://visa.orizn.app/api/v1/visa/check?passport=FRA&destination=JPN"
{ "passport": "FRA", "destination": "JPN", "requirement": "visa_free", "visa_free_days": 90 }

Troubleshooting

Symptom

Fix

"No Orizn API key"

Expected on the key-only tools. quick_visa_check still answers. To lift it, put the key in the env block of the config file — not your shell — then restart the client

"Keyless daily limit reached"

The 10 free checks for today are spent. A free key removes the cap

HTTP 403, "check ORIZN_API_KEY for typos"

Key is wrong, revoked, or has whitespace

HTTP 403, "requires Starter plan or above"

Right key, wrong plan — this tool is paid

HTTP 429

Monthly quota spent

HTTP 404 on a real country

Use alpha-3 codes (FRA, JPN), not alpha-2 (FR, JP)

Nothing works at all

Call get_coverage_stats — it needs no key. If that fails too, it is the network

get_recent_changes returns an empty list

Expected — the feed is being rebuilt. It does not mean the rules are unchanged

Links

License

MIT

Available Tools

5 tools
check_visa_requirementA

Check visa requirements between any two countries. Returns visa type (visa-free, e-visa, visa required, etc.), allowed stay duration, required documents, step-by-step application process, and travel tips. Covers 39,585 passport-destination pairs in 15 languages. Use this tool when the user asks about visa rules, entry requirements, travel documents, or whether they need a visa to visit a country. Requires an API key.

ParametersJSON Schema
NameRequiredDescriptionDefault
passportYesISO 3166-1 alpha-3 country code of the passport holder (e.g. 'FRA' for France, 'USA' for United States).
destinationYesISO 3166-1 alpha-3 country code of the destination country (e.g. 'JPN' for Japan, 'THA' for Thailand).
langNoLanguage code for the response. Supported: fr, en, es, pt, de, ja, ko, zh, ru, it, ar, hi, th, vi, tl. Defaults to 'en'.

TDQS

A3.8/5.0
Behavior3/5

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

No annotations provided. Description notes the tool requires an API key, which is helpful. But no mention of rate limits, error handling, or other behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and deliverables, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description covers what the tool returns and when to use it. Lacks details on output format or error scenarios, but for a query tool, it is largely complete.

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

Parameters3/5

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

Schema has 100% description coverage with clear descriptions of each parameter (country codes, language). Description adds no additional meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it checks visa requirements between two countries and lists return details. However, does not differentiate from the sibling tool 'quick_visa_check', which may serve a similar purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use the tool (for visa rules, entry requirements). Does not mention when not to use or suggest alternative siblings.

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

get_all_destinationsA

Get visa requirements for ALL destinations from a single passport country at once. Returns a complete list of every country with visa status, stay duration, and details for each. Ideal for travel planning, building visa maps, or comparing access across destinations. Requires a Pro plan API key. Use this when the user wants a full overview of where their passport lets them travel.

ParametersJSON Schema
NameRequiredDescriptionDefault
passportYesISO 3166-1 alpha-3 country code of the passport holder (e.g. 'FRA' for France).
langNoLanguage code for the response. Supported: fr, en, es, pt, de, ja, ko, zh, ru, it, ar, hi, th, vi, tl. Defaults to 'en'.

TDQS

A4.2/5.0
Behavior4/5

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

Since no annotations are provided, the description carries the full burden. It discloses the read operation, the return format (list with visa status, stay duration, details), and the API key requirement. It does not mention rate limits or performance, but overall is informative for a non-destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no redundancy. The first sentence states the core functionality, the second details the output, and the third provides usage context and a prerequisite. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 2 parameters, no output schema, and no annotations, the description covers the output (complete list of countries with details), a prerequisite (Pro plan), and use cases. It lacks explicit mention of potential limitations like pagination or timeout, but given the simplicity, it is sufficiently complete.

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

Parameters3/5

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

Schema coverage is 100%, with both parameters ('passport', 'lang') well-described in the schema. The description does not add any additional meaning or constraints beyond what the schema already provides, so a baseline score of 3 is appropriate.

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 clearly states the verb 'get', the resource 'visa requirements for ALL destinations', and the scope 'from a single passport country at once'. It distinguishes the tool from siblings like 'check_visa_requirement' by emphasizing the bulk, all-destinations nature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases ('travel planning, building visa maps, comparing access') and a directive ('Use this when the user wants a full overview'). It also mentions the prerequisite 'Requires a Pro plan API key'. However, it does not explicitly state when not to use this tool versus sibling tools.

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

get_coverage_statsA

Get coverage statistics for the Orizn Visa database. Returns the total number of passport-destination pairs covered, number of countries, and supported languages. This endpoint is free and requires no API key. Use this tool when the user asks about the size, scope, or coverage of the visa database.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.6/5.0
Behavior4/5

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

Discloses that the endpoint is free and requires no API key, which is valuable context beyond the tool's basic function. No annotations exist, so description carries full burden; it adequately covers cost/authentication behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose and returns, second provides usage guidance and a key behavioral note. No wasted words, information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no parameters and no output schema, the description adequately explains purpose, usage, and return data. It is complete enough for an agent to decide when to invoke.

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?

No parameters exist; schema coverage is 100% by default. The description adds value by explaining what the tool returns, fulfilling the baseline for a zero-parameter tool.

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 clearly states it gets coverage statistics for the Orizn Visa database, listing specific metrics (passport-destination pairs, countries, languages). It distinguishes from sibling tools like check_visa_requirement by focusing on overall scope rather than individual queries.

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 states when to use: 'when the user asks about the size, scope, or coverage of the visa database.' This provides clear guidance for agent selection.

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

get_visa_changesA

Get recent changes to visa policies worldwide. Returns newly announced visa requirement updates, visa exemptions, and policy modifications. Optionally filter by passport country or destination country. Requires a Starter plan API key. Use this tool when the user asks about recent visa news, policy updates, or changes in entry requirements for a country.

ParametersJSON Schema
NameRequiredDescriptionDefault
passportNoOptional ISO 3166-1 alpha-3 code to filter changes affecting holders of this passport.
destinationNoOptional ISO 3166-1 alpha-3 code to filter changes for this destination country.

TDQS

A4/5.0
Behavior3/5

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

Description discloses the authentication requirement ('Requires a Starter plan API key'), which adds value beyond the schema. However, no other behavioral traits like rate limits, default ordering, or pagination are mentioned, leaving some gaps given no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences with clear front-loading: first sentence states purpose, second describes returns, third lists filters, fourth gives usage guidance. No unnecessary words; each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 optional parameters, no output schema), the description covers purpose, filter options, auth, and usage context. It does not detail return format or any limitations, but is sufficient for basic understanding. Minor gap in not describing result ordering or count.

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

Parameters3/5

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

Schema coverage is 100% with each parameter having a description specifying ISO 3166-1 alpha-3 codes. The description adds only that filtering is optional, not providing additional semantics beyond the schema. Baseline score of 3 is appropriate.

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?

Description clearly states 'Get recent changes to visa policies worldwide' with specific verb and resource. It lists types of changes (updates, exemptions, modifications), differentiating from sibling tools like check_visa_requirement which handles specific inquiries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this tool when the user asks about recent visa news, policy updates, or changes in entry requirements for a country.' Provides clear context for when to use but does not mention when not to use or name alternative tools for other queries.

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

quick_visa_checkA

Quickly check whether a visa is required between two countries. Returns only the visa status (visa-free, e-visa, visa required, etc.) without detailed documents or process steps. Requires a free API key. Get one at https://visa.orizn.app Use this tool for simple yes/no visa requirement checks or when no API key is available. For full details, use check_visa_requirement instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
passportYesISO 3166-1 alpha-3 country code of the passport holder (e.g. 'FRA' for France).
destinationYesISO 3166-1 alpha-3 country code of the destination country (e.g. 'JPN' for Japan).

TDQS

A4.5/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses API key requirement, return type (only visa status), and excludes detailed documents. Lacks specifics on authentication method or error handling, but sufficient for a simple tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise three-sentence description with all essential information front-loaded. No extraneous words.

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?

Given the tool's simplicity (2 parameters, no output schema needed), the description fully covers what the tool returns and its limitations. No gaps for agent to use correctly.

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

Parameters3/5

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

Schema coverage is 100% with clear descriptions and examples for both parameters. The description does not add additional meaning beyond the schema, baseline score of 3 is appropriate.

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 clearly states the tool checks visa requirements between two countries, returns visa status, and distinguishes from sibling tool 'check_visa_requirement' by noting it is quick and returns only status without details.

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 says when to use: simple yes/no checks or when no API key. Provides alternative: use 'check_visa_requirement' for full details. Also mentions requirement of a free API key.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv1.0.3
    • First observedcheck_visa_requirement
    • First observedget_all_destinations
    • First observedget_coverage_stats
    • First observedget_visa_changes
    • First observedquick_visa_check
Deploy Server
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

TDQS

A4.2/5.0

Scored across 5 tools

Disambiguation5/5

Each tool serves a distinct purpose: detailed check, simplified check, batch overview, stats, and policy updates. No overlap or confusion between tools.

Naming Consistency4/5

All tools use consistent snake_case verb_noun pattern, except 'quick_visa_check' where 'quick' modifies the verb but remains readable and follows the pattern closely.

Tool Count5/5

Five tools is well-scoped for a visa information server, covering the core needs without being too sparse or bloated.

Completeness5/5

The tool set covers key visa queries: detailed and quick checks between two countries, full destination overview per passport, policy changes, and database statistics. No obvious gaps.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches