RainFocus has put three things on the record about its Model Context Protocol server that no other event platform has. One of them is an admission, and it applies to every vendor in this sector, not just to them.
TL;DR RainFocus exposes 123 admin MCP tools across 17 domains. Seven of them can send data out of the platform or change event-level configuration. Manual approval on writes is enforced by the AI client, not by the RainFocus server. No customer has yet run a write against a live production event.
In July, four event technology companies claimed a first of some kind on MCP. I wrote about that at the time and concluded that, scoped narrowly enough, all four claims were true at once, which is another way of saying none of them told you very much.
Six weeks on, RainFocus has answered a set of questions I put to chief executive JR Sherman and to Marius Milcher, its VP of platform strategy and AI. The answers are considerably more useful than the launch was. One of them is the most candid thing anyone selling into this market has said about agentic tooling, and it is not a comfortable answer for anybody, including RainFocus.
What did RainFocus actually ship?
MCP Profiles went live on 8 July inside Nexus, the company’s platform layer. An administrator creates a profile in the Integration Suite, switches on only the tools that profile needs, and copies a generated server URL. The AI client authenticates over OAuth and receives a short-lived, scoped token. Profiles are empty by default. Nothing is enabled until somebody enables it.
That much was in the announcement, and I covered it alongside the rest of the sector at the time. The launch is the least interesting part of this story. What matters is what the architecture implies once you push on it, and what it implies is that the value of an event platform is moving away from the interface it sells you.
Why would a chief executive argue his own switching costs should fall?
When we spoke, Sherman made the case that defensibility now sits in proprietary context, in complex workflows, and in data, and that a platform whose only asset is being a system of record gets relegated to exactly that. He thinks CRM is drifting into the system of record slot. It is a striking thing to say out loud when your company sits adjacent to Salesforce.
I asked him the obvious follow-up. If MCP exposes your workflow surface in a standardised shape, what stops a competitor implementing the same shapes and a customer swapping the server URL? His answer, given in writing:
MCP is a filter. It exposes companies whose moat was integration friction and strengthens the position of companies whose moat is real value. For years, a lot of enterprise stickiness came from lock-in-by-friction: talking to your back-end required a bespoke integration nobody wanted to rebuild, and that alone kept customers in place regardless of how good the workflow underneath was. MCP strips that layer out and makes moats honest.
JR Sherman, chief executive, RainFocus
Be clear-eyed about it. That argument flatters the person making it. Every vendor believes its own workflow depth is the real thing and everyone else’s stickiness is friction. Sherman is arguing a position that happens to suit RainFocus.
He is also, I think, right, and the argument has a limit he did not mention. MCP standardises the shape of the call, not the shape of the data underneath it. A competitor can implement identical tool names and still be querying a thinner model. So an open protocol lowers the integration cost of switching. It does not lower the migration cost of the data, and the data is where the accumulated value sits.
There is evidence of that in the sort of work RainFocus is being asked to do. Two or three of its large enterprise customers have commissioned integrations tying the RainFocus attendee profile to corporate identity systems, in the simpler cases to LinkedIn and in others considerably deeper. The customers are anonymised at RainFocus’s request. The motive is not personalisation. It is relationship persistence: keeping hold of a relationship when the contact changes employer. That is the moat argument in practice, and it has nothing to do with the interface.
At its INSIGHT conference, RainFocus demonstrated the other half of the same idea. Agentforce queries RainFocus for session schedules, executive and analyst availability, content, and the attendee profile, then registers someone, and if the flagship event does not suit, offers a regional alternative instead. The organiser’s software is doing the work. The organiser’s software is not what the attendee is looking at. Sherman’s point is that this is now open to any model rather than to one vendor’s agent.
Who enforces the confirmation when an agent writes?
This is where the piece stops being about RainFocus.
When I covered the sector in August, I argued that MCP tool annotations are advisory. The server can label a tool destructive, but whether anything happens as a result is decided by the client. Nobody had confirmed that on the record. Milcher has now done so, unprompted, about his own product:
Manual approval is client-side and not something our server enforces, yet. This is consistent with the current MCP spec, which places human-in-the-loop responsibility on the calling application, not the server. What we do enforce server-side is scope: OAuth ties a profile to a fixed tool set, separated across dev and prod, so a call to a tool outside that set fails regardless of what any client does.
Marius Milcher, VP of platform strategy and AI, RainFocus
Read that carefully, because two different controls are being described and they are often conflated in vendor material.
Scope is enforced by the server, and it works. A profile cannot call a tool it was never given, and no amount of clever prompting changes that. Confirmation is not enforced by the server. Once a tool is switched on inside a profile, the dialogue box asking whether you really want to email 40,000 people is produced by Claude, or ChatGPT, or whatever the customer has built. RainFocus ships readOnlyHint and destructiveHint annotations in its tool manifests, but an annotation is a label, and the client decides what to do with the label.
The practical consequence for an organiser is worth stating plainly. During a live show, the last thing standing between an agent and an irreversible action is a piece of software your event platform does not control and that you very probably did not procure. That is true of every MCP deployment in this industry today. RainFocus is simply the first to say it.
There is a second gap in the same area. Every tool call and data transfer is logged, and because profiles use OAuth with the user as principal, each call is tied to the administrator who made it. But RainFocus does not capture the prompts or the model’s responses, only the calls. There is an optional submitter attribute a customer can populate to record which agent or skill was involved. Optional. So if something anomalous happens, the log tells you what was called and under whose credential. It does not tell you what was asked, or by whom, unless somebody chose to record it.
How many tools can actually do damage?
RainFocus exposes 123 admin-transactional MCP tools across 17 domains. Rather than sorting them by CRUD verb, the company classifies them by consequence:
Read returns data and changes nothing: 55 tools. Reversible creates or updates a record: 50. Destructive removes a record or a relation between records: 11. Critical sends data out of RainFocus, an email or a badge print for instance, or changes organisation-level configuration such as the event record: seven.
That taxonomy is more useful than anything else published in this sector, and I would encourage organisers to ask for it by name. ADITUS, the only other vendor to publish a full breakdown, gave me 261 tools split 136 read, 69 create, 37 modify and 19 delete. That is a CRUD split, and CRUD has a blind spot. Sending an email to an attendee list is not a delete. Printing a badge is not a delete. Neither can be undone. A verb-based taxonomy files both under harmless updates. A consequence-based taxonomy puts them in the smallest, most tightly guarded bucket, which is where they belong.
Seven Critical tools out of 123 is a defensible number and RainFocus should get credit for it. All of these figures are supplied by the vendor and I have not independently verified them.
Has anyone actually used it?
I asked whether any customer had executed a write against a live show. The answer:
Nobody has executed a write against a live production event yet. Current activity is customers building, experimenting, and planning for upcoming events, but no production write has happened in practice.
Marius Milcher, RainFocus
Somewhat over half a dozen customers are building and experimenting. None has yet pointed an agent at a running event and let it change something. A vendor putting that in writing seven weeks after launch is unusual, and it reframes the whole first-to-market argument the sector spent the summer having. Nobody is first at anything if nobody has used it in production.
It also matches what Sherman described when we spoke. He sorts enterprise buyers into three camps: the box-checkers, whose security teams are never going to approve this; the holdouts still operating as they did in 2019 and wanting a white glove service; and a smaller group thinking about it seriously. One of RainFocus’s largest platform customers, which runs over a thousand conferences a year and is anonymised here at the company’s request, told them it has no interest in AI building its session schedule. It would take conflict detection and real-time room reallocation. That is a considerably more honest picture of enterprise readiness than any adoption statistic.
What happens when the attendee becomes the principal?
Everything above concerns admin tooling. The 123 tools are the administrative set, and there is a second set coming:
Yes, attendee-facing tools are on the roadmap, and they’d introduce a new pattern where the attendee authenticates as the principal rather than an admin. That’s correctly flagged as a different risk surface, it’s planned with no firm commitment on scope or timing yet.
Marius Milcher, RainFocus
That is the sentence to sit with. Today, every MCP action inside RainFocus runs under an administrator’s identity against a profile somebody deliberately assembled. When the attendee is the principal, the identity model inverts, and attendee-authored text starts meeting attendee-facing tools inside the same session.
The same tool-level controls apply to attendee profiles. An organiser can expose a single tool, schedule lookup and nothing else, and an attendee profile can never surface admin tools. Least privilege applies on both sides.
Which brings up prompt injection. Bios, session abstracts, exhibitor descriptions, and registration free text are all written by attendees, and all of it lands in an agent’s context in a system that can write. I asked what stops instruction text in a speaker bio from steering a tool call. The answer began:
Prompt injection is a real threat anywhere an agent ingests user-generated content. It’s not unique to event tech, it affects every vendor building on AI. No one has solved it and we won’t claim to have.
Marius Milcher, RainFocus
The mitigation, as described, is least privilege on what a profile can call, separation between read and write paths at the infrastructure level, manual approval on writes, and audit logging. Milcher closes with the line that does the real work: a bio can carry instruction text, but it cannot grant itself permissions the profile was never given.
Scoping carries over, then, and it is the right control. The open question is narrower and harder. It is whether a tightly scoped attendee tool set is enough when the text steering the agent was written by the attendee. Nobody has answered that, in this sector or outside it, because nobody has shipped it yet.
What to ask your platform before you connect anything
Six questions. They work on any vendor, and the quality of the answers will tell you more than any launch announcement.
One. How many tools does your MCP expose, broken down by consequence rather than by CRUD verb? Two. Which of those tools send data out of the platform or change event-level configuration, and how many are there? Three. Is the confirmation on a write enforced by your server, or by my AI client? Four. Does the audit log record the person who prompted, or the credential that executed, and does it capture the prompt itself? Five. Has any customer run a write against a live production event? Six. When attendee-facing tools arrive, who is the principal, and what changes?
If a vendor cannot answer the third question in one sentence, they either have not thought about it or would rather you did not.
The part nobody wants to say
Sherman is bullish on where this is heading commercially. His view, and it is his view rather than a published figure, is that enterprise B2B is waking up to offline channels as the strongest way to build trust and grow, and that investment in events is rising as a result. He calls it an undeniable shift in the market. I would want a number behind that before treating it as established, and he did not offer one, but it is a reasonable read of where budget is moving and he is better placed than most to see it.
What interests me more is the smaller admission underneath it. This sector spent July arguing about who shipped an MCP server first. The more useful question is who is holding the confirmation dialogue when an agent decides to send an email to your entire attendee list. As of today, across every platform in this market, the answer is not your event platform.
RainFocus is the first to say so on the record. That is worth more than being first to ship.
Disclosure: Tool counts, adoption figures, and technical detail in this piece were supplied by RainFocus and have not been independently verified. Quotations are taken from written answers provided by the company. Material from the interview of 20 August is reported rather than quoted directly. Event Tech Live has covered RainFocus previously as part of its ongoing MCP reporting. No payment was made or received in connection with this article. Updated 7 September to clarify that tool-level controls apply to attendee profiles.
