Client Transports
Understand the different ways FastMCP Clients can connect to servers.
New in version:Â 2.0.0
The FastMCP Client
relies on a ClientTransport
object to handle the specifics of connecting to and communicating with an MCP server. FastMCP provides several built-in transport implementations for common connection methods.
While the Client
often infers the correct transport automatically (see Client Overview), you can also instantiate transports explicitly for more control.
Clients are lightweight objects, so don’t hesitate to create new ones as needed. However, be mindful of the context management - each time you open a client context (async with client:
), a new connection or process starts. For best performance, keep client contexts open while performing multiple operations rather than repeatedly opening and closing them.
Choosing a Transport
Choose the transport that best fits your use case:
-
Connecting to Remote/Persistent Servers: Use
StreamableHttpTransport
(recommended, default for HTTP URLs) orSSETransport
(legacy option) for web-based deployments. -
Local Development/Testing: Use
FastMCPTransport
for in-memory, same-process testing of your FastMCP servers. -
Running Local Servers: Use
UvxStdioTransport
(Python/uv) orNpxStdioTransport
(Node/npm) if you need to run MCP servers as packaged tools.
Network Transports
These transports connect to servers running over a network, typically long-running services accessible via URLs.
Streamable HTTP
New in version:Â 2.3.0
Streamable HTTP is the recommended transport for web-based deployments, providing efficient bidirectional communication over HTTP.
Overview
- Class:
fastmcp.client.transports.StreamableHttpTransport
- Inferred From: URLs starting with
http://
orhttps://
(default for HTTP URLs since v2.3.0) that do not contain/sse/
in the path - Server Compatibility: Works with FastMCP servers running in
streamable-http
mode
Basic Usage
The simplest way to use Streamable HTTP is to let the transport be inferred from a URL:
You can also explicitly instantiate the transport:
Authentication with Headers
For servers requiring authentication:
SSE (Server-Sent Events)
New in version:Â 2.0.0
Server-Sent Events (SSE) is a transport that allows servers to push data to clients over HTTP connections. While still supported, Streamable HTTP is now the recommended transport for new web-based deployments.
Overview
- Class:
fastmcp.client.transports.SSETransport
- Inferred From: HTTP URLs containing
/sse/
in the path - Server Compatibility: Works with FastMCP servers running in
sse
mode
Basic Usage
The simplest way to use SSE is to let the transport be inferred from a URL with /sse/
in the path:
You can also explicitly instantiate the transport for URLs that do not contain /sse/
in the path or for more control:
Authentication with Headers
SSE transport also supports custom headers for authentication:
When to Use SSE vs. Streamable HTTP
-
Use Streamable HTTP when:
- Setting up new deployments (recommended default)
- You need bidirectional streaming
- You’re connecting to FastMCP servers running in
streamable-http
mode
-
Use SSE when:
- Connecting to legacy FastMCP servers running in
sse
mode - Working with infrastructure optimized for Server-Sent Events
- Connecting to legacy FastMCP servers running in
Local Transports
These transports manage an MCP server running as a subprocess, communicating with it via standard input (stdin) and standard output (stdout). This is the standard mechanism used by clients like Claude Desktop.
Session Management
All stdio transports support a keep_alive
parameter (default: True
) that controls session persistence across multiple client context managers:
keep_alive=True
(default): The subprocess and session are maintained between client context exits and re-entries. This improves performance when making multiple separate connections to the same server.keep_alive=False
: A new subprocess is started for each client context, ensuring complete isolation between sessions.
When keep_alive=True
, you can manually close the session using await client.close()
if needed. This will terminate the subprocess and require a new one to be started on the next connection.
Python Stdio
- Class:
fastmcp.client.transports.PythonStdioTransport
- Inferred From: Paths to
.py
files - Use Case: Running a Python-based MCP server script in a subprocess
This is the most common way to interact with local FastMCP servers during development or when integrating with tools that expect to launch a server script.
The server script must include logic to start the MCP server and listen on stdio, typically via mcp.run()
or fastmcp.server.run()
. The Client only launches the script; it doesn’t inject the server logic.
Node.js Stdio
- Class:
fastmcp.client.transports.NodeStdioTransport
- Inferred From: Paths to
.js
files - Use Case: Running a Node.js-based MCP server script in a subprocess
Similar to the Python transport, but for JavaScript servers.
UVX Stdio (Experimental)
- Class:
fastmcp.client.transports.UvxStdioTransport
- Inferred From: Not automatically inferred
- Use Case: Running an MCP server packaged as a Python tool using
uvx
This is useful for executing MCP servers distributed as command-line tools or packages without installing them into your environment.
NPX Stdio (Experimental)
- Class:
fastmcp.client.transports.NpxStdioTransport
- Inferred From: Not automatically inferred
- Use Case: Running an MCP server packaged as an NPM package using
npx
Similar to UvxStdioTransport
, but for the Node.js ecosystem.
In-Memory Transports
FastMCP Transport
- Class:
fastmcp.client.transports.FastMCPTransport
- Inferred From: An instance of
fastmcp.server.FastMCP
or a FastMCP 1.0 server (mcp.server.fastmcp.FastMCP
) - Use Case: Connecting directly to a FastMCP server instance in the same Python process
This is extremely useful for testing your FastMCP servers.
Communication happens through efficient in-memory queues, making it very fast and ideal for unit testing.
Configuration-Based Transports
MCPConfig Transport
New in version:Â 2.4.0
- Class:
fastmcp.client.transports.MCPConfigTransport
- Inferred From: An instance of
MCPConfig
or a dictionary matching the MCPConfig schema - Use Case: Connecting to one or more MCP servers defined in a configuration object
MCPConfig follows an emerging standard for MCP server configuration but is subject to change as the specification evolves. The standard supports both local servers (running via stdio) and remote servers (accessed via HTTP).
If your configuration has only a single server, the client will connect directly to that server without any prefixing. This makes it convenient to switch between single and multi-server configurations without changing your client code.
The MCPConfig format is an emerging standard for MCP server configuration and may change as the MCP ecosystem evolves. While FastMCP aims to maintain compatibility with future versions, be aware that field names or structure might change.