GPAI and the EU AI Act: what MCP server builders owe

GPAI here means general-purpose AI, not the Global Partnership on AI. In the EU AI Act it is a defined term with duties attached: Article 3(63) defines a general-purpose AI model, Article 3(66) defines a general-purpose AI system built on one, and Article 53(1) hangs four obligations on whoever places such a model on the Union market. If you build MCP servers, almost none of that is aimed at you. A tool server is not a model, and on a careful reading of Article 3(1) a plain tool server is not an AI system either. The provision most likely to reach you is Article 25(4), the value-chain rule for third parties who supply “tools, services, components, or processes” into a high-risk AI system, and since the AI Omnibus that rule carries its own fine.

Everything below cites the operative text of Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744, the Digital Omnibus on AI, rather than a summary of it, because the summaries in circulation are mostly written against the unamended 2024 text and several of their dates are now wrong.

What is GPAI?

Article 3(63) defines a general-purpose AI model as an AI model that “displays significant generality and is capable of competently performing a wide range of distinct tasks regardless of the way the model is placed on the market and that can be integrated into a variety of downstream systems or applications”, with a carve-out for “AI models that are used for research, development or prototyping activities before they are placed on the market”. Article 3(66) then defines a general-purpose AI system as an AI system based on such a model that “has the capability to serve a variety of purposes”. The model is the thing that gets trained; the system is the thing built around it.

What does the AI Act require of a GPAI provider?

Four duties land on providers of general-purpose AI models, under Article 53(1):

Article	Duty	Detail
53(1)(a)	Technical documentation of the model	Contents fixed by Annex XI, provided to the AI Office and national authorities on request
53(1)(b)	Downstream documentation	Information for providers who integrate the model, contents fixed by Annex XII
53(1)(c)	Copyright policy	Must identify and comply with rights reservations expressed under Article 4(3) of Directive (EU) 2019/790
53(1)(d)	Public training-content summary	”Sufficiently detailed summary about the content used for training”, to a template provided by the AI Office

An open-source carve-out in Article 53(2) drops points (a) and (b) for models “released under a free and open-source licence that allows for the access, usage, modification, and distribution of the model, and whose parameters, including the weights, the information on the model architecture, and the information on model usage, are made publicly available”. It does not touch the rest: the copyright policy and the training-content summary still apply to open-weights models, and the whole exception falls away for models with systemic risk. A companion post on the AI bill of materials takes up the 53(1)(d) template question, and finds that no regulation currently mandates an AI BOM by name.

If you publish MCP servers, you are not a GPAI provider unless you train and release a model. Shipping a server that calls someone else’s model does not put you here. It may put you under Article 3(68), which a later section takes up.

When does a GPAI model cross into systemic risk?

Under Article 51(2) a model “shall be presumed to have high impact capabilities” when its cumulative training compute is greater than 10²⁵ floating-point operations, a presumption the Commission can move by delegated act under 51(3), and Article 55 then stacks evaluation, risk-mitigation, incident-reporting and cybersecurity duties on top of Article 53. The GPAI Code of Practice of 10 July 2025 is the voluntary route through those duties: Articles 53(4) and 55(2) let providers rely on it, and anyone who does not must “demonstrate alternative adequate means of compliance for assessment by the Commission”.

What does the AI Act timeline actually look like after the AI Omnibus?

The dates live in Article 113: its second paragraph sets a general application date of 2 August 2026, and its third paragraph carves out exceptions. The Omnibus rewrote parts of that third paragraph and left the general date alone.

Adopted, in force, and citable:

Date	What
12 July 2024	Published in OJ L, 2024/1689
1 August 2024	AI Act enters into force
2 February 2025	Chapters I and II apply: prohibited practices (Art 5) and AI literacy (Art 4)
6 February 2025	Commission guidelines on the AI system definition
10 July 2025	GPAI Code of Practice published
18 July 2025	Commission guidelines on the scope of GPAI provider obligations
2 August 2025	GPAI obligations, governance and most of the penalties chapter apply, Art 113 third para (b)
24 July 2026	Digital Omnibus on AI published in OJ L, 2026/1744
27 July 2026	Omnibus enters into force, third day after publication
2 August 2026	General application date, including Article 50 transparency and Article 101
2 August 2027	Legacy GPAI models placed on the market before 2 August 2025 must comply, Art 111(3)
2 December 2027	Annex III high-risk systems, moved from the general date
2 August 2028	Annex I product-embedded high-risk systems, moved from 2 August 2027

The two postponements come from point (40) of Article 1 of the Omnibus, which replaces Article 113, third paragraph, point (c) with:

(c) Chapter III, Sections 1, 2, and 3, with the exception of Article 6(5), shall apply from: (i) 2 December 2027 as regards AI systems classified as high-risk pursuant to Article 6(2) and Annex III; and (ii) 2 August 2028 as regards AI systems classified as high-risk pursuant to Article 6(1) and Annex I

The same point also replaces point (a), delaying the newly inserted Article 5 prohibitions to 2 December 2026, and adds a new point (d) applying Articles 102 to 110 from 27 July 2026.

Is an MCP server an AI system at all under Article 3(1)?

Article 3(1) defines an AI system as:

a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments

The load-bearing word is infers. Recital 12 says so directly: the definition “should not cover systems that are based on the rules defined solely by natural persons to automatically execute operations”, and “a key characteristic of AI systems is their capability to infer”, which the recital explains as deriving models or algorithms from inputs or data. The Commission’s guidelines of 6 February 2025 exist to draw exactly this line.

Apply that to MCP and you get two answers.

A plain tool or resource server is not an AI system. A server that exposes read_file, query_orders or create_issue executes rules a person wrote, deterministically, against arguments it is handed. It has no capability to infer. It falls squarely inside the Recital 12 exclusion. The fact that its caller is a model does not transfer the model’s character to it, any more than a REST API becomes an AI system because a chatbot calls it.

A server that performs inference itself plausibly is. If a tool’s implementation calls a model, summarises with one, ranks with one or classifies with one, then that server does infer from the input it receives how to generate its output. The Article 3(1) elements start lining up. The same reasoning arguably reaches a server that drives MCP sampling, though sampling complicates it: in sampling, the server requests a completion and the client’s model produces it, so the inference happens on the other side of the wire. Whether that makes the server a system that infers, or a system that asks something else to infer, is not a question the Regulation contemplates.

Are you a provider, a deployer, a distributor, or none of them?

The AI Act assigns duties to roles, and the roles are defined narrowly.

• Provider, Article 3(3): develops an AI system or a GPAI model, or has one developed, “and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge”. Free of charge is expressly included, so a price of zero does not exempt anyone.
• Deployer, Article 3(4): uses an AI system under its authority, “except where the AI system is used in the course of a personal non-professional activity”. Running an agent at work makes you a deployer of that agent. Running one at home does not.
• Authorised representative, Article 3(5): someone in the Union holding a written mandate from a non-Union provider.
• Distributor, Article 3(7): in the supply chain, other than the provider or importer, and “makes an AI system available on the Union market”.
• Downstream provider, Article 3(68): a provider of an AI system, including a general-purpose AI system, “which integrates an AI model, regardless of whether the AI model is provided by themselves and vertically integrated or provided by another entity based on contractual relations”.

Provider, product manufacturer, deployer, authorised representative, importer and distributor roll up into operator under Article 3(8), which is the word the penalties provisions use.

The reach is set by Article 2(1), and it is deliberately extraterritorial. Point (a) catches providers placing AI systems or GPAI models on the Union market “irrespective of whether those providers are established or located within the Union or in a third country”. Point (c) catches providers and deployers established in a third country “where the output produced by the AI system is used in the Union”. Being incorporated in Delaware or Bengaluru is not a defence.

Working the roles through the common MCP cases:

What you do	Role
Publish a tool server to npm or PyPI	None, if it is not an AI system on the Article 3(1) reading above
Run a hosted MCP server that only wraps an API	None, on the same reading
Run an agent product that calls a third-party model	Provider of an AI system, and downstream provider under 3(68)
Use an agent internally at work	Deployer, Art 3(4)
Operate a registry or catalogue that lists other people’s servers	Not addressed by the Regulation, see the last section
Train and release a model	Provider of a GPAI model, Arts 53 and possibly 55

What applies when your MCP server feeds a high-risk AI system?

The value-chain rule sits in Article 25(4), which point (12)(b) of the Omnibus replaced. It now reads:

The provider of a high-risk AI system and the third party that supplies an AI system, AI model, tools, services, components, or processes that are used or integrated in a high-risk AI system shall, by written agreement, specify the necessary information, capabilities, technical access and other assistance based on the generally acknowledged state of the art, in order to enable the provider of the high-risk AI system to fully comply with the obligations set out in this Regulation. This paragraph shall not apply to third parties making accessible to the public tools, services, processes, or components, other than general-purpose AI models, under a free and open-source licence.

An MCP server is a “tool” or a “service” or a “component” on any ordinary reading of those words. So if a customer integrates your server into something that is high-risk under Article 6, that customer needs a written agreement with you covering information, capabilities and technical access.

The carve-out is narrow. Publish under a genuine free and open-source licence, make it publicly accessible, and 25(4) does not apply to you. Sell it, or ship it under a source-available licence that is not FOSS, and it does. Note also that the carve-out expressly excludes general-purpose AI models, so open-weights does not buy an exemption at the model layer the way it does at the tool layer.

