What should teams do when MCP tool lists are user-specific?

User-Specific MCP Tool Lists as an Access-Control Problem

When MCP tool lists vary by user, the list is part of the authorization boundary, not just UI content. The server should decide which tools are visible based on the authenticated principal, current role or policy state, and the active session. That makes tool discovery a live access decision, not a static catalogue shipped once to every client.

This matters because a tool list can leak capability even if invocation is blocked later. If a user can discover a sensitive tool, they may infer internal workflows, privileged operations, or data sources that were meant to stay hidden. It also creates a misleading client experience if the catalog is cached too aggressively and outlives the user's current entitlements.

The practical design rule is to filter on the server at the point of tool enumeration, then apply the same policy again at execution time. That gives you consistency across login state, role changes, revocation, and session expiry. A user-specific list should therefore be treated as policy-generated output, not as a permanent property of the client or host application.

How to Prevent Stale or Shared Tool Visibility

Cached tool lists, shared browser sessions, and reused agent sessions are the common failure modes. If the cache key does not include the identity and the relevant entitlement context, one user can inherit another user's view of the available tools. When the role or approval state changes, the old list must be invalidated quickly enough that the client does not continue showing tools the user can no longer call.

Server-side filtering also needs to account for delegation and step-up conditions. Some tool sets are only valid for a specific role, project, tenant, or approval state, so the catalogue should be recomputed when those conditions change. That is especially important when one session can outlive the permission that originally justified access.

For implementation, the safest pattern is to bind the tool list to the same identity and session assertions that govern the rest of the request. If the server cannot reliably determine who the caller is, or whether the caller still has the right to see a tool, the catalogue should fail closed rather than degrade into a shared default view.

Why Tool Discovery Must Match Tool Invocation

User-specific discovery only works when the visible list and the executable permission model stay aligned. If the client can show tools that the backend later rejects, users will see confusing denial behaviour and integrators will build against unstable assumptions. If the backend allows more than the catalogue reveals, the UI becomes an incomplete security control and the hidden surface can still be reached through automation or direct calls.

The right model is parity: the same policy logic should govern discovery, selection, and execution. That reduces drift between what the user sees and what the system will actually accept. It also makes auditing easier because visibility decisions become part of the same access record as the action itself.

In practice, that means tool metadata, entitlement state, and session state should be treated as security inputs. When those inputs change, the catalogue should change too. Anything less creates a gap between policy intent and runtime behaviour.

Risk and Threat Considerations

User-specific tool lists can expose privileged capability, stale entitlements, or cross-session contamination if the catalogue is cached or shared incorrectly. The main risk is not just unauthorized invocation, but unauthorized discovery, because visibility itself can reveal high-value operations and encourage misuse.

Failure mechanism: The server or gateway reuses a tool list across identities, roles, tenants, or sessions, or fails to invalidate it when entitlements change. That leaves the client displaying tools that no longer belong to the active security context.

Impact: Users may infer sensitive functionality, attempt actions they should not see, or inherit access from a previous session. In agentic or delegated workflows, that can widen the blast radius of an access mistake and make revocation appear ineffective until the cache expires.

Practitioner Guidance

What to verify: Confirm that tool enumeration is recomputed from server-side policy using the current authenticated identity, role, and session state. Test the exact points where role changes, logout, token refresh, and entitlement revocation should remove tools from the list.

Common mistake: Treating the tool catalogue as a front-end convenience layer and only enforcing authorization at execution time. That leaves discovery, caching, and session reuse outside the real control boundary.

Decision rule: If a tool would be denied at execution, it should normally not appear in discovery for that session context. If a short-lived exception is needed, it should be deliberate, auditable, and tied to the same policy event that grants the privilege.

Practitioner takeaway: For MCP, the safest mental model is that tool visibility is an authorization decision with a cache lifetime, so discovery and invocation must stay policy-synchronised or the catalogue becomes a hidden source of privilege drift.

Related resources from NHI Mgmt Group

• How should organizations prioritize security in their MCP implementations?
• What is the difference between centralized MCP tool optimization and per-user tool filtering?
• Why do private MCP deployments need per-user attribution for AI tool access?
• What is the difference between RAG access and MCP tool access?