Skip to main content
The Proxy Provider sources components from another MCP server through a client connection. This lets you expose any MCP server’s tools, resources, and prompts through your own server, whether the source is local or accessed over the network.

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 using create_proxy():
This gives you:
  • Safe concurrent request handling
  • Automatic forwarding of MCP features (sampling, elicitation, etc.)
  • Session isolation to prevent context mixing
To mount a proxy inside another FastMCP server, see Mounting External Servers.

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 an initialize 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:
Or expose a local server via HTTP:

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:
Shared sessions may cause context mixing in concurrent scenarios. Use only in single-threaded situations or with explicit synchronization.

MCP Feature Forwarding

Proxies automatically forward MCP protocol features:

Disabling Features

Selectively disable forwarding:

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:
This eliminates the MCP initialization handshake on every call, which can dramatically reduce latency under load. The Client uses reference counting for its session lifecycle, so concurrent callers sharing the same instance is safe.
Only reuse sessions when you know the backend is stateless (e.g. stateless HTTP). For stateful backends (stdio processes, servers that track session state), use the default fresh-session behavior to avoid context mixing.

Advanced Usage

FastMCPProxy Class

For explicit session control, use FastMCPProxy directly:
This gives you full control over session creation and reuse strategies.

Adding Proxied Components to Existing Server

Mount a proxy to add components from another server: