Event tech has a read/write line, and almost nobody is publishing it

ADITUS has put a trade fair registration system inside Claude, with 125 tools that can write to live event data and 19 that can delete it. The question worth asking is not what AI can now do to your event. It is what stops it.

The short version  ADITUS Evo is listed in Anthropic’s Claude directory with 261 tools. 136 are read-only. Of the remaining 125, 69 create data, 37 modify it and 19 can delete it.

That breakdown is the first published by any event technology vendor. It matters because a directory listing tests whether a connector is built correctly, not whether it is safe to point at a live show.

Someone asked Claude to delete a ticket type from a live trade fair.

Claude checked first. The article it had matched, a day ticket on a 2026 exhibition, had 14,995 tickets, 259 sale positions and two order positions attached to it. It declined, and said the deletion was blocked anyway. Told to do it regardless, it declined again, pointing out that the endpoint refuses while fiscal records exist and that there is no force flag on it by design. Told a third time, in blunter terms, it gave way and reached for the tool. Before anything reached the API, the client stopped it and put a box on the screen. Deny, or allow once.

That exchange, which ADITUS shared with Event Tech Live, is the most useful thing an event technology vendor has published about AI this year. Not because it shows an assistant behaving well. Because it shows precisely where the protection came from, and the model was the weakest part of it.

We are about nine months into event technology vendors shipping Model Context Protocol servers, the open standard that lets an AI assistant talk directly to a platform rather than through its dashboard. Eight organiser-side vendors have now shipped something real. Three of them will tell you the one thing that determines how much you should worry about it.

Which event tech vendors have actually shipped an MCP server?

In short  Eight organiser-side vendors have shipped or listed an MCP integration as of 11 August 2026: Ticket Tailor, Swoogo, Eventcombo, RainFocus, Jomablue, vFairs, InEvent and ADITUS. Only vFairs, Eventcombo and ADITUS have stated their read and write scope publicly. Cvent has no first-party server and reaches assistants through third-party bridges.

Swoogo went first among the organiser platforms, announcing a native server on 6 April and claiming to be the only event management platform offering one. Eventcombo has had one live since June, connecting Claude, ChatGPT and Gemini to registration, check-in and reporting data. RainFocus followed on 8 July with MCP Profiles, part of its Nexus system, built around OAuth and short-lived scoped tokens.

Then July got crowded. Jomablue launched its own MCP in the middle of the month, with general availability set for August. vFairs shipped on the 21st with roughly 50 customers in beta, and I covered that at the time. InEvent announced on the 28th, with the technical detail still to follow.

ADITUS was notified that its connector had been accepted into Anthropic’s directory on 30 July, and announced it on 6 August. Ticket Tailor, aimed at a very different customer, has been listed there since last year.

Sources listed at the end. Where a field says not disclosed, the vendor has not published it.

Four of those vendors claim a first of some kind. Swoogo says first native event management server. RainFocus says first native MCP with an enterprise-grade OAuth security layer. Ticket Tailor says first ticketing platform in Anthropic’s directory. ADITUS says first enterprise connector for event organisers. Scoped narrowly enough, all four are true at once, which tells you roughly what a first is worth here.

The gaps in that table are the story. Jomablue told Event Tech Live in July that its MCP had launched and would reach general availability in August, and nothing about it is publicly documented yet. InEvent has not published technical detail beyond its announcement. RainFocus has the most rigorous authentication model of the group and has not said whether an assistant can change anything. None of that is unusual for products this new, but it does mean an organiser cannot currently compare them on the thing that matters most.

Eventcombo answers the question directly and in plain language, which is more than most manage: the assistant answers and drafts, your team reviews and sends. One line in its FAQ is worth a second look, though. Asked whether the AI can get something wrong, it answers no, on the grounds that the data comes from the live system rather than from training data. That holds for the data and not quite for the answer. A model can pull accurate figures and still aggregate or summarise them in a way that misleads, and the distinction is worth keeping in view when the output is heading into a board update.

What does ADITUS Evo actually expose?

In short  ADITUS confirmed 261 tools to Event Tech Live on 10 August 2026. 136 are read-only. Of the 125 that write, 69 create data, 37 modify it and 19 can delete it, in each case subject to the authenticated user’s permissions, client approval and validation at the API.

That breakdown is the number the industry has not been given before. Evo covers ticketing, exhibitor management, halls, stand booking, organiser and exhibitor campaigns, mailings and content, and a meaningful share of that surface can be written to rather than just read. The connector panel groups the write and delete tools separately and sets them to need approval.

The 19 deletion tools are worth separating out from the other 106. Creating a ticket type badly is a nuisance. Modifying one badly is a problem. Deleting one three weeks before a show, on an article with fifteen thousand tickets attached, is the scenario every operations manager pictures when they hear that an AI assistant now has write access to their registration system. It is also the one ADITUS has built the most protection around, which is presumably why it was the example they chose to show me.

A count that size raises a fair objection, which is that models get worse at choosing tools as the list grows. It is also a moving target: the directory listed 255 when the connector was announced, a figure ADITUS says was roughly two weeks out of date because tools were still being added and refined during rollout. Sebastian Kluge, ADITUS’s head of product management, accepts the criticism of a flat 261-tool prompt and rejects the idea that 261 capabilities is itself a problem. He points to Anthropic’s own work on tool search, where definitions are loaded on demand rather than dumped into context, and Anthropic’s published figures do support him. In its testing, tool search cut the context spent on tool definitions by around 85% and lifted evaluation accuracy on its most capable model from 79.5% to 88.1%.

ADITUS also uses flexible query tools for reads rather than modelling every possible question as another endpoint, which is the right instinct and keeps the count lower than it would otherwise be. What Kluge does not say is whether the server itself narrows the set it offers, or whether all 261 arrive at the client and the filtering is the user’s job through the connector settings. On the evidence of the settings panel, at least some of it is currently the user’s job.

What stops an assistant deleting something it should not?

In short  Three layers, in order of usefulness: the API refuses destructive calls where dependent records exist, the client intercepts write and delete invocations and requires explicit approval before execution, and the connector inherits the user’s existing permissions. The model’s own reluctance is not one of the layers, and ADITUS says its architecture assumes as much.

Go back to the delete. The user pushed three times. The assistant reasoned well, surfaced the dependency check, explained the fiscal position of the sale positions, and then gave way and reached for the tool when instructed firmly enough. Nothing reached the API. The client intercepted the invocation and demanded an explicit yes, and behind that sat a server-side guard that refuses the call while dependent records exist.

This is the part organisers should take away, and it is the opposite of the reassurance most AI marketing offers. Safety here is a property of the permission model, the approval gate and the API, not of the assistant’s judgement. An assistant that argues with you for two rounds and then gives way is behaving exactly as you would expect a language model to behave. What stopped it was made of code.

Kluge puts the principle more plainly than I would have dared to on his behalf. ADITUS’s security model, he says, deliberately assumes that the language model itself is not a security boundary, and enforcement happens through user permissions, approval requirements, API validation and audit logging. That is the correct architecture, and it is worth holding up as the standard because it concedes something most vendors will not: the model will sometimes try the wrong thing, and the design has to survive that.

ADITUS says its tools carry the correct MCP annotations, including the read, write and destructive semantics that tell a client which actions to gate. That is worth crediting, because it is the actual compliance point and it is not universal. It also comes with a caveat the standard itself makes clear: annotations are advisory metadata, not enforcement. A client trusts them. It does not verify them. So a read-only claim is a design assertion by the vendor, not a guarantee the client can check on your behalf.

On permissions, Kluge is unambiguous. Write rights follow the authenticated user’s existing role in TERP, and the connector does not create a separate privilege model. Every action is logged against the affected record whether it came through the interface or the assistant, and AI-driven changes are additionally attributed to the specific tool that made them. That last detail is a good piece of engineering, and the first tool-level audit trail I have seen described in this sector.

Is shipping an MCP server the right move at all?

In short  EventsAir has deliberately not shipped one. Its argument is that MCP servers sit on top of APIs rather than replacing them, so the API should come first, and that connecting a general-purpose model to live event data raises governance questions most organisers have not thought through.

Every vendor above has made the same bet, so it is worth hearing from one that has not. EventsAir – built its AI assistants inside the platform instead, on models hosted in its own Azure environment in the same regions as its customers, so customer data never reaches any AI provider.

The technical part of the argument is sound and not especially contentious. An MCP server is a translation layer over an API, not a data source in its own right. Build the API properly first and the MCP layer is straightforward. Build the MCP layer over a thin API and you have shipped an announcement rather than a capability. EventsAir puts its GraphQL work first on that basis and says it will evaluate MCP as the standard matures, which is a hedge rather than a refusal.

