Provides real-time access to FastAPI documentation, including tools for fetching pages by path, searching with alias support, listing all available pages, extracting code examples, comparing approaches, and retrieving best practices.
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 Docs MCP Server How do I set up CORS in FastAPI?"
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.
An MCP (Model Context Protocol) server that provides real-time access to FastAPI documentation. Use it with Claude, GitHub Copilot, or any MCP-compatible client to instantly query FastAPI docs.
Real-time documentation — Fetches directly from fastapi.tiangolo.com
Smart search — Find docs by keyword with common alias support
Full sitemap access — Browse all available documentation pages
Code examples — Get just the code, no prose
Compare approaches — Side-by-side comparisons of different patterns
Related MCP server: DevDocs MCP Server
Tool | Description |
| Fetch any documentation page by path |
| Search docs by keyword (with alias support) |
| List all available documentation pages |
| Get just the code examples, no prose |
| Compare different approaches side-by-side |
| Get combined best practices from multiple pages |
Once connected, ask your AI assistant:
"How do I set up CORS in FastAPI?"
"Show me the FastAPI security documentation"
"What are FastAPI dependencies?"
"List all FastAPI tutorial pages"
"Give me a code example for JWT authentication"
"Compare sync vs async in FastAPI"
"What are the best practices for testing in FastAPI?"
git clone https://github.com/jaredthivener/fastapi-docs-mcp.git
cd fastapi-docs-mcp
uv syncAdd to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"fastapi-docs": {
"command": "uv",
"args": ["run", "--directory", "/path/to/fastapi-docs-mcp", "python", "main.py"]
}
}
}Add to .vscode/mcp.json in your workspace:
{
"servers": {
"fastapi-docs": {
"command": "uv",
"args": ["run", "--directory", "/path/to/fastapi-docs-mcp", "python", "main.py"]
}
}
}Build the image locally:
docker build -t fastapi-docs-mcp .Then use this MCP server config:
{
"servers": {
"fastapi-docs": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"fastapi-docs-mcp"
],
"type": "stdio"
}
}
}uv run python main.py# Install dev dependencies
uv sync --extra dev
# Run tests
uv run pytest
# Lint
uv run ruff check .
# Format
uv run ruff format .
# Type check
uv run mypy main.pyThe server fetches documentation directly from the official FastAPI website:
Sitemap-based discovery — Uses sitemap.xml to find all available pages
Real-time fetching — Retrieves current documentation on each request
Smart extraction — Extracts readable content from HTML pages
Keyword aliases — Maps common terms (e.g., "auth" → "security")
To keep responses fast and avoid overloading AI context windows, documentation content is truncated to a maximum length (currently 15,000 characters). If a page exceeds that limit, the response ends with a truncation notice and a link to the full page.
MIT
Compare FastAPI approaches side-by-side (e.g. sync vs async, auth methods).
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | What to compare, e.g. "sync-async", "auth-methods", or any topic. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint: true, openWorldHint: true) already indicate safe read operation and result variability. The description adds minimal behavioral context ('side-by-side'), but does not disclose specific output format, constraints, or depth of comparison.
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?
Single sentence with examples, no wasted words. Front-loaded with action and resource.
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 low-complexity tool with one parameter and good annotations, the description is adequate. It covers purpose and examples, though return format could be mentioned. Overall complete enough for selection and invocation.
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 covers 100% of parameters with detailed description for 'topic'. The description repeats examples from schema but adds no new semantics beyond what the schema provides.
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?
Description clearly states the tool compares FastAPI approaches, with specific examples (sync vs async, auth methods). This distinguishes it from sibling tools like get_fastapi_best_practices or get_fastapi_example, which serve different purposes.
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 when to use the tool (to compare approaches) but does not explicitly state when not to use it or mention alternatives. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Combine best-practice content from all doc pages matching a topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic to gather, e.g. "security", "testing", or "dependencies". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description does not add any behavioral details beyond what annotations convey, such as the nature of the combined content or any limitations. It is neutral and non-contradictory.
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 a single, well-formed sentence that immediately conveys the action and scope. Every word is necessary; there is no redundancy or irrelevant detail.
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 simplicity (one parameter, no output schema), the description provides the core purpose. It could mention the output format (e.g., returns a text block), but the agent can infer from the tool name and context. It is mostly complete.
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 describes the 'topic' parameter with examples. The description mentions 'matching a topic' but adds no new semantics beyond the schema. With 100% schema coverage, a baseline score of 3 is appropriate.
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 'Combine' and a clear resource 'best-practice content from all doc pages matching a topic'. It distinguishes itself from siblings like 'get_fastapi_docs' which retrieves a single page, and 'search_fastapi_docs' which may return snippets. The scope is well-defined.
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 when one needs an aggregated view of best practices on a topic, but does not explicitly state when not to use it or mention alternative tools for similar tasks. For example, it doesn't contrast with 'search_fastapi_docs' for broader searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch FastAPI documentation content for a page by its path.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Doc path, e.g. "tutorial/first-steps" or "advanced/websockets". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations and emerging documentation. The description simply says 'Fetch', which aligns with read-only behavior, but adds no extra context about side effects or limitations. No contradiction with annotations.
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?
A single, concise sentence that immediately conveys the tool's purpose and the key parameter. No wasted words, front-loaded with the action and resource.
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 simple fetch operation with one parameter and no output schema, the description is adequate. Annotations provide safety context. However, since there is no output schema or description of return format, completeness is slightly less than perfect.
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 provides full description for the single parameter 'path' with an example. The description does not add any additional semantic meaning beyond what is already in the schema. With 100% schema coverage, baseline 3 is appropriate.
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 clearly states the verb 'Fetch', the resource 'FastAPI documentation content', and the method 'by its path'. It distinguishes from sibling tools like list_fastapi_pages (which lists pages) and search_fastapi_docs (which searches), making the tool's purpose unambiguous.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for fetching content of a specific page, but does not mention when to use sibling tools like search_fastapi_docs or compare_fastapi_approaches. Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get code examples (no prose) for a FastAPI topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic to fetch examples for, e.g. "cors", "jwt", or "websockets". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (safe read) and openWorldHint=true (results vary). The description adds the key behavioral trait that the tool returns only code examples and no prose, which is beyond the annotations and provides useful context to the agent.
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?
A single sentence that is front-loaded with the key purpose and constraint. No extraneous words or repetition. Every word earns its place.
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 has only one parameter, high schema coverage, no output schema, and simple behavior, the description is complete. It tells the agent exactly what to expect (code examples, no prose) and provides typical topic examples.
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 100%, so the schema already explains the 'topic' parameter. The description adds example values ('cors', 'jwt', 'websockets') but does not provide additional semantic meaning beyond the schema. Baseline 3 is appropriate.
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 clearly states the verb 'Get', the resource 'code examples', and the constraint 'no prose'. It also specifies the domain 'FastAPI topic'. This distinguishes it from siblings like get_fastapi_docs which would include prose.
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 when to use (when only code examples are needed, not prose) but does not explicitly state when not to use or list alternatives. The sibling tools provide context but the description alone gives no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available FastAPI doc pages, categorized by section.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, meaning the tool is a safe read with potentially dynamic results. The description adds no further behavioral context, which is acceptable given the annotations provide adequate transparency.
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 a single, clear sentence with no redundant words. It is appropriately front-loaded and efficient.
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 no parameters, no output schema, and annotations covering safety and openness, the description suffices. It could optionally hint at the output format (e.g., 'returns a list of sections'), but the current text is minimally adequate.
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 zero parameters, and the description does not mention any. Since there are no parameters, the description does not need to add meaning beyond the schema. Score baseline 4.
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 'List all available FastAPI doc pages, categorized by section' uses a specific verb ('list') and resource ('FastAPI doc pages'), clearly distinguishing it from sibling tools like 'get_fastapi_docs' which retrieve specific pages or 'search_fastapi_docs' which search.
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?
No explicit when-to-use or when-not-to-use instructions. However, the description implies it is for browsing available pages, and sibling tool names suggest different purposes (e.g., 'compare_fastapi_approaches' for comparison). Implicit differentiation but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the docs by keyword and return the best-matching page.
Common aliases are supported (e.g. "auth" finds security pages).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term, e.g. "cors", "database", or "websocket". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that common aliases are supported and returns best-matching page, but no additional behavioral traits like rate limits or return format.
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?
Two sentences, front-loaded with main purpose, second sentence adds helpful detail. No redundant information.
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?
No output schema exists, and the description only says 'return the best-matching page' without detailing the response format. For a search tool, this is adequate but could be more explicit.
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 100% with parameter description. The description adds extra semantic value by noting that common aliases are supported, enhancing the parameter's usability.
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 clearly states it searches FastAPI docs by keyword and returns the best-matching page. This is distinct from siblings that get specific pages, list pages, or provide examples.
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 does not explicitly state when to use this tool versus alternatives. It only implies that it's for searching, but does not contrast with other tools like get_fastapi_docs for known pages.
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.
v2.0.0compare_fastapi_approachesget_fastapi_best_practicesget_fastapi_docsget_fastapi_examplelist_fastapi_pagessearch_fastapi_docsEach tool targets a distinct task: comparing approaches, best practices, fetching docs, examples, listing pages, and searching. No overlap in functionality.
All names use snake_case and follow a verb_fastapi_noun pattern. Minor variation in verbs like 'compare' vs 'get' but overall consistent.
Six tools is well-scoped for a documentation server, covering essential operations without being excessive or insufficient.
The surface covers common documentation needs (browse, search, fetch, examples, comparisons). Minor gap: no explicit tool for random page or offline caching, but core workflows are complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
@latest documentation and code examples to 9000+ libraries for LLMs and AI code editors in a singl…
Versioned documentation registry and semantic search for AI tools and coding assistants.
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jaredthivener/fastapi-docs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
