Ever since the Sulu MCP Bundle was released, it has been possible to edit content in Sulu using an AI assistant. The documentation lists Claude.ai, Claude Code, Claude Cowork, ChatGPT and Codex as possible clients. It is still a release candidate; I have version 1.0.0-RC3 installed. Pages and articles can be edited with it, and events should not be left out. That is why the SuluEventBundle has also been given MCP tools.

One caveat straight away: I haven’t yet used the event tools in day-to-day work. This post therefore describes how they are built and why, rather than sharing practical experience.

What the Sulu MCP Bundle claims to offer

The MCP Bundle turns Sulu into an MCP server. AI assistants connect via HTTP and use the same processes as the admin. Four principles emerge from the documentation:

  • Every request runs as the logged-in Sulu user. Anything prohibited in the admin interface is also prohibited via MCP. There is no separate permissions layer.
  • Each tool specifies which permissions it requires. Tools that a role is not permitted to use are omitted from that role’s tool list.
  • Authentication is handled via OAuth 2.1. Sulu displays a consent page that lists the client and the requested permissions; only then is a token issued.
  • Tools with irreversible consequences are disabled by default: deleting, publishing, removing blocks and uploading media.

According to the documentation, in the default profile the AI can read everything and create drafts, but cannot publish, delete or reorganisation the page structure. Anyone wishing to do more must explicitly enable these functions in the configuration.

The six tools in the EventBundle

The EventBundle integrates into this system. It registers six tools, but only if the MCP Bundle is installed. Without it, nothing is loaded; the EventBundle remains independent.

  • sulu_event_list: Events for a language, page by page
  • sulu_event_get: an event with all fields
  • sulu_event_create: Create an event as a draft
  • sulu_event_update: Change the fields of an event
  • sulu_location_list: Locations with their IDs
  • sulu_location_create: Create a location

The permissions are the same as for events in the admin panel: ‘View’ for the lists, ‘Add’ for creation, ‘Edit’ for changes. Anyone who is not authorised to create events in the admin panel will not be able to see the tool. Creating and editing also appear in the activity log, just like any other action in the admin panel (more on this in the post Recycle Bin, Time Control and Activities).

Why 'Publish' is missing

An event created by an assistant is set to ‘Draft’ status. The description of the creation tool states that it is published in the admin panel. The edit tool describes one further step: if you use it to edit an event that has already been published, it reverts to ‘Draft’ and must be republished in the admin panel.

There is no dedicated publishing tool in the EventBundle. This is in line with the MCP Bundle, which disables publishing by default. A published event appears on the website, for example in lists and in the sitemap. The bundle leaves this step to the admin or the batch actions if several events are to be processed at once.

Give it a go

The MCP Bundle cannot be set up in two minutes. The installation requires an OAuth key pair, the league/oauth2-server-bundle, a database migration and a firewall, which must be positioned in front of the administrator’s firewall. The bundle’s documentation takes you through the process step by step and includes instructions for the clients mentioned.

Once that’s done, you don’t need to do anything else for the event tools. They are included with the bundle; descriptions of the individual tools can be found in the EventBundle documentation. I haven’t had a chance to try them out in practice yet.

The series begins with How the SuluEventBundle came about. Previously: The port of the SuluEventBundle to Sulu 3.

Repository: manuxi/SuluEventBundle on GitHub