Skip to main content
Glama
EasyOnward

EasyOnward MCP Server

Official
by EasyOnward

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

passport_country

The traveler's passport country. ISO 3166-1 alpha-2 code (US) or name (United States).

destination_country

The destination country. ISO 3166-1 alpha-2 code (KE) or name (Kenya).

Output — both human-readable text and a structured object containing:

  • verdict — a one-line plain-language summary (restricted / conditional / straightforward).

  • worst_severityBLOCK | WARN | INFO | NONE.

  • requirements[] — each flagged requirement as severity, title, detail.

  • official_sources[] — deduped official government source URLs.

  • deep_linkhttps://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. KenyaKE. 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-server

    The 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/mcp

Or 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 claude

Windsurf, Cline & other stdio clients

Any client that supports local stdio MCP servers uses the same blockcommand: 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

EASYONWARD_API_BASE

https://easyonward.com/api/v1

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 stdio

This package lives in its own directory and is intentionally isolated from the EasyOnward frontend/backend tooling and CI.

License

MIT

Available Tools

2 tools
check_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
passport_countryYesThe traveler's passport-issuing country. ISO 3166-1 alpha-2 code (e.g. "US") or country name (e.g. "United States").
destination_countryYesThe destination country. ISO 3166-1 alpha-2 code (e.g. "KE") or country name (e.g. "Kenya").

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesA country name or ISO-2 code, e.g. "Kenya" or "KE".

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness5/5

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.

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 (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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

  1. 2 tool updatesv0.2.0
    • First observedcheck_visa
    • First observedcountry_code

TDQS

A4.2/5.0
Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessSyncing

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

Related MCP Servers

  • A
    license
    A
    quality
    C
    maintenance
    Check 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.
    5
    211
    1
    MIT

Latest Blog Posts

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