Connecting your event data to an AI assistant

What is MCP, and why does it exist?

Until now, the way to ask an AI assistant about your event data was to export a report from the panel and paste it into the chat. That works, but it has three problems: you move the data by hand, you are the one policing what leaves, and the moment you paste the file every row — including attendee names — has gone to the assistant.

Model Context Protocol (MCP) is an open protocol that standardises this. The assistant calls tools the application itself defines, and what each tool returns is fixed in advance. The difference: when you paste a file, you draw the boundary; with MCP, the application draws it.

Etkin’s MCP surface is off by default. No data leaves through it until you explicitly authorise an assistant. If you never set it up, everything else in Etkin works exactly as before.

Setting up the connection

The endpoint is https://app.etkin.app/api/mcp. You enter this address in your assistant’s “custom connector” screen. For a step-by-step Claude setup with screenshots, see Connecting Etkin to Claude.

An OAuth 2.1 flow then starts, and your password is never given to the assistant. Midway through you land on Etkin’s own consent screen: you see which application is requesting which permissions, and you approve or decline. Without approval no connection is made; there is no silent or automatic consent.

Two practical notes

• You can revoke access later. On the Settings page, the Connect to your AI assistant card lists connected applications and disconnects any of them in one click. Access ends immediately.
• Your role decides what is possible. Only super_admin, stk_admin and organization staff can set up the connection — and the assistant never sees more than you can. The connection carries your existing permissions; it does not create new ones.

What you can ask

The assistant can call fourteen tools. Ten only read. One drafts text without saving anything (it does consume your AI credit), one creates a draft event (it never publishes), and the remaining two produce outside effects only with your explicit approval. In plain terms:

All of these run through the same calculation chain the panel uses. So the number the assistant gives you and the number on your screen cannot drift apart — there is one source, not two code paths.

What the assistant cannot see

This is the most important section, because an integration is worth as much for what it cannot do as for what it can.

• No attendee list. Names, emails and phone numbers never pass through. The assistant can answer “how many attended”, never “who attended”.
• Free-text survey answers are never returned — not as samples, not as summaries, not as word frequencies. A person’s own sentence can identify them even when summarised.
• Small samples are suppressed. If a question has fewer than five responses, only the response count is reported; the distribution itself could point at a single person.
• Bank details (IBAN, bank, account holder), organizer contact records and internal notes never leave.
• No cross-tenant access. A request for another organization’s event is refused — not silently returned as “not found”, but refused.
• The assistant cannot update, delete or cancel events, and cannot remove anyone from one.
• No SMS or WhatsApp. Only email can leave through this surface, and only with approval.

The two actions that need approval

Two tools produce irreversible outside effects: publishing an event (which may send an announcement email to followers) and scheduling a reminder email to attendees. A sent email cannot be recalled — so these two behave differently from the rest.

Before acting, the tool tells you how many people would receive what and asks for explicit approval. Decline and nothing happens. On the reminder side there are further safeguards:

• Delivery starts 15 minutes later at the earliest; until then you can cancel it from the panel.
• A single call covers at most 100 recipients. Above the cap the job is not created at all — the list is never silently truncated.
• Recipient addresses are never shown to the assistant; Etkin sends the mail, the assistant only sees the count.

If your client cannot display an approval prompt, these two actions are refused and you get a link to the panel instead. That is by design, not a fault: if approval cannot be obtained, an irreversible action is not taken.

Every call is logged

Every tool call the assistant makes is written to your account’s audit log and is visible in the panel: which tool ran, what the result was, how long it took, which event it concerned and which client connected.

The purpose is security: only this record can show whether something was done without your knowledge. Refused requests are logged too — a failed access attempt often says more than a successful one.

The text you write to the assistant is not stored. The prompt you type for a draft, or the subject and body of a reminder, never reach the log; only the fact that those fields were filled in is kept.

Today’s limitation: client support

To be straight about it, there is a limitation today. The approval round used by the publish and reminder tools requires the assistant to speak a specific protocol version, and most common clients have not moved to it yet.

In practice: twelve tools work today, while publish and reminder safely refuse and point you to the panel. When clients adopt the newer protocol, those two will start working with no change needed on your side.

We would rather write this down than hide it: knowing when an integration does not work beats assuming that it does.

Frequently asked questions

Related articles