How can I return different sets of tools depending on the client?

[HQidea]

For example, I want to return tools A and B for Claude and tools C and D for Openai.

Since version 2.13, I can access the client info during the initialization phase, but the context is not ready at that point. When the context becomes ready, the client info is no longer available.

Any guidance would be appreciated. Thanks!

[bytedev999]

I would be careful about making the tool list depend on ctx, because ctx exists for individual MCP operations, while tool discovery happens earlier through list_tools.

In practice, I’d solve this one of two ways.

The simplest option is to expose separate MCP endpoints/servers per client:

/mcp/claude   -> tools A, B
/mcp/openai   -> tools C, D

[scastria]

This is a builtin feature of fastmcp. You can use the AuthMiddleware and the check_auth callback which is called for every tool in list/tools. This check_auth callback is provided an AuthContext which contains the user's token. This allows you to inspect the token and compare its claims against the tool being checked and return True or False to show or hide it.

[Michael-WhiteCapData]

The important distinction is identity versus client software.

If A/B and C/D are permissions, do not key them from the reported client name ("Claude" versus "OpenAI"). Client information is self-asserted and is not an authorization boundary. Put the entitlement in a validated access-token claim/scope and let AuthMiddleware filter discovery and direct calls consistently.

This HTTP example assumes auth_provider is a configured token verifier or authentication provider. Authorization middleware does not establish authentication by itself, and current FastMCP skips these checks for stdio.

from fastmcp import FastMCP
from fastmcp.server.middleware import AuthMiddleware
from fastmcp.utilities.authorization import AuthContext

async def allowed(ctx: AuthContext) -> bool:
    if ctx.token is None:
        return False
    audience = ctx.token.claims.get("tool_profile")
    required = (ctx.component.meta or {}).get("profile")
    return required is None or required == audience

mcp = FastMCP("server", auth=auth_provider, middleware=[AuthMiddleware(auth=allowed)])

@mcp.tool(meta={"profile": "claude"})
def tool_a(): ...

@mcp.tool(meta={"profile": "openai"})
def tool_c(): ...

The exact metadata field can be your own convention; the key property is that the check is based on a verified token and runs for both listing and invocation, so hiding a tool is not the only defense.

If this is compatibility rather than permission — for example, one host cannot render a component type — separate endpoints/providers are clearer and easier to test. A client name may be useful for telemetry or a compatibility workaround, but it should not decide what data/actions that caller is authorized to reach.

Current implementation and examples: FastMCP authorization middleware.

Edit, October 6: made the authentication prerequisite explicit, handled missing tokens, and documented the stdio exception.