AI, MCP and the Joomla Roadmap

This content was generated with the assistance of AI and should be verified against the official Joomla documentation before being relied on in production.

This sub-section’s Joomla bibliography lists the reference material consulted while preparing these pages.

Anyone asking "does Joomla have AI?" gets two honest answers. The first is about the product: no AI feature ships in Joomla core as of 6.2. There is no built-in assistant in the editor, no content generator, no model connection setting in Global Configuration and no MCP endpoint. The second is about direction: the project’s strategy wants Joomla to be "AI-ready", which means a foundation on which AI tools can work with the site rather than AI features bolted into the core, and two items on the 6.x roadmap, an MCP server and an AI framework, describe the first steps. This page separates what exists from what is planned, shows how to let an agent work with a site today through the Web Services API with the right safeguards, and points at the ecosystem for everything else.

This page was checked against the official sources on 2026-10-30 and written for Joomla 6.2.x (6.2.0 is the current release on the developer roadmap) and PHP 8.3 or later. The roadmap, features and strategy pages are living documents; re-read them before relying on anything described here as a plan.

What ships in core as of 6.2

Nothing AI-specific ships in core. The roadmap page for 6.2 lists a modular build script system, TinyMCE improvements, CSS class fields for images in articles, multi-level dropdown menus, a better view of module positions and an option to display subcategory images; none is an AI feature. The 6.2 announcement does not present an AI feature either. A Joomla site that offers AI today does so through an extension, an external service or a script that talks to the site from outside.

That is a deliberate position and not an omission. The Product Strategy states the goal as making Joomla AI-ready by building a foundation for AI tools to work with it, and names four components of that foundation: documentation written for machines, a framework layer, an improved web-service interface and MCP servers. The pieces that already exist, the Web Services API and its token authentication, are the starting point.

The roadmap items

Two items under the 6.x branch, in the "Increase Efficiency" theme of the list of planned features, concern AI. Both are plans, and the project states that roadmap dates are tentative.

Item	Status on the features page	What it describes
Build MCP servers to enable AI usage, with WCAG in mind	In Progress	MCP servers that let AI agents read resources and perform actions in a Joomla site under controlled permissions. The stated uses are generating categories, articles and menus from a sitemap or a PDF, writing SEO titles and meta descriptions in bulk, updating extensions across several sites and building landing pages for a product launch. The server is explicitly not meant to be limited to Super Users, and the goal is a lightweight tool that is easy to install.
Investigate if and how to integrate the AI Framework	In Planning	A framework that came out of a Google Summer of Code 2025 project, meant to let extension developers add AI features in a standard way through a provider abstraction layer that covers the basic interactions with AI providers. The roadmap item is an investigation of whether and how to integrate it, not a commitment to ship it.

Item

Status on the features page

What it describes

Build MCP servers to enable AI usage, with WCAG in mind

In Progress

MCP servers that let AI agents read resources and perform actions in a Joomla site under controlled permissions. The stated uses are generating categories, articles and menus from a sitemap or a PDF, writing SEO titles and meta descriptions in bulk, updating extensions across several sites and building landing pages for a product launch. The server is explicitly not meant to be limited to Super Users, and the goal is a lightweight tool that is easy to install.

Investigate if and how to integrate the AI Framework

In Planning

A framework that came out of a Google Summer of Code 2025 project, meant to let extension developers add AI features in a standard way through a provider abstraction layer that covers the basic interactions with AI providers. The roadmap item is an investigation of whether and how to integrate it, not a commitment to ship it.

The strategy page words the second item as "investigate if and how", and it describes the MCP item as planned with tentative dates, while the features page marks it In Progress. Read the two together: work has started, and nothing has been released.

What the MCP work looks like so far

A Joomla Community Magazine article from February 2026 reports the results of a January 2026 discovery sprint. It describes a proof of concept, not a release:

