Allows AI assistants to inspect FastAPI applications and routers, extracting OpenAPI schemas, registered routes, and backend metadata from local files or live deployments.
Provides tools to extract JSON schemas from Pydantic BaseModel classes and generate TypeScript interfaces and Zod schemas from them.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fastapi-mcp-server Generate TypeScript interfaces from the Pydantic models in main:app"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that connects AI coding assistants directly to your FastAPI applications, APIRouters, and Pydantic models.
Functions as a Full-Stack Context Bridge—allowing AI in your IDE to inspect local Python files or live backend deployments, generate 100% accurate TypeScript interfaces and Zod schemas, scaffold typed API clients, and discover backend routes without hallucinations or stale documentation.
When AI assistants write frontend hooks, API clients, or backend tests, they often guess request shapes, parameter names, and route paths based on incomplete file views or outdated training data.
fastapi-mcp-server solves this by giving AI assistants native inspection tools:
Dual-Mode Introspection: Inspects local .py files directly from disk (no running uvicorn required) or fetches live schemas from deployed staging/production URLs (https://api.example.com/openapi.json or http://localhost:8000/docs).
Instant TypeScript & Zod Generation: Converts Pydantic models and OpenAPI schemas into strict, copy-paste ready TypeScript interfaces and Zod validation schemas with full typing, nullability, and JSDoc comments.
Standalone Router & Sub-Module Support: Introspects full applications (main:app) as well as standalone APIRouter files (routers.users:router) and factory functions.
Project Auto-Discovery: Scans backend repositories using AST analysis to catalog every FastAPI app, router, and Pydantic model automatically.
Cross-Repository Context: Frontend developers working in a separate repository (e.g. Next.js/React) can point their IDE's MCP client to the backend project directory to inspect backend types while writing frontend code.
Related MCP server: FastAPI MCP Server
uvx (Recommended — no installation needed)uvx fastapi-mcp-serverpippip install fastapi-mcp-servergit clone https://github.com/username/fastapi-mcp-server.git
cd fastapi-mcp-server
uv sync
uv run fastapi-mcp-serverAdd to your Zed settings.json (Ctrl + , or Cmd + ,):
{
"context_servers": {
"fastapi-mcp-server": {
"command": {
"path": "uvx",
"args": ["fastapi-mcp-server"]
}
}
}
}For local workspace development without publishing:
{
"context_servers": {
"fastapi-mcp-server": {
"command": {
"path": "uv",
"args": [
"run",
"--directory",
"/path/to/fastapi-mcp-server",
"fastapi-mcp-server"
]
}
}
}
}Go to Cursor Settings > Features > MCP Servers > + Add New MCP Server:
Name: fastapi-mcp-server
Type: command
Command: uvx fastapi-mcp-server
Add to your VS Code user or workspace settings (settings.json):
{
"mcp": {
"servers": {
"fastapi-mcp-server": {
"command": "uvx",
"args": ["fastapi-mcp-server"]
}
}
}
}Add to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"fastapi-mcp-server": {
"command": "uvx",
"args": ["fastapi-mcp-server"]
}
}
}get_openapi_schemaExtracts the complete OpenAPI JSON schema from a local FastAPI app, standalone APIRouter, factory function, or live deployed HTTP URL.
app_path (str, required): Import target (e.g. "main:app", "routers.users:router", "src/api.py:app") or live URL ("https://api.example.com/openapi.json", "http://localhost:8000/docs").
project_dir (str, optional): Path to the backend project root.
get_pydantic_schemaExtracts the JSON Schema from any Pydantic BaseModel class (supporting both Pydantic v2 and v1).
model_path (str, required): Import target (e.g. "models.user:UserProfile", "src/schemas.py:Item").
project_dir (str, optional): Path to the backend project root.
list_registered_routesReturns a structured catalog of registered routes, HTTP methods, operation IDs, summaries, and tags from an app, standalone router, or live URL.
app_path (str, required): Target app, router, or URL.
project_dir (str, optional): Path to the backend project root.
get_typescript_definitionDirectly generates strict TypeScript interfaces and types from a Pydantic model, local app, or remote OpenAPI URL.
target (str, required): Model target (e.g. "models.user:UserProfile"), app target ("main:app"), or live URL.
project_dir (str, optional): Path to the backend project root.
get_zod_schemaGenerates client-side Zod validation schemas (z.object({...})) and inferred TypeScript types from a Pydantic model or OpenAPI target.
target (str, required): Model target, app target, or live URL.
project_dir (str, optional): Path to the backend project root.
discover_fastapi_projectScans a backend project directory using zero-execution AST parsing to catalog all FastAPI instances, APIRouters, and Pydantic models.
project_dir (str, optional): Path to the project directory to scan.
All tools return clean structured JSON dictionaries rather than raising unhandled exceptions or crashing the MCP connection:
{
"error": "ModuleNotFoundError",
"detail": "Failed to import module 'src.main'. Searched in sys.path: [...]"
}# Clone the repository
git clone https://github.com/username/fastapi-mcp-server.git
cd fastapi-mcp-server
# Install dependencies
uv sync
# Run tests
uv run pytest
# Run type checker and linter
uv run basedpyright
uv run ruff check src testsMIT License. See LICENSE for details.
Automatically scan a project directory to discover all FastAPI apps, APIRouters, and Pydantic models.
Args: project_dir: Optional path to the project root directory. Defaults to current working directory.
Returns: A structured catalog listing all discovered apps, routers, and models with import target strings.
| Name | Required | Description | Default |
|---|---|---|---|
| project_dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full transparency burden. It clearly states that the tool automatically scans a directory and returns a structured catalog with import target strings, which goes beyond the minimal schema. It does not mention potential performance costs or failure modes, but the core behavior is adequately disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with Summary, Args, and Returns sections. Each sentence adds meaningful information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the lack of an output schema, and the absence of annotations, the description provides a solid high-level contract: input path, default behavior, and returned content. It stops short of giving the exact catalog structure, but it is sufficient for an agent to decide whether and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines project_dir as an optional string or null, but the description adds full semantic meaning: it is a path to the project root and defaults to the current working directory. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and resources: 'scan a project directory to discover all FastAPI apps, APIRouters, and Pydantic models.' This clearly separates it from siblings like get_openapi_schema or list_registered_routes, which operate on schemas or routes rather than discovering the project's structural components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the description: call this when you need a project-wide catalog of FastAPI apps, routers, and models. However, it does not explicitly state when to prefer this over sibling tools, nor does it mention any exclusions or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract the complete OpenAPI schema from a local FastAPI app, APIRouter, factory function, or live HTTP URL.
Args: app_path: Import string pointing to the target (e.g. 'main:app', 'routers.users:router', 'https://api.example.com/openapi.json'). project_dir: Optional path to the project root directory. Defaults to current working directory.
Returns: The OpenAPI specification dictionary or an error dictionary.
| Name | Required | Description | Default |
|---|---|---|---|
| app_path | Yes | ||
| project_dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the input forms and that the return is either a spec dictionary or an error dictionary, but it does not mention potential side effects of importing app code, network behavior for URLs, or specific error circumstances beyond a generic error return.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence summary is front-loaded, followed by a compact Args section and a terse Returns section. Every sentence provides needed information without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite missing annotations and output schema, the description gives the essential contract: what to pass, the accepted input forms, and the return shape. It could be slightly more complete by describing the error dictionary structure or side effects of import, but it is adequate for an extraction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully defines both parameters: app_path is clearly explained as an import string or URL with concrete examples, and project_dir is described as an optional path with a default. This fully compensates for the schema's missing descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Extract') and a distinct resource ('complete OpenAPI schema'), and enumerates source types (FastAPI app, APIRouter, factory function, live HTTP URL) that clearly separate it from sibling tools like get_pydantic_schema, get_typescript_definition, and get_zod_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is provided for when to call: if you need the OpenAPI schema from a FastAPI target or URL. However, it does not explicitly name alternative tools or state exclusion conditions, relying on the agent to infer the boundary from the purpose and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract the JSON Schema from a local Pydantic BaseModel class definition.
Args: model_path: Import string pointing to the Pydantic model (e.g. 'models.user:UserCreate', 'src/schemas.py:Item'). project_dir: Optional path to the project root directory. Defaults to current working directory.
Returns: The JSON schema dictionary for the Pydantic model or an error dictionary.
| Name | Required | Description | Default |
|---|---|---|---|
| model_path | Yes | ||
| project_dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It states that the tool operates on local models, accepts an optional project_dir that defaults to the current working directory, and returns either a JSON schema dictionary or an error dictionary. This gives the agent a clear picture of expected outcomes, though it does not mention potential side effects of importing the model module.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with a clear purpose statement, followed by efficient Args and Returns sections. Every sentence adds necessary information, and there is no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough information to call the tool correctly: both parameters are documented, return behavior is stated, and examples clarify the required import-string format. It lacks explicit sibling-tool routing and caveats about invalid or non-importable model paths, but it is otherwise self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description's Args section is the only source of parameter meaning. It fully explains model_path as an import string with concrete examples, and project_dir as an optional project root path defaulting to the current working directory. This completely compensates for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Extract' and a precise resource ('JSON Schema from a local Pydantic BaseModel class definition'). It clearly distinguishes the tool from siblings like get_zod_schema, get_typescript_definition, and get_openapi_schema by targeting local Pydantic models specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for extracting JSON Schema from local Pydantic model definitions, but it does not explicitly explain when to prefer it over the sibling tools or when not to use it. There is no alternative guidance or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate strict TypeScript interfaces and types from a Pydantic model, FastAPI app, or live OpenAPI URL.
Args: target: Target identifier (e.g. 'models.user:UserProfile', 'main:app', 'https://api.example.com/openapi.json'). project_dir: Optional path to the project root directory.
Returns: TypeScript interface/type definitions code as a string, or an error dictionary.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| project_dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It clearly states that the tool returns TypeScript code as a string or an error dictionary, which is useful, but it does not disclose side effects, network behavior for live URLs, or what triggers the error return path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then provides a compact Args/Returns structure. Every sentence contributes useful information, and there is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description gives enough context for an agent to understand the input sources and expected return value. It stops short of explaining error dictionary structure or the exact behavior when a target cannot be resolved, but it is reasonably complete for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema's bare string fields. It does meaningfully enrich 'target' with concrete formats like 'models.user:UserProfile', 'main:app', and an OpenAPI URL, and it clarifies that 'project_dir' is an optional path to the project root.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate strict TypeScript interfaces and types' from a Pydantic model, FastAPI app, or live OpenAPI URL. It is clear about what the tool produces, but it does not explicitly differentiate it from sibling tools like get_zod_schema or get_openapi_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing the accepted source types ('Pydantic model, FastAPI app, or live OpenAPI URL') and giving target examples, so an agent can infer when it is relevant. However, it provides no explicit when-to-use, when-not-to-use, or comparison with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate Zod validation schemas with inferred TypeScript types from a Pydantic model, FastAPI app, or live OpenAPI URL.
Args: target: Target identifier (e.g. 'models.user:UserProfile', 'main:app', 'https://api.example.com/openapi.json'). project_dir: Optional path to the project root directory.
Returns: Zod schema definition code as a string, or an error dictionary.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| project_dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the return type ('Zod schema definition code as a string, or an error dictionary') and implies network/filesystem interaction through 'live OpenAPI URL' and 'project_dir.' It does not detail side effects or error conditions beyond an error dictionary, but this is reasonable for a code-generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with clear Args and Returns sections. The opening sentence states the core purpose, and every subsequent line adds useful detail without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description provides enough context: target forms, optional project directory, return type, and error outcome. It could mention prerequisites such as whether a local FastAPI app must be importable or whether a URL must be publicly accessible, but the current level is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates. It explains 'target' with three concrete example formats and clarifies that 'project_dir' is an optional path to the project root. Each parameter receives meaning beyond its raw type in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate Zod validation schemas with inferred TypeScript types.' It then names the accepted source types: Pydantic model, FastAPI app, or live OpenAPI URL. This clearly differentiates it from siblings like get_openapi_schema and get_pydantic_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states what kinds of targets are accepted and gives concrete examples such as 'models.user:UserProfile' and 'main:app'. It does not explicitly say when to prefer this over get_typescript_definition or get_openapi_schema, but the supported targets and output format make the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered HTTP routes, methods, operation IDs, summaries, and tags from a FastAPI app, APIRouter, or live URL.
Args: app_path: Import string pointing to the target (e.g. 'main:app', 'routers.items:router', 'http://localhost:8000/docs'). project_dir: Optional path to the project root directory. Defaults to current working directory.
Returns: A list of registered routes or an error dictionary.
| Name | Required | Description | Default |
|---|---|---|---|
| app_path | Yes | ||
| project_dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does mention accepting import strings or live URLs and returning an error dictionary on failure, which is useful. However, it does not disclose that importing an app or fetching a URL may execute code or make network requests, nor what failure cases produce the error dictionary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well structured: a one-sentence purpose, then brief Args and Returns sections. Every sentence adds useful information and the main capability is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema and no annotations, the description covers purpose, both parameters, accepted app_path forms, defaults, and the general return type. The first sentence also implies the output shape by listing route fields. A concrete example entry or explicit mention of import/URL side effects would make it fully complete, but for a two-parameter read-only enumeration tool this is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must do the work for both parameters. It explains app_path as an import string with concrete examples and project_dir as an optional project-root path defaulting to the current working directory. This fully compensates for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and names the resource ('registered HTTP routes') plus the exact attributes returned (methods, operation IDs, summaries, tags), and lists the possible sources (FastAPI app, APIRouter, live URL). It is clear, but it does not explicitly differentiate itself from sibling get_openapi_schema, which could also expose route/method information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The expected use case is implied: an agent should call this when it needs an inventory of routes from a FastAPI app, router, or URL. However, the description does not state when not to use it or contrast it with alternatives such as get_openapi_schema or discover_fastapi_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0discover_fastapi_projectget_openapi_schemaget_pydantic_schemaget_typescript_definitionget_zod_schemalist_registered_routesEach tool has a distinct output type: OpenAPI schema, Pydantic JSON schema, route listing, TypeScript interfaces, Zod schemas, and project discovery. The two code generation tools accept similar targets, but their output formats are clearly described, so misselection is unlikely.
Most tools follow a get_<object> pattern such as get_openapi_schema, get_pydantic_schema, and get_zod_schema. list_registered_utes and discover_fastapi_project use different verbs but are still predictable and consistent in naming style.
Six tools is a well-scoped count for a FastAPI introspection and schema generation server. Each tool serves a clear purpose without unnecessary redundancy.
The tool set covers OpenAPI extraction, Pydantic schema extraction, route listing, project discovery, and both TypeScript interface and Zod schema generation. This provides comprehensive coverage for the server's stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Serves your design system and coding standards to coding agents, so they stop guessing.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Discover, compare, and monitor 1,400+ APIs directly from your AI coding agent.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mantle-bearer/fastapi-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
