Related Pages

Related topics: Authentication and Authorization, Deployment, Operations, and Known Issues

Overview and Core Architecture

Purpose and Scope

FastAPI-MCP exposes a FastAPI application's endpoints as Model Context Protocol (MCP) tools, allowing MCP clients (AI assistants, agents, inspectors) to invoke those endpoints through structured tool calls. The package's public surface is intentionally small: the FastApiMCP class plus the supporting types AuthConfig and OAuthMetadata. Source: fastapi_mcp/__init__.py:18-19

The library is positioned as FastAPI-native rather than as an OpenAPI-to-MCP code generator. The MCP server holds a reference to the live FastAPI FastAPI instance and either talks to it directly over ASGI or via httpx.AsyncClient, which means existing FastAPI dependencies, middleware, and documentation are reused as-is. Source: README.md:63-75 Authentication flows declared on the FastAPI app therefore carry over to MCP tools without duplication.

Core Architecture

The FastApiMCP class is the single user-facing entry point. Its constructor accepts the FastAPI app and a set of configuration flags — name, description, describe_all_responses, describe_full_response_schema, http_client, include_operations, exclude_operations, include_tags, exclude_tags, auth_config, and headers — and defers the heavy lifting (OpenAPI resolution and tool construction) until the server is actually mounted. Source: fastapi_mcp/server.py:29-141

Three layers cooperate at runtime, shown below.

flowchart LR
    A[FastAPI App] -->|get_openapi| B[OpenAPI Schema]
    B -->|resolve_schema_references| C[Resolved Schema]
    C -->|convert_openapi_to_mcp_tools| D[MCP Tools + operation_map]
    D --> E[FastApiMCP.call_tool]
    E -->|httpx.AsyncClient / ASGI| A
    F[FastApiMCP.mount_http] --> G[FastApiHttpSessionManager]
    H[FastApiMCP.mount_sse] --> I[FastApiSseTransport]

OpenAPI Conversion Pipeline

The conversion entry point is convert_openapi_to_mcp_tools, which first calls resolve_schema_references over the entire schema, then iterates paths and HTTP methods to emit mcp.types.Tool objects and an operation_map keyed by operationId. Source: fastapi_mcp/openapi/convert.py:18-37 Parameters are bucketed by location (path, query, header, request body), and the resolved schema is rewritten as the tool's JSON Schema input. An optional HTTPRequestInfo payload can be attached to each call so the executor knows how to reconstruct the originating MCP request. Source: fastapi_mcp/types.py:24-30

