Provides tools for searching and retrieving Godot Engine documentation, including the manual, tutorials, and class reference, with code examples.
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-docs-mcp what's the correct 4.x signature for move_and_slide?"
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 server that serves the Godot Engine documentation to AI coding agents.
Godot is under-represented in LLM training data relative to Unity and Unreal, so agents routinely hallucinate GDScript APIs, invent node names, and apply Godot 3.x idioms to 4.x projects. This server grounds them in the real docs: full-text search over the manual and tutorials, plus a structured class reference built from the engine's own API metadata.
Built on MCP specification revision 2026-07-28 via the official
mcp Python SDK v2, which also serves
every earlier protocol revision from the same server.
Status: in development. The server, its tools and resources, the command line, and the weekly workflow that publishes the index all work, and a prebuilt index for Godot 4.7 is published, so
syncinstalls one without a build. Not on PyPI yet — install from git, as below. Packaging as a Claude Code plugin, with skills, is a later phase.
The documentation is indexed offline into a single SQLite database, so lookups are fast and work without a network connection.
Content | Source | Why |
Manual, tutorials, getting started |
| The authored prose |
Class reference |
| Structured and typed — the |
docs.godotengine.org sits behind a Cloudflare challenge that rejects non-browser clients,
so the rendered site is not used as a source. Everything comes from GitHub.
Related MCP server: Godot MCP Documentation Server
Install the prebuilt index. It is one download of about 8 MB, and it only has to happen once per Godot version.
uvx --from git+https://github.com/mcintalmo/godot-docs-mcp godot-docs-mcp sync
uvx --from git+https://github.com/mcintalmo/godot-docs-mcp godot-docs-mcp statusThen point a client at it. For Claude Code:
claude mcp add godot-docs -- \
uvx --from git+https://github.com/mcintalmo/godot-docs-mcp godot-docs-mcpNo index published for the version you want, or working on the parsers? Build one from
source instead. That needs git and takes about a minute:
uvx --from git+https://github.com/mcintalmo/godot-docs-mcp godot-docs-mcp sync --rebuildAsk something a model reliably gets wrong — "what's the correct 4.x signature for
move_and_slide?" — and the answer should come back from get_godot_class_member as
bool move_and_slide(), with no arguments. It took several in Godot 3.x, which is what most
training data remembers.
Command | Purpose |
| Serve over stdio. This is what a client launches; |
| Download a prebuilt index. |
| What is indexed, what it was built from, and whether it has fallen behind. |
| Run a query through the same code the tools use, and print the ranking |
| Write the release assets for the installed index. For the build workflow |
Every setting is also an environment variable, prefixed GODOT_DOCS_MCP_ — see
config.py for the full table.
The documentation moves without warning, so two things track it independently.
A weekly workflow checks whether the upstream commits
have moved, and if they have, rebuilds the index, queries the whole corpus to confirm it
answers, and publishes it as a release asset. godot-docs-mcp sync is how that reaches you.
A running server checks once a day, in the background, whether a newer index has been
published. It never downloads one — an index that lags still answers correctly for the
version it was built from, and replacing it is your call. What it does instead is say so:
in godot://status, and as a one-line notice on search results. If the check cannot run,
the answer is "could not check", never "up to date".
Every tool is read-only, and every response is capped so that one call cannot crowd out the conversation it was meant to inform. A response that was cut says so, and names the call that returns the rest.
Tool | Purpose |
| Ranked search across the manual, tutorials, and class reference. Questions in plain words work |
| A page, or a single section of one |
| Inheritance chain plus a signature map for a class — no prose, so a 300 KB class entry stays answerable |
| Exact signature and full description for one member |
| GDScript and C# snippets, with the page and heading they came from |
URI | Content |
| Indexed version, counts, and the upstream commits it was built from |
| A map of the corpus: what it holds, how it is addressed, which tool to call |
| A page, or one section of it |
| A class, or one member of it |
The 515 pages and 1,078 classes are deliberately not enumerated in resources/list.
The templates are the URIs every tool already returns, so a search hit can be followed by
the host without a further tool call.
Requires uv.
uv sync --dev
uv run pre-commit installCommand | Purpose |
| Unit suite (hermetic — no network) |
| Integration tests against a real index |
| Lint and format |
| Type check |
| Everything the CI lint job runs |
See CLAUDE.md for the architecture and contribution conventions.
MIT. The Godot documentation itself is licensed CC BY 4.0 by Juan Linietsky, Ariel Manzur and the Godot community; this project redistributes an indexed form of it and does not alter that license.
Return one manual or tutorial page as Markdown, or a single section of it. Pass the uri from a search hit exactly as it was given: the #... on the end names the section that matched, and that section is what comes back -- section_title says which. Drop the #... to read the whole page. Pages are cut to fit the response budget: when truncated is set, section_titles lists the titles section accepts, so the rest can be read a section at a time. For a class-reference entry call get_godot_class instead -- this tool serves the prose documentation only.
Inputs: uri (required), section. Returns: A manual or tutorial page, whole or by the section.
Return a map of one engine class: what it inherits, what it is for, and the signature of every member it declares, without their descriptions. This is the cheap first call for any question about a class -- some class entries run past 300 KB, so the map is what makes them answerable. Choose the member needed from members, then call get_godot_class_member for its full text. Inherited members are not listed; request a class named in inheritance_chain to see those.
Inputs: class_name (required), include. Returns: A map of one class: what it is, what it inherits, and what it declares. Signatu…
Return the exact signature and full description of one member of one class. Use this to confirm a signature before writing a call: Godot's API changed substantially between 3.x and 4.x, and a remembered signature is often the 3.x one. Several members can share a name -- Godot overloads constructors and operators -- so members may hold more than one. If the name is wrong, the error names the closest members the class does declare, which is usually where a 3.x name is corrected to its 4.x form.
Inputs: class_name (required), member_name (required), member_kind. Returns: Full detail for every member of a class going by one name. Plural because Godot…
Search runnable code examples extracted from the documentation. Each sample carries its language tag, the URI of the page or class it came from, and the heading it appeared under. Use this when working code is wanted; use search_godot_docs when an explanation is wanted.
Inputs: query (required), limit, language. Returns: Runnable examples matching one query.
Search the Godot documentation -- manual, tutorials, and class reference -- and return ranked matches. Start here whenever the exact class or page is not already known. Natural-language questions work as well as keywords: framing words are stripped before searching, so 'how do I make a character jump' finds the tutorial rather than every page titled 'How do I'. Follow a hit with its own fields: uri is what fetch_godot_doc takes, and a hit from the class reference also carries class_name and member_name, which are what get_godot_class and get_godot_class_member take. At most one hit is returned per page or class; also_matched counts the further matches on that same source that were folded into it.
Inputs: query (required), kind, limit. Returns: Ranked matches for one query.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 5 tools
Each tool targets a distinct retrieval need: prose pages, document/code search, class overviews, and individual member details. Cross-references are explicit, such as fetch_godot_doc directing class-reference lookups to get_godot_class, so an agent is unlikely to confuse them.
All tool names use a lowercase snake_case verb_noun pattern: fetch/search/get followed by the object. The singular doc in fetch_godot_doc is meaningful because it fetches one page, while search_godot_docs searches the corpus, and get_godot_class_member extends get_godot_class naturally.
Five tools cover the full Godot docs workflow without bloat: search prose/classes, fetch prose, get class summaries, get member details, and search code examples. Each tool has a distinct role and none is redundant.
The surface covers the main documentation workflows: discovering sources via search, retrieving prose pages section-by-section, extracting cheap class overviews, drilling into individual members, and finding runnable examples. Search hits carry the exact fields needed by the retrieval tools, so there are no dead ends.
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…
