Quick answer

An MCP server is just a program that exposes tools, resources and prompts over JSON-RPC. Where that program runs decides where your data lives. If you launch it as a subprocess on your laptop over stdio, the data stays on your machine. If you put it behind a Streamable HTTP endpoint in Frankfurt, the bytes move through Frankfurt. If you hand the whole thing to a managed MCP host, you inherit whatever region and contract they offer. The protocol itself is silent on geography. Your choice of transport and hosting decides the residency story.

Why this matters for a solo founder

The moment your MCP server touches a paying customer’s record, your compliance footprint changes. Even a small product that calls a hosted MCP integration to read a CRM record, summarise a support ticket or trigger a payment is now moving identifiable data through a tool you do not fully control. That is the point at which “it runs on my laptop” stops being a polite answer to a procurement questionnaire.

The practical question is narrow: when a customer asks “where does our data sit when your AI workflow runs?”, can you answer it in one sentence and prove it?

The Model Context Protocol specification only describes message format and transport bindings. It does not require any specific region, encryption posture, or audit trail. Those are choices you, the operator, make in code and in your hosting bill.

The three residency shapes you can actually choose

Before picking a region, pick a shape. Most solo founders end up in one of three patterns, and each has a different default residency story.

1. Local stdio on the founder’s machine

The simplest pattern. A desktop host such as an AI IDE launches the MCP server as a child process and talks to it over standard input and output. JSON-RPC messages, including prompts and tool results, flow through pipes on the same machine.

  • Residency: wherever the laptop sits.
  • Network exposure: none, by default.
  • Who can see the data: the founder, the host application, and any tool the server itself calls (for example, a database on the same box).

This is fine for development and for internal workflows. It stops being fine the moment you want a second user, a teammate, or a customer to trigger the workflow. stdio is a local binding, not a service.

2. Self-hosted Streamable HTTP on your own infrastructure

You run the MCP server as a long-lived process that exposes a single HTTP endpoint. Clients POST JSON-RPC messages to it and optionally receive responses as an SSE stream. The server might live on a VPS, a small container in a regional cloud account, or a bare-metal box in a colocation facility you rent.

  • Residency: the region of the machine, the region of the storage it reads, and the regions of any downstream APIs it calls.
  • Network exposure: whatever you expose. The spec warns about DNS rebinding and recommends binding only to localhost when developing.
  • Who can see the data: you, your hosting provider, and any third party whose API you call.

This is the pattern that gives you the cleanest answer for a customer. “Our MCP server runs in eu-central-1, reads from a Postgres instance in eu-central-1, and the only outbound call is to the LLM provider’s EU endpoint.” If that is what your contract requires, this is how you prove it.

3. Managed MCP hosting from a vendor

A growing number of vendors will host, scale and sometimes monitor your MCP server for you. Some are pure MCP hosts; others are LLM platforms that let you register remote MCP servers and route clients through their gateway.

  • Residency: whatever the vendor offers, which may or may not include a region picker.
  • Network exposure: the vendor’s perimeter and any logging they keep.
  • Who can see the data: the vendor, their subprocessors, and any tool calls their gateway rewrites.

Managed hosting can be the right call when the workload is spiky, the data is not regulated, or you would rather pay margin than learn a second runtime. It is the wrong call when the answer to “where does the data live” has to be a specific country that the vendor cannot promise.

What actually crosses the wire

