MCP for Events Booking - Run events and registrations from your AI client

Written by: Tim Davis Created: 18 September 2026

Category: Extensions

New!Hits: 336Reading time: 00:28

MCP for Events Booking is a Pro add-on for MCP for J that puts your Events Booking site in front of your AI client. Thirty-eight tools cover events, registrants, capacity and revenue reporting, check-in, targeted configuration writes and a health audit, so you can ask which events are nearly full or who's on a waiting list and get an answer instead of a spreadsheet. The one tool that isn't a convenience is the mailing: Events Booking's own Mass Mail structurally cannot deduplicate across events, so a person registered to ten of your events receives every mailing ten times. This add-on can mail that audience once. Events Booking itself is a separate commercial product you buy from JoomDonation.

Why this exists

Events Booking's Mass Mail sends to one event at a time. That's not a setting — the send routine takes a single event id and scopes its recipient query to it, and the form it's driven from offers no category filter, no date range and no way to pick more than one event. There's a configuration option called "prevent duplicate mass mail" that looks like it should solve the obvious consequence, and it can't: the list of already-mailed addresses it keeps is created fresh inside each send and thrown away at the end of it. It can stop one person being mailed twice for one event. It has no way to know what the previous event's send already did. So if you mail a year's worth of events, somebody who came to ten of them gets your message ten times, and the flag is working exactly as written.

The fix was sitting in the component already, in two halves that had never been introduced. Events Booking's registrant list model genuinely spans events — it filters by category, by date range, by status and by ticket type. Its batch mailer takes an explicit list of registrant ids and is entirely event-agnostic. Both halves are the vendor's; this add-on supplies the join, collapsing the cross-event list to one row per email address and handing those winners to the batch mailer. The rest of the tool set is the ordinary event and registrant work you'd expect, plus reports the component doesn't offer.

What Claude can do

Thirty-eight tools, grouped roughly the way you'd reach for them.

Tool names use Events Booking's own eb_ table prefix rather than this add-on's name — list_eb_registrants, get_eb_event_capacity — because that's what reads naturally to somebody who already knows what's in #__eb_registrants.

Installing it

You'll need Joomla 5 or 6, PHP 8.2 or later, MCP for J, a Cybersalt Pro membership, and Events Booking itself — which is a separate commercial product you buy from JoomDonation. Without Events Booking installed, every tool in this add-on refuses. Events Booking has no free edition, so there's no vendor feature gate here to work around and nothing in the component is locked away from these tools.

1. Subscribe above, or get this and every other Pro add-on with MCP for J Pro — All Access.
2. Download the ZIP and install it through System → Install → Extensions, or paste your download URL into Install from URL.
3. That's the whole install. The plugin enables itself, and the tools show up in your connected AI client the next time it lists them.

There's no admin screen for this plugin, by design — it adds tools to MCP for J rather than a place to click. If you go hunting for a menu entry after installing, that's why there isn't one.

Using it

Ask for what you want in plain language. "Which of next month's events are more than eighty percent full?" runs the capacity report. "Who's on the waiting list for the October retreat?" answers from one call. "Check in Sarah Whitfield for tonight" finds the registrant and marks them in.

The mailing flow is deliberately three steps rather than one, and the first one is the useful one. Start with "How many duplicate emails would a mailing to everyone who registered this year actually send?" That runs the audit, which touches nothing and sends nothing. It tells you how many messages Events Booking's own Mass Mail would send, how many a deduplicated send would, and — the part people tend to stare at — which specific people would have received how many copies. On a site that runs a lot of events with a loyal audience, that number is usually worse than expected.

The mailing tool has more rails on it than anything else in this suite

Read this part before you use it. Mail is the one thing here that can do damage you can't take back, so the send tool is built to be hard to fire by accident.

It previews by default. The dry-run flag is on unless you turn it off, and turning it off isn't enough on its own — you have to pass an explicit confirmation alongside it. A preview costs nothing and tells you the whole recipient list, so there's no reason to skip it.

It sends in chunks with a cursor you can see. Events Booking's own Mass Mail loops the entire recipient set inside one synchronous request, with no batching, no queue, no resume and without raising the PHP time limit — which is why large sends on that screen die halfway with no way to tell what got out. This add-on doesn't inherit that. It sends a chunk at a time and hands back a position.

A failure mid-send says so plainly rather than looking clean. The vendor's batch mailer has no transaction and reports no progress, so if a chunk fails there's genuinely no way to know from the return value how far it got. The tool tells you that in those words and tells you to check the email log for the subject line before retrying, because retrying blind is how somebody gets the message twice.

And only one registrant id per distinct email address ever reaches the vendor's mailer, which is the entire point — that mailer has no deduplication of any kind and doesn't even consult the component's own duplicate-prevention setting.

Saves that delete what you did not send

Most of the write tools here exist to avoid a destructive default rather than to add a feature.

Saving an event through Events Booking's own routine rebuilds its category assignments from whatever it was handed, so a save that omits them drops the event out of every category view. It does the same to group pricing. It appends a time string to the event date unconditionally, so omitting the date doesn't leave the date alone — it produces a malformed value the database quietly stores as a zero date. And it decides whether it's creating or updating from internal state rather than from the id you passed, so a straightforward save with an id in it can be treated as a brand-new record and overwrite the row with defaults.

Registrants have their own version. Saving one deletes every custom-field answer and re-inserts from the payload, blanking anything absent, so the update tool reads them all back first — decrypting the encrypted ones so they don't get encrypted twice, and converting date answers into the site's own format so they don't fail to parse and land empty. Group-billing registrations on events that collect member details are refused outright, because there's no partial save of that shape that doesn't blank somebody's name.

The configuration is the same story with a bigger blast radius: Events Booking's configuration save empties the entire settings table and re-inserts only what it was given. There's no merge path in the component at all, and the admin screen only survives it because the form posts every field it rendered. So the configuration tool here never calls that routine. It updates the keys you named and leaves the rest alone.

Deletes are guarded for a different reason. Deleting an event doesn't cascade to its registrants, and deleting a group-billing registration silently takes every member of that group with it. Events Booking has no trash and no undo for registrations, so both delete tools require explicit confirmation and show you the full blast radius first.

Why the numbers here match what your admin shows

Two things about Events Booking's data are easy to get wrong, and getting them wrong produces reports that look authoritative and disagree with the component's own screens.

The first is that a contactable registrant isn't simply a published one. Events Booking's own definition, written out identically in three separate places in its source, counts a pending registration as live if it's on an offline payment method — somebody who's coming and will pay at the door — while a pending registration on a card method is an abandoned checkout. Every count, report and recipient list here uses that same definition. Relatedly, the published column on a registrant isn't a publish flag at all; it's the registration status, and the payment status column is about deposits rather than about whether anyone has paid.

The second is that seats aren't rows. A group booking stores a parent row holding the whole booking's total plus one row per member, and those member rows carry their own seat counts and their own money, so counting rows double-counts the group and summing every row roughly doubles its revenue. Capacity, revenue and check-in here all sum the seat column and exclude member rows, the way the component does. Revenue is reported per currency and never summed across currencies.

Version 1.0.0 has not yet been run against a live site

Worth saying plainly, since you're being asked to pay for it. Every tool here is written from a close reading of the Events Booking 5.8.2 source, and the add-on passes its verification harness — all thirty-eight tools load, construct and describe themselves correctly. But no tool has yet executed against real registration data.

The read and reporting tools are safe to explore with, and the duplicate audit is the best place to start: it's read-only, it sends nothing, and it's the tool most likely to tell you something you didn't know. Before pointing the write tools at a site that takes money, take a backup. If you run into something, I'd genuinely like to hear about it — that feedback is what turns 1.0.0 into 1.0.1.

Open source

GPL-2.0-or-later, the same license as Joomla itself. Source lives on GitHub.

Interesting blog? Like it on Facebook, Post it or share this article on other bookmarking websites.