3.0.0
Every FastMCP server has one or more component providers. A provider is a source of tools, resources, and prompts - it’s what makes components available to clients.
What Is a Provider?
When a client connects to your server and asks “what tools do you have?”, FastMCP asks each provider that question and combines the results. When a client calls a specific tool, FastMCP finds which provider has it and delegates the call. You’re already using providers. When you write@mcp.tool, you’re adding a tool to your server’s LocalProvider - the default provider that stores components you define directly in code. You just don’t have to think about it for simple servers.
Providers become important when your components come from multiple sources: another FastMCP server to include, a remote MCP server to proxy, or a database where tools are defined dynamically. Each source gets its own provider, and FastMCP queries them all seamlessly.
Why Providers?
The provider abstraction solves a common problem: as servers grow, you need to organize components across multiple sources without tangling everything together. Composition: Break a large server into focused modules. A “weather” server and a “calendar” server can each be developed independently, then mounted into a main server. Each mounted server becomes aFastMCPProvider.
Proxying: Expose a remote MCP server through your local server. Maybe you’re bridging transports (remote HTTP to local stdio) or aggregating multiple backends. Remote connections become ProxyProvider instances.
Dynamic sources: Load tools from a database, generate them from an OpenAPI spec, or create them based on user permissions. Custom providers let components come from anywhere.
Built-in Providers
FastMCP includes providers for common patterns:| Provider | What it does | How you use it |
|---|---|---|
LocalProvider | Stores components you define in code | @mcp.tool, mcp.add_tool() |
FastMCPProvider | Wraps another FastMCP server | mcp.mount(server) |
ProxyProvider | Connects to remote MCP servers | create_proxy(client) |
TransformingProvider | Adds prefixes to avoid name collisions | mcp.mount(server, namespace="api") |
LocalProvider (through decorators) and occasionally mount or proxy other servers. The provider abstraction stays invisible until you need it.
Provider Order
When a client requests a tool, FastMCP queries providers in registration order. The first provider that has the tool handles the request.LocalProvider is always first, so your decorator-defined tools take precedence. Additional providers are queried in the order you added them. This means if two providers have a tool with the same name, the first one wins.
When to Care About Providers
You can ignore providers entirely if you’re building a simple server with decorators. Just use@mcp.tool, @mcp.resource, and @mcp.prompt - FastMCP handles the rest.
Learn about providers when you want to:
- Mount another server into yours
- Proxy a remote server through yours
- Control visibility of components
- Build dynamic sources like database-backed tools
Next Steps
- Local - How decorators and visibility control work
- Mounting - Compose servers together
- Proxying - Connect to remote servers
- Namespacing - Avoid name collisions
- Custom - Build your own providers