MCP messages are JSON-RPC 2.0 and must be UTF-8 encoded. In a Streamable HTTP binding, each request is an HTTP POST to a single endpoint. The protocol version and client capabilities travel inside _meta.io.modelcontextprotocol/* fields in the message body, and selected fields may be mirrored into HTTP headers for intermediaries to inspect.

For residency purposes, treat the following as data that may leave the region you control, unless you have engineered otherwise:

  • The full JSON-RPC request body, including prompt text and tool arguments.
  • The full JSON-RPC response body, including tool results and any resource payloads.
  • HTTP request metadata mirrored from the body, which can include identifiers the intermediary needs to route.
  • Standard HTTP headers such as Origin, which the server should validate, and any auth tokens you attach.

If your MCP server returns a “resource” that is a 40 MB CSV from a customer’s warehouse, that CSV is in the response body. Region choices that look fine for a chat prompt can quietly break once a tool starts returning large resources.

A founder-facing decision framework

Use this as a checklist before you sign a customer or pick a region.

  1. Classify the worst payload. What is the largest, most sensitive thing an MCP tool on your server could return? Customer PII, financial records, health data, internal source code, or only public docs?

  2. Map the trust boundary. For each tool, list every outbound call: the LLM provider, a database, a third-party SaaS API. Note the region each of those endpoints actually lives in. The residency of your workflow is the union of those regions, not the residency of the box your MCP server runs on.

  3. Pick the shape that matches the answer. If the customer demands data stay in a specific country, the only honest answer is self-hosted in that country, calling only providers that also operate in that country, with storage in that country. Managed hosting can stay on the table only if the vendor offers that country as a first-class region and will put it in the contract.

  4. Decide what the host application does. The MCP host is the AI app that opens the connection. If the host is a third-party SaaS, its region and its logging policy are part of your residency story, even if your server sits in the right place.

  5. Engineer the small things. Bind to localhost during development, validate the Origin header on every Streamable HTTP request, and put authentication in front of the endpoint. These are spec-recommended hardening steps and they reduce the chance that residency arguments are undermined by an exposed local port.

Trade-offs worth pricing in

Self-hosting in a specific region usually costs more than picking the cheapest region of a hyperscaler. Bandwidth, egress between availability zones, and the smaller menu of managed database regions can each add up. For a solo founder, the bill is rarely the binding constraint; the binding constraint is the number of environments you are willing to keep alive at 2 a.m.

Managed MCP hosting inverts the cost curve. You pay margin, you gain uptime and dashboards, and you lose the ability to answer residency questions with your own infrastructure. The honest question is whether the vendor’s standard contract and region list are good enough for the next twelve months of customers you plan to sign.

A common middle path is to keep the MCP server itself stateless and push all sensitive state into a regional database or object store. That way the region decision lives in one place (the storage account) and the server can be redeployed, scaled, or even moved to a managed host without changing the residency story.

Frequently asked questions

Does MCP require a specific region or encryption standard? No. The specification defines message format, transports and metadata. It does not require any particular region, encryption posture, or audit log. Those decisions belong to the operator.

If I self-host, does that automatically make my data “sovereign”? No. The data only stays where you think it does if the storage, the LLM provider, and any third-party tools you call also stay in that region. Self-hosting is a necessary step, not a sufficient one.

Is stdio safer than Streamable HTTP for residency? stdio keeps the data on the machine that launched the subprocess, which removes a network hop. It does not remove the question of which APIs the MCP server then calls. For a solo founder running locally, stdio is the simplest default. For a product other people use, you need a hosted transport.

Can a managed MCP host promise a region for me? Some can, and some publish a region list with contractual commitments. Treat that commitment as part of the vendor’s data processing addendum, not as a marketing page. If the region is critical, ask which subprocessor stores the message bodies and how long.

What is the smallest change that usually improves a residency story? Move all sensitive state behind a regional managed database or object store, and keep the MCP server stateless. That single change tends to make the residency story easier to explain than any number of architecture diagrams.

A short, opinionated checklist before you ship

  • Write down the worst payload your MCP server can return, in megabytes and in sensitivity.
  • Write down every outbound call your tools make, with the region of each endpoint.
  • Decide whether your customer contract requires data to stay in a named country. If yes, choose self-hosting in that country and pick a vendor list that respects it.
  • Bind to localhost in development, validate Origin in production, and require authentication on every endpoint.
  • Put the residency answer into your security and privacy page in one sentence. If you cannot, the architecture is not done.

Residency is a property of the whole workflow, not a flag you can flip in a config file. Pick the shape, pick the region, and write the sentence your customer will read.

Sources