Skip to main content
New in version 3.0.0 Custom 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.

When to Build Custom

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

Providers vs Middleware

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.

The Provider Interface

A provider implements protected _list_* methods that return available components. The public list_* methods handle transforms automatically - you override the underscore-prefixed versions:
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.

What Providers Return

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:
The function’s type hints become the input schema, and the docstring becomes the description. You can override these:
Similar from_function methods exist for Resource and Prompt.

Registering Providers

Add providers when creating the server:
Or add them after creation:

A Simple Provider

Here’s a minimal provider that serves tools from a dictionary:
Use it like this:

Lifecycle Management

Providers often need to set up connections when the server starts and clean them up when it stops. Override the lifespan method:
FastMCP calls your provider’s lifespan during server startup and shutdown. The connection is available to your methods while the server runs.

Full Example: API-Backed Resources

Here’s a complete provider that fetches resources from an external REST API:
Register it like any other provider: