Existing FastAPI routes become MCP tools
FastAPI-MCP reads a FastAPI application's OpenAPI information and exposes chosen operations as Model Context Protocol tools. Request models, response descriptions, operation IDs, tags, and FastAPI dependencies stay connected to the original routes. That is the useful part: a team can add an agent interface without copying every input schema into a second server. The MCP endpoint can live on the API application or on another FastAPI app.
Conversion still requires editorial judgment. The configuration accepts included or excluded operation IDs and tags, and the project's own best-practices page warns against exposing every route. It specifically advises caution with PUT and DELETE operations because a model can call the wrong tool. Automatic generation removes duplicate wiring, but it does not decide which business actions are safe for an agent.
HTTP is recommended, while SSE remains for older clients
Release 0.4.0 added Streamable HTTP and deprecated the generic mount() method in favor of mount_http() or mount_sse(). HTTP is the documented default, while SSE remains for compatibility. Both can mount at a custom path or on a router, and a separate deployment can run the source API and MCP app on different ports. This is a practical fit for teams already comfortable with ASGI routing.
Protocol age is now a concern. The last repository push was November 24, 2025, and the latest release was published July 28, 2025. Issue 323, opened in August 2026, asks for MCP Python SDK 2.0 support and says the current package assumes the older session lifecycle. The repository had 11,986 stars and 166 combined issues and pull requests when fetched, so interest is substantial even though the published line has not moved with recent SDK changes.
What happened when we ran it
Our sandbox installed commit e5cad13 in 28 seconds. It added 70 packages, occupied 71 MB, and built successfully in 8 seconds. Pip-audit reported 0 known vulnerabilities. The checkout itself contained 84 files and about 6,154 lines of source, with 2 CI workflow files and a tests directory but no Dockerfile.
The test step failed after 55 seconds. Pytest recorded 12 passed, 32 failed, and 22 collection or setup errors out of 66. The tail repeatedly named HTTP and SSE real-transport cases, each ending with RuntimeError: Server failed to start after 20 attempts. That message proves the test servers did not come up in our unprivileged Debian container. It does not say whether the block was networking, process startup, dependency behavior, or something else.
A passing build therefore answers only part of the adoption question. The package can be installed and assembled in a small environment, but our run did not establish a working client-to-tool round trip. Before attaching it to a real API, reproduce the intended transport with the exact Python and MCP dependency versions, then exercise initialization, tool listing, an authenticated call, and shutdown.
Authentication works only when you require it
The authentication guide supports simple token forwarding and a fuller OAuth 2 flow. Existing FastAPI dependencies can inspect the forwarded Authorization header. For OAuth, AuthConfig accepts issuer and authorization metadata, audience, client credentials, default scopes, and custom provider metadata. Compatibility proxies can fill gaps such as dynamic client registration, missing scopes, or audience values, while mcp-remote may need a fixed callback port.
The important default is easy to miss: rejecting requests with no Authorization header is optional. The guide tells users to add an AuthConfig dependency if they want that behavior. Issue 324 reports that an HTTP server mounted without AuthConfig allowed an anonymous client to initialize, list tools, and call a wrapped route. That report matches the documented configuration model, so a security review should treat MCP mounting and access control as separate changes.
Complex schemas need a conversion test before rollout
OpenAPI conversion is where convenience meets edge cases. Issue 319 reports that top-level arrays and primitive request bodies can disappear because conversion looks for object properties. The same report describes collisions when a path parameter and body field share a name: the path value is removed before the remaining arguments become the body. Either case can make a valid FastAPI route unusable through its generated tool.
Issue 287 covers a harsher failure. A self-referencing Pydantic model caused recursion during schema resolution and prevented the MCP server from starting, rather than dropping only the affected route. Issue 304 says optional list schemas can lose their items definition, leading clients including Claude Code to reject the tool. These are specific reasons to generate and inspect the tool catalog from your own application, especially if its models use recursive unions or nested optional collections.
The best fit is a narrow, pinned adapter
FastAPI-MCP is most convincing when an application already has a clean OpenAPI surface and the team wants a dozen read-oriented tools, not hundreds of raw routes. Its filters, direct ASGI calls, separate-app option, and reuse of FastAPI dependencies reduce repeated code. The MIT license also leaves teams free to inspect and patch the adapter while waiting for upstream releases.
Release 0.4.0 should be pinned alongside a compatible MCP SDK, and the generated schemas should become deploy-time artifacts that reviewers can compare. Our 32 failures and 22 setup errors make that discipline necessary, not ceremonial. If protocol currency matters more than route reuse, the official SDK or FastMCP gives you more control. If route reuse wins, keep the exposed set small and make unauthenticated calls part of the acceptance test.