Skip to main content
New in version 2.2.0 As your application grows, you’ll want to split it into focused servers — one for weather, one for calendar, one for admin — and combine them into a single server that clients connect to. That’s what mount() does. When you mount a server, all its tools, resources, and prompts become available through the parent. The connection is live: add a tool to the child after mounting, and it’s immediately visible through the parent.

Mounting External Servers

Mount remote HTTP servers or subprocess-based MCP servers using create_proxy():

Mounting npm/uvx Packages

For npm packages or Python tools, use the config dict format:
Or use explicit transport classes:
For advanced configuration, see Proxying.

Namespacing

New in version 3.0.0 When mounting multiple servers, use namespaces to avoid naming conflicts:

How Namespacing Works

Namespacing uses transforms under the hood.

Dynamic Composition

Because mount() creates a live link, you can add components to a child server after mounting and they’ll be immediately available through the parent:

Tag Filtering

New in version 3.0.0 Parent server tag filters apply recursively to mounted servers:

Performance Considerations

Operations like list_tools() on the parent are affected by the performance of all mounted servers. This is particularly noticeable with:
  • HTTP-based mounted servers (300-400ms vs 1-2ms for local tools)
  • Mounted servers with slow initialization
  • Deep mounting hierarchies
If low latency is critical, consider implementing caching strategies or limiting mounting depth.

Custom Routes

New in version 2.4.0 Custom HTTP routes defined with @server.custom_route() are also forwarded when mounting:

Conflict Resolution

New in version 3.0.0 When mounting multiple servers with the same namespace (or no namespace), the most recently mounted server takes precedence for conflicting component names: