Skip to main content
Glama
Sign In

orizn-visa-mcp

by io.github.MattJeff
OverviewDiscussionsAdmin

Transit and layover rules

check_transit_visa
Read-onlyIdempotent

[needs a free API key — this call will fail without one: https://visa.orizn.app/visa-api/register?source=mcp-remote, then reconnect with ?key=] Transit and layover rules for a country being connected through: airside/landside rules and how many free transit hours its main hubs grant. Call it for layovers, stopovers and connecting flights — not for entering a country as a destination, which is check_visa_requirement. IMPORTANT: this data is modelled PER TRANSIT COUNTRY, not per passport nationality. The answer is the same for every passport, the passport argument is recorded but does not narrow the result, and only 44 transit countries are covered. Present the reply as general hub rules to confirm with the airline or the transit country's authority, never as a per-nationality ruling. When the country is not covered the tool answers {status: "unavailable"} instead of guessing. Needs the Starter plan ($149/month, 30,000 requests) or above and costs 1 request. On a free key this call is refused before anything is charged, with the upgrade link.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "passport": "<passport>",
      "transit_country": "<transit_country>"
    },
    "name": "check_transit_visa"
  }
}

Input Schema

NameRequiredDescriptionDefault
langNoLanguage code. One of: fr, en, es, pt, de, ja, ko, zh, ru, it, ar, hi, th, vi, tl. Defaults to en.
passportYesTraveller's passport, ISO 3166-1 alpha-3 (e.g. IND). Recorded, but does not narrow the answer.
transit_countryYesCountry being transited, ISO 3166-1 alpha-3 (e.g. ARE for a Dubai layover, TUR for Istanbul).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the readOnly/idempotent annotations, it discloses that the data is modelled per transit country rather than per passport, that only 44 countries are covered, that uncovered countries return {status: "unavailable"} instead of guessing, and that it costs 1 request on a paid plan. The auth/plan prerequisites are also stated up front, though they are repeated redundantly in the trailing sentences.

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

Conciseness4/5

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

The purpose, exclusions, and modelling caveat are front-loaded and each earns its place. The billing/upgrade information is stated twice (the bracketed key notice and the trailing plan sentences), which is the main source of avoidable length.

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?

There is no output schema, so the description supplies the response shape for the failure case and warns about the per-country (not per-nationality) modelling and the 44-country scope. For a read-only lookup gated by an API key and paid plan, an agent has everything needed to call it and to caveat the answer.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds a crucial semantic the schema only hints at: the passport argument is recorded yet does not narrow the result, and the answer is identical for every nationality. That materially changes how an agent should interpret and present the arguments.

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 names a specific resource ('Transit and layover rules for a country being connected through') and enumerates the concrete outputs: airside/landside rules and free transit hours at main hubs. It explicitly distinguishes itself from check_visa_requirement, so an agent can route without opening either schema.

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?

It gives positive triggers ('layovers, stopovers and connecting flights') and an explicit exclusion ('not for entering a country as a destination'), naming the alternative sibling that handles that case. Nothing about when to select this tool is left to inference.

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

All orizn-visa-mcp toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources