visa-check

Check entry requirements

check_entry_requirements

Read-onlyIdempotent

Whether 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).

Input Schema

TableJSON Schema

Name	Required	Description
`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)

Output Schema

TableJSON Schema

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

TDQS

A4.5/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All visa-check tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources

Need Help?