FastMCP from OpenAPI - is the httpx.AsyncClient shared?

[MicaelJarniac]

import httpx
from fastmcp import FastMCP

# Create an HTTP client for your API
client = httpx.AsyncClient(base_url="https://api.example.com")

# Load your OpenAPI spec 
openapi_spec = httpx.get("https://api.example.com/openapi.json").json()

# Create the MCP server
mcp = FastMCP.from_openapi(
    openapi_spec=openapi_spec,
    client=client,
    name="My API Server"
)

https://gofastmcp.com/integrations/openapi#create-a-server

If the external API returns cookies, for example, are those saved on the shared httpx.AsyncClient, and therefore shared among all MCP users, or is there some sort of separation per user of the MCP server?

[MicaelJarniac]

From my testing, it seems like cookies aren't shared. Is there anything else that could be shared between different users?

[Michael-WhiteCapData]

Yes — the client passed to FastMCP.from_openapi(..., client=client) is shared.

The provider stores that exact client, and every generated OpenAPI tool gets the same object. In the current implementation each tool calls self._client.build_request(...) and then sends through self._client: OpenAPITool source.

That means these are shared across concurrent MCP callers:

• the connection pool (desirable);
• client-level headers, auth, hooks and limits;
• the client's mutable cookie jar (usually undesirable for per-user sessions).

If an upstream response sets a cookie matching the later request's domain/path, HTTPX stores it in the client's jar and can send it on a later request made for another MCP user. A test that appears not to share cookies often has a domain/path mismatch, or the backend did not actually return a valid Set-Cookie.

So I would not use that shared cookie jar as the identity boundary for a multi-user MCP server. Prefer a stateless credential on each upstream request, derived from the authenticated MCP principal. If the upstream requires cookie sessions, partition clients by a trusted tenant/user key and manage their lifetime explicitly; do not mutate or clear one global client's cookies around a request, because concurrent calls can interleave.

A small regression test is worth adding: have a mock upstream set a cookie for caller A, then issue caller B's generated-tool request and assert the cookie is absent. That tests the isolation property rather than just successful requests.