The other half is Article 25(1), which can convert you into a provider without you doing anything model-shaped at all. Any distributor, importer, deployer or other third party “shall be considered to be a provider of a high-risk AI system” and picks up the full Article 16 obligations where they (a) put their name or trademark on a high-risk system already on the market, (b) make a substantial modification to a high-risk system that leaves it high-risk, or (c) modify the intended purpose of a system, “including a general-purpose AI system”, so that it becomes high-risk. Re-badging someone else’s agent product for your customers is (a). Point (c) catches you if you assemble general-purpose components into something with a specific, regulated purpose.

Your high-risk customer’s own duties sit in Article 26, and they determine what that customer will ask of you: technical and organisational measures to use the system per its instructions (26(1)), human oversight by competent people (26(2)), input-data relevance where they control it (26(4)), monitoring and suspension on risk (26(5)), and under Article 26(6) they must keep the logs the system generates automatically, to the extent those logs are under their control, “for a period appropriate to the intended purpose of the high-risk AI system, of at least six months”, a requirement on them that lands on your retention design.

Does Article 50 transparency reach tool calling?

Article 50 has applied since 2 August 2026. Chapter IV is not carved out of the amended third paragraph of Article 113, so the general application date is the one that governs it.

Three paragraphs matter:

• 50(1) requires providers to design systems intended to interact directly with natural persons so that people are told they are interacting with an AI system, “unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use”.
• 50(2) requires providers of systems, “including general-purpose AI systems”, that generate synthetic audio, image, video or text to mark the outputs “in a machine-readable format and detectable as artificially generated or manipulated”, with the technical solutions “effective, interoperable, robust and reliable as far as this is technically feasible”. It does not apply where the system performs an assistive function for standard editing, or does not substantially alter the deployer’s input data or its semantics.
• 50(4) puts disclosure on deployers: deep fakes must be disclosed as artificially generated or manipulated, and text published to inform the public on matters of public interest must be disclosed too.

The duty lands on the agent surface, not on the wire protocol. A user talking to a chat product is interacting directly with an AI system, so 50(1) bites on whoever provides that product. An MCP server answering a tools/call is not interacting with a natural person at all; its counterparty is a client. Nothing in Article 50 asks for a marker on a JSON-RPC response. If your server generates synthetic content that ends up in front of a person, the marking duty under 50(2) attaches to the provider of the system that generated it, which is a fact about your architecture rather than about MCP.

New Article 111(4) gives a transitional period: providers of systems generating synthetic content that were placed on the market before 2 August 2026 “shall take the necessary steps in order to comply with Article 50(2) by 2 December 2026”. And point (20) rewrote Article 50(7) so that the Commission may adopt an implementing act specifying common rules for marking and labelling if it judges the codes of practice inadequate.

What evidence would you have to produce?

At the model layer, Annexes XI and XII fix the contents of the technical documentation under Article 53(1)(a) and the downstream pack under 53(1)(b), down to architecture, training methodology, data provenance, compute and context window length.

At the system layer, Article 12 requires high-risk systems to allow automatic recording of events over their lifetime, sufficient to identify risk situations and substantial modifications, support post-market monitoring under Article 72, and support the human monitoring in Article 26(5). Article 25(2), as replaced by the Omnibus, says what handing over a component involves. Where someone else becomes the provider under 25(1), the initial provider must cooperate, and that obligation now expressly includes:

(a) making available of technical documentation sufficient to assess compliance with the requirements laid down in Article 16; (b) informing the new providers about known limitations and failure modes; and (c) providing the new providers with targeted technical access, including for testing and validation.

Read that list as a specification for what a well-run MCP server should be able to emit, whether or not the Regulation reaches you:

• Pinned, resolvable versions. “Which build was in the loop on 14 March” is unanswerable if your server is a floating latest tag. Version pinning is the cheapest item here.

• A tool manifest you can archive. Tool names, descriptions and JSON Schemas are the interface a model actually reasons over. Snapshot the tools/list output per release, and you have a durable record of what the system could do. Over stdio that is one line:

  echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' \
    | your-mcp-server > "tools-$(git rev-parse --short HEAD).json"

• A changelog of tool-description changes specifically. A description edit changes model behaviour without changing any code path, which is the mechanism behind tool poisoning. Tracking descriptions separately from code is what turns “known limitations and failure modes” from a paragraph into a diff.

• Build provenance. Signed attestations linking a published artefact to the source and builder that produced it. See build provenance for what that looks like per ecosystem.

• Logs shaped for six-month retention. If your customer needs Article 26(6) retention, decide now what your server emits per call and how long they can keep it without breaching data-protection law.

