When an employee connects a CRM to Claude over MCP and asks “summarise my open deals”, personal data about your customers moves from your system, through an AI client, into a model run by a third party, and back. Under the GDPR that is processing, it happened on your behalf, and you are the controller. Nobody signed anything.
This post walks through what the GDPR expects at each step of an MCP tool call and what a reasonable team does about it. It is not legal advice. It is the map your counsel will want you to have already drawn.
Who is who in an MCP call
The GDPR cares about roles. In a typical MCP setup there are at least four parties:
- You, the controller. Your employee, your customer data, your purpose.
- The MCP server operator. Often the vendor of the system that holds the data, who is already your processor under an existing agreement. Sometimes a third party or a community project that is not.
- The AI client vendor. Anthropic, OpenAI, Cursor. Processors, if you use them under business terms that say so.
- The model provider, which may or may not be the same as the client vendor.
Article 28 requires a contract with every processor. The question to ask for each MCP server is simple: is this operator covered by a data processing agreement we have? For a vendor’s official server it usually is. For a community wrapper found in a registry it almost never is, and connecting it means sending customer data to a party with no contract, no obligations and no sub-processor list.
Purpose limitation and data minimisation
Article 5 says personal data should be collected for specified purposes and limited to what is necessary. MCP servers are designed the opposite way: expose everything, let the model decide. A server with forty tools gives the model forty ways to pull records, most of them irrelevant to any given task.
The practical translation is per-tool, per-role rules. The support team’s AI can read the ticket it is working on; it cannot list all customers. That is data minimisation expressed as configuration, and it is also the control that makes every other obligation smaller. Data the model never fetched never needs a legal basis, a retention period, or a line in a breach notification.
Records of processing (Article 30)
You need to be able to describe what processing happens, for what purpose, involving which categories of data and recipients. With MCP, the recipients list changes every time someone connects a new server. If each employee manages their own connections, there is no record of processing at all, because nobody can list what is connected.
An allow-list of approved servers, each tagged with the data categories its tools touch, is a large part of your Article 30 record. The tool-call log is the evidence that the record matches reality.
Security of processing (Article 32)
“Appropriate technical and organisational measures” has become a concrete list for MCP:
- Servers vetted before connection, including a scan for injected instructions in tool descriptions.
- OAuth with minimal scopes rather than long-lived API keys pasted into config files.
- Tools that return individual records restricted by role; tools that send data outbound gated or blocked for clients that hold sensitive reads.
- Instant revocation when someone leaves. A grant that lives in a config file on a laptop is not revocable.
- A complete, attributable log of every call.
Response-side redaction is a reasonable addition. It is not a substitute for the list above, for reasons covered in the PII filtering post.
International transfers
Chapter V applies the moment a tool result crosses into a model hosted outside the EU. Most major providers now offer EU hosting options or rely on the EU-US Data Privacy Framework and standard contractual clauses. Check which applies to the tier you actually use. Consumer plans and business plans often differ, and the difference is exactly the clause you need.
The MCP server operator is a second transfer question. A community server hosted on a personal cloud account in an unknown region is a transfer with no mechanism at all.
Data subject rights
When a customer asks what you hold about them, or asks you to erase it, MCP has created new copies: in the model provider’s logs, in the client’s conversation history, in any system a write tool copied data into. You can only honour the request for copies you know about. Again this points at the log: if you can see every tool call that read or wrote a given record, you can find the copies.
Do you need a DPIA?
Article 35 requires a data protection impact assessment for processing likely to result in high risk, and supervisory authorities have listed “innovative use of technology” and large-scale processing of special categories as triggers. An AI agent with write access to a system holding health, financial or employee data is a reasonable candidate. The inventory, the per-tool rules and the log are most of what the assessment will ask for.
A practical sequence
- Inventory connected servers across all clients. Map each to an existing DPA or mark it uncovered.
- Disconnect uncovered servers that touch personal data, or get them covered.
- Restrict tools per role. Block bulk reads and outbound sends for AI clients that don’t need them.
- Route everything through one logged endpoint so Article 30 and Article 32 have evidence.
- Confirm hosting region and retention terms for the model and client tiers you use.
- Decide with counsel whether a DPIA is needed. You will already have the inputs.
The GDPR did not anticipate AI agents calling tools. It did anticipate controllers who cannot say what they process, for whom, or where it went. MCP without a chokepoint makes you that controller. With one, it is just processing you can describe.