Spanly Spanly
· Tim Quinteiro

EU AI Act traceability for MCP tool calls

If your MCP server is part of an AI system in scope of the EU AI Act, logging and traceability are not optional. A practical look at what that means for tool calls, and a checklist.

  • mcp
  • compliance
  • eu-ai-act

If your MCP server sits inside a product that European customers use, the EU AI Act is now part of your engineering reality, not just your legal team’s. The Act phases in obligations over several years, and a recurring theme across them is traceability: the ability to reconstruct what an AI system did and why. For an MCP server, the things that need to be traceable are tool calls. This is a practical look at what that means and how to get ahead of it.

A note before we start: this is engineering guidance, not legal advice. Whether and how the Act applies to your specific product is a question for your counsel. What we can speak to is the technical capability the Act keeps asking for, and how MCP monitoring provides it.

What the Act keeps asking for

Across the high-risk provisions, the same capability appears in different words: record-keeping and logging that let you reconstruct the operation of the system over its lifecycle. The Act expects automatic logging of events, retention of those logs for an appropriate period, and enough detail to support oversight and post-incident analysis.

Strip out the legal phrasing and you are left with a set of engineering requirements that should feel familiar:

  • Events are logged automatically, not on a developer’s good intentions.
  • Logs are detailed enough to reconstruct what happened.
  • Logs are retained for a defined period.
  • Access to those logs is controlled and auditable.
  • Data handling respects where it is allowed to live.

For an MCP server, “events” means tool calls, resource reads, and the sessions that tie them together. Those are the actions an AI system takes through your server, and they are exactly what needs to be reconstructable.

Mapping it to MCP tool calls

Tool calls are where the AI system does things. A traceability story for an MCP server has to cover them concretely:

What was called, and with what. The tool name and the arguments. A log that says “a tool was called” is not reconstructable. One that preserves the tool and its inputs is.

What came back. The response, or the error. Whether the call succeeded at the protocol level, not just the HTTP level.

Who and when. Which client, which session, and the timestamp. Client and session identity are what let you reconstruct a sequence of actions rather than isolated events.

Linked context. The ability to connect an MCP tool call back to the wider request in your own systems, so the trace is not an island.

If you can answer those for any tool call after the fact, you have the substance of what the traceability provisions are reaching for.

Retention, residency, and access

Three operational details turn “we log things” into “we can stand behind our logs.”

Retention. Logs need to survive long enough to be useful for oversight and investigation. Pick a retention period deliberately and make sure your tooling actually holds data that long. Spanly retains telemetry by plan: 30 days on Free, 90 days on Pro, and 12 months on Business, with custom retention for Enterprise.

Residency. For EU customers, where the data lives matters. Spanly runs two independent regions, US and EU, with separate storage and separate API endpoints. EU workspaces stay on EU-resident infrastructure, and data does not cross regions. The API key carries the region (spanly_eu_...), so the SDK routes correctly without extra configuration. This is the default architecture, not a bolt-on.

Access control. Logs that anyone can read or quietly alter do not support an audit. Workspace access is gated by SSO where configured, and every administrative action against a workspace is recorded in an audit log the owner can export. That export is often the artifact a reviewer actually wants to see.

A practical checklist

If you are getting ahead of this, here is the engineering checklist:

  1. Every tool call is logged automatically, with tool name, arguments, response or error, client, session, and timestamp. No manual instrumentation that can drift.
  2. Logs are retained for a defined, documented period that matches your obligations.
  3. EU customer data stays in the EU, with residency you can point to rather than promise.
  4. Access to the logs is gated and audited, with an exportable audit trail.
  5. MCP traces link back to your wider systems via trace context, so a reviewer can follow an action end to end.
  6. You can produce a record on demand for a given session or time window without an engineering project.

A drop-in SDK plus protocol-native monitoring gets you most of this without building a logging pipeline from scratch:

import { SpanlyClient } from '@spanly/sdk';

const spanly = new SpanlyClient({
  apiKey: process.env.SPANLY_API_KEY,
});

spanly.monitor(mcpServer);

Tool calls, sessions, and client identity are captured automatically from that point, in the region your key is scoped to.

Why this is worth doing now

The Act’s obligations land on a timeline, and the practical work of building reconstructable logging takes longer than the compliance memo suggests. Teams that wait until a requirement is immediate end up retrofitting traceability under deadline pressure, which is the worst time to discover that your logs do not actually contain what you need.

Putting protocol-level monitoring on your MCP server now means the traceability capability is already there when you need to demonstrate it, and in the meantime you get the operational benefit of actually being able to debug your server. The compliance posture is a byproduct of good observability, not a separate project.

Tim