A
licenseA
qualityA
maintenanceConnects MCP clients directly to a live Godot editor, enabling AI assistants to build scenes, edit nodes, and control the editor through over 120 operations.
47
11,725 PyPI
2,549
MIT
Hermes_WorldKit_MCP
by DeployFaith
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., "@Hermes_WorldKit_MCPSummarize the current scene in the Godot editor."
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.
Hermes WorldKit MCP
A separate, first-party MCP control server for WorldKit's Godot editor adapter. Hermes launches the Python process over stdio; the process also binds a localhost-only WebSocket endpoint. The optional Godot 4.6 EditorPlugin connects outbound, authenticates, and proves it opened the exact pinned project root.
Vertical-slice capabilities
Report bridge/editor status and capabilities.
Summarize the currently edited scene.
List selected nodes in that scene.
Select one existing node by an edited-scene-relative path.
There is deliberately no terminal, file writing, GDScript evaluation, generic method invocation, arbitrary property mutation, autoload, or runtime dependency.
Related MCP server: Godot Universal MCP
Install
git clone https://github.com/DeployFaith/Hermes_WorldKit_MCP.git
cd Hermes_WorldKit_MCP
uv syncCopy addons/worldkit_mcp_bridge into the target Godot project's addons/ directory, then enable WorldKit MCP Bridge in Project Settings → Plugins. The addon remains optional and must not be copied into WorldKit's base addon payload.
Required configuration
Generate a random token and make the same value available to both the MCP process and the Godot editor environment:
export WORLDKIT_MCP_TOKEN="$(python -c 'import secrets; print(secrets.token_urlsafe(32))')"
export WORLDKIT_PROJECT_ROOT="/absolute/path/to/the/godot/project"Optional server settings:
export WORLDKIT_MCP_WS_HOST="127.0.0.1" # only loopback values are accepted
export WORLDKIT_MCP_WS_PORT="6506" # use 0 only in tests that pass the chosen URI to Godot
export WORLDKIT_MCP_REQUEST_TIMEOUT="5.0"The Godot addon reads WORLDKIT_MCP_TOKEN and, optionally, WORLDKIT_MCP_WS_URL (default ws://127.0.0.1:6506). The URL must be exactly ws://127.0.0.1:<port> or ws://[::1]:<port> with no credentials, path, query, or fragment. Start/restart Godot from an environment containing those values after changing them. Port 0 asks the Python bridge to choose an ephemeral port; it is intended for disposable tests because the selected port must then be supplied to Godot through WORLDKIT_MCP_WS_URL.
Hermes stdio configuration example
mcp_servers:
worldkit:
command: /absolute/path/to/Hermes_WorldKit_MCP/.venv/bin/worldkit-mcp
args: []
env:
WORLDKIT_MCP_TOKEN: "replace-with-the-same-random-token-used-by-godot"
WORLDKIT_PROJECT_ROOT: "/absolute/path/to/the/godot/project"
WORLDKIT_MCP_WS_PORT: "6506"The exact enclosing Hermes configuration keys may vary by installed Hermes version; the important stdio command and environment contract are shown above.
Wire protocol
Protocol version 2 uses mutual challenge-response authentication. Python sends a random server nonce; Godot replies with a client nonce and HMAC-SHA256 proof; Python returns its own proof before either side accepts the session. Proofs are bound to the protocol version and canonical project root, but neither the shared token nor project root is transmitted during authentication. Browser-origin WebSockets, malformed envelopes, wrong versions, mismatched roots/secrets, unsolicited response IDs, and a second simultaneous editor are rejected.
Accepted requests and responses carry a UUID request_id; responses use {ok, code, message, data}. The Python bridge turns cancellation, timeouts, protocol failures, and disconnects into stable structured errors. A timed-out selection reports SELECTION_OUTCOME_UNKNOWN because Godot may have applied it before the response was lost.
worldkit_scene_summary and worldkit_selected_nodes return a scene_token. worldkit_select_node(node_path, expected_scene_token) requires that exact token before changing selection, preventing a command inspected against one scene from affecting a newly opened scene. Paths are canonical relative paths under the edited root. Absolute paths, subnames, empty or . components, backslashes, and any .. segment are rejected before lookup. Internal nodes and nodes not owned by the current edited scene are excluded.
Scene inspection is bounded to 2,000 child-scan steps and 256 returned nodes; selected-node output is also capped at 256. The addon queues at most 64 requests and executes at most one request per editor frame.
Development checks
uv run pytest -q
uv run ruff check .
uv run python -m worldkit_mcp.schema_dump
uv run python scripts/verify_godot_editor_e2e.pyThe final command first verifies the executable is Godot 4.6, then launches a disposable headless editor and loads the real optional plugin. Its hostile fixture contains 2,005 wide root children plus a nested selectable node. The check completes mutual authentication, proves the scene summary stops at 256 returned nodes and reports truncation, changes the editor selection, reads it back, and proves that escaping, stale-scene, and noncanonical paths are rejected. It uses explicit runtime checks that remain active under python -O. Set WORLDKIT_GODOT_BIN if godot is not on PATH.
This headless editor integration check proves the transport and editor API behavior. It does not prove visible UI rendering or satisfy WorldKit's eventual human manual-QA gate.
Available Tools
5 toolsworldkit_capabilitiesARead-onlyIdempotent
List the safe WorldKit MCP tools and authenticated editor capabilities.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| code | Yes | |
| data | Yes | |
| message | Yes | |
| request_id | Yes |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no new behavioral context beyond stating it lists safe tools; it does not mention any authentication details or output specifics, but for a simple list operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the action and resource. No fluff, front-loaded with the verb 'List', and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with an output schema and annotations covering safety, the description is complete. It doesn't explain the distinction between 'safe WorldKit MCP tools' and 'authenticated editor capabilities', but that is minor given the tool's simplicity and the existing structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema correctly has no properties. With 100% schema coverage and no parameters, the baseline is 4; the description appropriately adds no parameter-related text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a clear resource ('safe WorldKit MCP tools and authenticated editor capabilities'). This clearly distinguishes the tool from sibling tools that report status, scene summary, selected nodes, or select a node. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools are listed but there is no mention of when to call this capability-listing tool instead of status or selection tools, nor any exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
worldkit_scene_summaryARead-onlyIdempotent
Summarize bounded nodes in the scene currently open for editing in Godot.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| code | Yes | |
| data | Yes | |
| message | Yes | |
| request_id | Yes |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about scope ('bounded nodes', 'scene currently open for editing') but does not describe output details or edge cases. With annotations covering side-effect behavior, this level of added context merits a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. Every word contributes to meaning: 'Summarize' (action), 'bounded nodes' (object), 'scene currently open for editing in Godot' (context). It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with an output schema and clear annotations, the description is mostly complete. It clarifies the prerequisite that a scene must be open for editing, but it does not explain what 'bounded nodes' means or what the summary includes, relying on the output schema for that. Minor gap, but generally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the parameter semantics baseline is 4. The description does not need to explain parameters, and the schema already shows an empty object, so no information is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Summarize') and resource ('bounded nodes in the scene currently open for editing in Godot'). It effectively communicates scope, but does not explicitly differentiate from sibling tools like 'worldkit_selected_nodes' or 'worldkit_status', so it stops short of full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, without any 'use when' or 'instead of' hints, leaving the agent to infer usage from the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
worldkit_selected_nodesARead-onlyIdempotent
List bounded selected nodes owned by the current edited scene.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| code | Yes | |
| data | Yes | |
| message | Yes | |
| request_id | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotent behavior (readOnlyHint=true, idempotentHint=true). The description adds useful scoping information ('bounded' nodes, 'current edited scene'), enriching the agent's understanding of what is included in the result. It does not contradict annotations and provides extra context beyond the safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately states the action and scope, making it quick to parse and easy to remember.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with an output schema (which covers return format), the description provides enough information: what is listed and from where. Minor ambiguity around the term 'bounded' is a small gap, but given the output schema and annotations, the overall context is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The description correctly focuses on behavior rather than parameters. Baseline for 0 parameters is 4, and the description meets that by being clear about what is being listed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') with a precise resource ('bounded selected nodes') and context ('owned by the current edited scene'). It clearly differentiates from sibling tools like worldkit_select_node (which modifies selection) and worldkit_scene_summary (which provides a broader scene overview), so an agent can tell exactly what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by specifying that it lists selected nodes limited to the current edited scene, which implies read-only inspection. However, it does not explicitly mention when to use it over alternatives such as worldkit_scene_summary or when not to use it. Lacks explicit exclusions or routing guidance, so a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
worldkit_select_nodeCIdempotent
Select a canonical relative node path only if the inspected scene token matches.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| node_path | Yes | ||
| expected_scene_token | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| code | Yes | |
| data | Yes | |
| message | Yes | |
| request_id | Yes |
TDQS
C2.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (idempotentHint=true, readOnlyHint=false, destructiveHint=false) already indicate a safe, non-destructive operation. The description adds the conditional behavior of requiring a token match, which is useful. However, it does not disclose what happens if the token does not match (e.g., error, no-op) or any side effects, even though it could.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loads the primary action and condition. It wastes no words, but could include more actionable details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 required parameters, an output schema, and no nested objects, the tool is simple, but the description lacks critical semantics for both parameters. An agent would not know the format of node_path (e.g., slash-separated) or how to obtain expected_scene_token (e.g., from worldkit_scene_summary). Given the 0% schema coverage, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It mentions 'canonical relative node path' and 'inspected scene token' but does not explain their format, meaning, or relationship. The condition 'only if the inspected scene token matches' implies expected_scene_token is compared to something, but no detail is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Select'), a resource ('canonical relative node path'), and a condition ('only if the inspected scene token matches'). However, the meaning of 'canonical relative node path' and 'inspected scene token' is not explained, and the tool's purpose is not clearly differentiated from siblings like worldkit_selected_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a condition for use ('only if the inspected scene token matches') which implies when to use, but does not explicitly state when not to use or mention alternatives. The sibling worldkit_selected_nodes suggests there is a related tool that selects nodes without a token condition, but no guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
worldkit_statusARead-onlyIdempotent
Report whether the pinned WorldKit Godot editor bridge is connected.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| code | Yes | |
| data | Yes | |
| message | Yes | |
| request_id | Yes |
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the specific subject (pinned bridge connection) but does not add behavioral detail beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word contributes to identifying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument read-only status tool with rich annotations and an output schema, the description is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so the input schema requires no further explanation. The description adds no parameter semantics but none are needed, making the baseline of 4 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: "Report whether the pinned WorldKit Godot editor bridge is connected." This clearly distinguishes the tool as a connectivity check, distinct from the sibling capability and scene/node tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the use case clear: check whether the bridge connection is active. It does not name alternatives or exclusions, but for a simple status probe the context is sufficient to guide correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
5 tool updates
v0.1.0- First observed
worldkit_capabilities - First observed
worldkit_scene_summary - First observed
worldkit_select_node - First observed
worldkit_selected_nodes - First observed
worldkit_status
TDQS
A3.7/5.0
Scored across 5 tools
Disambiguation5/5
Each tool addresses a distinct concern: connection status, capability discovery, scene content, current selection, and changing selection. The two node-related tools are separated by summary versus selected state, and the action verb in select_node makes its purpose clear.
Naming Consistency4/5
All tools share a consistent worldkit_ prefix and snake_case style, which makes them predictable. However, most names are noun-like while select_node is the only verb-led name, so the pattern is not perfectly uniform.
Tool Count5/5
Five tools is a tight, well-scoped set for a safe editor bridge. Each tool covers a necessary operation without redundancy.
Completeness4/5
The surface covers the core read-only workflow: verify connection, discover capabilities, summarize the scene, inspect selected nodes, and change selection. Minor gaps like deselecting or retrieving a specific node's full details are absent but are not fatal for the apparent safe-introspection purpose.
Maintenance
ActivitySlowing
ResponsivenessNo issues
Related MCP Connectors
Remote MCP server to read and manage your Atako AI agents, messages, files, and integrations.
Remote MCP server for Web3TV creators — manage your account over MCP.
- mcpOAuthco.aistoryhub
Remote MCP server for AIStoryHub: stories, chapters, story bible, Voiceprints, AI generation.
Related MCP Servers
- AlicenseBqualityBmaintenanceConnects MCP-capable AI clients to a running Godot 4 editor for scene, node, project, and debug runtime operations via a local-first architecture.361MIT
- AlicenseAqualityBmaintenanceMCP bridge between an AI assistant and the Godot editor, enabling control via 6 tools (call methods, run GDScript, screenshots, etc.) over WebSocket.1012 npm1MIT
- FlicenseCqualityBmaintenanceCustom MCP server for automating Godot Engine 4.x, enabling direct scene manipulation, node inspection, GDScript injection, and runtime testing via a WebSocket bridge.63-