← Back to Blog
July 29, 2026 · 5 min read

EU Hosted MCP: Why Teams Ask Where Their AI Infrastructure Runs

Short answer: if a vendor cannot tell you which country your MCP gateway runs in, they cannot tell you where your agent's credentials, tool payloads, and memory live either. That is the whole reason EU hosted MCP infrastructure has moved from nice-to-have to one of the first questions European teams put in a vendor call.

Agent infrastructure sounds abstract until you list what actually passes through it. Then data residency for AI agents stops being a legal footnote and becomes a very concrete question about a very concrete server.

What actually flows through an MCP gateway

An [MCP gateway](/blog/what-is-an-mcp-gateway) sits between your agent and every tool it can call. That position makes it a concentration point for three kinds of data.

Credentials. The gateway stores OAuth tokens and API keys for every connected tool, server-side, so your agent can sign in once. Whoever runs that vault holds standing access to your CRM, your helpdesk, your accounting tool.

Tool payloads. Every request and every response passes through the gateway. A "look up this customer" call carries a name and an email address. A "list open invoices" call carries billing data. The gateway sees all of it in transit, and most gateways log at least some of it.

Memory. If the gateway has a memory layer, it also stores data at rest: goals, decisions, IDs, fragments of past sessions. Unlike a payload that passes through, memory is designed to persist. It is a database of what your agent knows, and it lives wherever the gateway lives.

That third category is the one procurement checklists usually miss. A memory layer is a new data store, and it belongs on your list of processing locations like any other database.

Why location matters to EU buyers

For a European company, the location question is process, not paranoia.

GDPR restricts moving personal data outside the EU. Transfers to the US are possible but need a legal mechanism and, since the Schrems II ruling, a case-by-case assessment of whether that mechanism actually holds up. Every US-hosted service in your stack is one more entry in that assessment, one more sub-processor in your DPA, one more conversation with whoever reviews your vendor list.

We wrote up [what GDPR means for AI agent setups](/blog/gdpr-and-ai-agents) in detail. The short version for gateways: tool payloads routinely contain personal data (customer records, ticket contents, email addresses), so the gateway that routes them is a processor in your chain, and its hosting location is a fact you are expected to know and document.

There are unglamorous practical reasons too. Keeping your AI infrastructure inside the EU keeps latency low for EU teams, keeps the sub-processor list short, and keeps the answer to "where is this data?" one sentence long.

EU hosted MCP is still rare in 2026

Here is the uncomfortable market fact: MCP grew out of the US AI ecosystem, and most of the big MCP platforms and gateway products are US companies running on US infrastructure. As of mid 2026, EU residency for MCP infrastructure is the exception, not the rule. If you need it, you are choosing from a short list, and you should verify the claim rather than assume it, because "we have EU customers" and "your data stays in the EU" are very different sentences.

Five questions to ask any MCP vendor

Where are credentials stored, and how? You want a named region and encryption at rest, ideally per secret, not a vague "in the cloud." [Credential handling in a gateway](/blog/mcp-gateway-security) is a solvable problem, so vagueness here is a red flag.

Where do tool payloads get processed? Edge networks complicate this: a CDN with global points of presence can touch traffic outside the EU even when storage is European. Ask about processing, not just storage.

Where does agent memory live, and can you export and delete it? Persistent memory is personal data waiting to happen. You need a location, a retention answer, and a delete button.

Can I revoke one connection without nuking the rest? Residency is about control, and control includes the off switch. Per-connection revocation is the bar.

What gets logged, and for how long? An [audit trail of every agent call](/blog/ai-agent-audit-trail) is a feature you want, but logs are data too, and they live somewhere.

Where Tulimoa stands

Full disclosure: Tulimoa is our product, so weigh this section accordingly.

We are a two-founder company, built in Germany, and [the Tulimoa gateway](/gateway) is hosted in the EU, in Frankfurt. Credentials sit in an encrypted per-secret vault, every connection is revocable at any time, and data export is available in the app. The gateway itself is in early beta and not self-serve yet; the directory and our public MCP server are live today.

What we will not do is wave a compliance badge at you. We do not claim certifications we do not hold, and hosting location alone does not make anyone compliant. It just makes the residency question easy to answer, which is where every honest compliance story starts.

Frequently asked questions

Does MCP itself say anything about where data is processed?

No. MCP is a protocol, like HTTP. It defines how agents and tools talk, not where the servers run. Residency is a property of the deployment you choose, which is exactly why you have to ask each vendor separately.

Is self-hosting MCP servers a way around the residency question?

Partly. Running MCP servers on your own EU infrastructure keeps that traffic under your control, but most useful tools are remote SaaS services that process data on their side regardless. Self-hosting shortens your vendor list; it does not eliminate the question.

Does EU hosting make my agent setup GDPR compliant?

No. Hosting location is one factor among many. Compliance depends on your whole chain: what data your agents touch, your legal bases, your DPAs, retention, and the sub-processors behind every tool. EU hosting removes one hard problem, international transfers for that piece of the chain, nothing more.