MCP server GDPR compliance

When GDPR applies to an MCP server

GDPR applies when personal data is processed. Personal data is any information relating to an identified or identifiable natural person. For MCP servers, ask this question about each tool: can the arguments or results of this tool be used to identify a specific living person?

The EU/EEA establishment of either the controller (typically your customer) or the data subjects (the people whose data is processed) is what makes GDPR applicable, not the location of the MCP server itself. A US-hosted MCP server processing EU customer data is within GDPR scope.

Data minimization in tool schema design

Article 5(1)(c) of GDPR requires that personal data be "adequate, relevant, and limited to what is necessary" — the data minimization principle. Applied to MCP tool design, this means accepting the least-identifying argument that still enables the tool to do its job:

# Excessive: accepts full customer record (includes name, email, address, payment info)
@mcp.tool()
async def update_customer_tier(customer: CustomerRecord, new_tier: str) -> str:
    """Update a customer's subscription tier."""
    # Only needs the ID and new tier — why accept the full record?
    return await _update_tier(customer.id, new_tier)

# Minimal: accepts only what's needed
@mcp.tool()
async def update_customer_tier(customer_id: str, new_tier: str) -> str:
    """Update a customer's subscription tier by ID."""
    return await _update_tier(customer_id, new_tier)

# The inputSchema difference matters:
# BAD:  {"properties": {"customer": {"type": "object", "properties": {"id": {}, "name": {}, "email": {}, ...}}}}
# GOOD: {"properties": {"customer_id": {"type": "string", "description": "Customer account ID (not email)"}}}

This matters beyond compliance: smaller tool arguments reduce token usage, make it easier to trace what data went where, and limit blast radius if a tool result is logged somewhere it shouldn't be.

Pseudonymization vs anonymization

GDPR treats pseudonymized data (customer_id instead of name/email) as personal data — it's still linkable to a person with the right lookup table. Anonymized data (aggregate stats, irreversibly de-identified) is not personal data. Prefer pseudonymization in tool arguments (use opaque IDs) and anonymization in tool outputs where the LLM doesn't need individual-level data.

Lawful basis for tool call processing

Every processing activity under GDPR requires one of six lawful bases. For MCP servers processing personal data, the most common bases are:

Maintain a Record of Processing Activities (RoPA) that lists each MCP tool that processes personal data, the categories of data processed, the lawful basis, and the retention period. This is a legal requirement for organisations with 250+ employees, and best practice for smaller teams in GDPR scope.

Conversation log retention and deletion

MCP tool calls are often logged as part of broader AI conversation logs (the full message history including tool arguments and results). Those logs contain personal data if any tool argument or result does. Retention obligations:

# Log schema with retention support

CREATE TABLE mcp_tool_call_logs (
    id INTEGER PRIMARY KEY,
    ts TEXT NOT NULL,          -- ISO 8601 timestamp
    user_id TEXT,              -- pseudonymous user identifier (not email)
    tool_name TEXT NOT NULL,
    arg_keys TEXT,             -- JSON array of argument key names (not values)
    result_category TEXT,      -- 'success' | 'error' | 'no_data'
    session_id TEXT,           -- links to conversation session
    delete_after TEXT          -- ISO date for scheduled deletion (e.g., ts + 90 days)
);

-- Scheduled deletion: run nightly
DELETE FROM mcp_tool_call_logs
WHERE delete_after IS NOT NULL
  AND date(delete_after) <= date('now');

-- Right to erasure: delete all logs for a specific user
DELETE FROM mcp_tool_call_logs
WHERE user_id = ? AND ts < datetime('now', '-1 day');
-- Note: keep a tombstone record (user_id hash, deletion_requested_at, fulfilled_at)
-- to prove erasure was performed

Log argument keys, not values. "arg_keys": ["customer_id", "new_tier"] gives you operational traceability without storing the actual customer identifier in the audit log. Your application already has the customer_id in the response — the log doesn't need it too.

Right to erasure (Article 17)

Data subjects can request deletion of their personal data. For MCP servers, this means you need to be able to find and delete all personal data linked to a specific individual across: conversation logs, tool call logs, cached tool results, and any derived data created from tool outputs.

