Skip to main content
Glama

Mirabello Immigration Intelligence

Visa Requirement by Nationality

check_visa_requirement
Read-onlyIdempotent

VISA REQUIREMENT for ONE nationality travelling to ONE destination: visa-free (with maximum stay in days where published), visa on arrival, e-visa, electronic travel authorisation, visa required, or no admission. Covers 199 passports x 199 destinations from the open Passport Index dataset, with the Wikipedia corroboration page and the IATA Travel Centre verification link returned alongside. General information only - entry rules change without notice; the destination authority is final.

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": {
      "from_nationality": "<from_nationality>",
      "destination": "<destination>"
    },
    "name": "check_visa_requirement"
  }
}

Input Schema

NameRequiredDescriptionDefault
destinationYesdestination - ISO alpha-2 code or country name, e.g. TR, "Turkey", "Schengen" (checked via Germany)
from_nationalityYespassport held - ISO alpha-2 code or country name, e.g. NG, IN, "Nigeria"

Output Schema

NameRequiredDescriptionDefault
errorNo
termsNo
sourceNo
book_urlNo
providerNo
disclaimerNo
data_updatedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedOutput schema / description
      Previous value: -"Mirabello response envelope. Tool-specific fields vary; the provenance/disclaimer envelope is always present."New value: +"Mirabello envelope; tool fields vary; error only on failure."
    • removedOutput schema / properties / book_url / description
      Removed value: -"Link to request a consultation with a Mirabello specialist, for a personal case."
    • removedOutput schema / properties / data_updated / description
      Removed value: -"Date the underlying dataset was last updated."
    • removedOutput schema / properties / disclaimer / description
      Removed value: -"Information, not legal/tax/financial/immigration advice; figures indicative."
    • removedOutput schema / properties / error / description
      Removed value: -"Present only when the request could not be fulfilled."
    • removedOutput schema / properties / provider / description
      Removed value: -"Always \"Mirabello Consultancy\"."
    • removedOutput schema / properties / source / description
      Removed value: -"Attribution for the data, when it is not Mirabello Consultancy itself."
    • removedOutput schema / properties / terms / description
      Removed value: -"Acceptable-use and information-not-advice terms."
  2. Changed3 schema fields changed
    • removedOutput schema / properties / book_a_consultation
      Removed value: -{
      -  "description": "URL to book a Mirabello consultation.",
      -  "type": "string"
      -}
    • addedOutput schema / properties / book_url
      Added value: +{
      +  "description": "Link to request a consultation with a Mirabello specialist, for a personal case.",
      +  "type": "string"
      +}
    • changedOutput schema / properties / source / description
      Previous value: -"Attribution for the data."New value: +"Attribution for the data, when it is not Mirabello Consultancy itself."
  3. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description still adds genuine value: the underlying Passport Index dataset and its 199x199 coverage, the fact that a Wikipedia corroboration page and IATA Travel Centre verification link come back with the answer, that 'no admission' is a valid outcome, and that rules can change without notice.

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?

Two sentences, front-loaded with the resource and cardinality, then the dataset and provenance. Dense but nearly every clause carries information; the enumerated outcome list is long yet functional since it defines the result vocabulary.

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?

With an output schema present, the description need not explain the return shape, and it still discloses data source, corroboration links, and the disclaimer that the destination authority is final. The only gap is sibling disambiguation, which matters in a roster containing check_visa_free and get_entry_requirements.

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 already document accepted formats (ISO alpha-2 or name, with 'Schengen' resolving via Germany), so the description does not need to re-explain syntax. It reinforces the one-to-one cardinality and the covered domain, but adds no per-parameter meaning beyond the schema.

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?

States a specific verb and resource ('VISA REQUIREMENT for ONE nationality travelling to ONE destination') and enumerates the exact possible outcomes (visa-free with max stay, VOA, e-visa, ETA, visa required, no admission). The dataset scope (199 passports x 199 destinations) and the single-pair cardinality clearly separate it from list-style siblings like list_visa_free_destinations.

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 'ONE nationality travelling to ONE destination' framing implicitly tells the agent this is a pairwise lookup rather than a bulk scan, which is real routing guidance. However, it never names an alternative (e.g. check_visa_free, list_visa_free_destinations, get_entry_requirements) or states when not to use it, so the agent must infer the boundary.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.