Provides tools for managing Godot projects, scenes, nodes, and editor operations, enabling AI assistants to interact directly with the Godot game engine.
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 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 bears full burden for behavioral disclosure. It only says 'Get the current debug output and errors,' implying a read operation, but fails to disclose whether the output is cleared after retrieval, permissions needed, or any 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 single sentence and not verbose, but it lacks structure and fails to provide crucial details beyond the basic verb+resource. It is concise but under-specified for an adequate 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?
Given no output schema, the description should explain what the tool returns. It only vaguely mentions 'current debug output and errors' without indicating format, structure, or scope. The tool is simple, but the description does not fully compensate for the missing 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?
The tool has zero parameters, so the baseline is 4. The description adds the meaning that the tool returns 'debug output and errors', but this is already covered by the purpose. No additional parameter explanation is needed.
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 retrieves 'debug output and errors', which is a specific verb+resource. It distinguishes from sibling tools like add_node or edit_node, as none of them perform this debug retrieval 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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or context. There is no mention of when not to use it, leaving the agent to infer usage.
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. The description does not add behavioral context beyond the name. However, the tool is trivial (read-only, no side effects), so this is adequate.
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 wasted words. It is efficiently front-loaded.
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 no parameters, no output schema, and performs a simple retrieval, the description fully covers the needed context.
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 no parameters, so schema coverage is effectively 100%. The description does not need to add parameter details. Baseline 4 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 'Get the installed Godot version' uses a specific verb ('Get') and resource ('installed Godot version'), clearly stating the tool's purpose. It distinguishes this from sibling tools like add_node or create_scene, which 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?
No explicit guidance on when to use this tool versus alternatives is provided. However, the purpose is straightforward and no sibling tool serves the same function, so the implied usage is clear.
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?
With no annotations, the description must disclose behavioral traits. It merely says 'retrieve metadata', implying read-only behavior, but does not specify if it is safe, idempotent, or what specific metadata is returned.
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 very concise (6 words) and front-loaded, but it is under-specified. Given the context of no annotations and many sibling tools, more details are needed.
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 has low complexity (1 param, no output schema, no annotations), but the description lacks contextual completeness. It does not explain what metadata is returned, how it differs from similar tools, or any 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 covers 100% of parameters with a description for 'projectPath'. The description does not add new meaning beyond the schema, which is acceptable for baseline scoring.
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 resource ('metadata about a Godot project'). However, it does not differentiate from sibling tools like 'list_projects', which might also retrieve project metadata.
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 usage guidelines are provided. The description does not indicate when to use this tool over alternatives such as 'list_projects' or 'get_godot_version', nor does it mention any prerequisites or exclusions.
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 provided, so description carries full burden. It does not disclose whether the operation is read-only, side-effect-free, or requires permissions. Only mentions Godot version requirement.
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 that is front-loaded and to the point, with zero 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 tool simplicity (2 params, no output schema), description is mostly complete. It specifies the Godot version. Lacks info on return value format or behavior, but core function is clear.
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?
Input schema has 100% description coverage for both parameters, so baseline is 3. Description does not add extra meaning beyond schema; it merely restates the purpose.
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 verb 'Get', resource 'UID for a specific file', and context 'in a Godot project (for Godot 4.4+)', distinguishing it 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?
No guidance on when to use this tool versus alternatives such as 'get_project_info' or 'update_project_uids'. The description lacks context about prerequisites or typical use cases.
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?
No annotations provided; description only says 'Launch', lacking details on whether it blocks, requires specific conditions, or has side effects. Minimal behavioral disclosure.
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 unnecessary words. Highly 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 simple tool with one required parameter and no output schema, the description is adequate. It could optionally mention that launching the editor opens a GUI window.
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 a clear parameter description. The tool description adds no extra meaning beyond 'path to the Godot project directory'.
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 verb 'Launch', resource 'Godot editor', and scope 'for a specific project'. It distinguishes from siblings like run_project which runs a project, not the editor.
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 explicit guidance on when to use or not use this tool versus alternatives (e.g., run_project). Usage is implied but not clarified.
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?
No annotations provided. Description does not disclose behavioral traits such as read-only nature, permissions needed, or effects on the file system.
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, highly concise with no redundant information. Front-loaded with essential 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?
For a simple list tool, the description is adequate but does not clarify output format or the definition of a Godot project. No output schema 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 coverage is 100% with descriptions for both parameters. Description does not add significant meaning beyond the schema, so baseline score 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 tool lists Godot projects in a directory, with a specific verb and resource. It distinguishes from siblings which focus on editing, launching, or other actions.
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 specify prerequisites, limitations, 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.
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?
Missing annotations place the full burden on the description. 'Capture output' is vagueāit does not explain whether output is returned as a string, streamed, or logged. There is no mention of blocking behavior, error handling, or side effects like GUI windows appearing.
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 superfluous words. It is optimally concise for the information conveyed.
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 likely returns important output (captured console), but no output schema exists and the description omits return format or how to retrieve it. Given sibling 'get_debug_output,' the differentiation is unclear, and critical behavioral context is missing.
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 explains both parameters adequately. The description adds no extra context about parameter usage, defaults, or constraints, so it meets but does not exceed the baseline.
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 'Run the Godot project and capture output,' which specifies the action (run) and the resource (Godot project). However, it does not differentiate from sibling tools like 'launch_editor' or 'get_debug_output,' though the intent is generally clear.
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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives such as 'stop_project' or 'get_debug_output,' nor does it mention prerequisites like Godot installation or project validity.
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 must fully disclose behavior. It only states the action, omitting what happens if no project is running, error handling, or side effects. Minimal transparency.
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, clear sentence with no extraneous words. It is perfectly concise and well-structured.
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 is mostly complete. However, it fails to mention potential failure modes or prerequisites (e.g., is a project required to be running?), which would improve 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?
There are no parameters, and schema coverage is 100% trivially. The description does not need to explain parameters, and it adds no misleading information. Baseline for zero parameters is 4.
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 ('stop') and the target resource ('currently running Godot project'), leaving no ambiguity. It distinguishes from the sibling tool 'run_project'.
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 explicit guidance on when to use this tool versus alternatives, though the purpose is straightforward. Usage is implied but not elaborated.
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?
No annotations provided, so description carries full burden. Mentions resaving resources but does not disclose side effects (e.g., file modification, permissions, or whether the project must be closed). Lacks details on 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?
Single sentence, 12 words, front-loaded with action and resource. 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 simple single-parameter operation, the description is adequate but minimal. No output schema, no return value description, and no prerequisites mentioned. Could be more complete for a mutation 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?
Only parameter 'projectPath' is fully described in the input schema (100% coverage). The tool description adds no additional meaning beyond 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?
Clearly states the verb 'update', the resource 'UID references in a Godot project', and the method 'by resaving resources'. Specifies Godot version requirement. Distinct from sibling tools which focus on nodes and 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?
Implies usage for updating UID references, but no explicit guidance on when to use or when not to use. No alternatives mentioned.
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. Dates show when Glama detected each change.
v0.1.0add_nodecreate_sceneedit_nodeexport_mesh_libraryget_debug_outputget_godot_versionget_project_infoget_uidlaunch_editorlist_projectsload_spriteremove_noderun_projectsave_scenestop_projectupdate_project_uidsEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bradypp/godot-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
