RFC Number: XXXX
Status: Draft
**Created:** 2026-08-03
**Last Updated:** 2026-08-03
Initiator: Olivier Dobberkau, President TYPO3 Association
Responsible Body: TYPO3 Association Board
Target Version / Timeframe: Contract version 1.0 by Q1 2027, reference implementation alongside v14 LTS
The TYPO3 Association defines a binding interface contract for how TYPO3 presents itself over the Model Context Protocol. What is standardised are mappings, not products: how backend permissions map onto authorization, how workspaces and languages are carried in context, how TCA is served as a machine readable schema, which write path is permitted, and which operations must force a question back to a human. The contract is made verifiable through a conformance test suite. An official MCP server in the core is explicitly not proposed. Implementations remain extensions and remain in competition with each other.
At least two serious MCP implementations for TYPO3 already exist, notably from the hauptsache.net orbit and from Marek Skopal. Both are well built, and both answer the same foundational questions differently. One routes every change through workspaces, the other operates primarily in the live workspace. One inherits the permissions of the authenticated editor, the other offers an administrator mode as a convenient entry point. Both model context as implicit state established by a switch command.
For an early phase this is entirely reasonable. It becomes a problem the moment customers run these endpoints in production, and it becomes a governance problem the moment someone asks what actually counts as safe agent access to TYPO3. A CMS endpoint where a language model is allowed to write is a new attack surface. If every extension invents its own permission mapping, the Association cannot make any defensible statement about that attack surface in the context of the Cyber Resilience Act and NIS2. There is also a window of opportunity. The specification released on 28 July 2026 breaks with the previous model by removing sessions and the handshake and moving the protocol to stateless request and response semantics. State now belongs in explicit handles that the model can see. Dynamic Client Registration has been deprecated in favour of Client ID Metadata Documents. Every existing implementation has to migrate regardless. A contract written now costs the parties involved very little additional work. A contract written eighteen months from now costs rework.
The third reason is market perception. Whether a CMS is considered ready for AI is currently being judged, to a considerable extent, by whether it offers a usable MCP endpoint. TYPO3 has a structural argument here that few other systems can present as cleanly: permissions, versioning, workspaces, a single write path and a machine readable content model have existed for years. That substance should become visible as a standard rather than as an accidental property of individual extensions.
The contract standardises the mapping of TYPO3 core concepts onto MCP constructs and the security requirements that follow from it. It does not standardise the choice of a server, the internal architecture of an implementation, the choice of SDK, or functionality beyond the mandatory part. The key words MUST, SHOULD and MAY are to be read as described in RFC 2119.
Every MCP access MUST map to a backend identity. Anonymous or blanket privileged access is not permitted. Permissions derive exclusively from the rights of that identity, meaning page permissions, table permissions, field permissions, mount points and group membership. An implementation MUST NOT offer, as its default, an operating mode that bypasses this check. A development mode with elevated permissions MAY exist, but MUST be explicitly enabled and MUST be visibly marked as such in the backend.
New implementations SHOULD no longer offer Dynamic Client Registration and SHOULD support Client ID Metadata Documents instead. Validation of the issuer parameter per RFC 9207 before redeeming an authorization code is mandatory, as is binding client credentials to the issuer that minted them. Operation behind an external authorization server MUST be possible so that organisations can use their existing identity infrastructure. The mapping of scopes onto backend user groups is fixed by the contract. All mutating operations MUST go through the DataHandler. Direct database writes for content mutation are not permitted. This keeps hooks, versioning, workspace behaviour, history and the reference index intact, and it means an agent behaves no differently from an editor working in a form. An MCP server is a protocol adapter, not a second write path.
Site, language, workspace and the version of the interface contract MUST be carried in a signed context handle that a tool returns and that subsequent calls pass back as an argument. An implicit switch command, after which all following calls silently operate in a different context, is incompatible with the stateless protocol core and MUST NOT be used. The handle MUST be signed server side and bound to the identity of the caller.
The prefix typo3.
is reserved for the mandatory part of the contract. Extensions register their tools under their own prefix. The contract fixes names, arguments and return shapes for a small mandatory set, covering at minimum reading the page tree, reading a record, writing a record, search, listing workspaces and publishing. Everything beyond that is free.
The content model MUST be served as a resource under a uniform scheme and MUST NOT be decomposed into a large number of generated tools. TCA is the machine readable description of the editing surface that already exists. The contract defines which parts of it are served, how field permissions become visible within it, and how relations are represented.
Operations with irreversible or publicly visible effect MUST trigger a question back to the user through Multi Round-Trip Requests. This includes at minimum deleting records that carry existing references, publishing a workspace, flushing caches, and bulk operations above a configurable threshold. In these cases the server returns the open question and the client repeats the call with the answer attached. Human approval thereby becomes part of the protocol rather than a matter of hope.
Operations of indeterminate duration, such as indexing runs, reference index updates, upgrade wizards or bulk translations, SHOULD be modelled as tasks and polled through the tasks extension. The contract defines how tasks map onto the Scheduler or Messenger and how progress is reported.
Responses to list requests MUST carry cache hints. The cache scope MUST reflect dependency on the user group, since the tool catalogue is permission dependent. The contract fixes the binding to the TYPO3 Caching Framework and to cache tags, so that changes to the content model or to permissions trigger invalidation.
Every tool invocation MUST be logged, at minimum with identity, tool name, context handle, outcome and timestamp, and MUST be viewable in the backend. Without this requirement no defensible statement is possible under the Cyber Resilience Act or NIS2.
The contract is made verifiable through a test suite published as a package and executed against a running installation. Existing implementations can use it to test themselves. On this basis the Association issues a marker that becomes visible in the Extension Repository. The marker is not a quality judgement about the extension, it is a statement about conformance to the contract.
The contract is versioned and carries a deprecation window of at least twelve months, mirroring the practice of the protocol specification itself. The contract version is part of the context handle so that client and server are speaking about the same revision.
Community and Contributors:
Existing implementations will need to adapt, particularly in their context model and their authorization. Since the protocol revision forces a migration in any case, the additional effort is contained. The authors of the existing extensions SHOULD be involved as co-authors of the contract from the outset, not as recipients of a mandate. If this RFC reads as something handed down from above, it will fail regardless of its content.
Technical:
The contract itself is a document and a test suite. Optionally a thin contract library emerges, carrying interfaces, context handle signing and the permission mapping, which implementations can depend on. Whether that library belongs in the core or lives as a standalone package is left open and deliberately not decided in this RFC.
Financial:
The effort lies in drafting the document, building the test suite and commissioning a security review. A realistic order of magnitude is a mid five figure budget across two quarters, predominantly for the test suite and the review. The document itself is assumed to be covered by volunteer and board time.
Governance and Legal:
The contract gives the Association a defensible position on agent access to TYPO3 that can be cited in Cyber Resilience Act and NIS2 contexts. It simultaneously creates an expectation that the Association maintains that position. Whoever adopts the contract takes on an ongoing obligation.
An official MCP server in the core. This offers the greatest external clarity, but it would pull a fast moving integration layer into a core designed for stability and long maintenance cycles. The July 2026 protocol revision shows how quickly the ground moves. A core component under an LTS promise, built on a protocol that abandoned its notion of state within a year, is a maintenance commitment nobody wants to sign. It would also devalue two active community projects.
Declaring one existing extension official. Fast and cheap, but arbitrary, divisive and without a verifiable standard. It would replace the question of what is safe with the question of who arrived first.
Doing nothing. The market would settle the question by itself, most likely in favour of whichever implementation has the best visibility. That is not a bad outcome in itself, but the Association would lose the opportunity to set the security portion and would later have to give account without a standard of its own.
Where does the contract live organisationally, in the core, in a dedicated extension, or purely in the documentation, and which unit or team maintains it over time?
Should the security portion be signed off by the TYPO3 Security Team before the RFC enters the Final Comment Period?
How does the contract relate to the public, read only discovery surfaces, meaning llms.txt style signals and related approaches? Both describe the same installation for machines, one publicly and read only, the other authenticated and able to write. Shared terminology would be desirable.
Is part of this contract expressible across CMS boundaries and therefore a candidate for the Open Website Alliance? Permissions, approval and auditability are not TYPO3 specific problems. A shared core with system specific extensions would carry considerably more weight with regulators than a single vendor position.
How is the conformance marker granted and withdrawn, and who carries responsibility when a marked extension turns out to have a vulnerability?
Model Context Protocol, specification 2026-07-28, [https://modelcontextprotocol.io/specification/2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28)
Release announcement, [https://blog.modelcontextprotocol.io/posts/2026-07-28/](https://blog.modelcontextprotocol.io/posts/2026-07-28/)
RFC 9207, OAuth 2.0 Authorization Server Issuer Identification
RFC 2119, Key words for use in RFCs to Indicate Requirement Levels
hauptsacheNet/typo3-mcp-server
marekskopal/typo3-mcp-server
| Date | Event |
|---|---|
| 2026-08-03 | Draft created |
| Public Comment Period opened | | | Revision | | | Final Comment Period | | | Decision |
To be added during the Public Comment Period.
To be added after the Board decision.