MCP Tools Need More Than a Login: Designing Coach Access

Authentication establishes an identity under a particular credential. It does not by itself establish that the person is a coach, belongs to an organisation or has an accepted relationship with the requested client. Treating those questions as equivalent creates a product that can look correct in a single-account demo and fail as soon as multiple roles exist.

A useful operation begins by determining the caller and then resolving the specific permission. The result should not depend on a model politely following an instruction. The application must enforce the boundary even when an operation is called directly or the assistant chooses an unexpected sequence.

Separating client and coach tool surfaces helps each audience understand the available tasks. It also reduces accidental confusion about what a tool is intended to do. But hiding a tool from a menu is not sufficient enforcement; the server still needs to reject an unauthorised caller.

This distinction resembles frontend navigation. A sub-coach may not see an organisation-wide page, but removing its link does not protect the underlying data. The same principle applies when the interface is a language model. Discoverability is a usability choice. The service must remain the source of permission.

An invitation, a pending connection and an accepted coaching relationship represent different states. A coach who has merely invited someone should not automatically gain access to that person’s history. An archived relationship may need a different policy from an active one.

The documented coach integration uses accepted relationships and role-aware access rather than assuming that a known client identifier is enough. This is a general pattern: resolve access at the time of the operation and make the relationship state explicit. A credential issued earlier should not freeze a business relationship forever.

A newly accepted relationship does not necessarily justify reading everything a person recorded before it began. A product can choose a coaching start date as the lower bound for visible history. That decision should be consistent across the portal and conversational tools.

The frontend then needs to communicate the boundary honestly. An empty history may mean no records fall within the permitted period, not that the person never logged anything. A helpful answer explains the available scope instead of inventing missing context. The point is not to reveal internal access rules in detail; it is to make the user-facing meaning understandable.

For changes that affect a client, a preview can show the proposed edit before commitment. That is useful even when the operation is relatively small because it surfaces misunderstandings before they become saved state. The preview must still be bound to the intended resource and revalidated when executed.

An important limitation in the documented integration is that confirmation inside the same AI conversation is not an independent approval channel. The host model may participate in generating the next tool call. I would never describe that mechanism as equivalent to a separate human-controlled approval interface unless the application actually enforces such a boundary.

A teaching matrix can use fictional people: one coach, a teammate, an accepted client and a pending invitation. Explain which kinds of task should be available and why. There is no need to publish actual record identifiers, tool schemas or production routing details to make the lesson concrete.

A useful example also includes refusal. “I cannot access that client under this account” is a valid product outcome, not a failure to be hidden. A refusal should avoid revealing whether an unrelated person exists. The assistant can explain the next authorised step without leaking information about another account.

The MCP specification discusses security considerations such as binding credentials to intended resources and avoiding unsafe token handling. Those protocol concerns matter, but they do not replace business-level access rules. Correctly transported credentials can still be applied to an incorrectly authorised operation.

Conversely, a well-designed relationship model does not justify improvising an OAuth flow. Follow the current protocol and client documentation for transport and authorisation mechanics. Keep those responsibilities separate enough to test independently. This article discusses the design principles, not a certification of every supported chat client or integration version.

A useful test set includes a pending invitation, an accepted relationship, an archived connection, a role change and a request outside the visible history period. It should exercise both reads and writes. The important question is whether the same boundary holds when the interface changes.

I would also test that a preview does not silently grant later access after a relationship is revoked. Approval and permission are separate checks. The operation may have been understandable and previously allowed, yet no longer be authorised when execution occurs. That is a normal lifecycle event that a trustworthy product needs to handle.

Does a signed-in coach automatically see every organisation client? Only if the product’s role policy explicitly permits it. Team membership, head-coach powers and assigned-client access should be defined rather than inferred from a label.

Can I enforce permissions in a prompt? A prompt can explain expected behaviour, but the application must enforce the actual boundary. The model should not be the only defence between unrelated accounts.

Should every user-facing action become an MCP tool? Not necessarily. Expose operations that have clear inputs, useful outcomes and enforceable permissions. A smaller, understandable tool surface can be easier to use and review than a complete mirror of every internal method.