How Canadian clubs connect their data to Claude, ChatGPT and other AI tools

Canada edition. This guide is written for volunteer-run clubs in Canada. Where rules differ — grants, tax, incorporation, safeguarding — follow the Canada-specific pointers below or check with your national body.

There is one question that decides whether any AI tool can connect to your club, and you can answer it before you touch a single setting. Can the tool take a custom Authorization header, or let you paste a static token? If yes, it connects. If it only takes a URL and then runs a sign-in flow — the screens usually call it OAuth — it cannot. It will end up asking you for an authorisation code, and nothing on our side can issue one.

That is not a gap waiting to be filled. ClubHelix's assistant endpoint deliberately publishes no OAuth metadata: a request without a valid token is refused with a plain 401, and a client that reads that refusal as "this server wants me to start a sign-in" will walk you into a dead end. Knowing the rule first saves you the twenty minutes of clicking that ends there.

So the shape of this guide is simple. Tools that take a header work, and we give you the exact configuration for the main ones. Tools that insist on a sign-in do not, and we tell you what that failure looks like so you recognise it in the first thirty seconds rather than the last.

What you need before you start

Three things, and you will already have the first if you have read how to connect an AI assistant to your club data.

A connection token. Mint it in your club admin under System → API & webhooks, in the card headed AI assistant access (MCP). Name it after where it is going to live — the placeholder even suggests something like "Claude on the secretary's laptop" — pick an expiry, and decide whether to tick Allow changes (create and edit pages, news, events) and Allow publishing (make changes visible to the public). Both unticked is a read-only connection, which is where every club should start.

The endpoint. It is the same for every club and every tool:

https://clubhelix.com/api/mcp

No particular plan. Assistant access works on every plan we offer, including the free one — see pricing for what each plan includes. What a token can never do, on any plan, is change your subscription: plans, billing and payment settings are platform-staff tools and no organisation token reaches them.

One warning that matters more than any of the configuration below: the token is shown exactly once. Copy it into a password manager the moment it appears, because the screen will not show it again. It is stored hashed, so nobody — including us — can read it back to you. Lose it and you revoke it and mint another, which takes about fifteen seconds and is genuinely fine.

Claude Code: the path we test against

This is the fully verified route, and it is the one our own admin page prints for you. Open the Connect Claude Code panel in the token card and it shows this command with your endpoint already in place:

claude mcp add --transport http clubhelix https://clubhelix.com/api/mcp --header "Authorization: Bearer YOUR_TOKEN"

Replace YOUR_TOKEN with the token you copied. The short flags work identically if you prefer them — -t for --transport and -H for --header. The full flag reference lives in the Claude Code MCP documentation.

Where that configuration lands is controlled by the scope flag:

• --scope local is the default, and writes to your personal ~/.claude.json. The connection is yours, on this machine.
• --scope project writes to .mcp.json in the repository you are in. Useful when a small group shares a working folder — but read the token warning below before you go near it.
• --scope user makes the connection available to you across projects on that machine.

For a club officer with one laptop, the default is right and you can ignore the flag entirely.

The reason this path is the reliable one is a documented behaviour rather than luck. Claude Code does not fall back to a sign-in flow once you have set a custom header, and it reports a 401 or 403 as a failed connection rather than as "this server needs authentication". So a wrong token fails loudly and immediately, instead of bouncing you into a sign-in that could never have completed. That is exactly the behaviour a static-token server like ours needs, and it is why we point clubs here first.

An editor or desktop client that uses a JSON config file

Several tools — VS Code and the editors and desktop clients that copied its shape — configure assistant connections in a small JSON file rather than on a command line. In VS Code the file is .vscode/mcp.json inside your project, or your personal profile copy, which the editor opens for you through the MCP: Open User Configuration command.

The shape is a servers object, a name of your choosing, and then the connection details:

{
  "servers": {
    "clubhelix": {
      "type": "http",
      "url": "https://clubhelix.com/api/mcp",
      "headers": {
        "Authorization": "Bearer ${input:clubhelix-token}"
      }
    }
  }
}

Two things to take from that block rather than copy blindly.

