What Happens When AI Agents Can Check Visa Status Through MCP?

Last updated: 8 November 2026

The agent gets three read-only checks and one gated write. Through MCP it can ask whether a passport and destination pair needs an authorization, what documents and fees apply, and how long processing takes. It can generate an application link and read back the status of applications made through the provider. It cannot query a government system directly, because no such interface exists, and that boundary is the whole story. The interesting part is not the travel use case. It is that regulated status checks now have a standard shape, and every business system with a status worth checking can expose the same tools.

What does MCP actually give an agent here?

MCP, the Model Context Protocol, is a specification that lets an AI agent discover and call external tools in a standard way instead of building a custom integration for every system. For travel authorizations, an MCP server exposes a small set of tools: check the requirement for a passport and destination, list documents and fees, estimate processing time, create an application link, read an application status, and receive status updates through a webhook. The agent discovers those tools at runtime and calls them like any other function.

According to the November 2026 write-up in Luxury Travel Magazine, the reference implementation from YourVisa.ai is read-only and never triggers charges. That detail matters more than it sounds. The tools that answer questions cannot move money or file paperwork. Submission and status checks run through the provider's API, and the MCP layer only makes those calls discoverable. The agent is a caller, not an authority.

Tool	Input	Output	Read-only
Check requirements	Passport, destination	Authorization needed or not needed	Yes
Get documents and fees	Passport, destination	Required documents and fees	Yes
Get processing time	Destination, application type	Estimated processing duration	Yes
Create application link	Passport, destination	URL to the provider's form	No, provider API
Get application status	Application ID	Submitted, approved or refused	No, provider API
Status webhook	Application ID, callback URL	Push updates from the provider	No, provider API

What are the three status types an agent has to separate?

An electronic travel authorization is a digital pre-screening approval that decides whether a traveller can board a flight without a full visa. For an agent, status breaks into three separate questions. Requirement status asks whether an authorization is needed for this passport and destination. Application status asks whether a submitted application has been approved, refused or is still pending. Validity status asks whether an existing approval still covers the traveller's passport and travel dates. Mixing them produces the answer that stalls a booking: a confident statement about eligibility when the traveller actually wanted to know whether their approval is still live.

The separation is also what makes the tools safe. Requirement status is a lookup against rules and can be answered from a maintained dataset. Application status belongs to one application and one applicant, so it needs an identifier and consent. Validity status sits between the two, because it depends on a granted authorization plus the travel dates. An agent that keeps the three apart can give a precise answer and cite the right source for each, which is exactly what the traveller needs before paying for a flight.

Why can't an agent just check ESTA or ETA status itself?

Because the official checks run only on government sites and require the traveller's own details. Neither CBP nor the UK Home Office publishes a public API for third-party systems to query ESTA or ETA status, according to the same Luxury Travel Magazine analysis. Scraping those portals is fragile, usually against their terms of service, and breaks whenever the layout or the rules change. Training data does not solve it either, because fees, eligibility rules and validity periods move, and a model trained on last year's rules will answer confidently and wrongly.

This is the part most agent demos skip. An agent that claims to check ESTA status is either reading a stale dataset or driving a browser against a portal it should not be touching. The honest design admits the boundary: the agent can prepare, explain and link, and the provider can submit and report, but the government remains the authority. That admission is a feature, not a limitation, because it keeps the agent inside the rules and keeps the traveller out of a refused boarding.

What does this look like in Australia?

Australia has the same three-layer shape with local names. The Electronic Travel Authority, subclass 601, is applied for through the Australian ETA app and carries a AUD 20 service fee, with multiple entry over 12 months and stays of up to three months per visit, according to the Department of Home Affairs and the app's own documentation. European passport holders are often better served by the free eVisitor, subclass 651. Applications in progress sit in ImmiAccount, and granted entitlements are verified through VEVO, the Visa Entitlement Verification Online service, which the department describes as free and available to visa holders, employers, education providers and other organisations.

