The number that sounds right

I have spent this week asking an AI agent questions about event data and then quietly checking its homework.

It was right most of the time.

That's the part that worries me.

A tool that's wrong all of the time is not dangerous. It's annoying. You stop using it by Wednesday.

A tool that's right most of the time teaches you to stop checking.

That's not a technology problem. That's a brain doing what brains do. We are pattern machines. Give us four correct answers and we will take the fifth without looking, because looking is expensive and trust is cheap.

Now we are wiring that instinct directly into our event data.

What actually happened this month?

vFairs shipped an MCP server. Adam Parry covered it properly for Event Tech Live, including the governance questions worth asking any vendor, so I am not going to repeat his work here. Read it. It's a great piece and it asks five brilliant questions.

If the term is new to you, the Model Context Protocol is a standard way for an AI assistant like ChatGPT or Claude to reach into a platform and pull real data. Registration numbers, session attendance, whatever you have permission to see, without opening a dashboard.

It is a socket, not a source.

It's fancy plumbing really.

I want to be clear about that, because there is a criticism doing the rounds that MCP somehow invents or corrupts your data because it uses generative models.

'Generative' is in the name.

That must mean they generate data, right?

Wrong.

The kind of wrong that spreads very quickly too.

The data underneath is the same data that was always there. EventsAir set this out well back in June. vFairs went read-only and scoped to existing permissions, which is the right call and deserves saying out loud.

Nobody is hallucinating your attendee list.

So that's not the risk.

The query you can't see

When I write a GraphQL query, I name the fields I want.

I get those fields. Or I get an error.

It is boring, and boring is the entire point. It is repeatable. It is auditable. And when it is wrong, it is wrong the same way every single time.

Which means I can find it, fix it, and know it stayed fixed.

When an agent answers the same question, three things happen that didn't happen before.

It picks which tool to call. Give it a handful of well-defined options and it does this well. Give it fifty overlapping ones and it starts guessing, confidently, with no tell.

It takes whatever comes back. Including page one of twelve.

Nothing in that response says "there is more", and nothing in the agent particularly wants to ask.

Then it writes you a sentence.

And here is the bit I keep coming back to.

A sentence has no error state.

A failed query shouts. A spreadsheet with a missing column looks wrong immediately. But fluent English does not have a broken setting. The number arrives dressed as a fact, in a clean paragraph, with no working shown and no query you can inspect.

The failure did not get bigger. It got quieter.

Why this bites harder in events

Almost everywhere else I can think of, a wrong number is an awkward slide.

In our world it becomes food.

Rooms.

Badge stock.

Staff rotas.

Coaches.

Dietary requirements for people who genuinely cannot eat the alternative.

We turn numbers into physical objects, against deadlines that do not move.

With no undo button.

By the time anyone works out the figure was page one of twelve, the catering is ordered and the room is set wrong and someone is on the phone at eleven at night trying to fix it with charm.

There is something else, and I have not seen anyone say it.

Experienced event people have brilliant instincts for a wrong number. Show an ops manager a registration figure in a system they have used for nine years and they will frown at it before they can explain why. That instinct is real and it's earned.

It doesn't transfer.

They have no calibration whatsoever for a wrong number that arrives inside a confident paragraph from a tool they have used for three weeks. The alarm doesn't go off. There is nothing to frown at.

We are removing the friction that used to catch our mistakes and calling it efficiency.

Two vendors, same word

Here is the fair objection, and it is a good one.

None of this is inherent to MCP.

You can build one properly. Expose a small set of pre-defined, strongly typed operations so the agent picks between known-good queries instead of improvising across a sprawl of tools. Apollo do exactly this over GraphQL. Conversational on the outside, deterministic underneath.

So the protocol is not the story.

The engineering is.

Two platforms can both announce "an MCP server" and ship completely different products. One constrains the agent to typed operations over a schema that actually means something. The other opens a wide door onto free-text fields that every event team has been filling in differently since 2019.

Both demo beautifully. Demos always do.

The schema is the guardrail

This is the part I would put on the wall.

An agent is only ever as trustworthy as the data model underneath it. A strong, well-documented schema is what stops it inventing a field, guessing a relationship, or reading a status that means one thing in your organisation and something else in mine.

The structure is doing the work. The protocol is just the socket. The plumbing, if you will.

Which is why the platforms worth watching are not necessarily the ones shipping MCP first. EventsAir have not shipped one. What they did do was build a proper public GraphQL API starting back in 2023, and treat it as the foundation everything else has to stand on.

Foundation first. Socket second.

That order is not slower. It's the only order that works.

Five questions I would ask before connecting anything

1. What does the schema actually look like? Typed and documented, or free text that means something different at every event?
2. Are the operations pre-defined, or is the agent improvising across a big pile of tools?
3. Can I see the query it ran, or only the answer it chose to give me?
4. What happens at the edge of a page? Does it tell me it truncated, or hand me page one with a straight face?
5. When it is wrong, and it will be, how would we find out?

That last one is the only one I would refuse to proceed without.

Not because agents can't be trusted.

Because anything you can't audit, you aren't managing.

You are hoping.

I'm not telling you to wait

I use this stuff every day. All day. It's the reason I get my evenings back.

Read-only MCP servers are an awesome development. Planners working inside an assistant instead of a dashboard is where this is all going, and standing in the road won't stop it.

But the order matters, and our industry has form for getting it backwards.

If your operation is fragmented, pointing an agent at it doesn't fix the fragmentation. It queries it faster and describes it more persuasively.

Make the system visible. Fix the data model. Then let the agents read it.

Last week I wrote about an ottoman, 61 days in hospital, and AI handing me back the hours I used to burn overnight. I said it could give me the time but couldn't tell me what the time was for.

This is the same sentence wearing a lanyard.

AI can give you an answer. It can't tell you whether it is true.

That part is still ours, and it might be the only part that ever was.

The dangerous number was never the one that was obviously wrong.

Somebody always catches that one.

It is the one that sounds right.

If you have already connected an agent to your event data: how long would it take you to notice if it handed your team a wrong number tomorrow morning?