This pipeline is the source of several community-reported defects. resolve_schema_references() recurses without memoization and raises RecursionError on Pydantic models that reference themselves (issue #287). The schema-cleaning helper in fastapi_mcp/openapi/utils.py strips anyOf while failing to hoist items, yielding an invalid {type: "array"} for Optional[List[X]] parameters (issue #304). When a request body field is typed T | U with neither T nor U being None, the conversion collapses the union to a single arbitrarily-chosen type entry that the MCP JSON Schema validator rejects with a misleading "is not of type X" error (issue #307).

Transport Layer

Starting with v0.4.0 the library exposes two mounts: mount_http() implementing the Streamable HTTP specification (recommended) and mount_sse() for backwards compatibility with the older SSE transport. The previously unified mount() method is deprecated and will be removed in a future release. Source: CHANGELOG.md:5-21 The HTTP transport delegates to FastApiHttpSessionManager in fastapi_mcp/transport/http.py, while SSE uses FastApiSseTransport in fastapi_mcp/transport/sse.py. Statefulness is supported on both, but session state is held in-process; this is the root cause of the "404 session not found" errors that surface when the server runs behind a load balancer with multiple workers (issues #189 and #208). A related limitation: FastAPI StreamingResponse is not preserved through either transport (issue #77).

When using mount_http(), the FastAPI app's lifespan context manager is not currently triggered (issue #256, v0.4.0), so startup/shutdown hooks attached to the app will silently not run unless the app is started through a separate ASGI server entry point.

Tool Execution

FastApiMCP.call_tool looks up the requested tool in operation_map, substitutes path parameters, separates query and header arguments, and then issues the HTTP call to the matching FastAPI endpoint using either the user-supplied httpx.AsyncClient or the default ASGI transport. Source: fastapi_mcp/server.py:142-189 The headers constructor argument (defaulting to ["authorization"], added in v0.3.6) is an allowlist of HTTP header names forwarded from the incoming MCP request into each tool invocation. Source: fastapi_mcp/server.py:121-129, CHANGELOG.md:40-46

Configuration Model

Endpoint filtering is symmetrical and mutually exclusive: include_operations cannot be combined with exclude_operations, and the same applies to include_tags / exclude_tags. Source: fastapi_mcp/server.py:75-114 Schema description verbosity is controlled by describe_all_responses and describe_full_response_schema, both defaulting to False. Source: fastapi_mcp/server.py:43-53

Authentication is opt-in via the AuthConfig model. When supplied, the library either serves a custom OAuth metadata document at a configured path or proxies a third-party metadata URL; both modes live in fastapi_mcp/auth/proxy.py and comply with the MCP 2025-03-26 authorization specification. Source: fastapi_mcp/auth/proxy.py:26-58, fastapi_mcp/types.py:33-95

Examples and Common Patterns

The examples/ directory ships seven runnable samples covering the canonical workflows: basic integration (01_basic_usage_example.py), full schema descriptions (02), custom endpoint exposure (03), separate-server deployment (04), re-registering tools after dynamic route changes (05), custom MCP router configuration (06), and HTTP timeout customization (07). Source: examples/README.md:1-12

See Also

• CHANGELOG.md — release notes, including the v0.4.0 deprecation of mount()
• fastapi_mcp/transport/http.py — Streamable HTTP transport implementation
• fastapi_mcp/transport/sse.py — SSE transport implementation
• fastapi_mcp/openapi/utils.py — schema cleaning helpers referenced by issue #304
• Issue #256 — lifespan context manager behavior with mount_http()
• Issue #208 — discussion of stateful sessions across multi-worker deployments

Related Pages

Related topics: Overview and Core Architecture, Deployment, Operations, and Known Issues

Authentication and Authorization

FastAPI-MCP exposes FastAPI endpoints as Model Context Protocol (MCP) tools, which means it must handle two distinct authentication concerns: authenticating the MCP client (the AI assistant connecting to the MCP server) and authenticating the downstream FastAPI endpoint (the actual business logic invoked by each tool call). The library provides a layered design that reuses your existing FastAPI authentication infrastructure while also implementing OAuth 2.1 compliance for MCP clients that follow the MCP 2025-03-26 Specification.

Source: CHANGELOG.md:8

Design Philosophy: FastAPI-Native Auth

The headline feature highlighted in the README is that FastAPI-MCP is not just another OpenAPI → MCP converter, but a native extension of FastAPI. Practically, this means that any FastAPI Depends() you already use to protect your API endpoints is automatically respected when those endpoints are invoked through an MCP tool — there is no separate auth model to maintain.

Source: README.md:13

Because the MCP server is mounted onto the same FastAPI ASGI application, a request that arrives over the MCP HTTP or SSE transport flows through your existing dependency tree. Authentication tokens, API keys, or session cookies validated at the FastAPI layer are honored without duplication.

AuthConfig and OAuth 2.1 Proxies

For the MCP-client side, FastAPI-MCP ships with an AuthConfig Pydantic model and a set of proxy helpers that turn the library into a compliant OAuth 2.1 resource server / authorization proxy.

The relevant building blocks live in fastapi_mcp/types.py (defining AuthConfig, OAuthMetadata, OAuthMetadataDict, and the Pydantic models for client registration) and fastapi_mcp/auth/proxy.py (the proxy endpoints). The AuthConfig is passed to the FastApiMCP constructor via the auth_config parameter and, when present, triggers _setup_auth_2025_03_26() to wire up the OAuth flow.

Source: fastapi_mcp/server.py:60-66 Source: fastapi_mcp/server.py:118-161

AuthConfig Fields

AuthConfig is a Pydantic model that controls how MCP clients authenticate. The most important options include:

Source: fastapi_mcp/types.py:150-260

Proxy Helpers

The proxy module in fastapi_mcp/auth/proxy.py exposes four helpers used by _setup_auth_2025_03_26():

• setup_oauth_custom_metadata — serves a static metadata document from metadata_path.
• setup_oauth_metadata_proxy — fetches the upstream issuer's /.well-known/openid-configuration and re-serves it under metadata_path.
• setup_oauth_authorize_proxy — forwards browser-driven /authorize requests to the upstream provider, applying client_id, audience, and default_scope fallbacks where the MCP client has not supplied them.
• setup_oauth_fake_dynamic_register_endpoint — implements a stub of RFC 7591 Dynamic Client Registration that simply echoes the pre-registered client_id/client_secret, useful because tools like npx mcp-remote require the endpoint to exist even when real registration is not desired.

Source: fastapi_mcp/auth/proxy.py:60-160

sequenceDiagram
    participant Client as MCP Client (e.g. mcp-remote)
    participant MCP as fastapi-mcp (mounted on FastAPI)
    participant IdP as OAuth Provider (e.g. Auth0)

    Client->>MCP: GET /.well-known/oauth-authorization-server
    MCP->>IdP: GET /.well-known/openid-configuration
    IdP-->>MCP: Metadata
    MCP-->>Client: Proxied metadata
    Client->>MCP: POST /oauth/register
    MCP-->>Client: Echo client_id / client_secret
    Client->>MCP: GET /oauth/authorize (browser redirect)
    MCP->>IdP: Forward authorize request
    IdP-->>Client: Token via redirect
    Client->>MCP: tools/call with Authorization: Bearer ...
    MCP->>MCP: Forward to FastAPI Depends() (validates token)
    MCP-->>Client: Tool result

Source: fastapi_mcp/server.py:118-161

Header Forwarding and Token Passthrough

In addition to the OAuth dance, FastAPI-MCP lets you forward specific HTTP headers from the incoming MCP request into the tool invocation. The headers constructor parameter accepts an allowlist of header names; only those headers are forwarded. By default, headers=["authorization"] is set, so an MCP client that already holds a bearer token can pass it straight through to the protected FastAPI endpoint.

Source: fastapi_mcp/server.py:80-90

This parameter was introduced in v0.3.6 (PR #181) and is the basis for the *token passthrough* example, which shows how to mount an MCP server in front of an upstream API and reuse the caller's bearer token without re-issuing one.

Source: CHANGELOG.md:60-64

End-to-End Auth0 Example

The most complete reference implementation is examples/09_auth_example_auth0.py, which:

1. Loads Auth0 settings from environment variables using pydantic_settings.BaseSettings (domain, audience, client id/secret, JWKS URL).
2. Fetches the JWKS public key in a FastAPI lifespan handler and stashes it on app.state.
3. Constructs an AuthConfig with setup_proxies=True, setup_fake_dynamic_registration=True, and the Auth0 metadata URL.
4. Passes the AuthConfig to FastApiMCP(...) and mounts it via mcp.mount_http().

The corresponding examples/shared/auth.py helpers fetch the JWKS document and expose a FastAPI Depends() that validates the bearer token against the cached key, demonstrating the layered model: the OAuth proxy handles the MCP-client side, and the FastAPI dependency handles the downstream-API side.

Source: examples/09_auth_example_auth0.py:1-90 Source: examples/README.md:1-10

Common Failure Modes and Gotchas

A handful of issues observed in the community are tied directly to authentication and deployment:

• Stateful sessions and multi-worker deployments. A long-standing problem (issues #189 and #208) is that v0.4.0's stateful session manager keeps session state in-process. Behind a load balancer with multiple workers, clients receive 404 session not found errors. Authentication headers alone will not save you — you also need a shared session store if you scale out.

Source: Issue #189, Issue #208

• default_scope not being applied. Older 0.3.x versions ignored default_scope; this was fixed in v0.3.7. If you upgrade from an earlier version, verify that the OAuth provider is still receiving scopes when the client omits them.

Source: CHANGELOG.md:50-55

• Audience not sent by some clients. npx mcp-remote and similar clients may omit the audience parameter, so the audience fallback in AuthConfig exists specifically as a workaround. Configure it explicitly to avoid silent authorization failures.

Source: fastapi_mcp/types.py:200-220

• lifespan not firing under mount_http(). Issue #256 reports that FastAPI lifespan context managers are not triggered when using mount_http() in 0.4.0. Because the Auth0 example relies on lifespan to fetch the JWKS key, this bug directly affects authentication bootstrapping and should be tracked.

Source: Issue #256

See Also

• MCP 2025-03-26 Authorization Specification
• OAuth 2.0 Server Metadata (RFC 8414)
• OAuth 2.0 Dynamic Client Registration (RFC 7591)
• examples/08_auth_example_token_passthrough.py — minimal header-forwarding example
• examples/09_auth_example_auth0.py — full Auth0 integration

Related Pages

Related topics: Overview and Core Architecture, Deployment, Operations, and Known Issues

Schema Handling and OpenAPI Conversion

Purpose and Scope

fastapi-mcp exposes FastAPI endpoints as Model Context Protocol (MCP) tools. The bridge between the two ecosystems is the OpenAPI conversion layer, located in the fastapi_mcp/openapi/ package. This layer takes the OpenAPI 3 schema that FastAPI already produces, transforms its $ref-based component definitions into a single inlined schema, classifies operations by HTTP method, and finally emits a list of mcp.types.Tool objects together with a lookup map of operation IDs to operation metadata.

The conversion is invoked from the FastApiMCP constructor through mcp.tools (a list) and mcp.operation_map (a dict). Source: fastapi_mcp/openapi/convert.py:1-50.

Why a custom pipeline and not a generic OpenAPI → MCP converter? The README states that fastapi-mcp is "not just another OpenAPI → MCP converter" and instead integrates natively with FastAPI, preserving request/response model schemas and Swagger-style documentation. Source: README.md:1-25.

Conversion Pipeline

The conversion follows a deterministic, multi-stage pipeline:

flowchart LR
    A[FastAPI app] --> B[get_openapi]
    B --> C[resolve_schema_references]
    C --> D[Per-path/Per-method iteration]
    D --> E[clean_schema_for_display]
    E --> F[generate_example_from_schema]
    F --> G[get_single_param_type_from_schema]
    G --> H[mcp.types.Tool list]
    G --> I[operation_map]
    H --> J[MCP server]
    I --> J

1. OpenAPI extraction — fastapi.openapi.utils.get_openapi produces the spec dict.
2. Reference inlining — resolve_schema_references(openapi_schema, openapi_schema) walks every $ref and replaces it with the resolved object. Source: fastapi_mcp/openapi/convert.py:37-46.
3. Operation filtering — Non-HTTP methods (options, head, trace, x-…) are skipped with a warning. Source: fastapi_mcp/openapi/convert.py:42-46.
4. Parameter grouping — Parameters are grouped into path, query, and header buckets. Body parameters come from requestBody.content[*].schema.properties. Source: fastapi_mcp/openapi/convert.py:103-118.
5. Schema display — clean_schema_for_display strips verbose JSON-Schema constructs so the resulting inputSchema is MCP-friendly. Source: fastapi_mcp/openapi/utils.py.
6. Tool assembly — A types.Tool is created with name=operation_id, a Markdown description, and inputSchema = {type: "object", properties: ..., title: f"{operation_id}Arguments"}. The required array is populated from the union of required path/query/header/body fields. Source: fastapi_mcp/openapi/convert.py:121-130.

Schema Utility Functions

The fastapi_mcp/openapi/utils.py module provides the building blocks of the conversion. Their roles are summarized below.

Source for all four: fastapi_mcp/openapi/utils.py.

Response Description Modes

The FastApiMCP constructor exposes two boolean flags that change how the response section of each tool description is rendered. Source: fastapi_mcp/server.py.

• describe_all_responses=False (default) — only the success (2XX) response is described.
• describe_all_responses=True — every response declared in responses is included.
• describe_full_response_schema=False (default) — a generated example is rendered.
• describe_full_response_schema=True — the full JSON schema is embedded in a fenced code block.

Example combining both flags is shown in examples/02_full_schema_description_example.py, which sets describe_full_response_schema=True and describe_all_responses=True on the Item API MCP server.

Endpoint Filtering and Header Forwarding

Two FastApiMCP constructor parameters control which operations are converted into tools:

• include_operations / exclude_operations — Lists of OpenAPI operationIds. Mutually exclusive. Source: fastapi_mcp/server.py.
• include_tags / exclude_tags — Tag-based filtering, also mutually exclusive. Source: fastapi_mcp/server.py.

These are demonstrated in examples/03_custom_exposed_endpoints_example.py.

The headers constructor argument (default ["authorization"]) is an allowlist of HTTP header names from the incoming MCP request that are forwarded into each tool invocation when the tool is executed through the ASGI transport. Source: fastapi_mcp/server.py. The CHANGELOG records that this allowlist was added in v0.3.6. Source: CHANGELOG.md.

Known Limitations and Community-Reported Issues

Several schema-handling edge cases are tracked in the issue tracker and are useful to be aware of when designing FastAPI models:

• Self-referencing $ref schemas — resolve_schema_references raises RecursionError when a Pydantic model contains a recursive type definition (e.g., a Tree node with children: List[Tree]). Tracked in issue #287.
• Optional[List[X]] rendering — clean_schema_for_display removes anyOf but does not hoist the items field from array variants, producing invalid {type: "array"} without items. Tracked in issue #304.
• Union of two non-null types — When a field is annotated as T | U with neither being None, get_single_param_type_from_schema projects a single arbitrary "type" field; the resulting MCP tool schema is rejected by downstream JSON-Schema validators. Tracked in issue #307.

These issues do not currently alter the documented behavior of the conversion layer — they are listed so users can model around them until they are resolved upstream.

See Also

• README.md — project overview and installation
• CHANGELOG.md — version history, including v0.4.0 HTTP transport
• fastapi_mcp/types.py — HTTPRequestInfo, AuthConfig, OAuthMetadata types used alongside schemas
• examples/README.md — full list of usage examples

Related Pages

Related topics: Overview and Core Architecture, Authentication and Authorization, Schema Handling and OpenAPI Conversion

Deployment, Operations, and Known Issues

This page documents the deployment topologies, operational configuration surface, and known failure modes for the fastapi_mcp library. It is intended for operators and integrators who already understand the basic FastApiMCP constructor and want a consolidated reference for putting the project into production.

1. Deployment Topologies

FastAPI-MCP supports two primary deployment patterns, both implemented through mount methods on the FastApiMCP class.

1.1 In-Process Mounting (Same App)

The recommended pattern is to mount the MCP endpoint onto the existing FastAPI application. The constructor is defined in fastapi_mcp/server.py:21-30, and the mount_http() method introduced in v0.4.0 is now the preferred entry point. As noted in CHANGELOG.md:3-15, the legacy mount() method is deprecated and will be removed; users should migrate to mount_http() for Streamable HTTP transport or mount_sse() for the older SSE transport.

from fastapi import FastAPI
from fastapi_mcp import FastApiMCP

app = FastAPI()
mcp = FastApiMCP(app)
mcp.mount_http()  # exposes MCP at /mcp on the same ASGI app

1.2 Separate Server Deployment

For scenarios where the MCP surface must be served from a different process (e.g., different scaling profile, different auth), the examples directory contains a dedicated sample: examples/04_separate_server_example.py and the advanced-routing variant examples/06_custom_mcp_router_example.py. This topology is useful when the upstream FastAPI service is already behind a load balancer and you do not want MCP traffic competing for the same workers.

flowchart LR
    A[MCP Client] -->|HTTP POST /mcp| B[MCP Server Process]
    B -->|httpx AsyncClient| C[FastAPI App Process]
    B --> D[(Shared Session Store)]
    C --> E[(Database / Backend)]

2. Operations and Configuration

The operational surface of FastApiMCP is controlled entirely through constructor parameters defined in fastapi_mcp/server.py:35-126.

The headers allowlist was added in v0.3.6 (CHANGELOG.md:46-48) to give operators explicit control over header forwarding, which is a common security concern when bridging MCP into HTTP APIs. Custom HTTP timeouts are demonstrated in examples/07_configure_http_timeout_example.py. Tool re-registration after FastApiMCP construction is shown in examples/05_reregister_tools_example.py.

The OAuth integration is provided by fastapi_mcp/auth/proxy.py, which exposes metadata endpoints and registration proxies for AuthConfig consumers. The AuthConfig and OAuthMetadata types live in fastapi_mcp/types.py.

3. Known Issues and Limitations

The community has surfaced a number of operational issues that operators should plan around.

3.1 Multi-Worker Session Sharing (issue #189, #208)

Stateful sessions created via mount_http() or mount_sse() are held in-process. When the application is deployed behind multiple workers, the load balancer can route a follow-up request to a worker that does not own the session, producing a 404 session not found error (issue #189). Tracking for a shared session store is open in issue #208. Workarounds include sticky-session load balancing or deploying the MCP surface as a single-worker process.

3.2 Lifespan Context Manager Not Triggered (issue #256)

In fastapi-mcp 0.4.0, mounting with mount_http() does not trigger the parent FastAPI application's lifespan context manager (issue #256). Code that depends on startup/shutdown hooks (DB pool creation, warm-up loads) must run outside the lifespan path until this is resolved.

3.3 OpenAPI Schema Conversion Errors

Two known issues affect schema fidelity in the OpenAPI-to-MCP conversion pipeline in fastapi_mcp/openapi/convert.py and the helpers in fastapi_mcp/openapi/utils.py:

• Self-referencing $ref: resolve_schema_references() recurses without a depth guard, causing a RecursionError on recursive Pydantic models (issue #287).
• Optional[List[X]] rendering: clean_schema_for_display() removes anyOf without hoisting items, producing invalid {type: "array"} schemas with no items (issue #304).
• Non-nullable unions: T | U unions with no None member collapse to a single arbitrary type field, failing the MCP-side JSON Schema validator with a misleading error (issue #307).

3.4 Streaming Responses (issue #77)

FastAPI endpoints that return streaming responses are not currently compatible with the MCP tool invocation path (issue #77). Tools that internally stream will block until the full body is collected.

3.5 SSE Deprecation

The SSE transport is now considered legacy per the MCP specification. The community has requested that mount_http() (Streamable HTTP) be the default, and a deprecation note is emitted by inspector clients (issue #133, issue #61). New deployments should prefer mount_http().

4. Operational Best Practices

1. Pin transports explicitly. Call mount_http() for new deployments; treat mount_sse() as a compatibility path.
2. Validate OpenAPI before deploy. Run the app's /openapi.json through the conversion locally to catch recursive or union-type schemas before they crash initialization.
3. Single-writer for stateful sessions. Until a shared session store lands, keep the MCP process single-worker or use sticky sessions.
4. Restrict the headers allowlist. Only forward headers that downstream API auth actually needs; the default ["authorization"] is the safest starting point.
5. Run lifespan work outside the MCP mount. Until #256 is resolved, initialize pools and warm-up caches at module import time or via a separate startup hook.
6. Contribute fixes. The project uses ruff, mypy, and pytest per CONTRIBUTING.md, and PRs against the open issues above are welcome.

See Also

• README.md — project overview and quick start
• CHANGELOG.md — release history (v0.3.6, v0.3.7, v0.4.0)
• examples/README.md — list of runnable examples
• fastapi_mcp/server.py — FastApiMCP class definition
• fastapi_mcp/auth/proxy.py — OAuth proxy implementation
• fastapi_mcp/openapi/convert.py — OpenAPI → MCP conversion pipeline

Doramagic Pitfall Log

Found 14 structured pitfall item(s), including 4 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification.

1. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/tadata-org/fastapi_mcp/issues/287

2. Configuration risk: Configuration risk requires verification

• Severity: high
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/tadata-org/fastapi_mcp/issues/189

3. Configuration risk: Configuration risk requires verification

• Severity: high
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/tadata-org/fastapi_mcp/issues/256

4. Configuration risk: Configuration risk requires verification

• Severity: high
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/tadata-org/fastapi_mcp/issues/304

5. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/tadata-org/fastapi_mcp/issues/305

6. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.host_targets | https://github.com/tadata-org/fastapi_mcp

7. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/tadata-org/fastapi_mcp/issues/303

8. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/tadata-org/fastapi_mcp/issues/307

9. Capability evidence risk: Capability evidence risk requires verification

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.assumptions | https://github.com/tadata-org/fastapi_mcp

10. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/tadata-org/fastapi_mcp

11. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: downstream_validation.risk_items | https://github.com/tadata-org/fastapi_mcp

12. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: risks.scoring_risks | https://github.com/tadata-org/fastapi_mcp

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using fastapi_mcp with real data or production workflows.

• [[BUG] RecursionError in resolve_schema_references() with self-referencin](https://github.com/tadata-org/fastapi_mcp/issues/287) - github / github_issue
• clean_schema_for_display() strips anyOf and loses items for Optional[Lis - github / github_issue
• [[BUG] lifespan context manager not triggered when using mount_http() in](https://github.com/tadata-org/fastapi_mcp/issues/256) - github / github_issue
• [[BUG] Union types of two real types (non-null) rejected at MCP-server js](https://github.com/tadata-org/fastapi_mcp/issues/307) - github / github_issue
• [[VOTE] Support Stateful Sessions in a Multi-Worker Environment, Using a](https://github.com/tadata-org/fastapi_mcp/issues/208) - github / github_issue
• MCPSafe deep scan: 32 medium findings, score 71/100 — badge available - github / github_issue
• [[BUG] MCP session 404 in multi worker production environment](https://github.com/tadata-org/fastapi_mcp/issues/189) - github / github_issue
• Suggestion: MCPWatch observability example for fastapi_mcp users - github / github_issue
• FastAPI streaming response - github / github_issue
• v0.4.0 - github / github_release
• v0.3.7 - github / github_release
• v0.3.6 - github / github_release