The server is meant to live inside Joomla core rather than run as a separate service, and it is written in PHP so that it adds no extra runtime dependency.
It exposes an HTTP endpoint that follows the MCP Streamable HTTP transport (see MCP transports for what that means on the wire).
The MCP tools, resources and prompts are implemented as Joomla plugins, so an extension can contribute its own abilities the way it contributes events today. A generic plugin that wraps existing web services for create, read, update and delete operations is planned.
The first authentication method is an MCP-specific token that an administrator creates in the backend for each client connection. A generic Joomla OAuth server with dedicated scopes for MCP and web services is described as a planned way to make connecting clients simpler.
The proof of concept has a backend screen for client connections and tokens, an endpoint that validates tokens and registers the abilities plugins provide, and a sample plugin that exposes system information as a resource and purges the cache as a tool. Initialise, ping, resource and tool calls were tested end to end.
Before production use the team lists cleanup of the backend, installation scripts and automated tests, plus a benchmark of the PHP MCP package in use and a possible switch to an official reference implementation.

The article does not describe how permissions will map to Joomla’s ACL, and it gives no version number for a release. Nothing in it should be read as a promise for a particular 6.x minor. The "with WCAG in mind" part of the title refers to the roadmap’s accessibility commitment: Joomla treats accessibility as a unique selling point that it intends to keep, and a separate roadmap item plans WCAG 2.2 AA compliance for the front end and the back end. Read it as a design constraint on the new screens and not as a feature that makes agents accessible.

For how an MCP server is built and secured in general, which is the design problem the Joomla team faces, the MCP section of this site covers the protocol, with architecture, tools, resources and prompts, authorization and security. For a comparison with a CMS where an MCP server module already exists as a beta-quality contributed project, see MCP Server and AI Agents in Drupal.

Contributing with AI: the Generative AI policy

Joomla publishes a Generative AI policy on the developer site for people who contribute to the project. It does not describe a feature of the CMS. It permits AI tools for research, suggestions, documentation and problem analysis, and puts the responsibility on the contributor, who must understand and validate everything submitted. Contributions must stay compatible with GPL version 2 or later, so AI output that reproduces proprietary code has to be removed or rewritten. Pull requests that were assisted by AI must be marked with an [AI] title prefix, an [AI Generated] label or both, and unreviewed bulk output ("vibe coding") may be closed. If you build pkg_tallpine with an assistant and plan to contribute a fix back, follow the same rules.

Third-party AI extensions

Because core has no AI layer, every AI feature on a Joomla site today comes from the ecosystem. The Joomla Extensions Directory (JED) at extensions.joomla.org is where such extensions are listed, and extensions that add AI features are published there by their vendors; the set changes constantly, so this page names none of them. Treat an AI extension like any other extension that holds secrets and edits content:

Check that it is listed on the JED, that it supports Joomla 6 and PHP 8.3, and how it is updated (see update servers and the JED). Check the Vulnerable Extensions List before installing, as for any extension.
Find out where the provider key is stored. A key typed into an extension’s options is saved in the database, so it ends up in every database backup, and anyone with core.admin or the extension’s options permission can read it. Prefer an extension that reads the key from an environment variable or a file outside the web root, and give the key its own spending cap at the provider.
Find out what data leaves the site. Article text, user comments and form submissions sent to an external model are personal data when they identify someone, and the site’s privacy policy and the privacy tools have to reflect that.
Treat generated text as a draft. An extension that publishes model output straight to a live article removes the editorial step; with the workflow feature enabled, generated content can be required to pass through the same stages as anything an Author writes.

The integration surface today: the Web Services API

An agent that needs to read or change a Tallpine site today does what any other client does: it calls the Web Services API at /api/index.php/v1, which speaks JSON:API, and the headless Joomla page describes the API and the Astro "trail map" that reads it. This page does not repeat that; it adds what matters when the caller is an AI agent. The Joomla Manual’s Web Services page documents the endpoint, the X-Joomla-Token header and the two requirements for the token’s account.

