Use this file to discover all available pages before exploring further.
New in version 3.0.0Custom providers let you source components from anywhere - databases, APIs, configuration systems, or dynamic runtime logic. If you can write Python code to fetch or generate a component, you can wrap it in a provider.
The built-in providers handle common cases: decorators (LocalProvider), composition (FastMCPProvider), and proxying (ProxyProvider). Build a custom provider when your components come from somewhere else:
Database-backed tools: Admin users define tools in a database, and your server exposes them dynamically
API-backed resources: Resources that fetch content from external services on demand
Configuration-driven components: Components loaded from YAML/JSON config files at startup
Multi-tenant systems: Different users see different tools based on their permissions
Plugin systems: Third-party code registers components at runtime
Both providers and middleware can influence what components a client sees, but they work at different levels.Providers are objects that source components. They make it easy to reason about where tools, resources, and prompts come from - a database, another server, an API.Middleware intercepts individual requests. It’s well-suited for request-specific decisions like logging, rate limiting, or authentication.You could use middleware to dynamically add tools based on request context. But it’s often cleaner to have a provider source all possible tools, then use middleware or visibility controls to filter what each request can see. This separation makes it easier to reason about how components are sourced and how they interact with other server machinery.
A provider implements protected _list_* methods that return available components. The public list_* methods handle transforms automatically - you override the underscore-prefixed versions:
from collections.abc import Sequencefrom fastmcp.server.providers import Providerfrom fastmcp.tools import Toolfrom fastmcp.resources import Resourcefrom fastmcp.prompts import Promptclass MyProvider(Provider): async def _list_tools(self) -> Sequence[Tool]: """Return all tools this provider offers.""" return [] async def _list_resources(self) -> Sequence[Resource]: """Return all resources this provider offers.""" return [] async def _list_prompts(self) -> Sequence[Prompt]: """Return all prompts this provider offers.""" return []
You only need to implement the methods for component types you provide. The base class returns empty sequences by default.The _get_* methods (_get_tool, _get_resource, _get_prompt) have default implementations that search through the list results. Override them only if you can fetch individual components more efficiently than iterating the full list.
Providers return component objects that are ready to use. When a client calls a tool, FastMCP invokes the tool’s function - your provider isn’t involved in execution. This means the Tool, Resource, or Prompt you return must actually work.The easiest way to create components is from functions:
from fastmcp.tools import Tooldef add(a: int, b: int) -> int: """Add two numbers.""" return a + btool = Tool.from_function(add)
The function’s type hints become the input schema, and the docstring becomes the description. You can override these:
tool = Tool.from_function( add, name="calculator_add", description="Add two integers together")
Similar from_function methods exist for Resource and Prompt.