When TYPO3 v14 was released as an LTS version on 21 April 2026, many had expected a big AI splash. The roadmap had announced a “GenAI toolbox”. What arrived was a tidied-up backend, Fluid 5 and a clear statement: there are no integrated AI or chatbot features in the core (Netresearch, 23 April 2026).
I think that was the right decision, and for a practical reason. A CMS does not need to do AI itself. It needs to be cleanly accessible from the outside, by the model you use today and by the one you will use in a year’s time. That is exactly what the Model Context Protocol is for. Over the past few months, the TYPO3 community has filled the gap with surprisingly good extensions.
At nextlevels, we mainly build Shopware shops and custom software. Many of our clients also run a corporate website on TYPO3. The question we have heard most often there since the summer: “Can’t Claude just maintain our pages?” It can. In this article, I’ll show you which extension to use, where the limits are and which rules you should set beforehand.
What MCP actually does in TYPO3
MCP is an open standard through which an AI assistant can call tools of another system. We described the basics in detail in the article MCP servers explained. For TYPO3, one picture is enough: the extension is the server, your AI tool is the MCP client, and in between sits a list of tools with clear descriptions.
A TYPO3 MCP server typically provides three things:
- Tools for taking action: reading the page tree, listing the content elements of a page, creating or changing records, uploading files, generating translations.
- Resources for understanding: the TCA schema of the tables, so that the model knows which fields a content element or a news record has.
- Prompts or skills: ready-made workflows such as “Translate page” or “Add meta descriptions”.
So the assistant does not see your database. It sees a toolbox controlled by the extension, and it acts with the permissions of the backend user the connection is bound to. That sentence will later decide your security, which is why we will come back to it.
The TYPO3 MCP extensions at a glance
As of October 2026, there is no official MCP solution for TYPO3, but there is a handful of serious extensions. They target two very different groups: editorial teams and developers.
| Extension | Provider | Target group | TYPO3 | Distinctive feature |
|---|---|---|---|---|
| hn/typo3-mcp-server | hauptsache.net | Editorial | 13.4 and later | All changes land in workspaces; OAuth for backend users; every push is tested with models from Anthropic, OpenAI, Mistral and Google |
| dirnbauer/typo3-mcp-server | dirnbauer (webconsulting) | Editorial | v14 focus | Further development of hn for v14, 52 tools, backend module with health checks |
| in2mcp | in2code | Editorial | 13.4 to 14 | Reading and creating content, alpha status |
| ms_mcp_server | Marek Skopal | Administration | 13.4 and 14 | CRUD on pages, content, files; OAuth 2.1 with PKCE and rate limiting |
| smart-extension-builder | mittwald | Development | n/a | Generates extension scaffolds with AI, locally via the CLI |
| typo3-dev-mcp | balatD | Development | 13.4 and 14 | Supplies TCA, schema, TypoScript and logs to Claude Code; read-only by default, alpha |
If you don’t want MCP at all but AI features directly in the backend, take a look at nr_llm by Netresearch: a provider-independent foundation for calling a large language model from within TYPO3.
For editorial teams, hn/typo3-mcp-server is currently the benchmark. What tips the balance is the security concept, which was built in from the start. More on that shortly.
Two worlds: editorial MCP and development MCP
The table already shows it: “TYPO3 + MCP” covers two fields of use with completely different risk. If you mix them in one project, you are building yourself a problem.
| Criterion | Editorial MCP | Development MCP |
|---|---|---|
| Who uses it | Editorial team, marketing, content team | Developers in their local environment |
| Typical client | Claude Desktop, ChatGPT, n8n | Claude Code, Cursor |
| Where it runs | On the production system, via HTTP and OAuth | Locally in DDEV, via stdio |
| What it may do | Read content and write it as a draft | Read schema, configuration and logs, generate code |
| Biggest risk | Wrong content goes live, prompt injection | Credentials or customer data end up in the model |
The development MCP is the more straightforward case. typo3-dev-mcp is read-only by default and runs in your DDEV environment. The model no longer has to guess TCA columns or content types; it reads them from the running instance. For agencies that maintain many TYPO3 projects, this is a noticeable productivity gain when upgrading to v14.
The editorial MCP is the more interesting case, because it sits on the production system and can write. That is what the rest of this article is about.
Why workspaces are the real lever
Compared with almost any other CMS, TYPO3 has a structural advantage for AI integrations: workspaces. A change in a workspace is a draft that only goes live after approval. The concept has existed for many years, and it fits surprisingly precisely with what you want from AI agents.
With hn/typo3-mcp-server, all content changes automatically land in a workspace. The assistant can create pages, rewrite texts and generate translations. Nobody sees any of it on the website until a human reviews and publishes the changes. This gives you human in the loop without separate approval software, simply because the CMS already knows the process.
The workflow looks like this:
- An editor gives Claude the task: “Add missing meta descriptions on all service pages.”
- Claude reads the page tree and content via the MCP server.
- Claude writes the new meta descriptions to the workspace.
- The editor checks the preview and the old-versus-new comparison in the TYPO3 backend.
- She publishes what works and discards the rest.
You should know three limits before you rely on it:
- Files are not versioned. An uploaded image lands in file storage immediately. It only becomes visible through a file reference, and that in turn is bound to the workspace. The extension also only uploads new files, never overwrites or deletes anything, and rejects executable files.
- Workspace selection is still missing. According to the project status, the extension uses the user’s first writable workspace. So give the AI user exactly one.
- Translations are experimental. The feature has been implemented but, according to the developers, has not yet been tested enough in real use. So check multilingual pages particularly carefully.
Use cases that already work today
Tasks that work best are those that affect many pages, can be described clearly and whose result a human can judge in seconds.
| Use case | Example task | Effort before | Maturity |
|---|---|---|---|
| SEO maintenance | “Add missing meta descriptions on all pages under /services.” | Hours per section | Good |
| Content audit | “Find all pages that still contain the old company name.” | Full-text search plus manual work | Good |
| Document import | “Turn this Word document into a news article.” | Copy and paste plus formatting | Good |
| Embedding media | “Embed this YouTube video on the home page.” | Several clicks in the backend | Good |
| Bulk change | “Add the new sustainability notice to all product pages.” | Page by page | Good, with spot checks |
| Translation | “Translate /about-us into German.” | Agency or DeepL plus entering it | Experimental |
Less suitable are tasks whose result is hard to check: a complete restructuring of the page tree, changes to legal texts such as the legal notice or privacy policy, anything involving prices and commitments. There, the review costs more time than the AI saves.
Security: five rules before you connect
An MCP server on the production system is a new, write-enabled access point to your website. Treat it as seriously as a new admin account. We always apply these five rules in our projects.
1. A dedicated backend user with minimal permissions. Create a user just for the AI, with its own group, limited page and file permissions and exactly one workspace. No admin, strictly following the principle of least privilege. Watch out for the local CLI variant of hn/typo3-mcp-server: according to the documentation, it runs with admin rights by default. So it is off limits for editorial work.
2. OAuth instead of static tokens. The serious extensions bind the connection to a backend user via OAuth. Access can then be revoked individually, for example via mcp:oauth revoke. A token that sits in a configuration file and never expires is an open door.
3. Publishing stays a human job. The AI user gets no permission to publish from the workspace. That is the only safeguard that still works when all the others fail.
4. Plan for prompt injection. A model that reads third-party content can be manipulated by that content. A doctored Word document or a web page whose content you have it import can contain hidden instructions (prompt injection). A second risk arises when other MCP servers are connected to the same AI client: their tool descriptions may have been tampered with. In the MCPTox benchmark with 20 language models, such an attack succeeded in 36.5% of cases on average (Cloud Security Alliance, July 2026). Workspaces, minimal permissions and an AI client connected only to trusted servers limit the damage.
5. Clarify data protection. Everything the assistant reads via MCP goes to the model provider. For a pure marketing website, that is usually not critical. If TYPO3 also holds form data, job applications or members’ areas, those tables do not belong in the AI user’s permissions. And for the model provider, you need a data processing agreement (DPA), with EU hosting if required.
Setup in 30 minutes: connecting TYPO3 to Claude
This is what the route with hn/typo3-mcp-server looks like. Try it on a staging instance first, not on the live system.
- Install the extension. Run
composer require hn/typo3-mcp-serverin the project directory. The workspaces extension is pulled in automatically as a dependency. TYPO3 13.4 or later is required. - Create the AI user. A new backend group “AI editorial” with read access to the relevant page tree, write access to the necessary tables and exactly one workspace. In it, a backend user without the admin flag and without publish rights.
- Get the server URL. Log in as the AI user and copy the server URL under [username] → MCP Server.
- Connect the client. In Claude, add the URL as a connector; in other clients, as a remote MCP server. The client redirects you to the TYPO3 login, where you authorise access via OAuth.
- Test read-only. First task without write access: “Show me the page tree under /services and which pages have no meta description.” If the result is right, the model understands your structure.
- Give the first write task and review it in the workspace. Only once you have gone through the whole workflow yourself does the team join in.
On TYPO3 v14, it is worth looking at dirnbauer’s v14 line, which builds on the same concept. Before using any of them, check the current compatibility in the repository, because all of these extensions are evolving quickly right now.
My assessment
TYPO3 is better positioned for AI integrations than the sober v14 release communication suggests. The core stays out of it, the community delivers, and with workspaces the system brings exactly the safety net that has to be built from scratch elsewhere. For comparison: with version 6.7.11.0 in June 2026, Shopware brought an MCP server directly into the core, initially as an experimental feature (Shopware release notes). Both approaches work. With TYPO3, you simply carry more responsibility for choosing the extension.
At the same time, the tools are young. Several extensions are in alpha, translations are experimental, and workspace selection is missing. If you start today, treat it as a pilot: one use case, one AI user, one workspace, one person who approves. After four weeks you will know whether the time savings hold up in everyday work.
The model is the interchangeable part. What matters is what surrounds it: permissions, approval, logging. More on why this applies to every agent is in my article Agent = harness + model.