flowchart LR A[AI agent or MCP bridge] -->|HTTPS and token| W[Web Services API<br/>/api/index.php/v1] W --> T{Token plugin enabled?<br/>user in allowed group?} T -- no --> X[401 or 403] T -- yes --> P{ACL: core.login.api,<br/>core.create, core.edit ...} P -- denied --> X P -- allowed --> C[Joomla component<br/>articles, trails, categories] C --> D[(Database)]

Token authentication: what to know before handing a token to an agent

Reading the source of the token plugin in the 6.2 development branch (plugins/api-authentication/token) shows how the token is checked, which matters for deciding how much trust a token carries:

The plugin accepts the token as an Authorization: Bearer header first and falls back to X-Joomla-Token if there is no Bearer value. The Manual documents the X-Joomla-Token header.
The token is a base64 string of the form algorithm, user id and an HMAC. Only sha256 and sha512 are accepted. The HMAC is computed with the site’s secret from configuration.php, so changing the secret invalidates every issued token, and the comparison uses a timing-safe function.
The token is valid only if the user’s token is enabled in their profile, the HMAC matches and the user belongs to one of the groups in the plugin’s Allowed User Groups option. The default value of that option is the Super Users group, and an empty value allows all groups. A blocked user, a user with a pending activation or a user who must reset a password is refused.
On a fresh 6.2 installation the API token plugin is enabled and the Basic Auth plugin for the API is disabled, so the token is the only way in unless you change that. Leave Basic Auth off: it would put a password in an agent’s configuration.

The Joomla Manual says the account behind a token is either a Super User or an account that holds the core.login.api permission and core.login.site. The plugin’s group option, described above, is a separate check in the plugin, so a least-privilege account should be set up to satisfy both: its group has to be allowed in the plugin’s option and has to hold the login permissions in Global Configuration.

A least-privilege account for an agent

An agent given a Super User token can do everything a Super User can: install extensions, edit the plugin that authenticates it and read every user. Do not do that. Create a dedicated group instead, for example Trail Assistant, as a child of Author or Editor depending on the task, and give it only the permissions the job needs. Then create one user in that group per agent, so that the action log shows which agent did what.

# Steps in the Administrator, summarised; there is no CLI command for the group.
# 1. Users > Groups > New: "Trail Assistant", parent "Author".
# 2. System > Global Configuration > Permissions: for "Trail Assistant" allow
#    "Site Login" and "API Login" only.
# 3. Plugins > "API Authentication - Web Services Joomla Token": add "Trail Assistant"
#    to the Allowed User Groups option.
# 4. Users > New: "agent-trails", group "Trail Assistant". Open the user, switch to the
#    Joomla API Token tab and copy the token once, to a secrets store.

Source: Joomla Manual: Web Services

The plugin and option names above follow the 6.2 administrator screens; check them on your installation. Per-category and per-component rights then follow the normal rules described in users, groups, access levels and ACL and ACL in extensions: a group that may only create articles in Trails > Valley and cannot publish them can draft reports for an editor to approve and nothing more. Component web services check the ACL of the token’s account, which is why a custom component’s access.xml matters as much for an agent as for a person.

Reading and drafting with curl

The token comes from the environment and is never written into a script or a configuration file that is committed.

export TALLPINE_URL="https://tallpine.example.org"
# TALLPINE_API_TOKEN is exported from a secrets store, not written here.

# Read: the five latest published articles.
curl -sS "$TALLPINE_URL/api/index.php/v1/content/articles?page[limit]=5" \
  -H "Accept: application/vnd.api+json" \
  -H "X-Joomla-Token: $TALLPINE_API_TOKEN"

# Write: create an unpublished draft article in a category the account may use.
curl -sS -X POST "$TALLPINE_URL/api/index.php/v1/content/articles" \
  -H "Accept: application/vnd.api+json" \
  -H "Content-Type: application/json" \
  -H "X-Joomla-Token: $TALLPINE_API_TOKEN" \
  --data @draft-trail-report.json

{
  "title": "Valley loop closed for bridge repair",
  "alias": "valley-loop-closed",
  "catid": 12,
  "state": 0,
  "language": "*",
  "articletext": "<p>Draft prepared by an assistant, pending review.</p>"
}

