Skip to main content
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 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.

​
Built-in Providers

FastMCP includes providers for common patterns: 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

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. 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.

​
Provider Order

When a client requests a component by name or URI, FastMCP queries providers and returns the highest matching version across the providers that have it. For unversioned components, or for components with equal versions, provider registration order is the tie-breaker. LocalProvider is always registered first, so your decorator-defined components take precedence over equal-version components from mounted or proxied providers. Additional providers are registered in the order you add them.

​
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: The decorators you already use are themselves a provider: LocalProvider is what backs @mcp.tool and its siblings.