For an Australian business, VEVO is the interesting piece. It is already a status check that employers and education providers run on someone else's entitlement, with that person's consent, and it returns conditions and work rights rather than a simple yes or no. An MCP server in front of VEVO would expose exactly the pattern the travel tools describe: a read-only entitlement lookup, a consent step, an official source and a checked date. The same shape applies to an ATO status, an ASIC registration, a trade licence or an insurance policy. Regulated status is a category, not a travel feature.

What are the design rules for a regulated-status MCP server?

Five rules keep the server useful and defensible. Keep the requirement tools read-only, and gate submission behind the traveller's explicit consent, so the agent prepares and informs but never files on someone's behalf. Minimise passport data in prompts and logs, handling only the fields the task needs. Re-check requirements close to departure, around 72 hours before the flight, because rules change after booking. Return the official source and a last-verified date with every answer. And when the tool cannot decide, send the traveller straight to the government site rather than guessing.

Two more rules belong on our side of the fence. Scope the token, not the agent: an MCP server should authorise a specific tool for a specific applicant, not hand out a broad credential that any prompt can reuse. And log the call, not just the answer, because a regulated status check that cannot be reconstructed later is not auditable. The 2026-07-28 revision of the MCP specification hardened authorization around OAuth 2.1, protected resource metadata and audience-bound tokens, which gives builders the primitives to do both without inventing a scheme.

How does this generalise beyond travel?

Every business has a status worth checking that lives in someone else's system. A supplier's GST registration, an employee's right to work, a contractor's insurance certificate, a vehicle's registration, a trade licence, a claim's progress. Each of those is a regulated lookup with an authority behind it, a consent requirement and a freshness problem. The MCP pattern gives you one integration shape for all of them: discoverable read-only tools, a gated write where an action is needed, an official source with a date, and a recheck before the deadline.

The value for a business is not that the agent is clever. It is that the check becomes consistent. A person doing a right-to-work check on a Friday afternoon and a person doing it on a Monday morning should get the same answer with the same evidence attached. An MCP server with a logged call and a source citation delivers that, and it does it without giving the agent the ability to approve anything on its own.

What does Flowtivity build?

We build the server, not just the prompt. Four plays cover most engagements: MCP server design for a regulated system, scoped OAuth and consent flows, hosting on hardware you own where the data cannot leave the building, and audit logging that survives a review. We run DeepSeek V4 Flash on two NVIDIA DGX Sparks for the local steps, and we keep the provider calls thin so the boundary stays visible. If you are mapping the integration layer, our MCP enterprise integration post covers the general pattern. If the status check touches money or a regulator, pair it with the controls in our agent accountability post.

Frequently asked questions

Can an AI agent check my ESTA or ETA status?
Not directly. The official ESTA and ETA status checks run only on the government sites and require the traveller's own details. An agent can check the status of an application made through a provider's API, and it should send you to the official site for anything else.

Is there an official API for ESTA or ETA status?
No. Neither CBP nor the UK Home Office publishes a public API that third-party systems can query for ESTA or ETA status. Any product that claims otherwise is either scraping a portal or working from a dataset that can go stale.

What is an MCP server for travel authorizations?
It is a server that exposes travel authorization tools to an AI agent through the Model Context Protocol: requirement checks, documents and fees, processing times, application links and status updates. The read-only tools answer questions, and the write tools run through the provider's API with the traveller's consent.

What is VEVO and can an agent use it?
VEVO is Visa Entitlement Verification Online, a free Australian government service that lets visa holders, employers, education providers and other organisations check visa conditions and entitlements. An agent could use it through an MCP server only with the holder's consent and a scoped token, because the check is about a real person's entitlements.

Should an agent submit a visa application on my behalf?
No, not without your explicit approval at the point of submission. The safe pattern is for the agent to prepare the application, generate the official link and explain the fees, then let the traveller submit or approve the submission themselves. Submission is a write action and should be gated.

The useful shift is that regulated status checks now have a standard interface. Once the interface exists, the question stops being whether an agent can check a visa and becomes which statuses in your business deserve the same treatment.