Changes at "Mautic MCP: Exploring Practical AI-Assisted Workflows for Mautic"

• +Mautic MCP: Exploring Practical AI-Assisted Workflows for Mautic

• +

  Title:
  Mautic MCP: Exploring Practical AI-Assisted Workflows for Mautic

  Overview:

  Mautic MCP started from a practical question: how can AI assistants work with a running Mautic instance without giving them unrestricted access to application data or bypassing the permission model Mautic already has?

  The project explores that through a working Model Context Protocol implementation for Mautic.

  I did not want to start with autonomous actions, content generation, or broad database access. I wanted to start with development, testing, support, and debugging workflows where AI can already be useful by having better context.

  The current implementation allows an AI client to inspect selected contact and campaign information through a small, read-only, permission-aware toolset.

  This makes it possible to combine two types of context that are normally separate: the Mautic source code and the actual state of a running Mautic application.

  The project is in active development. The current focus is to understand which AI-assisted workflows are genuinely useful for Mautic, what information they require, and what safeguards should be in place before expanding the scope.

  Background and context

  AI-assisted development tools are becoming increasingly useful for understanding code, reviewing changes, and helping investigate problems.

  But when working with Mautic, source code is only part of the picture.

  A developer investigating an issue may also need to understand:
• +

• which contact is affected;

• +

• what happened on the contact timeline;

• +

• which campaign the contact entered;

• +

• how that campaign is configured;

• +

• which events are part of the campaign;

• +

• what the current authenticated user can see.

• +

An AI coding assistant typically doesn't have this application context.

The obvious alternatives are direct database access or broad API access. I didn't want to start there because it can give an agent much more information and authority than it needs.

Mautic already has models, services, APIs, and permissions that define how application data should be accessed. The project therefore works through those existing boundaries instead of creating another unrestricted path into the application.

Model Context Protocol provides the communication layer, while Mautic remains responsible for what is exposed.

Implementation

The project is implemented through the open-source Mautic MCP plugin.

The first phase focuses on read-only workflows around contacts and campaigns.

The currently available tools allow an AI client to:

• +

• search for contacts;

• +

• retrieve selected contact details;

• +

• inspect a contact timeline;

• +

• search for campaigns;

• +

• inspect campaign configuration.

• +

The implementation reuses Mautic's existing models, services, and permissions.

The basic flow is:

AI Client → MCP Tool → Application Service → Permission Check → Mautic Service/Model → Normalized Response

The AI client does not query Mautic entities or the database directly.

This was important for the project. The aim was not only to make Mautic data available to AI, but to understand what a controlled integration boundary could look like.

The current implementation is deliberately read-only.

There are no tools to create contacts, modify campaigns, send emails, publish content, or trigger campaign actions.

This limitation is intentional while we test the access model and real-world workflows.

Practical workflows

Support and debugging

When investigating why something happened to a contact, an AI assistant can retrieve the contact and inspect recent timeline activity.

Instead of manually copying information from Mautic into the conversation, the assistant can retrieve the relevant context itself, within the permissions of the connected Mautic user.

This can help with questions such as:

• +

• Why did this contact receive an email?

• +

• Which campaign activity happened before this event?

• +

• Which campaign is likely involved?

• +

• What should I inspect next?

• +

Campaign investigation

An AI assistant can search for a campaign and inspect its configuration and event structure.

This is useful when debugging campaign behavior because the assistant can compare the actual campaign configuration with the corresponding Mautic implementation.

AI-assisted development

A coding agent working on a Mautic issue normally understands the repository but has no direct understanding of the local application being used to reproduce the issue.

MCP lets you use both contexts together.

For example, the agent can inspect relevant application state and then continue investigating the implementation in the repository.

This reduces the gap between application debugging and code-level investigation.

Testing

The same approach can also support testing workflows.

An AI-assisted test session can inspect the resulting state of contacts, campaigns, and timelines after a test scenario instead of relying only on screenshots or manually copied values.

This is an area I am continuing to explore as the project develops.

Impact and results

The project is in active development, so I do not want to present it as a completed AI solution or claim adoption numbers that do not yet exist.

The main result so far is a working implementation that shows AI-assisted Mautic workflows do not require unrestricted access to Mautic.

The project has also helped turn broader AI questions into practical engineering questions.

For example:

• +

• Which Mautic permissions should apply to an AI tool?

• +

• What information does an agent actually need?

• +

• Should an MCP response contain an entire entity or only selected data?

• +

• How should viewown and similar permissions behave?

• +

• Which operations should remain read-only?

• +

• When should an action require additional confirmation?

• +

• How much application context is useful before it becomes unnecessary data exposure?

• +

These questions are easier to evaluate with a working implementation than through architectural discussion alone.

The current workflows also show that AI can be useful without immediately moving toward autonomous actions.

In many cases, giving an assistant the right diagnostic context is already useful.

Lessons learned

One of the main things I learned while building this is that connecting AI to Mautic is not the difficult part.

The more important question is what the AI should be allowed to see and do.

It is easy to expose a large API surface through MCP. I found it more useful to start with a small number of tools and require each one to have a clear purpose.

Another important point is that Mautic already has much of the foundation needed for controlled AI integration.

Its permission system, application services, and domain logic should remain the source of truth. AI integration should work through those boundaries rather than create shortcuts around them.

I also found that read-only AI workflows are useful on their own.

An AI integration does not always need to perform actions to provide value. Development, debugging, support, and analysis workflows can benefit simply from having the right context.

Using MCP also means the project does not need to be tied to one AI vendor or client. Mautic can define the tools and permissions, while compatible AI clients decide how to use them.

Future plans

The project is in active development.

The next step is to continue expanding the read-only context available to AI clients based on practical use cases.

Areas I am considering include:

• +

• segments;

• +

• emails;

• +

• campaign execution information;

• +

• configuration diagnostics;

• +

• additional contact context;

• +

• developer and test-oriented diagnostic tools.

• +

I also want to continue testing the project against real Mautic development, testing, and support scenarios before increasing the tool surface.

Write operations may come later, but only where there is a clear use case.

Before exposing actions that modify Mautic, the project needs to consider:

• +

• permissions;

• +

• confirmation;

• +

• auditability;

• +

• safe defaults;

• +

• limiting the scope of individual actions;

• +

• how AI-generated actions should be presented before execution.

• +

The project can also provide practical input into the wider Mautic AI Initiative by giving the community something concrete to review, test, and improve.

Community contributions

The complete implementation is open source under GPL-3.0.

I have also documented the architecture, AI client configuration, authentication, transport options, and practical examples so contributors can understand both how the plugin works and why certain decisions were made.

I see this as an important part of the project.

AI integration raises questions around permissions, privacy, security, and user control. I would rather explore those questions openly in the Mautic community than build an opaque integration tied to a specific provider.

The project is intended not only as a plugin, but also as a practical starting point for discussing how AI-assisted workflows should fit into Mautic.

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 the project to be published as a case study on mautic.org and included in the Mautic Pitch Deck.

+

+gid://app/Decidim::Hashtag/12/_MauticAwards