What are the EU AI Act penalties?

The tiers Member State authorities apply to operators sit in Article 99. Article 101 is a separate Commission route aimed only at GPAI model providers.

Provision	Ceiling	For what
Art 99(3)	EUR 35 000 000 or 7 % of total worldwide annual turnover, whichever is higher	Breach of the Article 5 prohibited practices
Art 99(4)	EUR 15 000 000 or 3 %, whichever is higher	Provider duties (Art 16), authorised representatives (22), importers (23), distributors (24), Article 25(2) and (4) since the Omnibus, deployers (26), notified bodies, and Article 50 transparency
Art 99(5)	EUR 7 500 000 or 1 %, whichever is higher	Supplying incorrect, incomplete or misleading information to notified bodies or national competent authorities
Art 99(6)	Whichever is lower	SMEs including start-ups, applied to paragraphs 3, 4 and 5
Art 99(6a)	Whichever is lower	Small mid-cap enterprises, inserted by the Omnibus, applied to paragraphs 4 and 5 only
Art 101(1)	EUR 15 000 000 or 3 % of annual total worldwide turnover, whichever is higher	Commission fines on GPAI model providers who intentionally or negligently infringe, or obstruct information requests, measures or model access

Article 101 applies from 2 August 2026, not 2 August 2025. Article 113, third paragraph, point (b) applies Chapter XII from 2 August 2025 “with the exception of Article 101”, and point (40) of the Omnibus did not touch point (b), so Article 101 falls back to the general application date in the second paragraph.

Who actually pays an AI Act fine?

Article 99(6) covers SMEs and start-ups and reaches all three fining paragraphs. The new 99(6a) covers small mid-cap enterprises, a category the Omnibus added to Article 3 as point (14b) by reference to Recommendation (EU) 2025/1099, and reaches paragraphs 4 and 5 only. A small mid-cap gets no relief on a prohibited-practices fine.

Fines attach to operators as defined in Article 3(8). Someone publishing a FOSS tool server under a real open-source licence is not an operator of anything and is not a GPAI provider. The exposure sits with whoever puts a product in front of users or into a high-risk deployment. If that is not you, most of Article 99 is not about you either.

What is still genuinely unsettled?

Four things.

Agentic systems are barely in the Regulation. The words “agentic AI” appear exactly once in the amended Regulation, in the new Annex XIV that the Omnibus added, where code AIH 0401 covers “AI systems based on other emerging AI technologies not covered by other codes, including Agentic AI”. That is an administrative code for notified-body designations. It creates no obligation. Beyond it, the operative text contains no rule about multi-tool orchestration, no definition of an agent, and no provision addressed to systems that plan and call tools in a loop.

Where a tool registry operator sits is unaddressed. Someone who runs a catalogue of other people’s MCP servers is not a provider (they developed nothing), not a deployer (they use nothing under their authority), and arguably not a distributor, since Article 3(7) speaks of making an AI system available and the listings are not AI systems on the reading above. The Regulation has no role for them. That may be correct, or it may be a gap that guidance eventually fills.

Whether a hosted MCP server that proxies a model makes you a downstream provider is open. A provider of an AI system that “integrates an AI model” is caught by Article 3(68), and a hosted server whose tools call a model does integrate one. Whether the wrapper is an AI system in its own right, or a component of the customer’s system, turns on the same definitional question, and it decides which side of 3(68) you land on. Nobody official has answered it.

There is no harmonised standard yet. Presumption of conformity runs through Article 40, and until CEN-CENELEC deliverables are cited in the Official Journal, the codes of practice under Articles 53(4), 55(2) and 56 are the only route to demonstrable compliance short of building your own evidence. The Omnibus added a subparagraph to Article 40(2) instructing the Commission to request those deliverables “without undue delay”, which is an acknowledgement that they are late.

Where to go next

• If you publish servers and want the evidence trail in place before anyone asks: build provenance and publishing cover pinned versions and signed attestations per ecosystem.
• If tool descriptions are the part that worried you: MCP prompt injection explains why the text a model reads is the control surface, and why a description diff deserves its own changelog.
• If you are deciding what your server should log: MCP observability covers what to emit, which is the question Article 26(6) asks from the other end.
• If you want to read the law rather than a reading of it: Regulation (EU) 2024/1689 and Regulation (EU) 2026/1744 are both free, both in English, and both shorter than the commentary about them.

The honest summary is that if you ship a plain MCP tool server, the EU AI Act mostly does not reach you today, and the one provision that plausibly does, Article 25(4), exempts genuine open source and now carries a fine for everyone else. Re-read it in a year. This post was written against the law as it stood on 1 September 2026 and is due for review on 1 February 2027.