What is MCP? What to check before connecting it to your event

It is 18:00 and the doors open tomorrow. The client asks you to “clean up the list and remind anyone missing”. You know they mean checking duplicates and preparing a reminder. An AI agent connected to your platform might have tools to read the list, change registrations and send messages.

Before giving it that instruction, you need to know which actions it can execute and which require someone’s approval. The difference matters: you can review a prepared list; a sent message has already reached its recipients.

When a provider announces an MCP connection, it has explained how the assistant can connect. Questions remain about what it will do with that connection and how the company will control its actions.

What MCP means for your event work

MCP stands for Model Context Protocol. It is a standard for connecting AI assistants with information and tools in other systems.

Suppose your team asks the agent to “check how many people have afternoon tickets”. If the platform offers that tool and the connection is prepared, the agent can request the data from the system. It no longer depends on someone exporting a list and attaching it to a conversation.

Other tools might change a record or send a message. The possibilities depend on what the provider has exposed and the connection’s permissions. Having MCP does not mean all those actions are available, or that they should be enabled together.

The official MCP tools documentation describes how functions are offered to connected applications. To decide whether a connection suits your event, ask the provider to translate its tool catalogue into actions your team recognises.

You do not need to program the protocol. You do need to understand what you are authorising.

Reading a list and sending it are different decisions

An agent can help prepare work without executing it outside the conversation. It can also act on a platform if it has the necessary tools. Separate these situations from the start.

Action	What changes	What you should be able to review
Read registrations	The agent accesses data	Which event and fields it can read
Propose an audience	A selection is prepared	The criteria and people included
Change a record	System information is modified	The record and exact change
Send a communication	The message reaches people	Content, recipients and timing
Delete or share information	Information is lost or leaves its environment	Scope and consequences before execution

These differences help you start with a limited scope. If the team only needs to consult information, there is no automatic reason to enable sending or deletion tools too.

In the opening scene, “clean up the list” should first become a reviewable proposal: which records appear duplicated and on what basis. “Remind anyone missing” needs clarification about who those people are, what message they will receive and when. The client’s request expresses an intention; the team should be able to approve the specific operation.

What it means to genuinely ask for permission

A description saying “ask for confirmation before sending” guides the agent, but does not demonstrate that the action is blocked. Nor is it enough for the model itself to fill in a “confirmed” field.

MCP includes a mechanism called elicitation for requesting user input through the application. It can be used within a confirmation process if the client and server support it. The specification does not require every sensitive tool to use that process. Source: MCP elicitation.

For effective approval, the executing system must wait for valid authorisation for that action. Confirmation must correspond to what you reviewed: the message, recipients and operation parameters. If the content or list changes afterwards, the team needs to know whether approval is required again.

Ask for a concrete demonstration: prepare a message and decline approval. It must not be sent. Also test what happens if you do not respond or the application does not offer that type of confirmation.

That behaviour matters more than a commercial claim about “human control”. The provider should explain where execution is prevented and what happens when authorisation is missing.

Tool labels do not replace controls

A tool can include indications about its behaviour, such as reading information or potentially taking a destructive action. These help interpret it, but should not be mistaken for a block that makes an operation impossible.

The specification treats annotations as hints and warns against relying on them when they come from an untrusted server. Source: MCP tool annotations.

For your event, the practical question is different: can the company disable an action and verify that it is no longer available? If an assistant should only read the programme, you need to check that it cannot access a tool that changes it.

Ask to see that separation in configuration and in a test. The tool’s name, its description or an instruction in the conversation does not replace that check.

What to ask the provider before connecting your platform

You can leave the technical review to whoever maintains the integration while still understanding its consequences. These questions provide a basis for that conversation:

• Which tools will be enabled? Ask for a list of actions, with examples of what each can do to your event.
• Which information will they access? Establish whether the connection is limited to one project or reaches other accounts and events.
• Who can use each action? Reading a registration and sending a campaign need not be available to the same people.
• What requires approval and where is execution blocked? Ask to see what happens after a refusal, no response and changes following confirmation.
• What is recorded? You need to reconstruct who requested an action, who authorised it and what happened.
• What can be recovered? Distinguish restorable internal changes from external effects that cannot be withdrawn.

If an answer amounts to “the agent knows it should not do that”, a verifiable control is missing. If you are shown a configuration, ask how they check it also applies when a request is ambiguous.

The review should cover the application your team will use. A mechanism existing in the protocol does not demonstrate that it works identically in every connected application.

Recovering memory does not withdraw a sent message

EVA Brain works with shared project memory, permissions and change history. That history helps you understand how knowledge has developed and recover memory states where appropriate.

Those controls address part of the problem: how the team works with event knowledge. Actions taken in external platforms need their own limits and approvals.

For example, restoring memory to before a change does not withdraw an email already sent or make a shared list disappear. Before connecting a communication tool, sending needs to be controlled. Before granting access to information, establish what can leave the system.

For a company with several teams, centrally managing connections and tools can provide a way to set those rules together. Evaluate that layer by its specific controls: enabled actions, authorised people, approval and records. Ask what is available in your configuration before assuming the problem is resolved.

If you are considering connecting agents to your event work, tell us which platforms you use and which actions you want to delegate. The conversation should start with those tasks and their consequences, before choosing a connection.

Frequently asked questions

Is MCP inherently dangerous?

No. Risk depends on the exposed tools, accessible data and client and server controls. A read-only connection has different consequences from one that can send messages or delete information.

Does MCP require permission before every change?

There is no universal human confirmation for every action. The protocol includes mechanisms for user interaction, but you need to check how the particular integration uses them and where sensitive operations are blocked.

Do I have to perform a technical audit myself?

You can ask the provider or a specialist. As an organiser, you need to understand which tasks you delegate and receive evidence of the agreed limits, approvals and records.

Does a history mean everything can be undone?

No. It can help recover information within a system. A sent message, shared data or an external action can have consequences that restoring memory does not reverse.