Source: Joomla Manual: Web Services

Setting state to 0 creates an unpublished article; a group that lacks core.edit.state cannot publish, so even a mistaken request leaves the article invisible. The category ID 12 is an example and is different on every site. The custom trail entity of com_tallpine is reached the same way once plg_webservices_tallpine registers its routes (see extending the Web Services API).

Passing the token to an agent safely

A token in a prompt, a chat transcript or a repository ends up in logs and in model context. Keep it where only the process that needs it can read it. The Manual advises a password manager or secrets vault for the token. In a local Docker Compose test of an agent script the token can be passed as an environment variable that Compose reads from the shell, with the value never written into the file:

services:
  trail-agent:
    image: node:22-alpine
    working_dir: /app
    volumes:
      - ./agent:/app
    environment:
      TALLPINE_URL: "http://joomla:80"
      # Taken from the shell that runs "docker compose up"; no value is stored here.
      TALLPINE_API_TOKEN: "${TALLPINE_API_TOKEN:?set TALLPINE_API_TOKEN}"
    command: ["node", "agent.js"]

Source: Docker Docs: Set environment variables

See local development with Docker for the Joomla service itself.

Putting an MCP server in front of the API

An agent host such as Claude Desktop or Claude Code speaks MCP, not JSON:API. Until a Joomla MCP server is released, the practical bridge is a small MCP server that you write and run yourself, which turns a few chosen tools such as list_trail_reports and draft_trail_report into Web Services API calls with the agent’s token. The design rules from designing good MCP servers apply: expose a handful of narrow tools instead of a generic "call any URL" tool, and keep write tools limited to drafts. The same site documents how to build such a server in Node.js, Python and Spring Boot, and how a host connects to it in connecting hosts. Running it locally over STDIO keeps the token on the machine of the person using the agent; running it remotely brings in the authorization requirements covered in deploying remote servers.

Risks specific to agents

Prompt injection. Any text an agent reads from the site, such as a comment, a contact-form message or an article body written by a lower-privileged user, can contain instructions aimed at the model. An agent that can both read untrusted content and write content can be steered into doing something its operator did not intend. Keep read and write accounts separate where possible, and read MCP security for the attack classes.
Over-broad tokens. One token tied to a Super User is full control of the site. Prefer one narrow account per agent, as above, and revoke a token by disabling it in the user’s profile or blocking the user.
Rate and volume. The API has no built-in quota for an agent loop. Put a rate limit on the reverse proxy (see web server, reverse proxy and HTTPS) so a runaway loop cannot create thousands of drafts.
HTTPS only. A token sent over plain HTTP is readable by anyone on the path.
Backups. Take a backup before the first bulk run; Joomla has no core backup, so see backups and recovery.

Version notes

Joomla 6.2.x: no AI or MCP feature in core. Fresh installations enable the API token plugin and keep the Basic Auth API plugin disabled. A joomla.org server can trigger core updates, but that is the Automated Core Updates feature, covered in updating Joomla and automated core updates, and has nothing to do with AI.
6.x roadmap: the MCP server is described as in progress and the AI framework as in planning or under investigation. Neither has a release date. If either lands, the extension classes it needs will follow the patterns in plugin development and events and the dependency-injection setup in namespaces, autoloading and dependency injection.
The 7.0 removals that affect extension authors are in deprecations and preparing for Joomla 7; an AI extension you write now should already avoid them.

Corrections to older books

Neither of the Joomla books in the comparison covers the topic, because both predate the roadmap items. Developing Extensions for Joomla! 5 (2023) shows a Web Services plugin that extends CMSPlugin and registers routes with onBeforeApiRoute(&$router); current extensions use SubscriberInterface and the BeforeApiRouteEvent class, as described in extending the Web Services API. Joomla! 4 Masterclass (2023) targets Joomla 4, which reached end of life in October 2025,. Neither book can be used for the AI and MCP roadmap; the sources below are the reference.