Plugin of the Year 2026 — Mautic MCP

Title

Mautic MCP — Controlled AI Access to Mautic

Overview

Mautic MCP is an open-source plugin that adds Model Context Protocol (MCP) support to Mautic, allowing AI clients to work with Mautic through a small and controlled set of tools.

The idea behind the project was not simply to connect an AI agent to Mautic. The bigger question was how to do that without bypassing the permissions, application logic, and data boundaries Mautic already has.

So the first version is intentionally small and read-only. It provides tools for searching and inspecting contacts, contact timelines, and campaigns. Requests go through Mautic's existing services and permission checks, and the responses are normalized into predictable, AI-friendly data instead of exposing raw entities.

The current use cases are mainly around development, testing, support, and campaign debugging.

The goal is to first validate the architecture, permissions, and access model before expanding the toolset or considering write operations. This gives Mautic a practical way to explore AI-assisted workflows without starting with unrestricted access to the application.

Background and context

AI-assisted development is becoming a normal part of engineering workflows. Coding agents can already understand a repository reasonably well, but they usually know very little about what is actually happening inside a running Mautic instance.

When debugging a Mautic problem, the useful context is often application data:

• Which contact is affected?

• What happened on the contact timeline?

• Which campaign is involved?

• How is that campaign configured?

• What does the authenticated user actually have permission to see?

One option is to give an AI agent direct database or broad API access. I did not want to start there.

Mautic already has models, services, APIs, and a permission system that define how application data should be accessed. The MCP plugin therefore sits on top of those existing boundaries rather than creating another unrestricted path into the application.

That also makes the approach relevant beyond a single AI provider or client. MCP provides the protocol; Mautic continues to control what is exposed through it.

Implementation

The plugin is built for Mautic 7 and uses symfony/mcp-bundle for MCP transport and tool discovery.

The current version exposes five tools:

• search_contacts

• fetch_contact

• get_contact_timeline

• search_campaigns

• fetch_campaign

All of them are read-only.

They cannot create, update, delete, publish, trigger, send, or otherwise modify Mautic data.

I deliberately kept the MCP tool classes thin. The flow is roughly:

MCP Tool → Application Service → Permission Check → Mautic Model/Service → Normalizer → MCP Response

This means the MCP layer mainly deals with accepting input and returning a structured result. Mautic-specific logic, permissions, and data handling stay outside the tool itself.

• Permissions

  The plugin reuses Mautic's existing permissions rather than introducing a separate access model.

  For example, if the authenticated user can only view their own contacts or campaigns, the MCP search results are restricted accordingly.

  Connecting through MCP should not give an AI client more access than the same Mautic user already has.

  This also means a dedicated low-privilege account can be used instead of giving an agent administrator access.

• Response structure

  The plugin does not pass complete Doctrine entities or arbitrary database results back to the client.

  Each result is normalized into a defined structure containing the information useful for that particular tool.

  This keeps the responses predictable for AI clients and reduces the amount of unnecessary application data being exposed.

• Transport

  For local development, stdio is the preferred transport.

  This works well when a coding agent such as Codex is running alongside a local Mautic checkout.

  HTTP transport is also available when a shared or remote MCP endpoint is needed, but it is opt-in and uses Mautic's existing authentication stack.

The repository includes setup instructions for AI clients, architecture documentation, manual MCP examples, and some practical workflows.

Impact and results

The plugin is still an early-stage project, so I do not think it would be useful to claim adoption or usage numbers that do not exist yet.

The current value is in proving that Mautic can provide useful context to an AI agent without giving that agent unrestricted access to the application.

A few workflows already work well:

• Contact and support debugging

  If somebody reports unexpected campaign or email behavior, an agent can:

  • search for the contact;

  • inspect the contact details;

  • inspect recent timeline activity;

  • use that context to help investigate what happened.

  That avoids manually copying information between Mautic and the AI client.

• Campaign inspection
  An agent can search for a campaign and inspect its configuration, including its sources and event flow.

  For development or support work, this means the agent can combine what it sees in the Mautic codebase with what is actually configured in the running application.

• AI-assisted development

  A coding agent working on a Mautic issue normally has repository context but not application context.

  MCP allows the two to be combined in a controlled way.

  For me, that is the main result of this first version: showing that useful AI integration in Mautic can start with context and diagnostics rather than immediately giving an agent permission to take actions.

Lessons learned

One of the main things I learned while building this is that MCP itself is not the difficult part.

The more important questions are around what we expose through it.

For every tool, there are questions such as:

• Does the agent actually need this information?

• Which Mautic permission should control it?

• Should the complete entity be returned or only selected fields?

• Is the output predictable enough for an AI client to work with?

• What happens when the user has limited permissions?

• Is this operation safe enough to expose at all?

That is why the first version stayed deliberately small.

It would have been relatively easy to expose more of Mautic. I think it was more useful to first establish the permission model, response structure and architecture, then expand from there based on actual use cases.

The same applies to write operations. Being technically possible does not necessarily mean they should be exposed without additional controls.

Future plans

The plugin is under active development, and the next phase is focused on expanding the read-only toolset into other useful Mautic areas.

Possible areas include segments, emails, campaign execution information, and configuration diagnostics.

I also want to validate the plugin against more real development, testing and support scenarios before deciding which tools are genuinely useful.

Write operations may come later, but only where there is a clear use case and where permissions, confirmation and other safeguards can be handled properly.

Another area I want to explore is how this work can feed into the wider Mautic AI Initiative.

MCP is only one part of the AI discussion, but it provides a practical example of how we can connect AI systems to Mautic while keeping permissions, privacy and application boundaries in mind.

Because MCP is not tied to a single model provider, the same approach can also work with different compatible AI clients instead of building the integration specifically for one vendor.

Community contributions

The plugin is publicly available under GPL-3.0 so that the Mautic community can inspect and experiment with the approach.

Alongside the plugin code, I have documented:

• the architecture and reasoning behind the implementation;

• local and HTTP transport setup;

• AI client configuration;

• authentication;

• practical MCP request examples;

• development and support workflows;

• troubleshooting.

The project is also intended as something the community can review before the scope becomes larger.

Questions around AI access, permissions, and data exposure are easier to discuss when there is a working implementation to test rather than only an abstract proposal.

I expect some of the most useful outcomes from the project to come from that feedback and from identifying where AI-assisted workflows genuinely make working with Mautic easier.

Supporting materials

• Project repository
  https://github.com/shinde-rahul/plugin-mautic-mcp

• Architecture
  https://github.com/shinde-rahul/plugin-mautic-mcp/blob/main/docs/ARCHITECTURE.md

• AI client setup
  https://github.com/shinde-rahul/plugin-mautic-mcp/blob/main/docs/AI_CLIENT_SETUP.md

• Real-world examples and workflows
  https://github.com/shinde-rahul/plugin-mautic-mcp/blob/main/docs/REAL_WORLD_EXAMPLES.md

Inclusion as a Case Study

Yes. I am happy for this project to be included as a case study on mautic.org and in the Mautic Pitch Deck.

#MauticAwards