docs/servers/providers/overview.mdx
import { VersionBadge } from '/snippets/version-badge.mdx'
<VersionBadge version="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.
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.
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 a FastMCPProvider.
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.
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) |
Most users only interact with LocalProvider (through decorators) and occasionally mount or proxy other servers. The provider abstraction stays invisible until you need it.
Transforms modify components as they flow from providers to clients. Each transform sits in a chain, intercepting queries and modifying results before passing them along.
| Transform | Purpose |
|---|---|
Namespace | Prefixes names to avoid conflicts |
ToolTransform | Modifies tool schemas (rename, description, arguments) |
The most common use is namespacing mounted servers to prevent name collisions. When you call mount(server, namespace="api"), FastMCP creates a Namespace transform automatically.
Transforms can be added to individual providers (affecting just that source) or to the server itself (affecting all components). See Transforms for the full picture.
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.
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: