Provides tools for managing Godot projects, scenes, nodes, and editor operations, enabling AI assistants to interact directly with the Godot game engine.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Godot MCP Add a 2D sprite to the current scene"
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.
A comprehensive Model Context Protocol (MCP) server for seamless AI assistant integration with the Godot game engine.
Related MCP server: Godot MCP server
Godot MCP bridges the gap between AI assistants and the Godot game engine by providing a standardized Model Context Protocol interface. This powerful integration enables AI assistants like Claude, Cursor, and Cline to directly interact with Godot projects through a comprehensive set of tools.
Direct Godot Integration: Launch editors, run projects, and capture debug output programmatically
Scene Management: Create, modify, and manage Godot scenes through AI commands
Real-time Feedback: AI assistants can see actual Godot output and errors for better assistance
Cross-platform Compatibility: Works seamlessly on Windows, macOS, and Linux
Secure Operations: Optional read-only mode for safe project analysis
Zero Configuration: Automatic Godot detection with manual override options
The server acts as a middleware layer between your AI assistant and Godot, translating natural language commands into specific Godot operations. When you ask your AI to "create a player scene with a sprite," the MCP server:
Validates the request and project structure
Executes the appropriate Godot operations
Returns detailed success/error feedback
Enables the AI to understand and respond to the results
This creates a powerful feedback loop where AI assistants can learn from actual Godot behavior, leading to more accurate code generation and debugging assistance.
š Launch Godot Editor: Open the Godot editor for specific projects
ā¶ļø Run Godot Projects: Execute projects in debug mode with real-time output capture
š Control Execution: Start and stop Godot projects programmatically
š Debug Output Capture: Retrieve comprehensive console output and error messages
ā¹ļø System Information: Get installed Godot version and project metadata
š Project Discovery: Find and list Godot projects in specified directories
š¬ Create New Scenes: Generate scenes with specified root node types
ā Add Nodes: Insert nodes into existing scenes with customizable properties
āļø Edit Node Properties: Modify positions, scales, textures, and other node attributes
šļø Remove Nodes: Clean up scenes by removing unwanted nodes
š¼ļø Load Sprites: Automatically load textures into Sprite2D nodes
š§± Export MeshLibrary: Convert 3D scenes to MeshLibrary resources for GridMap
š¾ Save Scene Variants: Create scene copies and manage scene versions
š Get File UIDs: Retrieve unique identifiers for project resources
š Update UID References: Maintain proper resource links during project upgrades
š Read-Only Mode: Restrict operations to analysis-only for secure environments
ā Path Validation: Comprehensive project and file path verification
š”ļø Error Handling: Robust error reporting with actionable suggestions
Godot Engine: Version 3.5+ or 4.0+ (latest stable recommended)
Node.js & npm
Cline & Roo Code: Full support with auto-approval configuration
Cursor & VS Code: Supports both UI and project-specific configuration
Claude Desktop: Compatible with MCP server integration
Other MCP-enabled tools: Any tool supporting the Model Context Protocol
# Clone the repository
git clone https://github.com/bradypp/godot-mcp.git
cd godot-mcp
# Install dependencies
npm install
# Build the project
npm run buildAdd to your Cline MCP settings file:
{
"mcpServers": {
"godot": {
"command": "node",
"args": ["/absolute/path/to/godot-mcp/build/index.js"],
"env": {
"DEBUG": "false",
"READ_ONLY": "false",
"GODOT_PATH": "/path/to/godot"
},
"disabled": false,
"autoApprove": [
"launch_editor",
"run_project",
"get_debug_output",
"stop_project",
"get_godot_version",
"list_projects",
"get_project_info",
"create_scene",
"add_node",
"edit_node",
"remove_node",
"load_sprite",
"export_mesh_library",
"save_scene",
"get_uid",
"update_project_uids"
]
}
}
}Open Cursor Settings ā Features ā MCP
Click + Add New MCP Server
Configure:
Name: godot
Type: command
Command: node /absolute/path/to/godot-mcp/build/index.js
Click Add and refresh the server list
Create .cursor/mcp.json in your project root:
{
"mcpServers": {
"godot": {
"command": "node",
"args": ["/absolute/path/to/godot-mcp/build/index.js"],
"env": {
"DEBUG": "false",
"GODOT_PATH": "/path/to/godot",
"READ_ONLY_MODE": "false"
}
}
}
}Variable | Description | Default | Example |
| Path to Godot executable | Auto-detected |
|
| Enable detailed logging |
|
|
| Restrict to read-only operations |
|
|
get_godot_versionGet the installed Godot version information.
Parameters: None
Example Response:
{
"version": "4.2.1.stable",
"platform": "linux.x86_64"
}launch_editorLaunch the Godot editor for a specific project.
Parameters:
projectPath (string, required): Path to the Godot project directory
Example:
{
"projectPath": "/home/user/my-game"
}run_projectExecute a Godot project and capture output.
Parameters:
projectPath (string, required): Path to the Godot project directory
scene (string, optional): Specific scene to run
Example:
{
"projectPath": "/home/user/my-game",
"scene": "scenes/MainMenu.tscn"
}list_projectsFind Godot projects in a specified directory.
Parameters:
directory (string, required): Directory to search for projects
recursive (boolean, optional): Whether to search recursively (default: false)
get_project_infoRetrieve detailed metadata about a Godot project.
Parameters:
projectPath (string, required): Path to the Godot project directory
Example Response:
{
"name": "My Awesome Game",
"path": "/home/user/my-awesome-game",
"godotVersion": "4.2.1.stable.official",
"structure": {
"scenes": 12,
"scripts": 8,
"assets": 45,
"other": 3
}
}create_sceneCreate a new scene in a Godot project.
Parameters:
projectPath (string, required): Path to the Godot project directory
scenePath (string, required): Path for the new scene file (relative to project)
rootNodeType (string, optional): Type of the root node (default: "Node2D")
Example:
{
"projectPath": "/home/user/my-game",
"scenePath": "scenes/Player.tscn",
"rootNodeType": "CharacterBody2D"
}add_nodeAdd a node to an existing scene.
Parameters:
projectPath (string, required): Path to the Godot project directory
scenePath (string, required): Path to the scene file (relative to project)
nodeType (string, required): Type of node to add (e.g., "Sprite2D", "CollisionShape2D")
nodeName (string, required): Name for the new node
parentNodePath (string, optional): Path to parent node (defaults to root)
properties (object, optional): Additional properties to set
Example:
{
"projectPath": "/home/user/my-game",
"scenePath": "scenes/Player.tscn",
"nodeType": "Sprite2D",
"nodeName": "PlayerSprite",
"properties": {
"position": { "x": 100, "y": 50 },
"scale": { "x": 2.0, "y": 2.0 }
}
}edit_nodeEdit properties of an existing node in a scene.
Parameters:
projectPath (string, required): Path to the Godot project directory
scenePath (string, required): Path to the scene file (relative to project)
nodePath (string, required): Path to the node to edit
properties (object, required): Properties to update
Example:
{
"projectPath": "/home/user/my-game",
"scenePath": "scenes/Player.tscn",
"nodePath": "PlayerSprite",
"properties": {
"position": { "x": 200, "y": 100 },
"modulate": { "r": 1.0, "g": 0.5, "b": 0.5, "a": 1.0 }
}
}remove_nodeRemove a node from a scene.
Parameters:
projectPath (string, required): Path to the Godot project directory
scenePath (string, required): Path to the scene file (relative to project)
nodePath (string, required): Path to the node to remove
load_spriteLoad a texture into a Sprite2D node.
Parameters:
projectPath (string, required): Path to the Godot project directory
scenePath (string, required): Path to the scene file (relative to project)
nodePath (string, required): Path to the Sprite2D node
texturePath (string, required): Path to the texture file (relative to project)
save_sceneSave a scene, optionally as a new variant.
Parameters:
projectPath (string, required): Path to the Godot project directory
scenePath (string, required): Path to the scene file (relative to project)
newPath (string, optional): New path to save as variant
get_debug_outputRetrieve current debug output and errors from running projects.
Parameters: None
stop_projectStop any currently running Godot project.
Parameters: None
get_uidGet the UID for a specific file in a Godot project.
Parameters:
projectPath (string, required): Path to the Godot project directory
filePath (string, required): Path to the file (relative to project)
update_project_uidsUpdate UID references in a project by resaving resources.
Parameters:
projectPath (string, required): Path to the Godot project directory
The Godot MCP server follows a modular architecture designed for maintainability and extensibility:
src/
āāā config/ # Configuration management
āāā core/ # Core functionality
ā āāā GodotExecutor.ts # Godot command execution
ā āāā PathManager.ts # Path detection and validation
ā āāā ProcessManager.ts # Process lifecycle management
ā āāā ParameterNormalizer.ts # Input parameter handling
āāā server/ # MCP server implementation
ā āāā GodotMCPServer.ts # Main server class
ā āāā types.ts # Type definitions
āāā tools/ # Tool implementations
ā āāā BaseToolHandler.ts # Shared tool functionality
ā āāā ToolRegistry.ts # Tool registration and filtering
ā āāā debug/ # Debug-related tools
ā āāā project/ # Project management tools
ā āāā scene/ # Scene manipulation tools
ā āāā system/ # System information tools
ā āāā uid/ # UID management tools
āāā utils/ # Utility functions
āāā scripts/ # Godot operation scriptsModular Tool System: Each tool is self-contained with its own definition and handler
Centralized Configuration: Environment variables and settings managed in one location
Robust Error Handling: Comprehensive error reporting with actionable suggestions
Security First: Read-only mode and input validation protect against misuse
Cross-platform Support: Platform-agnostic design with OS-specific handling where needed
Tools are registered in the ToolRegistry with metadata indicating their capabilities:
export interface ToolRegistration {
definition: ToolDefinition;
handler: (args: any) => Promise<ToolResponse>;
readOnly: boolean;
}The registry automatically filters tools based on the current mode (read-only vs. full access) and provides a unified interface for tool discovery and execution.
Complex Godot operations use a centralized GDScript approach:
Single Script File: All operations consolidated in godot_operations.gd
JSON Parameter Passing: Operations receive structured parameters
No Temporary Files: Eliminates file system overhead and cleanup complexity
Consistent Error Handling: Standardized error reporting across all operations
This architecture provides better performance, maintainability, and reliability compared to generating temporary scripts for each operation.
"Launch the Godot editor for my project at /path/to/my-game"
"Run my Godot project and show me any errors"
"Get information about my project structure and settings""Create a new Player scene with a CharacterBody2D root node"
"Add a Sprite2D node called 'PlayerSprite' to my Player scene"
"Load the character texture 'textures/player.png' into the PlayerSprite node"
"Set the Player's position to (100, 50) and scale to 2x"
"Create a CollisionShape2D node as a child of the Player root""Create a complete UI scene with buttons for Start Game, Settings, and Quit"
"Export my 3D level models as a MeshLibrary for use with GridMap"
"Analyze my project structure and suggest performance improvements"
"Debug this GDScript error and help me fix the character controller"
"Create a save system scene with file I/O nodes and data management"Read-only mode provides a secure way to analyze Godot projects without making any modifications. This is ideal for CI/CD pipelines, code reviews, educational environments, and shared development scenarios.
Set the READ_ONLY_MODE environment variable to "true":
{
"mcpServers": {
"godot": {
"command": "node",
"args": ["/absolute/path/to/godot-mcp/build/index.js"],
"env": {
"READ_ONLY_MODE": "true"
}
}
}
}System Tools:
get_godot_version: Get Godot version information
Project Tools:
launch_editor: Launch Godot editor
run_project: Run projects to analyze behavior
list_projects: Discover projects in directories
get_project_info: Retrieve project metadata
Debug Tools:
get_debug_output: Capture console output
stop_project: Stop running projects
UID Tools:
get_uid: Get file UIDs (Godot 4.4+)
Scene Modification Tools:
create_scene: Create new scenes
add_node: Add nodes to scenes
edit_node: Modify node properties
remove_node: Remove nodes from scenes
load_sprite: Load textures into nodes
export_mesh_library: Export MeshLibrary resources
save_scene: Save scene modifications
UID Modification Tools:
update_project_uids: Update UID references
š CI/CD Pipelines: Automated project analysis without risk of modification
š„ Code Reviews: Safe project inspection for team collaboration
š Documentation: Extract project information for automated documentation
š Debugging: Analyze project behavior without modification risk
Error: Could not find a valid Godot executable path
Solutions:
Set GODOT_PATH environment variable:
export GODOT_PATH="/path/to/godot"
# or for Windows:
set GODOT_PATH="C:\Program Files\Godot\godot.exe"Verify Godot installation:
# Test if Godot is accessible
godot --version
# or try:
godot4 --versionCommon Godot paths:
Windows: C:\Program Files\Godot\godot.exe
macOS: /Applications/Godot.app/Contents/MacOS/Godot
Linux: /usr/bin/godot4 or /usr/local/bin/godot
Error: MCP server not responding or tools not available
Solutions:
Restart your AI assistant after configuration changes
Check server logs by enabling debug mode: "DEBUG": "true"
Verify configuration path is absolute and correct
Test server manually:
node /path/to/godot-mcp/build/index.jsError: Invalid project path or project.godot not found
Solutions:
Ensure path contains project.godot:
ls /path/to/project/project.godotUse absolute paths when possible
Check file permissions on the project directory
Error: Build fails or dependencies missing
Solutions:
Clean and rebuild:
npm run clean
npm install
npm run buildClear npm cache:
npm cache clean --forceIf you encounter issues not covered here:
Check debug logs with DEBUG=true
Search existing issues on GitHub
Create a detailed issue report with:
Operating system and version
Node.js and Godot versions
Complete error messages
Configuration used
Steps to reproduce
Q: What versions of Godot are supported? A: Godot 3.5+ and all Godot 4.x versions. Some features (like UID management) require Godot 4.4+.
Q: Can I use this with Godot 3.x projects? A: Yes, most features work with Godot 3.5+. Scene management and project operations are fully supported.
Q: Is this safe to use on production projects? A: Yes, especially with read-only mode enabled. The server includes comprehensive validation and error handling.
Q: How does the server detect my Godot installation?
A: The server checks common installation paths for each platform. You can override detection with the GODOT_PATH environment variable.
Q: Can I run multiple instances of the server? A: Yes, each instance operates independently. Useful for working with multiple projects simultaneously.
Q: What happens if Godot crashes during an operation? A: The server detects process failures and returns appropriate error messages with suggestions for resolution.
Q: Are temporary files created during operations? A: No, the server uses a bundled GDScript approach that avoids temporary file creation for better performance and security.
Q: Which AI assistants work with this server? A: Any AI assistant supporting the Model Context Protocol, including Cline, Roo Code, Cursor, VS Code, Claude Desktop, and others.
Q: Can I customize which tools are available? A: Yes, through the autoApprove configuration or by modifying the tool registry for custom builds.
Q: How do I know if the integration is working? A: The AI assistant should be able to list available tools and execute them. Enable debug mode to see detailed operation logs.
Q: Can I add custom tools to the server?
A: Yes, the modular architecture makes it easy to add new tools. See CONTRIBUTING.md for development guidelines.
Q: How do I contribute to the project? A: Fork the repository, make your changes, and submit a pull request. Please follow the existing code style and include tests.
Q: Is the server extensible for other game engines? A: The MCP architecture is engine-agnostic, but this implementation is specifically designed for Godot. Similar servers could be created for other engines.
We welcome contributions to improve Godot MCP! Please see our CONTRIBUTING.md guide for:
Development setup instructions
Code style guidelines
Testing procedures
Pull request process
Issue reporting guidelines
# Fork and clone the repository
git clone https://github.com/your-username/godot-mcp.git
cd godot-mcp
# Install dependencies
npm install
# Start development mode
npm run dev
# Run tests
npm test
# Build for production
npm run buildThis project is licensed under the MIT License - see the LICENSE file for details.
This project was originally forked from Coding-Solo/godot-mcp.
š Bug Reports: GitHub Issues
š” Feature Requests: GitHub Discussions
š Documentation: This README and inline code documentation
š¬ Community: Join discussions about Godot MCP and AI-assisted development
Built with ā¤ļø for the Godot and AI development communities
Add a node to an existing scene in a Godot project
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Path to the Godot project directory | |
| scenePath | Yes | Path to the scene file (relative to project) | |
| nodeType | Yes | Type of the node to add (e.g., Node2D, Sprite2D, RigidBody2D) | |
| nodeName | Yes | Name for the new node | |
| parentNodePath | No | Path to the parent node (optional, defaults to root) | |
| properties | No | Additional properties to set on the node (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only says 'Add a node' without mentioning side effects (e.g., scene saving, project requirements) or limitations. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste. It is appropriately concise for a basic action description.
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?
With 6 parameters (some nested) and no output schema, the description is too sparse. It does not explain return values, error states, or how to interpret results, making it incomplete for complex usage.
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 baseline is 3. The description does not add any extra meaning beyond the schema; it simply summarizes the operation without explaining parameter details or interactions.
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 (Add) and resource (node to an existing scene in a Godot project). It differentiates from siblings like remove_node and create_scene. However, it could be more specific about what adding a node entails in Godot context.
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 no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It merely states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new scene in a Godot project
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Path to the Godot project directory | |
| scenePath | Yes | Path for the new scene file (relative to project) | |
| rootNodeType | No | Type of the root node (default: Node2D) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must bear the full burden of behavioral disclosure. It only states 'create', which implies a write operation, but does not explain side effects (e.g., file creation, overwrite behavior, required permissions) or the resulting state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no superfluous words. It is front-loaded with the key action, though it could benefit from additional context without becoming verbose.
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 lack of annotations and output schema, and the presence of 16 sibling tools, the description is incomplete. It does not explain the tool's role in the workflow, how it differs from creating nodes or saving scenes, or what happens after creation.
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 baseline is 3. The description does not add additional meaning beyond what the parameter descriptions already provide, nor does it explain inter-parameter dependencies or usage hints.
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 'Create' and the resource 'new scene' in a Godot project. It is not a tautology and distinguishes from siblings like 'add_node' which adds nodes to existing scenes, though it does not explicitly differentiate from 'save_scene'.
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 no guidance on when to use this tool versus alternatives like 'add_node' or 'save_scene'. There is no mention of prerequisites or context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit properties of an existing node in a Godot scene
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Path to the Godot project directory | |
| scenePath | Yes | Path to the scene file (relative to project) | |
| nodePath | Yes | Path to the node to edit (e.g., "Player", "UI/HealthBar") | |
| properties | Yes | Properties to set on the node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only says 'Edit properties' without detailing behavior like merge vs replace, error handling, 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?
Single sentence with no waste, front-loads purpose. Efficient but lacks structure for additional details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no description of return values or error conditions. For a mutation tool with 4 required params, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds no extra meaning beyond schema. Baseline is 3 for adequate coverage; no added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Edit properties of an existing node in a Godot scene' with specific verb and resource. Distinguishes from siblings like 'add_node' and 'remove_node'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a 3D scene as a MeshLibrary resource for GridMap
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Path to the Godot project directory | |
| scenePath | Yes | Path to the 3D scene file (relative to project) | |
| outputPath | Yes | Path for the output MeshLibrary resource (relative to project) | |
| meshItemNames | No | Names of specific mesh items to include (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the action (export) but does not disclose side effects (e.g., file overwrite, project modification), required permissions, or error conditions. The minimal description fails to inform the agent of behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. However, it could be slightly expanded to include behavioral or usage notes without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more context about the tool's return value, file creation behavior, and error conditions. Currently it only states the transformation, leaving the agent unsure of what to expect.
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?
All 4 parameters are fully documented in the input schema with clear descriptions (100% coverage). The tool description does not add meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb (Export), resource (3D scene), target format (MeshLibrary resource), and intended use (for GridMap). It uniquely identifies the tool among siblings, which include scene creation and editing tools, not export 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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, common scenarios, or exclusions. For a tool that converts scene data, explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current debug output and errors
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It merely states the action without mentioning side effects, requirements (e.g., running project), return format, or error behavior. The word 'Get' implies a read operation, but this is not explicit and no other behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently communicates the core function with no filler. It is appropriately sized for a zero-parameter tool, though it sacrifices completeness for brevity.
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?
Despite the tool's simplicity, the description omits important context such as when debug output is available, whether a project must be running, and the format of the returned output. With no annotations or output schema, these gaps make the description incomplete for an agent deciding to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema already fully covers parameter semantics. The description adds no parameter information, but none is needed; baseline 4 applies.
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 states a specific verb ('Get') and resource ('current debug output and errors'), clearly identifying the tool's function. It does not explicitly differentiate from sibling getters like get_project_info or get_uid, but the resource is unique enough that an agent can infer its purpose. However, 'current' is ambiguous (current project? current session?), so not a 5.
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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., project running) or exclusion cases, and there is no reference to sibling tools like run_project or stop_project. An agent is left without context on when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the installed Godot version
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states what it does, without mentioning side effects, error handling (e.g., if Godot is not installed), or whether any configuration is modified. For a simple getter this is a gap, but the lack of side effects is implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no redundancy. The information is front-loaded and every word earns its place. Perfectly concise.
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 zero-parameter getter with no output schema, the description is largely sufficient. It identifies what is retrieved, but does not explicitly describe the return format (e.g., version string) or behavior if Godot is absent. Given the simplicity, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema confirms this with an empty properties object. Per the rubric, 0 parameters warrants a baseline of 4. The description does not need to add parameter details, and it correctly does not.
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 ('Get') and the resource ('installed Godot version'). It is specific and distinguishes itself from sibling tools like add_node or launch_editor, which are about different operations. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool versus alternatives. However, given its singular purpose and the lack of overlapping sibling getters, the usage is implied. There is no guidance on prerequisites or conditions, which could be added but is not critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve metadata about a Godot project
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Path to the Godot project directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'retrieve' implies a read-only operation, but the description does not explicitly state that it has no side effects or what permissions it requires. Since there are no annotations, the description carries the full burden and only partially covers the 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 a single concise sentence with no unnecessary words or repetition. It is well-structured and 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?
There is no output schema or description of what metadata is returned. The term 'metadata' is vague and does not specify whether it returns project configuration, version info, or something else, leaving the agent without enough context to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'projectPath' is described as 'Path to the Godot project directory', which is clear and covers the basic meaning. However, since the schema already provides this description, the tool description adds no additional detail about path format, required existence, 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 action 'retrieve' and the target 'metadata about a Godot project', making the tool's basic purpose easy to understand. However, it does not explicitly differentiate itself from sibling tools like get_godot_version or get_uid, which could also be considered metadata retrieval.
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 gives no guidance on when to use this tool versus the sibling tools. There is no mention of scenarios, prerequisites, or exclusions, so an agent has little context for choosing this over more specific retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the UID for a specific file in a Godot project (for Godot 4.4+)
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Path to the Godot project directory | |
| filePath | Yes | Path to the file (relative to project) for which to get the UID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, permissions required, or side effects. The tool could be assumed to be a simple getter, but this is not explicitly stated, leaving the behavior opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It efficiently conveys the tool's purpose and relevant version constraint.
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?
The tool is simple, and the description covers its basic purpose. However, it does not mention the return format, potential errors, or edge cases. While acceptable for a straightforward getter, it leaves some context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with clear descriptions, achieving 100% coverage. The tool description itself adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: getting the UID for a specific file in a Godot project. It also specifies the Godot version constraint (4.4+), making it unambiguous and distinct from sibling tools like update_project_uids.
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 lacks explicit guidance on when to use this tool versus alternatives. While the purpose is obvious, there is no mention of scenarios where this tool is preferred or where other tools (e.g., update_project_uids) should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch Godot editor for a specific project
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Path to the Godot project directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without any side effects, blocking behavior, or requirements (e.g., whether it opens a new window, requires an existing project, or modifies any files). This is insufficient for an agent to predict the tool's impact.
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 extremely conciseāa single sentence with no filler. However, it is under-specified rather than efficiently comprehensive. It lacks necessary details about behavior and usage, so while it is short, it doesn't earn its place by providing full value. A 3 reflects the balance between brevity and adequacy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description should provide enough context to call it correctly. It states the action but omits critical information such as whether the editor must be installed, whether the path must point to a valid project, and whether the call is blocking or returns immediately. This is incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter projectPath is fully documented in the schema. The description adds no additional semantics beyond the action, but the schema already explains the parameter. Baseline 3 is appropriate; the description doesn't harm, but it also doesn't enhance the parameter meaning.
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 (launch) and the resource (Godot editor) for a specific project. It distinguishes implicitly from siblings like run_project (which runs the project rather than opening the editor) and list_projects (which lists projects). However, it doesn't explicitly name the alternative or the selection criteria, so it's clear but not maximally differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as run_project. The description does not mention any prerequisites, use cases, or conditions that would lead an agent to select this tool over its siblings. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Godot projects in a directory
| Name | Required | Description | Default |
|---|---|---|---|
| directory | Yes | Directory to search for Godot projects | |
| recursive | No | Whether to search recursively (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates the basic listing action and adds no details about whether the operation is read-only, how Godot projects are identified, what the return format is, or how the recursive parameter behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant wording. Every word earns its place, and the core action and scope are immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with two parameters, the description is minimally adequate: the schema covers parameter meanings. However, with no output schema and no annotations, the description does not clarify what the returned list contains (e.g., project names, paths) or whether directories without project.godot are ignored, leaving some contextual gaps.
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%, and both parameters are already documented clearly in the schema ('Directory to search for Godot projects' and 'Whether to search recursively (default: false)'). The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('Godot projects') and a scoping location ('in a directory'). It is unambiguous and easily distinguished from sibling tools like get_project_info or run_project, which target a single project or perform an action.
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 phrase 'in a directory' implies the tool is for project discovery in a filesystem location, which gives some usage context. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention any exclusions or follow-up tools like get_project_info for inspecting a specific project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a sprite/texture into a Sprite2D node in a Godot scene
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Path to the Godot project directory | |
| scenePath | Yes | Path to the scene file (relative to project) | |
| nodePath | Yes | Path to the Sprite2D node in the scene | |
| texturePath | Yes | Path to the texture file (relative to project) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only indicates the basic operation but fails to disclose side effects (e.g., overwriting existing texture), error handling, or required node type verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words, efficiently conveying the core function.
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?
Lacks essential context such as expected behavior on failure (e.g., invalid paths, wrong node type), return values, or prerequisites like open project, making it incomplete for an agent to use robustly.
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?
All parameters are described in the schema (100% coverage), so the description adds no extra parameter-level meaning; baseline score of 3 applies.
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 ('Load') and the target resource ('sprite/texture into a Sprite2D node'), distinguishing it from sibling tools that handle general node operations or scene creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like add_node or edit_node, nor any prerequisites or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a node from an existing scene in a Godot project
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Path to the Godot project directory | |
| scenePath | Yes | Path to the scene file (relative to project) | |
| nodePath | Yes | Path to the node to remove (e.g., "Player", "UI/HealthBar") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether the removal is reversible, if the scene is auto-saved, or what happens if the node doesn't 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?
Single sentence with no fluff. Every word contributes to the purpose.
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 simplicity of the parameters and lack of output schema, the description is largely adequate. However, it could mention that the removal is permanent or whether it requires the scene to be saved first.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove'), the resource ('node from an existing scene'), and the context ('in a Godot project'). It distinguishes well from sibling tools like add_node or edit_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites, context, or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the Godot project and capture output
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Path to the Godot project directory | |
| scene | No | Optional: Specific scene to run |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral burden. It mentions 'capture output' but does not disclose side effects, blocking behavior, or whether the process continues running after invocation. The name 'run_project' implies execution but lacks specifics about what the user will observe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant information. It efficiently conveys the primary purpose without unnecessary 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?
No output schema is present, and the description does not clarify what 'capture output' meansāwhether it returns logs, exit codes, or streams. It also omits whether the tool blocks until the project closes or returns immediately. This leaves the agent uncertain about the expected behavior and return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage for both parameters with their descriptions. The tool description adds no extra semantic detail beyond the schema, so it neither enhances nor detracts from the schema's clarity. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Run') and object ('the Godot project'), plus a specific outcome ('capture output'). It is distinct from siblings like `launch_editor` or `stop_project`, though the phrase 'capture output' could be more detailed about what output is captured.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention prerequisites, like whether the project must exist or if the Godot editor must be closed, nor does it explain the effect of the optional 'scene' parameter in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a scene, optionally as a new variant
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Path to the Godot project directory | |
| scenePath | Yes | Path to the scene file (relative to project) | |
| newPath | No | Optional: New path to save as variant (relative to project) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose destructive potential, error handling, or side effects of saving. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy. Could be expanded for clarity but remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description lacks details on return values, success/failure conditions, or prerequisite state. For a save operation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds context for 'newPath' with 'variant', but does not improve understanding of other parameters.
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 saves a scene, with an optional variant. However, it does not distinguish from sibling tools like 'create_scene', which has similar scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs 'create_scene' or 'edit_node'. The optional variant is hinted but no explicit when/when-not criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the currently running Godot project
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action 'Stop' without explaining side effects (e.g., unsaved changes, process termination), error conditions (no running project), or whether it's reversible. For a destructive action, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that directly states the action and target. It's front-loaded with the verb and resource, with zero redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description adequately covers the core action. However, it doesn't mention what happens if no project is running or whether the tool returns any feedback, which would be useful but not critical for a stop action. The description is mostly complete given its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage). The description doesn't need to explain any parameters, and the baseline for 0-parameter tools is 4. It adds no extra parameter meaning because none exist.
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 states a specific action ('Stop') and a specific resource ('the currently running Godot project'). It clearly distinguishes from siblings like run_project (which starts) and get_debug_output (which retrieves output), so an agent can easily infer its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to stop a running project) but does not explicitly mention when not to use it or alternatives. Since it's a simple action with no parameters, the context is clear, but it doesn't provide explicit routing like naming run_project as the counterpart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update UID references in a Godot project by resaving resources (for Godot 4.4+)
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Path to the Godot project directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It mentions resaving resources, implying file modifications, but does not disclose potential side effects, reversibility, permissions needed, or whether it may alter many files. The version requirement is useful but insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the primary action and resource. It avoids extraneous detail and is appropriately sized for a simple tool.
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 one parameter, no output schema, and no annotations, the description is minimally adequate. It explains what it does and the version constraint, but omits guidance on when to use it and potential side effects. Given the simplicity, it is not severely incomplete but lacks context an agent might need to decide correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter has 100% schema coverage with a clear description ('Path to the Godot project directory'). The tool description adds no additional meaning beyond the schema, so it meets the baseline for a fully documented parameter but does not enhance understanding further.
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 states a specific verb ('Update'), a resource ('UID references in a Godot project'), and a method ('by resaving resources'). It clearly identifies the tool's function and includes a version constraint (Godot 4.4+), distinguishing it from sibling tools like get_uid that retrieve UIDs.
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 no explicit guidance on when to use this tool versus alternatives. It only mentions a version requirement, but does not explain scenarios (e.g., after moving or renaming files) or when to prefer other project tools. The intended use is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_nodecreate_sceneedit_nodeexport_mesh_libraryget_debug_outputget_godot_versionget_project_infoget_uidlaunch_editorlist_projectsload_spriteremove_noderun_projectsave_scenestop_projectupdate_project_uidsScored across 16 tools
Each tool targets a specific action and resource: scene creation, node manipulation, project execution, debugging, etc. There is no ambiguity or overlap between tools like add_node, edit_node, remove_node, or create_scene, save_scene.
All tool names follow a consistent verb_noun pattern (e.g., add_node, create_scene, get_godot_version) using snake_case. Verbs are uniform and descriptive, making the set predictable.
With 16 tools, the set is slightly above the typical 3-15 range but still well-scoped for Godot project management and scene editing. Each tool serves a distinct purpose, though a few could be merged (e.g., get_godot_version and get_project_info).
The set covers core workflows like scene creation, node editing, and project execution, but lacks essential operations like opening/listening scenes, managing resources (scripts, textures), or editing project settings. Gaps exist for a full development lifecycle.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yoā¦
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal Eā¦
A Model Context Protocol server for Wix AI tools
Nifty's MCP server ā exposes tasks, projects, messages, and files as tools for AI agents.
