Provides access to the complete official Godot Engine documentation, including class references, tutorials, and development guides, allowing AI models to retrieve accurate information for Godot game development.
Click on "Deploy 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., "@Godot MCP Documentation Server explain the properties and methods of CharacterBody2D"
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.
中文文档 | English
A Model Context Protocol (MCP) server that provides AI assistants with access to the complete Godot Engine documentation, helping developers with Godot development by serving documentation directly to LLMs.
This server bridges the gap between AI assistants and Godot documentation, allowing developers to get instant, accurate answers about Godot classes, tutorials, and features without leaving their AI chat interface.
Related MCP server: godot-mcp-docs
This project is based on godot-mcp-docs by Nihilantropy, modified for local development on Windows without Docker.
Install uv (if not already installed):
# On Windows with PowerShell:
Invoke-WebRequest -Uri https://astral.sh/uv/install.ps1 -UseBasicParsing | Invoke-ExpressionClone the repository:
git clone https://github.com/Nihilantropy/godot-mcp-docs.git
cd godot-mcp-docsInstall Python dependencies:
uv syncThis command reads from pyproject.toml and creates a virtual environment.
Note: uv sync uses pyproject.toml as the source of truth, not requirements.txt. This is the modern Python packaging standard (PEP 517/518/621). The uv.lock file ensures consistent dependency versions across environments.
After installing dependencies, you need to download and process the Godot documentation:
Generate documentation:
uv run python .\docs_converter\godot_docs_converter.pyMove docs folder to root:
After conversion, move the generated docs folder to the project root directory.
Generate documentation tree:
cd docs
tree /f > docs_tree.txt
cd ..Note: If you encounter Chinese encoding issues, use:
tree /f | Out-File -Encoding utf8 docs_tree.txtStart the MCP server locally:
uv run python main.pyAdd this to your Claude Desktop configuration file:
{
"mcpServers": {
"godot-mcp-docs": {
"command": "uv",
"args": [
"run",
"python",
"main.py"
]
}
}
}get_documentation_tree() - Get a tree-style overview of the entire documentation structure
get_documentation_file(file_path: str) - Retrieve the content of specific documentation files
Explore documentation structure:
What documentation is available for Godot?Get specific class documentation:
Show me the documentation for CharacterBody2DLearn about tutorials:
What tutorials are available for 2D game development?Get specific tutorial content:
Show me the first 2D game tutorialCompare classes:
What's the difference between Node2D and CharacterBody2D?Start the server in dev mode:
uv run fastmcp dev main.pyThen open your browser to http://127.0.0.1:8000 to see all tools and test them interactively.
Use Anthropic's official MCP Inspector:
npx @modelcontextprotocol/inspector uv run python main.pyThis opens http://localhost:5173 in your browser, showing all tools, request/response logs, and allowing manual tool testing. No need to run uv run python main.py separately.
Send JSON-RPC requests to the server:
Invoke-WebRequest -Uri http://localhost:8000/message `
-Method POST `
-ContentType "application/json" `
-Body '{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "get_documentation_file",
"arguments": {
"file_path": "classes/class_characterbody2d.md"
}
},
"id": 1
}'Or using curl:
curl -X POST http://localhost:8000/message `
-H "Content-Type: application/json" `
-d '{
"jsonrpc": "2.0",
"method": "tools/call",
"params": { "name": "search_godot_docs", "arguments": { "query": "DisplayServer" } },
"id": 1
}'The DOCS_DIR = Path("docs").resolve() in the code is relative to the current working directory (CWD) when you run Python, not the script location.
Assume your directory structure:
D:\Codes\16_MCP\ <-- 根目录
├── main.py <-- 启动脚本
├── docs\ <-- 文档目录
└── srcs\
└── util\
└── docs_utils.py <-- 工具代码 (里面写了 Path("docs"))Case A: Running from root directory
cd D:\Codes\16_MCP
python main.pyCurrent Working Directory: D:\Codes\16_MCP
Path("docs") resolves to: D:\Codes\16_MCP\docs (Success)
Case B: Running from subdirectory (common error)
cd D:\Codes\16_MCP\srcs
python ../main.pyCurrent Working Directory: D:\Codes\16_MCP\srcs
Path("docs") resolves to: D:\Codes\16_MCP\srcs\docs (Fails - no docs folder)
To ensure paths work regardless of where you run from, use __file__-based absolute positioning:
from pathlib import Path
# Get current script directory
CURRENT_SCRIPT_DIR = Path(__file__).resolve().parent
# Navigate to project root
PROJECT_ROOT = CURRENT_SCRIPT_DIR.parent.parent
# Locate docs directory
DOCS_DIR = (PROJECT_ROOT / "docs").resolve()Overwrite (clears existing content):
ls > list.txtAppend (preserves existing content):
ls >> list.txtWith UTF8 encoding (recommended for Chinese):
ls | Out-File -FilePath output.txt -Encoding utf8See on screen and save:
ls | Tee-Object -FilePath log.txtThe server provides access to the complete official Godot documentation with this structure:
docs/
├── _styleguides
├── _tools
│ └── redirects
├── about
├── classes
├── community
│ └── asset_library
├── contributing
│ ├── development
│ │ ├── compiling
│ │ ├── configuring_an_ide
│ │ ├── core_and_modules
│ │ ├── debugging
│ │ │ └── vulkan
│ │ ├── editor
│ │ └── file_formats
│ ├── documentation
│ └── workflow
├── getting_started
│ ├── first_2d_game
│ ├── first_3d_game
│ ├── introduction
│ └── step_by_step
├── img
└── tutorials
├── 2d
├── 3d
│ ├── global_illumination
│ ├── particles
│ └── procedural_geometry
├── animation
├── assets_pipeline
│ ├── escn_exporter
│ └── importing_3d_scenes
├── audio
├── best_practices
├── editor
├── export
├── i18n
├── inputs
├── io
├── math
├── migrating
├── navigation
├── networking
├── performance
│ └── vertex_animation
├── physics
│ └── interpolation
├── platform
│ ├── android
│ ├── ios
│ └── web
├── plugins
│ └── editor
├── rendering
├── scripting
│ ├── c_sharp
│ │ └── diagnostics
│ ├── cpp
│ ├── debug
│ ├── gdextension
│ └── gdscript
├── shaders
│ ├── shader_reference
│ └── your_first_shader
├── ui
└── xrFor optimal results when working with Godot, use this system prompt:
"When working with Godot game development questions, always search for the latest available documentation using the godot-mcp-docs tools. Start with
get_documentation_tree()to understand the documentation structure, then useget_documentation_file()to retrieve specific information about classes, tutorials, or features. Prioritize official Godot documentation over general knowledge when providing Godot-related assistance."
To update to a newer version of Godot documentation:
uv run python .\docs_converter\godot_docs_converter.py
cd docs
tree /f > docs_tree.txtThis project is licensed under the MIT License - see the LICENSE file for details.
The Godot documentation content follows the original Godot documentation licensing:
Documentation content (excluding classes/ folder): CC BY 3.0
Class reference files (classes/ folder): MIT License
Attribution: "Juan Linietsky, Ariel Manzur and the Godot community"
Get the content of a specific documentation file.
Args: file_path: Path to the documentation file relative to the docs directory (e.g., "classes/class_camera2d.md").
Returns: The content of the requested documentation file, or an error message if not found.
Usage Example: - get_documentation_file("classes/class_camera2d.md") -> Content of class_camera2d.md
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns content or an error message, which covers basic success/failure behavior, but lacks details on permissions, rate limits, or other operational constraints. It adequately describes the core behavior but misses advanced contextual information.
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 with clear sections (description, args, returns, usage example), front-loaded with the core purpose, and every sentence adds value without redundancy. It efficiently communicates essential information in a compact format.
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 low complexity (1 parameter, no nested objects) and the presence of an output schema (which handles return value documentation), the description is mostly complete. It covers purpose, parameter semantics, and basic behavior, but could improve by addressing error handling details or constraints like file size limits.
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 description coverage is 0%, so the description must compensate. It explains the 'file_path' parameter with a clear example ('classes/class_camera2d.md') and specifies it's relative to the docs directory, adding meaningful context beyond the bare schema. However, it does not detail allowed file types or path validation rules.
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 specific action ('Get the content') and resource ('a specific documentation file'), distinguishing it from the sibling tool 'get_documentation_tree' which presumably retrieves a directory structure rather than file content. The verb+resource combination is precise and 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?
The description provides clear context for when to use this tool (to retrieve file content) and includes a usage example, but it does not explicitly state when NOT to use it or mention the sibling tool as an alternative for different needs. The example helps clarify the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a tree-style overview of the documentation folder.
Returns: String containing a directory tree representation of the documentation.
Usage Examples: - get_documentation_overview() -> Full docs tree from root
Note: Files are exposed via get_documentation_resource(file_path: str) resource.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a 'directory tree representation' as a string, which is useful behavioral context. However, it doesn't mention potential limitations like depth, formatting, or performance aspects. The description adds value but lacks comprehensive behavioral details.
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 with clear sections (Returns, Usage Examples, Note) and is front-loaded with the core purpose. It's concise, with each sentence adding value, though the usage example could be slightly more informative. Minimal waste, but not perfectly 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 the tool's simplicity (0 parameters, output schema exists), the description is reasonably complete. It explains what the tool does, provides a return type, and references related tools. However, it could benefit from more detail on the tree format or edge cases, keeping it from a perfect score.
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 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing on the tool's function. A baseline of 4 is applied since there are no parameters to document, and the description doesn't add unnecessary param info.
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 tool's purpose: 'Get a tree-style overview of the documentation folder.' It specifies the verb ('Get') and resource ('documentation folder'), and distinguishes it from the sibling tool get_documentation_file by mentioning that files are exposed via that other tool. However, it doesn't explicitly contrast the two tools' purposes beyond this mention, keeping it from a perfect score.
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 provides some usage context by noting that files are exposed via get_documentation_resource, implying this tool is for overview rather than file access. It includes a usage example, but lacks explicit guidance on when to use this tool versus alternatives (e.g., no clear 'when-not' scenarios). The guidelines are implied rather than explicit.
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.
v0.1.0get_documentation_fileget_documentation_treeScored across 2 tools
The two tools have clearly distinct purposes: get_documentation_file retrieves specific file content, while get_documentation_tree provides a structural overview. There is no overlap in functionality, making it impossible for an agent to confuse them.
Both tools follow a consistent verb_noun pattern with 'get_' prefix and snake_case naming. The naming is perfectly predictable across the tool set, with no deviations in style or convention.
With only 2 tools, the server feels thin for a documentation server that might benefit from additional operations like search, navigation, or metadata retrieval. While the tools cover basic reading and browsing, the count is borderline minimal for the apparent scope.
The server provides core read operations (get file, get tree) but lacks obvious enhancements like search functionality, content filtering, or version-specific documentation access. The surface is functional but incomplete for comprehensive documentation interaction, leaving notable gaps in typical documentation workflows.
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…
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
