EasyOnward MCP Server
OfficialClick on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@EasyOnward MCP ServerDo I need a visa to travel from the US to Kenya?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
EasyOnward MCP Server
A read-only Model Context Protocol server that lets any MCP-capable AI assistant (Claude Desktop, Cursor, ChatGPT desktop, …) check passport visa, entry, and transit requirements for a country pair — with official government sources and a deep link to the full EasyOnward analysis.
It wraps EasyOnward's public, unauthenticated visa-pair endpoint. It is read-only, sends no PII, and requires no API key.
Not legal or immigration advice. Results are a generic analysis for any citizen of the passport country. Always verify with your airline and the destination's authorities before travel.
Tools
check_visa
Check whether a traveler holding a given passport needs a visa, and what entry & transit requirements apply, for a destination country — with official government sources.
Inputs
Field | Description |
| The traveler's passport country. ISO 3166-1 alpha-2 code ( |
| The destination country. ISO 3166-1 alpha-2 code ( |
Output — both human-readable text and a structured object containing:
verdict— a one-line plain-language summary (restricted / conditional / straightforward).worst_severity—BLOCK|WARN|INFO|NONE.requirements[]— each flagged requirement asseverity,title,detail.official_sources[]— deduped official government source URLs.deep_link—https://easyonward.com/visa/{ORIGIN}-{DEST}for the full analysis.prepare_link— the same page tagged?ref=mcp, comparing visa services, travel insurance, and eSIM options alongside the official/free path.disclaimer.
country_code
Helper that resolves a country name (or an existing ISO-2 code) to its uppercase ISO 3166-1
alpha-2 code — e.g. Kenya → KE. Handy before calling check_visa.
Related MCP server: orizn-visa-mcp
Example
Calling check_visa with { "passport_country": "US", "destination_country": "KE" }:
Travel from United States to Kenya is conditional — see requirements.
Requirements:
[INFO] US travel advisory: Kenya — Level 2 (Exercise Increased Caution) — …
[INFO] Be ready to show proof of funds for Kenya (KE) — …
[WARN] An electronic travel authorization (eta) for Kenya on your United States (US) passport — …
Official government sources:
- https://www.etakenya.go.ke
- https://immigration.go.ke
- https://travel.state.gov/…/kenya-travel-advisory.html
…
Full details: https://easyonward.com/visa/US-KE
Generic analysis for any United States citizen. Not legal or immigration advice — verify with
your airline and the destination's authorities before travel.Install & run
Two ways to connect, same tools:
Hosted (remote) — no install, nothing to run. Point any HTTP-capable MCP client at
https://mcp.easyonward.com/mcp(Streamable HTTP). Best for most users.Local (stdio) — runs on Node 18+ via
npx(no install needed):npx -y @easyonward/mcp-serverThe server speaks MCP over stdio. Best for offline/air-gapped setups or clients without remote transport.
Hosted (remote) — Claude Code / any HTTP client
claude mcp add --transport http easyonward https://mcp.easyonward.com/mcpOr in a client config that supports remote servers:
{
"mcpServers": {
"easyonward": {
"type": "streamable-http",
"url": "https://mcp.easyonward.com/mcp"
}
}
}The hosted server is read-only, stateless, and PII-free — same two tools as the local build.
Claude Desktop (local stdio)
Add to claude_desktop_config.json
(macOS: ~/Library/Application Support/Claude/claude_desktop_config.json,
Windows: %APPDATA%\Claude\claude_desktop_config.json):
{
"mcpServers": {
"easyonward": {
"command": "npx",
"args": ["-y", "@easyonward/mcp-server"]
}
}
}Restart Claude Desktop, then ask: "Do I need a visa to fly from the US to Kenya?"
Cursor
Add to ~/.cursor/mcp.json (or Settings → MCP → Add new server):
{
"mcpServers": {
"easyonward": {
"command": "npx",
"args": ["-y", "@easyonward/mcp-server"]
}
}
}Smithery
This server ships a smithery.yaml manifest, so it can be installed from the
Smithery registry:
npx -y @smithery/cli install @easyonward/mcp-server --client claudeWindsurf, Cline & other stdio clients
Any client that supports local stdio MCP servers uses the same block —
command: npx, args: ["-y", "@easyonward/mcp-server"]. In Windsurf it's
Settings → Cascade → MCP Servers; in Cline it's the MCP settings JSON. No
client-specific setup.
Configuration
Env var | Default | Purpose |
|
| API base URL. Point at a dev/staging host for testing. |
Example (point at a dev host):
{
"mcpServers": {
"easyonward": {
"command": "npx",
"args": ["-y", "@easyonward/mcp-server"],
"env": { "EASYONWARD_API_BASE": "https://dev.easyonward.com/api/v1" }
}
}
}Security & privacy
Read-only. The server only performs GET lookups against the public EasyOnward API — it never writes, books, or mutates anything.
No secrets, no auth. There's no API key or token to configure, so there's nothing to leak.
No PII. It sends only a passport country + a destination country (ISO-2 codes or country names). It never asks for or transmits passport numbers, names, dates of birth, or any personal data.
Public data only. Everything returned is public visa/entry/transit reference information, with links to official government sources.
Fail-safe. An unreachable API or an uncatalogued country pair returns a clear message, not a crash. Requests are subject to the public API's rate limits.
Develop
npm install # install deps
npm run build # tsc -> dist/
npm test # unit tests (mocked fetch)
npm start # run the built server on stdioThis package lives in its own directory and is intentionally isolated from the EasyOnward frontend/backend tooling and CI.
License
MIT
Available Tools
2 toolscheck_visaCheck visa & entry requirementsAInspect
Check whether a traveler holding a given passport needs a visa, and what entry & transit requirements apply, for a destination country — with official government sources. Accepts ISO 3166-1 alpha-2 codes (e.g. "US", "KE") or common country names (e.g. "United States", "Kenya"). Returns a plain-language verdict, the specific requirements by severity, deduped official source links, and a deep link to the full EasyOnward analysis. Read-only and PII-free; the analysis is generic for any citizen of the passport country.
| Name | Required | Description | Default |
|---|---|---|---|
| passport_country | Yes | The traveler's passport-issuing country. ISO 3166-1 alpha-2 code (e.g. "US") or country name (e.g. "United States"). | |
| destination_country | Yes | The destination country. ISO 3166-1 alpha-2 code (e.g. "KE") or country name (e.g. "Kenya"). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses read-only and PII-free nature, mentions official government sources, deduped links, and output types. Does not mention rate limits or data freshness, but the behavioral detail is good.
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, no fluff, and front-loads the key purpose. Every word earns its place, making it efficient and easy to parse.
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 lists all major output components (verdict, requirements, source links, deep link). With no output schema, this is adequate. Could be more complete by mentioning any limitations (e.g., coverage of visa types), but it's sufficient for the tool's 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%, and both parameters have clear descriptions. The description adds examples of valid inputs (ISO codes and country names) but largely reiterates what the schema already provides. Minimal added meaning.
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 the tool's purpose: checking visa and entry requirements for a traveler based on passport and destination. It specifies verb 'check' and resource 'visa & entry requirements', and distinguishes from sibling 'country_code'.
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 (visa check) and explicitly states it's read-only and PII-free. It doesn't provide explicit alternatives or when not to use, but the sibling tool name 'country_code' hints at differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
country_codeResolve a country name to its ISO-2 codeAInspect
Resolve a country name (or an existing ISO 3166-1 alpha-2 code) to its uppercase ISO 3166-1 alpha-2 code — e.g. "Kenya" → "KE". Useful before calling check_visa. Returns an error if the name can't be resolved.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A country name or ISO-2 code, e.g. "Kenya" or "KE". |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the transformation (to uppercase), input acceptance (name or existing code), and error behavior. For a simple lookup, this is adequate, though it could mention if it requires authentication or has rate limits.
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, very concise, and front-loaded with the main purpose. Every sentence adds value, and there is no 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?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description is complete. It covers purpose, usage, input flexibility, example, and error handling.
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% and the description adds value beyond the schema: it clarifies that the parameter can be a country name or an existing ISO-2 code, and provides an example. The schema only states 'A country name or ISO-2 code'; the description enriches understanding.
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 the tool's function: resolve a country name or existing ISO code to its uppercase ISO-2 code, with an example ('Kenya' → 'KE'). It also distinguishes itself from the sibling tool 'check_visa' by noting it's useful before calling that 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 explicitly states when to use the tool ('useful before calling check_visa') and what happens on error ('returns an error if the name can't be resolved'). It does not explicitly state when not to use it, but the context is sufficiently clear.
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. Dates show when Glama detected each change.
2 tool updates
v0.2.0- First observed
check_visa - First observed
country_code
TDQS
The two tools have clearly distinct purposes: country_code resolves country names to ISO codes, while check_visa checks visa requirements. There is no ambiguity or overlap.
Both tools use lowercase with underscores, but country_code (noun_noun) is not imperative like check_visa (verb_noun). The inconsistency is minor and does not hinder understanding.
With only two tools, the server feels minimal. While they cover the essential workflow, the count is low for a general travel information server, bordering on insufficient.
The tool set covers the core loop of normalizing country names and checking visa requirements. There are no obvious missing operations for the stated purpose, though additional tools like country listing could enhance coverage.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Visa eligibility matcher and immigration intelligence for MCP-compatible AI assistants.
Your personal AI travel concierge — flights, hotels, 116M+ POIs, visas, weather & more
Plan trips and track visa days per traveller across 39,601 entry rules
Visa Requirements MCP — passport visa rules for any nationality → destination pair
Related MCP Servers
- FlicenseCqualityBmaintenanceProvides tools to fetch up-to-date visa and immigration information for various countries, helping users plan their international travel with accurate data.2-
- AlicenseAqualityCmaintenanceCheck visa requirements for 39,585 passport-destination pairs in 15 languages. Returns visa type, required documents, application process, and travel tips from 136 official government sources. Free quick checks without API key.52111MIT
- AlicenseAqualityAmaintenanceEnables travel search workflows including airport lookup, route comparison, travel timing guidance, and external booking links with commission-eligible links.5481MIT
- AlicenseAqualityBmaintenanceProvides immigration eligibility intelligence, enabling AI assistants to match user profiles to visas, compare pathways, and get country overviews using Transita's API.570MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/EasyOnward/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server