DDEV is already implementing an MCP server (you don’t need to know the details).
For TYPO3 developers with an IDE like PhpStorm or VS Code and an AI setup like GitHub Codespaces or Claude Code, it means that the AI can get authoritative information about the status and configuration of all DDEV projects, without making inaccurate guesses how to get it.
In the current DDEV draft PR you can already ask things like
“Show me running DDEV projects and their URLs”
“Open the Mailpit URL of the t3v13 project”.
Our proposal is to extend that to provide TYPO3-specific support, so you could say things like
Experts have these commands in their fingertips, but not everyone does. Having AI + IDE access to TYPO3 project details lowers the barrier for casual contributors and makes onboarding faster and easier.
This project will provide these features to TYPO3 users in a DDEV release in Q4 2025:
Basic DDEV status and configuration information
Extended TYPO3 project status and configuration information
Execution of TYPO3-specific commands powered by tools like bin/typo3 and composer
Path to grow with project-level code additions as the community discovers more usage opportunities.
The key TYPO3 v14 goals that this aligns with are:
What is the advantage of implementing MCP over letting your agentic coding tool use the CLI?
It might be that a single instruction in your agent’s file, like “use the ddev command to control the dev environment,” might already achieve what you want.
I think the popularity of the MCP approach is that it tries to make the AI behave predictably and use just the one “official” MCP technique. As I use Claude Code, for example, I see it use a variety of go and git approaches. Most of them work, or claude adjusts when they don’t. But it seems to never settle on a single approach. GitHub came out with an Official MCP Server I assume for this reason. Any AI can search github… but they do it in unconstrained ways and sometimes with unpredictable results. So I guess the MCP approach is to constrain that and provide an “official” access point and technique.
With all due respect but what is the advantage of typing “Flush TYPO3 caches” instead of “ddev typo3 cache:flush”? I might be missing the point
And as you’re writing in the comment “it tries to make the AI behave predictably” well the LLMs hallucinate, massively. As a result of the way they have been trained. Using Claude Code intensively daily for months I could elaborate for hours especially about what is not working However MCP is not a solution around that. The latest paper published by Anthropic and OpenAI gives a massive insight about the reason for the hallucinations and that is something you just cannot catch setting up an MCP.
If you used Claude Code since August, then you likely stumbled over their infrastructure issues, that made Claude really unpredictable. That should not be a reference going forward. Cursor, Codex, opencode all exist and (can) use different models. However:
Another issue with TYPO3 is that there’s significantly less training data available on how to correctly build a content block, for example, compared to how to build a React component. This lack of reference material makes it easy for TYPO3 coding tasks to fail. This is an area that could be improved, the question is: How.
MCPs are currently a buzzword. In the end, you are able to inject additional tools into the context of a language model. You have to be quite creative to actually improve coding quality using that method.
Context7 is an interesting project that tries to provide LLM friendly documentation for most libraries. Even TYPO3 documentation works fairly well: TYPO3 Latest Documentation | Context7 | Context7 but it struggles to give documentation on how to clear cache with ddev, that is a connection that isn’t directly in the documentation.
However, as I stated in my first comment, just writing into the CLAUDE.md or AGENTS.md “- Use ddev typo3 to access the TYPO3 cli” is likely all that is needed to get the correct behaviour here.
What I would find interesting is to provide a default AGENTS.md in TYPO3 installations as a template (just like a README.md). That file is becoming a standard (https://agents.md) and that could contain hints on how to handle the current installation (including ddev). I’d bet that that could improve the setup experience greatly.
Since August? Way longer than that So I had massive unreliable experiences before, and even since. So that doesn’t come as a surprise. And if you check with other heavy users they will all acknowledge the same experience. Using an LLM as an extended helper can be a massive support and get you to your results faster but fully relying on it is simply not possible.
Your comparison to React flaws as it is way more widespread in the world as TYPO3 is. So of course there was way more training data available at the time when Anthropic feeded Claude. However - and I guess we both can agree on that - who can tell which of these tons of stack overflow or blog postings reflect “the best solution to your problem” or even best practices?
Context7 is just relying on official documentation, correct? First off I’d be interested to know how you could/would implement this in a real-life workflow using Claude Code in your IDE. Then: How would a pure documentation-based focus help to solve your engineering problem? I have strong doubts it will.
As of your bet improving setup experience greatly with an AGENTS.MD it also would be a question of what you’re trying to achieve. I would bet against it being a massive improvement for coding/code quality as the real problem lies way deeper and outside of our reach: It’s the way how LLMs have been trained in the first place. OpenAI and Anthropic released a paper recently that explains the problem: An LLM wasn’t just rewarded for saying “I don’t know”. And THAT is the key problem.
Sorry, it would be better to take AI debates elsewhere and not muddy up this proposal. This proposal is not about whether AI is good or bad, but about an experimental way to improve access for some users via DDEV and MCP.