What this guide answers
- Do we need a developer to set this up?
No. Creating the token is a normal admin-page action, and connecting the assistant is pasting one command.
- Which AI assistants work with it?
Anything that speaks MCP over HTTP and lets you set an authorisation header — the standard is open, but that second half is the part that decides it.
- Can the assistant see personal member details?
The membership tool returns aggregates — counts by status and payment standing — not names, emails or medical details.
- What happens if someone steals the token?
They'd hold a time-limited key that can't sign in to the admin, can do only what you ticked when you made it, can't send an email or an SMS or move any money whatever you ticked, is rate-limited, logs every action to…
Ireland edition. This guide is written for volunteer-run clubs in Ireland. Where rules differ — grants, tax, incorporation, safeguarding — follow the Ireland-specific pointers below or check with your national body.
AI assistants stopped being a novelty the day they learned to use tools. An assistant that can read your actual club data — members, orders, pages, fixtures — answers a different class of question than one that can only talk in general terms. "How should a club chase lapsed members?" is a blog post. "Which of our members lapsed, and draft the renewal email" is an afternoon of committee work done before the kettle boils.
The technology that makes this possible is called the Model Context Protocol (MCP) — an open standard that lets an AI assistant connect to a piece of software and use a defined, permission-checked set of tools. This guide explains how it works in plain language, then walks through connecting an assistant to a ClubHelix club step by step, with the guardrails a volunteer committee should insist on.
What MCP is, in club terms
Think of MCP as a service hatch for your club platform. Instead of giving an assistant your password and letting it wander around the admin (never do this), the platform opens a small, well-lit hatch with a fixed menu of things an assistant may ask for: summarise the membership, list recent orders, fetch this page's content, save a draft news post. Everything not on the menu simply doesn't exist as far as the assistant is concerned.
Three properties make this club-safe:
- The menu is fixed by the platform, not the assistant. An assistant can't invent a "delete all members" option; if the platform didn't put it on the menu, it can't be asked for.
- Every request is authenticated and permission-checked. The connection uses a token tied to a named admin, and each request is re-checked against that person's current role — not the role they had when the token was created.
- It's revocable in one click. Lose a laptop, or just finish the project? Revoke the token and the connection is dead everywhere, instantly.
What a connected assistant can do in ClubHelix
ClubHelix's MCP endpoint gives a connected assistant two kinds of tools:
Reading (always available): more than seventy read tools covering the club — membership summaries (totals and paid-up counts, aggregate numbers rather than personal details), orders and payments, events and fixtures, forms, facilities, programs, email deliverability, your website's pages and their content, and a search over the club's own audit log.
Changing and publishing (only what you tick): the connection has two tick boxes, and they split the decision where it matters to a club. Allow changes lets an assistant create and edit pages, news posts and events — a draft news post waiting in the News admin, a draft email waiting unsent in the broadcasts composer, a page edit offered in the page editor as a proposal to restore or discard. It cannot publish or unpublish, so it can never put something new on your site or take something off it — and on your website's pages, even an edit to a live one is refused and handed back as a draft. Allow publishing is the separate, deliberate step that lets it make that work public and take it down again. Leave it off and publishing stays a human decision. Whichever you tick, every change is shown to you as a plan and confirmed before it happens — an assistant cannot act on your club by surprise.
One line is worth having in front of the committee, because it is structural rather than a setting: there are more than 200 tools on the connection and not one of them sends an email or an SMS, takes a payment or issues a refund. An assistant you have allowed to publish a page still cannot mail a single member. Choosing how far to go is its own conversation — which scope to give an AI assistant walks a committee through it.