async def fulfill_erasure_request(user_id: str) -> dict:
    """Process a GDPR right-to-erasure request for an MCP server user."""
    results = {}

    # 1. Delete conversation session data
    deleted_sessions = DB.execute(
        "DELETE FROM conversation_sessions WHERE user_id = ? RETURNING id",
        (user_id,)
    ).fetchall()
    results["sessions_deleted"] = len(deleted_sessions)

    # 2. Delete tool call logs
    DB.execute(
        "DELETE FROM mcp_tool_call_logs WHERE user_id = ?",
        (user_id,)
    )
    results["tool_call_logs_deleted"] = DB.rowcount

    # 3. Invalidate any cached tool results associated with this user
    await cache.delete_pattern(f"tool_result:*:user:{user_id}")
    results["cache_keys_invalidated"] = True

    # 4. Log the erasure (keep pseudonymous proof, not personal data)
    erasure_id = hashlib.sha256(user_id.encode()).hexdigest()[:16]
    DB.execute("""
        INSERT INTO erasure_log (pseudonymous_id, requested_at, fulfilled_at)
        VALUES (?, ?, ?)
    """, (erasure_id, datetime.now(timezone.utc).isoformat(),
          datetime.now(timezone.utc).isoformat()))
    DB.commit()

    results["erasure_log_id"] = erasure_id
    return results

The erasure log entry (pseudonymous ID + timestamps) is evidence that you fulfilled the request — keep it even after all the personal data is gone. GDPR requires you to be able to demonstrate compliance, and a bare deletion leaves no proof.

Data Processing Agreements (DPA)

If you operate an MCP server that other businesses use to process their customers' personal data, you are a data processor under GDPR (Article 28). Your customers are data controllers. This relationship requires a DPA — a contract that governs how you handle their data, what security measures you implement, and what happens if there's a breach.

Key DPA clauses for MCP server operators:

• Subject matter and duration: what tool calls you'll process and for how long
• Nature and purpose: what the MCP tools do and why the controller needs this processing
• Categories of data subjects: who the personal data relates to (customers, employees, etc.)
• Security measures: your specific technical controls (encryption in transit, access control, audit logging)
• Sub-processors: any service you use that also processes the data (your hosting provider, your own upstream MCP dependencies)
• Breach notification: you must notify the controller within 72 hours of discovering a personal data breach
• Deletion on termination: what you'll do with data when the customer ends the relationship

Most cloud hosting providers (AWS, Google Cloud, Azure, Fly.io, Railway) offer standard DPAs — sign them before deploying any MCP server that processes personal data. Your hosting provider is a sub-processor for the MCP server's processing activities.

Cross-border data transfers

Transferring personal data from the EU/EEA to a country without an EU adequacy decision (including the US, without a specific transfer mechanism) requires additional safeguards. For MCP servers, this matters when:

• An EU-based agent calls an MCP server hosted in the US that processes EU user data
• An MCP server in the EU sends tool call results to a US-hosted LLM API (OpenAI, Anthropic, etc.)
• EU data is logged to a US-based monitoring or analytics service

The primary transfer mechanisms are Standard Contractual Clauses (SCCs, included in most cloud provider DPAs), binding corporate rules (for intra-group transfers), or the EU–US Data Privacy Framework (for US entities certified under DPF). If you use OpenAI or Anthropic APIs and pass EU personal data in tool call results, check whether those APIs are covered by SCCs in your service agreement — most are, but verify.

AliveMCP's monitoring probes collect operational metadata (HTTP timestamps, status codes, latency measurements) — no tool arguments or results flow through the monitoring layer. The monitoring relationship doesn't involve personal data transfer, so no transfer mechanism is required for the monitoring activity itself.

Further reading

• MCP server SOC 2 — trust criteria, audit evidence, and compliance controls
• MCP server audit logging — structured event logs for compliance
• MCP server SAML SSO — enterprise single sign-on and user attribution
• MCP server security monitoring — detecting anomalies and access violations
• MCP server secrets management — credentials, rotation, and vault patterns
• MCP server structured logging — JSON logs for compliance and debugging
• AliveMCP — continuous protocol monitoring for MCP servers