For EU companies needing GDPR compliance, running MCP servers with self-hosted models keeps all data in your infrastructure. Zero third-party data transfers. No Data Processing Agreements to negotiate. No cross-border transfer headaches. This is the gold standard for privacy-conscious AI tool integration.

Why MCP + self-hosted matters for GDPR

GDPR compliance with AI tools typically involves a painful chain of requirements: Data Processing Agreements with every AI provider, Standard Contractual Clauses for cross-border transfers, Data Protection Impact Assessments, and ongoing monitoring of how providers handle your data. Every API call to OpenAI, Anthropic, or Google is a data transfer that needs legal justification.

Self-hosting eliminates all of this. When your LLM runs on your own infrastructure and your MCP servers connect only to your own databases and tools, there are no third-party processors. No data leaves your network. The entire GDPR compliance surface shrinks dramatically.

MCP (Model Context Protocol) makes this practical by providing a standardized way to connect your self-hosted LLM to your internal tools — databases, file systems, APIs, documentation — without building custom integrations for each one. Learn the fundamentals in our MCP complete developer guide.

The architecture

Here’s how the pieces fit together:

┌─────────────────────────────────────────────────────┐
│                  YOUR NETWORK                        │
│                                                      │
│  Developer's IDE                                     │
│       │                                              │
│       ▼                                              │
│  AI Coding Tool (Aider/OpenCode/Continue.dev)        │
│       │                                              │
│       ▼                                              │
│  Self-hosted LLM (Ollama)  ◄──── MCP Client          │
│       │                            │                 │
│       │                    ┌───────┴────────┐        │
│       │                    │                │        │
│       ▼                    ▼                ▼        │
│  Response to dev     MCP Server:       MCP Server:   │
│                      PostgreSQL DB     Git repos     │
│                                                      │
│  ════════════════════════════════════════════════     │
│  Nothing crosses this boundary                       │
└─────────────────────────────────────────────────────┘

Every component runs on your infrastructure. The LLM processes prompts locally. MCP servers access your internal tools via stdio transport (no HTTP exposure). Responses go directly back to the developer. At no point does any data leave your network.

Step-by-step setup guide

Step 1: Set up the self-hosted LLM

Install Ollama and pull a capable model:

# Install Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Pull a strong coding model
ollama pull devstral-small:24b

# Or for less powerful hardware
ollama pull qwen3.5:9b

Verify it’s running:

ollama list
curl http://localhost:11434/api/tags

See our Mistral local guide for model selection advice or the full Ollama guide for configuration options.

Step 2: Configure MCP servers locally

MCP servers connect your LLM to internal tools. Use stdio transport — this means the MCP server runs as a child process of the AI tool, communicating through standard input/output. No network ports, no HTTP endpoints, no attack surface.

Example: connecting to your PostgreSQL database:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://user:pass@localhost:5432/mydb"
      }
    },
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/project"]
    },
    "git": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-git", "--repository", "/path/to/repo"]
    }
  }
}

Step 3: Connect your AI coding tool

Configure your AI coding tool to use the local Ollama instance instead of a cloud API:

Aider:

aider --model ollama/devstral-small:24b

OpenCode:

# opencode.yml
provider: ollama
model: devstral-small:24b
base_url: http://localhost:11434

Continue.dev:

{
  "models": [{
    "title": "Local Devstral",
    "provider": "ollama",
    "model": "devstral-small:24b"
  }]
}

Step 4: Verify no external connections

Confirm nothing is phoning home:

# Monitor network connections during an AI session
sudo lsof -i -P | grep -E "ollama|node" | grep -v "localhost"

# Should return empty — no external connections

If you see any external connections, check for telemetry settings in your AI tool and disable them.

Which MCP servers work locally

Not all MCP servers are suitable for a fully local setup. Some connect to cloud services by design. Here are the ones that work entirely on your infrastructure:

Fully local MCP servers:

