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., "@Godot MCP Server Show me the current scene tree and read the player.gd script"
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.
Connect Claude to your Godot 4 project. Claude can read and manipulate scenes, nodes, scripts, and assets directly in your editor.
Claude (claude.ai)
│ MCP (stdio)
▼
godot-mcp-server (Node.js, runs locally)
│ HTTP localhost:9080
▼
MCP Bridge Plugin (GDScript, runs inside Godot editor)
│
▼
Godot EditorRelated MCP server: Godot MCP Server
cd godot-mcp-server
npm install
npm run buildCopy the godot-plugin/addons/mcp_bridge folder into your Godot project's addons/ directory:
your-godot-project/
└── addons/
└── mcp_bridge/
├── plugin.cfg
├── mcp_bridge.gd
└── mcp_http_server.gdThen in Godot: Project → Project Settings → Plugins → enable MCP Bridge.
You should see: [MCP Bridge] Listening on http://127.0.0.1:9080 in the Output panel.
Add to your Claude MCP config (claude_desktop_config.json or equivalent):
{
"mcpServers": {
"godot": {
"command": "node",
"args": ["/absolute/path/to/godot-mcp-server/dist/index.js"],
"env": {
"GODOT_PORT": "9080"
}
}
}
}Variable | Default | Description |
|
| Host where Godot is running |
|
| Port the MCP Bridge plugin listens on |
Tool | Description |
| List all open scenes |
| Get full node hierarchy |
| Get all properties of a specific node |
| Add a new node to a scene |
| Remove a node and its children |
| Set one or more properties on a node |
| Move a node to a new parent |
| Add a .tscn as an instance in a scene |
| Save the current scene to disk |
Tool | Description |
| Read a .gd file |
| Write/create a .gd file |
| Execute a GDScript expression in the editor |
Tool | Description |
| List files in the project |
| Get metadata about a resource |
| Assign a resource to a node property |
| Create a new empty .tscn file |
Once connected, you can ask Claude things like:
"Show me the scene tree of the current scene"
"Add a Sprite2D called PlayerSprite as a child of /root/Main/Player"
"Set the position of the Enemy node to (400, 300)"
"Instantiate res://enemies/goblin.tscn under /root/Level at position (200, 150)"
"List all .tscn files in the project"
"Read the player.gd script"
"Create a new scene at res://levels/level2.tscn with a Node2D root"
The MCP Bridge plugin must be active and Godot must be open for any tools to work.
godot_run_script executes arbitrary GDScript — use with care.
Scene edits are live in the editor but not saved automatically. Use godot_save_scene to persist changes.
The plugin binds to 127.0.0.1 only (no external access).
Adds a new node of the specified type as a child of the given parent node.
Args:
parent_path (string): Node path of the parent e.g. "/root/Main"
node_type (string): Godot class name e.g. "Sprite2D", "CharacterBody2D", "Label", "AudioStreamPlayer"
node_name (string): Name for the new node
scene_path (string, optional): Scene to modify. Defaults to active scene.
properties (object, optional): Initial property values to set on the new node.
Returns: { name, type, path } of the created node.
Examples:
Use when: "Add a Sprite2D called PlayerSprite under /root/Main"
Use when: "Add a Label node to the HUD with text 'Score: 0'"
| Name | Required | Description | Default |
|---|---|---|---|
| parent_path | Yes | Node path of the parent node | |
| node_type | Yes | Godot class name for the new node | |
| node_name | Yes | Name for the new node | |
| scene_path | No | Scene to modify. Omit for active scene. | |
| properties | No | Initial property key/value pairs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-readOnly, non-destructive mutation tool. The description adds valuable context beyond annotations: it specifies that it modifies scenes (with a default to active scene), describes the return format ({name, type, path}), and implies creation of new nodes rather than duplication. No contradictions with annotations exist.
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 (purpose, Args, Returns, Examples), front-loads the core functionality, and every sentence adds value. No redundant or verbose elements are present.
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 mutation tool with no output schema, the description provides good context: it explains the action, parameters, return format, and usage examples. However, it doesn't cover potential errors (e.g., invalid parent paths) or side effects (e.g., scene modification state), leaving minor gaps in completeness.
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?
With 100% schema description coverage, the schema already documents all parameters thoroughly. The description adds minimal extra meaning (e.g., examples of node_type values like 'Sprite2D', 'CharacterBody2D'), but doesn't significantly enhance understanding beyond the schema. This meets the baseline for high schema 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 clearly states the specific action ('Adds a new node') and resource ('as a child of the given parent node'), distinguishing it from siblings like godot_remove_node (removal) and godot_reparent_node (reparenting). The verb 'adds' is precise and 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 'Examples' section provides clear context for when to use this tool (e.g., adding specific node types with names), but it doesn't explicitly state when NOT to use it or mention alternatives like godot_instantiate_scene for instantiating existing scenes. The guidance is helpful but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Loads a resource and assigns it to a property of a node. Useful for setting textures, materials, audio streams, etc.
Args:
node_path (string): Node path e.g. "/root/Main/Player/Sprite2D"
property (string): Property name e.g. "texture", "material", "stream"
resource_path (string): res:// path to the resource to assign
scene_path (string, optional): Scene to modify. Defaults to active scene.
Returns: Confirmation of the assignment.
Examples:
Use when: "Set the player sprite texture to res://assets/player.png" -> node_path: "/root/Main/Player/Sprite2D", property: "texture", resource_path: "res://assets/player.png"
| Name | Required | Description | Default |
|---|---|---|---|
| node_path | Yes | Target node path | |
| property | Yes | Property to set the resource on | |
| resource_path | Yes | res:// path to the resource | |
| scene_path | No | Scene to modify. Omit for active scene. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it explains what gets modified (node properties), mentions the optional scene_path parameter with default behavior, and describes the return value ('Confirmation of the assignment'). Annotations cover idempotency and safety, but the description provides practical implementation details that help the agent understand the tool's behavior.
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 the core purpose, followed by organized sections (Args, Returns, Examples). Every sentence adds value: the first explains the tool's function, the second provides usage context, and subsequent sections offer practical guidance without redundancy.
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 mutation tool with no output schema, the description provides good coverage: it explains the tool's purpose, parameters, return value, and usage examples. The annotations cover safety aspects (idempotent, non-destructive), and the description adds practical implementation details. Minor gap: doesn't explicitly mention error conditions or what happens if the resource doesn't exist.
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?
With 100% schema description coverage, the baseline is 3. The description adds meaningful context by explaining the purpose of each parameter in the Args section, providing concrete examples of property values ('texture', 'material', 'stream'), and clarifying the optional scene_path behavior ('Defaults to active scene'). This goes beyond the schema's basic 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 clearly states the tool's purpose with specific verbs ('Loads a resource and assigns it to a property of a node') and distinguishes it from siblings like 'godot_set_node_property' by focusing on resource assignment rather than general property setting. It provides concrete examples of use cases (textures, materials, audio streams).
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 explicitly states when to use this tool ('Useful for setting textures, materials, audio streams, etc.') and provides a clear example scenario ('Set the player sprite texture to res://assets/player.png'). It distinguishes from siblings by focusing on resource assignment rather than general property setting or resource retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new empty scene file (.tscn) with a specified root node type.
Args:
scene_path (string): res:// path for the new scene e.g. "res://levels/level2.tscn"
root_type (string): Godot class for the root node e.g. "Node2D", "Node3D", "Control", "CharacterBody2D"
root_name (string, optional): Name for the root node (defaults to the scene file stem)
open_in_editor (boolean, optional): Open the new scene in the editor (default: true)
Returns: { path, root_node, root_type } of the created scene.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | Yes | res:// destination path for the new .tscn | |
| root_type | Yes | Godot class name for the root node | |
| root_name | No | Name for the root node | |
| open_in_editor | No | Open in editor after creation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, etc., so the agent knows this is a non-destructive write operation. The description adds useful context about the file format ('.tscn'), the optional 'open_in_editor' behavior, and the return structure, which goes beyond annotations. However, it doesn't mention potential errors (e.g., invalid paths, unsupported root types) or side effects.
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 a clear purpose statement followed by parameter and return sections. It's appropriately sized for a 4-parameter tool. However, the 'Args' section somewhat duplicates schema information, and the purpose statement could be slightly more front-loaded without the parameter details inline.
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 creation tool with full parameter documentation in the schema and annotations covering safety profile, the description provides adequate context. It explains the file format, includes examples, describes the return structure, and mentions the editor-opening behavior. The main gap is lack of error handling information, but overall it's reasonably 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 description coverage is 100%, so the schema already fully documents all parameters. The description repeats parameter information in the 'Args' section but doesn't add meaningful semantic context beyond what's in the schema (e.g., explaining what 'res://' paths mean, providing examples of valid root types beyond the examples given). Baseline 3 is appropriate when schema does the heavy lifting.
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 ('Creates a new empty scene file') with the resource type ('.tscn file') and key constraint ('with a specified root node type'). It distinguishes from siblings like 'godot_instantiate_scene' (which loads existing scenes) and 'godot_save_scene' (which saves modified scenes).
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 context through the parameter descriptions (e.g., 'res:// path', 'Godot class for the root node'), but doesn't explicitly state when to use this tool versus alternatives like 'godot_instantiate_scene' for loading existing scenes or 'godot_add_node' for adding nodes to existing scenes. The guidance is clear but lacks explicit sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all properties of a specific node by its scene path.
Args:
node_path (string): Full node path e.g. "/root/Main/Player" or "Player/Sprite2D"
scene_path (string, optional): Scene to look in. Defaults to active scene.
Returns: { name, type, path, properties: Record<string, unknown> }
Examples:
Use when: "What are the properties of the Player node?"
Use when: "Get transform of res://enemy.tscn root node"
| Name | Required | Description | Default |
|---|---|---|---|
| node_path | Yes | Node path within the scene | |
| scene_path | No | res:// path to the scene. Omit for active scene. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds value by specifying it returns 'all properties' and clarifies the return format with examples, though it doesn't mention rate limits or authentication needs. 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?
The description is well-structured with clear sections (description, Args, Returns, Examples), front-loaded with the core purpose. Every sentence adds value, such as clarifying the return format and providing usage examples, with 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?
Given the tool's low complexity, rich annotations (covering safety and idempotency), and 100% schema coverage, the description is complete. It includes purpose, parameters, return format, and usage examples, making it sufficient for an AI agent to select and invoke the tool correctly without an output schema.
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 documents both parameters fully. The description adds minimal extra context (e.g., 'Defaults to active scene' for scene_path, which is already in the schema). Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('Returns') and resource ('all properties of a specific node'), specifying it's by scene path. It distinguishes from siblings like godot_get_scene_tree (which gets tree structure) and godot_set_node_property (which modifies properties).
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 'Examples' section provides explicit 'Use when' scenarios that guide when to invoke this tool versus alternatives. It gives concrete examples like 'What are the properties of the Player node?' and 'Get transform of res://enemy.tscn root node', which help differentiate from tools like godot_get_scene_tree or godot_get_resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns metadata about a specific resource file (texture, audio, mesh, etc.).
Args:
resource_path (string): res:// path to the resource e.g. "res://assets/player.png"
Returns: { path, type, name, metadata: object }
| Name | Required | Description | Default |
|---|---|---|---|
| resource_path | Yes | res:// path to the resource |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds useful context by specifying the return format (path, type, name, metadata object) and clarifying it works on resource files, not just any file. 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?
The description is efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence adds value: the first defines the tool's function, the Args section clarifies parameter usage, and the Returns section specifies output format without redundancy.
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 read-only metadata retrieval tool with comprehensive annotations and 100% schema coverage, the description is mostly complete. It specifies the return format (compensating for no output schema) and resource examples. However, it could better explain metadata content or error cases for missing resources.
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% with one parameter (resource_path) fully documented in the schema. The description adds minimal value beyond the schema by providing an example path format ('res://assets/player.png'), but doesn't explain path validation or supported resource types. Baseline 3 is appropriate given high schema 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 clearly states the specific action ('Returns metadata about') and resource type ('specific resource file'), with examples of resource types (texture, audio, mesh). It distinguishes from siblings like godot_list_files (which lists files) and godot_get_node (which gets node info).
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 for retrieving metadata about existing resources, but doesn't explicitly state when to use this vs alternatives like godot_list_files (for listing) or godot_get_node (for node-specific info). No explicit when-not-to-use guidance or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full node hierarchy of the specified scene (or the currently active scene if no path given).
Args:
scene_path (string, optional): Path to the scene file e.g. "res://levels/main.tscn". Defaults to the active scene.
depth (number, optional): Maximum recursion depth (default: 10, max: 50).
Returns: Nested node tree: { name, type, path, children[], properties? }
Examples:
Use when: "Show me the scene tree" or "What nodes are in res://player.tscn?"
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No | res:// path to the scene. Omit for active scene. | |
| depth | No | Max depth to traverse |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable behavioral context beyond annotations: it specifies the default behavior (active scene if no path given), recursion depth limits (default: 10, max: 50), and the return structure (nested node tree with specific fields). No contradiction with annotations exists.
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 efficiently structured with a clear opening sentence stating the purpose, followed by organized sections (Args, Returns, Examples). Every sentence adds value: the first defines scope, Args clarifies parameters, Returns describes output, and Examples provides usage guidance. No wasted words.
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 moderate complexity (2 optional parameters, read-only operation), the description provides complete context: purpose, parameter usage, return structure, and examples. With annotations covering safety aspects and 100% schema coverage for inputs, the description fills all necessary gaps despite no output schema.
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 documents both parameters thoroughly. The description adds minimal value beyond the schema: it restates the optional nature of scene_path and depth's default/max values, but doesn't provide additional semantic context about parameter interactions or edge cases.
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 ('Returns the full node hierarchy') and resource ('of the specified scene'), distinguishing it from siblings like godot_get_node (which gets a single node) or godot_list_scenes (which lists scene files). The verb 'returns' and scope 'full node hierarchy' precisely define the tool's function.
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 explicitly provides usage guidance with 'Use when' examples ('Show me the scene tree' or 'What nodes are in res://player.tscn?'), giving clear context for when to invoke this tool. It also distinguishes from alternatives by specifying it returns the 'full node hierarchy' rather than individual nodes or scene lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Instantiates an existing .tscn file as a child node inside another scene.
Args:
scene_to_instantiate (string): res:// path of the scene to instance e.g. "res://enemies/goblin.tscn"
parent_path (string): Node path of the parent in the target scene e.g. "/root/Main"
node_name (string, optional): Override the instance name. Defaults to the scene file's stem.
target_scene_path (string, optional): Scene that will receive the instance. Defaults to active scene.
properties (object, optional): Properties to override on the root node of the instance.
Returns: { name, type, path } of the instantiated node.
Examples:
Use when: "Add a Goblin enemy to the level at position (300, 100)" -> scene_to_instantiate: "res://enemies/goblin.tscn", parent_path: "/root/Level" properties: { "position": {"x": 300, "y": 100} }
| Name | Required | Description | Default |
|---|---|---|---|
| scene_to_instantiate | Yes | res:// path to the .tscn to instance | |
| parent_path | Yes | Parent node path in the target scene | |
| node_name | No | Override instance name | |
| target_scene_path | No | Scene to add the instance to. Omit for active scene. | |
| properties | No | Property overrides on the instance root node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains that the tool creates a child node within a parent scene, specifies default behaviors (node_name defaults to scene file's stem, target_scene_path defaults to active scene), and describes the return format ('{ name, type, path } of the instantiated node'). Annotations already indicate this is a non-destructive, non-idempotent write operation, but the description enriches this with implementation 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 perfectly structured and front-loaded: the first sentence states the core purpose, followed by organized sections (Args, Returns, Examples) with zero wasted words. Every sentence serves a clear purpose, from explaining parameters to providing practical usage guidance.
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 tool with 5 parameters, no output schema, and annotations covering basic safety hints, the description is remarkably complete. It explains what the tool does, when to use it, all parameter meanings with examples, return format, and includes a practical use case. The combination of description and annotations provides everything needed for an agent to use this tool effectively.
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?
With 100% schema description coverage, the baseline is 3, but the description adds meaningful semantic context: it clarifies that 'scene_to_instantiate' must be a '.tscn file', provides concrete path examples ('res://enemies/goblin.tscn'), explains default behaviors for optional parameters, and shows how 'properties' can be used to set position in the example. This goes beyond the schema's technical 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 clearly states the specific action ('Instantiates an existing .tscn file as a child node inside another scene') with the exact resource type (.tscn files) and distinguishes it from siblings like godot_add_node (which likely creates new nodes) or godot_create_scene (which creates new scenes). 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 includes an explicit 'Examples' section with a 'Use when' scenario that demonstrates the tool's application ('Add a Goblin enemy to the level at position (300, 100)'), providing concrete guidance on when to use this tool. While it doesn't explicitly mention alternatives, the example implicitly distinguishes it from tools like godot_set_node_property (which modifies existing nodes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists files in the Godot project filesystem under a given directory.
Args:
directory (string, optional): res:// directory path (default: "res://")
filter_type (string, optional): Filter by extension e.g. "tscn", "gd", "png", "tres". Omit for all.
recursive (boolean, optional): Include subdirectories (default: false)
limit (number, optional): Max results (default: 50, max: 200)
offset (number, optional): Pagination offset (default: 0)
Returns: { total, count, offset, has_more, items: [{ path, type, name }] }
| Name | Required | Description | Default |
|---|---|---|---|
| directory | No | Directory to list | res:// |
| filter_type | No | File extension filter e.g. 'tscn' | |
| recursive | No | Include subdirectories | |
| limit | No | Max results | |
| offset | No | Pagination offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety aspects. The description adds valuable behavioral context beyond annotations: it specifies the return format with pagination details (total, count, offset, has_more) and item structure (path, type, name), which helps the agent understand what to expect. No contradictions 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?
The description is efficiently structured: a clear purpose statement followed by well-organized Args and Returns sections. Every sentence earns its place—no wasted words. The information is front-loaded with the core functionality stated first.
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 moderate complexity (5 parameters, list operation), rich annotations (readOnly, idempotent, non-destructive), and 100% schema coverage, the description is complete. It explains the purpose, parameters, and return format thoroughly. No output schema exists, so the Returns section is essential and well-provided.
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%, with all parameters well-documented in the schema. The description repeats parameter information in the Args section but adds minimal extra semantic value (e.g., 'res:// directory path' for directory, examples for filter_type). This meets the baseline of 3 when schema does the heavy lifting.
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 ('Lists files') and resource ('in the Godot project filesystem under a given directory'), distinguishing it from siblings like godot_list_scenes (which lists only scenes) and godot_get_scene_tree (which retrieves scene structure). 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 list files in the project filesystem) but doesn't explicitly state when not to use it or name alternatives. It distinguishes from godot_list_scenes by implication (files vs scenes), but lacks explicit 'use X instead for Y' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all scenes currently open in the Godot editor, including the active scene.
Returns: Array of scene objects: { path: string, root_node: string, root_type: string, node_count: number }
Examples:
Use when: "What scenes are open?" or "List all scenes"
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds context about returning 'currently open' scenes and including the active scene, which is useful behavioral detail beyond annotations, but doesn't cover aspects like rate limits or error conditions.
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, followed by return format and usage examples in a structured, efficient manner. Every sentence adds value without redundancy, making it easy to parse quickly.
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 (0 parameters, no output schema), rich annotations, and clear purpose, the description is nearly complete. It explains what the tool does, when to use it, and the return format. A minor gap is lack of explicit error handling or edge case details, but overall it's sufficient for agent use.
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?
With 0 parameters and 100% schema description coverage, the baseline is high. The description appropriately omits parameter details since none exist, focusing instead on return value semantics, which adds value beyond the empty 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 clearly states the specific action ('Returns all scenes currently open') and resource ('in the Godot editor'), including the active scene. It distinguishes from siblings like godot_list_files (which lists files) and godot_get_scene_tree (which gets scene structure).
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 explicit usage examples ('What scenes are open?' or 'List all scenes'), giving clear context for when to use this tool. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings, though the purpose implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the content of a GDScript (.gd) or other text-based resource file.
Args:
file_path (string): res:// path e.g. "res://player/player.gd"
Returns: { path: string, content: string }
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | res:// path to the script file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds value by specifying the file types (GDScript and text-based resources) and the return format (path and content), which are not covered by annotations, providing useful behavioral context without contradiction.
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 in the first sentence, followed by structured Args and Returns sections. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
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 (single parameter, read-only operation) and rich annotations, the description is mostly complete. It covers purpose, parameters, and return values, but lacks output schema details (e.g., structure of the returned object). However, with annotations handling safety and idempotency, it provides sufficient context for effective use.
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%, with the input schema fully documenting the file_path parameter. The description adds minimal semantics by providing an example path ('res://player/player.gd'), but does not elaborate on format constraints or edge cases beyond what the schema states. This meets the baseline for high schema 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 clearly states the specific action ('Reads the content') and resource type ('GDScript (.gd) or other text-based resource file'), distinguishing it from siblings like godot_write_script (write) and godot_list_files (list). It precisely defines what the tool does without being vague or tautological.
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 for reading script files, but does not explicitly state when to use this tool versus alternatives like godot_get_resource (which might handle non-text resources) or godot_run_script (which executes scripts). No explicit exclusions or prerequisites are provided, leaving usage context inferred rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Removes a node (and all its children) from the scene. This is destructive and cannot be undone via MCP.
Args:
node_path (string): Full node path to remove e.g. "/root/Main/OldEnemy"
scene_path (string, optional): Scene to modify. Defaults to active scene.
Returns: Confirmation message.
| Name | Required | Description | Default |
|---|---|---|---|
| node_path | Yes | Full node path to remove | |
| scene_path | No | Scene to modify. Omit for active scene. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds valuable context: it specifies that removal includes all children and cannot be undone via MCP, which clarifies the irreversible nature beyond the annotation. No contradiction with annotations exists.
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 action, followed by structured Args and Returns sections. Every sentence adds value: the first explains behavior, Args clarify parameters, and Returns sets expectations. No wasted words.
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 destructive tool with no output schema, the description is mostly complete: it explains the action, behavioral traits, and parameters. However, it doesn't detail error cases or prerequisites (e.g., scene must be loaded), leaving minor gaps given the complexity.
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 fully documents parameters. The description's Args section repeats schema info without adding extra meaning (e.g., format examples or edge cases). Baseline 3 is appropriate as the schema carries the burden.
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 action ('Removes a node'), specifies the resource ('from the scene'), and distinguishes from siblings by noting it removes children too, unlike tools like 'godot_reparent_node' or 'godot_set_node_property'. It's specific and avoids tautology.
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 it (to remove nodes from scenes) and mentions it's destructive, but doesn't explicitly state when not to use it or name alternatives like 'godot_reparent_node' for moving nodes instead. It's helpful but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Moves a node to a new parent within the same scene, preserving its world transform.
Args:
node_path (string): Node to move e.g. "/root/Main/Enemy"
new_parent_path (string): Destination parent e.g. "/root/Main/EnemyGroup"
scene_path (string, optional): Scene to modify. Defaults to active scene.
keep_global_transform (boolean, optional): Whether to preserve world-space transform (default: true)
Returns: New node path after reparenting.
| Name | Required | Description | Default |
|---|---|---|---|
| node_path | Yes | Node to reparent | |
| new_parent_path | Yes | Destination parent node path | |
| scene_path | No | Scene to modify. Omit for active scene. | |
| keep_global_transform | No | Preserve world-space transform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutable, non-destructive operation (readOnlyHint: false, destructiveHint: false), which the description aligns with by describing a 'move' that preserves transforms. The description adds valuable context beyond annotations: it specifies the operation occurs 'within the same scene' (scope constraint) and details the 'keep_global_transform' behavior (default true), which are not captured in 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?
The description is well-structured with a purpose statement upfront, followed by Args and Returns sections. It avoids redundancy, though the Args section slightly repeats schema info. Every sentence adds value (e.g., clarifying transform behavior and return value), but could be more front-loaded by integrating key details into the opening sentence.
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 mutation tool with no output schema, the description adequately covers purpose, parameters, and return value. It includes behavioral details (scene scope, transform preservation) and annotations provide safety context. However, it lacks error conditions (e.g., invalid paths) or side effects (e.g., impact on node references), leaving minor gaps in completeness.
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%, providing clear documentation for all parameters. The description adds minimal value beyond the schema—it restates parameter purposes in the Args section but doesn't elaborate on semantics like path format requirements or transform preservation implications. With high schema coverage, the 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 specific action ('Moves a node to a new parent'), the resource ('within the same scene'), and a key behavioral detail ('preserving its world transform'). It distinguishes from siblings like 'godot_remove_node' (deletion) and 'godot_set_node_property' (property modification) by focusing on hierarchical restructuring.
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 for node hierarchy changes within a scene, but provides no explicit guidance on when to use this versus alternatives like 'godot_remove_node' followed by 'godot_add_node', or prerequisites such as ensuring parent/child compatibility. The optional 'scene_path' parameter hints at context (active vs. specific scenes), but no when-not-to-use rules are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes a GDScript expression or block in the Godot editor context (via EditorScript). Useful for querying engine state or performing quick operations.
Args:
code (string): GDScript code to execute. Should be a valid expression or a series of statements. Has access to: Engine, ProjectSettings, EditorInterface (in editor context).
timeout_ms (number, optional): Max execution time in milliseconds (default: 5000, max: 30000).
Returns: { success: boolean, output: string, error?: string }
Examples:
Use when: "What is the current project name?" -> code: "ProjectSettings.get_setting('application/config/name')"
Use when: "List all files in res://levels/" -> code: "DirAccess.get_files_at('res://levels/')"
Warning: This runs arbitrary code in the editor. Use with care.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | GDScript code to execute | |
| timeout_ms | No | Execution timeout in ms |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations. Annotations indicate destructiveHint=true and non-idempotent, but the description elaborates with a 'Warning: This runs arbitrary code in the editor. Use with care.' It also mentions access to Engine, ProjectSettings, and EditorInterface, and specifies timeout behavior (default: 5000, max: 30000), enhancing transparency about risks and constraints.
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 the core purpose. It uses sections (Args, Returns, Examples, Warning) efficiently, with each sentence adding value—no redundancy. The examples are concise and illustrative, and the warning is placed appropriately without verbosity.
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 (executes arbitrary code, destructive) and lack of output schema, the description is mostly complete. It covers purpose, usage, parameters, returns, examples, and warnings. However, it could briefly mention error handling or typical output formats beyond the return structure, slightly limiting completeness for a high-risk 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?
With 100% schema description coverage, the baseline is 3. The description adds meaningful semantics: it explains that 'code' should be 'a valid expression or a series of statements' and 'Has access to: Engine, ProjectSettings, EditorInterface (in editor context).' For 'timeout_ms', it clarifies 'Max execution time in milliseconds (default: 5000, max: 30000),' providing context beyond the schema's numeric constraints.
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: 'Executes a GDScript expression or block in the Godot editor context (via EditorScript).' It specifies the action ('executes'), resource ('GDScript expression'), and context ('Godot editor context'), distinguishing it from siblings like godot_list_files or godot_set_node_property that perform different operations.
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 explicit usage guidance: 'Useful for querying engine state or performing quick operations.' It includes examples with 'Use when:' scenarios (e.g., 'What is the current project name?'), offering clear context for when to apply this tool versus alternatives like godot_get_scene_tree for specific data retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Saves the specified scene (or active scene) to disk.
Args:
scene_path (string, optional): res:// path of the scene to save. Omit for active scene.
save_as (string, optional): New res:// path to save a copy to (like Save As).
Returns: Confirmation with the saved path.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No | Scene to save. Omit for active scene. | |
| save_as | No | New path to save a copy (Save As) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-destructive, idempotent write operation (readOnlyHint: false, destructiveHint: false, idempotentHint: true). The description adds value by clarifying that it saves to disk and handles optional 'save_as' for copies, which provides context beyond annotations. No contradiction with annotations exists.
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 in the first sentence, followed by structured Args and Returns sections. Every sentence is necessary, with no wasted words, making it efficient and easy to parse.
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 moderate complexity (saving files), rich annotations, and full schema coverage, the description is mostly complete. It explains the action, parameters, and return confirmation. However, without an output schema, it could benefit from more detail on error cases or confirmation format, but it's sufficient for basic use.
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%, with clear parameter descriptions in the schema. The description's Args section repeats this information (e.g., 'Omit for active scene'), adding minimal extra meaning. This meets the baseline score of 3 for high schema 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 clearly states the tool's purpose with specific verbs ('saves') and resources ('scene'), distinguishing it from siblings like 'godot_create_scene' (creation) or 'godot_list_scenes' (listing). It specifies saving to disk, which is distinct from other scene-related operations.
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 on when to use this tool (to save scenes) and includes usage guidance in the Args section (e.g., 'Omit for active scene'). However, it does not explicitly state when not to use it or name alternatives for related operations, such as 'godot_create_scene' for new scenes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sets one or more properties on an existing node.
Args:
node_path (string): Full node path e.g. "/root/Main/Player"
properties (object): Key/value pairs to set. Values must be JSON-serialisable Godot variants. Common keys: "position", "rotation", "scale", "visible", "modulate", "text", "texture"
scene_path (string, optional): Scene to modify. Defaults to active scene.
Returns: Updated property values.
Examples:
Use when: "Move the Player to position (100, 200)" -> properties: { "position": {"x": 100, "y": 200} }
Use when: "Hide the HUD node" -> properties: { "visible": false }
| Name | Required | Description | Default |
|---|---|---|---|
| node_path | Yes | Node path to update | |
| properties | Yes | Properties to set as key/value pairs | |
| scene_path | No | Scene to modify. Omit for active scene. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover basic hints (readOnlyHint=false, destructiveHint=false), but the description adds valuable context: it specifies that values must be 'JSON-serialisable Godot variants', mentions common property keys, and clarifies the optional scene_path defaults to 'active scene'. This goes beyond annotations without contradicting them.
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 (Args, Returns, Examples), front-loaded purpose statement, and zero wasted sentences. Examples are directly tied to usage scenarios, making every element earn its place efficiently.
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 mutation tool with no output schema, the description is quite complete: it explains the action, parameters, return values, and provides examples. However, it could mention error cases (e.g., invalid node paths) or side effects, leaving minor gaps in contextual coverage.
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?
With 100% schema description coverage, the baseline is 3. The description adds some value by listing common property keys and clarifying the scene_path default, but it doesn't provide deep semantic insights beyond what the schema already documents (e.g., node_path format, properties as key/value pairs).
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 ('Sets one or more properties') on a specific resource ('on an existing node'), distinguishing it from siblings like godot_add_node (creates new nodes) and godot_remove_node (deletes nodes). The verb 'Sets' is precise and the resource 'existing node' 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 provides clear context through examples ('Move the Player to position', 'Hide the HUD node'), which implicitly guides when to use this tool. However, it lacks explicit guidance on when NOT to use it (e.g., vs. godot_add_node for new nodes) or named alternatives, preventing a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Writes (creates or overwrites) a GDScript file at the given path.
Args:
file_path (string): res:// path e.g. "res://player/player.gd"
content (string): Full GDScript source code to write.
Returns: Confirmation with the file path.
Examples:
Use when: "Create a new movement script for the Player"
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | res:// path for the script | |
| content | Yes | Full GDScript source code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-readOnly, idempotent, non-destructive write operation. The description adds valuable context beyond annotations by explicitly stating 'creates or overwrites' (clarifying idempotent behavior) and specifying the file path format ('res:// path'), which helps the agent understand the tool's behavior more concretely.
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 efficiently structured with a clear purpose statement, organized sections (Args, Returns, Examples), and no redundant information. Every sentence serves a distinct purpose, making it easy to parse.
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 write operation with good annotations (idempotent, non-destructive) and full parameter documentation, the description provides adequate context including purpose, usage example, and behavioral clarification. The lack of an output schema is compensated by the 'Returns' note, though more detail on the confirmation format would be helpful.
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%, with both parameters well-documented in the schema. The description's 'Args' section repeats the schema information without adding significant semantic context beyond what's already in the structured fields, meeting the baseline for high schema 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 clearly states the specific action ('writes'), resource ('GDScript file'), and scope ('creates or overwrites') with the path parameter. It distinguishes from siblings like godot_read_script (read vs. write) and godot_list_files (list vs. write).
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 'Examples: - Use when:' section provides clear context for when to use this tool ('Create a new movement script for the Player'), but it doesn't explicitly state when not to use it or name alternatives like godot_read_script for reading existing scripts.
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.
v1.0.0godot_add_nodegodot_assign_resourcegodot_create_scenegodot_get_nodegodot_get_resourcegodot_get_scene_treegodot_instantiate_scenegodot_list_filesgodot_list_scenesgodot_read_scriptgodot_remove_nodegodot_reparent_nodegodot_run_scriptgodot_save_scenegodot_set_node_propertygodot_write_scriptScored across 16 tools
Each tool has a distinct purpose with clear boundaries: node operations (add, get, remove, reparent, set property), scene operations (create, get tree, instantiate, save, list), resource operations (assign, get), file operations (list files, read/write script), and a general-purpose run_script. No significant overlap exists; descriptions clarify specific use cases.
All tools follow a consistent 'godot_verb_noun' pattern with snake_case throughout. The verb-noun structure is predictable (e.g., godot_add_node, godot_get_scene_tree), making the set easy to navigate and understand.
16 tools is slightly high but reasonable for a Godot editor server covering nodes, scenes, resources, files, and scripts. Each tool serves a specific function, though some could potentially be consolidated (e.g., list_files and list_scenes). The count aligns well with the domain's complexity.
The toolset provides comprehensive coverage for Godot editor interactions: full CRUD for nodes (add, get, remove, reparent, set property), scene lifecycle (create, instantiate, save, list), resource handling (assign, get), file management (list, read/write scripts), and advanced operations (run_script). No obvious gaps exist for typical agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Manage your IoT device fleet directly from Claude. Create device templates with datastreams and events, provision new devices, read live sensor data, and control outputs. The Blynk connector integrates with the Blynk IoT platform, enabling direct configuration and monitoring of connected devices and infrastructure.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Create projects, nodes, and tasks in UluP Spaces by conversation with Claude.
