The godot-mcp server is a comprehensive MCP server that gives AI assistants full control over the Godot game engine, exposing 157 operations across 19 tools spanning project management, scene editing, runtime interaction, and more.
Core & Project Management
Launch the editor, run/stop projects, capture debug output, get Godot version, list projects
Create new projects (including .NET/C#), manage project settings, autoloads, input maps, export presets, plugins, layer definitions, and main scene
Scene & File System
Create, load, read, modify, and save scenes; add/remove/reparent nodes; attach scripts; manage scene signals
Read/write/delete/rename files, create directories, manage resources (.tres/.res), shaders, themes, and translations
GDScript Validation
Validate single or batch GDScript files for syntax/type errors headlessly (no running game needed)
Runtime Game Control
Execute arbitrary GDScript code (game_eval), pause/unpause, wait frames, take screenshots
Monitor performance (FPS, memory, draw calls), capture errors/logs, serialize/deserialize node tree state
Node Manipulation
Get/set properties, call methods, introspect nodes, instantiate/remove/reparent nodes
Spawn nodes, manage groups, create timers, attach/detach scripts, set process modes
Input Simulation
Simulate mouse clicks, keyboard holds/releases, scrolling, drag, gamepad, and touch/gesture events
Query input state and manage runtime InputMap actions
Signal System
Connect, disconnect, emit, list, and await signals on nodes at runtime
Animation & Tweening
Control AnimationPlayer (play/stop/pause/seek/queue), tween properties with easing
Create animations with tracks/keyframes, control AnimationTree state machines, manage skeleton bone poses and SkeletonIK3D
Camera & Viewport
Query/move 2D/3D cameras, configure DOF and exposure, create/configure SubViewports
Physics & Navigation
Perform 2D/3D raycasts, add collision shapes, configure physics body properties (mass, velocity, damping, friction)
Create physics joints, query area/shape intersections, bake and query navigation paths
2D Rendering
Manage CanvasLayers, draw 2D geometry (lines, rects, circles, polygons, text)
Configure 2D lights/occluders, parallax backgrounds, Line2D/Polygon2D, Path2D, and TileMapLayer cells
3D Rendering & Geometry
CSG nodes with boolean ops, MultiMeshInstance3D, procedural meshes, 3D lights, MeshInstance3D, GridMaps
ReflectionProbes, Decals, FogVolumes, VoxelGI, LightmapGI, Path3D, Sky/environment settings
Set shader parameters, configure GPU particles, draw debug geometry, manage render settings (MSAA, FXAA, TAA)
Audio
Get bus layout, play/stop/pause audio streams, set bus volume/mute/solo
Add/remove/configure audio bus effects, manage spatial audio properties
UI Controls
Apply theme overrides, manage LineEdit/TextEdit/RichTextLabel text, show/hide popups
Interact with Tree, ItemList, OptionButton, TabContainer, PopupMenu, MenuBar, range widgets (Slider, SpinBox, ProgressBar, ColorPicker)
Networking
HTTP GET/POST/PUT/DELETE requests, WebSocket client connections, ENet multiplayer server/client setup, and RPC method calls
System & Window
Get/set window size, fullscreen, title, position; query OS/screen/memory info
Manage Engine time scale, world settings (gravity, physics FPS), locale, and video settings
Provides full control over the Godot game engine, enabling AI assistants to manage projects, scenes, nodes, scripts, animation, audio, physics, input, and more.
Allows creating and managing .NET/C# Godot projects and scripts, including scaffolding and generating C# scripts.
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 Camera2D node 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 that gives AI assistants full control over the Godot game engine. It exposes 162 operations spanning networking, 3D/2D rendering, UI controls, audio effects, animation trees, file I/O, runtime code execution, property inspection, scene manipulation, signal management, physics, project creation, project-local skills, and more.
This project is built upon and extends godot-mcp by Solomon Elias (Coding-Solo). The original project provided the foundational architecture including the TypeScript MCP server, headless GDScript operations system, and TCP-based runtime interaction server. Thank you for making this possible with your excellent open-source work!
Related MCP server: Godot MCP
The original godot-mcp provided 20 tools for basic project management and scene creation. This fork extends that capability set to 162 operations, now exposed through a compact public tool tree:
validate_script autoload resolution - Script validation now compiles the target through a SceneTree at _initialize() (after project autoloads are registered) instead of --check-only at _init(). References to autoload singletons no longer produce false Identifier not found errors, while real syntax/type errors are still caught. Verified building a full game whose scripts reference several autoloads.
manage_input_map event merging - Adding a second key to an existing input action now merges it into that action's events array (with physical_keycode de-duplication) instead of writing a duplicate actionname= line, which previously left project.godot malformed and silently dropped earlier bindings.
.NET / C# support - Scaffold C# projects and generate C# scripts (create_project with dotnet: true, create_csharp_script); the .csproj SDK version is matched to your installed Godot.
GDScript diagnostics - Validate scripts for syntax and type errors without running the game (validate_script, and validate_scripts for all git-changed or project-wide files).
Correctness and robustness fixes across the headless scene operations and the runtime interaction server (resource-typed properties now persist, reparenting works, runtime commands are correlated by request id, and the operations survive projects with warnings-as-errors). Requires Godot 4.4 or later; tested and working with the latest Godot 4.7.
game_eval - Execute arbitrary GDScript code in the running game with return values
Full await support for async GDScript code
Works even when the game is paused (PROCESS_MODE_ALWAYS)
game_get_property / game_set_property - Read/write any property on any node by path
game_call_method - Call any method on any node with arguments
game_get_node_info - Full node introspection: properties, signals, methods, children
game_instantiate_scene - Dynamically add scenes to the running game
game_remove_node - Remove nodes at runtime
game_change_scene - Switch scenes at runtime
game_reparent_node - Move nodes between parents
game_connect_signal - Wire up signal connections at runtime
game_disconnect_signal - Remove signal connections
game_emit_signal - Emit signals with arguments
game_play_animation - Control AnimationPlayer (play, stop, pause, list)
game_tween_property - Smooth property animation with configurable easing
game_pause - Pause/unpause the game
game_performance - FPS, frame time, memory, object counts, draw calls
game_wait - Wait N frames (timing-sensitive operations)
game_get_nodes_in_group - Query nodes by group
game_find_nodes_by_class - Find all nodes of a specific class
read_scene - Parse any .tscn file and get full node tree with properties as JSON
modify_scene_node - Change node properties in scene files
remove_scene_node - Remove nodes from scene files
attach_script - Attach GDScript files to nodes in scenes
create_resource - Create .tres resource files (materials, themes, etc.)
read_project_settings - Parse project.godot as structured JSON
modify_project_settings - Change project settings programmatically
list_project_files - List and filter project files by extension
read_file / write_file / delete_file - Full file system access within Godot projects
create_directory - Create directory structures for scripts, scenes, assets
game_get_errors - Get new push_error/push_warning messages since last call
game_get_logs - Get new print output from the running game since last call
game_key_hold / game_key_release - Hold keys down for movement testing (WASD etc.)
game_scroll - Mouse scroll wheel events
game_mouse_drag - Drag between two points over multiple frames
game_gamepad - Gamepad button and axis input events
create_project - Create a new Godot project from scratch (pass dotnet: true to scaffold a .NET/C# project)
create_csharp_script - Create a C# script in a Godot .NET project
manage_autoloads - Add, remove, or list autoloads
manage_input_map - Add, remove, or list input actions and key bindings
manage_export_presets - Create or modify export preset configuration
create_project with dotnet: true - Scaffold a Godot .NET project (.csproj with Godot.NET.Sdk matched to your Godot version, plus the "C#" feature flag)
create_csharp_script - Generate an idiomatic C# script (partial class, correct _Ready/_Process override signatures); the class name is kept in sync with the file name so Godot can attach it
get_project_info reports an isDotnet field
validate_script - Check a single GDScript file for syntax and type errors headlessly, returning { valid, errors: [{ message, file, line }] }
validate_scripts - Batch-validate all git-changed .gd files (or the whole project), so an agent can verify its edits before running the game
game_get_camera / game_set_camera - Query and control 2D/3D cameras
game_raycast - Cast physics rays (auto-detects 2D vs 3D)
game_get_audio - Get audio bus layout and playing streams
game_spawn_node - Create any node type at runtime with properties
game_set_shader_param - Set shader parameters on materials
game_audio_play / game_audio_bus - Full audio playback and bus control
game_navigate_path - Query navigation paths (2D/3D)
game_tilemap - Get/set TileMapLayer cells
game_add_collision - Add collision shapes to physics bodies
game_environment - Configure post-processing (fog, glow, SSAO, tonemap, etc.)
game_manage_group - Add/remove nodes from groups
game_create_timer - Create timer nodes programmatically
game_set_particles - Configure GPUParticles2D/3D properties and process materials
game_create_animation - Create animations with value/method/bezier/audio tracks and keyframes
export_project - Trigger headless project export builds (CI/CD ready)
game_serialize_state - Save/load entire node tree state as JSON
game_physics_body - Configure mass, velocity, damping, friction, bounce
game_create_joint - Create physics joints (pin, spring, hinge, cone, slider)
game_bone_pose - Get/set skeleton bone poses for character animation
game_ui_theme - Apply color, constant, and font size theme overrides
game_viewport - Create/configure SubViewport nodes
game_debug_draw - Draw debug geometry (lines, spheres, boxes)
game_http_request - HTTP GET/POST/PUT/DELETE with headers and body
game_websocket - WebSocket client connect/disconnect/send messages
game_multiplayer - ENet multiplayer create server/client/disconnect
game_rpc - Call or configure RPC methods on nodes
game_script - Attach, detach, or get source of node scripts at runtime
game_window - Get/set window size, fullscreen, title, position
game_os_info - Get platform, locale, screen, adapter, memory info
game_time_scale - Get/set Engine.time_scale and timing info
game_process_mode - Set node process mode (pausable/always/disabled)
game_world_settings - Get/set gravity, physics FPS, and world settings
game_list_signals - List all signals on a node with connections
game_await_signal - Await a signal with timeout and return args
game_touch - Simulate touch press/release/drag and gestures
game_input_state - Query pressed keys, mouse position, connected pads
game_input_action - Manage runtime InputMap actions and strength
game_csg - Create/configure CSG nodes with boolean operations
game_multimesh - Create/configure MultiMeshInstance3D for instancing
game_procedural_mesh - Generate meshes via ArrayMesh from vertex data
game_light_3d - Create/configure 3D lights (directional/omni/spot)
game_mesh_instance - Create MeshInstance3D with primitive meshes
game_gridmap - GridMap set/get/clear cells and query used cells
game_3d_effects - Create ReflectionProbe, Decal, or FogVolume
game_gi - Create/configure VoxelGI or LightmapGI
game_path_3d - Create Path3D/Curve3D and manage curve points
game_sky - Create/configure Sky with procedural/physical sky
game_camera_attributes - Configure DOF, exposure, auto-exposure on camera
game_navigation_3d - Create/configure NavigationRegion3D and bake
game_physics_3d - Area3D queries and point/shape intersection tests
game_canvas - Create/configure CanvasLayer and CanvasModulate
game_canvas_draw - 2D drawing: line/rect/circle/polygon/text/clear
game_light_2d - Create/configure 2D lights and light occluders
game_parallax - Create/configure ParallaxBackground and layers
game_shape_2d - Line2D/Polygon2D point manipulation
game_path_2d - Path2D/Curve2D management and AnimatedSprite2D
game_physics_2d - Area2D queries and 2D point/shape intersections
game_animation_tree - AnimationTree state machine travel and params
game_animation_control - AnimationPlayer seek/queue/speed/info control
game_skeleton_ik - SkeletonIK3D start/stop/set target position
game_audio_effect - Add/remove/configure audio bus effects
game_audio_bus_layout - Create/remove/reorder audio buses and routing
game_audio_spatial - Configure AudioStreamPlayer3D spatial properties
rename_file - Rename or move a file within the project
manage_resource - Read or modify .tres/.res resource files
create_script - Create a GDScript file from a template
validate_script - Check a GDScript file for syntax/type errors headlessly (no run needed)
validate_scripts - Batch-check GDScript files: git-changed ones by default, or all
manage_scene_signals - List/add/remove signal connections in .tscn files
manage_layers - List/set named layer definitions in project
manage_plugins - List/enable/disable editor plugins
manage_shader - Create or read .gdshader files
manage_theme_resource - Create/read/modify Theme .tres resources
set_main_scene - Set the main scene in project.godot
manage_scene_structure - Rename/duplicate/move nodes within .tscn scenes
manage_translations - List/add/remove translation files in project
game_locale - Set/get locale and translate strings at runtime
game_ui_control - Set focus, anchors, tooltip, mouse filter on Control
game_ui_text - LineEdit/TextEdit/RichTextLabel text operations
game_ui_popup - Show/hide/popup for Popup/Dialog/Window nodes
game_ui_tree - Tree control: get/select/collapse/add/remove items
game_ui_item_list - ItemList/OptionButton: get/select/add/remove items
game_ui_tabs - TabContainer/TabBar: get/set current tab
game_ui_menu - PopupMenu/MenuBar: add/remove/get menu items
game_ui_range - ProgressBar/Slider/SpinBox/ColorPicker get/set
game_render_settings - Get/set MSAA, FXAA, TAA, scaling mode/scale
game_resource - Runtime resource load, save, or preload
Reentrancy guard - Prevents concurrent command processing during async operations
Full type conversion - Supports Vector2/3, Color, Quaternion, Basis, Transform2D/3D, AABB, Rect2, and all packed array types
Smart property type detection - Uses node's get_property_list() for automatic type conversion
PackedArray serialization - Proper JSON arrays instead of string fallback
Graceful error handling - Scene read fallback to raw .tscn text on missing dependencies
To avoid overwhelming MCP clients and agents with 162 top-level tools, the server now exposes 20 public tools:
godot_catalog lists the tree, or returns operation descriptions and input schemas for one requested domain.
Nineteen <domain>_manage tools accept { "op": "<operation>", "params": { ... } }.
Start by calling godot_catalog. Then call the matching branch. For example, the former top-level call:
validate_script({ "projectPath": "C:/games/my-game", "scriptPath": "res://player.gd" })becomes a call to validation_manage with these arguments:
{
"op": "validate_script",
"params": {
"projectPath": "C:/games/my-game",
"scriptPath": "res://player.gd"
}
}The branches are: core, project, scene, filesystem, validation, runtime, node, input, signal, animation, camera, physics, render_2d, render_3d, audio, ui, network, system, and skill. The 162 operation names below remain the compatibility reference; they are values of op, not MCP tool names.
Operation | Description |
| Launch Godot editor for a project |
| Run a Godot project and capture output |
| Stop the running project |
| Get console output and errors |
| Get installed Godot version |
| Find Godot projects in a directory |
| Get project metadata |
Operation | Description |
| Create a new scene with a root node type |
| Add a node to an existing scene |
| Load a texture into a Sprite2D node |
| Export a scene as MeshLibrary |
| Save a scene (with optional variant path) |
| Get UID for a file (Godot 4.4+) |
| Resave resources to update UIDs |
Operation | Description |
| Read full scene tree as JSON |
| Modify node properties in a scene file |
| Remove a node from a scene file |
| Attach a GDScript to a scene node |
| Create a .tres resource file |
Operation | Description |
| Parse project.godot as JSON |
| Change a project setting |
| List/filter project files |
Operation | Description |
| Capture a screenshot (base64 PNG) |
| Click at a position |
| Send key press or input action |
| Move the mouse |
Operation | Description |
| Get all visible UI elements |
| Get full scene tree structure |
| Detailed node introspection |
Operation | Description |
| Execute arbitrary GDScript with return values |
Operation | Description |
| Get any node property |
| Set any node property (auto type conversion) |
| Call any method on a node |
| Add a PackedScene to the running tree |
| Remove a node from the tree |
| Switch to a different scene |
| Move a node to a new parent |
Operation | Description |
| Connect a signal to a method |
| Disconnect a signal |
| Emit a signal with arguments |
| List all signals on a node with connections |
| Await a signal with timeout and return args |
Operation | Description |
| Control AnimationPlayer |
| Tween a property with easing |
Operation | Description |
| Pause/unpause the game |
| Get FPS, memory, draw calls |
| Wait N frames |
| Query nodes by group |
| Find nodes by class type |
Operation | Description |
| Read a text file from a Godot project |
| Create or overwrite a text file |
| Delete a file from a project |
| Create a directory inside a project |
Operation | Description |
| Get new errors/warnings since last call |
| Get new print output since last call |
Operation | Description |
| Hold a key down (no auto-release) |
| Release a held key |
| Mouse scroll wheel event |
| Drag between two points over N frames |
| Gamepad button or axis input |
| Simulate touch press/release/drag and gestures |
| Query pressed keys, mouse position, connected pads |
| Manage runtime InputMap actions and strength |
Operation | Description |
| Create a new Godot project (supports |
| Create a C# script in a Godot .NET project |
| Add, remove, or list autoloads |
| Add, remove, or list input actions |
| Create or modify export presets |
Operation | Description |
| Get active camera position/rotation/zoom |
| Move or rotate the active camera |
| Cast a ray and return collision results |
| Get audio bus layout and playing streams |
| Create a new node of any type at runtime |
| Set a shader parameter on a node's material |
| Play, stop, or pause an AudioStreamPlayer node |
| Set volume, mute, or solo on an audio bus |
| Query a navigation path between two points |
| Get or set cells in a TileMapLayer node |
| Add a collision shape to a physics body node |
| Get or set environment and post-processing settings |
| Add or remove a node from a group, or list groups |
| Create a Timer node with configuration |
| Configure GPUParticles2D/3D node properties |
| Create an animation with tracks and keyframes |
| Save or load node tree state as JSON |
| Configure physics body properties (mass, velocity) |
| Create a physics joint between two bodies |
| Get or set bone poses on a Skeleton3D node |
| Apply theme overrides to a Control node |
| Create or configure a SubViewport node |
| Draw debug lines, spheres, or boxes in 3D |
Operation | Description |
| Export a Godot project using a preset |
Operation | Description |
| HTTP GET/POST/PUT/DELETE with headers and body |
| WebSocket client connect/disconnect/send messages |
| ENet multiplayer create server/client/disconnect |
| Call or configure RPC methods on nodes |
Operation | Description |
| Attach, detach, or get source of node scripts |
| Get/set window size, fullscreen, title, position |
| Get platform, locale, screen, adapter, memory info |
| Get/set Engine.time_scale and timing info |
| Set node process mode (pausable/always/disabled) |
| Get/set gravity, physics FPS, and world settings |
Operation | Description |
| Create/configure CSG nodes with boolean operations |
| Create/configure MultiMeshInstance3D for instancing |
| Generate meshes via ArrayMesh from vertex data |
| Create/configure 3D lights (directional/omni/spot) |
| Create MeshInstance3D with primitive meshes |
| GridMap set/get/clear cells and query used cells |
| Create ReflectionProbe, Decal, or FogVolume |
| Create/configure VoxelGI or LightmapGI |
| Create Path3D/Curve3D and manage curve points |
| Create/configure Sky with procedural/physical sky |
| Configure DOF, exposure, auto-exposure on camera |
| Create/configure NavigationRegion3D and bake |
| Area3D queries and point/shape intersection tests |
Operation | Description |
| Create/configure CanvasLayer and CanvasModulate |
| 2D drawing: line/rect/circle/polygon/text/clear |
| Create/configure 2D lights and light occluders |
| Create/configure ParallaxBackground and layers |
| Line2D/Polygon2D point manipulation |
| Path2D/Curve2D management and AnimatedSprite2D |
| Area2D queries and 2D point/shape intersections |
Operation | Description |
| AnimationTree state machine travel and params |
| AnimationPlayer seek/queue/speed/info control |
| SkeletonIK3D start/stop/set target position |
Operation | Description |
| Add/remove/configure audio bus effects |
| Create/remove/reorder audio buses and routing |
| Configure AudioStreamPlayer3D spatial properties |
Operation | Description |
| Rename or move a file within the project |
| Read or modify .tres/.res resource files |
| Create a GDScript file from a template |
| Check a GDScript file for syntax/type errors (headless) |
| Batch-check GDScript files (git-changed by default, or all) |
| List/add/remove signal connections in .tscn files |
| List/set named layer definitions in project |
| List/enable/disable editor plugins |
| Create or read .gdshader files |
| Create/read/modify Theme .tres resources |
| Set the main scene in project.godot |
| Rename/duplicate/move nodes within .tscn scenes |
| List/add/remove translation files in project |
| Set/get locale and translate strings at runtime |
Operation | Description |
| Set focus, anchors, tooltip, mouse filter on Control |
| LineEdit/TextEdit/RichTextLabel text operations |
| Show/hide/popup for Popup/Dialog/Window nodes |
| Tree control: get/select/collapse/add/remove items |
| ItemList/OptionButton: get/select/add/remove items |
| TabContainer/TabBar: get/set current tab |
| PopupMenu/MenuBar: add/remove/get menu items |
| ProgressBar/Slider/SpinBox/ColorPicker get/set |
Operation | Description |
| Get/set MSAA, FXAA, TAA, scaling mode/scale |
| Runtime resource load, save, or preload |
Operation | Description |
| List bundled skills and their CLI target paths |
| Install one bundled skill into a Godot project |
| Install all bundled skills into a Godot project |
| Show installed skill status for each CLI target |
| Remove one bundled skill from a Godot project |
Skill installation is project-scoped only. Claude Code reads .claude/skills/<skill>/, while Codex CLI and Antigravity CLI share .agents/skills/<skill>/. The bundled source is copied locally; the MCP server does not modify global CLI directories or download skills from the network.
Example:
{
"op": "install_all_skills",
"params": {
"projectPath": "C:/games/my-game",
"target": "all"
}
}Godot Engine 4.4 or later (the headless operations script and UID features require 4.4+); tested and working with the latest Godot 4.7
(Optional) .NET SDK 8.0+ and the Godot .NET (C#) build, only if you use create_project's dotnet: true flag or create_csharp_script
Node.js >= 18.0.0
An AI assistant that supports MCP (Claude Code, Cline, Cursor, etc.)
git clone https://github.com/XOVIET-GAME/godot-mcp.git
cd godot-mcp
npm install
npm run buildAdd to your Claude Code MCP settings:
{
"mcpServers": {
"godot": {
"command": "node",
"args": ["/absolute/path/to/godot-mcp/build/index.js"],
"env": {
"GODOT_PATH": "/path/to/godot",
"DEBUG": "true"
}
}
}
}Add to your Cline MCP settings (cline_mcp_settings.json):
{
"mcpServers": {
"godot": {
"command": "node",
"args": ["/absolute/path/to/godot-mcp/build/index.js"],
"disabled": false
}
}
}Create .cursor/mcp.json in your project:
{
"mcpServers": {
"godot": {
"command": "node",
"args": ["/absolute/path/to/godot-mcp/build/index.js"]
}
}
}To use the game_* runtime operations, your Godot project needs the MCP interaction server autoload. Copy build/scripts/mcp_interaction_server.gd to your project and register it as an autoload:
Copy build/scripts/mcp_interaction_server.gd to your project's scripts folder
In Godot: Project > Project Settings > Autoload
Add the script with the name McpInteractionServer
The server listens on 127.0.0.1:9090 and accepts JSON commands over TCP when the game is running.
Variable | Description |
| Path to the Godot executable (overrides auto-detection) |
| Set to |
| Optional. Restrict |
The server uses two communication channels:
Headless CLI - For operations that don't need a running game (scene reading, modification, resource creation). Runs Godot with --headless --script godot_operations.gd <operation> <json_params>.
TCP Socket - For runtime interaction with a running game. The mcp_interaction_server.gd autoload listens on port 9090 and processes JSON commands sent by the TypeScript MCP server.
Path | Description |
| MCP server, public tool tree, operation schemas, and handlers |
| Project-local Claude, Codex, and Antigravity skill installer |
| Pure utility functions (parameter mapping, validation, error helpers) |
| Headless GDScript operations runner |
| TCP interaction server autoload |
| Vitest test suite |
The project uses Vitest with 466 tests across 6 files:
File | Tests | What it covers |
| 31 | Parameter mappings, normalization, path validation, error responses, version detection |
| 172 | All 162 operations mapped once, 20 public tools, schemas valid |
| 225 | Game command arg transforms, required-param validation, headless op path checks, source structure |
| 20 | .NET feature flag, .csproj generation, C# script template generation, identifier validation |
| 12 | GDScript diagnostic parsing + git-changed file collection |
| 6 | Project-local install, status, idempotency, and removal |
npm test # run once
npm run test:watch # watch mode"Run my Godot project and check for errors"
"Eval this in my running game: return get_tree().current_scene.name"
"Get the player's position in the running game"
"Set the player's health to 100"
"Read the test_level.tscn scene and show me the node tree"
"Change the player's speed property in the player.tscn scene file"
"List all .gd files in my project"
"Connect the enemy's 'died' signal to the game manager's 'on_enemy_died' method"
"Tween the camera's position to (0, 10, -5) over 2 seconds with ease-out"
"Get performance metrics - what's my FPS and draw call count?"
"Pause the game and take a screenshot"
"Find all CharacterBody3D nodes in the scene"
"Create a new Godot project called 'MyGame' and write a player script"
"Create a new C# (.NET) Godot project and add a CharacterBody2D script"
"Validate player.gd for errors"
"Check all my changed GDScript files for syntax errors before I run the game"
"Hold down the W key for 2 seconds to test walking"
"Cast a ray from the player downward to check for ground"
"Get the camera position and move it to look at the player"
"Show me the latest error messages from the running game"This project is licensed under the MIT License - see the LICENSE file for details.
Original project: godot-mcp by Solomon Elias (Coding-Solo) - provided the foundational MCP server architecture, headless operations system, and TCP interaction framework
Extended by: Tugcan Topaloglu - extended to 162 operations covering networking, 3D/2D rendering, UI controls, audio effects, animation trees, file I/O, runtime code execution, node manipulation, signals, project creation, camera control, physics, project-local skills, and comprehensive type conversion
Godot animation operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the animation branch | |
| params | Yes | Parameters for the selected operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no information about side effects, permissions, or safety. For a tool that likely modifies game state (e.g., playing animations), 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?
The description is minimal, consisting of a short sentence and a reference. It is concise but lacks substance, so it does not effectively earn its place.
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 output schema and annotations, the description should provide more context. It fails to explain expected returns, usage constraints, or behavior, making it 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?
Schema coverage is 100% but the description adds no additional meaning to the parameters. The 'op' enum values and 'params' object are not explained beyond the schema, leaving ambiguity.
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 'Godot animation operations' which is broad and vague. It does not specify the exact actions (e.g., play, create) without relying on the enum. It distinguishes from sibling tools by focusing on animations, but the purpose is not sharp.
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 instruction 'Call godot_catalog for the operation tree' provides guidance on how to discover available operations. However, it does not specify when to use this tool vs alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot audio operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the audio branch | |
| params | Yes | Parameters for the selected operation |
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 (e.g., side effects, idempotency, permissions, rate limits). The description is entirely silent on what happens when the tool is used, leaving the agent with no understanding of potential impacts.
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 short (two sentences), which is concise but not necessarily effective. The first sentence is overly generic, and the second is a redirect. It lacks structure; it does not front-load the most critical information. Acceptable minimalism but not optimally designed for agent use.
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, the description should provide more context, such as what each operation does, return format, or side effects. The tool appears to be a dispatcher, but the description fails to explain how the 'params' object should be structured or what behavior 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?
Schema description coverage is 100%, so the baseline is 3. The description does not add any meaning beyond the schema; it merely repeats the domain. However, the schema itself clearly defines the 'op' enum and 'params' object, so the description is not harmful, just not additive.
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 only states 'Godot audio operations,' which is a vague domain label rather than a specific verb and resource. It does not clarify what the tool does (e.g., manage audio playback, buses, effects). The instruction to call godot_catalog for the operation tree provides a hint but does not define the tool's own 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 lacks guidance on when to use audio_manage versus sibling tools. It only says to call godot_catalog for the operation tree, which is procedural but does not specify the conditions under which this tool should be invoked instead of alternatives like animation_manage or node_manage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot camera operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the camera branch | |
| params | Yes | Parameters for the selected operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided and the description does not disclose behavioral traits such as whether operations are read-only, destructive, or require specific permissions. The nature of the tool (dispatching based on 'op' parameter) is not explained.
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 short but under-specified. It does not earn its place; a single sentence without substantive guidance is insufficient for tool selection.
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 4 enumerated operations and a generic 'params' object, the description is too minimal to enable correct usage. No output schema and no details on parameter structures or results.
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 both parameters are described adequately. The description adds no additional meaning beyond what is in the schema, so 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 'Godot camera operations' is vague and lacks a specific verb+resource. It does not distinguish from sibling tools like animation_manage or scene_manage, and offloads explanation to godot_catalog.
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 when-to-use or when-not-to-use guidance. The reference to godot_catalog implies it provides context, but the description itself gives no situational advice or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot core operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the core branch | |
| params | Yes | Parameters for the selected operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description bears full responsibility for behavioral disclosure. It omits any mention of side effects (e.g., whether operations are read-only or destructive), authentication needs, rate limits, or error behaviors. The schema's enum hints at possible actions, but the description itself adds no 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 extremely concise with two sentences, but the first sentence is overly generic and lacks substance. While brevity is positive, the content is insufficiently informative, making it less effective. The structure is simple but the trade-off between brevity and clarity is not well-balanced.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, enum of 7 operations, nested 'params' object) and the absence of an output schema, the description is severely lacking. It does not explain return values, error handling, or the structure of the 'params' object for each operation. Compared to the rich sibling tool set, this description leaves the agent underinformed.
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 both parameters are described in the schema: 'op' as an enum and 'params' as an object. The description adds no further meaning beyond the schema, which already defines the parameter purposes. A baseline score of 3 is appropriate since the schema carries the load without description enhancement.
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 'Godot core operations' is vague and does not specifically define what 'core' means in this context. It hints at functionality through the enum in the schema but lacks a clear verb-resource statement. The reference to godot_catalog adds some direction but does not clarify the tool's unique purpose among many sibling manage tools.
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 only guidance is 'Call godot_catalog for the operation tree,' which suggests where to find possible operations but does not explain when to use this tool versus alternatives like system_manage or runtime_manage. No conditions, prerequisites, or exclusions are provided, leaving the agent uncertain about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot filesystem operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the filesystem branch | |
| params | Yes | Parameters for the selected operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects (e.g., file creation/deletion can be destructive), permissions needed, or any limitations. The agent must infer behavior from operation names, which is risky.
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 (two sentences) but at the cost of clarity. Front-loading 'Godot filesystem operations' is clear but insufficient. The second sentence is a tangential reference, not essential for immediate tool use.
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 supports 10 distinct operations with free-form parameters and no output schema, the description is severely incomplete. It fails to explain operation-specific behavior, parameter requirements, or return values, making it nearly unusable without external documentation.
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% (both parameters described), but the description adds no extra meaning. The 'params' object is opaque with 'additionalProperties: true' and no guidance on structure per operation. The agent cannot determine required fields for each op without external knowledge.
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 'Godot filesystem operations' which is vague. It does not specify which operations are available (enum does but description lacks detail). The reference to godot_catalog hints at a broader system but doesn't clarify this tool's distinct role.
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 instruction 'Call godot_catalog for the operation tree' implies prerequisite guidance, but there is no mention of when to use filesystem_manage versus other sibling tools like animation_manage or audio_manage. The agent is left without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the Godot MCP operation tree before choosing a domain tool
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Optional domain to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond 'browse.' No annotations are provided, so the description carries full burden. It lacks information about read-only nature, side effects, permissions, or output format. For a read-like tool, minimal behavioral disclosure is acceptable, but it barely meets the threshold.
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 (11 words) with no superfluous content. Every word earns its place, clearly conveying purpose and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description adequately covers its purpose and usage guidance. It does not elaborate on the 'operation tree' concept, but the context is sufficiently complete for an exploration 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?
Schema coverage is 100% (the single enum parameter is described in the schema as 'Optional domain to inspect'). The description adds no additional meaning beyond this. Baseline 3 is appropriate since the tool is simple and the parameter is already well-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Browse the Godot MCP operation tree before choosing a domain tool.' It uses a specific verb ('Browse') and resource ('operation tree'), and distinguishes itself from sibling domain-specific tools (e.g., core_manage, scene_manage) by positioning itself as a preliminary exploration step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool 'before choosing a domain tool,' providing clear context for when to invoke it. It implicitly suggests that after browsing, one should select a specific sibling tool, though it does not explicitly describe when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot input operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the input branch | |
| params | Yes | Parameters for the selected operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but does not. It omits whether operations are mutating, require a running game, or are destructive. The enum values hint at actions like hold/release, but the description itself provides no 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 short but under-specified. The two sentences are not efficiently informative; the first is vague, and the second offloads detail to another tool. Not well-structured for quick understanding.
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 complexity (many enum operations, nested params, no output schema, no annotations), the description is severely incomplete. It lacks explanation of return values, error conditions, prerequisites, or how to construct the params object for each operation.
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% but the schema descriptions are minimal ('Operation in the input branch', 'Parameters for the selected operation'). The tool description adds no extra meaning, leaving the agent to infer param usage from the enum values or by calling godot_catalog.
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 'Godot input operations' is vague and essentially restates the tool name. It fails to specify what type of input management is performed (e.g., simulation, monitoring). Sibling tools like `input_manage` and `godot_catalog` are not differentiated.
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. alternatives. The instruction to call `godot_catalog` for the operation tree is a pointer but does not clarify usage context or exclude other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot network operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the network branch | |
| params | Yes | Parameters for the selected operation |
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 disclosing behavioral traits. It fails to mention side effects, permissions, rate limits, or what each operation does. This is a critical gap for a tool managing network operations.
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?
Two short sentences with no unnecessary words. The structure is clean, but the second sentence is essential for guidance. Could be slightly more concise by integrating the reference, but overall efficient.
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 2 parameters (including a dynamic object), no output schema, and no annotations, the description is highly incomplete. It does not explain operation behaviors, required params per op, or return values. The reference to godot_catalog partially compensates but leaves significant 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 coverage is 100% for both parameters. The description adds no additional meaning beyond the schema. Since baseline is 3 when coverage is high, this score reflects the lack of extra context for the dynamic 'params' object.
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 states it handles 'Godot network operations', which is a broad verb+resource. It does not distinguish from sibling tools like 'audio_manage' or 'scene_manage' beyond the network domain. The enum in the schema provides some specificity, but the description itself is vague.
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 advises calling 'godot_catalog for the operation tree', implying that catalog is needed for detailed operations. However, it offers no explicit guidance on when to use this tool versus siblings, no prerequisites, and no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot node operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the node branch | |
| params | Yes | Parameters for the selected operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It fails to mention any side effects, permissions, or safety aspects. The description is insufficient for understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks necessary detail. It is under-specified rather than concise, similar to the calibration low example 'Process'.
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 15 possible operations and a generic params object, but the description provides no details about operations, parameters, or outputs. It defers entirely to godot_catalog, making it highly 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?
Both parameters are described in the input schema (100% coverage). The description adds no additional semantic value beyond the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Godot node operations' is vague and does not specify the exact functionality. It does not distinguish from sibling tools like scene_manage or runtime_manage. The instruction to call godot_catalog undermines its own clarity.
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 only instruction is to consult godot_catalog, which is a prerequisite but not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot physics operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the physics branch | |
| params | Yes | Parameters for the selected operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description offers no behavioral details: no mention of side effects, error handling, required permissions, or output format. The tool is effectively a black box beyond the schema.
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 short (2 sentences) but this brevity sacrifices essential information. It is concise but not appropriately sized for the tool's complexity, lacking necessary 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?
Given the tool dispatches 8 distinct physics operations with an open-ended params object, the description is severely incomplete. No information about operation semantics, required parameters per op, or return values is provided. The schema alone is insufficient.
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% (both op and params are described), so the baseline is 3. The description adds no additional meaning to the parameters, but the schema already enumerates valid op values and defines params as an object.
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 states 'Godot physics operations' which is vague and does not specify a concrete action. It reads as a category rather than a specific verb+resource, and fails to distinguish from sibling tools like animation_manage.
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 only guidance is to call godot_catalog for the operation tree, which implies the tool is a dispatcher. No explicit when-to-use, when-not-to-use, or alternatives are provided, 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.
Godot project operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the project branch | |
| params | Yes | Parameters for the selected operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It does not disclose behavioral traits such as whether operations are destructive, require permissions, or have side effects. The 'params' field allows arbitrary additional properties, which is a notable behavior not mentioned.
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: two sentences front-loading the tool's domain and providing a critical cross-reference. Every sentence is purposeful, with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (proxy for many operations via generic params), the description adequately directs to godot_catalog. However, it omits details about return values, side effects, and behavior across operations. The lack of an output schema compounds this gap, making the tool incomplete for an agent without additional 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?
Schema description coverage is 100%, with both 'op' (enum) and 'params' (generic object) described in the schema. The description adds no parameter-level detail, instead deferring to godot_catalog. This meets the baseline for high coverage but fails to enrich semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Godot project operations,' which identifies the domain but is vague. It does not list specific operations, leaving the purpose broad. The input schema enumerates operations, but the description relies on that rather than clarifying the tool's role relative to siblings like scene_manage or node_manage.
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 directs the agent to 'Call godot_catalog for the operation tree,' providing a cross-reference for detailed usage. However, it offers no guidance on when to choose project_manage over sibling tools or what prerequisites exist. The guidance is partial but useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot render_2d operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the render_2d branch | |
| params | Yes | Parameters for the selected operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and the description discloses no behavioral traits. Does not indicate whether operations are read-only, destructive, or require authentication.
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 concise with one sentence, but it sacrifices informativeness for brevity. It is not front-loaded with critical 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?
Given the tool's complexity (multiple operations, dynamic params, no output schema), the description is severely incomplete. It lacks usage context, behavior, and parameter details, forcing reliance on another 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?
Schema coverage is 100% but the description adds no meaning beyond the schema. The op parameter enum lists values but no explanation of each. The params object is free-form with no description, leaving the agent without guidance on its structure.
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 only says 'Godot render_2d operations', which is a tautology with the name. Does not specify what the tool does beyond being a manager. The instruction to call godot_catalog for the operation tree suggests the actual purpose is unclear.
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 render_3d_manage or other sibling tools. Only advises to call godot_catalog for details, which is indirect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot render_3d operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the render_3d branch | |
| params | Yes | Parameters for the selected operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral insights. The tool likely performs mutations given the 'manage' suffix, but this is not stated. There is no disclosure of destructive actions, authentication needs, rate limits, or side effects. The description fails to add any transparency beyond the name.
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 short (one sentence), which is concise, but it lacks necessary detail. Every word is earned, but the content is insufficient for understanding the tool. It is not overly verbose, but under-specified.
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 complexity of the tool (16 operations in an enum, nested params object, no output schema), the description is severely incomplete. It does not explain any operation, parameter usage, or return values. The reference to godot_catalog is helpful but does not compensate for the lack of essential information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a basic description in the schema. The tool description adds no additional meaning beyond the schema, but per guidelines, baseline is 3 for high coverage. No extra context is provided, but the schema itself is sufficient.
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 'Godot render_3d operations' is essentially a tautology of the tool name and provides no specific verb or resource. It does not clarify what actions the tool performs, just that it deals with 3D rendering operations. It vaguely distinguishes from sibling tools like render_2d_manage by mentioning '3d', but lacks specificity.
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 provide guidance on when to use this tool versus alternatives. The only additional clue is 'Call godot_catalog for the operation tree,' which implies a relationship but does not explain usage context or exclusions. There is no mention of prerequisites or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot runtime operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the runtime branch | |
| params | Yes | Parameters for the selected operation |
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 side effects, required permissions, or rate limits. The tool appears to invoke various runtime operations, but no details are given.
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 short (one sentence) but lacks essential information. It is concise but under-specifies, making it barely adequate.
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 complexity of a tool with 14 sub-operations and a nested params object, the description is severely incomplete. No guidance is provided on parameter structures for each operation, making it hard for an agent to use 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?
Schema coverage is 100%, so the schema already documents the parameters (op enum and params object). The description adds no extra meaning beyond what the schema provides, earning a baseline 3.
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 'Godot runtime operations' but lacks a specific verb or resource action. It redirects to godot_catalog, making the tool's purpose unclear.
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 siblings. The only hint is 'Call godot_catalog for the operation tree,' which implies it is a dispatcher but doesn't clarify usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot scene operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the scene branch | |
| params | Yes | Parameters for the selected operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description lacks any information about behavioral traits such as side effects, destructive actions, authorization requirements, or return behavior. This is a critical gap for a tool managing scene operations.
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 too short (two sentences) to be useful. The first sentence is too generic, and the second redirects to another tool. It sacrifices completeness for brevity, making it ineffective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 enum operations, nested params) and the absence of annotations and output schema, the description is severely incomplete. It fails to explain any operation details, parameter usage, or expected results.
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 baseline is 3. The description does not add meaning beyond the schema's parameter descriptions ('Operation in the scene branch' and 'Parameters for the selected operation').
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 'Godot scene operations' is vague and does not specify what the tool does. It does not differentiate from sibling tools like node_manage or animation_manage.
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 instructs to 'call godot_catalog for the operation tree' but provides no guidance on when to use this tool vs alternatives such as node_manage or animation_manage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot signal operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the signal branch | |
| params | Yes | Parameters for the selected operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits are disclosed. The description does not mention side effects, permissions, or whether operations are read-only or destructive. With no annotations, the description carries the full burden but provides zero 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 very short (two sentences) and front-loaded, but it sacrifices substance for brevity. While concise, it omits critical information needed for correct tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's polymorphic nature (five sub-operations) and no output schema, the description is severely incomplete. It fails to explain any operation details, expected parameters, or return values, leaving the agent to guess.
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?
Even though schema coverage is 100%, the description adds no extra meaning beyond the schema. The parameter descriptions are minimal and generic (e.g., 'Operation in the signal branch'), and the tool description does not clarify what parameters should be used for each operation.
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 only states 'Godot signal operations', which is a broad category without specifying the action or resource. It fails to distinguish from sibling tools like node_manage or scene_manage. The reference to godot_catalog implies it is a dispatcher but does not clarify 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?
No explicit guidance on when to use this tool versus alternatives. The only hint is 'Call godot_catalog for the operation tree', which is indirect and does not provide clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot system operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the system branch | |
| params | Yes | Parameters for the selected operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as mutability, side effects, or permissions. The op enum hints at sub-operations, but the description adds no behavioral context beyond what the schema already provides.
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 short (two sentences) but under-specified. It does not front-load important information and contains a redirect instead of substantive content. Could be more effective if it provided a concrete 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 no output schema and a nested params object, the description is incomplete. It does not explain what the tool returns, how to construct 'params', or the behavior of each op value. Relies entirely on sibling tool and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any meaning beyond the schema's descriptions of 'op' and 'params'. It fails to elaborate on parameter usage, constraints, or format.
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 'Godot system operations' is vague and does not specify what the tool actually does. It fails to distinguish this tool from siblings like 'core_manage' or 'scene_manage'. No verb or specific resource is indicated.
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 using godot_catalog to discover available operations, but provides no explicit guidance on when to use this tool versus alternatives. No context or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot ui operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the ui branch | |
| params | Yes | Parameters for the selected operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It merely states 'Godot ui operations' without any details on side effects, permissions, rate limits, or whether operations are destructive. This is insufficient for an AI agent to understand 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 very short (two sentences) and front-loaded, but the content is minimal. While it is not verbose, it sacrifices completeness for brevity. Every sentence is necessary, but more detail would be beneficial.
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?
This is a dispatcher tool with 9 enum operations and a dynamic params object. Without an output schema, the description should provide more context about what each operation does or how to use params. The lack of behavioral details and parameter semantics makes it incomplete for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters having descriptions. The tool description adds no additional semantics about the parameters beyond what the schema already provides. 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 'Godot ui operations' which identifies the resource, but the verb is implicit. It distinguishes from siblings by the UI domain, but does not specify exactly what the tool does beyond that. The instruction to call godot_catalog for the operation tree provides context but the purpose remains vague.
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 a hint about workflow: 'Call godot_catalog for the operation tree' implies that this tool is for executing UI operations after looking them up. However, it lacks explicit guidance on when to use this tool versus alternatives, and no exclusion criteria are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Godot validation operations. Call godot_catalog for the operation tree.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation in the validation branch | |
| params | Yes | Parameters for the selected operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no description of side effects, authentication needs, or error behavior, the tool's behavioral traits are completely opaque. Agents cannot know what happens when an operation is executed.
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 brief—two sentences that are front-loaded with the tool's purpose and key guidance. It is concise, 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?
The tool has nested object parameters, no output schema, and a generic interface. The description completely fails to explain what operations are available, their inputs, or outputs, leaving agents without necessary 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?
Schema coverage is 100% and parameter descriptions in the schema adequately define the fields (op enum, params object). The description adds no additional meaning, but given the baseline, a 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 states 'Godot validation operations,' which identifies the domain but is vague. It lacks a specific verb-resource pairing and does not differentiate from sibling tools like audio_manage or core_manage, which follow the same pattern.
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 instruction to 'Call godot_catalog for the operation tree' provides some guidance, but it does not clarify when to use this tool versus others, nor does it explain prerequisites or conditions for invocation.
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.
v3.1.0animation_manageaudio_managecamera_managecore_managefilesystem_managegodot_cataloginput_managenetwork_managenode_managephysics_manageproject_managerender_2d_managerender_3d_manageruntime_managescene_managesignal_managesystem_manageui_managevalidation_manageScored across 19 tools
Each tool has a distinct domain prefix (e.g., animation, audio, camera) making them clearly distinguishable by name, despite identical descriptions.
All operation tools follow a consistent <domain>_manage pattern, except for godot_catalog which breaks the pattern.
19 tools is a reasonable number, but many of them are redundant wrappers that delegate to a single catalog tool, making the surface feel inflated.
The tool set lacks direct operations; all manage tools merely redirect to godot_catalog, which is a single point of entry, leaving the actual functionality hidden and incomplete for direct agent use.
Control Unreal Engine to browse assets, import content, and manage levels and sequences. Automate…
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Drive real devices from your AI Coding tool. Embed a client SDK (Unity, Godot, Flutter, iOS/macOS, Android, React Native, Web) in your app, then capture screenshots, traverse the UI tree, inject taps and key events, and run automated test tasks on the physical device over a secure relay.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