Before you connect: three questions for the committee
- Who is the named owner? The connection acts as one admin. Pick someone accountable (secretary or registrar, usually), because the audit log will record the assistant's activity under their name.
- Read-only, or changes too? Start read-only. Tick Allow changes once the committee has seen a month of useful answers and understands the review workflow, and treat Allow publishing as a third, later decision rather than part of the same one.
- What's the expiry? Treat tokens like keys to the clubhouse: 90 days is a sensible default, with a calendar note to re-issue. "Never expires" is for clubs that also never change the padlock code.
Step by step: connecting Claude to a ClubHelix club
You'll need to be a full admin of your organisation — on any plan, including the free one (see pricing) — and an MCP-capable assistant. Claude is the one we test against.
- Create the token. In your club admin, open System → API & webhooks and find AI assistant access (MCP). Name the token after where it will live ("Claude on the secretary's laptop"), pick an expiry (90 days is the default), and leave both Allow changes and Allow publishing unticked for now. Click Create token.
- Copy it immediately. The token is shown exactly once, then only a fingerprint is stored — the same one-time rule as an API key. If you lose it, revoke and re-create.
- Add the connection in the assistant. The page shows the exact command for Claude; it boils down to giving the assistant your club's MCP address plus the token in an authorisation header. Paste the command into a terminal (or follow your assistant's "add connector" screen) and you're done. The token travels in the connection settings — never paste it into a chat message.
- Test it. Ask: "Who are you connected as, and what can you see?" The assistant should report your club, the named admin, and a read-only scope. Then try a real question: "Summarise our membership."
- (Later) allow changes. When the committee is ready, create a second token with Allow changes ticked and revoke the first. Ask the assistant to draft a news post about the weekend's results — then go and find it waiting, unpublished, in your News admin. If you want it to touch one area and no other, open Limit what this token can touch and tick only that area: the news page without the shop.

The security model, for whoever asks hard questions
Every committee has one person who (rightly) asks "but what stops it doing X?" Here is the honest answer for ClubHelix, in their language:
- Scoped to your club only. A club-issued token is pinned to your organisation. Ask the assistant about any other club and the request is refused — first by the application, and beneath that by the same row-level database security that separates every club's data on the platform. There is no configuration in which your token reads someone else's members, or theirs reads yours.
- It stops working when you do. Every single request re-checks that the token's owner is still an admin of the club. Demote that admin, or revoke the token, and the connection dies mid-conversation. Changing your plan does not affect it — assistant access is not plan-gated.
- Rate-limited and logged. Requests are throttled per token, and every read and draft is written to the club's audit log with the owner's name and the token used.
- No passwords involved. The token isn't your password and can't be used to sign in to the admin. It opens the service hatch and nothing else.
Our AI safety and privacy checklist generalises these into questions you can put to any vendor, not just us.
What to actually use it for
The clubs getting value from a connected assistant use it for unglamorous things, weekly:
- Committee prep: "Give me the numbers for Thursday: membership by status, anything unshipped in the shop, and what changed in the audit log this week."
- Renewal season: "How many members lapsed versus this time last season? Draft the renewal email." (Draft — the registrar picks the audience and sends.)
- Website hygiene: "List our pages and flag any that still mention the old venue. Draft corrected versions of the two worst."
- Handover: an incoming secretary can simply ask how things stand instead of reverse-engineering a predecessor's spreadsheets — a genuine fix for the no-time club problem.
Frequently asked questions
Do we need a developer to set this up?
No. Creating the token is a normal admin-page action, and connecting the assistant is pasting one command. If your club has ever set up a club email address, this is easier.
Which AI assistants work with it?
Anything that speaks MCP over HTTP and lets you set an authorisation header — the standard is open, but that second half is the part that decides it. We test against Claude in the terminal, and the connection screen shows the exact command for it. A chat app whose connector screen only takes a web address and then tries to sign you in cannot connect, because there is no sign-in flow here to complete. Setting up the connection in each kind of tool goes through what to look for.
Can the assistant see personal member details?
The membership tool returns aggregates — counts by status and payment standing — not names, emails or medical details. Order listings show what an admin would see on the orders screen, because the token acts as that admin. The principle throughout: the assistant can never see more than the person it acts for, and usually sees far less.
What happens if someone steals the token?
They'd hold a time-limited key that can't sign in to the admin, can do only what you ticked when you made it, can't send an email or an SMS or move any money whatever you ticked, is rate-limited, logs every action to your audit trail, and dies the moment you press Revoke — or the moment the owner's admin role is removed. Compare that with what a stolen admin password could do, and the design goal is obvious: make the AI path safer than the human path it replaces.