JoomEngine!
Introducing JoomEngine MCP for Joomla: An Open Alpha for AI-Assisted Joomla Administration #1024
Llewellynvdm
started this conversation in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Over the past two days, I have been working with ChatGPT to develop something I believe could become a significant addition
to the Joomla ecosystem: a dedicated Model Context Protocol server for Joomla.
The project is called JoomEngine MCP for Joomla, and the repository is now available here:
https://github.com/joomengine/joomla-mcp
This project is still very new. It is firmly in the alpha stage, it has not yet been certified for production use, and there are undoubtedly areas where its behaviour still needs to be corrected, constrained, tested, and improved.
To put it plainly: it may still be a little trigger-happy.
Nevertheless, the project has already made tremendous progress, and I believe the time has come to invite the wider Joomla community to examine it, test it, question it, and help shape where it goes next.
What are we trying to build?
The objective is to create a structured and secure way for artificial intelligence agents to understand and administer Joomla through the Model Context Protocol, commonly known as MCP.
An MCP server provides an AI client with a defined collection of tools, resources, schemas, and operational boundaries. Instead of an AI agent guessing how a Joomla site works—or being given unrestricted access to HTTP endpoints, shell commands, PHP execution, SQL, or the filesystem—the MCP describes exactly which Joomla operations are available and exactly how they may be used.
The long-term goal is not merely to let an AI “connect” to Joomla.
The goal is to give an AI a reliable, discoverable, permission-aware understanding of Joomla administration.
That includes capabilities such as:
The intention is not to create a generic remote-control interface for Joomla. It is to create a semantic Joomla administration layer that an AI can understand and use responsibly.
Why TypeScript?
Joomla is a PHP application, and PHP remains the authoritative environment in which Joomla performs its domain validation, access control, events, persistence, and extension behaviour.
However, the current AI and MCP ecosystem has substantially stronger tooling and SDK support around TypeScript and Python.
I did not want to build a Python layer around a PHP project. TypeScript therefore became the more appropriate choice for the MCP-facing portion of the system.
This does not mean we are attempting to rewrite Joomla in TypeScript.
The TypeScript layer provides the MCP server, action catalogue, schemas, permission workflow, transport handling, audit boundaries, and integration contracts. Joomla itself remains the authority for Joomla behaviour.
Where Joomla provides a Web Services API route, the MCP can use that route.
Where a required capability is not adequately available through the Web Services API, the project includes a Joomla-native companion package. That companion works inside Joomla through fixed, schema-validated actions using Joomla’s own dependency injection, access checks, models, services, forms, and lifecycle events.
The companion does not provide arbitrary PHP, shell, SQL, filesystem, URL, model, method, or command execution.
That distinction is critical.
We do not want an AI to bypass Joomla. We want it to work through Joomla.
What has already been implemented?
The project has progressed considerably during its first days of development.
The current source-backed catalogue covers all 236 Joomla 6.1 core Web Services route templates identified by the project.
This includes 36 core CRUD resource families, covering areas such as:
The server can operate through two Joomla integration paths:
Joomla Web Services API
This provides remote HTTPS access through a dedicated Joomla API identity with only the permissions required for its enabled responsibilities.
Joomla-native companion
This provides local, fixed-action access through an installable Joomla console plugin. It is intended for operations that require Joomla-native models, services, effective ACL inspection, or capabilities not properly exposed through the remote API.
The project can run over standard MCP input and output or through authenticated Streamable HTTP. It is also structured as an embeddable TypeScript library, allowing other applications and services to integrate the Joomla MCP capabilities without launching the standard standalone process.
Deployment foundations are already included for Docker, OCI images, Docker Compose, and systemd-based operation.
The repository also contains extensive technical documentation covering architecture, security, deployment, clients, testing, live verification, API actions, the PHP companion, remote HTTP operation, troubleshooting, release management, and library integration.
Writes require more than tool access
One of the most important areas of this project is the handling of write operations.
It would be relatively easy to create an MCP tool that accepts an article title and body and immediately posts it to Joomla.
That is not sufficient for responsible administration.
A write-capable AI agent must operate through a controlled permission and confirmation process.
The current design allows an operator to grant permission for:
A typical write operation is intended to follow a process like this:
Permission does not override Joomla ACL.
It does not override the Joomla API user’s permissions.
It does not enable a disabled MCP toolset.
It does not override OAuth scopes.
It does not allow arbitrary execution.
This defence-in-depth approach is essential if AI-assisted Joomla administration is ever going to be trusted in real environments.
It is not production-ready yet
Although much has been implemented, it is important that we do not confuse implementation with proof.
The project deliberately distinguishes between actions that are:
At the time of writing, no complete action family has yet passed the full live success, denial, postcondition, cleanup, and recovery matrix required for production certification.
That means the repository must not yet be described as production-ready.
The current live testing infrastructure is developing rapidly. It can create disposable Joomla fixtures, install the companion package, generate temporary credentials, inspect available Joomla command contracts, exercise MCP transports, and retain redacted evidence when something fails.
However, far more live validation is required.
For example, when the MCP reports that an article was created, we need more than a successful HTTP status or a positive tool response. We need to independently confirm that the article exists in Joomla, appears through the relevant administrative and API views, contains the correct data, belongs to the expected category, has the correct state, and can be safely cleaned up afterward.
The same standard must be applied to users, menus, modules, banners, contacts, fields, extensions, configuration, maintenance actions, and every other supported family.
The repository’s coverage documentation is intended to remain the truth table for that process.
Where community assistance would be most valuable
This is where help from the Joomla community could make an enormous difference.
We need developers, site builders, extension developers, security reviewers, documentation contributors, testers, and technically curious Joomla users who are willing to examine the project critically.
Some particularly valuable contributions would include:
Testing against disposable Joomla installations
Run the MCP against test environments, never production sites, and report where the documented behaviour differs from what Joomla actually does.
Testing across Joomla 6.1, upcoming Joomla 6.2 compatibility, different PHP versions, MariaDB, MySQL, and PostgreSQL will be especially important.
Verifying real postconditions
Do not merely report that an action returned success.
Confirm that Joomla persisted the correct result, that the result is visible through the expected interfaces, and that the operation respected Joomla events, validation rules, access controls, and extension behaviour.
Testing least-privilege denial
A secure administrative system must prove both that authorised actions succeed and that unauthorised actions fail.
Testing with carefully restricted Joomla users and API identities will help verify that MCP permissions never bypass Joomla ACL.
Reviewing schemas and field contracts
The project contains reviewed field allowlists for mutation families, but many Joomla fields have complex version-specific requirements, nested structures, form rules, state transitions, and extension interactions.
People with deep knowledge of specific Joomla components can help make these contracts more accurate.
Reviewing the permission and security model
The write-planning, operator-grant, idempotency, locking, audit, OAuth, and transport boundaries need careful scrutiny.
Security findings should be reported privately according to the repository’s security policy rather than disclosed through a public issue.
Improving documentation and onboarding
The repository already contains substantial documentation, but new contributors are often the best people to identify what remains confusing.
Improvements to setup instructions, client configuration, examples, troubleshooting, diagrams, and terminology are very welcome.
Testing different AI clients
The project includes guidance for connecting clients such as ChatGPT, Codex, Claude, Gemini, and Grok.
Real-world testing will help us understand whether AI agents correctly discover Joomla capabilities, select appropriate actions, request permissions, respect denied operations, and verify their own results.
Reporting bad AI behaviour
If an agent chooses the wrong action, supplies invalid data, fails to request permission, misunderstands a Joomla response, or behaves too aggressively, that is valuable information.
This project is partly about making the MCP precise enough that an AI knows what it may do, what it may not do, and what it must verify before claiming success.
The path toward a Joomla Component Builder MCP
This Joomla MCP is also an important foundation for another objective that I believe will interest many people in our community.
Once the core Joomla integration is stable, tested, secure, and moving toward production readiness, we intend to extend the same approach to Joomla Component Builder.
The eventual goal is for an AI agent to understand and work with JCB through a structured MCP layer.
That could open the door to AI-assisted management of JCB projects, components, plugins, modules, libraries, powers, blueprints, configuration, compilation workflows, and related development processes.
However, it would be a mistake to build that advanced layer on top of an unreliable Joomla foundation.
The immediate priority is therefore to make the Joomla MCP trustworthy.
Once that foundation is sound, the JCB possibilities become extremely exciting.
An invitation to participate
This project is free and open-source software released under the GNU General Public License.
You are welcome to inspect the code, run the tests, challenge the architecture, improve the documentation, report defects, suggest better contracts, and contribute fixes.
The repository is here:
https://github.com/joomengine/joomla-mcp
Issues can be reported here:
https://github.com/joomengine/joomla-mcp/issues
Before contributing code, please review the contribution guidance:
https://github.com/joomengine/joomla-mcp/blob/main/CONTRIBUTING.md
The current implementation and production-readiness truth table can be found here:
https://github.com/joomengine/joomla-mcp/blob/main/docs/COVERAGE.md
Please remember that this is an alpha project.
Do not connect it to a production Joomla website without fully understanding its present limitations and safeguards. Use disposable environments, restricted credentials, least-privilege Joomla users, and carefully reviewed toolsets.
We are at the beginning of this journey.
What has emerged in only a few days already demonstrates that a structured, native-first, security-conscious Joomla MCP is possible. What remains is the serious work of testing every claim, closing every unsafe gap, improving agent behaviour, and proving that the system can operate reliably under real Joomla conditions.
That is work worth doing.
I am very interested to see where this leads us, and I would be grateful to hear what the wider Joomla community thinks.
Please take a look, test it responsibly, open an issue, contribute where you can, and help us build an MCP layer that Joomla developers and administrators can genuinely trust.
All reactions