Do not put the token itself in the file. VS Code's own documentation is blunt about it — "Avoid hardcoding sensitive information like API keys" — and points you at input variables instead, which is what the ${input:clubhelix-token} placeholder above is. Configured that way, the editor prompts you for the token once and keeps it out of the file. This matters most for the project-scoped config: a JSON file inside a shared folder is a file that gets copied, zipped, emailed and occasionally committed to a repository, and a token that leaks that way is a working key to your club admin.

Field names vary slightly between clients. The servers → name → type and url structure is stable and widely copied, but the block that carries the header is where clients differ: some call it headers, some spell the transport differently, some expose the header through a settings panel instead of the file. If yours does not accept the block above verbatim, that is normal — go to that tool's current documentation and look for the place it lets you set a request header. Everything else you need is already in this guide.

Calling it from the OpenAI API

If you are wiring the connection into something you are building yourself rather than into a chat client, the OpenAI API accepts a tool of type: "mcp". The documented fields are server_label, server_url, and optionally server_description, allowed_tools, require_approval and authorization:

{
  "type": "mcp",
  "server_label": "clubhelix",
  "server_url": "https://clubhelix.com/api/mcp",
  "require_approval": "always",
  "authorization": "YOUR_TOKEN"
}

Be precise about what that last field is. OpenAI documents no headers field on this tool, and documents authorization as carrying an access token issued by a sign-in flow. It is the field a bearer value goes in. We are not claiming OpenAI has blessed pasting a long-lived static token there — we are telling you where the bearer value belongs in the shape they publish, and leaving the judgement about whether that suits your build to you.

allowed_tools is worth a look while you are there. It lets the caller narrow which tools the model may reach for, which pairs neatly with the narrowing you can already apply to the token itself under Limit what this token can touch. Two independent limits, both of which can only ever take capability away.

Anything else, including the connector screens in chat apps

This is the honest section, and it is short on purpose.

Plenty of AI products now have a screen for adding a connection — a connectors page, an integrations tab, a "custom MCP server" dialog. We are not going to describe the fields or the click path on any of them, including the connector screen in ChatGPT. The reason is not coyness: we could not find a primary source from the vendor stating which authentication options those screens offer, and the third-party write-ups that describe them contradict each other. Publishing a click-by-click walkthrough of somebody else's settings screen based on that would be guessing in a confident voice, and those screens change often enough that even an accurate walkthrough goes stale within weeks. So we describe the shape, and you check the vendor's current documentation for the clicks.

Here is the shape to look for, and it is the rule from the top of this guide applied with your own eyes:

Look for somewhere to paste a token, or to set a request header. We are not going to guess what your tool calls that field, because the names differ between products and change between releases — but if the screen offers you one, paste your token there as the bearer value, point the connection at https://clubhelix.com/api/mcp, and you are connected.

Watch for the failure. If the screen takes only a URL and then immediately sends you to a sign-in page, or asks you to paste back an authorisation code, stop. That tool is attempting a sign-in flow, ClubHelix publishes nothing for it to sign in against, and no amount of retrying changes that. Use a tool that lets you set the header — Claude Code is the one we test against and the one our admin page prints a command for.

Then go to the vendor's own current documentation for the exact field names and the current click path. We would rather send you to a page that is right this week than print one that was right the week we published.

Check that it worked

Do not assume a connection is live because a settings screen went green. Ask the assistant a question that only a real connection can answer:

Who are you connected as, and what can you see?

A working connection answers with your organisation's name, the admin whose token it is using, and the scope that token carries. If it tells you which club it is looking at, you are connected to the right club — the token is pinned to one organisation and cannot reach another, so a wrong name here means a wrong token rather than a wrong setting.

Then ask something real:

Summarise our membership.

You should get counts — totals and payment standing — rather than a list of people. That is deliberate: the member-facing tools return aggregate numbers, not names, email addresses or medical details. If that answer arrives, the connection is doing its job.

When it does not work

Six failures cover almost everything, and each one tells you what to change.

You are asked to sign in, or for an authorisation code. The client is trying an OAuth sign-in. There is nothing to fix at our end and nothing to fix at yours — switch to a client that lets you set a custom header.

