Why Use Proxy Provider
The Proxy Provider enables:- Bridge transports: Make an HTTP server available via stdio, or vice versa
- Aggregate servers: Combine multiple source servers into one unified server
- Add security: Act as a controlled gateway with authentication and authorization
- Simplify access: Provide a stable endpoint even if backend servers change
Quick Start
Create a proxy usingcreate_proxy():
- Safe concurrent request handling
- Automatic forwarding of MCP features (sampling, elicitation, etc.)
- Session isolation to prevent context mixing
Connection Semantics
FastMCP proxies are lazy bridges. Creating the proxy object and starting the local server do not contact the upstream server. The upstream connection begins when an MCP client sends aninitialize request to the proxy.
During initialization, the proxy initializes the upstream server before responding locally. If the upstream server is unavailable, the URL does not point to an MCP endpoint, or upstream authentication cannot complete, the proxy initialization fails. This keeps the local proxy’s connection status aligned with the upstream server it represents.
After initialization, the proxy forwards MCP requests such as ping, tools/list, resources/list, prompts/list, tool calls, resource reads, sampling, elicitation, logging, and progress through the upstream client.
Transport Bridging
A common use case is bridging transports between servers:Session Isolation
create_proxy() provides session isolation - each request gets its own isolated backend session:
Shared Sessions
If you pass an already-connected client, the proxy reuses that session:MCP Feature Forwarding
Proxies automatically forward MCP protocol features:Disabling Features
Selectively disable forwarding:Tool Results Are Relayed, Not Inspected
A proxy passes a backend’s tool results through untouched, including results that don’t match the output schema the backend advertised. Deciding whether a server honored its own contract belongs to the client consuming the result, and that client validates for itself. This matters when a backend’s declared schema is subtly wrong — an enum missing a variant it actually returns, say. A proxy that enforced the schema would replace the backend’s working response with an error of its own, and the client would never see what the backend actually said.tools/list round trip to the backend on every proxied call, since validation would need the backend’s schemas and a proxy builds a fresh connection per request.
Protocol Era Mirroring
A proxy is a server on its front and a client on its back, and the two MCP protocol eras have mutually exclusive interaction models on a single session. On the handshake era (≤2025-11-25) the backend can push server-initiated requests — sampling, elicitation, roots — which the proxy forwards to your client. On the modern era (2026-07-28) those pushes are gone; a backend guard tool instead returns an input request that the proxy relays back as a result. A single proxy session speaks one era, so the whole chain has to agree end-to-end. By default the proxy relays the era: whatever era your client negotiates on the front, the proxy negotiates the same era on its backend connection, per request. A handshake client reaches a handshake backend, so server-initiated forwarding works; a modern client reaches a modern backend, so a guard tool’s input request round-trips. Different clients hitting the same proxy each get a backend session in their own era — the eras never cross.mode pins the backend to one era regardless of the client:
FastMCP instance); when you hand create_proxy an already-configured Client, that client carries its own mode and mirroring does not override it.
A multi-server configuration adds a hop: FastMCP mounts one proxy per configured server onto a router, and your client talks to that router rather than to any backend directly. The era carries through the whole depth, so each real backend negotiates the era your client did — not just the router in front of them.
weather and calendar on modern sessions, so a guard tool on either one round-trips end to end. An explicit mode pins every backend in the configuration, the same way it pins a single one.
Configuration-Based Proxies
Create proxies from configuration dictionaries:Multi-Server Proxies
Combine multiple servers with automatic namespacing:Component Prefixing
Proxied components follow standard prefixing rules:Mirrored Components
Components from a proxy server are “mirrored” - they reflect the remote server’s state and cannot be modified directly. To modify a proxied component (like disabling it), create a local copy:Performance Considerations
Proxying introduces network latency:
When mounting proxy servers, this latency affects all operations on the parent server.
Component List Caching
ProxyProvider caches the backend’s component lists (tools, resources, templates, prompts) so that individual lookups — like resolving a tool by name during call_tool — don’t require a separate backend connection. The cache stores raw component metadata and is shared across all proxy sessions; per-session visibility, auth, and transforms are still applied after cache lookup by the server layer. The cache refreshes whenever an explicit list_* call is made, and entries expire after a configurable TTL (default 300 seconds).
For backends whose component lists change dynamically, disable caching by setting cache_ttl=0.
Session Reuse for Stateless Backends
By default, each tool call opens a fresh MCP session to the backend. This is the safe default because it prevents state from leaking between requests. However, for stateless HTTP backends where there’s no session state to protect, this overhead is unnecessary. You can reuse a single backend session by providing a client factory that returns the same client instance:Client uses reference counting for its session lifecycle, so concurrent callers sharing the same instance is safe.
Advanced Usage
FastMCPProxy Class
For explicit session control, useFastMCPProxy directly:

