Search

Language

Get started

AI agents and the Abilities API

HappenBoard can expose itself to AI assistants, so an agent can list your events, create one, check availability or read your settings on your behalf. The feature is off when you install the plugin, and nothing is registered until you switch it on.

Turning it on

  1. Go to HappenBoard → Settings → AI agents.
  2. Switch on Expose HappenBoard to AI agents.
  3. Click Save.

This registers HappenBoard with the WordPress Abilities API and, if an MCP client is installed on the site, with MCP as well. While the switch is off nothing is registered at all, so an agent sees no HappenBoard abilities rather than a list of refusals.

It needs WordPress 6.9 or later, which is the release the Abilities API arrives in. On an older version the setting saves but has no effect, and the rest of HappenBoard is unaffected either way.

What an agent can do

HappenBoard registers 41 abilities, grouped into four categories so an agent can find what it needs:

  • Events & calendar: read and manage events, occurrences, venues and organizers, preview a repeat rule, duplicate an event, bulk-update several.
  • Appointment booking: booking types, host availability, bookable slots, and creating, rescheduling or cancelling a booking.
  • Attendees & RSVPs: registrations, attendee records and saved events.
  • Configuration & diagnostics: a site overview, the system status and your settings.

The overview ability is deliberately the cheapest, broadest call: an agent orienting itself asks that one question and learns the shape of your site before fetching anything in detail.

What keeps it safe

Four rules apply to every ability, and none of them can be switched off from this screen.

  • An agent acts as a WordPress user. It can only do what that user’s role already allows, checked against the same permissions as the admin screens. Nothing is reachable anonymously, and giving an agent an application password gives it exactly that person’s reach, no more. See roles and permissions.
  • Rate limits, per user. 300 reads a minute, 60 writes a minute and 600 writes an hour. They exist so a looping agent, or a leaked application password, cannot exhaust the site.
  • Anything that cannot be undone asks first. Destructive abilities carry a required confirm input and refuse until it is set to true, so a misread instruction does not delete an event on the first try.
  • Destructive abilities are never exposed over MCP. That is decided in the code, per ability, and no setting can widen it.

Your public sign-up and booking forms are not part of this surface. They keep their own protections, described in protecting your forms from spam, whether the agent surface is on or off.

The agent activity log

Under the same settings section, Agent activity lists what agents have actually done. Each row carries the time in UTC, the account the agent was acting as, the ability it called, and how the call ended.

Five outcomes are recorded: Completed, Refused (a permission check said no), Errored, Rate limited and Not confirmed (a destructive call that arrived without its confirmation). You can filter on the outcome and page through the history.

Two things worth knowing about what it contains. Only writes are logged, because logging reads would bury the twenty rows that matter under a hundred thousand that do not. And refusals are kept alongside successes on purpose: a credential probing the surface produces refusals, not completions, so a log holding only successes would be blind to exactly the behaviour it exists to catch.

Rows are kept for 90 days and then cleaned up.

Turning it off again

Switch the toggle off and everything is unregistered on the next request. Nothing is deleted, and turning it back on restores the same surface.

For an incident, or to neutralise the surface across a whole network without touching the database, add this to your wp-config.php:

define( 'HAPPENBOARD_DISABLE_ABILITIES', true );

That wins over the setting, so the surface stays off even if someone flips the toggle.

MCP

MCP, the Model Context Protocol, is how assistants such as Claude talk to tools. HappenBoard needs no MCP plugin of its own: if the official WordPress MCP adapter is present, HappenBoard registers a dedicated happenboard server with it, so you can point an agent at this plugin alone rather than at every ability on your site.

Only abilities marked as public in the code reach MCP. Adding an ability therefore does not silently widen what an agent can see. Without the adapter installed the abilities remain reachable through the Abilities REST API exactly as before.

What’s next