• @modelcontextprotocol/server-filesystem — file system access
• @modelcontextprotocol/server-postgres — PostgreSQL (local instance)
• @modelcontextprotocol/server-sqlite — SQLite databases
• @modelcontextprotocol/server-git — Git repositories
• @modelcontextprotocol/server-memory — in-memory knowledge graph
• Custom servers you build yourself (see our TypeScript MCP guide)

Servers that connect externally (avoid for GDPR):

• GitHub MCP server (connects to github.com)
• Slack MCP server (connects to Slack API)
• Any server that calls cloud APIs

For external services you need to access, build a local proxy MCP server that caches data on your infrastructure and only syncs on a controlled schedule.

GDPR compliance benefits

Running this architecture gives you concrete compliance advantages:

No third-party processors: Since no data leaves your infrastructure, you don’t need Data Processing Agreements for AI processing. Your existing data governance covers everything.

No cross-border transfers: All processing happens in your data center or office. No Standard Contractual Clauses needed. No adequacy decisions to worry about. No Schrems II complications.

Simplified DPIAs: Your Data Protection Impact Assessment for AI tools becomes much simpler. The risk profile of “all data stays on our network” is fundamentally different from “data is sent to a US-based AI provider.”

Full data control: You can delete, modify, or audit any data at any time. No need to submit deletion requests to third-party providers and hope they comply.

Article 25 compliance: GDPR’s “data protection by design and by default” is satisfied by an architecture that physically prevents data from leaving your control.

Trade-offs and honest assessment

This setup isn’t free. Here’s what you’re giving up:

Model quality: Self-hosted models (even the best 24-27B models) are roughly 80-90% as capable as frontier cloud models like Claude Opus or GPT-4.5. For most coding tasks, this gap is acceptable. For complex reasoning or very large codebases, you’ll notice the difference.

Hardware costs: You need capable hardware. A Mac Mini M4 with 32GB RAM ($1,150) runs 27B models well. For a team, a Mac Studio or dedicated server with 64-192GB RAM is needed. See our self-hosted AI guide for hardware recommendations.

Maintenance: You’re responsible for model updates, server maintenance, and security patches. Cloud providers handle this for you.

No frontier features: Cloud AI providers ship new capabilities weekly. Self-hosted models update on a slower cycle.

For many EU organizations, especially those handling sensitive data (healthcare, finance, legal, government), these trade-offs are well worth the compliance simplicity and data sovereignty.

FAQ

Is MCP GDPR compliant?

MCP itself is a protocol — it’s neither compliant nor non-compliant, just like HTTP isn’t inherently GDPR compliant or non-compliant. What matters is how you deploy it. MCP servers running locally with a self-hosted LLM keep all data on your infrastructure, making GDPR compliance straightforward. MCP servers connecting to cloud services involve third-party data transfers that need the usual GDPR safeguards (DPAs, SCCs, etc.). The protocol gives you the flexibility to choose either approach.

Can I run MCP servers locally?

Yes, and it’s the recommended approach for GDPR compliance. MCP servers using stdio transport run as local processes — they communicate through standard input/output with no network exposure. You can run filesystem, database, Git, and custom MCP servers entirely on your local machine or internal network. The key is choosing servers that don’t connect to external cloud services and using stdio transport instead of HTTP/SSE transport.

Does self-hosted MCP avoid data transfers?

Yes, completely — when configured correctly. With a self-hosted LLM (like Ollama) and local MCP servers using stdio transport, zero data leaves your network. The LLM processes prompts locally, MCP servers access local resources, and responses are generated entirely on your infrastructure. This eliminates the need for cross-border transfer mechanisms (SCCs, adequacy decisions) and third-party Data Processing Agreements. Verify this by monitoring network connections during operation as shown in the setup guide above.

Related: MCP Complete Developer Guide · Self-Hosted AI for GDPR · Ollama Complete Guide · AI and GDPR