HockeyStick Knowledge Base Knowledge Base Open Command Centre

MCP server and AI apps

Giving people access and linking accounts

Who can connect, how the first sign-in links by verified email, and how staff pick a client with engagement_id.

Giving people access and linking accounts

There is no per-organisation MCP switch to flip. If a person is an active HockeyStick user and their app is supported in that environment, they can connect. Your job is making sure the right people are invited with the right email, and that the client has Activate if they want brief and revenue tools.

Who can connect

  • Any active user with the role client, admin or consultant.
  • The person must already exist in HockeyStick. The MCP never creates users. Invite them first from the client's Users tab (see Inviting contacts).
  • On Claude Team or Enterprise, the customer's own Claude administrator must add the connector in Claude's organisation settings first.

The old manual "Verify my account" step in Settings has been removed. Linking now happens on the first tool call:

  1. The user signs in through the AI app with the email code.
  2. On the first call, the MCP checks the identity came from the email connection and the email is verified.
  3. It looks for exactly one active HockeyStick user with that email and links them. The audit log records first_call_link with the result linked.

From then on the user shows as Linked in the Login migration column on the Command Centre Users page, and in their own Settings > Connected AI apps card.

When linking is refused

CodeCause
account_not_foundNo HockeyStick user has that email. The message names the email and asks them to get an invite.
identity_untrustedThey used a password or Google sign-in, not the email code.
identity_unverifiedThe email was not verified.
identity_conflictMore than one match, the account is already linked to a different identity, or the account was revoked and its identity is reserved.
connection_disconnectedAI apps were disconnected for this account.

Staff and engagement_id

Admins and consultants see every client their role already reaches. list_clients returns the account and the visible clients. Staff must pass that client's engagement_id on each call. The selection is per request and is never saved, so a new chat starts with no client chosen. An engagement_id the person cannot access is refused (ENGAGEMENT_FORBIDDEN), and one that does not match the brief or partner being read is refused too.

Client users never need engagement_id; their organisation is used automatically.

Activate and funding

Brief, revenue and programme tools need the client's Activate product allocated or active, otherwise ACTIVATE_REQUIRED. Where generation accounting is switched on, Webinar and Event generation can also be refused with GENERATION_FUNDING_UNAVAILABLE until the client's agent access licensing and credit are in place.