Should you use it for an existing FastAPI app?
FastAPI-MCP is worth a controlled trial when reusing an existing API matters more than designing a separate MCP interface. The project's README describes reuse of request and response schemas, endpoint documentation and FastAPI dependencies. It also describes direct ASGI communication and deployment beside the API or separately. Those are documented capabilities, not successful deployment results from our sandbox.
For background on the underlying framework, see our FastAPI guide. This review addresses the adapter and its recorded execution, rather than choosing the web framework.
What our sandbox established
Our run on September 28, 2026, tested commit e5cad13. Installation returned exit code 0 after 32 seconds, and the build returned exit code 0 after 6 seconds. The test command returned exit code 1 after 55 seconds.
The harness records each command's outcome, exit code, elapsed time and timeout status, then stores parsed test counts separately. Here, installation and build succeeded, tests failed, and none of those steps timed out. A zero exit code for installation or build does not demonstrate that an MCP client initialized, listed tools or completed an authenticated tool call.
The attached stored parser summaries report 12 passed, 32 failed, 22 errors and 0 skipped, with a recorded total of 66. These are recorded parser summaries, not verified exhaustive counts of unique tests. No new execution or complete-log reconciliation was performed.
The raw failure tail adds detail that the aggregate cannot explain:
- Basic functionality and configuration cases report a Server constructor argument mismatch.
- OpenAPI conversion cases report a missing inputSchema attribute and suggest input_schema.
- API tool execution cases report that async functions are not natively supported by the test runner.
- SSE mock cases include validation and JSON-RPC attribute errors. A named real SSE tool-call case reports that its server failed to start after 20 attempts.
The raw output also reports 58.28% coverage against an 80% requirement. Its pytest footer reports 47.41 seconds, while the harness records 55 seconds for the test command. These are separately recorded timings; neither replaces the other.
The evidence does not establish whether dependency compatibility, test configuration, sandbox behavior or several causes produced these failures. It also does not establish a successful production deployment, runtime throughput or a completed OAuth flow. The testing methodology explains the publisher's recording approach and its limits. That current page is provenance context, not evidence that this older run used today's procedure.
Authentication needs an explicit decision
Rejecting requests without an authorization header requires an optional dependency in the documented configuration. The pinned authentication guide distinguishes forwarding an Authorization header from configuring the MCP server to reject requests that lack one.
For a protected service, inspect the dependency that makes the authorization decision and test both permitted and anonymous requests. The documentation also describes OAuth configuration, provider metadata and callback setup. Our run did not validate that flow, so those instructions should be treated as setup documentation rather than a result we reproduced.
The supplied extracts do not independently verify the issue reports cited by the previous page. This correction therefore does not use those reports to assert anonymous access, recursive-schema crashes or compatibility with a particular MCP SDK generation.
Use the release's transport guidance
The v0.4.0 release recommends Streamable HTTP, retains SSE for backward compatibility and deprecates the generic mounting method in favor of the transport-specific methods. The README's minimal example still uses the generic method, so consult the release guidance when configuring this version.
Before deployment, inspect the generated tool catalog, initialize the intended client, list its tools and call a permitted route. Then verify that an unauthorized request is rejected. Repeat those checks with the dependency versions and transport you intend to deploy. These are recommended acceptance checks, not additional tests performed for this review.
When to choose a different MCP implementation
FastMCP wraps Python functions as MCP tools, resources and prompts. Choose it as an alternative when you want to write the MCP interface directly instead of deriving it from an existing FastAPI application. Its supplied README also describes clients and interactive apps; this review did not test those capabilities.
The MCP Python SDK supports building MCP servers and clients. Choose it when you want to implement those protocol roles using the project's Python SDK. Its supplied README documents stdio, Streamable HTTP and SSE. That does not establish compatibility between its current version and this FastAPI-MCP checkout.
These are alternatives for implementing the MCP interface. Neither replaces the business logic in your existing FastAPI application, and this evidence does not establish that either must be installed alongside FastAPI-MCP.
How to read the editorial scores
The assessed scores use this rubric: 1 means the supplied evidence shows a basic requirement blocked; 2 means substantial obstacles remain; 3 means partial success with material validation still needed; 4 means the examined area is documented in useful detail; 5 requires broader corroboration than these extracts provide. Scores describe the evidence examined here, not adoption, security or universal compatibility. An unassessed dimension has no numerical rating.
Setup earns 3 because installation and build succeeded while tests failed. Documentation earns 4 for the supplied installation, deployment, authentication and transport guidance, although the mounting example needs to be read alongside the release notes. Maturity earns 2 because this checkout's test command failed across several named areas and did not establish a working deployment. Community remains unassessed: contribution instructions and a community invitation do not establish participation or maintainer responsiveness.