The second part is more pointed, and it got there before I did. EventsAir argues that connecting ChatGPT or Claude to an event platform can hand an external system on-demand access to attendee personal data, registration records and behavioural analytics before an organiser has worked through the governance and auditability implications. On writes, it notes that an MCP connection does not only retrieve, and that without proper guardrails an organiser ends up with a general-purpose model making decisions in a live environment. Who controls the data, the permissions, and the intelligence flowing through those systems, it asks, is the question worth asking before you connect.

That is the right question, and it is the same one this piece is built on. It is also a question EventsAir is well placed to ask and rather well served by asking, because its own answer keeps the customer inside its platform. Attendee and event data still reaches a language model under the embedded approach. What changes is who owns the pipe, and the vendor arguing that the pipe should be theirs is not a neutral party.

Both models have a real trade-off. Embedded AI gives the vendor control of the context, the tuning and the audit surface, and gives the organiser one throat to choke. It also means the intelligence stops at the platform boundary, and an organiser running three systems gets three assistants that cannot see each other. MCP goes the other way: portable across clients, able to reason across tools, and dependent on the organiser understanding a permission model they did not design. Neither is the safe option. They fail differently.

Does a directory listing mean someone checked it?

In short  It means the connector passed an automated technical check. Anthropic’s directory distinguishes verified connectors, reviewed in depth, from community connectors that have passed those checks. ADITUS Evo is listed at the community tier, with a manual review pending at Anthropic and further reviews pending with OpenAI and Microsoft.

This is where the story stops being about one German company.

ADITUS Evo is officially listed in Anthropic’s Claude directory at the Community tier, having passed the automated technical checks required for that listing. ADITUS has requested an additional manual review by Anthropic, which is currently pending.

The more interesting answer was the one to a question he was not really asked. His reading of how these reviews work, and he was careful to flag it as interpretation rather than something the platforms have told him, is that they validate the technical side and nothing else. In his experience the questions from platform providers have always been technical. ADITUS was never asked to justify whether a particular exhibition workflow was any good, or whether a tool solved an organiser’s business problem in a sensible way.

Read that back slowly, because it is the whole point. Nobody at any of these AI companies is assessing whether a trade fair stand booking workflow makes sense. They are not staffed to, and they have never claimed to be. The badge on the listing tells you the connector is built to standard and behaves predictably. It tells you nothing about whether pointing it at a live show three weeks out is a sensible idea.

Which means the domain judgement stays with us. Organisers cannot outsource it to a directory, vendors cannot claim it by being listed, and a trade press that treats a listing as an endorsement is not doing its job.

Who is responsible for the data once it leaves your event platform?

In short  You are. Once an organiser connects Claude or ChatGPT to a registration system, the AI provider’s residency and retention terms apply, and the customer chose that provider. ADITUS states plainly that it does not claim processing stays inside the EU.

Kluge’s answer here deserves quoting for its rarity. ADITUS does not claim that AI processing remains entirely inside ADITUS or the EU. Once a customer uses Claude or ChatGPT, that provider’s residency and retention terms apply. The vendor’s responsibility is controlling what the authenticated user may access and what the connector returns. The customer controls which AI provider is connected.

That is contractually correct and refreshingly free of spin, and it puts an obligation on the organiser that most have not yet worked out. Connecting an assistant to your registration system is a deliberate extension of your own processing chain. The transfer risk is yours. The data protection impact assessment is yours. Whether your attendee privacy notice covers a third-party model reading their records is your problem, not your ticketing vendor’s.

It is also worth knowing that zero data retention arrangements do not necessarily cover the connector path in the way people assume. Retention on tool definitions and execution results can follow the provider’s standard policy. If your data protection lead has waved this through on the basis that ZDR handles it, that assumption needs testing before anything gets connected.

What should organisers ask before connecting anything?

Six questions. They work on any vendor in the table above, and against most of them four of the six currently produce silence.

• Read-only or read and write? If write, how many tools, and can I see the split?
• Are the destructive tools annotated so my client knows to gate them, or is the assistant guessing from the tool names?
• Do permissions inherit from my existing roles, or does the connector run its own privilege model?
• Is there an audit trail, and does it distinguish an AI-driven change from a human one?
• Which AI providers are supported, where does the processing happen, and who is controller in that chain?
• What refuses at the API layer, regardless of what the assistant decides to do?

