Skip to content
  • There are no suggestions because the search field is empty.

Grip Organiser MCP (BETA)

Connect your event to an AI assistant and explore your live event configuration — attendee types, agenda, homepage, integrations and more — using plain language.

OVERVIEW

This article explains how to set up and use the Grip Organiser MCP — a Model Context Protocol (MCP) server that lets an AI assistant securely read your live Grip Engage event configuration on your behalf.

Once connected, you can ask an assistant questions like “show me my most recent events” or “what attendee types and meeting dates are set for this event?” and it will retrieve the answer directly from Grip. The connection is scoped to the applications and events your Grip account already has access to, and it is read-only — it retrieves configuration, it never changes it.

mcp-video-Martin-Edit

Table of Contents

  1. What is the Grip Organiser MCP?
  2. Before you begin
  3. How to connect the Grip Organiser MCP
  4. Understanding applications and containers
  5. Available tools
  6. Field groups you can request
  7. Example questions to ask
  8. Troubleshooting
  9. Frequently Asked Questions

What is the Grip Organiser MCP?

What is MCP?

The Model Context Protocol (MCP) is an open standard that lets AI assistants connect securely to external systems. An MCP server exposes a defined set of tools; an MCP-compatible assistant (the client) can then call those tools on your behalf when you ask it a question.

What does the Grip Organiser MCP do?

The Grip Organiser MCP is Grip’s official MCP server for event organisers. It exposes a small, focused set of read tools (for now) that let your assistant look up your events and fetch their configuration from the Grip Engage server. Instead of clicking through the Admin to check how an event is set up, you can simply ask — and the assistant pulls the live values for you.

What can it not do?

The Grip Organiser MCP is strictly read-only for now. It can retrieve event configuration and data, but it cannot create, edit, publish or delete anything in your event. There is no write path — so exploring your setup through an assistant carries no risk of changing it.

Before you begin

To use the Grip Organiser MCP you will need:

  • A Grip account with organiser access to at least one application or event. The MCP mirrors your existing permissions — you will only see the events you can already access in Grip.
  • An MCP-compatible AI client, such as Claude (desktop, web or mobile) or Claude Code. Any client that supports remote MCP connectors will work.
  • The server URL (below). M


How to connect the Grip Organiser MCP

The exact steps vary slightly between AI clients, but the flow is the same everywhere: add a custom (remote) connector, point it at the Grip server URL, and authorise it with your Grip login.

  • Open your client’s connector settings. In your AI assistant, find the section for connectors, integrations or custom MCP servers (in Claude, this is under Settings → Connectors).
  • Add a custom connector. Choose to add a new remote / custom connector and give it a name, for example Grip Organiser.
  • Authorise with Grip. When prompted, sign in with your Grip credentials. This links the connector to your account and carries over your existing event permissions.
  • Confirm the tools are available. Once connected, your assistant will list the Grip tools (search_events, list_applications, get_container). Try a prompt like “list my recent Grip events” to check it responds.

 

TIP

If your organisation already distributes the Grip Organiser MCP centrally (for example through a managed connector or workspace policy), it may already appear in your client — in which case you can skip straight to authorising with your Grip login.


Understanding applications and containers

Two Grip terms appear throughout the tools, and understanding them makes the workflow intuitive:

  • Application — your event app or organiser workspace. One application can hold many events. Each has a name (e.g. the organiser or app name) that the tools use for access verification.
  • Container — a single event, identified by a numeric container_id. In Grip, “container” and “event” are used interchangeably.

The typical flow is: find the event (using search_events, which returns both the application_name and container_id), then read it (using get_container). You rarely need to know these IDs yourself — the assistant discovers them by searching first.

Available tools

The Grip Organiser MCP exposes three tools. Your assistant chooses which to call based on what you ask, so you don’t need to invoke them by name.

STEP 1 search_events — find your events

Searches for events (containers) across every application your account can access. This is usually the first step in any request. Each result includes the application_name and container_id needed to read it, plus start and end dates.

query optional — The event name you mentioned, used to rank the best match first. Omit it to list your most recent events.

SELECTOR list_applications — list your event apps

Lists the Grip applications (event apps) your account can access. Useful when you want to work within a specific app before drilling into its events. The chosen application name is then passed to get_container.