You get a 401. The token itself is the problem: mistyped, expired, or revoked. Check it against the token list on the admin page, and mint a new one if in doubt — the value is only ever shown once, so a half-copied token is the usual culprit.

You get a 403 saying the owner is no longer an admin. The token is fine; the person it belongs to is not an admin of the club any more. This catches people out and is working as intended: the platform re-checks the owner's role on every single request, so a committee handover quietly kills the connection the moment the role changes. Mint a fresh token under whoever holds the role now.

You are refused a particular job with a message about your plan. The connection itself is not plan-gated, but individual modules still are — asking an agent to switch on something your plan does not include is refused with the plan named, rather than quietly writing a row that changes nothing.

A refusal that names a permission. The token was narrowed when it was minted, or its owner does not hold that permission themselves. Remember that the token acts as its minting user and can never do more than that person can — so check the person's permissions first, then the token's. Which scope to give an AI assistant walks a committee through choosing those limits.

Nothing at all, from any tool. There is a platform-level switch that turns the whole assistant endpoint off. If every tool and every token is dark at once, that is the likeliest cause, and it is ours to look at rather than yours.

One more that is not a fault but looks like one: the connection is rate-limited at 120 requests a minute per token. A person asking questions will never come near it; a script in a loop will.

Keep the token where it belongs

The single rule worth printing out: the token goes in the tool's configuration, never into a conversation. Do not paste it into a chat message to the assistant, a group message to the committee, or a shared document. A token is a key to the clubhouse — it acts as a named admin, and the club's audit log records everything it does under that person's name.

There is one limit worth knowing rather than discovering. A connection token, like any API token, bypasses the browser's two-factor step-up — it is a key that works on its own, without the second factor a person is asked for when they sign in to the admin. That is precisely why the platform makes it expire, makes it revocable in one click, and records everything it does in the audit log. Those three controls are what stand in for the step-up, so treat them as the safeguard rather than as paperwork.

The defaults are on your side. Expiry defaults to 90 days, which is short enough that a forgotten token retires itself and long enough not to be a nuisance. Revoking is one click and takes effect everywhere at once. And the platform's structural limits hold no matter which tool you connected: every change is dry-run and shown to you as a plan before it happens, and of the more than 200 tools on the connection, not one 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.

That is worth pausing on, because it is the difference between a policy and a guarantee. Read more about how we handle credentials and access on our security page, and about what the connection exposes on the AI agent access feature page.

Frequently asked questions

Which AI tools can actually connect to ClubHelix?

Any tool that lets you set a custom Authorization header or paste a static token. Claude Code is the verified path and the one our admin page prints a command for. Code editors and desktop clients that use a JSON config file work too, as long as the file or its settings panel gives you somewhere to put a header. Tools that accept only a URL and then run a sign-in flow cannot connect, because we publish no sign-in metadata for them to use.

Why does my AI tool keep asking me to sign in to ClubHelix?

Because it is trying a sign-in flow rather than reading the token you gave it. Our endpoint refuses an unauthenticated request with a plain 401 and offers no sign-in metadata, so a client built to start a sign-in at that point will ask you for an authorisation code that nothing here can issue. It is not a misconfiguration you can correct — use a client that takes a header.

Can I put the token in a config file my committee shares?

You can, and you should think hard first. A shared config file gets copied, zipped and occasionally committed to a repository, and the token in it is a working key to your club admin acting as one named person. The better pattern is the one the editors themselves recommend: use an input variable so the tool prompts for the token and keeps it out of the file. If you do share a connection, mint a token for that purpose with a short expiry and only the permissions it needs.

What happens to the connection when our secretary steps down?

It stops working, immediately and without anyone remembering to do anything. The token acts as its minting user and the platform re-checks that person's role on every request, so the moment they lose the admin role the connection is dead. Mint a new token under the incoming officer. This is also why the audit trail is readable: every action the assistant took is recorded against the real person whose token it was.

Do I need to be a developer to set this up?

For Claude Code, no — you copy one line from the admin page, paste your token into it, and run it. For the JSON config route you need to be comfortable editing a small text file, which is a lower bar than it sounds. The OpenAI API route is for people building something, and if that is not you, you do not need it.