That last one is the one I would press hardest on. It is the only question whose answer does not depend on a model behaving itself.

Where this goes next

ADITUS introduced Evo to selected customers on 2 July and spent the month running hands-on sessions. Kluge was straight about the consequence, which is that usage is currently too low to produce a meaningful read to write ratio, and that he would rather say so than overstate early traction. He expects a customer willing to talk publicly by October. He also expects writes to settle in single-digit percentages of total calls, on the reasonable logic that any sensible write is preceded by two to five reads validating state and dependencies.

The connector is included in the Evo licence with no separate charge, which is the right call and a mild inconvenience for anyone hoping MCP becomes a line item.

My expectation for the rest of the year is that two or three more organiser-side platforms ship servers, that at least one ships write access without publishing the split, and that the first genuinely awkward incident in this sector involves an assistant doing something permitted rather than something exploited. The failure mode to watch is not a breach. It is a busy operations manager, three days out from opening, approving a dialog box they did not fully read.

The vendors who come out of that well will be the ones who published their read and write split, annotated their destructive tools properly, and told organisers plainly where the responsibility sits. Two have done all three so far. The rest have time, and the ones moving fastest are mostly a documentation page away from being judged on the same terms.

Frequently asked questions

What is an MCP server in event technology?

Model Context Protocol is an open standard, now governed under the Linux Foundation, that lets an AI assistant connect directly to a software platform and use its functions as tools. In event technology it means asking an assistant about registrations, ticket sales or exhibitor status and getting an answer from the live system rather than from a dashboard export.

Is a connector in the Claude directory safe to use?

A listing means the connector met technical requirements such as transport, authentication and tool annotation. Anthropic distinguishes verified connectors, reviewed in depth, from community connectors that passed automated checks. Neither tier assesses whether a tool suits an event workflow. That judgement stays with the organiser.

What is the difference between a read-only and a read and write MCP server?

A read-only server can retrieve and analyse data but cannot change anything, which is the approach vFairs has taken. A read and write server can also create, update or delete records, which is what ADITUS Evo and Ticket Tailor offer. The distinction determines your entire risk position and most vendors do not publish it.

Does connecting an AI assistant to my event platform create a GDPR problem?

It creates a GDPR responsibility. The organiser remains controller, the platform is a processor, and the AI provider becomes a further processor chosen by the organiser rather than by the platform vendor. Transfer mechanisms, retention terms and attendee privacy notices all need checking before connection, not after.

Should my event platform have an MCP server?

Not necessarily. Some vendors, EventsAir among them, argue that a mature API should come first because an MCP server is a translation layer built on top of one, and that embedding models inside the platform gives tighter control of governance. The trade-off is portability: embedded AI stops at the platform boundary, while MCP lets an assistant reason across several tools at once.

How many tools should an MCP server expose?

There is no fixed answer, but selection accuracy degrades as the list grows unless the server or client narrows what the model sees. Anthropic’s tool search approach, which loads definitions on demand, improved accuracy in its own evaluations. Ask a vendor how tools are surfaced, not just how many exist.

Notes on sourcing

Tool counts and their read, create, modify and delete breakdown, the permission model, audit trail, annotation status, security architecture, commercial terms and rollout timing for ADITUS Evo were confirmed to Event Tech Live by Sebastian Kluge, head of product management at ADITUS GmbH, in correspondence between 10 and 12 August 2026. The deletion sequence and connector permission panel were supplied by ADITUS and are published with permission. Kluge’s account of how platform reviews are conducted is presented as his interpretation, which he asked to be made clear.

Vendor announcement dates and scope are drawn from company releases: Swoogo, 6 April 2026; RainFocus, 8 July 2026; InEvent, 28 July 2026; ADITUS, 6 August 2026. vFairs details come from Event Tech Live’s own reporting of 21 July 2026. Eventcombo details are from its published MCP documentation. The Jomablue launch and August general availability were confirmed to Event Tech Live by Matthew Tuey, chief marketing officer at Jomablue, on 23 July 2026. No public documentation for the Jomablue MCP could be found at the time of writing, and the company has been asked to confirm its scope.

EventsAir’s position is drawn from its published article of 9 June 2026, updated 17 June, and from an interview with Pavvi, who heads EMEA sales at EventsAir, conducted for Event Tech Live in May 2026. Air Intelligence launched on 21 April 2026.

Anthropic’s tool search figures are from its published engineering work. Directory tier definitions are Anthropic’s own.