query optional — Free text (an app or event name) to rank the closest-matching application first.

STEP 2 get_container — read an event’s configuration

Fetches the live configuration for a single event from the Grip Engage backend. This is the main data-retrieval tool. You choose which parts of the configuration to return using field groups (see the next section); if you don’t specify any, it returns the general overview.

application_name required — The event / application name, used for access verification and labelling.

container_id required — The numeric event (container) ID.

fields optional — One or more field groups to fetch. Defaults to [“general”].

Field groups you can request

When reading an event with get_container, you can request any combination of the field groups below. In practice you just describe what you want in plain language — “show me the attendee types and homepage” — and the assistant maps that to the right groups.

Field group

What it returns

general

Core event details: name, start/end dates, status and key URLs (privacy, terms). The default group. Dates are returned as Unix timestamps.

general_config

Broader event settings and onboarding configuration.

simple_container_data

A lightweight summary of the event — handy for a quick overview.

style_config

Branding and visual styling (colours, assets, theme).

locale_config

Languages and translations enabled for the event.

types

The participant, company and product types configured — the “badges” attendees hold.

active_count

Counts of active records by type — a quick read on event size.

type_permissions

Networking permissions: which types can meet, message or see one another.

must_meet_config

MustMeet / Hosted Buyer setup, including groups and event phase.

homepage

The event’s landing-page layout and content blocks.

navigation

The in-app menu and navigation structure.

native_integrations

Configured native integrations (e.g. Grip Pull, A2Z, Cvent) and their latest run status.

meetings_config

Meeting and networking configuration, including meeting dates and time slots.

cpf_config

Custom profile fields and how they map to attendee data.

email_config

Email settings for the event, such as the sending domain and templates.

notification_config

Push-notification campaigns configured for the event.


Example questions to ask

Because the assistant handles the tool calls, you can stay in plain language. Some examples:

  • “Show me my most recent Grip events.”
  • “What attendee types are set up for [event], and how many are active?”
  • “Summarise the homepage and navigation for container 9716.”
  • “Which native integrations are configured for [event], and did the last sync succeed?”
  • “What meeting dates and networking permissions are set for [event]?”
  • “Is MustMeet turned on for [event], and which groups are configured?”

Troubleshooting

“Access denied” for an event

If a request returns access_denied, your Grip account doesn’t have permission for that event or application. Ask your Grip administrator to grant access, or check you’re signed in with the correct account. The assistant will not retry against other events — this is expected behaviour.

I can’t find my event

Confirm you’re authenticated with the Grip account that has access to it, then search by the exact event name. Remember the event’s container_id is its numeric ID — letting the assistant search first is more reliable than typing IDs by hand.

Dates look like large numbers

Some values in the general group are stored as Unix timestamps. Ask the assistant to show them as readable dates — it normally does this automatically.

Frequently Asked Questions

Q: Do I need to be a developer to use it?

A: No. You interact entirely in plain language through your AI assistant, and the assistant calls the tools for you. No coding or API knowledge is required.

Q: Can it change my event configuration?

A: No. The Grip Organiser MCP is strictly read-only. It retrieves configuration and data but cannot create, edit or delete anything in your event. There is no write path.

Q: What can it access?

A: Only the applications and events your Grip account already has permission to see. Access mirrors your existing Grip permissions, and the server verifies access on every request — anything outside your permissions returns access_denied.

Q: Which AI assistants work with it?

A: Any client that supports the Model Context Protocol, including Claude (desktop, web and mobile) and Claude Code. You add it as a custom / remote connector using the server URL above.

Q: What’s the difference between an “application” and a “container”?

A: An application is your event app or organiser workspace; a container is a single event within it, identified by a numeric container_id. “Container” and “event” mean the same thing.

Q: Is my data secure?

A: Requests are authenticated with your Grip login and scoped to your permissions. The connection is read-only and access is checked server-side on every call.

Q: Does it work on mobile?

A: Yes, provided your AI client supports MCP connectors on mobile.

Q: How is this different from the Grip API or webhooks?

A: The MCP is designed for AI assistants to read event configuration conversationally. Programmatic and real-time data integration is still handled through Grip’s APIs and outbound webhooks.

Still need help? Event organisers can reach the Grip team via the Grip Help Center or support@grip.events