3.0.0
Component versioning lets you maintain multiple implementations of the same tool, resource, or prompt under a single identifier. You register each version, and FastMCP handles the rest: clients see the highest version by default, but you can filter to expose exactly the versions you want.
The primary use case is serving different API versions from one codebase. Instead of maintaining separate deployments for v1 and v2 clients, you version your components and use VersionFilter to create distinct API surfaces.
Versioned API Surfaces
Consider a server that needs to support both v1 and v2 clients. The v2 API adds new parameters to existing tools, and you want both versions to coexist cleanly. You define your components on a shared provider, then create separate servers with different version filters.api_v1 see the two-argument calculate. Clients connecting to api_v2 see the three-argument version. Both servers share the same component definitions.
VersionFilter accepts two keyword-only parameters that mirror comparison operators: version_gte (greater than or equal) and version_lt (less than). You can use either or both to define your version range.
Unversioned components are exempt from version filtering. A
VersionFilter only affects versioned components—unversioned components always pass through regardless of the filter’s constraints. This ensures that adding version filtering to a server with mixed versioned and unversioned tools doesn’t accidentally hide the unversioned ones. To prevent confusion, FastMCP forbids mixing versioned and unversioned components with the same name.Filtering Mounted Servers
When you mount child servers and apply aVersionFilter to the parent, the filter applies to components from mounted servers as well. Range filtering (version_gte and version_lt) is handled at the provider level, meaning mounted servers don’t need to know about the parent’s version constraints.
VersionFilter sees components after they’ve been namespaced, but filters based on version regardless of namespace. This lets you apply version policies consistently across your entire server hierarchy.
Declaring Versions
Add aversion parameter to any component decorator. FastMCP stores versions as strings and groups components by their identifier (name for tools and prompts, URI for resources).
process with version 2.0 (the highest). When they invoke process, version 2.0 executes. The same pattern applies to resources and prompts.
Versioned vs Unversioned Components
For any given component name, you must choose one approach: either version all implementations or version none of them. Mixing versioned and unversioned components with the same name raises an error at registration time.VersionFilter. By enforcing consistency at registration, FastMCP ensures version filtering behaves predictably.
Version Discovery
When clients list components, each versioned component includes metadata about all available versions. This lets clients discover what versions exist before deciding which to use. Themeta.fastmcp.versions field contains all registered versions sorted from highest to lowest.
"1.0" and "2.0", listing returns the 2.0 implementation with meta.fastmcp.version set to "2.0" and meta.fastmcp.versions set to ["2.0", "1.0"]. Unversioned components omit these fields entirely.
This discovery mechanism enables clients to make informed decisions about which version to request, support graceful degradation when newer versions introduce breaking changes, or display version information in developer tools.
Requesting Specific Versions
By default, clients receive and invoke the highest version of each component. When you need a specific version, FastMCP provides two approaches: the FastMCP client API for Python applications, and the MCP protocol mechanism for any MCP-compatible client.FastMCP Client
The FastMCP client’scall_tool and get_prompt methods accept an optional version parameter. When specified, the server executes that exact version instead of the highest.
NotFoundError. This ensures you get exactly what you asked for rather than silently falling back to a different version.
MCP Protocol
For generic MCP clients that don’t have built-in version support, pass the version through the_meta field in arguments. FastMCP servers extract the version from _meta.fastmcp.version before processing.
_meta field is part of the MCP request params, not arguments, so your component implementation never sees it. This convention allows version selection to work across any MCP client without requiring protocol changes. The FastMCP client handles this automatically when you pass the version parameter.
Version Comparison
FastMCP compares versions to determine which is “highest” when multiple versions share an identifier. The comparison behavior depends on the version format. For PEP 440 versions (like"1.0", "2.1.3", "1.0a1"), FastMCP uses semantic comparison where numeric segments are compared as numbers.
v prefix is stripped before comparison, so "v1.0" and "1.0" are treated as equal for sorting purposes.
Retrieving Specific Versions
Server-side code can retrieve specific versions rather than just the highest. This is useful during migrations when you need to compare behavior between versions or access legacy implementations. Theget_tool, get_resource, and get_prompt methods accept an optional version parameter. Without it, they return the highest version. With it, they return exactly that version.
NotFoundError is raised.
Removing Versions
Theremove_tool, remove_resource, and remove_prompt methods accept an optional version parameter that controls what gets removed.
Migration Workflow
Versioning supports gradual migration when updating component behavior. You can deploy new versions alongside old ones, verify the new behavior works correctly, then clean up. When migrating an existing unversioned component to use versioning, start by assigning an initial version to your existing implementation. Then add the new version alongside it.get_tool("process_data", version="1.0").
Once the migration is complete, remove the old version.

