This server provides extensive AI-driven control over Godot Engine 4.x projects through 358 tools across 29 categories. Key capabilities include:
File & Project Management: Read/write project config, list/ search/ move/ delete files, manage autoloads, input actions, export presets, validate project health, and generate reports.
Scene Editing: Create, read, edit, and delete .tscn scenes; add/remove/duplicate/rename/reparent nodes; modify properties, transforms, and collision shapes; connect/disconnect signals; batch-edit scenes; search nodes across scenes.
Scripts & Shaders: Create, read, write, validate, and analyze GDScript, C#, and .gdshader/.gdshaderinc files; inject functions, signals, and exports; build and edit VisualShader graphs with 40+ node types.
Resources: Create, read, and modify .tres resources using 14 built-in templates for materials, animations, themes, physics materials, navigation meshes, environments, and more.
Editor Control (123 tools): Control a running Godot editor: play/stop/pause project, set breakpoints, debug step, inspect scene tree, select nodes, save scenes, create/attach scripts, bake lightmaps/navigation, manipulate 3D viewport, and query ClassDB for live documentation. All scene mutations are registered on the native undo stack (Ctrl+Z reversible).
Runtime Game Control (11 tools): Inspect and manipulate a live running game: read/write node properties, call methods, emit signals, inject input, freeze/resume/step frames, capture screenshots.
Animation & Audio: Manage AnimationPlayer/AnimationTree tracks, keyframes, libraries; configure audio bus layouts, effects, and volumes.
Physics & Navigation: Create collision shapes, physics materials, joints (Pin, Hinge, Slider, etc.); create/inspect navigation meshes and links; handle VehicleBody3D and SoftBody3D.
Diff & Validation: Compare scenes, resources, scripts, animations, and config files; validate project integrity.
Asset Operations: Duplicate, delete, move, create files/directories with backup support.
Tool Discovery & Diagnostics: search_tools to find relevant tools, get_status for connectivity and error diagnostics.
Engine Introspection: Query ClassDB for classes, methods, properties, signals, and built-in docs.
Transport & Modes: Supports stdio, SSE, and Streamable HTTP; optional read-only mode (--read-only) that blocks all 164 write/side-effect tools; token authentication for HTTP.
Provides tools for interacting with Godot Engine projects, enabling AI agents to manage scenes, scripts, resources, animations, audio, and more within a Godot project.
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 list all scenes in the project"
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.
Godot MCP is a Model Context Protocol server that connects any AI assistant — Claude, Cursor, VS Code Copilot, Windsurf, Cline, Codex, Aider — directly to Godot Engine 4.x. Your AI stops guessing about your project and starts operating it.
📂 Reads and writes your project files natively — .tscn scenes, .tres resources, GDScript, C#, .gdshader, project.godot. Custom parsers, no Godot process required, instant response.
🎛️ Drives the live editor — select nodes, connect signals, author visual shaders, bake lightmaps, set breakpoints, step the debugger, run and stop the game.
↩️ Every scene edit is undoable — add, remove, rename, move, reparent, duplicate and instantiate all register on Godot's native undo stack. If the AI gets it wrong, Ctrl+Z puts it back.
🎮 Reaches inside the running game — inspect the live scene tree, call methods, inject input, freeze the game, step it one frame at a time, and screenshot the result. No other public Godot MCP does this.
🔎 Stays usable at scale — search_tools finds the right tool out of 386, get_status tells you exactly what is connected, and every error returns a typed code plus a repair hint.
386 tools · 30 categories · 22 AI clients · 4 communication paths · one-command setup.
npx @yanhuifair/godot-mcp --enable-plugin -p .Requirement | |
Godot | 4.x (Godot 3 not supported) |
Node.js | >= 18 |
AI Client | Any MCP-compatible client (see Configuration) |
Godot MCP | Other Godot MCP servers | |
Tool count | 386 across 30 categories | 16 – 156 |
Works without Godot running | ✅ Native | ⚠️ Usually needs a live editor |
Live editor control | ✅ 140 tools — play, debug, breakpoints, viewport, bake | Partial |
Undoable AI edits | ✅ Every scene mutation is one Ctrl+Z away — native | ❌ Edits are permanent |
Control the running game | ✅ 11 tools — live tree, method calls, input injection | ❌ None |
Deterministic frame stepping | ✅ | ❌ None |
Tool discovery for large catalogs | ✅ | ❌ None |
Error messages | ✅ Typed error code + actionable repair hint | Raw stack traces |
Transports | Stdio · SSE · Streamable HTTP | Usually stdio only |
Editor plugin install | ✅ One command, auto-enabled | Manual copy |
Engine introspection | ✅ Live ClassDB — classes, methods, properties, signals, docs | Rare |
If you have ever wanted to say "run the game, freeze it at the moment the player lands, and show me the collision state" — this is the server that can actually do it.
Related MCP server: Godot MCP server
Two setup steps, about two minutes. You do not need to install anything globally, and you do not need to keep a terminal open — your AI client starts the server for you.
You need | How to check |
Godot 4.x installed | Open Godot → the version shows in the title bar. (Godot 3 is not supported.) |
Node.js 18 or newer | Run |
An MCP-capable AI client | VS Code + Copilot, Cursor, Claude Desktop, Windsurf, Cline… see the full list. |
Open a terminal, cd into your Godot project folder (the one containing project.godot), and run:
npx @yanhuifair/godot-mcp --enable-plugin -p .Run this from your project root — the folder containing
project.godot— because-p .means "the current directory". If you run it from anywhere else, pass an absolute path instead:npx @yanhuifair/godot-mcp --enable-plugin -p /Users/me/games/my-game
Always installs the latest version.
npxfetches the newest release every time. To force it or pin a specific version:npx @yanhuifair/godot-mcp@latest --enable-plugin -p .(latest) ·npx @yanhuifair/godot-mcp@1.11.2 --enable-plugin -p .(pinned)
What this does: copies the plugin into addons/godot-mcp/ and switches it on inside project.godot. Nothing to click in Godot.
How to confirm it worked: you should now see an addons/godot-mcp/ folder in your project. If Godot is already open, reload the project (Project → Reload Current Project) so it picks up the plugin.
Only if you want the live editor and live game tools (play the scene, read the current selection, set breakpoints, bake lightmaps, freeze the running game…).
Over 220 of the 386 tools — everything that reads and writes .tscn, .tres, .gd, shaders, project settings, etc. — work without the plugin and without Godot even being open. If that's all you need, skip to Step 2.
Create .vscode/mcp.json in your project root (this exact file works for VS Code / GitHub Copilot):
{
"mcpServers": {
"godot-mcp": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@yanhuifair/godot-mcp", "-p", "."]
}
}
}Then restart your AI client so it reads the new config.
Using something else? The config file has a different name and location per client, but the
command/argspart is almost always identical. Copy-paste blocks for Cursor, Claude Desktop, Claude CLI, Windsurf, OpenAI Codex, Cline, Roo Code, Continue, Aider, Cody, Goose, Zed are in AI Client Configuration.
Ask your AI:
"Run get_status"You should get back the tool count and whether the editor / runtime bridges are reachable. That means everything is wired up. Now try:
"List all scenes in the project"
"Find all CharacterBody2D nodes and tell me their collision layers"
"Run the game and take a screenshot"With 386 tools, the AI can't see them all at once — tell it to search_tools when it isn't sure what's available (e.g. "search_tools for animation").
Symptom | Fix |
Client shows no | Restart the client. Config files are only read on startup. |
| Node.js isn't installed or isn't on your |
| The |
Editor tools fail, file tools work | The plugin isn't installed/enabled. Re-run Step 1, then reload the project in Godot. |
| Godot isn't running, or the plugin isn't enabled. The server will try to launch Godot itself; if that fails, open the project in Godot manually and check Project → Project Settings → Plugins → Godot MCP is enabled. |
| The editor received the command but refused it — usually a wrong node path, a property that doesn't exist on that node type, or an invalid target. The message carries Godot's own reason. Use |
AI made a scene edit you don't want | Press Ctrl+Z in Godot, or call |
Godot binary not found | Set the |
Godot MCP provides comprehensive coverage of the Godot 4.x engine through 386 tools in 30 categories.
# One command to set up everything
npx @yanhuifair/godot-mcp --enable-plugin -p .
# Then ask your AI:
> "Create a 2D platformer scene with a CharacterBody2D player"
> "Add a Timer node, connect its timeout signal, write the handler"
> "Create a metallic PBR material and apply it to all MeshInstance3D nodes"
> "Set up an audio bus with reverb, set SFX volume to -6dB"
> "Set a breakpoint at line 42, run the game, step through the debugger"Category | Tools | Description |
Editor | 140 | Live editor control — select, play, undo, save, breakpoints, file ops, performance |
Project | 24 | Config, input map, file ops, autoloads, export presets, validation, unused assets |
Scene | 22 | Scene CRUD — nodes, signals, transforms, collision, sprites |
Script + Shader | 21 | GDScript/Shader CRUD, structure analysis, code injection, validation |
Domain | 14 | Curve, Gradient, Path, Skeleton, ReflectionProbe, MultiMesh, NoiseTexture |
Animation | 10 | AnimationPlayer/AnimationTree — tracks, keyframes, parameters |
Godot Engine | 9 | Engine detection, launch editor, run/export project, screenshot |
Coverage | 18 | Mesh primitives, 2D lights, vehicles, spring arm, decal, occluder, grid map |
Node Inspectors | 8 | CharacterBody, AnimatedSprite, Audio, Video, Parallax, RichText, Container, Tab |
Resource | 8 | .tres CRUD, PBR materials, themes, 14 templates |
Audio | 7 | Audio bus layout, effects, volume |
Shader Graph | 8 | VisualShader graph — 40+ node types, connections, parameters |
Utility | 9 | Signal catalog, StyleBox, AtlasTexture, popup listing, cohesion report |
Rendering | 5 | MeshInstance, Viewport, Area, RayCast/ShapeCast |
Environment | 6 | Environment read/write, presets |
Inspector | 5 | Camera, Light, Particle node inspection |
Physics | 5 | PhysicsMaterial CRUD, collision layers |
Import | 3 | .import file read/write |
TileMap | 5 | TileSet resources, TileMapLayer inspection |
Navigation | 6 | NavigationRegion, NavigationMesh |
Translation | 8 | CSV/PO translation files, .po authoring, registration |
Joints | 5 | Physics joints — create, configure, list |
UID | 4 | File UID query, batch update, missing UID detection |
2D Geometry | 4 | CollisionPolygon2D, shape point editing |
Diff | 5 | Scene and resource comparison |
Texture | 4 | Texture import/read/write, atlas, noise |
Extension/World/C# | 5 | GDExtension, C#, World3D, CSProj |
Meta / Introspection | 2 | Tool search (search_tools) + system diagnostics (get_status) |
Logs | 5 | Read game-run logs ( |
Runtime (game) | 11 | Control the running game — tree, properties, methods, signals, input, freeze/step, screenshot |
Total: 386 tools across 30 categories
Project Management
Read and write project.godot settings, input maps, autoload singletons, and export presets. Perform file operations (list, search, move, delete with .bak backups), validate project health, detect unused assets, and generate comprehensive project reports.
Scene Editing
Full CRUD on .tscn scene files. Add, delete, modify, clone, and rename nodes. Edit node properties, transforms (position/rotation/scale), collision shapes, and sprite textures. Connect and disconnect signals between nodes. Search nodes across scenes by type, property, group, or signal.
Scripting & Shaders
Read, write, and create GDScript, C#, and .gdshader files. Analyze script structure (class names, signals, exported variables, functions). Inject functions, signals, and @export variables into existing scripts. Validate GDScript for common syntax issues. Validate and compile shaders. Manage VisualShader graphs — add, remove, connect, and configure nodes.
Resource Management
Read, write, and create .tres resource files with 14 built-in templates (StandardMaterial3D, ShaderMaterial, ORMMaterial3D, CanvasItemMaterial, and more). Inspect and modify PBR material parameters. Read Theme resources with properties grouped by type.
Animation Pipeline Complete AnimationPlayer and AnimationTree support: list animations, read tracks and keyframes, create new animations, add/remove tracks, set keyframes at specific times, configure animation libraries, and inspect AnimationTree state machines.
Audio Configuration Read, create, and modify audio bus layouts. Add and remove audio buses, attach effects (14 types: Reverb, Delay, Chorus, Compressor, and more), and set bus volume in dB.
Physics & Collision Inspect VehicleBody3D, SoftBody3D, and physics materials. Create collision shapes. Read collision layer and mask configuration from project settings. Create physics joints (PinJoint, HingeJoint, SliderJoint, and more).
Rendering & Environment Inspect MeshInstance3D, Viewport, Area, and RayCast nodes. Create and configure Environment resources (4 presets). Manage 2D lights, decals, and occluders. Read 3D mesh primitives (Box, Sphere, Capsule, Cylinder, Torus, and more).
Live Editor Control (140 tools) Interact with the running Godot editor in real time over a TCP or stdio bridge: select nodes, run/stop/pause the project, undo/redo, save scenes, create and attach scripts, set breakpoints, step the debugger, evaluate expressions, control the 3D viewport camera, bake lightmaps and navigation meshes, manage plugins, and simulate key presses.
Live Game Runtime Control (11 tools)
Go beyond the editor and reach into the actually running game. Inspect the live scene tree with real positions, read and write node properties at runtime, call arbitrary methods, emit signals, inject keyboard input, and — the headline feature — runtime_freeze the game, runtime_step forward an exact number of frames, and runtime_screenshot the result. This makes AI-driven gameplay debugging deterministic and reproducible.
Visual Shader Graphs Create and modify VisualShader graphs programmatically. Add nodes from a catalog of 40+ types (constants, math operations, textures, inputs), connect node ports, set node parameters, and list available node types with their default input/output configurations.
Engine Introspection (ClassDB) Query the live engine's ClassDB: list all classes, inspect methods, properties, and signals of any Godot type, read built-in class documentation, and search the help system. The AI works from ground truth instead of hallucinating APIs.
TileMap, Navigation & Translation Inspect TileSet resources and TileMapLayer nodes. List and read NavigationRegion nodes, create NavigationMesh resources. Read and create CSV/PO translation files with search support.
MCP Protocol (stdio/SSE/Streamable HTTP)
+-----------------+ +------------------+
| AI Client |<-------------------------------------->| Godot MCP Server |
| (VS Code/Cursor | | (TypeScript) |
| Claude/etc.) | | |
+-----------------+ | +-------------+ |
| | Tool Registry| |
| | (386 tools) | |
| +------+------+ |
| | |
| +----v-----+ |
File I/O (direct) | | Parsers | |
+------------------+<-------------------------------------->| | .tscn | |
| Godot Project | | | .tres | |
| Files on Disk | | | .godot | |
| (.tscn/.tres/.gd)| | +----------+ |
+------------------+ | |
| +-------------+ |
stdin/stdout (spawned process) | | Godot CLI | |
+------------------+<-------------------------------------->| | (spawn/edit) | |
| Godot Editor | | +-------------+ |
| (GDScript addon) | +------------------+
| TCP port 9876 |
| 102 commands |
+------------------+The server uses four distinct communication paths depending on the operation:
Direct File I/O — For file-based tools (read_scene, write_script, create_resource, etc.), the server reads and writes Godot project files directly on disk using custom parsers. No Godot process is required. This is the fastest path.
Godot CLI — For engine operations (launch_editor, run_project, export_project, get_godot_version), the server spawns Godot as a subprocess and communicates via command-line arguments and stdout/stderr.
Editor Bridge (dual-mode) — For live editor tools (editor_get_selection, editor_play, editor_set_breakpoint, etc.), the MCP server communicates with a running Godot editor instance. Two modes are supported:
TCP mode (default): Connects to an already-running Godot on localhost:9876. The editor plugin listens on this port.
Stdio mode (fallback): Spawns Godot as a child process with --editor --path <project>, sets MCP_STDIO=true, and communicates via stdin/stdout using JSON-RPC with a __MCP__: marker prefix. This mode auto-starts and auto-restarts Godot as needed.
Live-Game Runtime Bridge — For runtime tools (runtime_*, e.g. runtime_get_tree, runtime_set_node, runtime_step), the MCP server talks to a small autoload running inside your played game on 127.0.0.1:9877. The autoload (addons/godot-mcp/runtime_bridge.gd, named godot_mcp_runtime) is added to your project and listens only on loopback. This lets the AI inspect and mutate the live scene tree, inject input, pause/resume, deterministically step frames, and screenshot the running game — a tier no other public Godot MCP offers out of the box.
godot-mcp/
├── src/
│ ├── index.ts # CLI entry point, argument parsing, transport dispatch
│ ├── server.ts # MCP server factory, tool registration, request routing
│ ├── tools/ # tool handler files (one group per category)
│ │ ├── register.ts # Centralized registration (386 tools)
│ │ ├── project.ts # Project management tools
│ │ ├── scene.ts # Scene editing tools
│ │ ├── script.ts # Script and shader tools
│ │ ├── editor.ts # Live editor bridge (TCP + stdio, persistent connection)
│ │ ├── resource.ts # Resource/material/theme tools
│ │ ├── godot.ts # Godot engine control
│ │ ├── animation.ts # Animation pipeline
│ │ ├── audio.ts # Audio bus management
│ │ ├── scene_inspectors.ts # 2D lights, vehicles, spring arm, etc.
│ │ ├── mesh.ts # 3D mesh primitives
│ │ ├── shader_graph.ts # VisualShader graph editing
│ │ └── ... (16 more files: domain, physics, navigation, joints, etc.)
│ ├── parsers/
│ │ ├── scene_parser.ts # .tscn file parser (sections, nodes, connections)
│ │ ├── resource_parser.ts # .tres file parser
│ │ ├── config_parser.ts # project.godot INI parser
│ │ └── parser_helpers.ts # Shared utilities (quote handling, bracket balancing)
│ ├── transports/
│ │ ├── stdio.ts # Stdio transport (default, for local AI clients)
│ │ └── http-server.ts # SSE + Streamable HTTP transport
│ └── utils/
│ ├── types.ts # TypeScript type definitions
│ ├── file_utils.ts # File system operations with path traversal protection
│ ├── godot_cli.ts # Godot binary detection, process management
│ ├── registry.ts # ToolRegistry class with sorted listing
│ ├── errors.ts # Structured error codes
│ └── cache.ts # TTL-based file cache for parsed documents
├── addons/
│ └── godot-mcp/ # Godot editor plugin
│ ├── plugin.cfg # Plugin metadata
│ └── plugin.gd # stdin reader, TCP server, 102 command handlers
├── test/ # Vitest suite (197 tests: 127 runnable + 70 integration requiring a live Godot project) + legacy .mjs suites
│ ├── test_all.mjs # Legacy standalone suite (176 tool checks)
│ ├── test_editor.mjs # Legacy editor bridge TCP tests
│ ├── test_runner.mjs # Early integration test runner
│ ├── tools.test.ts # Vitest tool handler tests
│ ├── parsers.test.ts # Vitest parser tests
│ ├── structural.test.ts # Vitest structural tests
│ ├── integration_mcp_test.test.ts # Vitest integration tests
│ ├── server_normalization.test.ts # Vitest parameter-normalization tests
│ ├── scene_format.test.ts # .tscn/.tres on-disk format contract (round-trip, hierarchy, ids)
│ ├── addon_bridges.test.ts # GDScript bridge invariants (reserved names, poll(), return types)
│ ├── editor_error_surface.test.ts # Editor error tagging + undo/redo addon invariants
│ ├── fixtures/ # Test fixture files (.tscn, .tres, .gd)
│ └── test-project/ # Standalone Godot test project
├── scripts/
│ └── sync-addons.js # Post-build: syncs addons to target Godot project
├── package.json
└── tsconfig.jsonAll Godot file formats (.tscn, .tres, project.godot) are parsed directly in TypeScript using custom parsers. This eliminates the need to launch Godot for file operations, making reads and writes near-instantaneous.
Scene parser (parsers/scene_parser.ts):
Parses all .tscn sections: [gd_scene], [ext_resource], [sub_resource], [node], [connection]
Handles multi-line property values with balanced bracket/quote detection
Builds node hierarchy trees from parent references
Supports round-trip serialization for safe edits
Resource parser (parsers/resource_parser.ts):
Parses .tres text resources with section-based structure
Detects binary .res files via GDROM magic header (returns unsupported error)
Extracts header, external resources, sub-resources, and main resource properties
Config parser (parsers/config_parser.ts):
Parses INI-style project.godot and .cfg files
Handles multi-line values with indentation-based continuation
Preserves comments for round-trip editing
The editor plugin (addons/godot-mcp/plugin.gd) implements 102 command handlers that wrap Godot's EditorInterface API. Communication uses JSON-RPC 2.0 over two channels:
TCP mode (port 9876): When Godot is running independently, the plugin accepts TCP connections on 127.0.0.1 only (never the LAN). This is the preferred mode for interactive development. Set GODOT_MCP_TOKEN (or the project setting godot_mcp/auth_token) to require an auth handshake per connection.
Stdio mode: When the MCP server spawns Godot as a child process (godot --editor --path <project>), the plugin reads JSON-RPC requests from stdin and writes responses to stdout with a __MCP__: prefix marker. The server filters for these markers to distinguish JSON-RPC from Godot's standard output.
The bridge auto-detects which mode to use: it first attempts a rapid TCP health check (800ms timeout), and falls back to spawning Godot if no existing instance is found. If the spawned process exits unexpectedly, it auto-restarts up to 3 times.
To accommodate AI clients that may use either snake_case or camelCase parameter naming, the server automatically normalizes 30+ common parameter names to the snake_case keys its Zod schemas expect (projectPath -> project_path, scenePath -> scene_path, etc.) before validation. The advertised inputSchema always uses snake_case, so snake_case inputs pass through unchanged.
Path traversal protection: All file operations validate that resolved paths stay within the project root
Automatic backups: Write operations on script and scene files create .bak backup copies
Read-only mode: --read-only (or GODOT_MCP_READ_ONLY=true) rejects the 218 write/side-effect tools (write_, create_, delete_, move_, set_, edit_, editor_* mutations, run/export/launch, …) via a maintained whitelist — they are hidden from tools/list and blocked with a READ_ONLY error if called directly
TCP only on loopback: The editor plugin's TCP bridge binds 127.0.0.1 only, never the LAN
Optional token auth: Set GODOT_MCP_TOKEN to require a bearer token on HTTP (/mcp, /sse) and an auth handshake on the plugin TCP bridge; non-loopback HTTP binds are refused without it
Undoable editor mutations: Every scene-changing editor command (editor_add_node, editor_remove_node, editor_set_node_properties, editor_rename_node, editor_move_node, editor_move_node_3d, editor_reparent_node, editor_duplicate_node, editor_delete_selected, editor_instantiate_scene, …) is committed through Godot's native EditorUndoRedoManager, so a single Ctrl+Z (or editor_undo) reverts what the AI just did
Structured errors: Tool failures return structured { content, isError: true } responses; privileged paths carry typed error codes (READ_ONLY, EDITOR_NOT_REACHABLE, EDITOR_COMMAND_FAILED, NOT_FOUND, …). Engine-side failures are never reported as success — if the editor rejects a command, the tool surfaces EDITOR_COMMAND_FAILED with the engine's own message
Godot MCP supports three transport protocols. Choose based on your client and deployment needs.
Mode | Protocol | Use Case | Default |
Stdio | Standard I/O (stdin/stdout) | Local AI clients (VS Code, Claude Desktop, Cursor, Windsurf) | Yes |
SSE | Server-Sent Events over HTTP | Older MCP clients, web-based clients, remote access | |
Streamable HTTP | MCP 2025 Streamable HTTP | Modern MCP clients, production deployments, remote access |
JSON-RPC communication over standard I/O (stdin/stdout). Ideal for local development — no network configuration needed.
npx @yanhuifair/godot-mcp -p /path/to/your/godot/projectHTTP-based transport using SSE for server-to-client streaming. Compatible with older MCP clients.
npx @yanhuifair/godot-mcp -t sse --port 3000 -p /path/to/your/godot/projectOption | Description | Default |
| Enable SSE transport mode | — |
| HTTP listen port |
|
| Bind address (use |
|
Client config:
{
"mcpServers": {
"godot-mcp": {
"url": "http://127.0.0.1:3000/sse"
}
}
}Modern HTTP transport based on the MCP 2025 spec. Supports session management, reconnection with resume, and both stateful and stateless modes.
npx @yanhuifair/godot-mcp -t streamable-http --port 3000 -p /path/to/your/godot/projectEndpoints:
Method | Path | Purpose |
|
| Establish SSE stream (supports |
|
| Send JSON-RPC requests/notifications |
|
| Close session |
Client config:
{
"mcpServers": {
"godot-mcp": {
"url": "http://127.0.0.1:3000/mcp",
"transportType": "streamable-http"
}
}
}npx @yanhuifair/godot-mcp -t all --port 3000 -p /path/to/your/godot/projectStarts: Stdio + SSE (/sse) + Streamable HTTP (/mcp) + Health Check (/health)
curl http://127.0.0.1:3000/health
# {"status":"ok","version":"1.11.2","projectRoot":"/path/to/project","endpoints":{...}}Read this first. In normal use you never launch this server yourself — your AI client launches it in the background using the
commandfrom its config file. The commands below are for installing the package and for manual/advanced runs (HTTP transports, debugging, CI).
Where to run these commands: from anywhere — but if you pass
-p ., the.refers to your current directory, so it must be your Godot project root (the folder containingproject.godot). When in doubt, pass an absolute path:-p /full/path/to/project.
Method | Best for | Trade-off |
npx (recommended) | Almost everyone | Nothing to install; always fetches the latest version. Tiny delay on first run. |
Global install | Slow/offline networks, pinning a version, using a bare | You must run |
From source | Contributing, or you need an unreleased change | You have to rebuild after every |
npx -y @yanhuifair/godot-mcp -p /path/to/your/godot/projectnpx downloads the package on demand and caches it. This is exactly what the config snippets in AI Client Configuration use, so if you follow the Quick Start there is no separate install step at all — -y just skips the "install this package?" prompt.
npm install -g @yanhuifair/godot-mcp
# then run it by name anywhere
godot-mcp -p /path/to/your/godot/projectIf you install globally, change your client config from "command": "npx" to "command": "godot-mcp" and drop the -y and package name from args:
{ "command": "godot-mcp", "args": ["-p", "."] }Update later with npm update -g @yanhuifair/godot-mcp.
git clone https://github.com/yanhuifair/Godot-MCP.git
cd Godot-MCP
npm install
npm run build # compiles TypeScript into dist/
node dist/index.js -p /path/to/your/godot/projectPoint your client at the built entry file:
{ "command": "node", "args": ["/absolute/path/to/Godot-MCP/dist/index.js", "-p", "."] }After any install method, confirm everything is in place:
Check | How | Expected |
Server version |
| A version number (e.g. |
Plugin files | Look in |
|
Plugin enabled | Open |
|
Server starts |
| Prints the tool count, e.g. |
Editor bridge | Open the project in Godot | Output log shows |
Install troubleshooting
Symptom | Fix |
| Install Node.js 18+ and make sure it is on your |
| You must run in the project root ( |
Godot still reports an old plugin version | Close Godot, delete |
Plugin loads but tools return | Project → Project Settings → Plugins → make sure Godot MCP is enabled, then reload the project. |
npx always fetches the newest release, so the same one-liner that installs also upgrades:
npx -y @yanhuifair/godot-mcp@latest --enable-plugin -p .To refresh the editor plugin (the files in addons/godot-mcp/), delete the old copy first, then re-run — otherwise stale plugin files can linger:
rm -rf addons/godot-mcp && npx -y @yanhuifair/godot-mcp@latest --enable-plugin -p .On Windows PowerShell use
rm -r addons/godot-mcp(no-fflag).
Pin a version — npx @yanhuifair/godot-mcp@1.11.2 …; force latest — npx @yanhuifair/godot-mcp@latest ….
Global install — npm update -g @yanhuifair/godot-mcp.
From source — git pull && npm run build.
Check your version — npx @yanhuifair/godot-mcp --version.
Upgrading from v1.9.0? That release shipped an editor plugin whose
runtime_bridge.gdfailed to parse in Godot 4.7 (a_inputfunction colliding with the built-inNode._input, plus an untyped_resolve). If your editor logs those parse errors, deleteaddons/godot-mcpand re-run--enable-pluginto install the fixed plugin.
See CHANGELOG for the complete history. v1.11.2 added export-preset writing (create_export_preset / update_export_preset / remove_export_preset), localization writing (create_po_translation / register_translation / unregister_translation), and a read-only / path-sandbox security pass.
Flag | What it does |
| Your Godot project folder — the one containing |
| Path to the Godot executable. Auto-detected if omitted (see the detection order below). |
| Copy the editor plugin into |
| Copy the plugin files only — you enable it yourself in Godot's Plugins tab. |
| Safe mode: rejects the 218 tools that write files or cause side effects. Great for letting an AI explore an unfamiliar project. |
|
|
| HTTP port for |
| HTTP bind address. Default |
| Disable an individual endpoint when running |
| Print all options and sample client configs. |
# a few real examples
npx @yanhuifair/godot-mcp --enable-plugin -p . # one-time setup for a project
npx @yanhuifair/godot-mcp -p . --read-only # let the AI look, not touch
npx @yanhuifair/godot-mcp -p . -t streamable-http --port 8080Variable | Description |
| Path to Godot binary (optional, auto-detected) |
|
|
| Auth token. HTTP: required when binding a non-loopback host. Plugin TCP bridge: enables the |
| Path to test project for integration tests |
| Target project for the |
|
|
Godot auto-detection order: GODOT_PATH -> /Applications/Godot.app -> PATH -> snap/flatpak -> Windows Program Files
Security note: The MCP server can read/write your project files, run GDScript, and export builds. When using HTTP transports, always set
GODOT_MCP_TOKEN— the server refuses to bind a non-loopback address without it, and loopback-only access is strongly recommended anyway.
Godot MCP is a plain stdio MCP server — anything that speaks MCP can drive it. Below are step-by-step setups for the most popular AI agents, IDEs and CLIs.
In a hurry? Nearly every client wants the same six lines of JSON. Copy the universal snippet, drop it into the file listed for your client, restart, then ask the AI to run
get_status. Done.
Client | Where the config lives | Top-level key |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
AI panel → MCP (UI) |
| |
|
| |
Settings → AI Assistant → MCP |
| |
|
| |
|
| |
|
| |
Settings → MCP servers (UI) |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
— | see below |
This is the config ~80% of clients accept verbatim:
{
"mcpServers": {
"godot-mcp": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@yanhuifair/godot-mcp", "-p", "."]
}
}
}What each part means:
Field | Why it's there |
| The name your AI will see. Rename it freely — nothing depends on it. |
| The server runs as a local child process. Some clients omit this field entirely; both are fine. |
| On Windows, if you hit |
| Skips npx's "install this package?" prompt. Without it the server hangs on first run. |
| Your Godot project folder. |
When to use . and when to use a full path:
Editors that open a folder (VS Code, Cursor, Windsurf, Zed, Trae, JetBrains) launch the server inside that folder → "." works, and the config stays portable across machines.
Desktop apps and global CLIs (Claude Desktop, Cherry Studio, a user-scope Claude Code entry) have no project folder → use an absolute path like "/Users/you/Games/MyGame" or "C:/Users/you/Games/MyGame".
Windows: always use forward slashes (C:/Users/...) or escaped backslashes (C:\\Users\\...) in JSON.
Two useful variants:
// Read-only — the AI can inspect everything but cannot modify a single file
"args": ["-y", "@yanhuifair/godot-mcp", "-p", ".", "--read-only"]
// Pin the Godot binary when auto-detection fails
"env": { "GODOT_PATH": "/Applications/Godot.app/Contents/MacOS/Godot" }1. Register the server. Run this from inside your Godot project folder:
cd /path/to/your/godot/project
claude mcp add godot-mcp -- npx -y @yanhuifair/godot-mcp -p .Everything after -- is the command Claude Code will spawn. The -- separator is required — without it Claude Code eats the -y and -p flags as its own.
2. Pick a scope (optional — the default is fine for one project):
Command | Stored in | Who gets it |
|
| Just you, just this project |
|
| Everyone who clones the repo — commit this |
|
| You, in every project (use an absolute |
Adding an environment variable:
claude mcp add godot-mcp -e GODOT_PATH=/Applications/Godot.app/Contents/MacOS/Godot \
-- npx -y @yanhuifair/godot-mcp -p .3. Verify. Start claude, then type /mcp. You should see godot-mcp with a connected status. Press Enter on it to browse the 386 tools.
4. First prompt:
Run
get_statusand tell me what the Godot MCP server can currently reach, then list every scene in the project.
Managing it later:
claude mcp list # all registered servers + connection status
claude mcp get godot-mcp # full details of one server
claude mcp remove godot-mcp # unregisterIf you used
-s project, Claude Code will ask you to approve.mcp.jsonthe first time you open the project. That's a security prompt, not an error — answer yes.
1. Create the config. Project-level is best — it travels with the repo:
.cursor/mcp.json in your Godot project root:
{
"mcpServers": {
"godot-mcp": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@yanhuifair/godot-mcp", "-p", "."]
}
}
}Prefer it everywhere? Use ~/.cursor/mcp.json (Windows: %USERPROFILE%\.cursor\mcp.json) with an absolute -p path instead.
You can also let Cursor create the file for you: Settings → Tools & Integrations → Add Custom MCP.
2. Verify. Open Cursor Settings → Tools & Integrations. godot-mcp should appear with a green dot and a tool count. Cursor hot-reloads this file, so no restart is needed — if the dot is red, click the refresh icon and check the JSON for a trailing comma.
3. Switch the chat to Agent mode (Cmd/Ctrl+I). Ask mode cannot call tools.
4. First prompt:
Use
search_toolsto find the tileset tools, then tell me which TileSets exist in this project.
Tool limit warning: Cursor only sends ~40–80 tools to the model at a time. Godot MCP ships 386. Keep
search_toolsin your rules file (see Make Your Agent Use the Tools Well) so the model looks a tool up instead of hallucinating one.
1. Create .vscode/mcp.json in your Godot project root. Note that VS Code's own key is servers, not mcpServers:
{
"servers": {
"godot-mcp": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@yanhuifair/godot-mcp", "-p", "."]
}
}
}Shortcut: run MCP: Add Server… from the Command Palette (Cmd/Ctrl+Shift+P) and pick Command (stdio) — VS Code writes the file for you.
2. Start it. VS Code shows a small Start codelens directly above the "godot-mcp" line in the JSON. Click it. (Or run MCP: List Servers → godot-mcp → Start Server.)
3. Switch Copilot Chat to Agent mode. Open Chat (Cmd/Ctrl+Shift+I), then choose Agent in the mode dropdown. Ask and Edit modes don't call MCP tools.
4. Verify. Click the tools icon (🛠) in the chat input — godot-mcp should be listed. If you see "0 tools", run MCP: List Servers → godot-mcp → Show Output to read the startup log.
5. First prompt:
#godot-mcp Run get_status, then list all scenes.
Team tip: commit
.vscode/mcp.json. Everyone who clones the repo gets the server automatically — VS Code just asks each person to trust it once.User-level instead: Command Palette →
MCP: Open User Configuration, and use an absolute-ppath.
1. Add the server with the built-in command (writes ~/.codex/config.toml for you):
codex mcp add godot-mcp -- npx -y @yanhuifair/godot-mcp -p .Or edit ~/.codex/config.toml by hand — note this is TOML, not JSON:
[mcp_servers.godot-mcp]
command = "npx"
args = ["-y", "@yanhuifair/godot-mcp", "-p", "."]
startup_timeout_sec = 30
[mcp_servers.godot-mcp.env]
GODOT_PATH = "/Applications/Godot.app/Contents/MacOS/Godot"startup_timeout_sec matters here: npx may need to download the package on the very first run, which can exceed Codex's default startup window.
2. Verify:
codex mcp list3. Use it — always launch Codex from inside the Godot project so -p . resolves correctly:
cd /path/to/your/godot/project
codex # interactive
codex exec "Run get_status and list all scenes" # one-shot1. Add the server:
cd /path/to/your/godot/project
gemini mcp add godot-mcp npx -y @yanhuifair/godot-mcp -p .Default scope is project → written to .gemini/settings.json. Add -s user to write ~/.gemini/settings.json instead (then use an absolute -p path).
Equivalent hand-written config:
{
"mcpServers": {
"godot-mcp": {
"command": "npx",
"args": ["-y", "@yanhuifair/godot-mcp", "-p", "."],
"timeout": 600000,
"trust": false
}
}
}trust: true skips the per-call confirmation prompt. Convenient, but it also means the AI can write files without asking — pair it with --read-only if you want a safety net.
includeTools / excludeTools accept arrays of tool names if you want to hand the model a curated subset instead of all 386.
2. Verify. Run gemini, then /mcp — it lists connected servers and their tools. gemini mcp list works outside a session.
3. First prompt:
Call get_status, then use search_tools to find animation-related tools.
1. Open the config. Either click Cascade → the hammer icon → Configure, or edit the file directly:
macOS/Linux: ~/.codeium/windsurf/mcp_config.json
Windows: %USERPROFILE%\.codeium\windsurf\mcp_config.json
{
"mcpServers": {
"godot-mcp": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@yanhuifair/godot-mcp", "-p", "/path/to/your/godot/project"]
}
}
}This file is global, so give it an absolute project path.
2. Refresh. Back in Cascade, click the hammer icon → Refresh. godot-mcp should turn green.
3. First prompt (Cascade is Cmd/Ctrl+L):
Run get_status, then read the main scene.
1. Open Cline's MCP settings — don't hunt for the file, use the UI: click the Cline icon in the sidebar → MCP Servers (the server rack icon at the top) → Installed tab → Configure MCP Servers. That opens cline_mcp_settings.json.
macOS: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
Windows: %APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json
Linux: ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
2. Add the entry:
{
"mcpServers": {
"godot-mcp": {
"command": "npx",
"args": ["-y", "@yanhuifair/godot-mcp", "-p", "/path/to/your/godot/project"],
"disabled": false,
"autoApprove": []
}
}
}autoApprove takes tool names that should run without a confirmation click — e.g. ["get_status", "search_tools", "list_scenes"] for read-only convenience.
3. Restart. Cline usually reloads on save; if not, click Restart Server next to godot-mcp in the MCP Servers panel. Wait for the dot to go green.
4. First prompt in Plan or Act mode:
Run get_status and summarize this Godot project's structure.
Roo Code supports both a project file and a global file — the project file wins on conflicts.
1a. Project-level (recommended): create .roo/mcp.json in your Godot project root:
{
"mcpServers": {
"godot-mcp": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@yanhuifair/godot-mcp", "-p", "."]
}
}
}1b. Global: Roo Code panel → MCP icon → Edit Global MCP (file lives at …/globalStorage/rooveterinaryinc.roo-cline/settings/mcp_settings.json). Use an absolute -p path there.
2. Enable it. In the Roo Code MCP panel, make sure the godot-mcp toggle is on and the status dot is green. Hit the refresh icon if it isn't.
3. First prompt:
Use search_tools to find shader tools, then list every .gdshader file.
Trae has two steps most people miss: adding the server and attaching it to an agent.
1. Add the server. Open the AI side panel → Settings (gear) → MCP → Add → Add manually (or Import from JSON), then paste:
{
"mcpServers": {
"godot-mcp": {
"command": "npx",
"args": ["-y", "@yanhuifair/godot-mcp", "-p", "."]
}
}
}Wait for the status to become Connected/available before continuing.
2. Attach it to an agent. This is the step that trips people up — Trae agents only see MCP servers you explicitly grant them. Go to Agents → create or edit an agent → Tools → tick godot-mcp, then save.
3. Select that agent in the chat's agent dropdown.
4. First prompt:
Run get_status, then list all scenes in this project.
If the tools never fire, check MCP → godot-mcp → View logs — Trae surfaces the raw stdio startup output there.
1. Add a local server. Either use the UI — Settings → AI → MCP Servers → Add Server → Add Local Server — or run zed: open settings file from the Command Palette and add:
{
"context_servers": {
"godot-mcp": {
"command": "npx",
"args": ["-y", "@yanhuifair/godot-mcp", "-p", "."],
"env": {}
}
}
}Zed calls MCP servers context servers — the key is context_servers, not mcpServers. Everything else is the same.
2. Verify. Go back to Settings → AI → MCP Servers. The dot next to godot-mcp should be green with the tooltip "Server is active".
3. First prompt in the Agent Panel:
Use the godot-mcp tools: run get_status, then list the scenes.
Mentioning the server by name meaningfully improves tool-selection accuracy in Zed. For guaranteed usage, create an agent profile that turns off the built-in tools and leaves only
godot-mcpon.
Relevant if you write C# in Rider against a Godot project. Requires a 2025.1+ IDE with the AI Assistant plugin (Junie shares the same MCP config).
1. Open Settings/Preferences → Tools → AI Assistant → Model Context Protocol (MCP).
2. Click +, switch the dialog to As JSON, and paste:
{
"mcpServers": {
"godot-mcp": {
"command": "npx",
"args": ["-y", "@yanhuifair/godot-mcp", "-p", "."]
}
}
}If your IDE launches processes without your shell's PATH, replace "npx" with the absolute path (which npx / where npx).
3. Apply, then wait for the row to report a tool count instead of an error.
4. Use it in the AI Assistant chat with Codebase/Agent mode enabled — plain chat mode does not call tools.
1. Create opencode.json in your project root (or ~/.config/opencode/opencode.json for all projects):
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"godot-mcp": {
"type": "local",
"command": ["npx", "-y", "@yanhuifair/godot-mcp", "-p", "."],
"enabled": true,
"timeout": 30000
}
}
}Two OpenCode-specific gotchas:
command is a single array, not command + args.
The default tool-discovery timeout is 5000 ms. Listing 386 tools plus a cold npx download regularly blows past that — bump it to 30000 as shown or the server will silently show zero tools.
2. Verify. Start opencode in that folder. The MCP server appears at startup; tools are namespaced godot-mcp_*.
3. First prompt:
use godot-mcp to run get_status and list all scenes
1. Edit the config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Easier route: Settings → Developer → Edit Config opens the file directly.
{
"mcpServers": {
"godot-mcp": {
"command": "npx",
"args": ["-y", "@yanhuifair/godot-mcp", "-p", "/path/to/your/godot/project"]
}
}
}Claude Desktop has no project folder, so the absolute path is mandatory.
2. Fully quit and relaunch. Not "close the window" — quit the app (Cmd+Q / tray → Exit). Claude Desktop reads this file only at startup.
3. Verify. A tools icon appears in the chat input showing the tool count. If it's missing, check the log: ~/Library/Logs/Claude/mcp-server-godot-mcp.log (macOS) or %APPDATA%\Claude\logs\ (Windows).
4. First prompt:
Get the Godot version and list all scenes in my project.
Continue (VS Code + JetBrains) reads ~/.continue/config.yaml:
mcpServers:
- name: godot-mcp
command: npx
args:
- "-y"
- "@yanhuifair/godot-mcp"
- "-p"
- "/path/to/your/godot/project"Older Continue installs use ~/.continue/config.json with a mcpServers array instead — check which file exists before editing. Save, then reopen the Continue panel; tools are discovered automatically. MCP tools only fire in Agent mode.
Popular cross-platform desktop MCP client, fully GUI-driven.
Settings → MCP Servers → Add Server → Quick create.
Name: godot-mcp · Type: STDIO · Command: npx
Arguments — one per line, not space-separated:
-y
@yanhuifair/godot-mcp
-p
/path/to/your/godot/projectSave and toggle the server on. A green indicator plus a tool count means it's live.
In a chat, enable the MCP server via the toolbox icon under the input box, then ask it to run get_status.
Import from JSON also works — paste the universal snippet with an absolute
-ppath.
Interactive (recommended):
goose configure
# → Add Extension → Command-line Extension
# Name: godot-mcp
# Command: npx -y @yanhuifair/godot-mcp -p /path/to/your/godot/project
# Timeout: 300Or edit ~/.config/goose/config.yaml directly:
extensions:
godot-mcp:
name: godot-mcp
type: stdio
cmd: npx
args:
- "-y"
- "@yanhuifair/godot-mcp"
- "-p"
- "/path/to/your/godot/project"
enabled: true
timeout: 300Goose calls MCP servers extensions and uses cmd, not command. Restart Goose, then run /mcp to confirm the connection.
Aider's MCP support is version-dependent — run aider --help | grep -i mcp first to see which flags your build has.
# Point Aider at a standard MCP JSON file
aider --mcp-servers-file ./mcp.json
# Or inline
aider --mcp-servers '{"mcpServers":{"godot-mcp":{"command":"npx","args":["-y","@yanhuifair/godot-mcp","-p","."]}}}'./mcp.json is just the universal snippet. Persist it in .aider.conf.yml:
mcp-servers-file: ./mcp.json1. Add via CLI:
hermes mcp add godot-mcp --command "npx" --args "-y" "@yanhuifair/godot-mcp" "-p" "/path/to/your/godot/project"Or edit ~/.hermes/config.yaml directly:
mcp_servers:
godot-mcp:
command: "npx"
args: ["-y", "@yanhuifair/godot-mcp", "-p", "/path/to/your/godot/project"]2. Reload and verify. In a session run /reload-mcp, then hermes mcp list / hermes mcp test godot-mcp. Tools appear prefixed mcp_godot-mcp_*.
1. Add the server (CLI, or Control UI → Settings → MCP → Add server):
openclaw mcp add godot-mcp \
--command npx \
--arg "-y" --arg "@yanhuifair/godot-mcp" --arg "-p" --arg "/path/to/your/godot/project" \
--cwd /path/to/your/godot/projectOr write it directly into ~/.openclaw/openclaw.json:
{
"mcp": {
"servers": {
"godot-mcp": {
"command": "npx",
"args": ["-y", "@yanhuifair/godot-mcp", "-p", "."],
"cwd": "/path/to/your/godot/project",
"enabled": true
}
}
}
}2. Verify the connection — a saved definition proves nothing:
openclaw mcp doctor godot-mcp --probeRestart the Gateway / agent (or openclaw mcp reload) so it picks up the new definition.
1. Add a [[plugins]] entry in reasonix.toml (project) or ~/.reasonix/config.toml (global):
[[plugins]]
name = "godot-mcp"
command = "npx"
args = ["-y", "@yanhuifair/godot-mcp", "-p", "."]2. Restart Reasonix and ask it to call get_status — the godot-mcp_* tools appear in its tool list.
1. Add a custom MCP connector. Open the Connectors panel → Custom (top-right), and add a server with:
command: npx
args: -y @yanhuifair/godot-mcp -p /path/to/your/godot/projectThis saves to ~/.workbuddy/mcp.json under mcpServers:
{
"mcpServers": {
"godot-mcp": {
"command": "npx",
"args": ["-y", "@yanhuifair/godot-mcp", "-p", "."]
}
}
}2. Trust it. WorkBuddy keeps a new server inactive until you open it in the connectors list and click Trust. Then start a new session.
3. Verify. Ask:
use godot-mcp to run get_status and list all scenes
If your client accepts a local command, give it:
command: npx
args: -y @yanhuifair/godot-mcp -p /path/to/your/godot/projectIf your client only accepts a URL (n8n, Dify, browser-based agents, hosted connectors), run the server yourself and point the client at the HTTP endpoint:
export GODOT_MCP_TOKEN="$(openssl rand -hex 32)" # required for non-loopback binds
npx -y @yanhuifair/godot-mcp -p /path/to/your/godot/project -t all --port 3000Endpoint | URL |
Streamable HTTP (MCP 2025) |
|
SSE (legacy clients) |
|
Health check |
|
See Transport Modes for the full details.
386 tools is more than most models can keep straight, and many clients only forward a slice of them to the model. Two minutes of setup fixes this.
1. Drop a rules file in your project. Agents auto-read these: AGENTS.md (Codex, OpenCode, Cursor, Gemini CLI, Zed), CLAUDE.md (Claude Code), .cursor/rules/*.mdc (Cursor), .clinerules (Cline / Roo Code), .github/copilot-instructions.md (Copilot).
## Godot MCP
This project has the `godot-mcp` server attached (386 tools).
- Never guess a tool name. Call `search_tools` with a keyword first —
e.g. search_tools("tileset"), search_tools("animation"), search_tools("navmesh").
- On `EDITOR_NOT_REACHABLE` or `RUNTIME_NOT_REACHABLE`, call `get_status`
and tell me what's missing instead of retrying blindly.
- On `EDITOR_COMMAND_FAILED`, the editor rejected the command — read the
engine message, verify the node path / property with `editor_get_scene_tree`
or `get_class_properties`, then retry. Do not repeat the same call.
- Every `editor_*` scene change is undoable — if I say "undo that",
call `editor_undo` rather than trying to reconstruct the old state.
- Prefer the file tools (read_scene, write_script, create_resource…).
They work with Godot closed and are the fastest path.
- Use `editor_*` tools only when the change must show up in a live editor.
- Use `runtime_*` tools only after the game is actually running (F5).
- Always `read_scene` before `add_node` so the parent NodePath is correct.
- Read a script before rewriting it; never blank a file you haven't read.2. Let it look before it touches. For a first run on an unfamiliar project, add --read-only to args. The server then rejects every write tool at the boundary, so no amount of enthusiasm from the model can damage your project.
3. Two prompts worth memorizing:
get_status— what is currently reachable (editor? running game?) and how many tools are loaded.search_tools("<keyword>")— the right tool name, ranked, without burning context on a 386-item list.
Symptom | Cause & fix |
No tools show up at all | The client is in Ask/Chat mode. Switch to Agent mode — most clients don't call tools otherwise. |
Server "fails to start", no error | JSON syntax. A trailing comma or a smart quote from a copy-paste is the usual culprit — validate the file. |
| Change |
| The app launched without your shell |
Server times out on first launch |
|
|
|
Connected, but 0 tools | Tool-discovery timeout too low (notably OpenCode's 5 s default). Raise it to 30 s. |
File tools work, | The editor plugin isn't running. Run |
| The game isn't running, or the runtime autoload isn't registered. See Tool Discovery & Live Game Runtime. |
Godot can't be found | Set |
Model picks the wrong tool | Add the rules file above, and tell it to call |
Node.js too old |
|
The following examples show what you can ask your AI assistant. Each maps to one or more MCP tools (shown in parentheses).
Command | Tools Used |
"Show me the project structure" |
|
"Generate a project overview report" |
|
"What autoloads are configured?" |
|
"Check my project for broken references" |
|
"Find unused assets I should clean up" |
|
Command | Tools Used |
"Create a 2D platformer scene with a CharacterBody2D root" |
|
"Add a Cooldown Timer node under the Player" |
|
"Clone the Enemy node as Enemy2" |
|
"Connect body_entered signal from Player to _on_body_entered" |
|
"Set the Player collision shape to CapsuleShape2D" |
|
"Load the player.png texture onto the Sprite" |
|
"Search all scenes for Timer nodes" |
|
"List all Button and Label nodes" |
|
Command | Tools Used |
"Analyze the structure of player.gd" |
|
"Add a dash method to the Player script" |
|
"Search all scripts for references to 'velocity'" |
|
"Validate all GDScripts for syntax errors" |
|
"Create a new spatial shader with vertex displacement" |
|
"Validate and compile the hurricane shader" |
|
Command | Tools Used |
"Create a metallic PBR material with roughness 0.3" |
|
"List all materials grouped by type" |
|
"Change the albedo color of player_material" |
|
"Show me all .tres files in the project" |
|
Command | Tools Used |
"Show all player animations with their keyframes" |
|
"Add a position track to the idle animation" |
|
"Set a keyframe at 0.5s with value Vector2(100, 0)" |
|
"Show the AnimationTree state machine" |
|
Command | Tools Used |
"Show the audio bus layout" |
|
"Add a reverb effect to the Master bus" |
|
"Set the SFX bus volume to -6 dB" |
|
"List all .wav and .ogg files" |
|
Command | Tools Used |
"Run the game at 1280x720 and take a screenshot" |
|
"Set a breakpoint at player.gd line 42" |
|
"Step through the debugger and show local variables" |
|
"Stop the running game" |
|
"Export the project for macOS" |
|
The tables above are the building blocks; here are two complete sessions showing how the tools compose.
Walkthrough 1 — Build a player scene from scratch (no Godot needed for the file work)
1. "Create a 2D scene saved as player.tscn with a CharacterBody2D root named Player"
→ create_scene
2. "Add a CollisionShape2D with a CapsuleShape2D sized to the sprite, and a
Sprite2D loading textures/player.png" → add_node, set_collision_shape, load_sprite
3. "Create scripts/player.gd with _physics_process reading ui_left/ui_right/
ui_up/ui_down and moving at 300 px/s, then attach it to Player" → create_script, attach_script
4. "Instance Player into main.tscn at (100, 200)" → add_node (instance)
5. "Run the current scene" → editor_play_current_sceneEvery step is a real file/editor mutation — run editor_undo or press Ctrl+Z in Godot to step back through any of them.
Walkthrough 2 — Freeze and inspect the running game
1. "Run the game" → run_project / editor_play_current_scene
2. "Freeze it" → runtime_freeze
3. "Show the Player node's position, velocity, and is_on_floor()" → runtime_get_node + runtime_call_method
4. "Step one frame and show position again" → runtime_step + runtime_get_node
5. "Resume" → runtime_resumeThis is the fastest way to answer "what was the player actually doing at that exact frame?" — freeze, inspect, step, repeat.
The editor plugin enables real-time interaction with the Godot editor through two modes:
stdio mode — when MCP spawns Godot as a child process (JSON-RPC 2.0 over stdin/stdout)
TCP mode — when Godot is opened manually, the plugin listens on 127.0.0.1:9876 (loopback only). If GODOT_MCP_TOKEN or the project setting godot_mcp/auth_token is set, every connection must complete an auth handshake first. The port can be changed via the godot_mcp/editor_port project setting.
npx @yanhuifair/godot-mcp --enable-plugin -p /path/to/your/godot/projectThis installs the plugin to addons/godot-mcp/ and auto-enables it in project.godot. No manual steps required.
View & Selection: editor_get_selection editor_set_selection editor_get_open_scene editor_read_current_scene editor_get_info editor_get_rect editor_focus editor_show_in_filesystem editor_open_dock
Playback Control: editor_play editor_stop editor_run_specific_scene editor_get_running_scene_tree editor_get_performance
Edit Operations: editor_undo editor_redo editor_save editor_save_all editor_reload_scene editor_delete_selected
Scene Operations: editor_create_scene editor_instantiate_scene editor_set_main_scene editor_get_scene_changes
Node Operations: editor_add_node editor_remove_node editor_duplicate_node editor_rename_node editor_reparent_node editor_move_node editor_get_node_properties editor_set_node_properties
Scripting: editor_create_script editor_attach_script editor_run_gdscript editor_evaluate_expression
Debugging: editor_set_breakpoint editor_remove_breakpoint editor_get_breakpoints editor_debug_continue editor_debug_step editor_debug_step_over editor_debug_break editor_get_stack_trace editor_get_debug_variables
Signals: editor_connect_signal editor_disconnect_signal editor_list_node_signals
File System: editor_open_asset editor_list_filesystem editor_create_folder editor_delete_asset editor_rename_asset editor_move_asset editor_duplicate_asset editor_reimport_asset editor_get_dependencies
Project Settings: editor_get_project_setting editor_set_project_setting editor_get_editor_setting editor_set_editor_setting editor_get_project_directory
Input & Autoloads: editor_get_input_map editor_add_input_action editor_remove_input_action editor_get_autoloads editor_add_autoload editor_remove_autoload
Assets & Baking: editor_bake_lightmaps editor_bake_navigation editor_take_screenshot
Class Documentation: editor_get_class_list editor_get_method_list editor_get_class_properties editor_get_class_signals editor_get_class_doc editor_search_help
Camera & Viewport: editor_get_camera editor_set_camera editor_toggle_grid editor_toggle_snap
Other: editor_get_recent_scenes editor_simulate_key editor_get_plugin_list editor_enable_plugin editor_disable_plugin editor_get_errors editor_clear_errors editor_health_check
Most MCP servers can only touch the editor. Godot MCP can also drive the game you are actually playing — a tier no other public Godot MCP offers. This enables AI-driven playtesting, runtime-state debugging, automated gameplay verification, and live screenshots.
The runtime bridge is a separate, lightweight autoload — it does not modify the editor plugin. Add it once per project:
Make sure the editor plugin is installed (npx @yanhuifair/godot-mcp --enable-plugin -p .). The runtime bridge script ships inside the same addons/godot-mcp/ folder.
In the Godot editor, open Project → Project Settings → Globals → Autoload.
Add addons/godot-mcp/runtime_bridge.gd with the autoload name godot_mcp_runtime and enable it.
Run the game from the editor (F5). The autoload prints [godot-mcp-runtime] Listening on 127.0.0.1:9877 to the output log.
Security: the bridge binds
127.0.0.1only — it is never reachable from the LAN. It runs withprocess_mode = PROCESS_MODE_ALWAYS, so pausing the game (viaruntime_freezeor the editor) does not stop the bridge from receiving commands.It also refuses to start in an exported build. The bridge can call arbitrary methods on any node, so shipping it would be a backdoor. It only listens when
OS.has_feature("editor")is true — i.e. when the game is run from the editor. If you forget to remove the autoload before exporting, it stays dormant instead of opening a port. To drive an exported build in CI, setGODOT_MCP_RUNTIME=1in the environment.
Tool | Description |
| Check if the live-game runtime bridge is reachable. |
| Read the running game scene tree (live, inside the played game). |
| Read live properties of a node in the running game. |
| Set properties on a node in the running game (live mutation). |
| Call a method on a node in the running game. |
| Emit a signal on a node in the running game. |
| Inject a key input event into the running game (keycode + press/release). |
| Pause (freeze) the running game. |
| Resume (unpause) the running game. |
| Advance the running game by N frames deterministically while paused (frame stepping). |
| Capture a screenshot of the running game viewport. |
"Run the game, freeze it, then step 5 frames and screenshot"
→ runtime_ping → runtime_freeze → runtime_step { frames: 5 } → runtime_screenshot
"Set the Player's health to 0 and emit died"
→ runtime_set_node { path: "Player", properties: { "health": "0" } }
→ runtime_emit_signal { path: "Player", signal: "died" }If the runtime tools return a RUNTIME_NOT_REACHABLE error, run get_status — it reports whether the autoload is reachable and how to enable it.
With 386 tools, guessing the right name wastes tokens. Two discovery tools help:
Tool | Description |
| Search all tools by keyword/description to discover the right tool name. AND-combines space-separated words; name matches rank higher. |
| System status / diagnostics: editor bridge, live-game runtime bridge, and tool count. Use to debug connection issues. |
"Find tools that deal with collision shapes" → search_tools { keyword: "collision shape" }
"What subsystems are available right now?" → get_statusClick each category to expand and see all tools with descriptions.
Tool | Description |
| Get selected nodes in editor. |
| Select node in editor. |
| Get currently open scene path. |
| Read live editor scene tree. |
| Get editor status info. |
| Get editor window dimensions. |
| Bring the Godot editor window to the foreground. |
| Reveal a file in the FileSystem dock. |
| Open a dock: filesystem, inspector, scene, output. |
| Play project from editor. |
| Stop playing in editor. |
| Run a specific scene (not just main). |
| Get the live scene tree while the game is running. |
| Get FPS, draw calls, memory usage while game is running. |
| Undo the last scene action (including every MCP scene mutation) and report which action was undone. |
| Redo the last undone scene action and report which action was redone. |
| Save current scene in editor. |
| Save all open scenes. |
| Save and reload current scene. |
| Delete currently selected nodes. |
| Create and open a new scene in the editor. |
| Instantiate a PackedScene into the current scene. |
| Set the project main scene. |
| Check unsaved changes plus the last action name and whether undo/redo are available. |
| Add a node to the currently open scene in editor. |
| Remove a node from the currently open scene. |
| Duplicate a node with children, scripts, and signals. |
| Rename a node in the editor. |
| Move a node to a new parent. |
| Move a 2D/3D node to a new position. |
| Read all editor-visible properties of a node. |
| Set multiple properties on a node at once. |
| Create and open a new GDScript in the editor. |
| Attach a script to a node in the editor. |
| Execute arbitrary GDScript code in editor context. |
| Evaluate a GDScript expression in debugger/editor context. |
| Set a breakpoint in a script. |
| Remove a breakpoint from a script. |
| List all breakpoints. |
| Resume execution in debugger. |
| Step into next line in debugger. |
| Step over current line in debugger. |
| Stop execution (break) in debugger. |
| Get current call stack from debugger. |
| Get local variables from debugger. |
| Connect a signal between nodes in the editor. |
| Disconnect a signal between nodes. |
| List signals and their connections on a node. |
| Open an asset in editor. |
| List files and directories in the editor filesystem. |
| Create a directory in the project via editor filesystem. |
| Delete a file or folder via editor. |
| Rename a file via editor filesystem. |
| Move a file to a new location via editor. |
| Duplicate a file via editor filesystem. |
| Force reimport of an asset. |
| Get all resource dependencies for a file. |
| Read a project setting via editor API. |
| Set a project setting via editor API (auto-saves). |
| Read an editor preference value. |
| Set an editor preference. |
| Get project res:// and user:// paths. |
| Read the Input Map via editor API. |
| Add an input action via editor API. |
| Remove an input action via editor API. |
| List autoload singletons via editor API. |
| Add an autoload singleton via editor API. |
| Remove an autoload singleton via editor API. |
| Trigger lightmap baking. |
| Bake navigation meshes for all NavigationRegion nodes in current scene. |
| Capture the editor viewport as a PNG. |
| List all Godot classes, optionally filtered. |
| List all methods of a Godot class. |
| List all editor-visible properties of a class. |
| List all signals of a Godot class. |
| Open Godot documentation for a class in browser. |
| Search Godot documentation in browser. |
| Get the 3D editor viewport camera position. |
| Set the 3D editor viewport camera position. |
| Toggle 3D grid visibility. |
| Toggle 3D snap mode. |
| List recently opened scene paths. |
| Simulate a key press in the editor (e.g. F5 to run, Ctrl+S to save). |
| List all installed editor plugins with enabled state. |
| Enable a named editor plugin. |
| Disable a named editor plugin. |
| Get current editor error/log list. |
| Clear the editor error list. |
| Check if the Godot editor plugin is reachable. |
Tool | Description |
| Read a .tscn scene file. |
| Create a new scene from template. |
| Apply batch operations to a scene. |
| List all .tscn scene files. |
| Full-text search in .tscn content. |
| Analyze inter-scene dependencies. |
| Add a node to a scene. |
| Remove a node from a scene. |
| Modify node properties or rename. |
| Deep-clone a node in a scene. |
| Rename a node in a scene. |
| Attach a script to a node. |
| Connect a signal between nodes. |
| Disconnect a signal. |
| Set node position (2D/3D auto-detect). |
| Set node rotation (2D/3D). |
| Set node scale (2D/3D). |
| Apply a transform to a node. |
| Set collision shape for CollisionShape node. |
| Load a texture onto a Sprite2D node. |
| List Control-derived UI nodes. |
| Search nodes across scenes by type/property. |
Tool | Description |
| List files and directories in the Godot project. |
| Read and parse project.godot. |
| Write a config value to project.godot. |
| Read export presets from export_presets.cfg. |
| Create an export preset in export_presets.cfg (Windows Desktop/Linux/macOS/Android/iOS/Web). |
| Update fields/options of an existing export preset (by name or index). |
| Remove an export preset and renumber the remaining ones. |
| Read input map with key bindings. |
| Create a new input action. |
| Remove an input action. |
| Add key/mouse/joypad binding to action. |
| List all autoload singletons. |
| Add an autoload entry. |
| Remove an autoload entry. |
| Search for text across project files. |
| Delete a file with .bak backup. |
| Move/rename a file within project. |
| Create a directory in project. |
| Duplicate a scene file. |
| Duplicate a .tres resource. |
| Generate comprehensive project overview. |
| Find orphaned project files. |
| Validate project for broken refs, empty UIDs. |
| List all node groups across scenes. |
Tool | Description |
| Read a script file with line numbers. |
| Write content to a script file. |
| Create a new script from template. |
| List all script files grouped by type. |
| Analyze GDScript structure. |
| Search in scripts with function context. |
| Validate GDScript for common issues. |
| Append a function to GDScript. |
| Add a signal declaration to GDScript. |
| Add @export variable to GDScript. |
| Read a .gdshader file. |
| Create a new .gdshader from template. |
| List all .gdshader files. |
| Write content to a .gdshader. |
| Validate .gdshader for syntax issues. |
| Compile (reimport) a .gdshader via Godot editor. |
| List VisualShader graph files. |
| Read a VisualShader graph. |
| Read a .gdshaderinc file. |
| Create a .gdshaderinc file. |
| List all .gdshaderinc files. |
Tool | Description |
| List AnimationPlayers and animations. |
| Read animation tracks and keyframes. |
| Create Animation .tres resource. |
| Set animation parameter. |
| Add animation library to player. |
| Add track to animation. |
| Set keyframe on track. |
| Remove track from animation. |
| Read AnimationTree with state machine. |
| Set AnimationTree parameter. |
Tool | Description |
| Detect installed Godot version. |
| Launch Godot editor with project. |
| Run the Godot project. |
| Stop all running Godot processes. |
| Export project via Godot CLI preset. |
| Capture screenshot of running game. |
| Read Godot process output. |
| Check if Godot editor is running. |
| Scan directory for Godot projects. |
Tool | Description |
| Create 3D mesh resource: Box, Capsule, Cylinder, Plane, Sphere, Torus, etc. (11 types). |
| List PointLight2D/DirectionalLight2D nodes with energy and shadow settings. |
| Set a parameter on a 2D light node. |
| Create a VehicleBody3D with VehicleWheel nodes for car physics. |
| List VehicleBody3D nodes with wheel counts. |
| Create a SpringArm3D for smooth camera follow. |
| List SpringArm3D nodes with spring length and collision settings. |
| List Decal nodes with size and texture info. |
| List OccluderInstance3D and OcclusionPolygon2D nodes. |
| List Marker2D/Marker3D position markers across scenes. |
| Read audio file info: format, size, loop, bitrate from .import config. |
| List AudioListener2D/3D nodes for spatial audio positioning. |
| Create CameraAttributes (Practical or Physical) for 3D camera DOF and auto-exposure. |
| Create a SpriteFrames .tres resource with named animations. |
| List AnimatedSprite nodes and their SpriteFrames resources. |
| List SoftBody3D nodes with mass and stiffness. |
| List GridMap nodes with cell size and mesh library references. |
| Create a GridMap node for 3D tile-based level design. |
Tool | Description |
| Read a .tres resource file. |
| List all resource files. |
| Create a resource from template. |
| Write properties to a resource. |
| List materials grouped by type. |
| Read material with PBR formatting. |
| Set a single material parameter. |
| Read Theme resource with type-aware grouping. |
Tool | Description |
| Read AudioBusLayout. |
| List audio files by format. |
| Create AudioBusLayout. |
| Add audio bus to layout. |
| Remove audio bus. |
| Add effect to audio bus. |
| Set bus volume in dB. |
Tool | Description |
| Create a new VisualShader .tres graph file. |
| Add a node to a VisualShader graph (40+ types: constants, math, textures, effects). |
| Remove a node from a VisualShader graph by index. |
| Connect two node ports in a VisualShader graph. |
| Disconnect two node ports in a VisualShader graph. |
| Set a parameter on a VisualShader node (constant, expression, operator, etc.). |
| List all VisualShader node types organized by category with I/O counts. |
| Get default ports and parameters for a specific VisualShader node type. |
Tool | Description |
| Search all tools by keyword/description to discover the right tool name. Use this instead of guessing among 350+ tools. |
| System status / diagnostics: editor bridge, live-game runtime bridge, and tool count. Use to debug connection issues. |
Tool | Description |
| Check if the live-game runtime bridge is reachable. |
| Read the running game scene tree (live, inside the played game). |
| Read live properties of a node in the running game. |
| Set properties on a node in the running game (live mutation). |
| Call a method on a node in the running game. |
| Emit a signal on a node in the running game. |
| Inject a key input event into the running game. |
| Pause (freeze) the running game. |
| Resume (unpause) the running game. |
| Advance the running game by N frames deterministically while paused (frame stepping). |
| Capture a screenshot of the running game viewport. |
Domain (11): read_curve, create_curve, read_gradient, create_gradient, list_paths, read_path, list_skeletons, read_skeleton, read_reflection_probe, read_multimesh, create_noise_texture
Nodes (8): read_character_body, read_animated_sprite, read_audio_player, read_video_player, read_parallax, read_rich_text, read_container, read_tab_container
Utility (6): list_all_signals, read_project_icon, read_stylebox, create_atlas_texture, list_popups, generate_cohesion_report
Rendering (5): read_mesh_instance, set_mesh_surface_material, read_viewport, read_area, read_raycast
Environment (4): read_environment, list_environments, create_environment, set_environment_param
Inspector (5): list_cameras, read_camera, list_lights, set_light_param, read_particles
Physics (4): list_physics_materials, read_physics_material, create_physics_material, read_collision_layers
Import (3): read_import_config, list_import_files, write_import_config
TileMap (3): list_tilesets, read_tileset, read_tilemap
Navigation (3): list_nav_regions, read_nav_region, create_nav_mesh
Translation (8): list_translations, read_translation, create_translation, write_translation, add_translation_key, create_po_translation, register_translation, unregister_translation
Joints (3): create_joint, set_joint_param, list_joints
UID (3): get_uid, update_project_uids, list_missing_uids
2D Geometry (2): create_collision_polygon, set_shape_points
Diff (2): diff_scene, diff_resource
Other (4): read_gdextension, list_csproj, create_world, read_texture_info
Format | Extension | Operations |
Scene |
| Read, write, create, edit |
Script |
| Read, write, create, validate, analyze |
Script |
| Read, write, create |
Shader |
| Read, write, create, validate, compile |
Shader Include |
| Read, write, create |
VisualShader |
| Read, list, graph editing |
Resource |
| Read, write, create (14 templates) |
Resource |
| Not supported (binary) |
Config |
| Read, write |
Config |
| Read |
Import |
| Read, write |
Environment |
| Read, write, create (4 presets) |
Animation |
| Read, create, modify |
AudioBus |
| Read, write, create |
PhysicsMaterial |
| Read, write, create |
TileSet |
| Read, list |
Translation |
| Read, create |
npm install # Install dependencies
npm run build # Build TypeScript to dist/
npm run dev # Dev mode (tsx hot reload)
npm test # Run vitest suite (197 tests: 127 runnable + 70 integration requiring a live Godot project); node test/test_all.mjs for 176 legacy checks
npm run test:watch # Watch mode
npm run check:godot # Load every fixture in a real headless Godot and verify
# ext_resource paths, UIDs and SubResource refs (needs Godot installed)Flag | Description |
| Path to Godot project root |
| Path to Godot binary (optional) |
| Transport mode: |
| HTTP port (default: 3000) |
| HTTP bind address (default: 127.0.0.1) |
| Copy editor plugin to target Godot project |
| Install and auto-enable the editor plugin |
| Reject 218 write/side-effect tools (security mode) |
| Disable SSE endpoint |
| Disable Streamable HTTP endpoint |
| Show help |
Runtime: Node.js >= 18
Language: TypeScript 5.5
MCP SDK: @modelcontextprotocol/sdk ^1.29
Schema Validation: Zod ^3.24
HTTP Server: Express ^5.2
Test: Vitest ^2.0
Transport: stdio (default), SSE, Streamable HTTP
npm run vsix
# Output: godot-mcp-1.11.2.vsixInstall in VS Code:
code --install-extension godot-mcp-1.11.2.vsixBinary .res files are not parseable — use .tres (text format) for editable resources
Godot CLI tools (launch_editor, run_project, export_project) require the Godot Engine binary
edit_scene uses text manipulation on .tscn; complex refactors may require manual verification
Screenshots depend on OS-native screenshot utilities
Do I need to keep Godot open? No. Every file-based tool — scenes, resources, scripts, shaders, project settings — uses native parsers and runs instantly against files on disk. Only the live editor tools (123) and live game runtime tools (11) need Godot running, and the server can launch it for you automatically.
Does it support Godot 3? No. Godot 4.x only. Godot 3's file formats and editor APIs differ too much to support cleanly.
Which AI clients work with it? Any MCP-compatible client. Verified with Claude Desktop, Claude Code, Cursor, VS Code (Copilot), Windsurf, Codex, Cline, Roo Code, Aider, Cody, Goose, and Continue.
How does the AI pick the right tool out of 386?
Use search_tools — it ranks the catalog by keyword against tool names and descriptions, so the AI can find add_audio_bus_effect without loading all 386 schemas into context. get_status reports which subsystems (editor bridge, game runtime) are currently reachable.
What makes the runtime tools different from the editor tools?
Editor tools talk to the Godot editor. Runtime tools talk to the running game through a lightweight autoload on 127.0.0.1:9877. That's what enables freezing the game, stepping an exact number of frames, and screenshotting a precise gameplay moment.
Is it safe to let an AI edit my project?
Destructive file operations write .bak backups, tools are classified read-only vs. write, and every failure returns a typed error code with a repair hint rather than silently corrupting a file. Use version control anyway.
Godot MCP · Godot MCP server · Model Context Protocol Godot · Godot AI assistant · Godot AI agent · Godot Engine 4 MCP · GDScript AI · AI game development · Godot Copilot · Claude Godot integration · Cursor Godot · VS Code Godot MCP · Windsurf Godot · Cline Godot · Godot automation · Godot scene editing API · .tscn parser · .tres parser · Godot shader AI · VisualShader automation · Godot debugging AI · Godot runtime inspection · AI game engine tooling · MCP server for game engines · Godot编辑器 AI · Godot 自动化 · Godot 智能体
AGPL-3.0-or-later
Add animation library to player.
| Name | Required | Description | Default |
|---|---|---|---|
| animations | No | Reserved UIDs of existing Animation sub-resources | |
| scene_path | Yes | Path to .tscn scene file | |
| animation_name | Yes | Name for the new animation library |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Add,' implying a mutation, but does not explain whether existing libraries are overwritten, whether permissions are needed, or what side effects occur on the scene file. This is insufficient for an agent to understand the operation'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 a single concise sentence with no fluff, and the key action is front-loaded. It is efficient but sacrifices important completeness, which is a separate concern.
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 that modifies a scene file, the description is severely incomplete. It does not clarify what 'player' refers to, how the optional 'animations' parameter integrates, or what the outcome of the operation is. With no output schema and no annotations, this is inadequate for a tool of this 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?
The input schema fully describes all three parameters, including scene_path as a .tscn path, animation_name as the new library name, and animations as reserved UIDs. With 100% schema coverage, the description need not add parameter details, but it also does not offer any context beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action (add animation library) and a target (player), but 'player' is ambiguous without specifying 'AnimationPlayer' or how it relates to the scene_path. It is distinguishable from sibling tools like add_animation_track because it mentions 'library', but the lack of domain context makes it less 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 guidance is provided about when to use this tool versus alternatives such as create_animation or add_animation_track. There is no mention of prerequisites (e.g., whether an AnimationPlayer must already exist in the scene) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add track to animation.
| Name | Required | Description | Default |
|---|---|---|---|
| interp | No | Interpolation method | linear |
| scene_path | Yes | Path to .tscn scene file | |
| track_path | Yes | Node property path to animate (e.g. ".:position", "Sprite2D:modulate") | |
| track_type | No | Track type | value |
| animation_name | Yes | Name of the animation in AnimationPlayer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, yet it only states 'Add track to animation.' It fails to mention that this modifies a scene file, whether the operation can overwrite existing tracks, whether it is reversible, or what the return value indicates. This is a mutation tool with 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 concise and front-loaded, with no redundant words. However, at just five words, it is under-specified and does not earn its place as the sole descriptive element for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the comprehensive schema, the description lacks essential context: prerequisites, consequences, and procedural steps. For a 5-parameter mutation tool with no annotations and no output schema, the description is inadequate for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear parameter descriptions, including helpful examples for track_path. The tool description adds nothing beyond the schema, so the 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 names the action ('Add'), the object ('track'), and the target ('animation'), which distinguishes it from sibling tools like create_animation and remove_animation_track. However, it lacks specifics about the Godot AnimationPlayer context, making it slightly less than fully precise.
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, no prerequisites, and no mention that the animation must already exist. There is no context about the intended workflow or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add audio bus to layout.
| Name | Required | Description | Default |
|---|---|---|---|
| send_to | No | Send target bus | Master |
| bus_name | Yes | New bus name | |
| volume_db | No | Volume in dB | |
| layout_path | No | Path to AudioBusLayout .tres | default_bus_layout.tres |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior, but it only states the action without any side effects. It does not mention whether the layout file is modified in-place, what happens if the bus already exists, whether missing files are created, or error conditions. This is a significant transparency gap 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 concise sentence with no filler words, making it appropriately front-loaded. However, it is so terse that it sacrifices informative content, but conciseness itself is achieved.
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 4-parameter tool with no annotations and no output schema, yet the description is only one short sentence. It fails to explain the concept of 'layout', the purpose of parameters beyond schema names, how the tool integrates with other audio bus operations, or what result to expect. The description is far from sufficient for an agent to confidently invoke the 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 description coverage is 100%, with clear descriptions for each parameter (bus_name, send_to, volume_db, layout_path). The description itself adds no additional parameter meaning beyond the schema, which is acceptable given the high schema coverage. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add audio bus to layout' has a specific verb ('Add') and resource ('audio bus') targeting a layout, making the core purpose clear. It is distinct from siblings like create_audio_bus_layout and add_bus_effect, though it does not explicitly name alternatives or clarify whether it modifies an existing layout or creates one implicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing an existing audio bus layout, nor does it distinguish when to use add_audio_bus instead of create_audio_bus_layout or set_bus_volume.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an autoload entry.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Autoload singleton name | |
| path | Yes | Script path (e.g. "res://globals.gd") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'Add an autoload entry' and discloses nothing about side effects, persistence, required permissions, or reversibility. For a mutation tool, this is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous words. It is front-loaded with the action verb and object, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers parameter meanings, the description lacks essential context about the operation's effect and how it relates to similar tools. Without annotations or an output schema, the agent is left without a complete understanding of the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes descriptions for both parameters ('Autoload singleton name' and 'Script path'), achieving 100% coverage. The description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'add' and the resource 'autoload entry', which clearly states the core function. However, it does not differentiate from sibling tools like 'editor_add_autoload', and it is unclear whether this operates at the project or editor level.
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 given about when to use this tool versus alternatives such as 'editor_add_autoload' or 'remove_autoload'. There is no mention of prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add effect to audio bus.
| Name | Required | Description | Default |
|---|---|---|---|
| bus_index | Yes | Bus index | |
| effect_type | Yes | Effect type | |
| layout_path | No | default_bus_layout.tres | |
| effect_params | No | Effect parameters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Add effect' without mentioning side effects, prerequisites, reversibility, or impact on the bus layout. For a mutation operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no irrelevant or redundant content. It is efficient, though it sacrifices impactful context. As a result, it is appropriately sized for a simple statement of purpose, but could be more useful with additional detail.
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 parameters, no output schema, and no annotations, the description is far too sparse. It lacks usage guidance, behavioral details, and parameter clarification. This is insufficient for an agent to confidently understand the tool's full context and requirements.
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 description adds no meaning beyond the input schema. Schema coverage is 75% (moderate), and the description does not compensate for the undocumented layout_path parameter. The existing schema descriptions are also minimal, and the description provides no additional explanatory 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?
The description clearly states the action 'Add' and the target 'effect to audio bus.' This distinguishes it from siblings like add_audio_bus (which adds a bus) and set_bus_volume (which sets volume). The specific verb+resource combination unambiguously conveys the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as add_audio_bus or create_audio_bus_layout. There is no context for selecting this over related tools, nor any exclusions or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add key/mouse/joypad binding to action.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Keyboard key name (e.g. "Space", "A", "Escape") — uses physical keycode | |
| action | Yes | Existing input action name | |
| device | No | Device ID (-1 for all) | |
| joypad_axis | No | Joypad axis (e.g. "left_x", "right_trigger") | |
| mouse_button | No | Mouse button index (1=left, 2=right, 3=middle) | |
| joypad_button | No | Joypad button index |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the core operation ('Add...'), without revealing whether existing bindings are overwritten or appended, what happens if the action doesn't exist, or any validation/error behavior. This is a significant gap 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 of six words, front-loaded with the verb and object. Every word earns its place; there is no fluff or 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?
The tool has 6 parameters with rich schema explanations, but the description is minimal and doesn't clarify key usage constraints such as exactly one input source (key, mouse, or joypad) should be specified, or what happens with mutual exclusivity. No output schema or annotations exist, so the description alone doesn't fully complete the picture, though the simple purpose is understandable.
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% for all parameters, with each parameter having a detailed description (e.g., key names, mouse button indices, device IDs). The tool description adds no additional parameter semantics, so the baseline of 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and names a specific resource ('key/mouse/joypad binding to action'), clearly distinguishing it from sibling tools like 'editor_add_input_action' (which adds an action) and 'remove_input_action' (which removes an action). The scope is exact and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for adding key/mouse/joypad bindings to an existing action, but it provides no explicit guidance on when to use this vs alternatives (e.g., 'write_input_action') and no exclusions or prerequisites (e.g., action must exist). Usage context is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a node to a scene.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | New node name | |
| type | Yes | Node type (e.g. "CharacterBody2D", "Timer", "CollisionShape3D") | |
| groups | No | Initial groups | |
| properties | No | Initial properties | |
| scene_path | Yes | Path to .tscn file | |
| parent_path | No | Parent node path (default: root level) | . |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure, but it fails to mention side effects (e.g., modifying the .tscn file), prerequisites (e.g., scene must exist, node type must be valid), or failure modes. This is a mutation tool with 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 a single, concise sentence with no wasted words. However, it is so brief that it lacks useful context, making it less effective than a slightly longer description that includes guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with six parameters and no output schema or annotations, this description is severely inadequate. It does not clarify return values, side effects, node placement, or any limitations, providing insufficient context for an agent to invoke the tool reliably.
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 all six parameters have descriptions in the schema. The tool description adds no additional meaning beyond that, which is acceptable but does not enhance parameter understanding.
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 'Add a node to a scene' uses a clear verb and resource, indicating the core operation. However, it does not distinguish from sibling tools like editor_add_node or clone_node, both of which could appear to add nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as editor_add_node, modify_node, or remove_node. The description merely states the action without any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add @export variable to GDScript.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .gd script file | |
| var_name | Yes | Variable name | |
| var_type | No | Type hint | |
| export_hint | No | Export hint (e.g. "int, 0, 100") | |
| default_value | No | Default value |
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, omitting side effects (e.g., modifies the script file), behavior on conflicts, formatting, or any error conditions. A mutation tool needs more 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?
The description is a single short sentence with no filler words. It is front-loaded and efficient, doing exactly what it needs for purpose clarity.
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, no annotations, and moderate complexity, the description is too sparse. It lacks behavioral details like whether it inserts into an existing script, how it handles duplicate variables, or what outcome the user can 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%, and each parameter has a clear description (path, var_name, var_type, export_hint, default_value). The description itself adds no extra meaning beyond this, so baseline 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 'Add @export variable to GDScript' clearly states a specific verb ('Add') and resource ('@export variable' in GDScript). This distinguishes it from sibling tools like add_script_function and add_script_signal, which target different constructs.
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 mention when to use this tool versus alternatives, nor any prerequisites (e.g., script must exist, variable must not already exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append a function to GDScript.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Function body | pass |
| path | Yes | Path to .gd script file | |
| params | No | Parameter names (e.g. ["delta: float"]) | |
| func_name | Yes | Function name | |
| after_func | No | Insert after this function | |
| return_type | No | Return type hint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It states only that the tool appends a function, but does not reveal that this modifies the file on disk, whether it checks for duplicate function names, how insertion order works, or any side effects. The 'append' wording implies mutation, but without safety or side-effect details, the description falls short 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 concise sentence with no redundant words. It is front-loaded with the core action, but it is arguably too terse for a tool with six parameters. However, conciseness is not penalized heavily because it is efficient; the lack of detail is addressed in other dimensions.
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 six parameters, no output schema, and no annotations, the single-sentence description is insufficient. It does not explain the return value, file modification behavior, interaction with the 'after_func' parameter, or how it relates to sibling tools like validate_script or write_script. The description leaves significant gaps for complex tool 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 all six parameters have descriptive text in the schema. The tool description itself adds no parameter information, but since the schema already documents each parameter (e.g., path, func_name, body), the baseline of 3 is appropriate. The description does not compensate or add extra meaning 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 'Append a function to GDScript' uses a specific verb ('Append') and identifies the resource ('function to GDScript'). It clearly indicates the tool's core action, distinguishing it from related tools like add_script_signal or add_script_export, though it does not explicitly name these alternatives.
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 such as create_script, write_script, or add_script_export. It lacks context about prerequisites, such as the script file existing or the function not already being present, and offers no 'when to use' or 'when not to use' information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a signal declaration to GDScript.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .gd script file | |
| params | No | Signal parameters | |
| signal_name | Yes | Signal name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects like file modification, error conditions, or whether existing signals are checked for duplicates, which 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, concise sentence that immediately conveys the tool's purpose without any filler or redundant information, perfectly 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?
For a simple 3-parameter tool with fully documented schema, the description is minimally adequate. However, the lack of annotations and absence of side-effect context (e.g., file mutation, script existence requirements) leaves some gaps in completeness, warranting a mid-range score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents all three parameters (path, params, signal_name). The description adds no additional parameter nuance, but the baseline of 3 is appropriate given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Add') and resource ('signal declaration to GDScript'). It distinguishes from sibling tools like add_script_function (adds functions) and connect_signal (connects signals), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or comparison with related tools such as connect_signal or add_script_export, leaving the agent without contextual decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a node to a VisualShader graph. 40+ node types available (constants, math, textures, effects).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to VisualShader .tres file | |
| params | No | Override default params | |
| position | No | [x, y] position on graph canvas (default: auto-place) | |
| node_type | Yes | Node type shorthand (e.g. "color_constant", "add", "texture2d", "fresnel"). Use list_shader_node_types to see all options. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects. It only states that a node is added, without explaining that the .tres file is modified, that invalid node types may error, how nodes are connected (or not), or whether auto-placement occurs. This is a significant transparency gap for a mutating 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, front-loaded sentence that clearly communicates the core action and the breadth of options. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 100% schema coverage, the tool operates in a complex domain (VisualShader graph editing) with no output schema and no annotations. The description does not cover prerequisites, failure modes, return behavior, or how nodes relate to connection/param-setting operations. It is too terse for the tool's 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%, so the baseline is 3. The description adds a small extra: '40+ node types available (constants, math, textures, effects)' which gives context for node_type but does not explain the format of params or position beyond the schema. The value added is marginal.
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 a node') and the resource ('VisualShader graph'), distinguishing it from sibling tools like remove_shader_graph_node or set_shader_node_param. The mention of '40+ node types' provides concrete 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 is provided on when to use this tool versus alternatives. It does not mention prerequisites like an existing .tres file, nor does it reference list_shader_node_types (which appears in the schema but not the description). There are no exclusions or alternative tool names in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a control type (font size/color) to a Theme.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Control type to add (e.g. "Button", "Label", "Panel") | |
| font_size | No | Default font size for this type | |
| font_color | No | Default font color (e.g. "Color(1, 1, 1, 1)") | |
| theme_path | Yes | Path to .tres Theme file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It implies a mutating add operation but doesn't state whether the .tres file is modified in place, whether the theme must already exist, what happens if the type already exists, or what the function returns. This is a significant gap for a tool that modifies resources.
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 fluff. It earns its place by stating the core purpose, but it is under-specification rather than genuinely concise; however, for the length, it is appropriately sized.
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 parameters, no annotations, and no output schema, the description is incomplete. It does not explain the effect on the theme file, error conditions, or any return value. The schema covers parameters, but the tool's usage context and post-conditions are absent, making it insufficient for an agent to fully anticipate the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema fully documents the parameters. The description adds minimal extra meaning with the phrase 'font size/color,' but this is already present in the parameter descriptions. Baseline 3 is appropriate because the description does not need to compensate for schema gaps.
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 a control type (font size/color) to a Theme. The verb 'add' and resource 'Theme' are specific, and the parenthetical clarifies what a control type involves. However, it doesn't explicitly distinguish among the many sibling 'add_*' tools, though the theme-specific resource and parameters do provide some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the Theme must exist), exclusions, or related tools like create_theme or read_theme. The agent is left with no context for choosing this tool over a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an atlas source (texture) to a TileSet.
| Name | Required | Description | Default |
|---|---|---|---|
| margin | No | Atlas margin [x, y] | |
| source_id | No | Source index (auto-detected if omitted) | |
| tile_size | No | Tile size [x, y] in pixels | |
| separation | No | Atlas separation [x, y] | |
| texture_path | Yes | Path to the tileset atlas texture (e.g. "res://textures/tiles.png") | |
| tileset_path | Yes | Path to .tres TileSet file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It identifies 'Add' as a mutation but does not explain that it modifies a .tres file, whether it requires an existing TileSet, how source_id auto-detection works (already in schema), what happens to existing sources, or error/return behavior. This significant gap for a mutating tool leaves the agent uncertain about 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 a single, focused sentence with no redundancy. It conveys the core purpose efficiently, earning a perfect score for 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?
Despite having 6 parameters and no annotations or output schema, the description provides only a minimal statement of purpose. It does not cover when to use the tool, behavioral expectations, prerequisites, or return values. For a tool with this complexity, the description is incomplete and leaves the agent without sufficient 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%, so the schema already documents all parameters. The description adds minimal value beyond the schema by clarifying that texture_path refers to an atlas texture, but this is also in the schema. Baseline of 3 is appropriate as the description does not compensate for gaps but also does not introduce confusion.
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 'Add an atlas source (texture) to a TileSet' uses a specific verb (Add) and clearly identifies the resource (atlas source/texture) and target (TileSet). It distinguishes itself from sibling tools like create_tileset, read_tileset, and create_atlas_texture by explicitly stating it adds an atlas source to an existing TileSet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (adding a texture atlas to a TileSet) but provides no explicit guidance on when to use this tool versus alternatives like create_atlas_texture or create_tileset. It does not mention prerequisites, such as requiring an existing TileSet, or contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append a translation key/row to an existing CSV.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | New translation key to add | |
| path | Yes | Path to .csv translation file | |
| translations | No | Optional map of language code to value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses that it modifies an existing CSV by appending, but provides no details about error handling, duplicate keys, file format requirements, or reversibility.
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, front-loaded with the action, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool, the description covers the core purpose and precondition, but lacks details on behavior with existing keys, return values, and the optional 'translations' parameter usage, which would be needed for agent decision-making.
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 covers 100% of parameters with descriptions, so baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Append' and identifies the resource: 'translation key/row to an existing CSV'. It clearly distinguishes from sibling tools like create_translation or write_translation which create or write whole translation files.
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?
It implies the tool is for adding a key to an existing translation file, but does not explicitly state when to use it vs alternatives such as create_translation or write_translation. No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach a script to a node.
| Name | Required | Description | Default |
|---|---|---|---|
| node_path | Yes | Node path to attach script to | |
| scene_path | Yes | Path to .tscn file | |
| script_path | Yes | Script resource path (e.g. "res://scripts/player.gd") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It does not mention side effects, such as modifying the .tscn file, whether an existing script is replaced, or whether the script must already exist. The description is too minimal to convey these important 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 sentence, extremely concise and front-loaded. It wastes no words. However, it is so sparse that it provides almost no context, but from a structural standpoint, it is appropriately sized for the simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple operation and full schema coverage, the description lacks essential context. It does not differentiate from editor_attach_script, does not explain what 'attach' entails (e.g., modifying scene file), and does not mention any prerequisites. The tool may be usable, but the description alone is incomplete for an agent to select it with confidence.
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 provides detailed descriptions for all three parameters (node_path, scene_path, script_path) with 100% coverage, so the description adds little beyond what is already structured. The description does not clarify relationships between parameters or add usage guidance for them. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Attach a script to a node.' It identifies the verb and resource, and the parameters make the intent clear. However, it does not distinguish itself from the sibling tool 'editor_attach_script', which likely performs a similar operation.
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?
There is no guidance on when to use this tool versus alternatives like editor_attach_script or add_script_export. No prerequisites, such as the node existing or the script already being present, are mentioned. The description provides no context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture screenshot of running game.
| Name | Required | Description | Default |
|---|---|---|---|
| delay | No | Delay in seconds before capture | |
| output_path | No | Output file path for the screenshot | screenshot.png |
| window_title | No | Window title to capture (default: capture Godot window) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It only repeats the tool's name and basic action without disclosing that a file is written, that there is a default delay, that window_title selects the source window, or what happens if no game is running. This is no richer than the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no wasted words. It is front-loaded with the purpose. However, its brevity borders on under-specification, but that is addressed in other dimensions. As far as conciseness itself, it earns a high score for efficiency, though not a perfect 5 because it lacks any structural aid (e.g., examples or use-case hints).
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 behavioral context, such as return format, file output behavior, or fallback behavior. The tool has 3 optional parameters and would benefit from explaining what happens when parameters are omitted. The description is insufficient for an agent to understand side effects or edge cases.
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 each parameter (delay, output_path, window_title) already has a meaningful schema description. The description adds no additional parameter semantics, but the baseline is 3 because the schema carries the full burden. The description does not introduce any new meaning or clarify parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Capture screenshot of running game.' It is unambiguous about the core action, but it does not specify what exactly is captured (e.g., the game window, the full screen) or differentiate from sibling tools like runtime_screenshot or editor_take_screenshot. This fits the 'clear but no sibling differentiation' category.
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 such as editor_take_screenshot (editor view) or runtime_screenshot (similar runtime capture). There is no mention of prerequisites (e.g., running game) or exclusions. The only implied usage is 'running game,' but it is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep-clone a node in a scene.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | New name (default: "name_copy") | |
| scene_path | Yes | Path to .tscn file | |
| parent_path | No | New parent (default: same as source) | |
| clone_source | Yes | Source node path to clone |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose side effects and constraints. 'Deep-clone' implies a write operation but does not specify what happens to the scene file, whether changes are saved, or what the return value is. It lacks details about undo behavior, name collisions, or cross-scene cloning, leaving significant behavioral ambiguity.
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, and it front-loads the key action. It earns its place by immediately conveying the tool's essence, though it omits contextual details that are scored separately.
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 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It does not explain the return value, side effects on the scene file, or how the clone source and parent path interact, making it hard for an agent to fully anticipate the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all 4 parameters with 100% coverage, so the baseline is 3. The description adds no parameter-specific information beyond what the schema provides, so it neither enhances nor detracts from the schema's clarity.
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 (deep-clone) and resource (a node in a scene), which is specific and distinguishes it from related tools like duplicate_scene or duplicate_resource. However, it does not explicitly differentiate from sibling tools such as editor_duplicate_node or duplicate_scene, so the purpose is clear but lacks explicit contrast.
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 duplicate_scene or editor_duplicate_node. It does not mention prerequisites, exclusions, or context, leaving the agent without explicit decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compile (reimport) a .gdshader via Godot editor or local validation.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .gdshader file to compile (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds context that compilation can happen 'via Godot editor or local validation', which implies two modes of operation. However, it does not disclose potential side effects (e.g., reimporting modifies project state) or any prerequisites (e.g., whether editor must be running for editor mode).
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 that efficiently conveys the tool's purpose and mode. Every word contributes meaning, with no redundancies or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is mostly complete. However, it does not explain what the tool returns (e.g., success/failure or compilation errors) and does not clarify the difference from validate_shader, which is a nearby sibling. Given the simplicity, this is a minor gap.
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 only param 'path' has a description), so the schema already documents the parameter. The description adds no further parameter semantics beyond the context of compiling a shader file.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Compile (reimport) a .gdshader'. It specifies the resource type (.gdshader) and the action (compile/reimport), and distinguishes itself from siblings like validate_shader (which may only validate) and write_shader (which writes content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via 'Godot editor or local validation' but does not explicitly state when to prefer this over alternatives like validate_shader or editor_reimport_asset. It provides partial context but lacks clear when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect two node ports in a VisualShader graph.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to VisualShader .tres | |
| to_node | Yes | Target node index | |
| to_port | Yes | Target port index | |
| from_node | Yes | Source node index | |
| from_port | Yes | Source port index |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action but does not reveal side effects, error conditions, whether the connection is directional, or what happens if nodes/ports are invalid. This is a significant gap 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, focused sentence that earns its place. It is concise and front-loaded with the essential action, with no unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the semantics of connecting ports (e.g., compatibility between port types), nor does it describe any validation or return behavior. The sparse description is insufficient for an agent to fully understand the tool's effect and constraints.
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 5 parameters are fully described in the input schema (100% coverage). The description adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Connect') and clearly identifies the resource ('two node ports in a VisualShader graph'). It is unambiguous and distinct from sibling tools like disconnect_shader_graph_nodes or set_shader_node_param, making the purpose immediately 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention exclusions, prerequisites, or relationships with sibling tools such as disconnect_shader_graph_nodes or add_shader_graph_node. The agent must infer usage solely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect a signal between nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| flags | No | Connection flags | |
| signal | Yes | Signal name (e.g. "body_entered", "pressed") | |
| to_node | Yes | Target node path | |
| unbinds | No | Number of unbinds | |
| from_node | Yes | Source node path | |
| scene_path | Yes | Path to .tscn file | |
| method_name | Yes | Method name on target (e.g. "_on_body_entered") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it fails to mention side effects such as modifying the scene file, prerequisites like existing signals, or failure behavior. The operation is a mutation but this is not made explicit, leaving the agent without critical safety information.
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 redundant wording, making it concise and front-loaded. However, it is somewhat under-specified, which slightly reduces the score but it is still efficient for what it conveys.
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 (7 parameters, no annotations, no output schema), the description is too sparse. It fails to explain the context of connecting signals in a scene, disambiguate from similar tools, or describe expected outcomes, leaving significant gaps for an agent to invoke it 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 description coverage is 100%, so the schema already documents all parameters. The description adds no extra parameter semantics, making baseline 3 appropriate. It does not explain relationships between parameters or provide examples 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 clearly states the action 'Connect a signal' and the resource 'between nodes', making the basic purpose understandable. However, it does not distinguish from sibling tools such as editor_connect_signal or connect_shader_graph_nodes, so it lacks sibling differentiation.
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 other similar connection tools (e.g., editor_connect_signal). The description only states the operation without any context about appropriate usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create Animation .tres resource.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for new Animation .tres file (e.g. "animations/idle.tres") | |
| length | No | Animation length in seconds | |
| loop_mode | No | Loop mode: none, linear, or ping_pong | none |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It only states 'Create Animation .tres resource' without mentioning whether the file will be overwritten, what happens if the path exists, or any side effects beyond creation. This lacks transparency for a write operation.
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, focused sentence that conveys the core action without any unnecessary words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with no annotations and no output schema, the description is minimal and does not explain the resource type beyond the file extension, nor does it mention the configurable length and loop_mode options. An agent would lack context on how this tool integrates with other animation-related operations.
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 all three parameters with descriptions and defaults, so the description adds no additional parameter meaning. Per the baseline for high schema coverage, 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 uses a specific verb 'Create' and resource 'Animation .tres resource', clearly identifying the operation. It distinguishes from siblings like create_curve or create_resource by specifying the .tres animation format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as add_animation_library, add_animation_track, or create_resource. The description gives no context about prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create AtlasTexture .tres.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path (e.g. "textures/sprite_atlas.tres") | |
| region | No | [x, y, w, h] region rect | |
| atlas_texture | Yes | Path to source texture |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only implies a file-write operation through 'Create' but does not disclose whether it overwrites existing files, creates directories, validates the source texture, or returns a result. 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 extremely concise, consisting of a single four-word sentence. It is front-loaded and contains no filler, which is good for conciseness, but the extreme brevity limits its informative value.
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 is too skeletal. It does not explain the purpose of the AtlasTexture resource, the role of the region parameter, or what happens on execution. For a tool with two required parameters, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters (path, region, atlas_texture), so the baseline is 3. The description adds no extra meaning about parameter relationships, such as how region applies to the atlas texture or what format the output path should take.
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 'Create AtlasTexture .tres' clearly states a specific verb (Create) and resource (AtlasTexture .tres), and it distinguishes from sibling create_* tools by the resource type. However, it lacks any explanation of what an AtlasTexture is or how it relates to the source texture and region, so it is not fully informative.
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 usage guidance. It does not state when to use this tool instead of alternative texture creation tools (e.g., create_image_texture, create_noise_texture), nor does it mention prerequisites, exclusions, 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.
Create AudioBusLayout.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Output path for AudioBusLayout .tres | default_bus_layout.tres |
| master_volume | No | Master bus volume (0-1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention side effects, whether existing files are overwritten, what the layout contains, or any permissions required. The description is essentially just the tool name in sentence form.
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 terse, but this is under-specification rather than effective conciseness. It is a single sentence that repeats the tool name without adding useful structure or content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is wholly inadequate. It fails to explain what an AudioBusLayout is, how the parameters affect the result, or what the user can expect after invocation. The schema helps with parameters, but the overall 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%, with both parameters (path and master_volume) having descriptive text. The description itself adds no parameter information, but the schema fully compensates, so the baseline 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 'Create AudioBusLayout.' simply restates the tool name create_audio_bus_layout with spaces, adding no new information. It is a tautology and does not distinguish this tool from siblings like add_audio_bus or read_audio_bus_layout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as add_audio_bus or set_bus_volume. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create CameraAttributes (Practical or Physical) for 3D camera DOF and auto-exposure.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| preset | No | practical |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Create' without mentioning side effects such as overwriting existing files, permission requirements, or return behavior. 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, front-loaded with the primary action and resource. It contains no redundancy and every word contributes meaning.
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 only two parameters and no output schema, so the description gives the essential purpose. However, it omits path semantics, overwrite behavior, and return value, leaving gaps for a creation 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 description coverage is 0%. The description explains the preset variants ('Practical or Physical') but does not explain the 'path' parameter, its purpose, or how it relates to the created resource. Preset is self-explanatory via the enum, but path is left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with the resource type 'CameraAttributes' and clarifies the two variants ('Practical or Physical') and their purpose ('3D camera DOF and auto-exposure'). This clearly distinguishes it from sibling tools like editor_create_camera or create_environment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for 3D camera DOF and auto-exposure' implies a use case, but the description provides no explicit when-to-use instructions or alternatives. It does not mention that modifying existing attributes might require editor_set_camera_param or that read_camera could be used for inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create CollisionPolygon2D.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Node name | CollisionPolygon2D |
| points | Yes | Array of [x, y] points (e.g. [[0,0], [100,0], [100,50], [0,50]]) | |
| scene_path | Yes | Path to .tscn scene file | |
| parent_path | No | Parent node path (usually a StaticBody2D or Area2D) | . |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Create', which implies a write operation, but does not mention side effects on the scene file, overwriting behavior, or error handling. 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 that repeats the tool name. While short, it is under-specified and fails to provide meaningful information beyond the name. This is under-specification, not conciseness, as the sentence does not 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?
With no annotations and no output schema, the description carries the burden of explaining what the tool does, what the inputs mean, and what happens after execution. It only states the action, leaving the agent to infer everything from the schema. For a mutation tool with four parameters, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions for all four parameters, including the points array format and parent_path default. The description adds no parameter-specific information, so it scores at the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a CollisionPolygon2D, which is a specific action and resource. However, it does not differentiate from sibling tools like set_shape_points or set_collision_shape, and it essentially restates the tool name without additional 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?
There is no guidance on when to use this tool versus alternatives. The description does not mention prerequisites, such as needing a parent physics body, nor does it compare to related tools like read_collision_polygon or set_shape_points.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create Curve .tres.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path (e.g. "curves/ease_in.tres") | |
| points | No | Array of [x, y] control points | |
| bake_resolution | No | Bake resolution |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It merely states 'Create Curve .tres.' without revealing whether it overwrites existing files, what file format specifics are involved, or any side effects. The agent is left in the dark about critical 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 this is under-specification rather than effective conciseness. A sparse sentence like 'Create Curve .tres.' fails to provide enough informative content, similar to the 'Process' example that scored low.
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 3 parameters, no annotations, and no output schema, the description is minimal. It doesn't explain the relationship between points and the resulting curve, the bake resolution purpose, or any creation behavior. The description is inadequate for an agent to understand the tool's full impact.
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 descriptions cover 100% of parameters, so the schema already provides basic meaning for 'path', 'points', and 'bake_resolution'. The tool description adds no additional semantic value beyond the schema. The parameter descriptions themselves are terse but present, warranting the baseline score.
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 'Create Curve .tres.' names a specific verb ('Create') and resource ('Curve .tres'), which is clear enough to differentiate it from generic create_resource and other creatable types. However, it doesn't explicitly distinguish itself from write_path_curve or read_curve siblings, and could be more descriptive about what a Curve resource entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like create_resource or write_resource. There is no context, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a directory in project.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Directory path to create (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral details. It only states that a directory is created, but does not say whether the path is relative to the project root, whether intermediate directories are created, or what happens if the directory already exists. This lack of behavior disclosure leaves important questions unanswered.
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 wasted words. It is appropriately concise for a simple tool, though it could have been slightly longer to include usage guidance 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?
The tool is relatively simple, and the schema covers the only parameter. However, the description lacks contextual information such as the relative path requirement, potential failure modes, or relationship to similar tools. This makes it adequate but not fully complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the single 'path' parameter with 'Directory path to create (relative to project root)', so schema coverage is 100%. The description adds no additional meaning about the parameter. The baseline of 3 is appropriate because the schema already provides full parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a directory in project.' This is a specific verb and resource, and it is distinct from other create_* tools. However, it does not distinguish itself from the sibling tool 'editor_create_folder', which seems to have a similar 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 gives no guidance on when to use this tool versus alternatives such as 'editor_create_folder' or 'move_file'. There is no mention of prerequisites, limitations, or preferred contexts. The lack of any usage direction makes this a minimal, unhelpful description for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create Environment from preset.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for new Environment .tres (e.g. "environments/default.tres") | |
| preset | No | Preset: default, stylized, dark, or bright | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral details. It does not mention side effects such as overwriting existing files, required project state, or what the 'preset' parameter does beyond the schema. This is minimal 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?
The description is a single short sentence that is front-loaded with the core action. It is appropriately concise for a simple create operation, though it could include more detail without losing efficiency.
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 two well-documented parameters, the description covers the fundamental purpose, but lacks usage context and behavioral details. The schema fills in parameter meanings, but the description does not address when to use it or what effects it has, leaving some completeness 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 has 100% coverage for both parameters, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already documents, such as the path format or preset enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' and identifies the resource 'Environment' with the qualifier 'from preset', which distinguishes it from sibling tools like create_world_environment. It clearly states the tool's core 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?
No guidance is provided about when to use this tool versus alternatives like create_world_environment or set_environment_param. The description lacks any context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a .gdextension config file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for new .gdextension (e.g. "addons/myext/myext.gdextension") | |
| entry_symbol | No | Entry symbol (init function name) | myext_init |
| library_path | No | Path to the compiled library (e.g. "res://addons/myext/bin/libmyext.linux.debug.x86_64.so") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool creates a config file, but does not disclose whether it overwrites existing files, creates parent directories, or has other side effects. The description is too brief to convey risks or operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff or redundancy. It efficiently communicates the core purpose without wasting words, which is ideal for a tool of this simplicity.
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 absence of annotations and the simplicity of the tool, the description is incomplete. It does not mention potential overwrite behavior, whether directories are created, or the return value. The schema covers parameters, but the description lacks sufficient context for safe and correct usage, especially for a file-writing 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 description coverage is 100% (all three parameters have descriptions with examples), so the schema fully documents each parameter. The description itself adds no additional parameter semantics, but the baseline score of 3 is appropriate since the structured data fills the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and identifies a clear resource ('.gdextension config file'), distinguishing it from siblings like read_gdextension or other creation tools. It is direct and unambiguous about what the tool accomplishes.
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, such as read_gdextension for reading or write_resource for generic resource writing. There are no prerequisites, exclusions, or context indicating the appropriate scenarios for creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create Gradient .tres.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path (e.g. "gradients/fire.tres") | |
| colors | No | Array of {offset, color} objects | |
| interpolation_mode | No | linear |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only says 'Create Gradient .tres' with no details on whether existing files are overwritten, whether directories are created, or any side effects. This is a significant gap for a file-writing operation.
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, but it borders on under-specification, essentially restating the tool name. Structure is clean but lacks substantive detail.
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 annotations, no output schema, and three parameters, the one-line description is insufficient for an agent to know how to construct parameters or anticipate results. It covers only the core action and leaves all context to the 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 schema provides descriptions for path and colors, but interpolation_mode lacks a description. The tool description adds no parameter meaning beyond the schema, so it fails to compensate for the incomplete 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 uses a specific verb ('Create') and resource ('Gradient .tres'), clearly stating what the tool does. It is distinct from generic tools like create_resource, though it does not explicitly name alternatives.
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 sibling tools like create_resource or write_resource. There is no mention of prerequisites, related operations, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a GridMap node for 3D tile-based level design.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | GridMap | |
| parent | No | . | |
| scene_path | Yes |
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 does not mention that creating a GridMap likely modifies the current scene, requires an open scene, or returns any value. The description is silent on side effects and prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no output schema, and no annotations, the description is too minimal to be complete. It does not explain what scene_path means, what parent defaults to, or what happens after creation. An agent would struggle to invoke this correctly 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 0% and the tool description does not explain any of the three parameters. The parameter names (name, parent, scene_path) are not self-explanatory—especially scene_path, which could refer to a scene file, a mesh library, or a node path. The description adds no value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Create'), a specific resource ('GridMap node'), and its purpose ('3D tile-based level design'). This distinguishes it from sibling tools like create_scene or create_mesh_primitive.
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 such as create_scene or read_grid_map. It only mentions a general purpose without exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an ImageTexture .tres pointing at an image file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output .tres path for the new ImageTexture (e.g. "textures/hero_tex.tres") | |
| source | Yes | Source image path relative to project (e.g. "sprites/hero.png") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that a .tres file is created referencing an image, but does not mention overwrite behavior, source file validation, or side effects like directory creation.
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 redundant words. It clearly conveys the operation without excessive detail.
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 2-parameter tool with complete schema coverage, the description is functional but lacks behavioral caveats (e.g., overwriting) and explicit usage guidance vs sibling texture creation tools. No output schema or annotations to compensate.
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 already documents both parameters with examples (100% coverage). The description adds minimal semantic value beyond stating the relationship between the .tres and the source image, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('ImageTexture .tres') with a clear relationship to an image file. It distinguishes this from sibling tools like create_atlas_texture and create_noise_texture.
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 the use case (creating an ImageTexture resource pointing at an image) but does not explicitly state when to prefer this over alternatives like create_atlas_texture or create_noise_texture. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a physics joint.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Joint node name | |
| node_a | No | Node A path (first connected body) | |
| node_b | No | Node B path (second connected body) | |
| joint_type | Yes | Joint type | |
| scene_path | Yes | Path to .tscn scene file | |
| parent_path | No | Parent node path | . |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Create' without explaining side effects such as modifying a scene file, whether it requires existing nodes for node_a/node_b, or whether the operation is reversible. This is a significant gap 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 concise sentence with no redundancy or filler. It is front-loaded with the key action, though it is extremely sparse—losing a point for being too brief to be fully self-contained.
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 6 parameters, no annotations, and no output schema, a one-sentence description is inadequate. It fails to mention joint types, the need for node_a/node_b, or that it operates within a scene, leaving the agent to rely heavily on schema and prior knowledge.
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%, meaning all parameters already have descriptive text. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and resource ('a physics joint'), which clearly distinguishes it from sibling tools like remove_joint, read_joint, and set_joint_param. It unambiguously conveys the tool's primary 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?
No guidance is provided on when to use this tool versus alternatives, nor are prerequisites mentioned (e.g., requiring existing physics bodies or a scene file). The description simply states the action without contextual clues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create 3D mesh resource: Box, Capsule, Cylinder, Plane, Sphere, Torus, etc. (11 types).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for mesh .tres | |
| params | No | Override default size params | |
| mesh_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only says 'Create 3D mesh resource' and lists types. It does not disclose whether existing files are overwritten, what the function returns, any side effects, or required permissions. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource, followed by examples and a count. Every word earns its place, and it is appropriately sized for a tool of this complexity.
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 no annotations and no output schema, the description needs to cover more context. It does not mention the return value, error cases, or behavior on existing files. It also doesn't explain that 'params' overrides defaults or that 'path' is an output path (though the schema covers those). This is insufficient for a create operation, which typically has side effects and potential errors.
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 67% (path and params have descriptions, mesh_type has only the enum). The description adds a few mesh type examples and the total count, which partially supplements the mesh_type enum but does not add meaning beyond what the schema provides. This aligns with the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('3D mesh resource'), and lists several concrete mesh types (Box, Capsule, etc.) with a count of 11. This distinguishes it from generic 'create_resource' and other mesh-related tools like 'create_multimesh'.
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 clearly implies when to use this tool: to create a 3D mesh resource. It provides context by naming mesh types, but does not explicitly mention when not to use it or suggest alternatives (e.g., 'create_resource' for non-mesh resources). This is clear context without exclusions, matching a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a MultiMesh .tres resource.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for new MultiMesh .tres (e.g. "meshes/grass_multimesh.tres") | |
| mesh_path | No | Optional .tres Mesh path (res://...) to assign | |
| instance_count | No | Number of instances to allocate | |
| transform_mode | No | Transform format | transform_3d |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description must disclose behavioral details. It only states the creation action without mentioning side effects like file overwriting, directory creation, or project registration. This is a significant transparency gap 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, front-loaded sentence with no wasteful words. It is concise and easy to scan, though slightly under-specified for a tool with four parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description should provide more context about the resource's purpose or side effects. It only states the resource type, leaving the agent to infer behavior from the schema alone. This is insufficient for a fully informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional parameter context beyond what the schema already provides, earning the baseline score of 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 clearly states the action ('Create') and the specific resource type ('MultiMesh .tres'), which is distinct from generic create_resource or write_resource tools. It unambiguously identifies the tool's 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 provides no guidance on when to use this tool versus alternatives like create_resource or write_resource. No contextual hints or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create NoiseTexture2D.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for NoiseTexture2D .tres | |
| width | No | Texture width | |
| height | No | Texture height | |
| seamless | No | Seamless tiling | |
| noise_type | No | simplex |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits such as side effects, file creation, or potential overwrites. The description only says 'Create NoiseTexture2D,' which reveals it is a creation operation but omits any details about what happens to existing files, permissions, or the output format. The schema's path parameter mentions '.tres', but the description itself gives no such 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?
While the description is a single concise sentence, it is under-specified and provides no substantive content. It is a restatement of the tool name rather than a useful summary. The conciseness dimension rewards value per sentence, and this sentence lacks informative value.
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 5 parameters, no annotations, no output schema, and many sibling creation tools. The description is entirely inadequate for an agent to understand what the tool does, when to use it, or what parameters affect. No mention of suitable use cases, parameter semantics, or expected results leaves the description completely incomplete for the tool's 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?
The schema has 80% parameter description coverage, with all parameters including path, width, height, seamless, and noise_type having descriptions. The tool description itself does not explain any parameters, but the high schema coverage means the description does not need to compensate. Baseline of 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create NoiseTexture2D' essentially restates the tool name 'create_noise_texture' without adding any additional meaning or context. It names the resource type but does not clarify what a NoiseTexture2D is, how it differs from other texture creation tools, or what the primary use case is.
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 create_image_texture or create_atlas_texture. No exclusions, prerequisites, or context are given, leaving the agent to infer the appropriate usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create PhysicsMaterial.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path (e.g. "physics/ice.tres") | |
| rough | No | Rough surface | |
| absorb | No | Absorbent mode | |
| bounce | No | Bounciness (0=none, 1=perfect) | |
| friction | No | Friction coefficient (0=ice, 1=rubber) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it discloses nothing about side effects, file writing, overwrite behavior, or required context. 'Create' alone is insufficient for an agent to understand the tool's operational 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 brief but under-specified rather than appropriately concise. It provides no useful information beyond the name, so the single sentence does not '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 tool has five parameters and no output schema or annotations, the description is too sparse to fully guide an agent. It fails to clarify that this creates a resource file, how it relates to sibling tools, or what the expected outcome is.
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 adds no parameter information beyond what the schema already provides, so it 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 'Create PhysicsMaterial.' simply restates the tool name with a verb and object, offering no additional detail about what a PhysicsMaterial is or how this tool differs from generic create_resource. It is effectively a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like create_resource or read_physics_material. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a resource from template.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for new resource (e.g. "materials/floor.tres") | |
| type | Yes | Resource type template | |
| properties | No | Optional custom properties to override template defaults |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden. It does not state whether the tool overwrites existing files, what side effects it has, or any error conditions, which is significant for a creation 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, front-loaded sentence that is easy to parse. It is concise, though it sacrifices some necessary detail 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?
Given three parameters, no annotations, and no output schema, the description is too minimal. It omits important context such as overwrite behavior, return values, and when to prefer this tool over similar ones.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters with descriptions and an enum for 'type'. The description adds little beyond the schema, so 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 uses a specific verb ('Create') with a clear object ('resource') and method ('from template'). It conveys the tool's core function, though it does not explicitly differentiate itself from sibling tools like write_resource.
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 given on when to use this tool versus alternatives such as write_resource or create_script, nor are any exclusions or prerequisites mentioned.
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 from template.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for new scene (relative to project root, e.g. "scenes/main.tscn") | |
| template | Yes | Root node type template | |
| root_name | No | Custom root node name (default: derived from template) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the basic create action with no disclosure of behavioral traits such as overwrite behavior, parent directory creation, or project context. Since annotations are absent, the description carries the full burden but provides minimal insight.
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, highly concise and front-loaded with the verb. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutating operation without annotations or output schema. The description does not explain what 'from template' means beyond the schema, nor does it specify file overwrite or directory creation behavior, leaving potential ambiguity for correct invocation.
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 description adds no information about parameters; however, the input schema has 100% description coverage, so the schema already documents path, template, and root_name. The description neither conflicts with nor adds to 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 clearly states the tool creates a new scene from a template, using a specific verb and resource. It distinguishes from other create_* tools by focusing on scenes, though it does not explicitly differentiate from sibling tools like editor_create_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?
There is no guidance about when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or cases where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new script from template.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path (relative to project root, e.g. "scripts/enemy.gd") | |
| type | Yes | Script language | |
| template | No | Template type | node_script |
| class_name | No | Optional class_name for GDScript |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden, but it reveals nothing about side effects, overwrite behavior, directory creation, permissions, or return values. 'Create' only implies a write operation, which is already conveyed by the tool 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 a single, grammatically simple sentence with no wasted words. However, it is so minimal that it leaves the agent without essential context, making it under-specified rather than appropriately 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 creation tool with 4 parameters, no output schema, and no annotations, this description is severely incomplete. It fails to provide any behavioral details, prerequisites, return value information, or caveats that an agent would need for safe and correct invocation.
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 all four parameters have inline descriptions. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('a new script'), and the phrase 'from template' distinguishes it from writing raw scripts to some extent. However, it does not explicitly differentiate from sibling tools like editor_create_script or write_script, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as write_script, attach_script, or editor_create_script. There are no usage contexts, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new .gdshader from template.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path (relative to project root, e.g. "shaders/glow.gdshader") | |
| type | Yes | Shader type template |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full responsibility. It only states the core action and does not disclose overwrite behavior, file system side effects, or template selection semantics. This is a gap for a file-creating 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 concise sentence that is front-loaded with the verb and resource. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with fully documented parameters, the core functionality is clear. However, it lacks behavioral context such as overwrite policy or what determines the template used, which prevents it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'path' and 'type' having helpful descriptions and the enum listing valid template types. The description adds no parameter details beyond implying a template-based creation, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create), resource (.gdshader), and source (from template). It distinguishes from siblings like write_shader (arbitrary shader content) and create_visual_shader (visual shaders) by specifying the template-based 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?
There is no guidance on when to use this tool versus alternatives such as write_shader or create_shader_include. No mention of exclusions or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a .gdshaderinc file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path (e.g. "shaders/common.gdshaderinc") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is extremely sparse and doesn't disclose any behavioral traits beyond the action of creating a file. With no annotations, the agent has no information about overwrite behavior, directory creation, or file content, leaving significant safety gaps 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 that front-loads the action and contains no wasted words. It is appropriately sized for a tool with this simplicity.
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 description is minimal and doesn't cover important context such as whether the file is created empty, whether existing files are overwritten, or if parent directories are created. For a mutation tool with no annotations and no output schema, this 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?
The schema fully describes the path parameter with an example. The description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a .gdshaderinc file, using a specific verb and resource. It distinguishes from sibling tools like create_shader and read_shader_include by explicitly naming the file type.
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 vs alternatives. It doesn't mention scenarios, prerequisites, or exclusions, so the agent must infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Sky .tres with a procedural or panorama sky material.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for new Sky .tres (e.g. "environments/sky.tres") | |
| material | No | Sky material type | procedural |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'Create' without mentioning whether the tool overwrites existing files, fails on conflicts, requires specific permissions, or what the return value indicates. For a write operation, this is a significant lack of behavioral context.
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 that front-loads the action and resource, and it does not waste words. It is appropriately sized for a tool with two parameters and no additional complex behavior that needs explanation.
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 schema and absence of annotations, the description is too thin. It lacks critical context about overwrite behavior, side effects, and when to use this tool vs. siblings. For a write tool with no output schema, the description should provide more behavioral and usage details to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides (e.g., the enum values are already listed). It does not compensate with additional context about path formatting or material specifics.
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 it creates a Sky .tres with procedural or panorama material, which is a specific resource and differentiates it from sibling tools like create_environment or write_resource. The verb 'Create' plus the resource type and material options make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use this when you need to create a Sky resource. However, it provides no explicit guidance on when to use it versus alternative tools (e.g., create_resource or write_resource), nor any exclusions or prerequisites. It stops short of naming alternatives, so it earns a 3 rather than a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a SpringArm3D for smooth camera follow.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | SpringArm3D | |
| length | No | ||
| parent | No | . | |
| scene_path | Yes |
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 details such as scene modification, side effects, or requirements. It only states the creation action and purpose, leaving the agent to infer behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently conveys the tool's primary function and 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?
With 4 parameters and no annotations or output schema, the description is insufficient. It fails to explain return values, side effects, or parameter roles, making it inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no additional meaning for the parameters (name, length, parent, scene_path). The names and defaults are visible in the schema, but the description does not clarify units, scope, or relationships.
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 specific resource 'SpringArm3D', adding the purpose 'for smooth camera follow'. This distinguishes it from other creation tools and leaves little ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for smooth camera follow' provides clear contextual guidance on when to use this tool. However, it does not explicitly mention alternatives or exclusions, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a SpriteFrames .tres resource with named animations.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for SpriteFrames .tres | |
| animations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral details. It only states the output type and 'named animations', but omits side effects like file overwriting, directory creation, error handling, and whether existing scenes are modified. This is a significant gap for a tool that writes to disk.
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 redundancy, immediately stating the action and resource type. It is appropriately 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?
The tool is simple in purpose but the animations parameter is a non-trivial array with defaults. With no annotations and no output schema, the description should explain the animation format and file-writing behavior. It does not, leaving the tool under-specified for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents 'path' with a description, but 'animations' lacks description. The phrase 'named animations' hints at the name property but does not explain fps or loop defaults. The description partially compensates for the missing schema documentation but leaves the animation structure ambiguous.
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', the resource type 'SpriteFrames .tres', and the key feature 'named animations'. It distinguishes itself from generic resource tools like create_resource and from animation-specific tools like create_animation, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as write_resource or create_animation. The description does not mention prerequisites, exclusions, or the intended workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Theme .tres resource.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for new Theme .tres (e.g. "themes/main.tres") | |
| default_font_size | No | Default font size |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose side effects, but it does not. It does not state whether an existing file at path is overwritten, whether directories are created, or whether any editor refresh is needed after creation. The bare phrase 'Create a Theme .tres resource' leaves the mutation profile ambiguous.
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 filler words. It front-loads the core purpose and nothing else, making it maximally 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 side-effectful file-creating tool with no annotations and no output schema, the description is too sparse. It omits overwrite behavior, return values, and any context about how the theme resource fits into the Godot project, 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?
Schema coverage is 100%, with both path and default_font_size having descriptive entries, so the description adds no extra semantic information. The path example in the schema already communicates the expected format, so 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 specifies the action ('Create') and the exact resource type ('Theme .tres'), which clearly distinguishes it from generic create_resource and other create_* siblings. The inclusion of the .tres extension makes the output format explicit.
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 over alternatives like create_resource or write_resource. There are no prerequisites, no mention of whether it's for new files only, and no references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a TileSet .tres resource.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for new TileSet .tres (e.g. "tilesets/main.tres") | |
| tile_size | No | Tile size [x, y] in pixels |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states what is created, but does not mention overwrite behavior, directory creation, side effects, or whether the resource is initialized with defaults. This is minimal beyond the action itself.
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 wasted words. It is concise and to the point.
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 no annotations, no output schema, and only a short description, the context is incomplete. Key information such as overwrite behavior, handling of missing directories, and use in tilemap workflows is absent. The schema covers parameters but not broader tool 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% for both parameters, so the baseline is 3. The description adds no additional parameter semantics; the schema already documents 'path' and 'tile_size' with clear examples and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and names the exact resource type ('TileSet .tres resource'), clearly distinguishing it from generic create_resource and other create_* tools. It is unambiguous and directly states what the tool does.
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 siblings like create_resource or write_resource. There is no mention of when not to use it or any alternative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create translation CSV.
| Name | Required | Description | Default |
|---|---|---|---|
| keys | No | Initial translation keys to add | |
| path | Yes | Output path for new translation .csv file (e.g. "localization/zh_CN.csv") | |
| language | No | Language code (e.g. "en", "zh_CN", "ja") | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it only restates the action and gives no details about side effects like file creation, overwriting, or permissions. It adds no meaningful behavioral context beyond the tool's 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 a single, short sentence with no wasted words. It is appropriately concise and front-loaded, reflecting an ideal level of 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?
Given the presence of related siblings like write_translation and add_translation_key, plus the lack of annotations and an output schema, this minimal description does not provide enough context for an agent to decide when to use it or what side effects to expect. It is under-specified for the tool's 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?
The input schema already provides 100% coverage with descriptions for all three parameters (keys, path, language), so the baseline is 3. The description adds no extra parameter-specific meaning, though the mention of 'CSV' hints at the output 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 uses a clear verb 'Create' and a specific resource 'translation CSV', so the core purpose is evident. However, it does not differentiate this from sibling tools like write_translation or add_translation_key, so it lacks sibling distinction.
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?
There is no guidance on when to use this tool versus alternatives such as write_translation or add_translation_key. No context, prerequisites, or exclusions are provided, leaving the agent without direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a VehicleBody3D with VehicleWheel nodes for car physics.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | VehicleBody3D | |
| parent | No | . | |
| wheels | No | ||
| scene_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that the tool creates a VehicleBody3D with wheels, but does not mention side effects (e.g., whether existing nodes are overwritten), requirements (e.g., valid scene_path), or default wheel behavior. This is a significant gap 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 clear sentence with no fluff, but it is under-specified. It front-loads the purpose but lacks any additional context, making it more incomplete than 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?
The tool has four parameters (one required) and no output schema, yet the description explains none of the parameter semantics or expected behavior. There is no mention of how wheels are configured, what scene_path must point to, or what the tool returns. The description is inadequate for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'VehicleWheel nodes' but does not explain the four parameters (name, parent, wheels, scene_path) or their meanings. An agent cannot infer that 'wheels' expects an array of objects with name/position/suspension fields, nor what 'parent' or 'scene_path' signify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (Create) and resource (VehicleBody3D) with the additional detail 'with VehicleWheel nodes for car physics,' which distinguishes it from other create_* tools. It clearly conveys what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, when not to use, or reference to related tools such as read_vehicle_body or create_scene. The description only states the action, leaving context entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new VisualShader .tres graph file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for new VisualShader .tres | |
| shader_type | Yes | Shader mode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, but it only states that a file is created. It does not disclose whether existing files are overwritten, required permissions, or return behavior. For a file-creation operation, this lack of side-effect disclosure is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler, earning a high score for structure.
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 low complexity and full schema documentation, the description is mostly complete, but it omits any mention of overwrite behavior or output message. A slightly richer description would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with 100% coverage (path and shader_type with enum values). The tool description adds no additional parameter semantics, but the baseline of 3 applies due to 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 uses a specific verb ('Create') and identifies the exact resource ('VisualShader .tres graph file'), clearly distinguishing it from other create_* tools like create_shader. The .tres extension further clarifies the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool over alternatives such as create_shader or when in a project workflow it should be invoked. The description only states what it does, not the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create World3D .tres.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for World3D .tres (e.g. "environments/main_world.tres") | |
| environment_path | No | Path to Environment .tres to attach |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create World3D .tres.' only states the action itself and does not disclose whether the tool overwrites existing files, creates directories, requires additional setup, or has side effects. This is a significant transparency gap for a file creation 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 extremely short (four words), which is concise but under-specified. It does not include essential context about behavior, usage, or side effects, making it an example of under-specification rather than effective conciseness. A single terse sentence is not appropriately sized for a tool with no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having complete schema coverage for parameters, the description lacks any contextual information about the World3D resource, when to use this tool, or what happens after creation. With no annotations and no output schema, the description should provide more context but instead offers only a bare statement, leaving the agent without sufficient understanding of the tool's behavior and implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (path and environment_path) described clearly in the input schema. The description itself adds no parameter information, so it does not exceed the baseline. The baseline of 3 applies because the schema fully documents the 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 'Create World3D .tres.' states a specific verb (create) and resource (World3D .tres file), which clearly identifies the tool's function. It distinguishes itself from sibling tools like create_environment and create_world_environment by specifying the exact resource type and file extension.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or comparison to similar tools such as write_resource or create_resource. The intended usage is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a .tscn with a WorldEnvironment node referencing an Environment.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for new .tscn with a WorldEnvironment node (e.g. "environments/world_env.tscn") | |
| environment_path | No | Optional .tres Environment to reference; if omitted an inline default Environment is used |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It states the output is a .tscn file and that it references an Environment, but it does not mention whether existing files are overwritten, whether parent directories are created, what happens if the environment_path is invalid, or what the return value is. The behavior is largely opaque beyond the basic creation action.
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 that directly states the tool's purpose. It contains no filler or redundant information, and every word contributes to the meaning. This is an ideal length for a simple creation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of web_search global annotations and output schema, the description needs to provide more context about side effects and prerequisites. It does not mention overwrite behavior, directory creation, error handling, or return values, leaving significant gaps for an agent to safely invoke the tool. The schema covers parameter semantics but not the overall execution behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters have detailed descriptions, including the optional behavior of environment_path (inline default if omitted). The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a .tscn file containing a WorldEnvironment node that references an Environment. It is specific about the output resource and node type, which distinguishes it from generic scene or resource creation tools. However, it doesn't explicitly call out alternatives like create_environment or create_world, so it's not fully 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 is provided on when to use this tool versus alternatives. The description does not mention any preconditions, exclusions, or scenarios where another sibling tool would be more appropriate. The agent is left to infer usage from the tool's name and the presence of similar creation tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a file with .bak backup.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to file to delete (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It mentions the .bak backup, indicating a safety mechanism, but does not explain whether deletion is permanent, where the backup is stored, or how to restore it. For a destructive operation, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and the backup behavior. It is front-loaded and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema), the description covers the core behavior but lacks critical context for a destructive tool. It does not specify backup file location, whether deletion is to trash or permanent, or failure behavior. The absence of annotations increases the need for more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single 'path' parameter, including a clear description. The tool description adds no extra parameter-level information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a file and mentions the .bak backup mechanism, which distinguishes it from other removal tools like remove_node or editor_delete_asset. The verb 'delete' plus resource 'file' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings such as move_file or editor_delete_asset. It does not mention prerequisites, safety checks, or situations where alternate tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two Animation .tres files.
| Name | Required | Description | Default |
|---|---|---|---|
| path_a | Yes | First animation .tres path | |
| path_b | Yes | Second animation .tres path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention what 'compare' entails, whether there are side effects, what output format is produced, or any limitations. This is a significant gap for a tool with no structured safety metadata.
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 entire description is a single short, front-loaded sentence ('Compare two Animation .tres files.') with no redundant information or unnecessary phrasing. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema or annotations, and the description fails to explain what the comparison returns or how results are delivered. For instance, it does not state whether it outputs unified diff, a boolean, or a report. This is a notable completeness gap even for a low-complexity 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?
The schema already fully describes both parameters (path_a and path_b) with 100% coverage, so the description adds no additional semantic value. Per the rubric, a baseline of 3 is appropriate when the schema covers all 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 uses a specific verb ('Compare') and identifies the resource type ('Animation .tres files'), making the tool's purpose immediately clear. It also distinguishes itself from sibling diff tools like diff_scene and diff_resource by specifying the file type.
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 such as diff_resource or diff_scene. It only states the core function without any contextual hints or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two config files (project.godot, .cfg, .import) ignoring whitespace and comments.
| Name | Required | Description | Default |
|---|---|---|---|
| path_a | Yes | First config file path (project.godot, .cfg, .import, etc.) | |
| path_b | Yes | Second config file path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral trait: ignoring whitespace and comments. However, it does not describe the output format or whether the operation has any side effects, leaving some ambiguity about what the agent should expect after invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence with no redundant words. It front-loads the verb and object and adds a meaningful behavioral qualifier. Excellent 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?
For a simple two-parameter diff tool with no output schema and no annotations, the description covers the core purpose and key filtering behavior. It does not explicitly state the return format, but the tool name and description strongly imply a diff result. Overall, sufficiently complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds minimal extra meaning beyond repeating the config file types already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Compare' and clearly identifies the resource type as config files, listing concrete extensions (project.godot, .cfg, .import). This distinguishes it from sibling diff tools like diff_resource, diff_scene, diff_script, and diff_animation, which target other resource types.
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 explicit mention of config file extensions implies when to use this tool, and the sibling names provide obvious contrast for other diff operations. However, it does not explicitly state exclusions or alternatives, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two resource files.
| Name | Required | Description | Default |
|---|---|---|---|
| path_a | Yes | First .tres resource path | |
| path_b | Yes | Second .tres resource path | |
| context_lines | No | Lines of context around diffs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does not state whether the comparison is textual or structural, what output format is returned, whether it is read-only, or any side effects. The minimal description leaves significant ambiguity.
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, front-loaded with the action verb and object, with no redundant information. It is appropriately concise for the tool's simplicity.
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 3 parameters, no output schema, and no annotations, the description is too minimal. It does not explain what 'resource files' refers to in this context (e.g., Godot .tres files) nor what the comparison produces, leaving important gaps for 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?
The schema provides 100% coverage with descriptive parameter declarations (e.g., 'First .tres resource path', 'Lines of context around diffs'). The description adds no parameter-specific meaning, but the schema already handles this, so a 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 ('Compare') and the object ('two resource files'). It distinguishes from sibling tools like diff_scene and diff_script by focusing on resource files, though it does not specify the .tres format explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as diff_scene or diff_script. There is no mention of prerequisites, use cases, or exclusions, leaving the agent to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two scene files.
| Name | Required | Description | Default |
|---|---|---|---|
| path_a | Yes | First scene path | |
| path_b | Yes | Second scene path | |
| ignore_whitespace | No | Ignore whitespace-only changes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It only says 'Compare two scene files,' which implies a read-only operation but does not disclose whether it modifies files, what the output format is, or how missing/invalid files are handled. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It efficiently conveys the core action and resource. While it omits details, that is a completeness issue, not a conciseness issue. It earns a high score for not wasting 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?
The description is minimal and lacks contextual completeness. There is no output schema, and the description does not explain what the tool returns (e.g., a diff report, exit code) or any side effects. For a tool with three parameters and no annotation support, more context is needed to understand the full scope and use case.
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% as each parameter has a description. The tool description itself adds no parameter-specific information, but the schema already provides clear descriptions for path_a, path_b, and ignore_whitespace. Per the rubric, this earns a baseline of 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 clearly identifies the tool's action ('Compare') and the resource ('two scene files'). It distinguishes from sibling tools like diff_script and diff_animation by specifying scene files. However, it does not elaborate on what aspect of scene files is compared or the nature of the output, so a slight deduction from 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as diff_resource or diff_project_config. It also does not mention any prerequisites or contextual scenarios. This is a clear gap in usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two GDScript files line-by-line.
| Name | Required | Description | Default |
|---|---|---|---|
| path_a | Yes | First .gd script path | |
| path_b | Yes | Second .gd script path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the 'line-by-line' comparison method, but does not mention potential side effects (likely none), permissions, or the format of the result. The read-only nature is implied but not explicit.
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, front-loaded with the verb, and contains no superfluous information. Every word contributes to the meaning.
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?
While the purpose and parameters are clear, there is no output schema and the description does not explain what the tool returns or any potential error conditions. For a simple tool this is minimally adequate but lacks important contextual details about the result.
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 meaning beyond the schema; it only restates that the tool compares files, without elaborating on path formats or other parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Compare' and clearly identifies the resource as 'two GDScript files', with the detail 'line-by-line' adding scope. This distinguishes it from sibling diff tools like diff_animation or diff_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 states what the tool does but provides no guidance on when to use it versus alternatives such as diff_scene or diff_resource. Usage is implied by the resource type, but there are no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect two node ports in a VisualShader graph.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to VisualShader .tres | |
| to_node | Yes | Target node index | |
| to_port | Yes | Target port index | |
| from_node | Yes | Source node index | |
| from_port | Yes | Source port index |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states the action 'Disconnect two node ports' without revealing side effects, reversibility, error behavior on missing connection, or any permission requirements. This is a sparse disclosure for a mutating 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, clear sentence that wastes no words. It is front-loaded with the action verb and directly states the subject, making it extremely 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 tool with 5 parameters, no output schema, and no annotations, the description is too minimal. It lacks context about what constitutes a valid connection, what happens if the connection doesn't exist, and whether the operation is reversible. The provided information is only the core action, leaving significant gaps for the agent to fully understand the tool's behavior and constraints.
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 ('Source node index', 'Target port index', etc.). The tool description adds no extra meaning beyond the schema, and does not clarify the relationship between from/to parameters (e.g., which is output vs input). The baseline of 3 applies because the schema already documents the parameters adequately, though the description does not enhance it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Disconnect' and identifies the resource as 'two node ports in a VisualShader graph.' It clearly distinguishes from sibling tools like connect_shader_graph_nodes by indicating the inverse operation, and from remove_shader_graph_node by targeting connections rather than nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for removing a connection in a shader graph, but provides no explicit guidance on when to prefer this over alternatives, no prerequisites (e.g., connection must exist), and no exclusion criteria. Usage is inferred from the tool name and description, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect a signal.
| Name | Required | Description | Default |
|---|---|---|---|
| signal | Yes | Signal name | |
| to_node | Yes | Target node path | |
| from_node | Yes | Source node path | |
| scene_path | Yes | Path to .tscn file | |
| method_name | Yes | Method name on target |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action 'Disconnect a signal' without mentioning side effects, reversibility, required permissions, or behavior when the signal 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?
The description is only one sentence, but this is under-specification rather than genuine conciseness. It lacks essential context and detail, similar to the 'Process' example where brevity comes at the cost of usefulness.
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 5 required parameters and no output schema, yet the description gives no information about the connection workflow, what a signal connection entails, or how the parameters relate. The description is grossly insufficient for an MCP tool of this 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% and each parameter has a description in the schema, so the baseline is 3. However, the tool description itself adds no extra meaning beyond the schema; it simply restates the tool's 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?
The description 'Disconnect a signal' is essentially a tautology of the tool name. It identifies the action and resource but provides no specifics about what kind of signal, in what scene, or how it differs from sibling tools like disconnect_shader_graph_nodes or editor_disconnect_signal.
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?
There is no guidance on when to use this tool versus alternatives such as connect_signal or editor_disconnect_signal. No context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate a .tres resource.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source .tres path (relative to project root) | |
| destination | Yes | Destination .tres path (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral details, but it only states the basic action. It does not mention overwrite behavior, error handling, or how dependencies are handled.
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, focused sentence that directly conveys the tool's purpose. No unnecessary words, and the key information is 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?
For a simple duplicate operation, the description is minimally sufficient, but it omits return value information and edge-case behavior. Given no output schema, a bit more context would improve completeness, yet the core purpose 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?
Schema coverage is 100% with both source and destination parameters fully described as relative paths to the project root. The description adds no extra semantics beyond the schema, so 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 uses the specific verb 'Duplicate' and identifies the target resource type as '.tres resource'. This clearly distinguishes it from sibling tools like duplicate_scene and write_resource.
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 such as write_resource or duplicate_scene. There is no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate a scene file.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source scene path (relative to project root) | |
| destination | Yes | Destination scene path (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Duplicate a scene file'. It doesn't mention overwrite behavior, dependency handling, path resolution, or other side effects, leaving significant ambiguity for an unannotated 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 five-word sentence with zero filler, making it perfectly concise and front-loaded. Every word is necessary.
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?
Although the tool is simple and the schema fully documents the parameters, the description omits critical behavioral context such as overwrite behavior, whether dependencies are copied, and whether the destination must not already exist. With no annotations and no output schema, the description leaves the tool's operational semantics unclear.
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 both parameters (source and destination) with descriptions and minLength constraints, providing 100% coverage. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Duplicate a scene file' clearly identifies the verb (duplicate) and resource (scene file), distinguishing it from sibling tools like duplicate_resource and clone_node. However, it doesn't explicitly mention alternatives or scope, so it's clear but lacks explicit sibling differentiation.
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 such as duplicate_resource or editor_duplicate_asset. It doesn't mention prerequisites, conditional use cases, 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.
Add an autoload singleton via editor API.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions 'via editor API' but does not disclose whether the operation is destructive, reverts existing autoloads, or requires specific permissions.
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 fluff or repetition. It is front-loaded and efficient, though it could be slightly more detailed 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?
For a mutation tool with no annotations and no output schema, the description is too minimal. It omits parameter details, explains no use cases, and does not address differences from sibling tools, leaving the agent without enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists two string parameters without descriptions, and the description does not clarify that 'name' likely refers to the autoload's registration name and 'path' to the script path. This leaves the parameters ambiguous, adding little semantic 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?
The description clearly states the action (Add) and resource (autoload singleton) with a method (via editor API). However, it does not distinguish from the sibling tool 'add_autoload', which appears to do the same thing without the editor API qualifier.
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_autoload' or 'editor_remove_autoload'. There is no mention of prerequisites, side effects, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an input action via editor API.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| deadzone | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the verb 'Add' with no mention of side effects, permissions, idempotency, or what happens if the input action already exists. The description adds minimal behavioral context beyond the action itself.
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, but it is under-specified for a tool with two parameters and no other context. While it is not verbose, it fails to include necessary details, making it 'adequate but with clear gaps' rather than 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?
Given the tool has no annotations, no output schema, and no parameter descriptions, the description is incomplete. It does not explain return values, side effects, or how this editor API action differs from other similar input-related tools. The overall context is insufficient for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It does not mention 'name' or 'deadzone' at all, leaving the purpose of 'deadzone' (a non-obvious parameter with a default) completely unexplained. This is a critical gap.
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 an input action') and the context ('via editor API'), which is specific enough to understand what the tool does. However, it does not distinguish it from similar sibling tools like 'add_input_action' or 'write_input_action', lacking explicit differentiation.
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?
There is no guidance on when to use this tool versus alternatives such as 'add_input_action' or 'write_input_action'. No context, exclusions, or alternative tool recommendations are provided, leaving the agent without decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a node to the currently open scene in editor.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Node name (auto-generated if omitted) | |
| type | Yes | Node type (e.g. "Sprite2D", "CollisionShape2D") | |
| parent | No | Parent node path | . |
| properties | No | Properties to set |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It only states the action without disclosing side effects, permissions, or whether the change is immediately applied or requires saving. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and free of filler. It is appropriately concise, though it sacrifices some informational content 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?
For a mutation tool with no annotations and no output schema, the description is too minimal. It does not explain return values, error conditions, or prerequisites such as the editor being running. The schema provides parameter detail, but broader 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?
The input schema covers all parameters with descriptions (100% coverage), so the description does not need to add parameter details. The baseline is 3, and the tool description adds no additional meaning 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 clearly states the action (add), the resource (node), and the context (currently open scene in editor). It is specific enough to distinguish from many sibling tools, but it does not explicitly differentiate from similar tools like 'add_node' or 'editor_create_mesh_instance'.
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. There is no mention of prerequisites (e.g., editor must be open) or exclusions for certain node types. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach a script to a node in the editor.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Node path | |
| script | Yes | Script path to attach |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It merely says 'attach a script to a node' without explaining what attaching involves (e.g., setting a property, overwriting, validation, or side effects). This leaves the agent to guess.
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 unnecessary words. It is immediately clear and 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?
The tool is simple and the schema covers all parameters, but the description omits usage context, prerequisites, and differentiation from similar tools. Given the absence of annotations and output schema, it is minimally viable but not rich.
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 fully described in the schema (100% coverage), so the description adds no extra meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (attach) and the objects (script, node), with scope 'in the editor'. It is specific and understandable, but does not distinguish from the similarly named sibling 'attach_script', so it lacks sibling differentiation.
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 like 'attach_script' or 'editor_create_script'. There are no prerequisites, exclusions, or context clues beyond the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger lightmap baking.
| 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 disclose behavioral traits. It only states the trigger action and fails to mention side effects (e.g., modifying lightmap textures), potential duration, or necessary setup. This is insufficient for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, succinct sentence that clearly states the core action with no redundant words. It is front-loaded and appropriately sized for a tool with no parameters.
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 no annotations and no output schema, the description must provide essential context. It fails to mention what scene/objects are baked, what effects occur, or any prerequisites. This leaves the agent without critical information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. With no parameters to explain, the baseline of 4 applies. The description adds no parameter information, but none 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 uses a specific verb ('Trigger') and resource ('lightmap baking'), clearly indicating the action. It distinguishes from similar baking tools like editor_bake_navigation by naming the resource. However, it omits scope details such as whether it applies to the current scene or selected objects, preventing a perfect score.
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 (e.g., editor_bake_navigation) and lacks context about prerequisites or exclusions. It simply states the action without any conditional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the editor error list.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly indicates a mutating action (clearing the error list), which implies destruction of the list contents. However, it does not mention whether the action is reversible, affects only the current session, or has any side effects on the editor's 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, front-loaded sentence without any wasted words. It directly states the tool's purpose and nothing else.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, simple mutation tool, the description is sufficient. It clearly identifies the target (editor error list) and the action (clear). While there is no output schema, the tool likely returns no meaningful value, so additional detail is not necessary.
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 schema is complete with 100% coverage. The description does not need to explain parameter semantics because there are none, which is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Clear' with a clear resource, 'the editor error list.' It is distinct from sibling tools like editor_get_errors (which retrieves errors) and compile_shader (which generates errors).
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, such as editor_get_errors, nor any context about prerequisites or situations where clearing the error list is appropriate. It simply states the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect a signal between nodes in the editor.
| Name | Required | Description | Default |
|---|---|---|---|
| node | Yes | ||
| method | Yes | ||
| signal | Yes | ||
| target | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details. It only states the action without mentioning preconditions (e.g., nodes must exist), side effects (e.g., duplicate connections, whether an existing connection is replaced), or failure behavior. For a mutation-like operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no redundancy. It is well-structured and front-loaded, stating exactly what the tool does without any 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 four parameters, no output schema, and no annotations, this one-sentence description is severely incomplete. It does not explain the role of each parameter, what constitutes a valid signal/method/target, or how to handle errors. Closely related sibling tools (connect_signal, connect_shader_graph_nodes) further heighten the need for richer 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 input schema has 0% description coverage, and the description does not explain any of the four parameters (node, signal, method, target). The phrase 'between nodes' hints at the target parameter, but no operational detail is given. The description adds no value beyond the raw 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 uses a specific verb 'Connect' and clearly identifies the resource 'signal' with the scope 'between nodes in the editor'. This distinguishes it from runtime signal connections (e.g., connect_signal) and shader graph connections (connect_shader_graph_nodes). It is a precise statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the editor context for connecting signals but does not explicitly state when to use this tool over alternatives or when not to use it. It lacks any mention of the relationship to connect_signal or prerequisites like node existence, so the agent gets only an implicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copy selected nodes to the editor clipboard.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It clearly states the action: copying selected nodes to the editor clipboard. While it doesn't disclose details like clipboard overwrite behavior or failure conditions if no nodes are selected, the operation is inherently simple and non-destructive, and the description matches the expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that gets straight to the point: 'Copy selected nodes to the editor clipboard.' Every word is necessary, and it is efficiently front-loaded with the core action.
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 very simple tool with no parameters and no output schema. The description fully explains what the tool does, and no additional context is needed to invoke it correctly. It is complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter details because none are needed; the input schema is empty and there is nothing to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Copy' and clearly identifies the resource: 'selected nodes to the editor clipboard'. It is unambiguous and distinguishes from sibling tools like editor_cut (which also involves copying but with deletion) and editor_paste (which places clipboard contents).
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 implicitly indicates when to use the tool (when you want to copy selected nodes to the clipboard), but it does not explicitly mention alternatives or when not to use it. There is no guidance comparing it to editor_cut or editor_duplicate_node, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Camera3D node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Node name (auto-generated if omitted) | |
| parent | No | Parent node path | . |
| properties | No | Properties to set on the new node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that a Camera3D node is created, but does not mention prerequisites (e.g., an open scene), error behavior if the scene is not open, whether the node is attached to the scene root or parent, or any side effects like selection. This is a significant gap 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, clear sentence with no filler or redundant information. It is appropriately concise for a simple create operation.
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 description is minimal but covers the core action. However, without annotations or an output schema, it lacks context about expected behavior when the scene is not open, naming conventions, or property application. It is adequate for a simple tool but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains the name, parent, and properties parameters. The description adds no additional meaning beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action 'Create a Camera3D node' and the context 'in the open scene'. It distinguishes this tool from camera-related siblings like create_camera_attributes (which creates a resource) and read_camera (which reads camera properties).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the goal is to add a Camera3D to the current scene, but it does not explicitly state when to prefer this over alternatives like editor_add_node, create_camera_attributes, or other editor_create_* tools. No exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a CSGBox3D node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Node name (auto-generated if omitted) | |
| parent | No | Parent node path | . |
| properties | No | Properties to set on the new node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing side effects. It states that the tool modifies the open scene by creating a node, but provides no details on prerequisites (must a scene be open?), failure modes, reversibility, or whether the node is selected.
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 that is immediately actionable. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple node-creation tool with three optional parameters and no output schema, the description covers the core purpose and context ('in the open scene'). While additional behavioral notes would improve it, the description is adequate given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with parameter descriptions explaining name auto-generation, parent path, and properties. The description itself adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create), the resource (CSGBox3D node), and the context (in the open scene). It is distinct from sibling tools like editor_create_csg_cylinder or editor_create_csg_sphere by explicitly naming the box type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it creates a CSG box in the current scene. It does not explicitly mention when to use alternatives or provide exclusions, but the tool name and sibling context make the intended use apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a CSGCylinder3D node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Node name (auto-generated if omitted) | |
| parent | No | Parent node path | . |
| properties | No | Properties to set on the new node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the creation action. It does not describe side effects, prerequisites like whether an open scene is mandatory, potential error conditions, or whether the operation is reversible. This lack of behavioral context is a significant gap 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 straightforward sentence with no wasted words, front-loading the action and target.
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 creation tool with fully documented parameters, the description is minimally adequate, but it omits any mention of return values, error handling, or prerequisites beyond the open scene. No annotations or output schema exist to compensate, so the description is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters with descriptions (name auto-generated, parent default '.', properties to set), so baseline is 3. The description adds no parameter information 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 uses the specific verb 'Create' and identifies the exact node type 'CSGCylinder3D' and target 'in the open scene', clearly distinguishing it from sibling tools like editor_create_csg_box or editor_create_csg_sphere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to prefer this tool over alternatives such as create_mesh_primitive or other CSG creation tools. It only states the action without any contextual or alternative scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a CSGCombiner3D node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Node name (auto-generated if omitted) | |
| parent | No | Parent node path | . |
| properties | No | Properties to set on the new node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Create' implies mutation but does not disclose side effects, requirements (like an open scene), or return behavior. It only states the basic operation.
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 redundant words. It clearly states what the tool does without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with three optional parameters covered by schema, the description provides the essential 'what and where' but lacks details about behavior on failure or return values. It is adequate but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes each parameter (name, parent, properties) with detailed descriptions. The tool description adds no extra parameter information, so it relies fully on the schema, which is comprehensive.
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 specifies the action (Create), the exact resource type (CSGCombiner3D node), and the target (open scene), clearly distinguishing it from sibling tools like editor_create_csg_box or editor_create_csg_sphere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly indicate when to use this tool versus other CSG creation tools. However, the resource type name makes the use case clear (combining CSG shapes), but there are no explicit exclusions or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a CSGPolygon3D node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Node name (auto-generated if omitted) | |
| parent | No | Parent node path | . |
| properties | No | Properties to set on the new node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the primary action, failing to mention side effects (e.g., adding to scene tree, generating default properties), error conditions (e.g., if no scene is open), or any other behavioral traits. The schema mentions auto-generated name, but the description adds no extra 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 redundant words. It is appropriately front-loaded with the action and resource. Every word earns its place, making it 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?
The tool has 3 parameters, no annotations, and no output schema, so the description should provide more context. It does not mention prerequisites like an open scene or editor running, nor does it explain what happens after creation (e.g., selection, return value). The description is too minimal for a tool with these complexities, especially given the large set of sibling tools.
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%: all three parameters (name, parent, properties) have descriptions, so the schema already documents parameter meaning. The description adds no extra semantic value beyond what the schema provides. The baseline of 3 applies because the schema handles parameter semantics fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Create') and specifies a specific resource ('CSGPolygon3D node') within a context ('open scene'). This clearly distinguishes it from sibling tools like editor_create_csg_box or editor_create_csg_sphere, which create different node types. The wording directly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While the name and resource type imply use for CSGPolygon3D, there is no mention of prerequisites (e.g., an open scene must exist) or when to prefer this over generic add_node or other CSG creation tools. The only context is 'in the open scene,' which is not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a CSGSphere3D node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Node name (auto-generated if omitted) | |
| parent | No | Parent node path | . |
| properties | No | Properties to set on the new node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic creation action, but omits details such as whether the operation is undoable, what happens if no scene is open, or whether the new node is selected. This is minimal 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, direct sentence that immediately conveys the tool's purpose. Every word is useful and there is 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?
For a simple creation tool with no output schema and good schema param coverage, the description is adequate but not rich. It lacks context about prerequisites (e.g., an open scene), error conditions, or how it relates to its many sibling CSG creation tools, leaving a moderate gap.
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 all three parameters (name, parent, properties) already have descriptions. The tool description adds no extra meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create', the specific resource 'CSGSphere3D node', and the location 'in the open scene'. It distinguishes from sibling tools like editor_create_csg_box or editor_create_csg_cylinder by naming the exact node type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a CSGSphere3D node is needed in the open scene, but it does not explicitly discuss when to use this versus alternatives, nor does it mention any exclusions or prerequisites. The context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a directory in the project via editor filesystem.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only mentions 'via editor filesystem' but does not disclose critical behaviors such as whether existing directories are overwritten, whether parent directories are created, or failure conditions. 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 that directly conveys the action and context with no filler or redundant content. It is optimally concise and 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?
For a simple one-parameter tool, the description provides the core action and location, but it omits important behavior around existing directories, parent creation, and differentiation from the sibling 'create_directory'. It is minimally adequate but leaves gaps that could lead to misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'path' gains some meaning from the phrase 'in the project', implying a project-relative scope. However, with 0% schema description coverage, the description only partially compensates by hinting at scope but lacks format details or examples.
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 ('Create a directory') and the scope ('in the project'), making the purpose evident. However, it does not distinguish this tool from the sibling 'create_directory' which likely serves a similar function, so it lacks sibling differentiation.
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 like 'create_directory' or other creation tools. There are no mentions of preconditions, exclusions, or contextual cues for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a GPUParticles3D node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Node name (auto-generated if omitted) | |
| parent | No | Parent node path | . |
| properties | No | Properties to set on the new node |
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 behavior. It only states that a node is created; it does not mention side effects, whether the node is selected, undo behavior, error conditions, or any other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the essential purpose. There is no wasted wording, and every word contributes meaning.
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 node-creation tool with a well-described schema, the one-sentence description is mostly sufficient, but the lack of annotations or output schema means some context (return value, failure modes, prerequisite checks) is missing. It is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (name, parent, properties) with 100% coverage, so the description does not need to add much. However, it also adds no extra meaning 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 uses a specific verb ('Create') and a specific resource ('GPUParticles3D node') with an explicit location ('in the open scene'). This clearly distinguishes it from sibling create tools for other node types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in the open scene' implies the prerequisite of an open scene, but there is no explicit guidance on when to use this tool versus alternatives such as editor_set_particles_param or other create tools. Usage context is implied rather than clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a MeshInstance3D node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Node name (auto-generated if omitted) | |
| parent | No | Parent node path | . |
| properties | No | Properties to set on the new node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details. It only states the action and the open-scene context, omitting side effects, return values, failure conditions, or what happens if no scene is open.
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 that immediately conveys the tool's function without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage, the description is minimally viable but lacks information about return values, error behavior, and usage context beyond the open-scene requirement.
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 provides 100% coverage with descriptions for all three parameters. The description itself adds no parameter-specific meaning, 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 uses a specific verb ('Create') and resource ('MeshInstance3D node'), and specifies the target context ('in the open scene'), clearly distinguishing it from generic node creation tools like add_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 is provided on when to use this tool over alternatives such as add_node or editor_add_node, nor any mention of prerequisites beyond an open scene.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a MultiplayerSpawner3D node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Node name (auto-generated if omitted) | |
| parent | No | Parent node path | . |
| properties | No | Properties to set on the new node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core behavior (creating a node in the open scene) and implies a mutation of the scene, but it does not mention side effects, failure conditions (e.g., no open scene), or whether existing nodes are replaced. This is adequate for a simple creation tool but lacks depth.
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. It efficiently communicates the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with three well-documented parameters and no output schema. The description covers the basic purpose, but it does not explain return values, failure modes, or what happens if the scene is not open. Given the low complexity, the description is sufficient but leaves some context 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?
The input schema has 100% description coverage for all three parameters, so the schema already explains name, parent, and properties. The tool description adds no additional parameter information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Create a MultiplayerSpawner3D node in the open scene.' It uses a specific verb and resource, and distinguishes from sibling tools like editor_create_multiplayer_synchronizer or add_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?
The description gives context ('in the open scene') but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Usage is implied from the tool name and description, but no guidance is provided for choosing between this and similar create tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a MultiplayerSynchronizer3D node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Node name (auto-generated if omitted) | |
| parent | No | Parent node path | . |
| properties | No | Properties to set on the new node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone carries the burden of behavioral disclosure. It only states a create operation in the open scene, but does not mention side effects (e.g., scene modification), error cases, return values, or interaction with existing nodes.
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 zero wasted words. It immediately states the action, resource, and 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?
The tool has no output schema and no annotations, and the description is extremely sparse. For a creation tool within a large editor toolset, it lacks context about the node's purpose, how it fits into a MultiplayerSynchronizer workflow, and what the user should expect after invocation, making it incomplete for a complex 3D scene editor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (name, parent, properties) with 100% coverage, so the baseline of 3 is appropriate. The description itself adds no additional parameter semantics beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') with a precise resource ('MultiplayerSynchronizer3D node') and a clear location ('in the open scene'). It is unambiguous and naturally distinguishes from sibling tools like editor_create_multiplayer_spawner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool over alternatives, nor any prerequisites or exclusions. The phrase 'in the open scene' implies a requirement but is not developed into practical usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create and open a new scene in the editor.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path for new scene | |
| root_name | No | ||
| root_type | No | Node2D |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states 'create and open,' without mentioning potential side effects (e.g., file overwriting), prerequisites (e.g., editor running), or defaults for root_type and root_name. The description is too sparse to inform the agent of important behavioral implications.
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 that directly states the tool's purpose. There is no fluff or redundant information. It is front-loaded and efficient, earning every word.
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 relative complexity (creating and opening a scene), the description is severely under-specified. It does not explain return behavior, the effect of root_type and root_name, whether existing scenes are overwritten, or what 'open' entails. No output schema exists, so the description must carry this burden, and it does not.
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 only 33% (path is described, root_name and root_type have no descriptions). The tool description does not compensate by explaining these parameters or their interplay. It adds no meaning beyond the schema, leaving two of three parameters semantically opaque.
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 action ('Create and open') and resource ('a new scene in the editor'). However, it does not explicitly distinguish from sibling tools like create_scene or edit_scene, so it lacks full differentiation. It is precise but not unique.
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 when the tool should be used: when you want to create a scene and have it opened in the editor. There are no explicit alternatives, exclusions, or guidance on choosing between this and similar tools like create_scene. The implied usage is present but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create and open a new GDScript in the editor.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Output path for new script | |
| extends | No | Base class | Node |
| template | No | Template: empty, node_script, character, resource_script, signal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions creating and opening a script, but says nothing about overwriting behavior, editor prerequisites, file creation side effects, or error conditions. 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?
The description is a single, front-loaded sentence with no filler. It clearly states the action and object with appropriate 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?
There is no output schema and no annotations, and the description does not explain return values, error behavior, or prerequisites (e.g., whether the editor must be open). The basic action is clear, but the agent has little to predict the tool's full behavior or failure modes.
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 path, extends, and template each having meaningful descriptions. The tool description itself adds no extra parameter semantics, so the baseline 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 uses a specific verb 'Create and open' with a clear resource 'GDScript' and context 'in the editor'. It distinguishes itself from siblings like create_script or write_script by adding the 'open' action, which is meaningful.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_script, write_script, or attach_script. There are no exclusions, prerequisites, or contextual hints beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cut selected nodes to the editor clipboard (with undo).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core mutation (cut = remove to clipboard) and mentions undo support, which is valuable. However, it does not disclose whether the clipboard is replaced, whether it fails without a selection, or any side effects beyond the cut.
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 that conveys the action, target, destination, and a key behavioral note (undo). Every word earns its place; there is no fluff or repetition.
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 largely complete. It clearly states the operation and undo support. It could optionally mention prerequisites (e.g., selected nodes) or the lack of a return value, but these are implied and not critical for a standard cut 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?
The tool has zero parameters, so the schema is trivially 100% covered. According to the rubric, 0 params earns a baseline of 4. The description adds no parameter details because none are 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 uses the specific verb 'Cut' with a clear resource ('selected nodes') and destination ('editor clipboard'), and adds the unique behavioral trait 'with undo'. This clearly distinguishes it from sibling tools like editor_copy and editor_paste, which are separate operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool operates on selected nodes for a cut-paste workflow. However, it does not explicitly mention alternatives (e.g., editor_copy for non-destructive duplication) or prerequisites like requiring a current selection. The description implies usage but provides no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop execution (break) in debugger.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining side effects. It merely restates the action without saying whether it halts the running game immediately, whether the break is temporary, or what the debugger state becomes afterward.
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. It is appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and the close sibling tools (editor_debug_continue, editor_debug_step, editor_pause), this description is incomplete. It does not explain when to use it or what effects it has, leaving an agent to guess about the tool's broader 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 zero parameters, so the input schema already provides complete information. There is no parameter-specific meaning for the description to add, and none 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 identifies the action (stop/break execution) and the domain (debugger). It distinguishes itself from debugger continue and step siblings by explicitly saying 'stop execution (break)'.
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 given on when to use this tool vs alternatives like editor_pause, editor_debug_step, or editor_debug_continue. It does not mention prerequisites such as needing a running debug session or how it differs from setting a breakpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume execution in debugger.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone carries the burden of behavioral disclosure. It merely states 'Resume execution in debugger' without revealing side effects, prerequisites (e.g., must be paused at a breakpoint), behavior if no debug session is active, or whether it is a control action that alters debugger state. This is a minimal 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?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes meaning, and it is appropriately sized for a zero-parameter debugger control tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter command, the description is minimally viable but lacks contextual details that would make it complete. It doesn't explain the required debugger state (paused vs. running), the effect on breakpoints, or how it differs from runtime_resume, leaving gaps in the agent's understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so the baseline for this dimension is 4. The description appropriately omits parameter details because none exist, and no additional parameter meaning is required.
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 'Resume execution in debugger' clearly states a specific action and resource, and it visibly distinguishes itself from sibling debugger step commands by implying continuation rather than single-step execution. However, it doesn't explicitly differentiate itself from sibling runtime_resume or clarify 'continue' semantics (e.g., run to next breakpoint/end), so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like editor_debug_step, editor_debug_step_over, or runtime_resume. The description gives no context about requiring a paused debugger state or when this command is appropriate, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step into next line in debugger.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states the basic action. It does not disclose preconditions (e.g., debugger must be paused), side effects (execution state changes, potential entry into a function), or error behavior when no debug session is active.
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 six words and contains zero redundancy: a clear verb, object, and context. Every word earns its place and the core action is front-loaded, making it an appropriately sized description for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter debugger control tool with no output schema, the description is minimally adequate. However, it lacks essential context for correct invocation, such as the requirement that a debug session be active and paused, making it incomplete in a debugging workflow 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 zero parameters, so the baseline is 4 per the rubric. The empty schema is fully covered, and the description adds no parameter information, which is appropriate since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('step into') and resource ('next line in debugger'), clearly identifying the action as a debugger stepping operation. It implicitly distinguishes from the sibling editor_debug_step_over through standard debugger terminology, but does not explicitly name the alternative.
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 like step-over, continue, or break. The description does not mention prerequisites such as an active or paused debug session, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step over current line in debugger.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It states the action but does not disclose prerequisites (e.g., active debug session), side effects (e.g., execution pause/advance), or what happens if no debugger is active. Minimal behavioral context is 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 extremely concise, a single short sentence that immediately conveys the operation. No filler or 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?
For a zero-parameter, simple debugger control, the description is adequate but lacks contextual details about when the tool is applicable (e.g., requiring a running debug session) and how it relates to other debug commands. It is not misleading, but it leaves some operational context implicit.
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 description does not need to explain parameter semantics. The baseline of 4 applies, and the description adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('step over') and resource ('current line in debugger'), clearly identifying the action. It distinguishes itself from siblings like editor_debug_step (step into) and editor_debug_continue by specifying the granularity of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage during a debugging session but does not explicitly state when to use step over versus alternatives like step into or continue. No exclusions or alternatives are mentioned, leaving the decision to the agent's understanding of debugging concepts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a file or folder via editor.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It states only that deletion occurs, but does not mention whether deletion is permanent, recursive for folders, requires specific permissions, or affects references. This is a significant transparency gap for a destructive operation.
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, focused sentence with no redundant words or filler. It front-loads the action and resource, making it easy to scan. There is no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a destructive operation with no annotations and only a one-line description. Despite its simple parameter structure, important context is missing: permanence, path semantics, folder recursion behavior, and any editor-specific constraints. The description is too sparse to fully prepare an agent for correct invocation.
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 0%, so the description must compensate. The single parameter 'path' is not elaborated: no format (absolute/relative), no indication of whether folder deletion is recursive, and no explanation of how 'via editor' affects path resolution. The description adds minimal meaning 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 clearly states the action (Delete) and resource (a file or folder via editor). It communicates the core purpose, but does not distinguish itself from sibling tools such as delete_file or editor_delete_selected, which also delete files or selected items.
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 like delete_file or editor_remove_node. There are no usage conditions, prerequisites, or exclusions, leaving the agent without context for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete currently selected nodes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action. It does not disclose whether deletion is undoable, whether a selection must exist, or any side effects on the scene, leaving the agent without important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It is perfectly concise and 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?
For a simple tool with no parameters and no output schema, the description is minimal but adequate. However, it lacks context about the meaning of 'currently selected' and the destructive nature of deletion, making it only minimally viable.
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 schema coverage is trivially 100%. The description does not need to explain parameter semantics, and the baseline of 4 for zero-parameter tools is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Delete') and a specific resource ('currently selected nodes'), which distinguishes it from siblings like editor_remove_node (which likely deletes a specific node by path) and editor_delete_asset (which deletes assets).
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?
There is no guidance on when to use this tool versus alternatives. It does not mention that editor_remove_node should be used for deleting a specific node by identifier, or that editor_delete_asset handles assets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disable a named editor plugin.
| Name | Required | Description | Default |
|---|---|---|---|
| plugin | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. The one-line description simply states the action without revealing side effects (e.g., whether the plugin needs to be enabled first, whether changes are persistent, or what happens if the plugin name is invalid). 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 short sentence, front-loaded with the action. It contains no redundant words and is appropriately sized for the tool's simplicity. Every word contributes meaning.
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, the description is still incomplete. It lacks guidance on where to find plugin names (e.g., via editor_get_plugin_list), any prerequqisites like the plugin being enabled, or error behaviors. The absence of annotations and output schema increases the need for contextual information, which is not provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the input schema provides only the property name 'plugin' and type string. The description adds the word 'named', indicating the parameter is a plugin name, but provides no further semantics such as valid formats, sources, or constraints. It adds marginal value but does not compensate for the lack of schema documentation.
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 'Disable a named editor plugin.' clearly states the action (disable) and the resource (editor plugin). It is specific and distinguishes from the sibling tool editor_enable_plugin. The verb and object are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to disable an editor plugin) but does not explicitly state alternatives, exclusions, or prerequisites. There is no mention of editor_get_plugin_list for discovering plugin names or editor_enable_plugin as the inverse operation. Usage context is only implied by the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect a signal between nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| node | Yes | ||
| method | No | ||
| signal | Yes | ||
| target | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description does not disclose any behavioral traits such as side effects, error conditions, or reversibility. It simply states the operation, which is insufficient for a tool with this complexity. The description carries the full burden but only provides a minimal verb phrase.
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 and front-loaded with the verb, but it is under-specified for a tool with four parameters and no annotations. It is not verbose, yet it lacks the detail needed to be genuinely helpful, sitting at the minimum viable level.
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 four parameters, absent annotations, no output schema, and the presence of similar sibling tools (disconnect_signal, disconnect_shader_graph_nodes), the description is incomplete. It does not clarify what 'method' and 'target' refer to, nor does it specify the intended context (e.g., signal connections in the editor vs. shader graphs).
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 0%, and the description does not explain any of the four parameters (node, signal, method, target). While 'node' and 'signal' are intuitive from context, 'method' and 'target' are completely ambiguous, and the description adds no meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Disconnect a signal between nodes.' It has a specific verb and resource, which is sufficient for basic understanding. However, it does not differentiate from the similar sibling tool 'disconnect_signal' beyond the editor_ prefix, so it misses the explicit distinction that would earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'disconnect_signal' or 'disconnect_shader_graph_nodes'. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate a file via editor filesystem.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action and does not explain overwrite behavior, path requirements, error handling, or side effects, leaving significant gaps 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, concise sentence with no unnecessary words. The verb is front-loaded, and the phrase 'via editor filesystem' is efficiently used to provide context. Every word earns 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?
With no annotations, output schema, or parameter descriptions, the description is too sparse to fully guide use. It fails to specify path formats, constraints, or differences from similar duplication tools, making it incomplete for a tool with two required parameters.
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 has 0% description coverage for parameters. The description does not explain the 'from' and 'to' parameters beyond implying a source and destination. While the parameter names are intuitive, the description adds no additional semantic value or usage detail.
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 ('Duplicate') and the resource ('a file'), with the contextual hint 'via editor filesystem'. This distinguishes it from resource-level duplication tools like duplicate_resource and duplicate_scene, though it does not explicitly name alternatives.
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 sibling tools such as duplicate_resource, duplicate_scene, or editor_move_asset. The description offers no context for selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate a node with children, scripts, and signals.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name for duplicate | |
| path | Yes | Node path to duplicate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that duplication includes children, scripts, and signals, but it does not mention whether the duplicate is placed as a sibling, how the name parameter defaults or conflicts are handled, or whether external signal connections are preserved. Mutation-relevant details are missing.
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 wasted words. It delivers the core information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema), but the description leaves important gaps: it does not mention what the tool returns, where the duplicate is created, or whether a scene must be open. It is minimally adequate but could be more helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover both parameters 100%, so the baseline is 3. The description adds little beyond the schema—it only implies that the path refers to a node with children/scripts/signals, but does not explain naming behavior or how the name parameter is used when omitted.
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 it duplicates a node and specifies the scope (children, scripts, signals), which is specific and helpful. However, it does not explicitly distinguish itself from sibling tools like clone_node or editor_duplicate_asset, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as clone_node, duplicate_scene, or editor_duplicate_asset. It lacks exclusions, prerequisites, or context about when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable a named editor plugin.
| Name | Required | Description | Default |
|---|---|---|---|
| plugin | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full transparency burden. It only says 'enable' without disclosing side effects, persistence, error behavior, or whether enabling requires a restart or affects the current session. This is insufficient for a mutation-style 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 six-word sentence that is front-loaded and free of superfluous words. Every word contributes to stating the core action, making it an excellent example of 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?
The tool is simple with one parameter and no output schema, so the description is minimally adequate. However, the lack of usage guidance and behavioral transparency leaves gaps in when and how to correctly invoke it, making it incomplete relative to the available 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 input schema has zero description coverage for the 'plugin' parameter. The description adds only that it is a 'named' plugin, but does not specify the expected format, valid values, or how to obtain the plugin name, failing to compensate for the schema gap.
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 enables a named editor plugin, using a specific verb 'enable' and a distinct resource. It effectively differentiates from sibling tools like editor_disable_plugin and editor_get_plugin_list by focusing on the activation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like editor_disable_plugin or editor_get_plugin_list. It does not mention how to discover valid plugin names or any prerequisites, leaving the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a GDScript expression in debugger/editor context.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | GDScript expression to evaluate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention that evaluating arbitrary GDScript expressions can have side effects, does not clarify the evaluation environment (e.g., current stack frame), and does not state whether the evaluation result is returned. This is a significant gap for a potentially dangerous operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently communicates the core action and context, perfectly sized for a tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) but involves evaluating arbitrary expressions, which benefits from more context. The description mentions 'debugger/editor context' but does not explain what happens after evaluation (e.g., return value, errors) or potential side effects. It is minimally viable but lacks the detail needed for a user to fully understand the tool's behavior without additional lookups.
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 only parameter 'expression' is described in the schema as 'GDScript expression to evaluate'. The tool description adds no further parameter semantics, so the baseline of 3 is appropriate when the schema already documents the parameter clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Evaluate') and resource ('GDScript expression'), and adds the context 'debugger/editor context'. This clearly distinguishes it from sibling tools like editor_run_gdscript or runtime_call_method, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in debugger/editor context' implies when to use it, but there is no explicit guidance on alternatives or when not to use it. The description does not mention related tools like editor_run_gdscript or runtime_call_method, leaving the user to infer the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bring the Godot editor window to the foreground.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explicitly states the observable effect (window comes to foreground) and implies no side effects. For a trivial UI operation with zero parameters, this is sufficient and unambiguous.
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?
One clear, single-purpose sentence with no filler or redundancy. It is perfectly concise and 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?
This is a simple tool with no parameters, no output schema, and a single clear behavior. The description fully communicates what the tool does and needs no 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?
The tool has zero parameters, so the schema provides 100% coverage. No parameter descriptions are needed. Per rubric, 0 params earns a baseline of 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: 'Bring the Godot editor window to the foreground.' The verb 'bring' and resource 'Godot editor window' are specific, and this tool is distinct from siblings, none of which mention focusing the window.
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?
Usage is implied: use when you want the editor window in the foreground. However, there is no explicit statement of when to use this tool versus alternatives, nor exclusions. The context is clear but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List autoload singletons via editor API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility. It only states 'List autoload singletons via editor API', which largely restates the tool name. It lacks details on return format, editor runtime requirements, or potential side effects, aside from the implicit read-only nature of 'list'.
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, front-loaded with the action, and contains no wasted words. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of the sibling tool 'list_autoloads' with an identical purpose, the description lacks differentiation and does not explain what the returned data looks like (no output schema). The missing guidance on alternatives makes the description incomplete for reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, leaving nothing for the description to explain about parameters. The baseline of 4 applies for zero-parameter tools.
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 autoload singletons, which is a specific verb+resource. However, it does not distinguish from the sibling tool 'list_autoloads', which appears to serve the same purpose, so it misses the top score.
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 like 'list_autoloads' or other editor tools. There is no mention of context, prerequisites, or exclusions, leaving the agent without selection help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all breakpoints.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It merely states 'List all breakpoints' without specifying that it is a read-only operation, any dependencies on the editor state, or the structure of the returned data.
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 minimal words, directly stating the operation. It is well-structured and front-loaded with the action and object, with no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool, the description is largely sufficient, but the lack of an output schema and annotations means it would benefit from noting the return format or any side effects. Overall, it provides adequate context for such a simple 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?
The tool has zero parameters, so the baseline is 4. The description does not need to add parameter details, and it correctly implies no configuration is required.
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 'List' and the resource 'breakpoints', indicating the tool retrieves all breakpoints. This distinguishes it from sibling tools like editor_set_breakpoint and editor_remove_breakpoint, which modify breakpoints.
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 any context, prerequisites, or why one might choose this over related tools like editor_get_selection or editor_debug_break.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the 3D editor viewport camera position.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The verb 'Get' clearly signals a non-mutating read operation, and no side effects are implied. It could add context about prerequisites or coordinate space, but for a simple getter, the description is sufficiently transparent.
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 of eight words, front-loaded with the verb 'Get' and a direct, specific object. Every word is essential, and there is no wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description adequately conveys what it does and what it returns (position). It lacks explicit details on return type or coordinate system, but such details are not critical for a simple getter and the description remains complete enough for effective selection and invocation.
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 schema coverage is trivially 100% and the baseline score for no parameters is 4. The description correctly does not attempt to explain nonexistent parameters, adding no noise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource '3D editor viewport camera' and the attribute 'position', clearly distinguishing it from sibling tools like editor_set_camera (set vs get) and read_camera (which reads a camera node's properties). This makes the purpose unambiguous and highly specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for retrieving the 3D editor viewport camera position, implying when it should be used. However, it does not explicitly mention alternatives or exclusions, such as when to use read_camera or list_cameras instead, so it falls short of the highest rating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open Godot documentation for a class in browser.
| Name | Required | Description | Default |
|---|---|---|---|
| class | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states the side effect of opening a browser, which is transparent. However, it does not disclose potential failures (e.g., if the class does not exist) or whether it is read-only, though that is implied. The description adds some behavioral context beyond the tool name but lacks depth.
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, front-loaded with the action, and contains zero superfluous words. It is a model of concise, straightforward prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with one parameter and no output schema, so a short description is appropriate. However, given the large number of sibling tools that involve classes and documentation, the description could provide more context (e.g., that it opens the online documentation, or that it is suitable for viewing class references). It is minimally viable but leaves some ambiguity.
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 0%, so the description must compensate. It mentions 'for a class', indicating the 'class' parameter is a Godot class name, but it does not specify the expected format, whether it should be a fully qualified name, or provide examples. The compensation is minimal, leaving the agent to infer the exact parameter value semantics.
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 'Open Godot documentation for a class in browser' uses a specific verb ('Open') with a clear resource ('Godot documentation for a class') and destination ('in browser'). This distinctly differentiates it from sibling tools like editor_get_class_list (which returns a list) and editor_get_class_properties (which returns properties).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as editor_search_help, editor_get_class_list, or editor_get_class_properties. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Godot classes, optionally filtered.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | ||
| extends | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It only promises 'all Godot classes' and optional filtering, without mentioning return format, ordering, or whether project classes are included. This is minimal for a tool with zero annotation support.
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?
It's a single front-loaded sentence with no filler. It states the action and resource immediately, earning every word.
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 two undocumented optional parameters, no annotations, and no output schema. The one-line description leaves critical information about parameters and return values unspecified, making it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description adds no meaning for 'filter' or 'extends' beyond calling filtering optional. The agent has no idea how to use these 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 uses the specific verb 'List' with the resource 'all Godot classes' and notes optional filtering. This clearly distinguishes it from sibling tools like editor_get_class_doc or editor_get_class_properties, which target individual class details.
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 context or alternatives are mentioned. It doesn't say when to prefer this over other editor_get_class_* tools or list tools, leaving the agent to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all editor-visible properties of a class.
| Name | Required | Description | Default |
|---|---|---|---|
| class | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral information. It implies a read-only operation via 'List' but does not state side effects, output structure, error conditions, or any constraints. This is a minimal statement without extra context.
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 that states the core function without waste. It is appropriately 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?
While the tool is simple (one parameter, no output schema), the description lacks essential context: it does not specify what the returned list contains, how to format the 'class' argument, or when this tool is preferred over its many sibling introspection tools. With no annotations or output schema, this 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?
The schema has one required parameter, 'class', with no schema-level description (0% coverage). The description only says 'of a class', which largely repeats the parameter name and does not explain expected value format, such as whether a script path, class name, or other identifier is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and names the resource 'editor-visible properties of a class,' clearly distinguishing it from sibling tools like editor_get_class_signals or editor_get_method_list. It directly states the 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?
No guidance is provided about when to choose this over alternatives such as editor_get_class_signals or editor_get_method_list, nor any context for use cases. It simply states what the tool does, so the agent receives no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all signals of a Godot class.
| Name | Required | Description | Default |
|---|---|---|---|
| class | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It only states a simple listing operation and does not disclose whether inherited signals are included, the expected format of the 'class' parameter, or the structure of the returned data. This is minimal and relies on inference.
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 short sentence that is direct, front-loaded, and wastes no words. It effectively communicates the core purpose with minimal verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description provides the essential action but lacks detail on parameter format and expected return. Given the existence of many sibling tools, it does not fully contextualize how this tool fits within the broader set, and the absence of an output schema increases the need for description-level clarity.
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 has one required parameter 'class' with no description (0% coverage). The description's wording 'of a Godot class' clarifies that the parameter refers to a Godot class, but it does not specify whether this is a class name, path, or other identifier. This adds slight meaning beyond the raw schema but leaves room for 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 uses the specific verb 'List' and clearly identifies the resource as 'signals of a Godot class', distinguishing it from sibling tools that list properties or methods. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like editor_get_method_list or list_all_signals. No prerequisites or context are provided, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get local variables from debugger.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it only states the action without noting prerequisites, side effects, or what happens when the debugger is not active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys the tool's purpose without extraneous 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?
The description omits critical context such as the dependency on an active debugging session and does not describe return values, which is especially important given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100% (empty object). The description adds no parameter info, but with zero parameters the baseline 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 verb 'Get' and the resource 'local variables from debugger', which is specific and distinguishes it from sibling tools like editor_get_stack_trace or editor_debug_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?
There is no guidance on when to use this tool, such as requiring a paused debugger or selected stack frame, nor any mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all resource dependencies for a file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only operation but does not state safety, error behavior, return format, or any side effects. It also doesn't clarify whether dependencies are resolved transitively or only direct.
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, front-loaded with the action. It is appropriately sized for a simple tool, though it could be slightly more specific 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 absence of an output schema, the description should explain what the returned dependency list contains (e.g., array of paths, resource IDs). It also doesn't mention failure conditions or editor-state requirements. The tool's behavior remains ambiguous despite its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'path' only as a string; the description adds 'for a file,' giving minimal context. However, it does not specify whether the path should be absolute, relative, project-relative, or a resource path, and there is no parameter-level description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('resource dependencies') and names the target ('a file'). However, it does not distinguish itself from sibling tool 'scene_dependency_graph', which likely overlaps in functionality.
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?
Provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or comparison to sibling tools like 'scene_dependency_graph'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an editor preference value.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Setting key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Read' without detailing the return value, potential errors (e.g., if the key doesn't exist), or whether the operation is strictly read-only. For a getter tool, there is no mention of what the agent should expect in the response, which is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant information. It is front-loaded with the action and resource, making it highly 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?
The tool is simple with one fully documented parameter, but there is no output schema and the description does not state what the tool returns. For a read operation, it would be valuable to mention the return value or that it returns the value associated with the key. The description is minimally adequate but leaves the return semantics undisclosed.
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 description for 'key' is 'Setting key', covering 100% of the parameter meaning. The description adds no extra context beyond the schema, so the baseline score of 3 is appropriate. No examples or clarification of the key format are given.
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 'Read an editor preference value' uses a specific verb ('Read') and resource ('editor preference'), clearly distinguishing it from sibling tools like editor_get_project_setting and editor_set_editor_setting. The purpose is immediately clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need to read an editor preference value. However, it does not explicitly mention alternatives or contexts, such as 'use this instead of editor_get_project_setting for editor-level settings.' The usage is self-evident but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current editor error/log list.
| 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 the full responsibility for behavioral disclosure. It states the tool 'gets' the list, implying a read-only operation, but it does not mention whether reading affects the list (e.g., clearing), or any other side effects. For a parameterless getter, this is minimally adequate but still thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word carries meaning and it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read operation with no output schema, the description covers the essential purpose. It lacks detail about the returned data structure or exact log scope, but these are minor gaps given the tool's straightforward nature.
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 and the schema coverage is effectively complete (empty schema). The description adds meaning by clarifying what 'current editor error/log list' refers to, which is sufficient for a resource-identifying tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'get' and identifies a clear resource: 'current editor error/log list'. It distinguishes itself from the sibling 'editor_clear_errors' by implying retrieval rather than clearing, though it does not explicitly call out that distinction.
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 vs alternatives. There is no mention of prerequisites (e.g., editor running) or exclusions. The single sentence simply states the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get editor status info.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it merely restates the tool's name without explaining what 'status info' includes, whether the operation is read-only, or what the return format is. This adds almost no behavioral context beyond the tool 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 a single sentence with no fluff, which is concise, but it is also under-specified. It lacks any additional structure or elaboration that would make it genuinely helpful, so it sits at an average level.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having zero parameters and no complex schema, the description fails to clarify what 'editor status info' encompasses or what a caller should expect in the response. Given the presence of several overlapping sibling tools, the description is insufficient for disambiguation or setting correct expectations.
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 score of 4 is appropriate. The input schema is empty, and the description does not need to explain parameter details since there are none to document.
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 action ('Get') and resource ('editor status info'), making its basic purpose understandable. However, it does not distinguish itself from sibling tools like 'get_status' or 'editor_health_check', which also appear to retrieve editor-related status information.
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 choose this tool over alternatives such as 'get_status', 'editor_health_check', or 'is_editor_running'. There are no context signals, exclusions, or recommended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the Input Map via editor API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Read', implying non-destructive behavior, but offers no additional context such as return format, side effects, or requirements (e.g., editor running). This is minimal 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?
The description is a single, direct sentence with no filler. It immediately states the action and object, making it easy to parse. This is appropriately concise for a zero-parameter read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should ideally explain what the tool returns or any operational context. It does not, leaving ambiguity about the result format and how it differs from 'read_input_map'. The tool's simplicity is not a substitute for essential operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. Per the rubric, the baseline for 0 params is 4. The description adds nothing beyond the schema because there are no parameters to describe, but the baseline already accounts for this.
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 ('Read') and the target resource ('Input Map'), with the qualifier 'via editor API' indicating it uses the editor-specific interface. However, it does not explicitly differentiate itself from the sibling tool 'read_input_map', which could be confusing for an agent deciding between the two.
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. There is a similar sibling 'read_input_map' which could be a viable alternative, but the description does not clarify the relationship or provide any context for selection. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all methods of a Godot class.
| Name | Required | Description | Default |
|---|---|---|---|
| class | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states it lists methods, but does not disclose whether this includes inherited methods, the return format, or any side effects. This is minimal behavioral 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 concise sentence that is front-loaded with the core action. It avoids unnecessary words and clearly communicates the tool's purpose without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations. The description is too terse to be considered complete; it does not clarify the nature of the returned methods, edge cases, or expected behavior. A minimum viable description should at least state what the output looks like or how the class parameter is used.
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 has one parameter 'class' with 0% description coverage. The description does not explain what 'class' means, what format to use, or provide any examples. The param name gives some indication, but the description does not compensate for the lack of schema detail.
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 a specific action ('list all methods') and a specific resource ('of a Godot class'). It distinguishes itself from sibling tools like editor_get_class_properties or editor_get_class_signals by naming the exact return type.
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 given on when to use this tool vs alternatives. There is no mention of when it is appropriate, what prerequisites exist, or which sibling tools to prefer. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read all editor-visible properties of a node.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Node path to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a read operation, implying non-destructive behavior, and introduces the 'editor-visible' scope. However, it does not detail error handling, output structure, or whether inherited properties are included. With no annotations, the description carries the full burden but remains minimal.
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 one concise, front-loaded sentence that directly states the verb and resource. Every word contributes meaning, with no redundancy or irrelevant 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?
The tool is simple with one well-documented parameter, but the description does not explain the return format or usage context, especially since no output schema is provided. It conveys the core purpose but leaves gaps for an agent needing full operational details.
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 coverage is 100% and the sole parameter 'path' is described as 'Node path to inspect' in the schema itself. The tool description adds no further context about path format or usage, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and identifies the resource as 'editor-visible properties of a node,' making the tool's purpose clear. The 'editor-visible' qualifier also differentiates it from siblings like runtime_get_node or type-specific read tools such as read_camera, establishing a distinct 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?
The description offers no explicit guidance on when to use this tool versus alternatives. It does not mention editor context, exclusions, or comparable tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get currently open scene path.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states only that it gets a path, but doesn't disclose what happens if no scene is open (e.g., returns null/empty), the format of the path (absolute vs relative), or any potential side effects. For a getter, the read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant content. It delivers the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with zero parameters and no output schema, the description is minimally adequate. However, it lacks details about edge cases (e.g., no open scene) and return value specifics, which would make it more complete. The tool's simplicity partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so the description doesn't need to explain parameter semantics. The baseline of 4 applies, and the description adds no redundant parameter information.
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 currently open scene path.' uses a specific verb ('Get') and resource ('currently open scene path'), making the tool's function clear. It distinguishes itself from siblings like 'editor_read_current_scene' by specifying 'path', though it doesn't explicitly name alternatives.
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?
There is no guidance on when to use this tool versus alternatives such as 'editor_read_current_scene' or 'read_scene'. The description is purely declarative and provides no context or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get FPS, draw calls, memory usage while game is running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It correctly implies a read-only operation with 'Get' and adds the prerequisite 'while game is running.' However, it does not disclose what happens if the game is not running, nor describe the return format or any side effects, leaving some transparency gaps.
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 of nine words that front-loads the verb and key metrics. It contains no fluff and every word earns 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?
For a simple, parameterless getter, the description covers the essential context: what is retrieved and when. There is no output schema, but listing FPS, draw calls, and memory usage gives a reasonable idea of the return data. It could be more detailed about types or error conditions, but it is sufficient for a tool of this 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?
The tool has zero parameters, so the schema fully covers parameter semantics. According to the rubric, a baseline of 4 is appropriate for parameterless tools, and the description adds no unnecessary parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with a clear resource: performance metrics (FPS, draw calls, memory usage). It further specifies the timing condition 'while game is running,' which distinguishes this tool from editor-only or project-modification siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'while game is running' provides clear context for when this tool should be used. It does not name alternatives or exclusions, but the timing condition is a useful and explicit guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all installed editor plugins with enabled state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states that the tool lists plugins and their enabled state, which is the core behavior. However, it does not disclose details such as return format, ordering, or potential side effects (though likely none). For a simple list, this is adequate but not rich.
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 that delivers the essential information without any waste. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (zero parameters) and the lack of an output schema, the description provides enough information to understand what the tool returns. It could be slightly more explicit about the shape of the returned list (e.g., array of plugin names with boolean enabled), but the statement 'with enabled state' is reasonably sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%. The description adds meaningful context by confirming that the output includes enabled state, which is valuable for a parameterless tool. No further parameter-level 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 uses a specific verb 'List' and clearly identifies the resource: 'installed editor plugins'. It also includes the notable detail that the enabled state is included, which differentiates it from other plugin-related tools in the sibling list that modify or enable/disable plugins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a read-only listing tool, but it does not explicitly state when to use it or contrast it with alternatives. Since it's a simple query tool, this is an acceptable though not explicit level of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get project res:// and user:// paths.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the tool's purpose and does not disclose return format, whether the editor must be running, or any side effects. This is insufficient for an agent to fully anticipate 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 a single, front-loaded sentence that uses every word meaningfully. It is concise and directly states the tool's function without any filler or repetition.
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 no annotations, the description is minimal but sufficient for a basic understanding. However, it does not specify the exact return format (e.g., whether it returns an object with 'res://' and 'user://' keys) or any prerequisites, leaving some gaps for an agent.
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 correctly does not mention any parameters, and there is no risk of misleading parameter documentation. It would receive no penalty for missing parameter details since there are none.
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 project res:// and user:// paths' uses a specific verb (Get) and clearly identifies the resource (project paths) and the two path types. It distinguishes itself from sibling tools, as none of the siblings focus on retrieving project paths.
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. It does not mention any context, prerequisites, or exclusion criteria. For a simple getter, the intended usage is somewhat obvious from the name, but the description itself lacks explicit usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a project setting via editor API.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states 'Read' which implies a side-effect-free operation, but it does not explain return values, error behavior for missing keys, or whether the project must be open.
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 short sentence that communicates the core purpose without any wasted words or filler. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema and no annotations, the description is too sparse. It does not specify the return value, how the setting value is delivered, or what happens if the key does not exist. An agent would be left guessing about the tool's behavior and output.
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 has one parameter 'key' with 0% description coverage, and the description provides no explanation of what 'key' means, what valid keys look like, or the expected format. The description adds no semantic value beyond the parameter name itself.
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 identifies the action ('Read') and the resource ('a project setting'). It also distinguishes this tool from siblings like 'editor_get_editor_setting' by specifying 'project setting' rather than 'editor setting'.
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 offers no guidance on when to use this tool versus alternatives such as 'read_project_config' or 'editor_get_editor_setting'. It does not mention prerequisites, exclusions, or when a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recently opened scene paths.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full transparency burden. It clearly implies a read-only listing operation via 'List', but it does not disclose path format, ordering/recentness criteria, or editor-running requirements. The core behavior is clear enough for a mid score.
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: 'List recently opened scene paths.' It is front-loaded and contains no filler or 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?
For a zero-parameter read-only list tool with no output schema, the description states the return value ('scene paths') and the operation. It is nearly complete, though it omits details like ordering or path format that would make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is already complete and there is nothing for the description to add. The 0-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('recently opened scene paths'). It distinguishes itself from sibling tools like editor_get_open_scene and list_scenes by focusing on historical/recently opened 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?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites (e.g., editor must be running), nor any contrast with similar tools like editor_get_open_scene or editor_read_current_scene.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get editor window dimensions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation with no side effects, but the description does not clarify whether dimensions are in screen coordinates or relative to the editor viewport, nor does it specify the return type (e.g., Rect2). This is a minor gap for a simple getter.
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 6-word sentence, immediately front-loaded with the verb and resource. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only getter, the description captures the core behavior. It does not state the return format or units of the dimensions, which—since there is no output schema—would be helpful for an agent to consume the result correctly. Still, the simplicity of the tool makes this adequate at a high level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter descriptions needed. Per the rubric, a baseline of 4 is appropriate since there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('editor window dimensions'), clearly distinguishing it from other sibling getters like editor_get_selection or get_godot_version. The tool name editor_get_rect aligns with the description, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a simple read-only query with an obvious use case: retrieving the editor's window dimensions. There are no alternative sibling tools for this exact purpose, so the context is clear even though explicit when-to-use guidance is not provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the live scene tree while the game is running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the condition (game running) but does not describe the return format, whether it is a snapshot or live reference, or what happens if the game is not running. This leaves significant behavioral ambiguity.
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 filler or redundant information. It is front-loaded with the key action and resource, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with zero parameters, but there is no output schema, so the description should explain the return value shape. It only says 'live scene tree' without describing its structure or format, which is a notable gap for an agent that must interpret the result. Additional detail about the return type would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so according to the rubric the baseline is 4. The description correctly adds no parameter details because there are none to describe, and the schema already covers 100% of the (empty) parameter set.
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 'Get', the resource 'live scene tree', and the scope 'while the game is running'. This effectively differentiates it from sibling tools like editor_read_current_scene or read_scene which operate on the editor tree or files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'while the game is running' implies the primary use case, but there is no explicit guidance on when to use this tool versus alternatives like runtime_get_tree or read_scene. No exclusions or alternative tool names are mentioned, so the usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if current scene has unsaved changes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden, but it only states the condition being checked. It does not disclose the return type (e.g., boolean), behavior when no scene is open, or whether it considers only scene resources versus project settings. This leaves important behavioral traits undocumented.
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, readable sentence with no redundant information. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the description omits the return value type and edge-case behavior (e.g., no scene open). Since there is no output schema, this is a notable gap for an agent to correctly interpret the response, making the description minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so parameter semantics are trivially covered. The baseline of 4 applies because no parameter information is needed, and the description does not need to clarify any argument details.
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 a specific verb ('check') and resource ('current scene has unsaved changes'), distinguishing it from other editor tools like editor_save or editor_get_open_scene. The purpose is unambiguous and the scope is explicit.
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, such as before saving or as a precondition for editor_save. There are no exclusions, prerequisites, or contextual hints to help an agent choose this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get selected nodes in editor.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the basic action and does not reveal any behavior beyond that—no return format, no indication of whether the result is a list of node paths, no mention of empty selection, or any side effects. The description is too sparse to be informative.
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 of six words, with no wasted words. It is concise and front-loaded, conveying the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is very simple, but without an output schema, the description should clarify what is returned (e.g., node paths, node objects). The current text states the result (selected nodes) but not the format or structure, leaving a gap for an agent invoking the 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?
The tool has zero parameters, so the description does not need to explain parameter details. The baseline for 0 parameters is 4, and the description does not conflict with the empty 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 'Get selected nodes in editor' uses a specific verb (Get) and resource (selected nodes), clearly distinguishing it from sibling tools like editor_set_selection. It communicates exactly what the tool does with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving the current selection, but it does not explicitly state when to use it versus alternatives like editor_set_selection or editor_delete_selected. There is no mention of prerequisites (e.g., an active scene) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current call stack from debugger.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only states the basic action and fails to mention prerequisites (e.g., debugger must be running), potential failure modes, or what is returned in edge cases. The lack of such details makes it minimally transparent.
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 of seven words, immediately conveying the core function without any filler. It is front-loaded and perfectly sized for the tool's simplicity.
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?
While the tool itself is simple, the description lacks contextual details about when it is valid (e.g., only during an active debug session) and what the return value looks like. Since there is no output schema, the description should fill this gap but does not, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%, so there is nothing to document. Baseline for 0 params is 4, and the description adds no unnecessary parameter information, correctly leaving it at that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as 'current call stack from debugger,' making the tool's purpose unmistakable. This clearly distinguishes it from sibling tools like editor_get_debug_variables or editor_debug_break, which serve different debugging functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is associated with the debugger, implying it should be used when debugging is active. However, it does not explicitly mention when not to use it or offer alternatives, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if the Godot editor plugin is reachable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool checks reachability, but does not describe what happens in success or failure, return format, side effects, or whether it is a read-only operation. This is minimal disclosure for a tool that may involve network or plugin 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 that fronts the core purpose. It avoids unnecessary words and is easy to scan. Every word adds value, though the content is limited.
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 there is no output schema, the description should explain what the tool returns or how the result is presented, but it does not mention return values, error behavior, or how to interpret the health check. The lack of usage context makes it incomplete for an agent to confidently invoke and act on the result, despite the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100% (empty). Per the rubric, a 0-parameter tool gets a baseline score of 4. The description does not need to add parameter details since there are none, and it introduces no confusion about arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: verifying that the Godot editor plugin is reachable. It uses a specific verb ('check') and identifies the resource ('Godot editor plugin'), which distinguishes it from related tools like is_editor_running or get_status. However, it could be more explicit about what 'reachable' means (e.g., network connectivity, plugin loaded), leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives. It does not mention prerequisites, exclusions, or recommended usage scenarios, such as checking the plugin before invoking other editor commands. This lacks helpful context for an agent deciding between editor_health_check and sibling tools like is_editor_running or get_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Instantiate a PackedScene into the current scene.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| scene | Yes | PackedScene path to instantiate | |
| parent | No | . |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral implications, but it only states the action. It does not mention side effects on the current scene, whether the scene must be already loaded, resource ownership, or if the operation is reversible. This is a significant gap 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 concise sentence that immediately states the core action. It has no fluff or repetition, but is perhaps too terse to cover important details. It is well-structured for readability.
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 three parameters, no annotations, and no output schema, the description is insufficiently complete. It does not explain parameter meanings, return values, side effects, or usage context, which are necessary for safe and correct invocation.
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 only 33% (only 'scene' has a description). The description text does not explain the 'name' or 'parent' parameters, leaving their semantics undocumented. This fails to compensate for the low 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 'Instantiate a PackedScene into the current scene' uses a specific verb (Instantiate) and resource (PackedScene) with a clear target (current scene). This distinguishes it from sibling tools like create_scene or edit_scene, though it does not explicitly name alternatives.
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 given about when to use this tool versus alternatives such as create_scene or editor_add_node. There are no exclusions, prerequisites, or context provided to help an agent choose this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and directories in the editor filesystem.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Directory path | res:// |
| pattern | No | Glob pattern (e.g. "*.gd") | |
| recursive | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action ('List files and directories'), but does not mention scope (res:// vs user://), recursion behavior, pattern matching semantics, or whether it returns full or relative paths. This is a significant gap for a tool with no safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words: 'List files and directories in the editor filesystem.' It is appropriately concise for a straightforward list operation, though it could add a few details 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?
With no output schema, no annotations, and a sparse description, the tool context is incomplete. The description does not clarify what the list contains (files only, directories only, or both), the default path (res:// is in the schema but not mentioned), or the return format. This leaves meaning of the tool's output ambiguous.
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 provides descriptions for 'path' ('Directory path') and 'pattern' ('Glob pattern (e.g. "*.gd")'), covering 67% of parameters. The 'recursive' parameter lacks a description, and the tool description does not compensate for this gap. Since the schema handles most of the semantic load, a 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 uses a specific verb ('List') and identifies a clear resource ('files and directories in the editor filesystem'), which distinguishes it from sibling tools that list specific resource types like list_scenes or list_scripts. It does not explicitly name alternatives, but the editor filesystem scope is sufficiently specific to define its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many other list tools (e.g., list_project_files, list_paths, list_scenes). It lacks any context about typical use cases or exclusions, leaving the agent to guess when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List signals and their connections on a node.
| Name | Required | Description | Default |
|---|---|---|---|
| node | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only listing but doesn't disclose potential failure modes, whether the node must exist, or what the response format contains. The word 'list' hints at a safe operation, but this is not explicitly confirmed and no additional behavioral context is 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 a single, front-loaded sentence with no redundant words. It efficiently communicates the core action and target, earning its place despite missing 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 no output schema and no annotations, the description should explain the result structure and usage context. It only states 'signals and their connections' without specifying what the output looks like, whether it requires a currently open scene, or how node addressing works. This is under-specified even for a simple read 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?
The sole parameter 'node' has no schema description (0% coverage). The description merely says 'on a node' without explaining the expected format (e.g., node path, name, or ID). This fails to compensate for the schema's lack of parameter documentation.
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 a specific verb (List) and resource (signals and their connections on a node). It distinguishes itself from the sibling tool 'list_all_signals' by scoping the listing to a particular 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 is provided on when to use this tool versus similar tools like list_all_signals or editor_get_info. There is no mention of prerequisites such as an open scene or valid node path, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a file to a new location via editor.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only restates the operation name and gives no details about side effects, error handling, overwrite behavior, reference updates, or whether paths are project-relative. This is essentially no additional transparency beyond the tool 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 a single sentence with no fluff, which is concise. However, it is under-specified to the point of being minimally informative, so it is not well-structured for an agent to act on. It earns its place but does not cover necessary 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 (2 params, no output schema), a short description could suffice, but this one omits critical details like path semantics, overwrite behavior, and how it differs from similar file operations. The presence of many sibling tools (e.g., 'move_file', 'editor_rename_asset') makes this lack of context harmful for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters ('from' and 'to') with no descriptions (0% coverage). The description does not explain what these parameters represent, their expected format (e.g., absolute paths, asset UIDs, project-relative paths), or their relationship. With no schema descriptions, the tool's own description should compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move a file to a new location') and resource ('a file') with a specific context ('via editor'). It is more specific than a tautology and differentiates from non-editor move tools, though it does not explicitly distinguish from the sibling 'move_file'.
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 like 'move_file' or 'editor_rename_asset'. There is no mention of prerequisites, file path constraints, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a 2D/3D node to a new position.
| Name | Required | Description | Default |
|---|---|---|---|
| position | Yes | Position (e.g. "Vector2(100, 200)" or "Vector3(0, 5, 0)") | |
| node_path | Yes | Node path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It only says 'Move' and gives no details about side effects (e.g., whether it modifies the scene file, requires undo support, or whether position is absolute/relative), no coordinate space, and no feedback on success/failure. This is a significant gap 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, focused sentence with no redundant words. It is front-loaded and immediately communicates the core action. This is appropriately concise for an operation with only two parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema), and the schema covers the parameters. However, the description lacks context about how this differs from the many sibling tools, especially 'set_node_position', and does not specify whether it is editor-specific (despite the name) or what happens on invocation. Missing behavioral and usage details reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the baseline is 3. The description adds no extra semantics beyond what the schema already provides (e.g., the meaning of 'position' is already stated with examples). It does not clarify relationships between parameters or type constraints 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 clearly states the action ('Move') and resource ('2D/3D node'), with a specific new position. It distinguishes from rotation/scale tools, but does not differentiate from the nearly identical sibling 'set_node_position', so it lacks explicit sibling differentiation.
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 vs. alternatives like 'set_node_position', 'transform_node', or 'modify_node'. It does not state prerequisites, such as requiring an open scene or the editor running, nor does it mention any excluded contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open an asset in editor.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Asset path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It merely states 'open' without explaining side effects (e.g., whether the editor must be running, if the asset is focused in the UI, or if any editor state changes). This is insufficient for an agent to anticipate outcomes.
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 fluff. It is front-loaded but could benefit from additional context; still, it is appropriately minimal for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has no output schema, no annotations, and only one parameter. The description does not clarify what 'open' entails in the editor, whether it returns a value, or what prerequisites exist. Given the large sibling toolset, the description is too sparse to be contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with 'path' described as 'Asset path'. The tool description adds no semantic value beyond the schema, so the baseline 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 uses a specific verb ('Open') and resource ('asset'), making the core purpose clear. However, it does not differentiate from sibling tools like editor_show_in_filesystem or edit_scene, which also involve accessing assets.
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. With numerous editor_* siblings, the description offers no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a dock: filesystem, inspector, scene, output.
| Name | Required | Description | Default |
|---|---|---|---|
| dock | Yes | Dock name: filesystem, inspector, scene, output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It states the action but does not detail behaviors such as whether the dock toggles, focuses, or errors on invalid input. For such a simple operation, the description is adequate but lacks explicit behavioral nuance.
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 that lists all valid options with zero filler. Every word earns its place, making it highly concise and 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 one parameter and no output, the description plus schema fully cover what the agent needs to know. The list of dock names is included, and the schema provides the parameter type. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for the 'dock' parameter ('Dock name: filesystem, inspector, scene, output'), and the tool description repeats the same list without adding extra meaning. With 100% schema coverage, 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 clearly states the action ('Open') and the resource ('a dock'), and lists the specific dock types (filesystem, inspector, scene, output). This distinguishes it from sibling tools that deal with editing, reading, or creating resources, as it is the only tool explicitly for opening docks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what the tool does and which docks are available, making its intended use obvious. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paste clipboard nodes into the scene (at selected node or root).
| Name | Required | Description | Default |
|---|---|---|---|
| parent | No | Parent node path for paste target (defaults to selected node or scene root) | . |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a mutation operation by saying 'Paste clipboard nodes into the scene' but does not disclose prerequisites (e.g., clipboard content, open scene) or consequences (e.g., undo support, overwriting behavior).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and states the key behavior without any redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—one optional parameter, no output schema—the description covers the primary behavior and target location. It lacks details on preconditions like requiring clipboard contents but is sufficiently complete for a straightforward action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single 'parent' parameter with a clear description. The tool description adds no additional parameter semantics beyond echoing the default location.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Paste' with the resource 'clipboard nodes' and states the target location ('selected node or root'), clearly distinguishing it from sibling tools like editor_copy, editor_cut, and editor_duplicate_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?
It provides context for when to use the tool—pasting clipboard nodes into the scene—and explains the default parent targeting. However, it does not explicitly compare with alternatives or state exclusions, but the editor clipboard workflow is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause the editor scene tree (note: only affects the editor tree, not a separately running game).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It honestly notes a key behavioral trait: the tool does not affect a separately running game, which is a useful caveat beyond the mere action. However, it omits other potential behaviors like idempotency or side effects, though for a simple no-param tool this is sufficient.
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 two sentences, with the second sentence adding a critical caveat. Every word earns its place, and the key information is 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 simplicity of the tool (no parameters, no output schema), the description fully covers the essential purpose and a significant limitation. It is complete for an agent to understand what the tool does and what it does not do.
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. There are no parameter semantics to clarify, and the description correctly focuses on the action rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Pause the editor scene tree'. It clearly identifies the target (editor scene tree) and distinguishes this from pausing a running game via the note, making its purpose unmistakable and differentiating it from sibling tools like runtime_freeze or stop_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 provides a clear context for use by noting it 'only affects the editor tree, not a separately running game'. This exclusion helps the agent know when not to use it, although it does not explicitly reference sibling tools like editor_unpause or runtime_freeze as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Play project from editor.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Play project from editor' and does not mention potential side effects, whether it blocks, or how it interacts with the editor's running state, which is insufficient for a tool that likely affects project execution.
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 at five words, with no filler, and the key verb is front-loaded. However, it is so terse that it might sacrifice useful context, making it slightly under-specified for a tool that could affect the editor's runtime.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema and no annotations, the description is minimally adequate but lacks important context such as whether it stops an already-running project, requires an open project, or how it differs from simply running the project externally. This is a clear gap but acceptable for a very simple action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is nothing to describe. Per the rubric, the baseline for 0 params is 4, and the description adds no param information but doesn't need to.
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 (Play), resource (project), and context (from editor), making the tool's purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like run_project or launch_editor, leaving some ambiguity about the exact 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 usage guidance is provided. The description simply states the action without indicating when to choose this tool over alternatives such as run_project or editor_stop, leaving it to the agent to infer based on sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read live editor scene tree.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Read' implies a non-destructive lookup, but the description doesn't disclose whether the editor must be running, whether unsaved changes are reflected, what 'live' means operationally, or what error conditions may arise.
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 — four words with no filler and good front-loading. It earns a high score for efficiency, though the brevity sacrifices clarifying detail about return values or behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations. The description only names the resource, leaving unclear what the returned scene tree contains, whether it includes node properties/hierarchy details, and how it differs from file-based scene reads. An agent would need to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters) and schema coverage is 100%, so there are no parameters to document. The description adds no parameter detail, but none is required in this case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' with a clear resource ('live editor scene tree'), and the tool name identifies 'current_scene.' It conveys the operation reasonably but doesn't explicitly contrast with siblings like editor_get_running_scene_tree or read_scene, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over siblings such as editor_get_running_scene_tree, runtime_get_tree, read_scene, or editor_get_open_scene. It also doesn't state prerequisites like needing an open scene or whether this should be used only during editing sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Redo last undone action.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It only restates the core function and fails to mention edge cases (e.g., behavior when there is no undone action), side effects, or any state requirements. The description adds no context beyond what the name implies.
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, short sentence that efficiently states the action. No unnecessary words or repetition. It is well-structured and 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?
For a zero-parameter tool with no output schema, the description is adequate but incomplete. It does not state usage context (e.g., that it should follow an undo) or potential failure scenarios. The absence of annotations and output schema increases the need for such details, making this minimal description only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. There are no parameters to describe, and the description does not need to add parameter semantics. The trivial 100% schema coverage makes this dimension minimally satisfied.
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 'Redo last undone action' clearly identifies the tool's function with a specific verb and resource, and it semantically contrasts with sibling tool editor_undo. It is unambiguous about what action is performed.
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 given on when to use this tool versus alternatives like editor_undo. The description merely states the function without specifying prerequisites, context, or that it should be used after an undo operation. There are no exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force reimport of an asset.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing behavioral effects. 'Force reimport' implies overwriting existing imported artifacts, but it does not state consequences like potential data loss, performance impact, or the need for the asset to exist. This is a significant gap for a mutating operation.
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 wasted words. However, it is so brief that it sacrifices useful detail, making it more an under-specification than ideal 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?
For a force operation with one required parameter and no output schema or annotations, the description is too minimal. It omits return behavior, error conditions, and any prerequisites (e.g., asset must exist). The tool appears to be a lower-risk operation, but the context is 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 description coverage is 0%, and the description does not explain what 'path' refers to (e.g., filesystem path, resource path, relative/absolute) or any expected format. The sole parameter's meaning is left ambiguous beyond its name.
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 'Force reimport of an asset' uses a specific verb and resource, clearly stating the action. It distinguishes itself from sibling tools like editor_open_asset or editor_delete_asset by focusing on reimporting.
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, such as when an asset's import settings have changed or when to prefer fix_missing_uids or validate_project. No context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save and reload current scene.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It mentions saving and reloading but does not clarify side effects such as discarding unsaved changes (though it saves first), potential editor state resets, or failure conditions. This is insufficient for a tool with no annotation support.
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, direct and front-loaded. There is no wasted text, making it efficient for quick comprehension.
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 there are no parameters, no output schema, and no annotations, the description is the only source of context. It adequately states the action but lacks usage context, side effects, and alternatives. It is minimally complete but not rich.
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 the schema is complete. The description does not need to explain parameter meanings; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves and reloads the current scene, using a specific verb and resource. It distinguishes itself from sibling tools like editor_save by including the reload action, though it could be more explicit about what reloading entails (e.g., from disk, after save).
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?
There is no guidance on when to use this tool versus alternatives like editor_save or editor_save_all. The description implies usage after scene modifications but does not state explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an autoload singleton via editor API.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses the action but fails to mention side effects, reversibility, persistence, or any required permissions. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and immediately understandable, though it sacrifices depth 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?
For a simple tool with one parameter and no output schema, the description is minimal. It lacks context about when the removal takes effect, whether it updates project configuration, or any prerequisites. The absence of annotations makes this 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?
With 0% schema description coverage, the description should compensate by explaining the 'name' parameter. It does not, leaving the agent to infer that 'name' refers to the autoload singleton's name, which is plausible but not explicitly stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Remove' and resource 'autoload singleton', clearly stating the tool's action. However, it doesn't differentiate from the sibling tool 'remove_autoload', which appears to serve a similar 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 guidance is provided on when to use this tool versus alternatives. The phrase 'via editor API' hints at a specific context but doesn't explicitly state when this version is preferred over 'remove_autoload' or any other approach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a breakpoint from a script.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | Line number | |
| script | Yes | Script path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects, failure modes (e.g., what if the breakpoint doesn't exist), or whether the removal is session-only or persists. This lack of detail is a significant gap 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, front-loaded sentence with no redundant information. Every word contributes to clarity.
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 two-parameter tool, the description is minimally viable, but it omits behavioral context such as what happens when the breakpoint doesn't exist or whether the script must be open. With no annotations and no output schema, additional detail 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?
Schema description coverage is 100%, with parameters 'script' and 'line' clearly documented. The description adds no additional parameter meaning, but per the rubric, the high schema coverage establishes a baseline of 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 uses a specific verb 'remove' with a clear resource 'breakpoint' and scope 'from a script'. It distinguishes itself from sibling tools like editor_set_breakpoint (adds) and editor_get_breakpoints (lists), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to remove a breakpoint from a script). While it doesn't explicitly mention alternatives or exclusions, the purpose is self-evident enough that no additional guidance is needed for this simple operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an input action via editor API.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the removal action but omits important details such as whether the operation is destructive, irreversible, or requires specific permissions, and what happens if the named input action does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. It is appropriately brief and front-loaded with the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no annotations and no output schema. The description does not elaborate on the broader context of input actions, error conditions, or side effects, making it insufficiently complete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'name' with no description, and schema description coverage is 0%. The tool description does not explicitly explain that 'name' refers to the input action's identifier, leaving the agent to infer this from the tool name and description.
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') and the target resource ('an input action') while specifying the context ('via editor API'). This distinguishes it from the related sibling 'remove_input_action' by explicitly indicating it operates through the editor API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when this is preferred over 'remove_input_action' or other editor removal tools, or any contextual cues for usage.
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 the currently open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Node path to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Remove a node' without addressing whether the removal is permanent, undoable, whether child nodes are affected, what happens if the path is invalid, or any other side effects. This is a significant gap for a destructive operation.
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 that contains no redundant or irrelevant content. Every word contributes to conveying the core purpose. This is a model of 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?
While the tool is simple with one parameter, it is a mutation with no annotations and no output schema. The description lacks critical context such as whether the removal affects the saved file, whether it is undoable, and what error behavior is expected. This makes it inadequate for an agent to fully understand the tool's consequences.
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 fully describes the single parameter 'path' as 'Node path to remove'. The description adds no additional parameter-specific details, such as path format or interpretation. Since schema coverage is 100%, the baseline score of 3 applies; the description does not elevate above 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 uses a specific verb ('Remove') and clearly identifies the resource ('a node') and the scope ('currently open scene'). This makes the tool's purpose immediately clear and distinguishes it from generic removal tools, as it specifically targets nodes in the open 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 phrase 'currently open scene' provides a clear contextual prerequisite for when the tool can be used. It does not explicitly mention alternatives or when not to use it, but the context is clear and no exclusions are stated, aligning with the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a file via editor filesystem.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states that renaming occurs via the editor filesystem, but does not reveal whether the operation overwrites existing files, handles references, or requires specific permissions. This is a significant gap 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 one concise sentence with no wasted words. It is appropriately short for such a simple operation, though it could have included 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 tool's simplicity, the description is minimal but insufficient. It lacks guidance on side effects, whether the rename moves the file across directories, updates references, or has any restrictions. With no annotations and no output schema, the description should provide more context to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'from' and 'to' parameters. The parameter names are self-explanatory for a rename operation, but the description adds no details about path formats, asset identifiers, or constraints, leaving the agent to infer meaning from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Rename a file via editor filesystem.' It clearly indicates the tool's function but does not distinguish it from siblings like editor_move_asset or rename_node, which could also rename assets or nodes.
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 information is provided about when to use this tool versus alternatives. The description only states what it does, without any context on prerequisites, scenarios, or exclusions, leaving the agent without guidance on selecting it over similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a node in the editor.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | New name | |
| path | Yes | Node path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention potential effects on references, whether the operation is limited to specific node types, or any side effects. This is a minimal statement for a mutation operation.
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 unnecessary words. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the lack of annotations and output schema means the description should provide more context about the rename operation. It does not explain what happens to references, whether confirmation is needed, or how the rename integrates with the editor's undo system. This is insufficient 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?
Schema description coverage is 100% with simple parameters ('path' and 'name') already described as 'Node path' and 'New name'. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rename') and target ('a node in the editor'), providing a specific verb+resource. It does not explicitly differentiate from the sibling 'rename_node' tool, but the 'editor' qualifier offers some 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?
No guidance is given on when to use this tool versus alternatives like 'rename_node' or other node-editing tools. There are no exclusions or conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a node to a new parent.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Node path | |
| new_parent | Yes | New parent path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only states the core action and does not mention side effects, validation requirements (e.g., parent must exist), transform preservation, or whether this is a destructive change. This is minimal but not misleading.
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 or redundancy. It front-loads the core action ('Move') and the key object ('node to a new parent'), making it immediately understandable. This is an example of appropriately economical writing.
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 (2 well-documented parameters, no output schema), the description provides the minimum viable information to understand the operation. However, it lacks behavioral context such as whether the node's global transform is preserved, what happens on failure, or any prerequisites. It is adequate but leaves gaps for a tool that modifies the scene tree.
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 clear parameter descriptions ('Node path' and 'New parent path'). The description adds marginal value by clarifying the relationship between the two parameters (moving from one parent to another), but it does not go beyond what the schema already conveys. 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 'Move a node to a new parent' clearly specifies the verb 'move' and the resource 'node to a new parent', which precisely distinguishes reparenting from other node operations like editor_move_node (position) or rename_node. The phrase 'new parent' leaves no ambiguity about the operation's intent.
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. Sibling tools like editor_move_node, modify_node, and remove_node exist, but the description does not mention any context, prerequisites, or exclusions. The agent is left to infer the tool's specific use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute arbitrary GDScript code in editor context.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | GDScript code to execute in editor context |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'in editor context', but fails to mention that arbitrary code execution can modify project files, crash the editor, or have other side effects. No information about return values, error handling, or execution scope is 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 a single, clear sentence that immediately conveys the tool's core function. It is appropriately sized with no wasted words, front-loading the key 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?
For a powerful code execution tool with no output schema and no annotations, the description is under-specified. It does not mention whether the code returns a value, what happens on errors, or the potential impact on the editor project. The agent is left without critical context needed to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with a description for the 'code' parameter, so the baseline is 3. The tool description does not add extra meaning beyond the schema's description, leaving the agent with only the basic understanding that 'code' is 'GDScript code to execute in editor context'.
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 executes arbitrary GDScript code in the editor context, using a specific verb and resource. It distinguishes itself from siblings like editor_evaluate_expression (which evaluates expressions) and runtime_call_method (which runs in runtime), making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as editor_evaluate_expression or validate_script. The description does not mention any exclusions, prerequisites, or preferred use cases, leaving the agent without context for choosing between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a specific scene (not just main).
| Name | Required | Description | Default |
|---|---|---|---|
| scene | Yes | Scene path to run (e.g. "res://scenes/level1.tscn") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning side effects (e.g., launching a game window, stopping current runs) or requirements (e.g., editor must be running). This is a gap for a tool that presumably mutates the running 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 sentence that is directly front-loaded with the core action ('Run a specific scene') and immediately adds the distinguishing scope ('not just main'). Every word earns its place, making it 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?
The tool is simple with only one parameter and no output schema, so completeness needs are relatively low. However, the description lacks behavioral and usage details (e.g., side effects, when to use), making it minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the 'scene' parameter is fully described with an example ('res://scenes/level1.tscn'). The tool description adds no extra parameter semantics, so the 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 tool's action ('Run a specific scene') and distinguishes it from running the main scene via the parenthetical '(not just main)'. This satisfies the verb+resource criterion, though it could be more explicit about the editor 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 phrase 'not just main' implies the tool is for non-main scenes, providing some situational context. However, it does not explicitly name alternatives like run_project or editor_play, nor does it give exclusions or prerequisites, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save current scene in editor.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavior disclosure. It only states the action without mentioning side effects, prerequisites (e.g., editor running), or failure modes, leaving the agent to infer the full 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 a single, front-loaded sentence with no redundant words. It is appropriately concise for the tool's simplicity.
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 and no output schema, the description adequately covers the core function. It could mention that the editor must be running, but this is largely implied by 'in editor' and is not critical for such a simple 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?
The tool has zero parameters, and the empty schema is fully covered. According to the rubric, a baseline of 4 applies because there is no parameter information needed beyond what the schema already confirms.
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 ('Save') and the resource ('current scene') in the editor context. This distinguishes it from the sibling editor_save_all by explicitly scoping to the current 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 implies the tool is for saving the current scene but does not explicitly mention when to use it versus alternatives like editor_save_all. No exclusion criteria or additional context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save all open scenes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action ('Save all open scenes') without disclosing potential side effects such as whether it prompts for confirmation, overwrites files directly, or fails if no scenes are open. The behavior is minimal but not hidden; still, key details are missing.
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 zero waste. It is front-loaded and to the point, earning a perfect score for conciseness and structure.
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 no parameters, no output schema, and no annotations, but the description adequately covers its core function. It does not mention return values or edge cases, but for a simple save operation the description is sufficiently complete for an agent to understand what it does.
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 the schema description coverage is 100% vacuously. Since there are no parameters to explain, the description is not required to add parameter details, achieving the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Save') and resource ('all open scenes'), clearly distinguishing this tool from sibling 'editor_save' which saves a single scene. It fully states what the tool does in a straightforward manner.
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. While the name implies saving all open scenes versus single scene, the description does not explicitly mention when to choose this over 'editor_save' or any other save-related tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Godot documentation in browser.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It hints at opening a browser but does not mention side effects like launching an external browser, requiring internet access, or whether the tool returns any result synchronously. The behavioral profile is under-specified.
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 fluff or redundancy. Every word contributes to stating the core function, making it very efficient. However, the extreme brevity also contributes to the lack of contextual information scored elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter, no annotations, and no output schema, the description is too skeletal. It fails to explain how 'query' is used, what the tool returns (if anything), or how it compares to sibling search tools. Critical context needed for correct invocation 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 0%, and the description does not mention the 'query' parameter at all. The name 'query' might imply a search term, but no detail about format, expected content, or behavior is provided. The description completely fails to compensate for the schema's lack of parameter documentation.
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 'Search Godot documentation in browser' clearly states the verb (Search) and resource (Godot documentation in browser), making the tool's purpose easy to understand. It doesn't explicitly differentiate from sibling search tools like search_in_project or search_in_scripts, but the specificity of 'documentation in browser' provides reasonable distinction.
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 like search_in_project, search_in_scripts, or search_tools. There is no mention of scenarios, exclusions, or relationships to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on an AnimatedSprite node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It says 'Set a property' (a mutation) but does not mention reversibility, permissions, error handling if the node/path is invalid, or whether changes are auto-saved. This is a significant gap 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, concise sentence that directly communicates the tool's function without unnecessary words. It is front-loaded and every word earns 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?
The tool is a simple setter with fully described parameters and no output schema needed. The description provides the key context (open scene, AnimatedSprite, property). However, given no annotations and no mention of side effects or error conditions, it remains minimally complete but not rich enough for a higher score.
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's description coverage is 100% for the three parameters (node_path, param, value), with each having a clear description including examples. The tool description itself does not add additional parameter syntax or constraints beyond what the schema already provides, so a 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 a specific verb ('Set'), a distinct resource ('property on an AnimatedSprite node'), and the context ('in the open scene'). This differentiates it from the many sibling editor_set_*_param tools by specifying the node type, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the node type and the action, but it does not explicitly discuss when to prefer this tool over alternatives like editor_set_node_properties or other specific setters. There are no exclusions or alternative recommendations, leaving the agent to infer based on the node type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on an Area2D/3D node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'set a property' without explaining side effects, error handling, reversibility, or persistence. This leaves the agent without important execution context for a mutating operation.
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, front-loaded with the verb, and contains no redundant information. It is concise and well-structured, with every word adding value.
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 setter tool with fully documented parameters, the description conveys the essential purpose and target node type. However, it lacks operational context such as failure modes, return behavior, and explicit differentiation from sibling tools, making it minimally adequate but not rich.
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 adds no extra meaning beyond the schema; it does not elaborate on node_path, param, or value beyond what the schema already provides.
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 'Set a property on an Area2D/3D node in the open scene,' identifying the action, target resource type, and context. This distinguishes it from sibling tools that target other node types or perform broader operations like editor_set_node_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as editor_set_node_properties or other editor_set_*_param tools. It merely states the action without any when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on an AudioListener node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It says 'Set' which implies a mutation, but it doesn't disclose whether the node must exist, whether the change is saved to the scene file, or any validation/error behavior. This is minimal transparency for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that immediately conveys the action and target. No wasted words or repetition of schema 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?
For a simple setter with fully documented parameters, the description covers the essential context: what it does, on which node type, and where (open scene). It could mention prerequisites or side effects, but given the simplicity and schema coverage, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all three parameters described (node_path, param, value) including examples for param and value. The description adds no extra parameter meaning, so the baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set a property') and the specific resource ('an AudioListener node in the open scene'). This distinguishes it from sibling setters for other node types like editor_set_audio_player_param or editor_set_camera_param.
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 clear context by specifying it applies to an AudioListener node in the open scene. While it doesn't explicitly mention alternatives or when-not-to-use, the target node type is unambiguous, allowing an agent to select it appropriately among many setters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on an AudioStreamPlayer node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that the tool performs a mutation (Set) but does not disclose potential errors, side effects, or requirements beyond being in the open scene, leaving key behavioral expectations unexplained.
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 filler, front-loaded with the verb, and directly states the operation and target. It is highly 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 setter with a complete schema, the description is adequate and conveys the essential operation and context. However, it lacks any behavioral caveats or usage guidance beyond the open-scene mention, making it minimally viable but with noticeable 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?
The schema description coverage is 100% for all three parameters, so the baseline is 3. The tool description adds no extra parameter information, and the schema examples are generic rather than AudioStreamPlayer-specific, but the schema itself is complete.
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 identifies the action (Set), the target resource (AudioStreamPlayer node), and the scope (in the open scene). It distinguishes this from sibling set_param tools by explicitly naming the node type.
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 context that the tool operates on the open scene, which implies when it should be used. However, it does not explicitly mention alternatives or when not to use it, though the naming convention makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a breakpoint in a script.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | Line number | |
| script | Yes | Script path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic action without disclosing any behavioral traits such as validation, side effects, or prerequisites (e.g., script must be loaded). Minimal added value beyond the tool 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?
One concise sentence with no unnecessary words. Front-loaded and immediately understandable.
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 tool (no output schema, few parameters, clear action), the description is sufficient. It doesn't explain error handling or preconditions, but for a basic breakpoint set operation this is acceptable.
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 covers 100% of parameters with descriptions ('Script path', 'Line number'). The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear and specific verb+resource: 'Set a breakpoint in a script.' It differentiates from sibling tools like editor_remove_breakpoint and editor_get_breakpoints by stating the action directly.
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?
Implied usage: use when you need to set a breakpoint. No explicit guidance on when not to use, or alternatives, but the context is clear given the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the 3D editor viewport camera position.
| Name | Required | Description | Default |
|---|---|---|---|
| position | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden but only restates the core action. It doesn't disclose side effects, coordinate system, or whether the editor must be running. This minimal disclosure is inadequate for a setter 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, clear sentence that is appropriately front-loaded with the verb. No extraneous information, achieving maximum 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 the minimal schema (0% coverage), lack of annotations, and no output schema, this sparse description is insufficient. It doesn't explain the parameter format or any behavioral caveats, making it incomplete for reliable invocation.
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 0%, and the description does not elaborate on the `position` parameter beyond mapping it to the camera position. It doesn't specify the expected format (e.g., string representation of Vector3), units, or coordinate space, leaving the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and identifies the exact resource ('3D editor viewport camera position'), clearly distinguishing it from sibling tools like `editor_set_camera_param` (which sets camera parameters) and `editor_get_camera` (which retrieves the camera).
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 such as `editor_set_camera_param` or `editor_set_viewport_param`. It states the action but lacks context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on a Camera node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action ('set a property') and does not reveal persistence, error conditions, or how the value literal is interpreted beyond what the schema 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 a single concise sentence that front-loads the verb and resource, with absolutely no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema documents all parameters, but the description lacks any context about return values, side effects, or prerequisites beyond 'open scene'. It is adequate but minimal for a mutation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with clear descriptions (node_path, param, value). The description adds no additional parameter meaning, so the baseline of 3 for high schema coverage 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 identifies the action (set) and the target resource (a property on a Camera node). This distinguishes it from sibling tools that target other node types, such as editor_set_area_param or editor_set_light_param.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use it or mention alternatives. Usage is implied by the tool name and reference to Camera, but there is no guidance on scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on a CharacterBody node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention side effects (e.g., modifying the open scene), prerequisites, error handling, reversibility, or changes saved only on project save. It only restates the basic action without any additional context.
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 unnecessary words. It is front-loaded with the verb and resource, making it easy to parse. It earns its place despite being brief.
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 description is minimal and does not cover usage context, behavioral outcomes, or error scenarios. For a mutation tool with no annotations and no output schema, this is insufficient for an agent to understand the full impact or when to invoke it safely.
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% for all three parameters, each with clear descriptions and examples. The tool description adds no extra parameter semantics beyond what the schema already provides, so the baseline 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 ('Set') and the specific target ('CharacterBody node in the open scene'), which is distinct from sibling tools like editor_set_area_param or editor_set_camera_param. It provides a precise, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for CharacterBody nodes but does not explicitly address when to use this tool versus alternatives like editor_set_node_properties or other param setters. There are no exclusions or alternative recommendations, leaving the agent to infer from the name and resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on a Container node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action ('Set') and context, but does not mention side effects, persistence, required permissions, error handling, or whether changes are immediately applied to the scene. This is a significant gap 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, front-loaded sentence with no redundancy. It efficiently communicates the core purpose without wasting 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?
The tool is simple and the schema is rich, but the description is minimal and does not clarify behavior beyond the bare action. It could benefit from noting that this is a single-property setter for a specific node type, especially given the large set of sibling tools. It is adequate but not comprehensive.
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 (param, value, node_path) having a clear description. The tool description adds no additional parameter details, but the baseline of 3 applies because the schema handles semantics well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set'), resource ('property on a Container node'), and scope ('in the open scene'), clearly distinguishing it from sibling tools that target other node types. This is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it applies to Container nodes in the open scene, but it does not explicitly state when to use this tool over alternatives like editor_set_node_properties or modify_node. No exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on a Decal node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose side effects and requirements, but it only states that a property is set. It does not mention whether the node must already exist, whether changes are persisted, or how invalid properties are handled, which 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, front-loaded sentence with no extraneous words. It immediately conveys the action and target, making it 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 setter with fully documented parameters, the purpose is clear and the parameter semantics are covered by the schema. However, the lack of usage guidance and behavioral detail (e.g., node existence, persistence, error handling) leaves the description incomplete for an agent to select and invoke it confidently among many sibling setters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters with 100% coverage, including examples for param and value. The description adds no additional parameter context or constraints beyond what the schema provides, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Set' and identifies the resource as 'a Decal node in the open scene,' clearly distinguishing it from sibling node-param setters like editor_set_area_param and editor_set_camera_param. The action and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling setter tools (e.g., editor_set_camera_param, set_shader_node_param). The description does not mention alternatives, exclusions, or prerequisites, leaving the agent to infer selection purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set an editor preference.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says 'Set an editor preference.' It does not disclose persistence, validation, permissions, reversibility, or other behavioral traits. This is a mutation tool with zero additional context.
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, grammatically correct sentence and is front-loaded. However, it is under-specified, failing to convey necessary details about the parameters or 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?
The tool is a mutation with 2 parameters, no annotations, no output schema, and no parameter descriptions. The description 'Set an editor preference' is grossly insufficient for an agent to understand what editor preferences are, what values are accepted, or how this differs from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description only implies that 'key' and 'value' refer to a preference name and its value. It does not explain what keys are valid, the expected value format, or provide examples.
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 'Set an editor preference' clearly states the action (set) and the resource (editor preference), distinguishing it from sibling tools like editor_set_project_setting. However, it is minimal and does not elaborate on what editor preferences are.
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. Many sibling tools such as editor_set_project_setting or editor_set_breakpoint exist, and the description gives no context for selecting this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the project main scene.
| Name | Required | Description | Default |
|---|---|---|---|
| scene | Yes | Scene path to set as main |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states only the action 'Set' without revealing potential side effects (e.g., modifying project.godot), whether the change is reversible, or if any validation occurs. This lack of detail is a significant gap 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, succinct sentence with no wasted words or redundancy. It perfectly fits the 'concise' ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema) and full schema coverage, the description is minimally adequate. However, it lacks usage guidance and behavioral transparency, which would make it more complete. It sits at the boundary of 'minimum viable'.
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% for the single parameter 'scene', which is described as 'Scene path to set as main'. The description adds no additional parameter semantics beyond the schema, so the baseline 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 'Set the project main scene' clearly identifies the verb (Set) and resource (project main scene), so the tool's purpose is unambiguous. However, it doesn't explicitly distinguish from sibling tools like editor_set_project_setting, though no direct competitor exists for this specific action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, prerequisites, or whether it's preferred over editing project settings directly. The description simply states the action without any contextual or exclusionary information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on a Marker node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only says 'Set a property' without mentioning side effects, whether the scene is modified on disk, what happens if the node doesn't exist, or any error behavior. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the action and target. There is no redundant or misplaced information, making it highly concise and 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?
Given the tool's simplicity, the schema plus description cover the parameters and basic operation. However, the lack of annotations and absence of any note about prerequisites (beyond 'open scene'), return values, or failure modes leaves the description somewhat incomplete for an agent to fully anticipate the tool's behavior.
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 each parameter having a clear description (e.g., param examples, value format as GDScript literal, node_path in the open scene). The tool description itself adds no extra parameter meaning, so the baseline 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 ('Set a property') and the target ('Marker node in the open scene'), which is a specific verb+resource combination. It distinguishes itself from sibling tools like editor_set_area_param or editor_set_camera_param by explicitly naming Marker nodes.
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 usage context is implied by the node type: use when setting a Marker property in the open scene. However, it does not explicitly state when not to use this tool or mention alternatives (e.g., other editor_set_*_param tools), so guidance is only moderate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on a MultiplayerSpawner3D node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
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 disclosure. It states a mutation ('Set a property') but does not mention side effects, whether the scene is saved, permissions required, error behavior for non-existent nodes or invalid properties, or any other behavioral traits. This lacks transparency for a write operation.
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 that is front-loaded with the verb and resource, no filler or redundant information. It is appropriately concise for a simple setter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the schema covers all parameters. However, because there is no output schema and no annotations, the description does not disclose important behavioral aspects such as whether the operation is reversible, how errors are reported, or what the tool returns. For a mutation tool, this leaves some gaps in completeness, though the core function is adequately described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the three parameters (param, value, node_path) are each described with examples or additional context. The tool description adds minimal semantic value beyond the schema—it just reinforces that the property belongs to a MultiplayerSpawner3D node, which is already evident from the tool name and schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set a property') and the target resource ('MultiplayerSpawner3D node in the open scene'), which distinguishes it from sibling tools that target other node types. However, it does not specify which properties can be set beyond what the schema already indicates, so it is slightly less rich than the highest examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in the open scene' indicates the tool operates on the currently open scene, giving some context. However, there is no explicit guidance on when to use this tool versus other editor_set_*_param tools, nor any exclusions or prerequisites beyond the implicit scene requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on a MultiplayerSynchronizer3D node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Set a property' and 'in the open scene,' but does not mention side effects, persistence, error handling, or whether the scene must be saved afterward. This is a minimal disclosure 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, clear sentence that directly conveys the tool's purpose without extraneous words. It is well-structured and front-loaded with the core action.
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 schema covers parameter semantics fully, and the description provides the essential 'what' and 'where' (set property on MultiplayerSynchronizer3D in open scene). However, it lacks usage context, behavioral caveats, and any information about return values or outcomes, making it adequate but not thorough for a no-annotation 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?
The input schema already provides complete descriptions for all three parameters (node_path, param, value) with 100% coverage. The description adds no additional semantic detail beyond what the schema provides, so a 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 ('Set') and the specific resource type ('MultiplayerSynchronizer3D node'), and scopes it to the open scene. It distinguishes from sibling tools like editor_set_multiplayer_spawner_param by naming the exact node type.
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 over alternatives, such as other set_param tools or direct node property editors. It only states the action and scope, leaving the agent to infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set multiple properties on a node at once.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Node path | |
| properties | Yes | Properties to set |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It specifies that properties are set but does not state whether existing properties are overwritten, whether invalid property names cause errors, whether the operation is atomic, or any side effects. This leaves significant behavioral ambiguity for a mutating 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, clear sentence with no wasted words. It is appropriately sized for a simple setter, though it is minimal and lacks depth. It is not bloated, but could have included more behavioral context without sacrificing 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 the tool's moderate complexity (batch mutation, no annotations, no output schema, two parameters), the description is too thin. It does not explain what 'properties' means in this context, how the batch operation behaves, or why an agent would choose this over specialized setters. The schema compensates for parameter names but not for operational 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 schema fully describes both parameters ('Node path' and 'Properties to set'), so schema coverage is 100%. The description adds the notion of 'multiple' and 'at once', but provides no additional semantic detail beyond what the schema already states, such as property value types or handling of nested objects.
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 'Set multiple properties on a node at once' clearly states the action (set), the target (node properties), and a key differentiator ('multiple at once') that distinguishes it from single-property setters like set_node_position. It is specific enough to convey the tool's core function, though 'properties' remains somewhat generic without schema 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?
No guidance is provided on when to use this tool versus alternatives such as modify_node or the many editor_set_*_param tools. There is no mention of prerequisites, contexts, or exclusions, leaving the agent to infer when batch-setting properties is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on an Occluder node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action and target, without mentioning side effects, prerequisites, error behavior, or whether the operation is destructive or reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence containing all necessary information without any filler or repetition. It is well-structured and 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?
The tool is a simple parameter setter with no output schema, and the description provides enough to understand its purpose. However, it lacks details on prerequisites (e.g., node existence), failure handling, and return behavior, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for all three parameters (property key, GDScript literal value, node path). The description adds minimal extra meaning beyond specifying the target node type, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Set') on a specific resource ('property on an Occluder node') with context ('in the open scene'). This distinguishes it from sibling setter tools for other node types.
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?
Usage is implied by the description: it should be used to set properties on Occluder nodes. However, it does not explicitly mention alternatives or exclusions, relying on the tool name and node type to differentiate from similar setters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on a ParallaxBackground node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action without mentioning side effects, error handling, persistence of changes, or any prerequisites. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, completely front-loaded with the core action and resource, with no filler or redundancy. It is as concise as possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich schema, the description lacks behavioral and usage context. It does not mention return value (no output schema), error conditions, or when to use this tool over similar setters, leaving an agent without sufficient information for safe invocation.
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 descriptions are comprehensive (100% coverage) for node_path, param, and value, explaining formats and examples. The description adds no additional parameter meaning, so 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 uses a specific verb ('Set') and resource ('property on a ParallaxBackground node'), clearly distinguishing it from sibling tools that target other node types like editor_set_area_param. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as modify_node or editor_set_node_properties. It only mentions 'in the open scene', which is already implied by the schema and does not help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on a particle system node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Set a property' – a mutation – but omits any context about side effects, persistence, error handling, or reversibility. This is a significant gap for a write operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that directly states the action and target. Every word earns its place with no filler or repetition.
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 3-parameter setter, the description plus schema gives enough to invoke correctly. However, the lack of output schema and any behavioral detail (return values, errors, mutation consequences) leaves some contextual gaps, especially given the large family of sibling param setters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents all three parameters with helpful descriptions and examples (e.g., GDScript literal format). Since schema description coverage is 100%, the baseline is 3, and the description adds no extra parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Set a property on a particle system node') and narrows scope to 'the open scene'. This clearly differentiates it from many sibling editor_set_*_param tools by explicitly naming the node type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus the many similar sibling set_param tools, nor does it mention any prerequisites or exclusions. The only implicit signal is the 'particle system node' qualifier, which is not an explicit alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a project setting via editor API (auto-saves).
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only disclosed behavioral trait is 'auto-saves', which is useful but insufficient. With no annotations, the description carries the full burden for explaining side effects, but it omits critical information such as whether the editor must be running, how invalid keys/values are handled, whether existing settings are overwritten, and what the return behavior is.
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, focused sentence that conveys the core purpose in a compact, front-loaded manner. There is no unnecessary verbiage, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and schema descriptions, the description is too sparse for reliable use. It leaves critical gaps around key formatting, value semantics, error handling, and runtime requirements. While sibling tools provide some context, the description alone is insufficient for correct invocation.
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 description adds no information about the 'key' and 'value' parameters. It does not explain what a valid project setting key looks like (e.g., dotted path), what value formats are accepted, or how the value is serialized. Since schema description coverage is 0%, the description completely fails to compensate for the lack of parameter context.
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 ('Set'), the target ('a project setting'), and the execution context ('via editor API'). It naturally distinguishes itself from sibling tools like editor_set_editor_setting (which targets editor settings) and editor_get_project_setting (which reads).
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. It does not mention exclusions, prerequisites, or how it differs from similar setters like editor_set_editor_setting or write_project_config. Usage must be inferred entirely from the tool name and the sparse description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on a RichTextLabel node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior, but it only says 'Set a property'. It omits key details such as side effects (e.g., modifying the scene graph), whether changes are undoable, how the value is parsed/validated, and what the return value indicates. 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, front-loaded sentence with no wasted words. It could be slightly more informative without becoming verbose, but it is appropriately concise for the tool's simplicity.
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 the existence of many sibling param-setter tools, the description is too minimal for complete guidance. It does not explain how this tool fits into a workflow, mention prerequisites (e.g., an open scene with a RichTextLabel node), or alert the agent to any constraints. The schema helps, but the description 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?
The schema provides 100% coverage with meaningful descriptions for all three parameters (node_path, param, value), including examples and format hints. The description itself adds no extra parameter semantics beyond what the schema already conveys, so the baseline 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 (set a property) and the target resource (a RichTextLabel node in the open scene), distinguishing it from sibling param-setter tools like editor_set_animated_sprite_param. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it applies to RichTextLabel nodes in the currently open scene. However, it does not explicitly mention when not to use it or point to alternatives, though the node-type specificity implicitly guides selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select node in editor.
| Name | Required | Description | Default |
|---|---|---|---|
| value | No | Property value | |
| property | No | Property key to set | |
| node_path | Yes | Node path to select |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects or state changes. It simply states the action without mentioning that selection mutates editor state, whether permissions are required, or how the optional property/value parameters affect behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is so brief that it may be under-specified for a tool with three parameters, but conciseness itself is well handled.
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 description fails to explain the purpose of the optional property and value parameters, does not clarify return values or side effects, and omits any interaction with sibling tools. For a tool with three parameters and no output schema, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (node_path, property, value), achieving 100% coverage. The description itself adds no extra semantic meaning beyond what the schema already states, so the 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 uses a clear verb and resource: 'Select node in editor.' It distinguishes itself from the sibling tool editor_get_selection, but it omits any mention of the optional property and value parameters, which could indicate a broader function beyond simple selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool relative to alternatives like editor_get_selection or editor_set_node_properties. There are no prerequisites, exclusions, or contextual hints beyond the implied action of selecting a node.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on a SoftBody3D node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'Set a property' with no mention of permissions, error handling, reversibility, or effects on the scene. This is minimal 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, clear sentence with no wasted words or repetition. It is front-loaded with the action and resource.
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 property setter with 3 fully described params and no output schema, the description is adequate but not rich. It lacks behavioral context such as scene-open requirements and error conditions, though the core purpose 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?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no extra meaning beyond the schema's property examples and node path explanation, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set a property') and the target resource ('SoftBody3D node in the open scene'), which is specific and distinguishes it from sibling set_param tools for other node types.
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 offers no guidance on when to use this tool versus alternatives like editor_set_node_properties or other editor_set_*_param tools. It only implies usage based on the node type, with no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on a TabContainer/TabBar node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'Set a property' without mentioning whether the change is irreversible, what happens on invalid properties, permissions required, or the return value. This is a significant transparency gap 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?
A single sentence that is direct and free of extraneous information. It fully communicates the tool's purpose without waste.
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 3-parameter setter with full schema coverage, the description provides minimal but sufficient context ('open scene'). However, it does not mention return behavior (no output schema) or error handling, and given the absence of annotations, the overall completeness is moderate but not severely lacking.
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 documents all parameters. The description adds no additional parameter meaning, and its only param-related examples ('mass', 'energy') are generic and potentially misleading for TabContainer. Baseline 3 is appropriate since the schema handles parameter semantics, but the description does not enhance them.
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 'Set' and the resource 'property on a TabContainer/TabBar node in the open scene', which precisely defines the tool's scope. This distinguishes it from sibling tools like editor_set_container_param that target other node types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when setting properties on TabContainer/TabBar nodes, but provides no explicit guidance on when to prefer this over similar siblings (e.g., editor_set_container_param) or any exclusions. The context 'in the open scene' is helpful but alternatives are not discussed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on a VideoStreamPlayer node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Set a property', implying mutation, but does not mention side effects (e.g., whether the scene file is modified, whether changes persist or apply only at runtime), required editor state, error behavior, or reversibility. This is a significant gap for a mutating 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, front-loaded sentence that immediately conveys the tool's purpose. It is appropriately concise with no filler or 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?
For a mutation tool with no annotations and no output schema, this description is too minimal. It lacks information about what happens after the property is set, whether the editor needs to be running, how failures are reported, and whether the change is persistent or temporary. The schema provides parameter details, but the behavioral context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters with 100% coverage, including formats for value and node_path. The description itself adds no additional parameter semantics. Baseline 3 is appropriate, though the schema's example property keys ('mass', 'energy') are inconsistent with a VideoStreamPlayer node, which the description does not clarify.
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 ('Set a property') and the specific resource ('a VideoStreamPlayer node in the open scene'), which distinguishes it from sibling editor_set_*_param tools targeting other node types. The verb and resource are specific and non-tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended scope is implied by naming 'VideoStreamPlayer node in the open scene', but the description does not explicitly state when to use this tool versus alternatives like editor_set_node_properties or other editor_set_*_param tools. No exclusions or alternative recommendations are provided, so usage guidance is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a property on a Viewport node in the open scene.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Property key to set (e.g. "mass", "energy", "visible") | |
| value | Yes | Property value as GDScript literal (e.g. "40.0", "true", "Color(1,0,0,1)") | |
| node_path | Yes | Node path in the currently open scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it only says 'Set a property'. It does not mention side effects, persistence, undo behavior, error handling, or whether the property must already exist. A mutation tool like this needs more 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, focused sentence with no superfluous words. It is front-loaded and communicates the essential function immediately.
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, no annotations, and three required parameters, the description is too minimal. It does not explain return values, failure modes, or any operational context. The agent is left without enough information to form correct expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters with descriptions (100% coverage), including examples for param and value. The description adds no extra meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set a property') on a specific resource type ('Viewport node') with scope ('in the open scene'). This distinguishes it from sibling tools like editor_set_camera_param or set_animation_param by explicitly naming the target node type.
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. With many sibling tools like editor_set_node_properties, modify_node, and various editor_set_*_param, there is no mention of exclusions or preferred scenarios. The usage is only implied by the name and basic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reveal a file in the FileSystem dock.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to reveal |
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 beyond the basic action. It does not mention side effects (e.g., whether the dock is opened or focused), error handling for missing paths, or whether the operation is read-only.
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 filler, making it highly concise and front-loaded. It loses one point because it is so terse that it omits potentially useful context, though it is still appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is mostly adequate, but it lacks any mention of preconditions (e.g., must the dock be visible?), error behavior, or whether folders can be revealed. This creates some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already defines the single parameter 'path' with a description 'Path to reveal', achieving 100% schema coverage. The description adds no additional semantics about the parameter, so it stays at the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Reveal' and names the exact resource ('a file in the FileSystem dock'), making it clear what the tool does and distinguishing it from sibling tools like editor_open_asset or editor_list_filesystem.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives or provide exclusions. However, the action is clear enough that an agent can infer it is for highlighting a file in the filesystem, so usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simulate a key press in the editor (e.g. "F5" to run, "Ctrl+S" to save).
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key name (e.g. "F5", "Ctrl+S" via modifiers) | |
| modifiers | No | {ctrl, shift, alt} booleans |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does (simulate a key press) but does not explain side effects, whether the key press is sent to the editor UI or the running game, if focus is required, or what the return behavior is. This lack of behavioral detail is a significant gap for an input-simulation 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, well-structured sentence that includes examples. Every word earns its place, and it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers the main purpose and examples. However, it does not clarify whether the simulated key press targets editor shortcuts or the running game, which is important given the sibling tool `runtime_input`. It also lacks any mention of edge cases or limitations, making it minimally complete but not thorough.
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 describes both parameters with 100% coverage, so the baseline is 3. The description adds a small amount of value by showing example key values ('F5', 'Ctrl+S') that hint at the modifier syntax, but it does not substantially enhance the schema's documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Simulate') and resource ('key press in the editor'), and provides concrete examples ('F5' to run, 'Ctrl+S' to save) that illustrate the intended use. This distinguishes it from sibling tools like editor_play or runtime_input, as it focuses on sending key presses to 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?
The examples imply usage scenarios (running, saving), but the description does not explicitly state when to use this tool versus alternatives like editor_play or runtime_input, nor does it provide any exclusions or prerequisites. It offers context but no direct guidance on choosing this tool over similar ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop playing in editor.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden; it names the primary effect (stop playing) but omits any side effects, reversibility, or state changes. The bare statement is honest but thin.
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, complete sentence with no filler. It front-loads the action and uses common editor terminology.
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's simplicity (no inputs, no output schema) means a one-line description can be complete; 'stop playing in editor' covers the essential effect. Slightly more context about whether this terminates the running game or just pauses it would improve completeness, but ambiguity with editor_pause is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the empty schema is 100% covered, so there is no parameter meaning to explain. Baseline 4 applies because no parameter documentation burden exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Stop') and target ('playing in editor'), unambiguously opposing the sibling editor_play. It distinguishes itself from stop_project by scoping to 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?
The description implies the tool is for ending an active editor playback session, but provides no explicit guidance about when to prefer this over related tools like stop_project or editor_pause. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture the editor viewport as a PNG.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | res://editor_screenshot.png |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions that a PNG is captured, without detailing side effects like file creation, the meaning of the default path, overwrite behavior, or whether the whole editor window or just the viewport is captured. This is a significant lack of transparency for a tool that writes a file.
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 filler or redundant information. It is appropriately concise and front-loaded with the core action.
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 no annotations, no output schema, and a single unexplained parameter, the description is incomplete. It leaves the agent uncertain about the parameter's role, side effects, and how to distinguish this tool from similar siblings. For such a simple tool, more context would be expected.
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 has one optional parameter 'path' with a default but no description. The tool description does not mention this parameter at all, and schema description coverage is 0%. The parameter name and default value hint at its purpose, but the description fails to add any explanatory 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?
The description uses a specific verb ('Capture') and resource ('editor viewport') and specifies the output format (PNG). It clearly states what the tool does, but it does not explicitly distinguish itself from sibling tools like runtime_screenshot or capture_screenshot, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as runtime_screenshot or capture_screenshot. No context is provided about the intended scenario or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Toggle 3D grid visibility.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'Toggle', implying a state change, but fails to explain the nature of the change, persistence, or any side effects. Minimal context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is appropriately concise for a simple, parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is complete. It fully communicates the action and target without additional context being necessary.
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 schema coverage is trivially 100%. Per guidelines, the baseline for 0 params is 4. The description adds no parameter details because none are 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 specific action 'Toggle' and the resource '3D grid visibility'. This is unambiguous and distinct from sibling tools like editor_toggle_snap, which toggles snapping rather than grid visibility.
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 or any alternatives. There is no mention of context, prerequisites, or conditions under which toggling grid visibility would be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Toggle 3D snap mode.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility for behavioral disclosure. It states only that the tool toggles 3D snap mode, omitting details about what state changes, persistence, or return 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 entire description is one short sentence of five words, with no filler or repetition. It is maximally concise for its 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?
While the tool is simple, the description lacks any context on side effects, return values, or when to use it. It is minimally viable but has clear gaps in contextual 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?
The input schema has zero parameters, making the baseline 4. No parameter descriptions are needed because there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Toggle' and identifies the resource '3D snap mode', clearly distinguishing it from sibling editor_toggle_grid. It effectively communicates the tool's function despite being sparse.
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, nor any context about prerequisites or effects. The description only states the action without situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Undo last editor action.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it undoes the last editor action, but does not disclose whether this is destructive, whether it can be undone itself, how far back the undo history goes, or what qualifies as an 'editor action'. This is a significant gap for a mutating 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 short sentence that directly states the tool's function. Every word is necessary, and there is no wasted content. It is appropriately concise for a straightforward undo operation.
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 (no parameters, no output schema) and low complexity, the description is minimally sufficient to convey the basic function. However, it lacks important context about the scope of the editor undo history and any prerequisites (e.g., whether the editor must be running). It is not fully complete for an agent to use it confidently without additional assumptions.
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 accepts zero parameters, and the schema coverage is 100% (vacuously). The description does not need to explain parameter meaning since there are none. The baseline of 4 is appropriate given the absence of parameters, and the description adds no unnecessary detail.
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 ('Undo') and the object ('last editor action'). It is specific enough to understand the primary purpose, although it does not differentiate from sibling tools like 'editor_redo' or other editor operations. The verb+resource structure is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any preconditions, limitations, or mention of 'editor_redo' as the counterpart. The intended use is implied but not explicit, and there is no exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume the editor scene tree from pause.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It explains the core action but does not mention edge cases like behavior when already unpaused, potential side effects, or whether it affects the runtime. This is minimal but adequate for a simple state-change 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, unambiguous sentence that presents the verb and object clearly. There is no wasted wording, making it highly concise and 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?
For a zero-parameter, no-output-schema tool, the description sufficiently explains the action. However, it lacks explicit differentiation from sibling tools like editor_debug_continue or runtime_resume, which would improve contextual completeness in a rich sibling environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there are no parameter semantics to document. Per the rubric baseline, 0 params merits a 4 since no description is needed for 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 action ('Resume') and the target resource ('the editor scene tree from pause'). It distinguishes from sibling tools like editor_pause (which pauses) and runtime_resume (which operates on the runtime, 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?
The phrase 'from pause' implies the tool is used when the editor scene tree is paused, providing a clear condition. However, there is no explicit mention of when not to use it or alternative tools such as runtime_resume or editor_debug_continue, so guidance is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply batch operations to a scene.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .tscn file to edit (relative to project root) | |
| operations | Yes | List of scene operations to apply |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Apply batch operations' is vague and does not reveal that the tool modifies the .tscn file on disk, whether operations are atomic, or how failures are handled. It implies mutation but provides no safety-relevant context.
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 zero wasted words, which is commendable for conciseness. However, it leans toward under-specification for a complex, multi-operation tool, though that trade-off is handled by the schema. It earns a 4 for being succinct while not adding redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested operations array, no output schema, no annotations), the description is not complete enough for an AI agent to understand how to construct and apply batches safely. It lacks context on batch semantics, error behavior, and validation, despite the schema detailing individual parameters. A stronger description would explain the operational workflow and constraints.
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 described in detail (path to .tscn file, list of operations including their own nested property descriptions). The description adds no additional parameter semantics beyond the schema, which is acceptable given the schema's thoroughness. 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 clearly states it applies batch operations to a scene, using a specific verb and resource. It distinguishes this from sibling single-operation tools (e.g., add_node, remove_node, connect_signal) by the 'batch' qualifier, though it could be more explicit about the operation types (add/modify/remove nodes and connections) as seen in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is intended for batched edits instead of calling individual scene-editing tools, nor does it state any prerequisites or exclusions. Given the large sibling list of granular tools, this is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export project via Godot CLI preset.
| Name | Required | Description | Default |
|---|---|---|---|
| preset | Yes | Export preset name (as defined in your export_presets.cfg, e.g. "Windows Desktop", "Linux/X11") | |
| output_path | Yes | Output file path (absolute or relative) for the exported build | |
| project_path | No | Project path (default: current project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only hints at the mechanism ('via Godot CLI preset') but does not disclose side effects (writing output files, overwriting existing files), requirements (Godot CLI availability, preset existence), or potential failure modes. For an operation that exports files, this is insufficient 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 short sentence, which is concise in length. However, it is under-specified rather than efficiently packed with information. It could have been expanded with usage examples or behavioral notes without becoming verbose. This falls short of the 'every sentence earns its place' standard because the sentence provides only minimal value.
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 3 parameters, no output schema, and no annotations, the description is minimal. It does not explain what the export output will be, what happens after the export, or any prerequisites. For an export operation that can fail due to missing presets or invalid paths, this lack of context makes the description 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 description coverage is 100%, and each parameter (preset, output_path, project_path) has a detailed description explaining its purpose and default. The tool description itself adds no additional parameter semantics; it merely uses the word 'preset.' Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Export' and identifies the resource 'project' with the mechanism 'Godot CLI preset.' It is clear that this tool exports the project via a preset, distinguishing it from related tools like read_export_presets or run_project. However, it lacks explicit mention of the produced artifact (a build executable), which would make it perfectly 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?
There is no guidance on when to use this tool versus alternatives such as run_project or launch_editor. It doesn't mention prerequisites like having export_presets.cfg, the need for a valid preset, or whether this is for distributing builds versus running the project. The description implies usage only by its name and short phrase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search nodes across scenes by type/property.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Filter by node group | |
| node_type | No | Filter by node type (e.g. "CharacterBody2D", "Timer") | |
| max_results | No | Max results (default: 100) | |
| signal_name | No | Filter scenes with this signal connection | |
| property_key | No | Filter by property key (e.g. "position", "script") | |
| property_value | No | Filter by property value (partial match, e.g. "player.gd") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only search but does not disclose return format, pagination, or how multiple filters are combined. The behavior of partial matching for property_value is only present in the schema, not the description.
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, front-loaded with the verb and resource. It wastes no words, though it is arguably terse given the tool's complexity.
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 six optional filters and no output schema, the description is incomplete. It does not explain result shape, default max_results behavior, filter combination logic, or how it compares to similar search tools.
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 adds no extra meaning beyond mentioning 'type/property' as filter dimensions; it does not explain parameter relationships or defaults beyond what the schema already states.
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 'Search' and the resource 'nodes across scenes', with filtering by type/property. It distinguishes itself from siblings like list_scenes and search_in_scripts, though it may overlap somewhat with search_scene_content.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or comparisons to similar search tools like search_scene_content or list_all_signals, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find orphaned project files.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It implies a non-destructive read operation but does not explain what 'orphaned' means, what the output looks like, or any side effects. Minimal behavioral 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, front-loaded sentence with no wasted words. It conveys the core purpose efficiently and is appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no params, no output schema, no annotations), the description is minimally viable but lacks important context such as what 'orphaned' means or what the tool returns. This leaves room for ambiguity, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, and the baseline for zero-param tools is 4. The description adds no parameter-specific information, but none 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 uses a specific verb ('Find') and resource ('orphaned project files'), clearly distinguishing it from sibling list tools like list_project_files. It unambiguously identifies the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor any prerequisites or exclusions. The description merely states the action with no context or comparison to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inject generated UIDs into scene/resource headers missing them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Inject' implies a mutating operation, but the description does not disclose side effects, whether files are modified in-place, irreversibility, or permission requirements. This is similar to update_drive, which lacked such details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 11 words that efficiently conveys the action and target with zero redundant information. Every word contributes to 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?
The description is too sparse for a mutation tool with no annotations and no output schema. It lacks guidance on when to use, what happens to existing UIDs, and how it relates to sibling tools like list_missing_uids and update_project_uids. This mirrors update_drive, which scored 2 for similar 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?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific details, but none are necessary since there is nothing to explain.
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 ('Inject generated UIDs') and the specific target ('scene/resource headers missing them'). This distinguishes it from sibling tools like list_missing_uids and update_project_uids by defining a precise repair operation.
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 the tool is used when scene/resource headers are missing UIDs, but it does not explicitly say when to use it versus alternatives like list_missing_uids (find missing) or update_project_uids (broader update). No prerequisites or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Project cohesion report.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosing behavior. It says nothing about whether this tool is read-only, what it computes, whether it has side effects, or what the output looks like. This is a severe transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four words, which is under-specification rather than appropriate conciseness. It lacks even a single meaningful detail that would help an agent. This is comparable to the 'Process' example in the calibration.
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 no output schema and no annotations, the description should explain what a cohesion report is, what metrics or sections it contains, and potentially how the output is returned. The current text provides none of this, making the tool effectively opaque.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the baseline is 4. The description adds no parameter-specific information, but none is needed. The score reflects the baseline rather than any 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?
The description 'Project cohesion report' is essentially a restatement of the tool name. It lacks a clear verb and does not specify what 'cohesion' means or what aspects of the project are analyzed. It also fails to distinguish this from the similar sibling tool 'generate_project_report'.
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. With many sibling tools like generate_project_report, validate_project, and scene_dependency_graph, the absence of any contextual or comparative information leaves the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate comprehensive project overview.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing side effects, output format, or required environment. It only says 'Generate comprehensive project overview' without indicating whether it writes a file, returns text, or modifies project 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 only one sentence and is technically concise, but the brevity stems from under-specification rather than efficient information delivery. It fails to provide necessary details despite being short.
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 no output schema and no annotations, the description should explain what the overview includes, its return value, and whether it has side effects. It does none of this, leaving a substantial gap even though zero parameters make invocation simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema fully covers invocation. There is no parameter information for the description to add, making the baseline 4 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Generate') and resource ('project overview'), but 'comprehensive project overview' is vague about what the overview contains. It does not distinguish itself from sibling tools like generate_cohesion_report or the many list_* read 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?
There is no guidance on when to use this tool versus alternatives such as generate_cohesion_report or list_project_files. No contextual triggers, exclusions, or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect installed Godot version.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only says 'detect' which implies a read-only operation, but it does not specify the return format, error conditions, or any side effects. Minimal behavioral context is 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 a single, focused sentence that fully covers the tool's purpose with no redundant or filler content. It is appropriately concise for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's extremely low complexity (no parameters, no output schema), the description is nearly complete. It clearly states the tool's function. Adding the return type (e.g., 'returns a version string') would make it fully complete, but the current level is adequate for an agent to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty and provides no constraints. The baseline for parameterless tools is 4, and the description does not need to add parameter-level detail. It correctly avoids inventing 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 uses a specific verb ('detect') and a clear resource ('installed Godot version'). It is unambiguous and distinguishes itself from sibling tools by targeting version detection, which no other tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking the installed Godot version but provides no explicit guidance on when to call it or mention of alternatives. Since it is a unique tool, there are no exclusions to note, but the context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get default ports and parameters for a specific VisualShader node type.
| Name | Required | Description | Default |
|---|---|---|---|
| node_type | Yes | Node type shorthand to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without disclosing behavior such as error handling for invalid node types, return format, or whether a project context is required. This is minimal beyond the literal semantics.
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, immediately front-loaded with the action and object. There is no waste or redundant phrasing.
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 one parameter, no annotations, and no output schema, the description is somewhat adequate but lacks explanation of what the returned defaults look like or any edge-case guidance. It is complete enough for a simple getter but misses useful context like return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully covers the single parameter node_type with a description ('Node type shorthand to inspect'). The tool description adds no additional parameter meaning, examples, or syntax details, so it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'default ports and parameters for a specific VisualShader node type.' It distinguishes itself from siblings like set_shader_node_param (setting) and list_shader_node_types (listing types) by focusing on retrieving defaults for a given type.
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. It does not mention that this complements list_shader_node_types or is useful before add_shader_graph_node, nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
System status / diagnostics: editor bridge, live-game runtime bridge, and tool count. Use to debug connection issues.
| Name | Required | Description | Default |
|---|---|---|---|
| probe_runtime | No | Also probe the live-game runtime bridge (port 9877). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the tool checks bridges and counts, which implies a read-only diagnostics operation but does not explicitly state side effects, failure modes, or return behavior. It adds context about the live-game runtime probe but could be more transparent about safety and expected output.
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 two tightly packed sentences. The first lists what the tool reports, the second provides usage guidance. No filler or repetition; every word earns 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 low complexity (one optional parameter) and no output schema, the description adequately covers the tool's purpose and usage. It does not describe the exact return structure, but the diagnostic nature implies a status report. This is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter (probe_runtime) is fully described in the schema with 100% coverage. The description independently mentions the live-game runtime bridge, which aligns with the parameter's purpose, but adds little beyond the schema's description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides system status/diagnostics, listing specific components (editor bridge, live-game runtime bridge, tool count). This distinguishes it from siblings like editor_health_check or runtime_ping, which target only one subsystem.
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 says 'Use to debug connection issues,' giving a clear context for when this tool is appropriate. It does not name specific alternative tools or explicitly state when not to use it, but the usage scenario is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get UID for a file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to file (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose return format, error behavior, whether the file must exist, or any side effects. The agent is left to infer these critical details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the verb and object. It is appropriately sized for a tool with one parameter and no need for extensive explanation.
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 absence of an output schema and annotations, the description is incomplete. It does not explain what the UID looks like, how it is returned, or what happens if the file is missing. The agent needs more contract information to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description ('Path to file (relative to project root)'). The tool description adds no additional meaning beyond restating 'file', so it does not go beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and the resource (UID for a file), making it distinct from siblings like list_missing_uids and fix_missing_uids. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_missing_uids or update_project_uids. There is no mention of prerequisites, exclusions, or context in which this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if Godot editor is running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the check action but does not specify return format (e.g., boolean), error behavior, or confirm that it is non-mutating.
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 short sentence with no filler. It front-loads the core purpose and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-param status-check tool, the description is mostly complete for selecting and invoking it correctly. However, without an output schema, it does not explicitly state what the return value represents, which is a minor gap.
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 description does not need to explain inputs. The empty schema fully covers the parameter surface, and the baseline for 0-param tools 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 uses the specific verb 'Check' and the resource 'Godot editor', clearly indicating a status query. It distinguishes from siblings like launch_editor and get_status by focusing on the running state.
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 context about when to use this tool versus alternatives such as get_status or editor_health_check. There is no mention of prerequisites, typical workflows, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch Godot editor with project.
| Name | Required | Description | Default |
|---|---|---|---|
| scene | No | Scene to open on launch (e.g. "res://main.tscn") | |
| project_path | No | Project path (default: current project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the launch action but does not explain whether the tool blocks, returns immediately, reuses an existing editor instance, or what happens if the editor is installed. This is insufficient for an agent to anticipate 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 a single sentence that is economical and front-loaded. However, it is under-specified, lacking useful details such as behavior or return values. It is not a tautology, but it conveys only the bare minimum.
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, the description is still incomplete. There is no output schema, no annotations, and no context about prerequisites (e.g., project existence, editor installation) or interactions with related tools like stop_project or is_editor_running. The description should provide more context for an agent to use the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (scene and project_path) adequately described. The description adds no additional semantic value beyond the schema, but this is acceptable given the schema already provides the necessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (launch) and target (Godot editor) with project context, distinguishing it from siblings like run_project and stop_project. However, it could be more specific about what 'with project' entails, such as opening a specific project path, though that detail is in the schema.
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 like run_project or editor_play. The description lacks any mention of appropriate use cases, prerequisites, or scenarios where another tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all signal connections across scenes.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No | Filter to scene | |
| signal_name | No | Filter by signal name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states 'list all' but does not mention whether the operation is read-only, its performance impact, or what data is returned. The description is minimal and offers no behavioral insights beyond the action.
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 one concise sentence with no filler, effectively communicating the core action.
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?
While the tool is simple, the description lacks details about the output format or return values, as there is no output schema. It does not mention any limitations or behavior for empty results. For a basic list operation, it is adequate but could be enhanced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes both scene_path and signal_name with clear descriptions, achieving 100% coverage. The tool description adds no extra parameter semantics beyond mentioning the cross-scene scope, which is already captured by 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 uses a specific verb 'list' and a clear resource 'signal connections across scenes', making it easy to understand the tool's function. It distinguishes itself from sibling tools like 'editor_list_node_signals' by its project-wide scope across scenes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when this tool should be used instead of alternatives like 'editor_list_node_signals' or 'connect_signal'. It does not specify prerequisites or exclusions, 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.
List AnimationPlayers and animations.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No | Filter to a specific scene (default: all scenes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states what it lists without explaining return format, default behavior (e.g., whether it scans all scenes), or any side effects. This is insufficient for an agent to predict the tool's output or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It front-loads the purpose effectively. However, it is so brief that it omits useful details, but for a simple list tool this level of brevity is acceptable.
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 description lacks an output schema and annotations, so it should explain return values and the effect of the optional 'scene_path' parameter. It does not, leaving critical gaps about what exactly is listed (names, paths, resources) and how filtering works. The description is not complete for confident invocation.
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 provides 100% coverage for the single parameter 'scene_path' with a clear description. The tool description adds no extra parameter meaning, so it meets the baseline for high schema coverage without compensation.
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 ('List') and the resource ('AnimationPlayers and animations'), which distinguishes it from read or create operations like 'read_animation' and 'create_animation'. However, it lacks explicit mention of alternatives or scope nuances, so it does not fully stand out from siblings.
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 such as 'read_animation' or 'list_all_signals'. There are no exclusions, prerequisites, or context given, leaving the agent to infer appropriate usage from the verb and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List audio files by format.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subdirectory to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'List audio files by format' and does not describe recursion, base directory, return format, or read-only characteristics beyond the verb 'list'.
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 short sentence, 'List audio files by format.', with no filler or redundant information. It is front-loaded and every word contributes meaning.
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 read-only list tool with one documented optional parameter, the description is minimally viable. However, it lacks return shape details and behavioral specifics such as recursion or exact format filtering, leaving some gaps for the agent.
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 fully documents the only parameter 'path' with the description 'Subdirectory to search' (100% schema coverage). The tool description adds 'by format' but does not add parameter-specific syntax or details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource as 'audio files' with a qualifying phrase 'by format'. This distinguishes it from sibling list tools focused on other resource types, though 'by format' is slightly ambiguous between grouping and filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_import_files, list_project_files, or read_audio_stream. There is no mention of scope, exclusions, or context that would help an agent choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all autoload singletons.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'List all autoload singletons' without mentioning return format, side effects, or whether it's a read-only operation. The agent gets no additional context beyond the tool's name and one-line purpose.
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 that directly states the tool's function. No unnecessary words or details, making it very 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 zero-parameter list operation, the description is minimally adequate but lacks information about the return value or output format, especially since there is no output schema. The agent can infer the basic purpose but may not know the exact structure of the result.
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 there is no parameter semantics to explain. The baseline of 4 applies because the description need not compensate for schema gaps when there are none.
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 all autoload singletons, using a specific verb and resource. It is distinct from most siblings but could be confused with editor_get_autoloads, which is not explicitly 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?
The description provides no guidance on when to use this tool versus alternatives, nor any context about editor-specific vs general use. It only states what the tool does, 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.
List Camera nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No | Filter to a specific scene (default: all scenes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It simply says 'List Camera nodes' without disclosing whether the operation is read-only, what information is returned, whether hidden nodes are included, or what happens if no scene is open. Minimal behavioral context is provided beyond the implied read-only nature of 'list'.
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, focused sentence with zero extraneous words. It is concise without being under-specified for the tool's simplicity, setting a good example of minimalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no nested objects, no output schema), so the description is adequate in that sense. However, it does not mention the return format or any caveats (e.g., whether nodes from all scenes are returned by default). For a list operation without an output schema, some hint about the return value 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?
Schema description coverage is 100% (the only parameter has a clear description: 'Filter to a specific scene (default: all scenes)'). The description adds no extra parameter semantics, but the baseline of 3 applies because the schema already documents the parameter effectively. The default 'all scenes' is a useful detail.
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 'List Camera nodes' clearly states the action (list) and the resource (Camera nodes), distinguishing it from sibling tools like list_lights or list_materials. However, it lacks explicit scope clarification (e.g., current project vs. scene), though the parameter description partially fills this gap. It earns a 4 because it is specific but not as richly differentiated as examples that explicitly state scope or alternatives.
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?
There is no guidance on when to use this tool versus alternatives such as list_scenes or read_camera. The parameter description mentions filtering by scene but does not explain use cases or exclude scenarios. This is a clear gap for a tool that could be confused with other list/read operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List C# project files.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the action but does not disclose return format, scope (e.g., current project only or recursive search), or whether it's a read-only operation. For a simple list tool, this is adequate but lacks useful contextual detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant wording. It is front-loaded with the verb and resource, making it immediately scannable.
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 trivial list tool, this is minimally viable. However, with no output schema, the description does not mention return format or scope, which could help the agent anticipate results. It is adequate but leaves some 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?
The tool has zero parameters and the schema coverage is 100%, so the schema fully describes the tool's inputs. The description adds no parameter details, but none are needed. Baseline 4 is appropriate given the parameter-less 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 uses a specific verb ('List') and a clear resource ('C# project files'), making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like 'list_project_files' (general file listing) and 'read_csproj' (reading a specific project file).
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 given on when to use this tool versus alternatives such as 'list_project_files' or 'read_csproj'. The description implies a discovery use case but does not state explicit context or exclusions, leaving the agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Environment resources.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subdirectory to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'List Environment resources' is a minimal statement that implies a read-only operation but does not explain whether the search is recursive, how path relates to the project root, or what the output format looks like. It is not misleading, but it is under-transparent.
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 three words: 'List Environment resources.' It is front-loaded, contains no filler, and every word is meaningful. Ideal conciseness for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no output schema), so the description does not need heavy detail. However, it lacks information about default search scope, return type, or how it differs from list_resources, leaving the agent to infer behavior. Acceptable for a low-complexity tool but with clear 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?
The schema provides 100% parameter coverage with 'Subdirectory to search' for the path parameter, so the schema already explains the parameter. The description adds no extra semantic detail about how the path filters results, keeping this at 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 uses a specific verb ('List') and a specific resource type ('Environment resources'), which clearly distinguishes it from singular tools like read_environment and write-oriented tools like create_environment. However, it does not mention the optional path restriction, leaving some scope ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over siblings such as list_resources or read_environment. The only usage hint (path being a subdirectory) is in the schema, not the description, so the agent receives no behavioral or selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all node groups across scenes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It states the tool lists all node groups across scenes, implying a read-only aggregation, but it does not disclose whether it scans the entire project, includes only loaded scenes, or how it handles duplicate group names. The safety profile is not explicitly stated.
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 that gets straight to the point with no wasted words. It is well-structured and 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?
The tool is simple with no annotations and no output schema. The description gives the basic function but does not specify the return format or any edge cases, leaving some ambiguity about what 'all node groups across scenes' actually returns (names vs. structured data). Given the lack of output schema, additional detail 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?
The tool has zero parameters, so the description need not explain parameter semantics. The baseline score of 4 applies here.
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 (list), the resource (node groups), and scope (across scenes), distinguishing it from other list_* tools that target different entity types. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_scenes or find_nodes_in_scenes. There is no mention of exclusions, preconditions, or when not to use it. This leaves the agent to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List .import files grouped by type.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subdirectory to search (default: root) | |
| type_filter | No | Filter by imported asset type (e.g. "png", "wav", "obj") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It adds the behavioral detail 'grouped by type', but does not mention whether traversal is recursive, how grouping is structured, or the read-only nature, which is only inferred. It provides minimal but non-zero behavioral context.
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 of six words, front-loaded with the verb and resource. It is concise and free of filler, ideal for a straightforward list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool, the two self-documenting parameters, and no output schema, the description is nearly complete. The phrase 'grouped by type' hints at the return structure, though a bit more detail on grouping or traversal would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with descriptions for both 'path' and 'type_filter', including default and example. The description adds no extra parameter-level meaning, so the baseline 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 uses a specific verb 'List' with a clear resource '.import files' and states the result format 'grouped by type'. This distinguishes it from sibling list tools that target other resource types, though it doesn't explicitly contrast with them.
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?
Usage is implied by the name and resource: the tool is meant for inspecting .import files. However, there is no explicit 'when to use' or reference to alternatives among the many sibling list_* tools, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List physics joints.
| Name | Required | Description | Default |
|---|---|---|---|
| joint_type | No | Filter by joint type | |
| scene_path | No | Filter to a specific scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It only states 'List physics joints,' implying a read-only enumeration but does not disclose return format, filtering behavior, or whether it operates on the current scene or whole project.
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 wasted words. However, it is extremely terse, which slightly reduces its value compared to a more informative but still concise 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?
The tool has no annotations, no output schema, and a minimal description. It does not explain the return value, how filters interact, or whether it requires an open scene, making it incomplete for an agent to confidently use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters ('Filter by joint type', 'Filter to a specific scene'), achieving 100% coverage. The description adds no additional parameter semantics, so baseline 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 'List physics joints.' uses a specific verb ('list') and resource ('physics joints'), making the operation clear. It distinguishes from siblings like create_joint, read_joint, and remove_joint, though it doesn't explicitly call out alternatives.
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 other joint-related tools (e.g., read_joint, set_joint_param) or other list_* tools. It does not mention scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List light nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| light_type | No | Filter by light type: OmniLight3D, SpotLight3D, DirectionalLight3D, PointLight2D | |
| scene_path | No | Filter to a specific scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior, but it only states the action. It does not mention whether it operates on the current scene, requires the editor, returns a list of paths, or has any side effects. While 'list' implies read-only, that is not explicit.
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 short sentence with no filler, front-loaded with the verb. However, it is so terse that it sacrifices informative content, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but lacks essential context: it does not specify the operation's scope, whether it searches across all scenes, or what the response contains. Without an output schema or annotations, the description is insufficient for an agent to confidently invoke it, especially with many sibling list tools.
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 have descriptions in the schema (100% coverage), so the schema already explains the filters. The description adds no extra semantic meaning or examples for the 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 uses the specific verb 'List' and names the resource 'light nodes,' clearly stating the operation. However, it does not specify the scope (e.g., current scene vs. all scenes) or explicitly differentiate from sibling list tools, so it falls short of a perfect score.
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 over related tools like read_light_2d, list_cameras, or other list tools. There is no mention of scenarios, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List materials grouped by type.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subdirectory to search (default: root) | |
| recursive | No | Search recursively (default: true) | |
| type_filter | No | Filter by material type (e.g. "StandardMaterial3D") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only reveals that results are grouped by type, but does not mention whether the search is recursive, what the return format is, if it requires an open project, or that it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriate in size for a simple listing tool and every word contributes to the core meaning.
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 is too sparse to be complete. It does not explain what 'materials' refers to, how grouping manifests, or what the response contains, leaving significant gaps for an 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?
Schema description coverage is 100%, so the parameters (path, recursive, type_filter) are already documented meaningfully. The description adds minimal value beyond 'grouped by type', which aligns with type_filter but does not introduce new semantics.
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 a specific verb ('List') and resource ('materials'), and adds the grouping behavior ('grouped by type'), distinguishing it from other list_* tools. It is unambiguous and immediately conveys the tool's function, though it does not explicitly mention the project 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 is provided on when to use this tool versus alternatives (e.g., list_resources for all resources, or read_material for a single material). The usage context is only implied by the name and description, with no exclusions or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files missing UIDs.
| 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 convey behavioral traits. The verb 'List' implies a read-only operation, but the description does not disclose the scope of 'files' (e.g., all project files, resources) or whether the operation has any side effects. It also doesn't describe the output format or how missing UIDs are determined, leaving the agent with incomplete behavioral expectations.
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, short sentence that gets directly to the point. It is front-loaded with the action and object, with no filler or redundant details. This is appropriate for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and an output schema, the description is too sparse to be fully contextual. It doesn't clarify whether 'files' refers to project resources, scenes, or all assets, nor does it specify the return format. The agent would need to infer or test behavior, which is a gap for such a minimally structured 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?
The tool has zero parameters and an empty schema, so there is nothing for the description to explain. The baseline is 4 per the rubric, and the description doesn't need to add anything beyond what's already evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('files missing UIDs'). It distinguishes itself from sibling tools like fix_missing_uids and update_project_uids, which perform mutations rather than listing. The meaning is clear even without additional 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 such as list_project_files or fix_missing_uids. There is no mention of prerequisites, intended workflow, or exclusion criteria. The only usage implied is that it lists files with missing UIDs, but no explicit recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Path2D/3D nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No | Filter to scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action without revealing important traits like whether the list is recursive, whether it operates on the current scene or all scenes, or what the return format is. This is a minimal but non-contradictory description.
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 redundant words. It is front-loaded and every word earns its place, making it highly 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?
Given the low complexity and one parameter, the description is still incomplete. It does not explain the scope of the listing (e.g., current scene vs. all scenes), whether both Path2D and Path3D are included, or what the output looks like. Since there is no output schema, the description should have provided more context about the expected return.
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 description for scene_path is 'Filter to scene', covering its meaning. Since schema description coverage is 100%, the baseline is 3. The tool description does not add further explanation about the parameter, but the schema already documents it sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and the resource 'Path2D/3D nodes', making the tool's function immediately clear. It distinguishes itself from sibling list_* tools by naming a unique resource type (Path2D/3D nodes compared to scenes, scripts, shaders, etc.).
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 such as read_path, write_path_curve, or other list_* tools. There is no mention of context like whether to use it for inspection vs. modification, or any exclusion cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List PhysicsMaterials.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subdirectory to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but it does not state potential side effects, permissions required, or the format of results. It offers minimal insight beyond the tool's 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 extremely concise at three words, with no redundant information. It front-loads the verb and resource, making it easy to parse at a glance. However, the severe brevity borders on under-specification, but as a standalone sentence it is 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 list tool with no output schema, the description is incomplete. It fails to mention the 'path' parameter, explain what the returned list contains, or distinguish from other listing tools. The lack of return-value documentation makes it hard for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for the 'path' parameter ('Subdirectory to search'), giving 100% schema coverage. The tool description adds no extra meaning beyond what the schema states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and resource ('PhysicsMaterials'), making the basic action understandable. However, it lacks any differentiation from sibling tools like list_materials or read_physics_material, and it does not specify scope or output. It is more than a tautology but still minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention the optional 'path' parameter or offer any context for selection among the many sibling list/read tools. There is no mention of exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Popup/Window/Dialog nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No | Filter to scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the action 'List' and does not explain output format, filtering semantics, or side effects. This is minimal and leaves room for misinterpretation.
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 redundant words. It is front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the tool returns, but it does not. It also omits any reference to the optional scene_path filtering or how this tool fits among numerous sibling list tools, leaving 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?
The schema description covers the only parameter (scene_path: 'Filter to scene') at 100% coverage, so the description does not need to add parameter details. It provides no extra semantics but the schema 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 uses a specific verb and resource: 'List Popup/Window/Dialog nodes.' It clearly identifies the node categories and distinguishes itself from sibling list tools by focusing on popups/windows/dialogs. It does not describe the return format, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like list_ui_nodes or find_nodes_in_scenes. It also does not mention the optional scene_path filter or any specific use cases, leaving the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and directories in the Godot project.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subdirectory relative to project root (default: root) | |
| pattern | No | Glob pattern filter (e.g. "*.tscn") | |
| recursive | No | Recurse into subdirectories (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic listing action and does not reveal details such as return format, recursion behavior, filtering, or any side effects, making it insufficient for understanding the tool's full behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and free of any fluff or redundancy. It efficiently conveys the core purpose without wasting 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?
The tool has no output schema, so the description should explain what the tool returns, but it does not. Additionally, with many sibling list_* tools, the description does not help the agent choose this tool over others. While parameters are well-documented, the overall context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters, achieving 100% coverage. The tool description itself does not repeat or add any parameter-related information, but the schema already documents each parameter effectively, so 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 clearly states the action ('List') and the resource ('files and directories in the Godot project'), making the tool's purpose easy to understand. However, it does not explicitly distinguish this tool from similar siblings like list_audio_files or list_import_files, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It neither mentions exclusions nor names any sibling tools that might be more appropriate for specific file types, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan directory for Godot projects.
| Name | Required | Description | Default |
|---|---|---|---|
| directory | No | Directory to search (default: current directory) | |
| recursive | No | Search recursively (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. 'Scan directory' implies a read-only operation, but the description does not clarify what the tool returns (e.g., a list of project paths), whether it looks for project.godot files, or any side effects. It discloses virtually no behavioral traits beyond the basic scan concept.
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 that is clear and to the point. It is not bloated or unnecessarily verbose. However, it is so minimal that it veers toward under-specification rather than concise completeness, missing important details like output and behavior. It earns its place but could be enriched without losing 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 no output schema, so the description is responsible for explaining return values. It doesn't. It also fails to mention that recursive search is enabled by default or what constitutes a Godot project. Given the schema's limited annotations and the absence of output schema, the description is insufficient for an agent to fully understand the tool's behavior and 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?
The input schema has 100% description coverage, so the schema fully documents both parameters (directory and recursive). The description adds no additional meaning beyond the schema, but since coverage is high, the baseline of 3 is appropriate. The description doesn't mention parameters, but the schema already does.
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 'Scan directory for Godot projects' uses a specific verb ('Scan') and resource ('directory'), and clearly identifies the object ('Godot projects'). It distinguishes from sibling tools that target other assets like scenes or scripts, though it could be more explicit about what constitutes a Godot project (e.g., project.godot file).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like list_project_files or list_scenes. It doesn't state any prerequisites, exclusions, or context that would help an agent choose this tool over similar ones. Usage is only implicitly understood from the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all resource files.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subdirectory to search (default: root) | |
| recursive | No | Search recursively (default: true) | |
| type_filter | No | Resource type filter (e.g. "Material", "Shader") |
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 without disclosing behavior like recursion defaults, output format, whether it returns absolute paths, or any permissions required. Minimal behavioral context is provided.
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. However, it is under-specified, which prevents a perfect score — conciseness should not come at the cost of essential 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?
For a simple listing tool, the description is minimally viable but incomplete. There is no output schema and no annotations, so the description should at least mention return format or scoping. The parameter descriptions help, but the overall context is sparse given the large sibling toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for path, recursive, and type_filter. The tool description adds no extra meaning beyond 'all resource files', so it neither compensates nor detracts from the schema's already adequate parameter documentation.
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 'List all resource files' uses a specific verb and resource, and the name is clear. However, it does not distinguish from numerous sibling list tools like list_project_files, list_scenes, or list_textures, leaving ambiguity about what exactly constitutes a 'resource file'.
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. There is no mention of exclusions, prerequisites, or comparisons to similar tools such as list_project_files or editor_list_filesystem.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all .tscn scene files.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subdirectory to search (default: root) | |
| recursive | No | Search recursively (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely restates the core function (listing .tscn files) without revealing any additional traits: return format, path semantics, recursion behavior, or handling of invalid paths. This is a thin description that adds little beyond the tool 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 a single, concise sentence that directly states the tool's purpose. No filler or redundant information, and it's 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?
The tool has no output schema and no annotations, so the description should explain return values and behavior. It only says 'list all .tscn scene files' without indicating whether it returns relative/absolute paths, whether it defaults to recursive, or how it handles edge cases. Given the simplicity of a list tool, more context is expected.
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 'path' and 'recursive' parameters having descriptions. The description itself adds no extra parameter semantics, but the schema already documents them sufficiently, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all .tscn scene files' clearly states a specific action (list) and resource (scene files with .tscn extension). It distinguishes from sibling tools like list_audio_files and list_scripts by specifying the file type.
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 mention when to use this tool over alternatives like list_project_files or list_resources, nor does it mention any prerequisites or exclusions. The presence of many similar list_* sibling tools makes this lack of differentiation problematic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all script files grouped by type.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subdirectory to search (default: root) | |
| type | No | Filter by script type | all |
| recursive | No | Search recursively (default: true) |
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 core behavior and grouping, but omits behavioral details such as recursive search defaults, output format, and how grouping is represented. This is insufficient for a tool with no safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loading the verb. Every word earns 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?
The tool is simple with well-documented parameters, but lacking an output schema, the description should clarify the return format (e.g., list of paths, grouping structure). It does not explain the grouping semantics, leaving some ambiguity. For a simple list tool, this is a moderate gap.
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 documentation covers all three parameters with 100% coverage, so the baseline is 3. The description's mention of 'by type' aligns with the type parameter, but adds no new syntax or format details beyond what the schema already provides.
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 (list) and resource (script files) with a distinguishing grouping behavior. It differentiates from sibling tools that target other resources (e.g., list_shaders, list_scenes). However, it does not explicitly mention the parameterized filtering options, which slightly limits 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 on when to use this tool versus alternatives like list_resources or list_project_files. The description does not provide context, exclusions, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all .gdshaderinc files.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subdirectory to search | |
| recursive | No | Search recursively |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('List') without explaining return format, path semantics, or any potential side effects. An agent would not know if the tool returns full paths, relative paths, or just filenames, nor any default recursion behavior (though the schema hints at it).
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 consists of a single sentence: 'List all .gdshaderinc files.' It is extremely concise, front-loaded, and contains no filler. Every word earns 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?
This is a simple read-only listing tool with two optional parameters and no output schema. The description is adequate for basic understanding, but it does not mention what the return value looks like (e.g., an array of paths). Given the lack of an output schema, the description could have provided a hint about the returned data structure, making this a minimal but not fully complete description.
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% for both parameters ('Subdirectory to search' and 'Search recursively'). The description adds no parameter-specific information beyond what the schema already provides, so the baseline 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 'List all .gdshaderinc files.' It uses a specific verb ('List') and a specific resource ('.gdshaderinc files'), distinguishing it from sibling tools like 'list_shaders' and 'read_shader_include'. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this tool is for listing shader include files, which provides context for when to use it. It does not explicitly name alternatives or exclusions, but the file extension in the description differentiates it from 'list_shaders'. For a simple listing tool, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all VisualShader node types organized by category with input/output counts.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category: Output, Constant, Texture, Math, Input, Effect, Conditional, Custom, UI |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose output structure (categories, input/output counts), which is valuable. However, it does not explicitly state this is a safe read-only operation or mention any edge cases, permissions, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundant wording. It efficiently conveys the purpose and output characteristics while remaining easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with one optional parameter, the description is adequate. It explains the core behavior and output includes input/output counts, while the schema fills in category details. It could be slightly more explicit about default behavior when no category filter is provided, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'category' has 100% schema description coverage, listing valid categories. The tool description reinforces the concept of organization by category but adds no further meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('VisualShader node types'), and key characteristics ('organized by category with input/output counts'). This distinguishes it from sibling tools like 'list_shaders', 'read_shader', and 'get_shader_node_defaults'.
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 usage is implied by the action and resource: use when you need to enumerate VisualShader node types. However, it provides no explicit when-to-use/when-not-to-use guidance or references to alternatives, leaving the agent to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all .gdshader files.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subdirectory to search (default: root) | |
| recursive | No | Search recursively (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly indicates a read-only listing operation, but it doesn't disclose that the search is recursive by default or that it operates from the project root unless a path is provided. The schema contains these details, but the description adds little beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that immediately conveys the tool's purpose. It is front-loaded and contains no fluff, making it an excellent example of 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 the tool's simplicity and the schema's coverage, the description is adequate but incomplete. It does not mention the return format (e.g., a list of file paths) or the search scope (project root, subdirectories). Since there is no output schema, the description should have briefly explained expected output.
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% for both parameters (path and recursive), each with descriptive defaults. The description itself adds no parameter-level detail, but the schema adequately documents them, meeting the baseline for high 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 'List all .gdshader files' uses a specific verb (list) and resource (.gdshader files), clearly distinguishing it from siblings like list_shader_includes (which lists .gdshaderinc files) and list_visual_shaders. It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no explicit guidance on when to use it over alternatives. Usage is implied by the name and description, but there's no mention of exclusions or context (e.g., 'for shader includes, use list_shader_includes').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Skeleton nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No | Filter to scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description simply restates the tool's name without disclosing scope (e.g., current scene vs. project-wide), recursion behavior, or side effects. The read-only nature is implied but not confirmed.
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 of four words with no filler or redundant information. Every word earns 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?
For a simple list tool, the description is minimally viable but omits the meaning of the optional scene_path default behavior and does not clarify what the tool returns. With no output schema or annotations, this leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes scene_path as 'Filter to scene' with 100% coverage, so the description adds no additional parameter meaning. Baseline 3 applies because the schema covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' and specifies 'Skeleton nodes', clearly indicating the operation and the resource. It is distinct from sibling tools like list_animations or read_skeleton, which target different resources or 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?
The description provides no guidance on when to use this tool versus alternatives such as read_skeleton or find_nodes_in_scenes. It does not mention preferred contexts 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.
List all texture/image assets in the project.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subdirectory to search (default: root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action without disclosing behavior such as the return format, path traversal behavior, or read-only nature. It lacks the context that would help an agent understand exactly what happens when invoked.
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, focused sentence with no wasted words. It is appropriately concise for a simple listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool complexity and no output schema, the description is minimally sufficient but does not explain return values or path filtering nuances. It covers the core purpose but lacks explicit details that would make it fully self-contained.
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 fully describes the only parameter 'path' as a subdirectory to search, with a default of root. The description adds no additional parameter 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 clearly states the tool's function: listing all texture/image assets in the project. This specific verb+resource combination distinguishes it from sibling tools like list_audio_files or list_materials.
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 use when textures/images are needed, but does not explicitly define when to use this tool over alternatives such as list_resources or list_import_files. No exclusions or partial-use cases are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List TileSet resources.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subdirectory to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states the listing action, with no mention of recursion, return format, read-only nature, or any other behavioral traits. This is minimal and not misleading but leaves significant gaps.
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 one short sentence with no wasted words, making it very concise. It could arguably include more context, but for its brevity, it earns 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 simple nature (1 optional parameter, no output schema, no annotations), the description is minimally adequate. However, it does not specify what the tool returns (e.g., paths, resource references) or whether it searches recursively, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single parameter 'path' with a description ('Subdirectory to search'), giving 100% coverage. The description itself adds no parameter-specific meaning, so 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 'List TileSet resources.' clearly identifies the action (list) and the resource type (TileSet resources). It effectively distinguishes from siblings like read_tileset (which reads a specific tileset) and create_tileset (which creates one), leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_resources or read_tileset. No exclusions or context are provided, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List translation files.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subdirectory to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'List translation files' and does not explain whether the listing is recursive, what output format is returned, or any side effects. This is a significant gap for a tool with zero annotation coverage.
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 short sentence with no unnecessary words. It is front-loaded and efficiently communicates the core action, earning a high score for 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?
The tool has a single optional parameter and no output schema or annotations. The description is too terse to convey what the tool returns (e.g., file paths) or how the path parameter affects results. For a tool with no annotations and no output schema, this is insufficient context for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with the 'path' parameter description 'Subdirectory to search'. The tool description does not add any additional meaning about the parameter, but since schema coverage is high, a 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 that the tool lists translation files, using a specific verb and resource. It is distinct from sibling tools like read_translation or write_translation, though it does not explicitly differentiate itself from other list_* tools. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of use cases, exclusions, or alternatives such as read_translation or create_translation. The description simply states what it does without any context on when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Control-derived UI nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| node_type | No | Filter by specific Control type (e.g. "Button", "Label"). Default: all Control-derived nodes. | |
| max_results | No | Max results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clarifies that only Control-derived nodes are listed, which is useful, but it does not mention return format, scene scope, or any side effects (though the verb 'list' implies read-only).
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 extraneous words. It is front-loaded and immediately conveys the tool's 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 gives the core idea but omits details about return values, scene context, and possible limitations. Without an output schema or annotations, more contextual information would be beneficial for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides comprehensive descriptions for both parameters (node_type filter and max_results default), covering 100% of the schema. The description adds no additional parameter semantics beyond the schema, making the baseline 3 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 the specific action ('List') and resource ('Control-derived UI nodes'), which is clear and unambiguous. It distinguishes this tool from sibling list tools by its focus on UI node types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to enumerate UI nodes of a particular type, but provides no explicit context, exclusions, or alternatives. It does not communicate when to prefer this over other list_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List VisualShader graph files.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subdirectory to search (default: root) | |
| recursive | No | Search recursively |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral transparency burden. It only says 'List', implying a read-only operation, but gives no details about return format, scope (e.g., project root vs filesystem), or whether it includes file extensions or paths. This is minimal for a tool with no annotation support.
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 redundancy or filler. Every word contributes to the core purpose, making it appropriately sized for the tool's simplicity.
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 simple nature (2 well-documented parameters, no output schema), the description covers the fundamental action but misses useful context such as what the output looks like (e.g., list of paths) and what specific file types count as 'VisualShader graph files'. It is adequate but leaves room for clarity.
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%: 'path' is documented as 'Subdirectory to search (default: root)' and 'recursive' as 'Search recursively'. The description adds no extra meaning beyond the schema, which already adequately explains both parameters. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'VisualShader graph files', which distinguishes it from sibling list_shaders (general shaders) and read_visual_shader (reading a specific shader). It does not explicitly name alternatives, but the resource specificity provides adequate differentiation.
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 list_shaders or read_visual_shader. There is no mention of expected usage context or exclusions, leaving the agent to infer based on tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a texture onto a Sprite2D node.
| Name | Required | Description | Default |
|---|---|---|---|
| node_path | Yes | Node path (Sprite2D or TextureRect) | |
| scene_path | Yes | Path to .tscn file | |
| texture_path | Yes | Texture resource path (e.g. "res://icon.svg") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It only states the core operation; it does not mention whether the scene file is saved, whether existing textures are overwritten, or any error behavior. This is a significant gap for a mutating 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 short sentence that conveys the essential action without redundancy. It is front-loaded and appropriately brief for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks annotations and an output schema, yet the description does not mention return values or side effects. It also fails to note the TextureRect compatibility from the schema, making the overall context incomplete for an agent to understand the full effect.
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 three parameters are fully described in the schema (100% coverage), so the description adds minimal value beyond the schema. The parameter names and schema descriptions are self-explanatory, and the description does not clarify any additional semantics.
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 a texture') and the target resource ('Sprite2D node'), using a specific verb. However, it omits that the node can also be a TextureRect as shown in the schema, so it's not fully precise.
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 given on when to use this tool vs alternatives like create_image_texture or editor_set_*_param tools. The verb 'load' implies usage in texture assignment contexts, but no explicit context, exclusions, or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify node properties or rename.
| Name | Required | Description | Default |
|---|---|---|---|
| new_name | No | New name (rename the node) | |
| node_path | Yes | Node path to modify (e.g. "Player" or "Main/Enemy") | |
| properties | No | Properties to set (key=value) | |
| scene_path | Yes | Path to .tscn file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavior. It only says 'Modify' without explaining side effects, whether properties are overwritten, whether renaming is allowed simultaneously, or any permissions required. This is a significant transparency gap 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, concise sentence with no superfluous wording. It is front-loaded and easily parsed, though it is terse and could benefit from additional details without compromising 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?
The tool has 4 parameters, no annotations, and no output schema, yet the description only gives a one-line summary. It lacks essential context such as how properties are formatted, whether the operation is reversible, and when to choose this tool over the many similar siblings present in the toolset.
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 parameters are already well-documented. The description adds minimal semantic value by mentioning 'properties' and 'rename', which maps to the new_name and properties parameters, but does not provide additional context 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 clearly states the tool modifies node properties or renames a node, identifying the resource and actions. However, it does not distinguish itself from sibling tools like rename_node or editor_set_node_properties, which have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as rename_node, editor_set_node_properties, or set_node_position. There is no mention of conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Godot process output.
| Name | Required | Description | Default |
|---|---|---|---|
| clear | No | Clear accumulated output after reading |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It says 'Read' implying non-destructiveness, but does not explain that output is accumulated, that reading may or may not clear it (despite the 'clear' parameter), or whether the tool blocks or returns immediately. Missing important behavioral context.
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 terse sentence, which is highly concise and front-loaded. However, it is so brief that it borders on under-specification, overlooking additional context that could be added without sacrificing 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?
For a tool with no annotations and no output schema, the description must compensate. It fails to explain what 'process output' entails, the return format, and the semantics of reading vs. clearing. The description is too minimal for the 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 schema covers the single 'clear' parameter with its own description and default value. The tool description adds no additional meaning about the parameter. Given 100% schema coverage, 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 'Read Godot process output' clearly identifies the action (read) and the resource (Godot process output), distinguishing it from other read tools in the sibling list. It is specific enough to convey what the tool does, though it could clarify what 'process output' refers to (e.g., stdout/stderr of a running 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 provides no guidance on when to use this tool versus alternatives like 'get_status' or runtime tools. It does not mention whether it is for running projects, what to do if no output exists, or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move/rename a file within project.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source file path (relative to project root) | |
| destination | Yes | Destination file path (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates mutation (move/rename) but does not disclose whether the destination is overwritten, whether directories are created, or what happens on error. There is no extra context beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence, front-loaded with the verb and resource, and contains no superfluous 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?
The tool is simple and the input schema is complete with parameter descriptions. However, the description lacks usage guidance and behavioral details such as overwrite behavior. Given the lack of annotations and output schema, it is minimally adequate but with 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?
The schema provides full descriptions for both parameters as relative paths, covering their meaning. The description adds no additional parameter semantics beyond what the schema already offers, so the 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: 'Move/rename a file within project.' It specifies the verb and resource, and distinguishes it from sibling tools like delete_file or create_directory. The scope 'within project' clarifies the 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?
There is no guidance on when to use this tool versus alternatives, no exclusions, or mention of for example editor_move_asset. The description simply states the function without context on choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read AnimatedSprite settings.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Specific node name | |
| scene_path | No | Filter to scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'Read' without disclosing behavior like whether it reads the active scene, what happens if the node doesn't exist, or whether it's non-destructive. This is a minimal disclosure gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no waste. It is concise, though it could be more informative without adding bulk, so it doesn't fully earn its place in terms of content.
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 annotations and no output schema, the description is too sparse. It doesn't explain return values, how the parameters interact, or what 'settings' includes, making it incomplete for an agent to invoke reliably among many similar read tools.
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 adds no additional parameter meaning, but the schema's descriptions ('Specific node name', 'Filter to scene') are clear, so no compensation 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 reads AnimatedSprite settings with a specific verb and resource. It distinguishes from other read_* siblings by targeting AnimatedSprite specifically, though it doesn't enumerate which settings are included.
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 vs alternatives or when it's appropriate. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read animation tracks and keyframes.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | Yes | Path to .tscn scene file containing the AnimationPlayer | |
| animation_name | No | Specific animation name to read (default: list all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior. 'Read' implies a read-only operation, but the description adds no context about return formats, defaults, or side effects. It doesn't contradict annotations (none exist), but it's minimal.
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, front-loaded with the verb and object, with no wasted words. It is efficiently 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?
The tool has only two parameters, both documented, and no output schema. However, the description is terse and doesn't explain what exactly will be returned or how to interpret the tracks/keyframes data. Given the complexity of animation data, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema (scene_path and animation_name), and the description adds no additional parameter semantics. Schema coverage is 100%, so baseline 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 'Read animation tracks and keyframes' clearly states the tool's function with a specific verb ('Read') and resource ('animation tracks and keyframes'). It distinguishes from sibling tools like read_animation_tree and diff_animation, though it doesn't explicitly name alternatives.
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 instead of alternatives such as list_animations or read_animation_tree. No use cases or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read AnimationTree with state machine.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | Yes | Path to .tscn scene file containing an AnimationTree node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation but does not state that explicitly, nor does it mention return format, side effects, or edge cases (e.g., missing AnimationTree node). The phrase 'with state machine' hints at scope but adds little behavioral detail.
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 short sentence, making it very concise and easy to parse. It front-loads the action and resource. However, it is so brief that it verges on under-specification, which costs a point compared to a more informative but still concise 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?
For a simple one-parameter tool, the description is still incomplete. It doesn't explain what the output will look like (and there is no output schema), nor does it mention any failure conditions or special requirements like whether the scene file must exist or be currently loaded. Given the minimalism, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter (scene_path) fully with a clear description, so the baseline is 3. The tool description does not add any further parameter meaning beyond suggesting the scene should contain an AnimationTree with a state machine, which is redundant with the schema's 'containing an AnimationTree node' note.
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 reads an AnimationTree node, specifically one with a state machine, which distinguishes it from related tools like read_animation or read_animated_sprite. However, it doesn't explicitly note when to choose this over other read tools, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as read_animation or read_scene. It also lacks prerequisites like whether the scene needs to be open or if the AnimationTree node must be the root. The description is purely functional without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Area2D/3D properties.
| Name | Required | Description | Default |
|---|---|---|---|
| node_name | No | Area2D/3D node name | |
| scene_path | Yes | Path to .tscn scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Read', implying non-destructive behavior, but does not mention return format, error handling, or any constraints (e.g., scene file requirement, editor-only operation). This is a meaningful gap for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the core purpose without waste. It is front-loaded and efficient, though it could arguably do more with that space given the lack of guidance elsewhere.
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 no annotations, no output schema, and only 2 parameters, the description is thin. It does not explain return values, when to use this read tool versus alternatives like read_collision_layers, or any prerequisites. The context is incomplete for an agent to invoke it 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 description coverage is 100%—both parameters have descriptions ('Path to .tscn scene' and 'Area2D/3D node name'). The tool description adds no parameter details beyond the schema, so the baseline 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 'Read Area2D/3D properties' uses a specific verb (Read) and resource (Area2D/3D properties), clearly indicating the tool's purpose. It stands out from sibling read_* tools by targeting a specific node type, though 'properties' is somewhat generic.
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. With many sibling read_* tools (e.g., read_collision_layers, read_camera), there is no explicit or implicit usage context to help an agent choose this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read AudioBusLayout.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to AudioBusLayout .tres file (default: default_bus_layout.tres) | default_bus_layout.tres |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only announces a read operation but does not describe return format, error behavior, or any side effects. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than concise effectiveness. It omits necessary context and reads as a placeholder rather than a helpful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with no output schema, no annotations, and a single parameter, the description should at least state what is returned or the file type expected. It does none of that, making it functionally incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the sole parameter 'path' with a full description (100% coverage), so the baseline is 3. The description adds no parameter information beyond what the schema already provides.
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 'Read AudioBusLayout.' is essentially a restatement of the tool name 'read_audio_bus_layout' with no additional detail. It does not clarify scope, output, or distinguish this tool from generic readers like read_resource.
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?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, or exclusions. The description provides zero context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List AudioListener2D/3D nodes for spatial audio positioning.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. While 'List' implies a read-only operation, the description does not explain the role of scene_path, what the return value looks like, or any side effects or limitations. It is too terse to be transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the core purpose, making it highly 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?
Given the tool has one parameter, no output schema, and no annotations, the description should at least cover the parameter and expected return. The one-sentence description omits these essential details, leaving the tool under-specified 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?
The schema description coverage is 0%, and the description provides no information about the sole parameter scene_path. Since the description must compensate for the missing schema documentation but does not, it fails to add any meaning to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('AudioListener2D/3D nodes'), and adds the purpose 'for spatial audio positioning,' which clearly distinguishes it from sibling read tools like read_audio_player or read_audio_stream.
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 clearly implies when to use this tool (when you need to list audio listener nodes), but it does not explicitly mention alternatives or when not to use it. This gives clear context without exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List AudioStreamPlayer nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No | Filter to scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'List AudioStreamPlayer nodes' without mentioning read-only nature, what nodes are included, return format, or any side effects. This adds minimal value beyond the tool 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 a single, front-loaded sentence with zero wasted words. It is appropriately concise for a simple listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must provide more context. It fails to explain what 'nodes' means (e.g., current scene or all project scenes), what the returned list contains, or default behavior without the filter. The description is too minimal for full 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?
The input schema has 100% coverage for the single parameter scene_path, with a description 'Filter to scene'. The tool description adds no parameter details, but since schema coverage is high, the 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 'List AudioStreamPlayer nodes' clearly specifies a verb (List) and a resource (AudioStreamPlayer nodes), making its primary function obvious. However, it doesn't specify the scope (e.g., current scene vs. project), which would fully distinguish it from similar tools like read_audio_listener or list_audio_files.
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?
There is no guidance on when to use this tool versus alternatives. The description provides no context about scenarios, prerequisites, or exclusions; the only hint is the optional scene_path filter, but it doesn't explain when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read audio file info: format, size, loop, bitrate from .import config.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to audio file (.wav/.ogg/.mp3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It discloses the return scope (format, size, loop, bitrate) and the source (.import config), but does not state whether it is read-only or mention error behavior for missing/invalid paths. As a read tool, the lack of side-effect disclosure is partially mitigated by the verb 'read', but more explicit context would be better.
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 that front-loads the primary action and resource, then lists the specific data fields. Every word provides value, with no redundancy or irrelevant detail.
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 one-parameter tool with no output schema and no annotations, the description is mostly complete. It covers what is read and from where. However, it leaves slight ambiguity about whether the path points to the audio file or the .import file, and it does not explain the return format or error conditions, which would be helpful for an agent to invoke it 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 baseline is 3. The description adds meaning by clarifying that the path refers to an audio file and that the tool reads from its associated .import config, which is not obvious from the schema alone. This extra context helps resolve how the path is used.
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 a specific verb and resource: 'Read audio file info' and specifies the source 'from .import config'. It identifies the exact pieces of information (format, size, loop, bitrate), distinguishing it from sibling tools like read_audio_player and read_import_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need audio file metadata from the .import config. However, it does not explicitly mention when not to use it or compare it with alternatives such as read_import_config or read_audio_player, leaving the boundary only vaguely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read camera configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | Yes | Path to .tscn scene file | |
| camera_name | No | Specific camera node name (default: first found) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'read', which implies a non-destructive operation, but it does not explain what happens if the camera is not found, what specifically constitutes 'configuration', or whether the return value is a summary or full detail. Compared to similar read tools, this lacks sufficient behavioral context.
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, front-loaded with the core action. It is appropriately short for a simple read tool, though it could benefit from a brief note about the scene file dependency. No wasted words, but the terseness contributes to its incompleteness.
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 only 2 parameters (one required), no output schema, and no annotations, the description should provide more context but does not. It fails to mention that the tool operates on a specific scene file, what camera configuration details are returned, or how the optional 'camera_name' parameter behaves. The schema covers parameter syntax, but the description leaves important usage context unexplained.
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 parameters have descriptions), so the baseline is 3. The description adds no extra parameter meaning beyond what the schema already provides, but it doesn't need to since the schema is complete. No contradiction or missing parameter information.
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 says 'Read camera configuration', which clearly identifies the verb ('read') and resource ('camera configuration'). It is more specific than just 'read camera', but it does not distinguish itself from sibling tools like 'read_scene' or 'editor_get_camera' that also deal with camera-related data.
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 vs alternatives. There are many sibling tools (e.g., 'list_cameras', 'read_viewport', 'editor_get_camera') but no mention of preferred use cases, prerequisites, or exclusions. The schema indicates it takes a scene path and optional camera name, but the description does not contextualize this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read CharacterBody properties.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | CharacterBody node name | |
| scene_path | Yes | Path to .tscn scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. The verb 'Read' clearly signals a non-destructive operation, which is useful. However, it does not disclose return format, whether the scene must be loaded, or behavior when name is omitted, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no wasted words. However, it is so terse that it omits potentially useful context, so while concise, it is not maximally well-structured for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter, no output schema), and the description together with the schema covers the basics. Still, it does not explain what 'properties' are returned or how the optional name affects behavior, leaving moderate gaps for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already described ('Path to .tscn scene' and 'CharacterBody node name'). The description adds no parameter-level meaning beyond the schema, so 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 uses a specific verb ('Read') and resource ('CharacterBody properties'), clearly indicating what the tool does. However, it does not distinguish itself from the many sibling read_* tools (e.g., read_area, read_soft_body), so it falls short of full differentiation.
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?
There is no guidance on when to use this tool versus alternative read_* tools. The description simply restates the tool's purpose and provides no context, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read collision layer names.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states 'Read', implying a non-destructive operation, but adds no further context about data source, return format, or error behavior. For a simple zero-parameter read, this is minimal but acceptable.
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 without any fluff. It is front-loaded with the verb and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with no output schema, the description is largely sufficient. It states what the tool does, though it could add context about the source of collision layer names or the output format. However, given the simplicity, it is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it adds no conflicting or confusing information.
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 'Read collision layer names' clearly states the action (read) and the resource (collision layer names). It is specific enough to distinguish this tool from siblings like write_collision_layers and other read_* 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or references to sibling tools such as write_collision_layers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read CollisionPolygon2D points from a scene.
| Name | Required | Description | Default |
|---|---|---|---|
| node_path | No | Specific CollisionPolygon2D node path (defaults to all) | |
| scene_path | Yes | Path to .tscn scene file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read operation but does not mention the optional node_path behavior (defaults to all), return format, or any side effects. The description adds minimal behavioral context beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded with the core action and resource. However, it omits useful details (like the node_path default), but for a simple tool, this level of brevity is acceptable.
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 no output schema and simple parameters, but the description does not explain what the function returns (e.g., coordinate format) or the behavior when node_path is omitted. Given the presence of sibling tools and the absence of annotations, more context is needed for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides. It implies scene_path is the source and node_path identifies the polygon, but does not elaborate on formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and identifies a specific resource ('CollisionPolygon2D points') with a source ('a scene'). It clearly distinguishes from siblings like read_collision_layers (layers vs points) and read_scene (whole scene vs specific polygon points). However, it does not explicitly name alternatives or elaborate on what 'points' entails, which prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of scenarios, exclusions, or comparison to sibling tools like read_collision_layers or read_scene. The one-line description offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Container layout.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Container node name | |
| scene_path | Yes | Path to .tscn scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states the action without any mention of side effects, permissions, return behavior, or safety profile. The description adds no behavioral transparency beyond what is implied by 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 extremely brief, which is concise, but it is also under-specified and lacks any structure beyond a simple phrase. While it is not verbose, it fails to convey necessary information, making it inappropriately sized for the tool's 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?
With no output schema and a simple description, the tool is contextually incomplete. It does not explain what a 'container layout' is, what data is returned, or how the parameters affect the operation. The description is insufficient for an agent to fully understand and correctly invoke the 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?
The input schema has full 100% coverage, with descriptions for both 'name' and 'scene_path'. The description itself adds no additional parameter meaning, so the baseline of 3 applies. The schema already handles parameter semantics adequately.
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 'Read Container layout' is essentially a tautology of the tool name 'read_container'. It provides a direct restatement without specifying what 'container layout' entails or how it differs from other read tools like read_scene or read_resource. No scope or distinguishing features are mentioned.
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?
There is no guidance whatsoever about when to use this tool versus alternatives. The description does not mention context, prerequisites, or exclusions. It is a single phrase with no actionable usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a C# .csproj (assembly, target framework, package refs).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .csproj file (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It communicates a read operation with no side effects, which is implied by 'Read'. However, it does not mention error behavior (e.g., file not found) or whether it returns parsed data or raw XML. For a simple read tool this is adequate but not rich.
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, front-loaded with the action and resource, and the parenthetical adds valuable specifics without waste. Ideal 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?
For a simple read tool with one parameter and no output schema, the description is mostly complete. It states what is read and the content categories. It could mention the return format, but the listed content types partially compensate. No missing critical 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% with a clear description for the 'path' parameter. The tool description adds no additional parameter semantics beyond what the schema already provides, so baseline 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?
Description uses a specific verb ('Read') and resource ('.csproj'), and explicitly lists the extracted content types (assembly, target framework, package refs). This clearly distinguishes it from sibling tools like list_csproj which lists files.
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 clear use case: reading a C# project file's metadata. However, it does not explicitly state when not to use it or mention alternatives such as read_project_config for Godot-specific config. Context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Curve resource.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .tres Curve resource |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Read' implies a non-destructive operation, but the description does not state potential errors, return format, or whether the file must exist. It adds no transparency beyond the verb itself.
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, consisting of a single clear sentence with no wasted words. It is appropriately front-loaded. However, it is arguably under-specified for a full tool description, though the simplicity contributes to its 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?
The description is minimal and lacks essential context. It does not describe the return value, error handling, or how this tool relates to sibling read tools. Given no output schema and no annotations, the description is insufficient for a complete understanding, despite the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'path' described as 'Path to .tres Curve resource'. The description adds no additional semantics beyond the schema. Baseline of 3 applies because the schema already documents the parameter thoroughly.
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 'Read Curve resource.' clearly states the action (read) and the target resource (Curve), matching the tool name. However, it does not differentiate from sibling tools like read_resource or read_path, which also read resources. It is clear but lacks distinction.
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. There is no mention of scenarios, prerequisites, or exclusions. The only implied usage is reading a Curve resource, but this is not explicitly stated as a recommendation or contrasted with other read tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Decal nodes with size and texture info.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it lists Decal nodes with size and texture info, conveying a read-only list operation. However, it does not disclose behavior around the optional scene_path (e.g., whether it defaults to the current scene, searches all scenes, or how it filters), nor does it describe the return structure. Since no annotations are provided, the description carries the full burden but provides only 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, short sentence that is front-loaded with the action and resource. It contains no filler or redundant information, making it highly concise, even though it sacrifices necessary details for completeness.
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 no output schema and no annotations, the description is too sparse for an agent to understand the full context. It does not explain the scene_path semantics, return values, or how this tool relates to other list/read tools in the large sibling set, so the description is insufficient for reliable invocation.
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 only parameter, scene_path, has a cryptic schema using 'anyOf' with 'not {}' and 'string', and 0% description coverage. The tool description never mentions this parameter, providing no help on how to set it, what values are valid, or what effect it has on the listing behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'Decal nodes' with details 'size and texture info.' This directly distinguishes it from sibling tools like read_texture_info or list_lights by clearly specifying the resource type and the type of information returned.
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?
There is no guidance on when to use this tool versus alternatives such as read_scene or editor_set_decal_param. The description does not mention the scene_path parameter or any use cases, exclusions, or prerequisites, leaving the agent without context for choosing this tool or understanding its scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Environment resource.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .tres Environment file or .tscn scene with WorldEnvironment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Read' conveys non-destructive behavior, which is useful since no annotations are provided. However, the description does not disclose what the tool returns (e.g., resource contents), error conditions, or any additional behavioral nuances. It is basic but not misleading.
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, short sentence with no filler or redundant content. It is appropriately sized for a simple tool, though it borders on under-specification. Structure is clean and 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?
For a simple one-parameter read tool, the description is minimally adequate. It lacks mention of return values or usage context, and there are no annotations to fill that gap. The schema provides the parameter details, but the description does not explain what the agent should expect from the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'path' is fully documented in the schema with a clear description of accepted file types. The tool description adds no extra parameter context, but with 100% schema coverage, the schema carries the information adequately, so the baseline 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 'Read Environment resource' clearly states a specific verb ('Read') and a specific resource type ('Environment resource'), which distinguishes it from generic siblings like read_resource. However, it could be slightly more explicit by noting it handles .tres files or .tscn scenes with WorldEnvironment, though that detail is in the schema.
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 vs alternatives such as read_scene, read_resource, or list_environments. The description simply states what it does without any context, preconditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read export presets from export_presets.cfg.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and source file, but does not mention return format, error behavior (e.g., missing file), or whether it parses the file into structured data. This is insufficient given the lack of annotations and output 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 a single, concise sentence that immediately conveys the tool's purpose. No filler or redundant information; it is well-structured and 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's simplicity (no parameters, no output schema), the description is nearly complete. It identifies the exact resource and source. However, it does not describe the return structure, which could be useful since no output schema exists, but the low complexity makes this a minor gap.
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 value by specifying the exact source file (export_presets.cfg), which is the only context needed. No parameter explanations are required.
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 reads export presets from a specific file, export_presets.cfg. The verb 'read' and resource 'export presets' are precise, distinguishing this from sibling tools like read_project_config or read_import_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you need export presets) but does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or prerequisites. For a simple read tool, the implied usage is reasonable, but it lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read .gdextension config.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to .gdextension file (default: auto-detect) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool reads configuration, but does not describe potential side effects, permissions, return format, or error behavior. While the operation is clearly read-only, the description adds no behavioral context beyond the literal action.
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, 'Read .gdextension config.', with no filler or redundant content. It is front-loaded and perfectly sized for the tool's simple 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?
The tool lacks an output schema, so the description should explain what is returned or any relevant context. It does not specify the return value (e.g., the parsed config content), error cases, or default behavior details beyond what the schema already provides. Given the simplicity of the tool, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, with the 'path' parameter documented as 'Path to .gdextension file (default: auto-detect)'. The description adds no additional parameter semantics, but since the schema is complete, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads .gdextension config files, using a specific verb ('Read') and resource ('.gdextension config'), which distinguishes it from other read_* tools like read_project_config or read_resource. It is unambiguous and directly reflects the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use when you need to read a .gdextension file. However, the description does not explicitly compare with alternatives or provide when/when-not guidance, relying on the tool name and file extension for context. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Gradient resource.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .tres Gradient resource |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only says 'Read'. It doesn't state that the tool is read-only, describe return format, or mention any side effects or limitations. This is insufficient for a tool reading a resource file.
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 brief and front-loaded, but it's under-specified. It essentially restates the tool name without adding meaningful content. While concise, it misses opportunities to provide useful context, making it average for this dimension.
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 schema (one param) and no output schema, the description should explain what reading a Gradient resource entails or what the return value represents. It does neither. Additionally, it doesn't differentiate itself among the many sibling read tools, leaving the agent without enough context to judge suitability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter 'path' with a description ('Path to .tres Gradient resource'), so the schema covers 100% of parameters. The description adds no parameter information beyond what the schema already provides, keeping the score at the baseline of 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 clearly states a specific action ('Read') on a specific resource type ('Gradient resource'), which is distinct from generic read tools like read_resource. However, it doesn't explicitly distinguish itself from other read_* sibling tools, and the wording closely mirrors the tool name, adding little new information.
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 such as read_resource or other resource-specific readers. There are no mentions of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List GridMap nodes with cell size and mesh library references.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states the action and data; it does not disclose whether it reads from the current scene, whether the optional scene_path alters behavior, or if there are any side effects, placing the full burden on an under-specified description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler; it is front-loaded with the action and key details. While sparse, it is not wordy, earning a high score for 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?
With no output schema and no parameter semantics, the description gives only a high-level summary; it omits how scene_path affects the result, the result format, and any fallback behavior, making the tool under-specified for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter scene_path with 0% schema description coverage, and the tool description does not mention the parameter at all, leaving the agent to guess how to scope the listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource 'GridMap nodes' and explicitly mentions the data returned ('cell size and mesh library references'), making it distinct from generic read_* siblings.
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 like read_tilemap or read_scene; there are no exclusions or preferred contexts, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read .import file config.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_path | Yes | Path to the source asset file (e.g. "sprites/hero.png") — the .import file is derived automatically |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without explaining what the config content looks like, whether the file must exist, or what the return format is. This is insufficient for a tool with no output 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 a single, focused sentence that is easy to parse and front-loads the primary action. It wastes no words and is appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one well-documented parameter, but the description is minimal. It does not explain what 'config' means or what the output will be, which would be helpful since there is no output schema. However, for a straightforward read operation, the description is borderline adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter description gives a clear example and notes that the .import file is derived automatically. The description adds no extra parameter semantics, but the schema already handles this, so 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 clearly states the verb ('Read') and the resource ('.import file config'), which distinguishes it from sibling tools like write_import_config (writing) and list_import_files (listing). The schema parameter further clarifies the specific input required, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. There is no mention of when to prefer this over list_import_files or read_resource, nor any exclusions or prerequisites. The usage is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read input map with key bindings.
| 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 disclose behavioral traits. It only says 'read', which implies non-destructive, but it does not explain return values, error conditions, or whether the editor must be running. This is minimal 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?
The description is a single concise sentence that is front-loaded and to the point. It earns a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, leaving the description to fully inform the agent. It does not describe what the input map consists of, how it differs from editor_get_input_map, or what the return value looks like, so contextual completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. According to the rules, a no-parameter tool gets a baseline of 4, and the description adds no parameter info because there are none.
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 reads an input map and mentions key bindings, making its function specific. However, it does not differentiate from sibling tools like editor_get_input_map, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as editor_get_input_map or input-modification tools. No usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a physics joint config in a scene.
| Name | Required | Description | Default |
|---|---|---|---|
| joint_name | No | Specific joint node name (defaults to all joints) | |
| scene_path | Yes | Path to .tscn scene file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral detail. It does not mention that joint_name defaults to all joints (though the schema does), what happens when the scene or joint is missing, or what format the returned config takes. The description adds no insights beyond the tool's basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is concise and efficiently communicates the core 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?
Although the tool is simple, the description lacks essential context for an agent: it omits the default behavior for joint_name (only in schema), the return format, and any error conditions. Without an output schema or annotations, these gaps make the description incomplete for confident invocation.
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 parameters are fully documented there. The description adds minimal semantics beyond the schema, only indicating the domain ('physics joint config') without elaborating on the parameters. This meets the baseline for high schema coverage but does not enhance understanding.
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 reads a physics joint config in a scene, with the verb 'Read' and the specific resource 'physics joint config'. This distinguishes it from sibling read tools like read_scene or list_joints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_joints for discovering joint names or read_scene for broader scene inspection. The description only states what it does, leaving selection to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List PointLight2D/DirectionalLight2D nodes with energy and shadow settings.
| Name | Required | Description | Default |
|---|---|---|---|
| light_type | No | Filter: PointLight2D, DirectionalLight2D | |
| scene_path | No | Filter to scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states that the tool lists nodes with energy and shadow settings, which implies read-only behavior, but it does not disclose important behavioral details such as whether it searches the whole project or current scene, or what happens when no filters are provided. Basic context is present but not comprehensive.
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 that is front-loaded with the action verb and resource. It contains no unnecessary words or filler, making it very 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?
Given the absence of annotations and output schema, the description is somewhat incomplete. It does not describe the return format (e.g., node paths, values) or clarify the behavior of optional filters. However, the schema fills in parameter details and the core purpose is clear, making it minimally viable but with 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?
The input schema already provides complete descriptions for both parameters (light_type and scene_path), with 100% coverage. The description adds no additional parameter semantics beyond what the schema offers, so a 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 verb 'List' and the resource 'PointLight2D/DirectionalLight2D nodes' with specific details about energy and shadow settings. This distinguishes it from sibling tools like set_light_2d_param (which modifies) and list_lights (which may be more generic).
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 use for reading light 2d nodes, but does not explicitly state when to use this instead of alternatives or when not to use it. There is no mention of exclusions or alternative tools, so usage guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Marker2D/Marker3D position markers across scenes.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No | ||
| marker_type | No | Marker2D or Marker3D |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation via the verb 'List' but does not explicitly state non-destructive behavior, whether it scans all project scenes or only the current scene, or what data 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?
One short sentence with no filler. The key information (verb, resource, scope) is front-loaded and every word contributes.
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 no output schema or annotations, the description needs to provide more operational context. It does not explain return format, the meaning of scene_path, or behavior when parameters are omitted, leaving critical usage details unspecified.
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 only 50%; marker_type is described in the schema, but scene_path has no schema description and the tool description adds no parameter details. The description merely repeats the marker types without explaining optional paths or value formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('Marker2D/Marker3D position markers'), and scope ('across scenes'). This clearly distinguishes it from sibling mutating tools like editor_set_marker_param.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives, nor does it explain how scene_path affects scope or mention exclusions. Usage context is only implied by the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read material with PBR formatting.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .tres material file (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Read' implies a non-destructive operation, but beyond that, no behavioral traits are disclosed: no mention of return format, error behavior, side effects, or whether special permissions are needed. The phrase 'with PBR formatting' is ambiguous and could mislead.
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 short sentence, so it is concise and easy to parse. However, it is under-specified: it lacks meaningful details that would justify its brevity. It is not bloated, but it also does not earn its place by conveying critical 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?
For a simple tool with one parameter, no annotations, and no output schema, the description is incomplete. It does not explain what 'PBR formatting' means, what output the user should expect, or how it differs from generic resource/materials reading. The param schema covers file path, but the tool's behavior and return value remain opaque.
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 for the single parameter 'path' is 100%, with a clear description of it as a path to a .tres material file. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb and resource ('Read material') which gives a basic sense of purpose. However, the qualifier 'with PBR formatting' is vague and does not distinguish it from sibling tools like read_resource or read_physics_material. It does not clarify what PBR formatting means or what specific material data is returned.
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 such as read_resource or set_material_param. There is no mention of intended use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read MeshInstance properties.
| Name | Required | Description | Default |
|---|---|---|---|
| node_name | No | MeshInstance node name (default: first found) | |
| scene_path | Yes | Path to .tscn scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Read' which implies read-only, but it does not describe return format, error handling, or side effects. There is no mention of what happens if the node is not found or the scene path is invalid.
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 redundant words. It is appropriately concise for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite clear purpose, the description is incomplete for a tool with no output schema. It does not specify what 'properties' are returned, whether it returns all properties or a subset, or any error behavior. The lack of return value explanation leaves significant ambiguity.
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 parameters are already well-documented (scene_path, node_name with default). The description adds no additional parameter meaning beyond what the schema provides, aligning with the baseline score of 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 clearly states the action (read), resource (MeshInstance), and scope (properties). The verb+resource combination distinguishes it from sibling readers like read_multimesh or read_scene, making the tool's purpose immediately 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 guidance is provided on when to use this tool versus alternatives. The description does not mention use cases, exclusions, or contrasting with other read_* tools, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List MultiMeshInstance nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No | Filter to scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states 'List MultiMeshInstance nodes' without disclosing read-only nature, return format, or any side effects. The verb 'List' implies enumeration but does not explicitly state behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it highly concise and 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?
With no output schema, the description should explain what the list contains (e.g., node paths, names), but it does not. It also does not clarify the scope (current scene, all scenes) or whether the list is filtered by default, leaving the agent with incomplete contextual 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 the single parameter 'scene_path' described as 'Filter to scene'. The description adds no additional meaning beyond what the schema already provides, so the baseline 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 uses a specific verb 'List' and a clear resource 'MultiMeshInstance nodes', which precisely identifies the operation. It distinguishes itself from sibling tools by targeting a unique node type (e.g., read_mesh_instance, read_collision_polygon).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention typical use cases, filtering options, or compare itself to other listing/reading tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List OccluderInstance3D and OcclusionPolygon2D nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'List' implies a read-only operation, it does not disclose expected return format, whether it operates on the current scene or a specified scene, or any side effects. This is minimal and leaves ambiguity.
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 that is front-loaded with the main purpose. It contains no unnecessary words and is appropriately compact for a tool that lists specific nodes.
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 no output schema, no annotations, and low parameter coverage, so the description needs to compensate. It fails to explain what the list returns, how the optional scene_path affects the result, or any behavioral context. The description is too sparse for a tool with these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'scene_path' parameter at all. The parameter's schema is non-standard (anyOf with 'not': {}), and the description adds no meaning to the parameter name, leaving it completely unexplained.
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 specific node types (OccluderInstance3D and OcclusionPolygon2D), using the verb 'List' with a specific resource. This distinguishes it from sibling read_* tools that target other node types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when these node types need to be listed, but provides no explicit guidance on when to use this tool vs alternatives, nor any exclusions or prerequisites. It is merely a functional statement without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read ParallaxBackground layers.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No | Filter to scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. The verb 'read' implies a non-mutating operation, but the description does not disclose output format, whether it lists all layers, or how the optional scene_path affects results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler; every word is informative.
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 optional parameter and no output schema, the description is minimally adequate, but it lacks details about return value structure and the effect of scene_path. The schema partially compensates for the parameter, but the overall description is thin.
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 only parameter (scene_path) is fully described in the schema with 'Filter to scene', so the description adds no additional meaning. Baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the target resource ('ParallaxBackground layers'), which distinguishes it from the many other read_* sibling tools. However, it does not elaborate on what 'layers' means or what the output includes.
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 given about when to use this tool versus alternatives, nor any prerequisites or exclusions. It simply restates the function without contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List particle systems.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No | Filter to a specific scene | |
| particle_type | No | Filter: GPUParticles3D, CPUParticles3D, GPUParticles2D |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'List particle systems' and does not disclose return format, whether it scans scene files, or any side effects. It's a read operation but provides minimal behavioral detail.
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?
At three words, it is exceptionally concise and front-loaded. The single sentence is easy to parse, though it could be considered under-specified rather than appropriately 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?
As a list tool with no output schema, the description should clarify what the list contains (e.g., node paths, scene paths) and what 'particle systems' refers to. It omits this context, leaving the agent to infer the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents both parameters (scene_path and particle_type) clearly. The description adds no additional parameter semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (List) and resource (particle systems), distinguishing it from other read_* tools. However, it doesn't specify the scope (e.g., in the project, in all scenes), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives, no prerequisites, and no exclusions. It simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Path node with curve.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Path2D/Path3D node name | |
| scene_path | Yes | Path to .tscn scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Read' which implies a non-mutating operation, but it does not describe what the tool returns (e.g., curve data), error behavior, or any side effects, making it insufficient for safe invocation.
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 fluff. It is appropriately front-loaded with the verb and resource, though it is so brief that it borders on under-specification, which is penalized in other dimensions.
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 there is no output schema and no annotations, the description should clarify what the tool returns or how to interpret 'with curve'. It does not, leaving the agent uncertain about the return value and behavior, making it incomplete for a tool with even low 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?
The input schema has 100% coverage with clear descriptions for both parameters ('Path2D/Path3D node name' and 'Path to .tscn scene'). The description adds no additional parameter semantics beyond what the schema already provides, so 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 'Read Path node with curve' clearly states the action (read) and the resource (Path node, including its curve). It is specific enough to distinguish from sibling tools like read_curve, though it does not explicitly name any alternatives.
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 offers no guidance on when to use this tool versus alternatives. There are no context cues, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read PhysicsMaterial.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to PhysicsMaterial .tres file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether the file must exist, what the return value is, or whether any side effects occur. The word 'Read' implies non-destructive behavior, but this is not explicit.
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, which is concise, but it is under-specified to the point of adding no value beyond the tool name. It does not 'earn its place' because it only restates the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but without an output schema or any additional description, it is incomplete. The agent is not informed about the return format, error behavior, or even that the file is read from disk.
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 the only parameter 'path' is clearly described as 'Path to PhysicsMaterial .tres file'. The description adds no additional parameter information, but the schema already provides adequate semantics, so a 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 'Read PhysicsMaterial' is a tautology; it directly restates the tool name with no additional detail. It names the resource but does not clarify what reading involves or how it differs from read_resource or read_material.
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 other read tools. The description does not mention any specific use cases, prerequisites, or alternatives, leaving the agent without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read and parse project.godot.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention return format, error behavior, or whether the file is read from the project root. 'Read' implies non-destructive, but this is not explicit.
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, focused sentence. It is appropriately sized for a tool with no parameters and no complex behavior, with zero filler 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?
The tool is simple, but the description lacks details about the output format (e.g., parsed dictionary vs raw text) and failure modes. With no output schema, more context would be helpful, but the tool's trivial nature allows a baseline score.
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 takes no parameters, and the schema is an empty object. The baseline score of 4 applies because there are no parameter semantics to clarify, and the description adds no unnecessary paranoia.
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 'Read and parse project.godot' clearly states the action (read and parse) and the specific resource (project.godot), distinguishing it from sibling tools like diff_project_config or write_project_config. It is specific and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as read_import_config or diff_project_config. It only states what it does, leaving usage context entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read project identity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Read project identity' without describing return format, whether any project state is required, or whether it has side effects. The read nature is implied by the name, but the description adds 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?
While the description is very short, it is under-specified. It doesn't earn its place because it fails to convey what 'project identity' means. It is structurally concise but at the cost of essential clarity.
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 (0 parameters, no output schema, no annotations), a one-sentence description could be sufficient, but this one is too vague. It doesn't define 'identity' or explain what the tool returns, leaving the agent uncertain about its behavior and integration.
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 0-parameter baseline of 4 applies. The description doesn't need to elaborate on parameters, and the empty schema fully covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Read') and a resource ('project identity'), but 'identity' is ambiguous—it doesn't clarify that this reads the project icon, nor does it distinguish the resource from siblings like read_project_config. The purpose is somewhat clear 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?
There is no guidance on when to use this tool versus alternatives, no exclusions, and no mention of prerequisites. The description simply states what it does without contextualizing its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List RayCast/ShapeCast nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| ray_type | No | Filter: RayCast2D, RayCast3D, ShapeCast2D, ShapeCast3D | |
| scene_path | No | Filter to scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It indicates a read-only 'List' operation but does not mention return format, scope (current scene vs project-wide), or behavior for empty results, leaving the agent under-informed.
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 that clearly communicates the tool's purpose. It is front-loaded and contains no redundant or filler content, earning 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?
For a simple list tool with full parameter schema coverage, the description is minimally viable. However, because there is no output schema or annotations, it lacks explicit context about return values and the default scope (e.g., current scene if scene_path is omitted), leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for both parameters (ray_type and scene_path) with 100% coverage. The main description adds no additional meaning beyond what the schema already conveys, so it meets the baseline without 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 clearly states the tool lists RayCast and ShapeCast nodes, covering all four variants (2D/3D). This specific verb+resource scope distinguishes it from sibling read_* tools like read_scene or read_collision_polygon.
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 such as find_nodes_in_scenes or read_scene. It only states the basic purpose without any exclusions, prerequisites, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List GI probes.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No | Filter to scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'List' which implies a read-only operation, but does not confirm whether it requires an open scene, what the return format is, or any side effects. This is minimal and 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 extremely brief (three words) and free of fluff, but it is under-specified. While conciseness is valued, the lack of detail about the list results or filtering behavior makes it less effective than a slightly longer but more informative 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 the single optional parameter and no output schema, the description should at least explain what the list contains and how the filter behaves. It only states 'List GI probes.', leaving the agent to infer return values and the effect of scene_path. This is a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a description for the only parameter, scene_path, as 'Filter to scene', achieving 100% coverage. The tool description adds no further parameter semantics, so the 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?
'List GI probes.' clearly states the verb (list) and resource (GI probes), distinguishing it from sibling tools that read other resource types. It is concise and unambiguous, though it does not elaborate on what constitutes a GI probe or the exact nature of the list.
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, nor any mention of prerequisites or context. The description merely states the action without indicating scenarios where it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a .tres resource file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .tres or .res file (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the only behavioral disclosure. 'Read' implies a non-mutating operation, but the description doesn't disclose return format, error behavior, or that it's read-only aside from the verb.
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?
One sentence, perfectly concise and to the point. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should at least indicate what the return value is (e.g., parsed resource properties). Missing this key context for a read 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 already provides full description for the single path parameter. The description adds no extra semantic detail 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?
Clearly states the action (read) and the target (.tres resource file). Distinguishes from many specific resource readers but doesn't explicitly differentiate from them, e.g., read_material.
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 the many sibling read_* tools. Does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List RichTextLabel nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | RichTextLabel node name | |
| scene_path | No | Filter to scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It simply states 'List RichTextLabel nodes.' without explaining whether this is read-only, what the return format is, whether it operates on the current scene or the whole project, or any side effects. The read-only implication from the name is not enough.
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, focused sentence with no wasted words. It is appropriately sized for the tool's apparent simplicity, and the key information is 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?
The description is too incomplete for a tool with no output schema and no annotations. It fails to specify what 'list' returns (e.g., node paths, names, nested information), the scope of the listing (current scene vs. all scenes), or any filtering behavior. The schema covers parameters, but the overall usage 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 baseline is 3. The description adds no additional meaning to the parameters 'name' and 'scene_path', but the schema already describes them adequately. The description does not need to compensate.
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 'List RichTextLabel nodes.' clearly states the tool's purpose with a specific verb ('List') and resource ('RichTextLabel nodes'). It distinguishes from sibling read_* tools which target different node types, and clarifies that the tool enumerates nodes rather than reading text content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_ui_nodes or find_nodes_in_scenes. The description does not mention typical use cases, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a .tscn scene file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .tscn file (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states 'Read' without explaining what reading entails, whether any side effects occur, or what the return format is. This is insufficient for a tool with zero annotation coverage.
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 wasteful words. It is appropriately short for a simple read operation, though it could include more context without becoming bloated.
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 no output schema and no annotations, so the description must explain the return value and behavior. It only says 'Read a .tscn scene file' without indicating what output is produced, whether the full content is returned, or any limitations. This is incomplete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the only parameter 'path', including a description. The tool description adds no additional meaning beyond what the schema already provides, so the baseline 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 verb 'Read' and the specific resource '.tscn scene file', which uniquely identifies this tool among siblings like read_resource and read_script. It is specific and distinguishes the target file type.
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. It does not mention any exclusions, prerequisites, or context that would help an agent decide between read_scene and other read_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a script file with line numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to script file (relative to project root) | |
| line_count | No | Number of lines to read (optional) | |
| line_start | No | Starting line (1-indexed, optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It implies a read-only operation and suggests output includes line numbers, but it does not detail how the file content is returned (e.g., full vs. partial), error handling, or that line_count/line_start modify output. This is minimal but not misleading.
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 one concise sentence, front-loaded with the core action ('Read a script file') and a key output detail ('with line numbers'). Every word earns its place with no fluff or repetition.
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 read tool with a well-documented schema, the description is adequate but minimal. It lacks context about what 'script' refers to (GDScript vs. other), whether it reads the entire file by default, and how line_count/line_start interact. No output schema exists, but the description doesn't explicitly mention return format beyond line numbers, leaving some ambiguity.
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 fully documents all three parameters with descriptions (path relative to root, line_count optional, line_start optional). The tool description adds no additional parameter semantics beyond stating line numbers, so it does not exceed the schema's coverage. Baseline 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 tool reads a script file and includes line numbers, making its primary purpose obvious. It does not explicitly differentiate from siblings like read_script_structure or list_scripts, but the 'with line numbers' detail hints at raw content viewing, which is a distinguishing feature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as read_script_structure, list_scripts, or diff_script. There is no mention of prerequisites, use cases, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze GDScript structure.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .gd file (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Analyze GDScript structure,' which essentially restates the tool name. It does not explain what analysis means, what output is produced, whether it performs validation, or any side effects, leaving the agent without meaningful behavioral information.
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 this is under-specification rather than concise writing. It does not add any detail beyond what the tool name already implies, so the brevity does not make the description more useful.
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 that analyzes script structure, the description is critically incomplete. It does not specify what kind of structure is returned, what the output looks like, whether it handles errors gracefully, or any limitations. With no output schema and no annotations, the agent cannot infer expected behavior 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?
The input schema fully documents the single 'path' parameter with a clear description ('Path to .gd file (relative to project root)'), giving 100% coverage. The tool description adds no additional meaning beyond the parameter's schema description, so the baseline 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 states a clear verb ('Analyze') and resource ('GDScript structure'), which distinguishes it from read_script (which reads content). However, 'structure' is vague and could mean an abstract syntax tree, class layout, function signatures, or something else, leaving the exact purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus siblings like read_script, validate_script, or search_in_scripts. There is no mention of typical use cases, prerequisites, or situations where an alternative would be better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a .gdshader file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .gdshader file (relative to project root) | |
| line_count | No | Number of lines to read (optional) | |
| line_start | No | Starting line (1-indexed, optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the tool's purpose and does not mention output format, error behavior, or the existence of optional line-range parameters.
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 wasted words. While terse, it is appropriately sized for the simple action described, though it could briefly mention optional parameters.
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 no annotations and no output schema, the description should provide more context about the return value and optional line_count/line_start behavior. The current description is too minimal to fully guide an agent in correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents path, line_count, and line_start. The description adds no additional meaning beyond the schema, hence the baseline score of 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 a specific verb and resource: 'Read a .gdshader file.' It clearly indicates the tool's function and distinguishes it from siblings like read_shader_include by specifying the .gdshader file type, though it does not explicitly mention alternatives.
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?
There is no guidance on when to use this tool versus alternatives. No mention of read_shader_include, list_shaders, or write_shader. The description simply states what the tool does without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a .gdshaderinc file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .gdshaderinc file (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states the operation ('Read') and the file type, omitting return format, error handling, side effects, or whether file contents are returned raw. This leaves the agent uncertain about the outcome.
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 extraneous content. It is front-loaded and to the point, ideal for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and the schema covers the parameter. However, without an output schema, the description does not specify what the tool returns (e.g., file contents as a string) or how errors like missing files are handled. This is a moderate gap for agent confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete coverage of the single 'path' parameter with a clear description ('Path to .gdshaderinc file (relative to project root)'). The tool description adds no extra parameter details, so the schema 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 clearly states a specific verb and resource: 'Read a .gdshaderinc file.' It is unambiguous about the file type. However, it does not differentiate from sibling tools like read_shader or list_shader_includes, limiting its distinguishing value.
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. There is no mention of use cases, prerequisites, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Skeleton bone hierarchy.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Skeleton3D node name | |
| scene_path | Yes | Path to .tscn scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description carries the full burden. It only states 'Read Skeleton bone hierarchy,' which conveys non-destructive intent but reveals nothing about return format, possible errors, or expected input requirements. This is minimal 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?
The description is a single, front-loaded sentence with no filler. It is appropriately sized for a simple read operation.
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 no output schema and no annotations, the description fails to explain what the returned bone hierarchy looks like or how to interpret it. While the tool is simple, the description leaves significant gaps for an agent trying to use it 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 description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning for 'name' or 'scene_path' beyond what the schema provides, yielding the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('Skeleton bone hierarchy'), making the tool's function clear. It does not explicitly distinguish from siblings like list_skeletons, but the focus on hierarchy is specific enough for a 4.
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. There is no mention of prerequisites, scene preparation, or comparison to sibling tools like read_scene or list_skeletons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List SoftBody3D nodes with mass and stiffness.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the basic listing action but does not disclose how scene_path affects results, whether it reads from the current scene or a different file, or any error/edge-case behavior. This is minimal for a read operation.
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 that immediately states the action and target with no filler. It is appropriately front-loaded and compact.
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 one optional parameter and no output schema or annotations, so the description must cover both behavior and parameter semantics. It explains the core action but leaves scene_path and the return format unexplained, which is a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter scene_path with no descriptive coverage (0%), and the description does not mention it at all. The agent receives no explanation of what scene_path means or how to use it, making correct invocation ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the exact resource: SoftBody3D nodes, along with the returned properties (mass and stiffness). This clearly distinguishes it from sibling tools like editor_set_soft_body_param or generic read_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 context on when to use this tool, no mention of alternatives, and does not specify whether it is intended for inspection versus modification. No exclusionary guidance or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List SpringArm3D nodes with spring length and collision settings.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure, but it only states the basic action. It does not mention read-only nature, error handling, or what happens if scene_path is invalid or omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no unnecessary words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core purpose is conveyed, but the tool has an unexplained parameter and no output schema, so the description does not fully cover usage context. It is adequate but leaves gaps regarding how scene_path affects the result.
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 sole parameter 'scene_path' is not mentioned in the description, and the schema provides no description for it. This leaves the parameter's meaning and effect completely undocumented.
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 action ('List') and the specific resource ('SpringArm3D nodes') along with the fields included (spring length and collision settings). This distinguishes it from sibling read_* tools that target different node types.
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 given about when to use this tool versus alternatives, nor are any exclusions or preconditions mentioned. The description is purely declarative and provides no decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List AnimatedSprite nodes and their SpriteFrames resources.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only restates the basic listing behavior and adds no detail about return shape, whether scene_path is required, or how scenes are searched. With no annotations, this leaves behavioral expectations underspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler. It is front-loaded and efficient, though it may be slightly terse.
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 covers the high-level purpose but omits parameter usage and output expectations. Given no output schema and no annotations, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one undocumented scene_path property (0% coverage), and the description never mentions it. The parameter name gives only a hint, so the description adds no semantic 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?
The description uses a specific verb ('List') and identifies both the target (AnimatedSprite nodes) and the associated data (their SpriteFrames resources). It is clear, though it does not explicitly distinguish itself from the sibling read_animated_sprite.
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 given about when to use this tool versus alternatives such as read_animated_sprite or list_resources. There is no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read StyleBox resource.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to StyleBox .tres file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Read' which is already implied by the name, and does not mention return format, error behavior, or side effects. This is a significant gap for a tool with zero annotation support.
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, focused sentence with no wasted words. It is appropriately concise for such a simple tool, though it could have been slightly more informative without sacrificing 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?
Given the lack of annotations, output schema, and any additional context, a one-line description is insufficient. It does not explain what the tool returns, whether it validates the file, or when it should be used relative to other read tools. The description is minimal but leaves critical 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?
The schema provides 100% coverage for the single 'path' parameter with a clear description ('Path to StyleBox .tres file'). The description adds no additional meaning, but the schema already handles it, so the baseline 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 a specific verb ('Read') and resource type ('StyleBox'), distinguishing it from other read_* siblings. However, it lacks any additional context about the resource format or what reading entails, so it's not quite a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives like read_resource or set_stylebox. It does not mention any conditions, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read TabContainer/TabBar.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | TabContainer/TabBar node name | |
| scene_path | Yes | Path to .tscn scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Read' implies a non-destructive operation, but the description discloses nothing else: no return format, no preconditions, no side effects. With no annotations, this sparse description leaves significant behavioral ambiguity.
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 only a short fragment, but it is under-specified rather than economically complete. It fails to include useful context that would justify its brevity, making it too thin for an effective tool 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 no output schema, the description should clarify what information the tool returns, but it does not. This leaves agents guessing about the tool's utility, output, and exact behavior, which is inadequate even for a simple read 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?
Both schema parameters (name, scene_path) have clear descriptions in the input schema, covering 100% of them. The tool description adds no additional parameter meaning or usage context beyond what the schema already provides.
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 'Read TabContainer/TabBar' identifies the tool's action and target resource, but it nearly duplicates the tool name and adds no detail about what reading entails. It distinguishes from sibling tools only by naming the node type, without explaining scope or 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?
There is no guidance on when to use this tool, what scenarios it fits, or how it compares to alternatives like read_container or read_ui_nodes. The description gives no context for selecting or switching between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read texture asset info.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to texture asset (e.g. "sprites/hero.png") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Read', implying a non-mutating operation, but does not specify what info is returned, error behavior, or any side effects. The absence of an output schema makes this vagueness problematic.
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 waste. It is appropriately concise for a simple tool, though under-specified in terms of content.
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 annotations and no output schema, the description is too vague. It does not clarify what 'info' includes or how the agent should use the result, making it incomplete for reliable invocation.
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 description covers 100% of the single parameter 'path', including an example. The description adds no additional meaning beyond what the schema already provides, so the 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 uses the specific verb 'Read' and the resource 'texture asset info', making it clear the tool retrieves information about a texture asset. However, it does not distinguish it from sibling tools like 'list_textures' or 'load_sprite'.
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?
There is no guidance on when to use this tool versus alternatives. The description simply states the function without providing context, exclusions, or references to related tools such as 'list_textures'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Theme resource with type-aware grouping.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to Theme .tres or .theme file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. 'Read' implies a non-mutating operation, but the description doesn't explicitly state that files are not modified, nor does it clarify what 'type-aware grouping' does or what output format to expect. It adds minimal behavioral context beyond the verb.
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 short sentence with no redundant words, making it efficient and front-loaded. However, its brevity borders on under-specification, and the term 'type-aware grouping' is used without explanation, slightly reducing its effectiveness.
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 no output schema and no annotations, the description should clarify return values and behavioral nuances. It fails to explain what 'type-aware grouping' means or what data the agent will receive, leaving significant gaps for a tool that reads a potentially complex Theme resource. This makes the description inadequate for informed use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single parameter 'path' as 'Path to Theme .tres or .theme file', giving 100% schema description coverage. The tool description adds no extra meaning about the parameter, so it neither improves nor detracts from the schema's clarity, meeting the baseline score of 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 clearly identifies the action ('Read') and the specific resource ('Theme resource'), making the purpose distinct from generic tools like read_resource. However, the phrase 'type-aware grouping' is vague and doesn't fully explain what this grouping entails, preventing a perfect score.
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?
There is no guidance on when to use this tool versus alternatives such as read_resource or read_stylebox. The description omits any context about suitable scenarios or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read TileMapLayer in scene.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | Yes | Path to .tscn scene containing TileMapLayer nodes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only states it reads TileMapLayer, but does not mention return format, what happens if no TileMapLayer exists, whether it reads all such nodes or only the first, or any side effects. The read-only nature is implied by the verb but not explicitly stated, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant words. It is front-loaded with the verb and direct object. While it could include more detail, it is appropriately brief for a straightforward read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but without an output schema, the description should at least hint at the return value or data shape. It does not. The description is too sparse to be considered complete for an AI agent to know what to expect from the invocation, especially in a broader scene-editing 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 schema already provides 100% coverage for the single parameter scene_path with a clear description ('Path to .tscn scene containing TileMapLayer nodes'). The tool description adds no additional meaning beyond what the schema states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read TileMapLayer in scene' clearly identifies a specific read operation targeting TileMapLayer nodes within a scene. It uses a verb+resource structure and distinguishes itself from sibling tools like read_tileset and read_scene by naming the specific node type. However, it is terse and could be more explicit about returning layer properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the action ('read') and target ('TileMapLayer in scene'), so an agent can infer when to use it. However, there is no explicit guidance on when not to use it or which alternatives (e.g., read_tileset) are better suited for other scenarios. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read TileSet resource.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .tres TileSet file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must communicate behavioral traits. It only states 'Read', which implies a safe read operation, but does not mention return format, error conditions, or whether the file must already exist. This is minimal disclosure for a tool with no annotation support.
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, front-loaded with the verb and resource, containing no redundant information. It is an efficient, well-structured statement.
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 parameter, no output schema), the description covers the basic purpose but lacks details on return values or potential failures. It is minimally adequate but not fully complete for an AI agent to anticipate outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single 'path' parameter as 'Path to .tres TileSet file', so the description adds no additional semantics. With 100% schema coverage, 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 'Read TileSet resource' uses a specific verb and resource type, clearly indicating the tool reads a TileSet. This distinguishes it from sibling tools like read_scene or write_resource, and the resource name is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as read_resource or list_tilesets. The description gives no context for tool selection, leaving the agent without explicit usage criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read translation file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .csv or .po translation file | |
| filter | No | Optional filter text to search for in keys or translations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers minimal behavioral disclosure beyond the word 'read', which implies a non-mutating operation. It does not describe the return format, filtering behavior (despite the filter parameter), error handling, or permissions, leaving the agent without critical operational context.
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 essentially restates the tool name with 'file' appended. While there is no wordiness, it fails to provide necessary information, making it under-specification rather than good 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?
With no output schema and no annotations, the description should compensate by explaining what the tool returns and how it behaves, but it does not. The tool has only 2 parameters, but the description is too sparse to be considered complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes both parameters with 100% coverage: 'path' and 'filter' each have descriptions. The tool description itself adds no parameter semantics, so the baseline 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 verb 'read' and the resource 'translation file', making the basic action understandable. However, it does not distinguish from sibling tools like list_translations or read_resource, and lacks details on what reading entails (e.g., returning key/value pairs).
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?
There is no guidance on when to use this tool, no mention of alternatives, and no exclusions. The description only states the action without any context about suitable scenarios or comparisons to other translation-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List VehicleBody3D nodes with wheel counts.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states the basic listing action, omitting details about what happens when scene_path is omitted, whether it reads from the current scene, or what the return format looks like.
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?
One sentence, directly to the point, with no filler. It is appropriately sized and front-loaded with the core 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 a parameter with zero documentation, no annotations, and no output schema, the description is far from complete. It does not explain the parameter's role, return values, or any edge cases, leaving significant gaps for a tool with this 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?
The schema has 0% description coverage and the description does not mention scene_path at all. The agent is left without any semantic clues about what this parameter does, how it affects the listing, or its 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 clearly states a specific verb ('List') and resource ('VehicleBody3D nodes') with a distinguishing detail ('with wheel counts'). This differentiates it from other read_* tools like read_soft_body or read_character_body.
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 mention of prerequisites, and no explanation of the scene_path parameter context. The description simply states the action without any contextual framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List VideoStreamPlayer nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | No | Filter to scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. The verb 'List' implies a non-destructive read operation, but it does not disclose return format, scope (current scene vs project), or how scene_path filtering affects behavior. This is adequate but minimal.
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 zero redundant wording. It is front-loaded and immediately states the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema, but the description lacks context about what 'List' returns (e.g., paths, names) or whether it operates on the current scene. It is minimally sufficient but leaves room for ambiguity.
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% for the single parameter, so the schema already explains 'Filter to scene'. The description adds no additional parameter meaning, keeping it at the baseline for high 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 uses the specific verb 'List' and the resource 'VideoStreamPlayer nodes', making the purpose clear. It distinguishes from sibling read_* tools by targeting a unique node type.
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. There are many read_* siblings for different node types, but the description does not explicitly mention scenarios or exclusions, leaving usage to be inferred from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Viewport settings.
| Name | Required | Description | Default |
|---|---|---|---|
| node_name | No | Viewport/SubViewport node name | |
| scene_path | Yes | Path to .tscn scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral disclosure burden. It only states 'Read Viewport settings.' which implies read-only but does not describe return format, failure modes, or whether any project state changes. This is insufficient for a tool with no annotations or output 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 a single short sentence with no unnecessary words. It is front-loaded and avoids bloat, earning a high score.
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 an output schema and annotations, the description is too thin. It doesn't explain what 'viewport settings' includes, what the return value looks like, or any prerequisites. This leaves the agent with 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?
Both parameters have descriptions in the schema (100% coverage), so the description adds no additional meaning. The schema already explains scene_path and node_name, and the description doesn't clarify their relationship or usage.
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 'Read Viewport settings.' clearly identifies the action (read) and the target (viewport settings), distinguishing it from sibling read_* tools that target other node types. However, it does not enumerate what specific settings are included, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to prefer read_viewport over similar read_* tools, how to combine scene_path and node_name, or any exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a VisualShader graph.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to VisualShader .tres file (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'read', implying a non-destructive operation, but it does not disclose what is returned, whether any side effects occur, or how the graph is represented. This is a minimal, under-specified 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?
The description is a single, front-loaded sentence with no wasted words. It is concise and to the point, though it could be argued it is too terse, but it does 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 absence of an output schema and the tool's moderately complex context (reading a VisualShader graph), the description is insufficient. It does not explain what the return value looks like, the structure of the graph, or any limitations. The agent would likely need to inspect results to understand the tool's behavior.
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 fully documents the single 'path' parameter with a description, achieving 100% coverage. The description adds no additional meaning beyond the schema, so 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 clearly states the action (read) and the resource (VisualShader graph), which is specific enough to distinguish from siblings like read_shader or create_visual_shader. However, it lacks any elaboration on what reading entails, so it does not fully leverage the opportunity to disambiguate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There are no exclusions, prerequisites, or references to sibling tools, leaving the agent to infer usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove track from animation.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | Yes | Path to .tscn scene file | |
| track_index | Yes | Track index to remove (0-based) | |
| animation_name | Yes | Animation name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only says 'Remove', which implies a destructive operation, but does not clarify whether the change is permanent, requires saving, affects other tracks, or validates the track index. This leaves the agent unaware of important 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 extremely concise and front-loaded, consisting of a single clear sentence with no redundant words. While it is minimal, it does not ramble, and for a simple removal tool this brevity is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description should provide more context about the operation's outcome, error handling, or persistence. It fails to mention what happens on success/failure, whether the file is modified on disk, or how invalid indices are handled, leaving the agent under-informed.
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 description coverage is 100% for all three parameters (scene_path, track_index, animation_name), so the description adds no additional semantic value. The description itself does not explain parameters, but the schema already does, earning the baseline score of 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 'Remove track from animation' clearly states the verb (remove) and resource (track from animation). It is specific enough to distinguish from sibling tools like add_animation_track and list_animations, though it does not explicitly name alternatives.
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, nor any prerequisites or exclusions. The description only restates the core function with no context about when it is appropriate (e.g., which scene or animation must be present).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove audio bus.
| Name | Required | Description | Default |
|---|---|---|---|
| bus_index | Yes | Bus index to remove (0=Master cannot be removed) | |
| layout_path | No | default_bus_layout.tres |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'Remove audio bus.' without disclosing that it modifies the bus layout, that removal may be permanent, or that removing the Master bus is disallowed.
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, easy to parse. However, it is so minimal that it provides no more information than the tool name, offering little structural benefit.
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 mutating operation with no annotations and no output schema, the description lacks necessary context about side effects, error conditions, and parameter relationships. It does not explain what happens if bus_index equals 0 or how layout_path selects the layout to modify.
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?
Description adds no parameter information beyond the schema. With only 50% schema coverage (bus_index documented, layout_path only has a default), the description could clarify layout_path's role and the master bus restriction, but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb+resource ('Remove audio bus.') making the core function clear. It differentiates from sibling tools like add_audio_bus and set_bus_volume, though it doesn't mention caveats like the master bus restriction.
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 like add_audio_bus or set_bus_volume. It lacks context about prerequisites (e.g., existing layout) or whether to use this vs editor_remove_node.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an autoload entry.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the autoload to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Remove an autoload entry' without mentioning potential side effects, persistence, permissions, or return values. For a mutation operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the action and resource. It contains no unnecessary words or repetition, making it appropriately sized for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and 100% schema coverage, the description is minimally adequate. However, the lack of annotations, output schema, and any behavioral context left the description to carry more weight. It does not explain the broader autoload concept or how it differs from similar tools, leaving clear 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?
The input schema has 100% coverage for the single parameter 'name', which is described as 'Name of the autoload to remove'. The tool description adds no additional meaning beyond the schema, so the baseline 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 ('Remove') and the resource ('an autoload entry'), providing a specific verb+resource combination. However, it does not distinguish itself from the sibling tool 'editor_remove_autoload', which likely has a similar purpose in a different context, so it misses the full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'editor_remove_autoload' or 'add_autoload'. The description simply states what it does without any context or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an input action.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Input action name to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
As annotations are absent, the description must disclose behavioral traits, but it only restates the operation. It does not mention side effects, persistence, prerequisites, failure behavior, or the scope of removal (e.g., project settings, runtime input map).
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 that directly states the operation. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is minimal but lacks important context about the input action (e.g., where it is defined, how it relates to other input tools, or whether removal is permanent). The presence of many sibling tools with similar names amplifies the need for 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?
The input schema provides 100% coverage for the single parameter 'action' with a description ('Input action name to remove'), so the description adds no new information. The baseline of 3 is appropriate given the schema's completeness.
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') and the resource ('an input action'), leaving no ambiguity about the tool's purpose. It distinguishes itself from generic tools by naming the specific object type.
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 its siblings such as 'editor_remove_input_action', 'write_input_action', or 'add_input_binding'. The description fails to specify the context (e.g., runtime vs editor) or any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a physics joint node from a scene.
| Name | Required | Description | Default |
|---|---|---|---|
| joint_name | Yes | Joint node name to remove | |
| scene_path | Yes | Path to .tscn scene file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the removal action, but doesn't mention whether the operation is reversible, what happens if the joint doesn't exist, or what side effects occur (e.g., scene file modification). For a destructive operation, this lacks critical context.
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 beginning with the action verb. It contains no redundant words or filler, making it an exemplary concise tool 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?
For a simple two-parameter tool with no output schema, the one-line description is nearly sufficient. However, it could mention that the operation modifies a .tscn file or that the joint name must exist in that scene. Given the simplicity, it's still reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters (joint_name and scene_path) with clear descriptions, so the coverage is 100%. The description does not add any additional semantic information beyond what the schema already provides, so it meets the baseline score of 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 uses a specific verb ('Remove') and resource ('physics joint node') with a clear scope ('from a scene'). It clearly distinguishes itself from sibling tools like create_joint, read_joint, and set_joint_param.
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 when to use the tool (when you need to remove a physics joint), but it provides no explicit context about when not to use it or how it differs from alternatives like remove_node. There is no mention of prerequisites or relationship to other tools.
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 a scene.
| Name | Required | Description | Default |
|---|---|---|---|
| node_path | Yes | Node path to remove (e.g. "Main/Enemy") | |
| scene_path | Yes | Path to .tscn file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention whether removal is permanent, whether it saves the scene file, if children are removed, if the scene must be open, or any undo/recovery options. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It earns its place by stating exactly what the tool does, though it is terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is too thin. It omits side effects (e.g., file saving, cascade deletion), prerequisites, and any confirmation or error behavior, leaving the agent underinformed for correct invocation.
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 both parameters (scene_path and node_path) are already documented in the schema with examples. The description adds no additional parameter semantics, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Remove') and target ('a node from a scene'), which is specific enough to understand the tool's core purpose. However, it does not explicitly differentiate from sibling tools like editor_remove_node or modify_node, so it misses the highest bar for sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as editor_remove_node, modify_node, or rename_node. The description only states the action without any context about prerequisites, scene state, or exclusions.
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 a VisualShader graph by index.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to VisualShader .tres file | |
| node_index | Yes | Node index to remove (0-based, use read_visual_shader to see indices) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full behavioral disclosure. It clearly states the removal action but does not mention whether the change is persisted to the .tres file, error handling for invalid node indices, or any undo/revert behavior. This is a significant omission for a destructive mutation.
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 that immediately communicates the action ('Remove'), the target ('node from a VisualShader graph'), and the selection method ('by index'). It contains no filler, repetition, or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no annotations and no output schema, leaving the description responsible for explaining consequences. It fails to clarify side effects, prerequisites (e.g., knowing the node index), or what the tool returns upon success/failure. The schema covers parameter meaning, but the description does not round out the tool's overall behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions for both required parameters. The 'path' is described as a VisualShader .tres file, and 'node_index' is noted as 0-based with a pointer to read_visual_shader. The tool description adds no extra parameter detail, which is acceptable given the strong 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 uses the specific verb 'Remove' and identifies the exact resource ('node from a VisualShader graph') and method ('by index'), which clearly distinguishes it from sibling tools like add_shader_graph_node, set_shader_node_param, and connect_shader_graph_nodes.
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 main description implies usage in a VisualShader editing workflow but does not explicitly say when to use it instead of remove_node or other similar tools. The schema's node_index parameter does reference read_visual_shader to find indices, providing some practical guidance, but no exclusions or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a node in a scene.
| Name | Required | Description | Default |
|---|---|---|---|
| new_name | Yes | New name for the node | |
| node_path | Yes | Current node path (e.g. "Player" or "Main/Enemy") | |
| scene_path | Yes | Path to .tscn file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic operation and gives no information about side effects, reference updates, error handling, or whether the operation is reversible. 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, perfectly concise sentence that immediately communicates the tool's purpose. There is no wasted wording, and the structure is front-loaded with the key action. It earns 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?
This is a mutation tool with no annotations and no output schema, yet the description offers no additional context. It does not explain how the scene path is resolved, whether the node path is relative to the scene root, or what happens on failure. Critical context for correct usage 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?
The schema already provides complete descriptions for all three parameters (scene_path, node_path, new_name), achieving 100% coverage. The description adds no additional semantic meaning beyond what the schema already offers, so 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 clearly states the action (rename), the resource (node), and the context (in a scene). It is a specific, unambiguous imperative. However, it does not distinguish this tool from the sibling 'editor_rename_node', which likely serves a similar purpose in a different 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?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as whether the scene must be open or how this differs from editor_rename_node. The description provides no contextual clues for selection.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| debug | No | Run with debugger | |
| scene | No | Specific scene to run | |
| headless | No | Run in headless mode (no window) | |
| window_size | No | Window size (e.g. "1280x720", "1920x1080") | |
| project_path | No | Project path (default: current project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to explain whether this launches a windowed game, runs headless, blocks until exit, or requires a project path. The behavior of the tool is virtually undisclosed beyond the action of running.
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 wasted words, but it is severely under-specified. It does not leverage the available space to clarify behavior or usage, making this under-specification rather than effective 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 5 optional parameters, no output schema, and no annotations, a one-sentence description is completely inadequate. It does not explain return values, side effects, or how parameters interact (e.g., whether headless and debug are mutually exclusive). The description fails to cover essential 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 each parameter has a short description (e.g., 'Run with debugger', 'Specific scene to run'). The tool description itself adds no additional parameter semantics, so the baseline 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 states the action clearly ('Run the Godot project') with a specific verb and resource. However, it does not differentiate from sibling tools like editor_play, launch_editor, or editor_run_specific_scene, which also run projects or 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?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, whether the editor must be running, or that stop_project is the matching termination tool. The usage context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call a method on a node in the running game.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Positional arguments. | |
| path | Yes | Node path inside the running scene. | |
| method | Yes | Method name to call on the node. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing side effects. It does not mention that calling an arbitrary method may alter state, crash the game, or have irreversible effects. The generic 'call a method' leaves expectations for return values and error behavior undisclosed.
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 that conveys the essential purpose without fluff. It is front-loaded and every word contributes value.
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 potentially risky nature of dynamically invoking a method on a node, the description is too minimal. It lacks behavioral context such as error handling, return values, or cautions about side effects. The presence of runtime_* siblings amplifies the need to clarify when and how this should be used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for path, method, and args. The description adds no additional parameter semantics or examples, so the baseline of 3 applies. It does not compensate with extra context like argument formats or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Call a method on a node in the running game.' The verb 'call' and resource 'node' are specific, and the scope 'in the running game' distinguishes it from editor-only operations. It differentiates well from sibling tools like runtime_emit_signal or runtime_set_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 is provided about when to use this tool compared to alternatives such as modify_node, runtime_set_node, or runtime_emit_signal. The only hint is 'in the running game,' which implies runtime context but does not explain exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Emit a signal on a node in the running game.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Signal arguments. | |
| path | Yes | Node path inside the running scene. | |
| signal | Yes | Signal name to emit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states the basic action without explaining side effects (e.g., triggering connected handlers), error conditions (e.g., node not found), or whether the game must be actively running. This is insufficient for a runtime mutation.
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 wasted words. It efficiently conveys the core 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?
The description is adequate for a simple tool with well-documented schema parameters, but it lacks important context such as error behavior, argument format details, and the relationship to sibling runtime tools. It does not explain what happens when the signal is emitted or how args are passed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (path, signal, args), so schema coverage is 100%. The tool description adds no extra meaning beyond what the schema already documents. Baseline 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: 'Emit a signal on a node in the running game.' It uses a specific verb ('emit') and resource ('signal on a node'), which distinguishes it from connection-related tools like connect_signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as connect_signal or editor_connect_signal. The only contextual hint is 'in the running game,' but no explicit usage scenarios or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause (freeze) the running game.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden. However, it only restates the name's meaning without disclosing additional behaviors such as reversibility, side effects, or prerequisites. The phrase 'the running game' implies it only works when a game is running, but no further transparency is provided.
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 short sentence with no filler words. It is concise and front-loaded, conveying the essential function immediately.
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 tool (no params, no output schema), the description covers the core action sufficiently. However, it does not explain how it relates to runtime_resume or when the game is not running, but for a zero-param tool this is not a significant gap.
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, which gives a baseline of 4. The description adds no parameter information because none exist, and no compensation 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 uses a specific verb 'Pause' with a clear resource 'the running game', and adds 'freeze' as a synonym. It distinguishes itself from sibling tools like runtime_resume, runtime_step, and stop_project by clearly indicating its scope is pausing the game.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to pause the running game, but it does not explicitly mention alternatives or conditions. For a simple tool with no parameters, the implied usage is moderately clear, but lacks explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read live properties of a node in the running game.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Node path inside the running scene (e.g. "Player" or "World/Enemies/Enemy1"). Use "" / "." for the current scene root. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the read-only nature ('Read') and 'live' (runtime) context, but omits crucial details such as what happens if the node path is invalid, whether the game must be actively running, any error behavior, or the format of the returned properties. This is a significant gap for a runtime 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, clear sentence that front-loads the verb and resource. There is zero wasted verbiage, and it effectively sets expectations for what the tool does.
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 simple tool with one fully described parameter, but the lack of an output schema and annotations leaves uncertainty about the return structure and runtime prerequisites. The description is minimally viable for an agent to attempt invocation, but it does not fully prepare the agent for potential failures or response formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single 'path' parameter, including examples and the special case for scene root. The description adds no additional parameter semantics, so the baseline of 3 is appropriate since the schema carries the load.
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 ('Read') and the specific resource ('live properties of a node in the running game'). It distinguishes itself from other read tools (e.g., read_scene, read_resource) that work on files rather than live runtime state, and from runtime_set_node which writes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in the running game' implies the tool is for runtime inspection, but there is no explicit guidance on when to use this versus other read tools, or when not to use it (e.g., when the game is not running). The usage context is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the running game scene tree (live, inside the played game).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates the operation is a read (implying non-destructive) but does not disclose what is actually returned (e.g., full tree structure, node paths, properties), whether the game must be running, or any potential 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 a single, focused sentence with no wasted words. It conveys the essence of the tool effectively.
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 0-parameter read tool, the description is adequate but minimal. With no output schema and no annotations, it would benefit from mentioning the return format or clarifying the difference from editor-side scene tree tools. It gives the essential action but lacks depth for an agent to fully anticipate the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty (100% coverage). The description correctly adds no parameter details since there are none, and the baseline for 0-param tools 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 a specific action and resource: 'Read the running game scene tree (live, inside the played game).' It distinguishes itself from related tools like read_scene by specifying the live/played context, though it doesn't explicitly name any sibling alternatives.
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 given on when to use this tool versus alternatives such as editor_get_running_scene_tree or read_scene. The description only states what it does, leaving the agent to infer appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inject a key input event into the running game.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | "press" or "release". | press |
| keycode | Yes | Godot keycode (e.g. KEY_W=87, KEY_SPACE=32). See https://docs.godotengine.org/en/stable/classes/class_@globals.html#enum-keymodifierkeycode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states it injects a key event, but does not disclose side effects, prerequisites (beyond the game running), whether the game must be in focus, or failure modes. This is minimal transparency for a mutation-like 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, concise sentence that immediately conveys the tool's purpose with no filler or redundant information. It is well-structured and 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?
For a simple tool with two well-documented parameters and no output schema, the description covers the essential purpose. The missing context (e.g., whether keys need to be released manually, the requirement for focus) is not critical for basic usage, but a bit more detail 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?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no extra meaning beyond the schema, which sets the baseline at 3. It does not explain the significance of action 'press'/'release' or keycode mappings beyond what the schema provides.
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 a specific action ('Inject a key input event') and targets a specific resource ('the running game'), which distinguishes it from similar tools like editor_simulate_key that operate in the editor context. This is a precise and actionable purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the game is running, but it does not explicitly state when to use this tool over alternatives (e.g., editor_simulate_key) or provide any exclusions. The 'running game' context provides an implied use case, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if the live-game runtime bridge is reachable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it adequately discloses a non-mutating read-only operation via the verb 'check'. It does not detail response format or error behavior, but for a zero-parameter reachability check, this level of transparency is sufficient.
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 of eight words, front-loading the action and object without any filler. It is an exemplary use of 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?
Given the tool's minimal complexity (no parameters, no nested objects, no output schema), the one-sentence description fully conveys the tool's purpose and usage. It explains enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so the description correctly adds no parameter details. Per the baseline for zero-parameter tools, this earns a 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 tool's function with a specific verb 'Check' and resource 'live-game runtime bridge', distinguishing it from sibling runtime_* tools that perform actions (e.g., runtime_screenshot, runtime_call_method). It precisely conveys that this is a connectivity health-check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need to verify that the live-game runtime bridge is reachable, likely as a precondition for other runtime operations. It does not explicitly mention alternatives or exclusions, but the purpose is self-evident for a ping tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume (unpause) the running game.
| 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 carry full burden. While it states the action, it doesn't disclose preconditions (e.g., game must be paused) or side effects (e.g., no-op if already running), which is a gap for a runtime control 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 concise sentence, front-loaded with the core action. It contains zero wasted words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no output schema, params, or annotations, so the description is the only source of info. It conveys the core purpose but lacks contextual details about prerequisites or how it differs from similar runtime controls.
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, so the baseline score of 4 applies. The description doesn't need to explain parameter semantics since the schema is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Resume' and clearly identifies the resource 'running game', distinguishing it from siblings like runtime_freeze and editor_unpause. It's precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'Resume the running game', but it doesn't explicitly mention when to use this tool versus alternatives like editor_unpause or runtime_freeze. There is no exclusion or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a screenshot of the running game viewport.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Output path (default user://runtime_screenshot.png). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention preconditions (e.g., game must be running), output behavior, error cases, or file overwrite semantics. The description is too minimal to provide meaningful transparency beyond the basic action.
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 that states the action and target in 10 words. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the essential context: it captures a screenshot from the running game viewport. It could note the default output path, but that is already in the schema. Given the tool's simplicity, the description is nearly complete, though a note about requiring a running game would make it fully robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the 'path' parameter already documented as 'Output path (default user://runtime_screenshot.png)'. The description adds no additional parameter semantics, so the 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 uses a specific verb ('Capture') and resource ('screenshot of the running game viewport'), clearly distinguishing it from sibling tools like editor_take_screenshot. It directly states what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'running game viewport' clearly implies this is for runtime use only, providing context for when to use it versus editor-focused tools. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set properties on a node in the running game (live mutation).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Node path inside the running scene. | |
| properties | Yes | Property values to set, as strings (e.g. {"position":"Vector2(10,20)", "visible":"false"}). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions 'live mutation', which implies running-game changes, but lacks critical traits such as whether changes are temporary, what happens if the node path is invalid, or any safety/destructive implications. 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, front-loaded sentence that communicates the essential purpose without any fluff or redundancy. Every word earns 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?
While the tool is simple with only two parameters and the schema covers them well, the description lacks guidance on when to use it versus related tools, and fails to disclose important runtime side effects. The absence of an output schema and annotations raises the need for more behavioral context, making this only minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete coverage of both parameters with descriptions, including a concrete example for properties. The tool description adds no additional parameter-level detail, so it does not exceed the schema's contribution. Baseline of 3 is appropriate 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?
Description clearly states the verb ('Set'), the resource ('properties on a node'), and the context ('in the running game (live mutation)'). This distinguishes it from sibling tools like 'editor_set_node_properties' which targets the editor scene, and 'modify_node' which is more generic. The 'live mutation' phrase is a specific scoping detail.
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 clearly conveys the intended context: use when the game is running and you need to mutate a node's properties live. However, it does not explicitly mention when not to use it or name alternatives like editor_set_node_properties or modify_node, leaving some ambiguity for agents choosing among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advance the running game by N frames deterministically while paused (frame stepping).
| Name | Required | Description | Default |
|---|---|---|---|
| frames | No | Number of frames to advance while paused (deterministic stepping). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation is deterministic and requires a paused state, but it does not state prerequisites (e.g., game must be running and paused), failure modes, or side effects (e.g., execution of scripts during the step). This leaves important behavioral ambiguity.
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, well-structured sentence that front-loads the verb and target, and the parenthetical adds the helpful synonym 'frame stepping' without unnecessary detail.
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 single-parameter tool with no output schema, the description covers the core action and condition, but it omits critical context about when the game must be paused, what happens if it isn't, and any side effects. The lack of annotations and usage guidance leaves the description only minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a clear description for the 'frames' parameter, and the tool description only repeats 'N frames'. With 100% schema_description_coverage, the description adds no additional meaning beyond the schema, so the baseline 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 ('Advance the running game by N frames'), the resource ('running game'), and the condition ('while paused'), with the parenthetical 'frame stepping' distinguishing it from runtime_resume and runtime_freeze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'while paused' gives clear context for when this tool operates, but it does not explicitly state when to prefer it over alternatives like runtime_resume or runtime_freeze, nor does it mention any exclusions or prerequisites. Usage is implied rather than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze inter-scene dependencies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Analyze,' which implies a read-only operation but does not state side effects, output format, performance implications, or whether it requires a currently open scene.
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 this is under-specification rather than effective conciseness. A single vague sentence is insufficient for an analysis tool that presumably produces a graph or report.
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 appears to be a complex analysis feature and there is no output schema or annotations, the description provides almost no context. It fails to explain what 'inter-scene dependencies' means, what the result looks like, or how the agent should interpret it, making the tool essentially unusable without external knowledge.
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 there is no parameter information to add beyond the empty schema. The baseline for zero parameters is 4, and the description does not need to explain anything further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Analyze inter-scene dependencies' uses a verb and resource but remains vague, essentially restating the tool name without specifying what the analysis entails or what output is produced. It does not distinguish this tool from related scene-analysis tools like editor_get_dependencies or generate_cohesion_report.
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 given about when to use this tool versus alternatives. It does not mention any prerequisites, use cases, or why one would choose this over sibling tools such as generate_cohesion_report or read_scene.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for text across project files.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term (case-insensitive) | |
| pattern | No | File pattern filter (e.g. "*.gd") | |
| max_results | No | Max results (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action 'search' without revealing any behavioral traits like return format, performance, or side effects, nor confirming it is read-only.
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 redundancy or filler. It is front-loaded with the essential verb and resource, making it easy to parse, though it could include a bit more context without becoming wasteful.
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 schema robustly documents parameters, but there is no output schema or annotations. The description does not clarify the scope of 'project files' or the nature of results, and sibling tools like search_in_scripts and search_scene_content introduce ambiguity about what 'project files' excludes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of all three parameters with descriptive comments (e.g., 'case-insensitive', 'File pattern filter', 'Max results'). The description adds no parameter-level detail beyond what the schema already documents, so the 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 uses the specific verb 'search' and clearly identifies the resource as 'project files', making the core purpose clear. It implicitly differentiates from sibling tools like search_in_scripts and search_scene_content by implying a broader scope, though it doesn't explicitly name them or contrast them.
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?
There is no guidance on when to use this tool versus alternatives such as search_in_scripts or search_scene_content. The description only states what the tool does, not when it should be preferred or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search in scripts with function context.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Script type filter | all |
| query | Yes | Search term (function name, variable, keyword) | |
| max_results | No | Max results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full behavioral disclosure burden. It only mentions 'function context,' but does not explain search scope, case sensitivity, output format, or that it is a read-only operation, leaving the agent with insufficient insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. However, it sacrifices depth for brevity, making it slightly less complete than ideal while still being 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 search tool with no output schema and no annotations, the description is too sparse. It fails to clarify how results are presented, what 'scripts' encompasses, or how it differs from several similar sibling tools, leaving 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?
All three parameters have descriptions in the schema (100% coverage), and the description adds no additional parameter detail. The baseline score of 3 applies because the schema handles parameter semantics adequately.
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 searches in scripts and highlights the distinctive 'function context' feature. It implies differentiation from broader search tools like search_in_project, but does not explicitly name alternatives.
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 the many sibling search tools (search_in_project, search_scene_content). It lacks any exclusions or contextual examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search in .tscn content.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term (case-insensitive) | |
| max_results | No | Max results (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does not disclose the exact scope (e.g., all .tscn files in the project), the return format, or whether it is read-only. The phrase 'full-text search' is generic and does not provide details about case sensitivity or result structure.
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 wasted words. However, its brevity contributes to under-specification; it is concise but lacks essential detail.
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 no output schema and no annotations, the description does not explain what results are returned or how the search behaves. For a tool with two parameters and a search operation, this is insufficient to fully understand its behavior.
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 fully documented in the schema (coverage 100%), providing descriptions for query and max_results. The tool description adds no additional parameter context, so the schema 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 clearly states the tool performs full-text search specifically in .tscn content, using a specific verb ('search') and a resource (scene file content). This distinguishes it from sibling tools like search_in_scripts or search_in_project, which target different scopes.
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 instead of alternatives such as search_in_project or search_in_scripts. The description simply states what the tool does, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search all tools by keyword/description to discover the right tool name. Use this instead of guessing among 350+ tools.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 25). | |
| keyword | Yes | Keyword(s) to search tool names + descriptions. Space-separated words are AND-combined (e.g. "collision shape", "tilemap source"). | |
| write_only | No | If true, only return write/side-effect tools. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It states the tool searches all tools by keyword/description, which is accurate and non-contradictory. However, it does not disclose details like output format or filtering behavior (e.g., AND-combined keywords or write_only). The description is honest but minimal, earning a middle score.
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 two sentences, front-loaded with purpose and ending with actionable guidance. No wasted words; every sentence earns its place. This is an example of highly effective concise writing.
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 search tool, the description is sufficiently complete. It explains the core purpose, references the scope (all tools), and indicates the output intent (discover the right tool name). While no output schema exists, the description implies the return value (tool names) and the schema covers parameters. Slight gap is the absence of explicit output details, but the tool's simplicity mitigates this.
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 all parameters are fully documented in the schema. The description adds no additional parameter semantics beyond what the schema already provides. According to the rubric, this is 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 clearly states the tool's function: 'Search all tools by keyword/description to discover the right tool name.' This explicitly names the verb (search), the resource (all tools), and the purpose (discover the right tool name). It also distinguishes itself from the hundreds of sibling tools by positioning as a discovery mechanism.
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?
Provides explicit guidance on when to use: 'Use this instead of guessing among 350+ tools.' This clearly indicates the tool is for finding the correct tool name when uncertain. It does not list alternative tools or exclusions, but the guidance is specific and useful for a search/meta tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set animation parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Parameter name (e.g. "length", "loop_mode", "step") | |
| value | Yes | New value for the parameter | |
| scene_path | Yes | Path to .tscn scene file | |
| animation_name | Yes | Name of the animation (as appears in AnimationPlayer) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention whether the operation mutates the scene file, requires a loaded scene, or has side effects. For a 'set' (mutating) operation, this is a critical omission.
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, but it is under-specified rather than concise. It provides zero value beyond the tool name, making the sentence waste. A useful description would include key behavioral or usage 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?
With four required parameters, no annotations, and no output schema, the description is completely inadequate. It does not explain what constitutes an animation parameter, valid values, or how the tool interacts with scene files. A minimal viable description would need much more 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%, so the schema already documents all four parameters with descriptions and examples. The description adds no additional parameter semantics, leaving the baseline of 3 given good 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 'Set animation parameter' is a direct restatement of the tool name 'set_animation_param'. It does not add specificity (e.g., which scene/animation) nor does it distinguish from sibling tools like set_animation_tree_param.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, context (e.g., editing .tscn files), or exclusions. The description simply states the action without situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set AnimationTree parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Parameter to set (e.g. "active", "tree_root/parameters/conditions/active") | |
| value | Yes | New value | |
| tree_name | No | AnimationTree node name (default: first found) | |
| scene_path | Yes | Path to .tscn scene file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, persistence, or required context, but it only says 'Set AnimationTree parameter.' It implies mutation but does not state whether changes are saved to the scene file, require an open scene, or affect runtime, leaving the agent without critical behavioral information.
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 one short sentence with no filler or redundant information. It is immediately readable and the subject/action are 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?
For a mutation tool with no annotations or output schema, a single generic sentence is insufficient to fully orient the agent. It omits usage alternatives, persistence semantics, and error behavior, despite the schema providing parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all four parameters with 100% documentation, including examples for param and default behavior for tree_name. The description adds no parameter-specific meaning beyond the schema, which is acceptable given the high 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 states the action ('Set') and resource ('AnimationTree parameter') clearly, and the resource name distinguishes it from sibling set_animation_param and other editor_set_* tools. It lacks additional scope details, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool vs alternatives such as set_animation_param or runtime methods. The description only states the action and does not give exclusions, 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.
Set bus volume in dB.
| Name | Required | Description | Default |
|---|---|---|---|
| bus_index | Yes | Bus index | |
| volume_db | Yes | Volume in dB (e.g. -6.0, 0.0, 3.0) | |
| layout_path | No | default_bus_layout.tres |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states the mutation ('Set bus volume') without disclosing side effects like persistence to the layout file, behavior for invalid bus indices, or whether the change affects the current session or saved resource.
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 that is easy to parse. It is efficient but arguably too minimal, omitting context about layout_path and potential side effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no annotations, no output schema, and minimal description, important context is missing. The optional layout_path parameter is unexplained, and there is no mention of errors or persistence, leaving the agent with insufficient information for safe invocation.
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 bus_index and volume_db with basic descriptions, but layout_path has no description in the schema. The tool description adds no parameter details beyond what the schema already provides, missing the opportunity to explain layout_path's role and default.
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 'Set bus volume in dB' uses a clear verb and resource, explicitly stating the operation on bus volume. It distinguishes itself from sibling tools like add_audio_bus and read_audio_bus_layout by targeting the volume-setting action specifically.
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, nor any preconditions such as verifying the bus exists or the layout file is loaded. The description is a single statement with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set collision shape for CollisionShape node.
| Name | Required | Description | Default |
|---|---|---|---|
| node_path | Yes | Parent node path (e.g. "Player" — the CollisionShape3D must already exist as child) | |
| scene_path | Yes | Path to .tscn file | |
| shape_type | Yes | Collision shape type | |
| shape_resource_path | No | Path to .tres resource file for the shape (e.g. "res://shapes/player_capsule.tres"). Creates one if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states the operation without mentioning side effects, prerequisites (e.g., node must exist), whether a shape resource is created automatically, or any implications for the node's collision behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded and efficient, though it borders on under-specification due to lack of detail.
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 no annotations, no output schema, and a very terse description, the tool lacks essential context. It doesn't explain when to use it, prerequisites, behavior details, or how it integrates with related tools, making it incomplete for an agent to select and invoke 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 description coverage is 100%, with each parameter clearly explained. The description adds no additional param meaning beyond the schema, so 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 'Set collision shape for CollisionShape node' uses a specific verb and resource, clearly indicating it modifies the collision shape of a CollisionShape node. However, it doesn't explicitly distinguish this from siblings like set_shape_points or create_collision_polygon, so it's clear but not fully 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 is provided on when to use this tool versus alternatives. With many sibling tools like set_shape_points or create_collision_polygon, the description gives no context or exclusions, 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.
Set environment parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .tres Environment file | |
| param | Yes | Parameter to set (e.g. "background_color", "fog_enabled", "ssao_enabled") | |
| value | Yes | New value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it provides no behavioral detail. It doesn't disclose that this modifies a .tres file, whether the file must exist, whether changes are persisted, or any side effects or return behavior. It is a tautology.
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 short sentence with no wasted words or redundant information. However, it is so terse that it lacks useful content, so it doesn't fully earn the top score for structure.
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 three required parameters, no output schema, and no annotations. The description offers no context about file existence, persistence, value types, return values, or where this tool fits in a workflow (e.g., with read_environment or create_environment). It is minimally complete for the simplest invocation 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%: 'path' is described as a .tres Environment file, 'param' gives examples like background_color, and 'value' is noted as a new value. The description adds no meaning beyond what the schema already provides, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set environment parameter' essentially restates the tool name (set_environment_param) with no added detail. It doesn't clarify that it refers to a Godot Environment resource (.tres) or distinguish it from sibling set_*_param tools beyond the tool name itself.
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?
There is no guidance on when to use this tool, what prerequisites exist, or which alternatives (e.g., read_environment, create_environment) are more appropriate. The description simply 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.
Set joint parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Parameter name (e.g. "bias", "angular_limit/lower", "motor/enable") | |
| value | Yes | New value | |
| joint_name | Yes | Joint node name | |
| scene_path | Yes | Path to .tscn scene file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'Set joint parameter' but does not mention side effects like modifying the .tscn file, whether it requires an open scene, or how it handles invalid parameters. Significant behavioral details are missing.
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 zero wasted words. However, it is almost too terse; while it is front-loaded and clear, it might have included a bit more contextual information without sacrificing 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 the tool modifies a scene file's joint parameters, the description is incomplete. It does not mention the effect on the scene, expected behavior, or any related concepts. For a 4-parameter tool with no output schema and no annotations, the description 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 coverage is 100%, so the schema already documents all four parameters with brief descriptions. The tool description adds no extra parameter semantics beyond what the schema provides, earning the baseline score of 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 'Set joint parameter' clearly states the action and resource, distinguishing it from siblings like set_animation_param or set_light_param. However, it lacks detail about what 'joint parameter' encompasses, so it's not exceptionally 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 guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or when not to use it. The description provides no strategic context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set keyframe on track.
| Name | Required | Description | Default |
|---|---|---|---|
| time | Yes | Time in seconds | |
| value | Yes | Value at keyframe (e.g. "Vector2(100, 0)", "1.5") | |
| easing | No | Easing weight (0=custom, 1=auto, >1=ease in, <-1=ease out) | |
| scene_path | Yes | Path to .tscn scene file | |
| track_index | Yes | Track index (0-based) | |
| animation_name | Yes | Animation name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention side effects (e.g., modifying the scene file), prerequisites (e.g., track must exist), or whether existing keyframes are overwritten. This is a significant gap 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, front-loaded sentence with zero waste: 'Set keyframe on track.' It fully captures the core action without unnecessary words, earning a perfect score for 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 the tool's complexity (6 parameters, mutating operation, no output schema) and no annotations, the description is highly inadequate. It omits crucial context such as the need for an existing animation and track, the effect on the scene, and any return value. The schema covers parameters but not the overall behavioral 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%, so the input schema fully documents all parameters including time, value, easing, scene_path, track_index, and animation_name. The description adds no extra parameter meaning, but the baseline of 3 applies since the schema handles the semantics.
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 'Set keyframe on track' uses a specific verb and resource, clearly indicating the operation of setting a keyframe on a track. However, it doesn't differentiate from sibling tools like set_animation_param or add_animation_track, so it lacks explicit sibling distinction.
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, such as adding a track first or using set_animation_param. It implies usage through its wording but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a parameter on a 2D light node.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | ||
| value | Yes | ||
| light_name | Yes | ||
| scene_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only says 'set a parameter' and omits side effects, required scene context, valid parameter values, or error behavior, which 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, front-loaded sentence that immediately conveys the core function without wasted words. It is appropriately concise for a simple setter, even though this brevity sacrifices depth (penalized in other dimensions).
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 four unannotated string parameters, no enums, and no output schema, the description is not complete enough for correct invocation. It omits parameter semantics, valid values, and any behavioral context, making it insufficient for a non-trivial 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?
Schema description coverage is 0%, and the description adds no meaning to the four generic string parameters. It does not explain what 'param' values are accepted, how 'value' should be formatted, or how to reference the light node, leaving the agent without necessary guidance.
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 ('Set') and the target resource ('2D light node'), with 'parameter' as the object. It also distinguishes itself from the sibling tool set_light_param by specifying '2D,' which helps the agent select the correct tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage on a 2D light node but provides no explicit guidance on when to choose this tool over alternatives like set_light_param or read_light_2d. No exclusions or alternative recommendations are given, leaving the decision to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set light parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| param | Yes | Light parameter (e.g. "energy", "color", "shadow_enabled") | |
| value | Yes | New value | |
| light_name | Yes | Name of the light node | |
| scene_path | Yes | Path to .tscn scene file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It only says 'Set light parameter,' which implies a mutation but does not explain what happens to the scene file, whether changes are applied to the editor or disk, if values are validated, or any side effects. 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 concise sentence with no wasted words. However, it is overly terse and could benefit from including a bit more context while remaining concise. Good structure, but extreme brevity slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with 4 required parameters and no output schema or annotations. The description is minimal, lacking critical context like whether the modification affects the scene file directly, if a reload is needed, or how the value format is interpreted. Given the tool's complexity, this is 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% with each parameter having a description, including examples for 'param'. The tool description itself adds no extra parameter meaning, so it relies on the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set light parameter' uses a specific verb and resource, but 'light' is ambiguous. It does not specify whether this is for a 3D Light3D node or a 2D Light2D node, and there is a sibling tool set_light_2d_param that implies this tool targets 3D lights. The purpose is clear in general but lacks explicit differentiation from related 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?
No guidance is provided on when to use this tool versus alternatives like set_light_2d_param or set_shader_node_param. There is no mention of prerequisites, such as whether the scene must be open or the light must exist. The description gives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a single material parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .tres material file | |
| param | Yes | Parameter name (e.g. "metallic", "roughness", "albedo_color") | |
| value | Yes | Parameter value (e.g. "0.5", "Color(1,0,0,1)") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the action without disclosing that it modifies the .tres file on disk, whether changes are persistent, or what error behavior occurs. It adds no context beyond the tool's 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?
A single short sentence that is front-loaded and completely free of redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers parameter meanings well, but the description omits behavioral context such as persistence and prerequisites. For a simple setter, this is minimally adequate but not rich.
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 three parameters are fully described in the schema with examples (path, param, value). The description adds no additional semantic detail, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and identifies the resource ('material parameter') and scope ('single'), which clearly distinguishes it from sibling param setters for other resource types (e.g., set_environment_param, set_shader_node_param).
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, nor does it mention prerequisites like the material file needing to exist. The agent must infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set surface material on MeshInstance.
| Name | Required | Description | Default |
|---|---|---|---|
| node_name | Yes | MeshInstance node name | |
| scene_path | Yes | Path to .tscn scene | |
| material_path | Yes | Path to material .tres file | |
| surface_index | No | Surface index |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core action without revealing side effects: does it modify the .tscn file permanently, overwrite existing materials, or require the scene to be loaded? This is insufficient for a mutating 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 unnecessary words, front-loading the verb 'Set' and specifying the target. It is perfectly concise for the information it conveys, though this brevity contributes to incompleteness in other dimensions.
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 four parameters, no output schema, and no annotations, yet the description provides only a basic statement. It lacks essential context about the operation's effect on the scene file, whether it can be undone, or what the expected outcome is. Sibling tools like read_mesh_instance exist but are not cross-referenced.
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 four parameters have descriptions in the schema (100% coverage), so the baseline is 3. The tool description adds no additional meaning about parameter interactions, constraints, or relationships beyond what the schema already provides. It neither improves nor degrades 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 specifies the action: setting a surface material on a MeshInstance. It distinguishes itself from sibling tools like set_material_param by naming the exact target resource and object type. The one-sentence description is unambiguous and leaves no doubt about what the tool does.
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 set_material_param or write_resource, nor does it mention prerequisites like having the scene open. There are no exclusions or context about typical workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set node position (2D/3D auto-detect).
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Position: "x,y" for 2D, "x,y,z" for 3D, or "Vector2/3(...)" | |
| node_path | Yes | Node path | |
| scene_path | Yes | Path to .tscn file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure responsibility. It only states the core action and auto-detect behavior, but does not reveal side effects like whether the scene is saved, whether the scene must be open, or error behavior. This is a significant gap 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 one sentence, front-loaded with the action, and has zero waste. It efficiently conveys the primary purpose and a helpful behavioral note in minimal space.
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 setter with no annotations, the description is too thin to cover essential context such as whether it operates on the open scene, if changes are saved, or any permissions required. The schema covers parameters, but the overall tool context remains 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 description coverage is 100%, so the baseline is 3. The description adds no additional parameter detail beyond the schema. The auto-detect hint relates to the value parameter but does not enrich the schema's own format explanations.
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 'Set node position' uses a specific verb and resource, clearly identifying the tool's action. It distinguishes from siblings like set_node_rotation and set_node_scale by naming the exact property. The added '2D/3D auto-detect' further clarifies the 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?
The description provides no guidance on when to use this tool versus alternatives such as transform_node or set_node_rotation. It does not mention exclusions or prerequisites. The only hint is 'auto-detect' regarding input formats, which is not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set node rotation (2D/3D).
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Rotation: float for 2D (e.g. "1.57"), "x,y,z" or "Vector3" for 3D | |
| node_path | Yes | Node path | |
| scene_path | Yes | Path to .tscn file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It mentions '2D/3D' but does not explain units (radians vs degrees), whether rotation replaces existing values, or what happens if the node doesn't exist. This is a minimal disclosure without side-effect or error information.
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, focused sentence with no superfluous words. It is front-loaded and easily parsed, though it omits details that would make it richer.
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 low-complexity setter, the description plus schema is mostly sufficient. However, with no annotations and no output schema, the lack of unit specification or behavioral notes makes it slightly incomplete, though not severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all three parameters, including the format for 'value' (float for 2D, x,y,z/Vector3 for 3D). The description adds nothing beyond this, but the schema already achieves high coverage, so a 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 uses a specific verb and resource ('Set node rotation'), and the '(2D/3D)' qualifier adds distinction from sibling setter tools like set_node_position and set_node_scale. This clearly identifies the tool's 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 guidance is provided on when to use this tool versus alternatives such as transform_node or set_node_position. It only states what it does without any context on selection criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set node scale (2D/3D).
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Scale: "x,y" for 2D, "x,y,z" for 3D, or "Vector2/3(...)" | |
| node_path | Yes | Node path | |
| scene_path | Yes | Path to .tscn file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It does not state that this modifies the scene file, whether the scale is absolute (overwriting the existing scale), or any side effects. This is a significant gap 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 that is front-loaded and free of any waste. Every word earns its place, making it appropriately 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 tool with no annotations and no output schema, the description fails to provide sufficient context. It does not clarify that the operation modifies a scene file, the relationship between node_path and scene_path, or any implications of setting scale. This leaves the agent under-informed for tool selection and invocation.
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's mention of '2D/3D' adds minimal value over the schema's value description, which already specifies the coordinate formats. No additional parameter semantics are provided beyond what the schema documents.
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 'Set' and the resource 'node scale', and explicitly notes it handles both 2D and 3D. This distinguishes it from sibling tools like set_node_position and set_node_rotation, which target different node properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as transform_node or modify_node. The description only states what it does, without any context about appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a parameter on a VisualShader node (constant, expression, operator, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to VisualShader .tres | |
| param | Yes | Parameter name (e.g. "constant", "expression", "operator") | |
| value | Yes | New value | |
| node_index | Yes | Node index |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, yet it only states the mutation intent ('Set a parameter'). It omits side effects such as writing to the .tres file, preconditions like valid node index or existing node, and error behavior for invalid param/value combinations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or repetition of schema content, and the action verb appears first. However, the trailing 'etc.' is slightly vague, and one sentence feels lean for a mutating tool with four parameters, though nothing is wasted.
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 mutating tool with 4 required parameters, no output schema, and no annotations, the description plus terse schema descriptions is insufficient. The agent lacks guidance on locating node_index (e.g., via read_visual_shader), valid value types per param, and failure outcomes, making confident invocation unlikely.
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 adds slight value by echoing param examples (constant, expression, operator) and linking them to node types, but it does not clarify the 'value' parameter's expected format or how 'node_index' is resolved, leaving schema entries like 'New value' and 'Node index' unenriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Set a parameter on a VisualShader node') and narrows scope with the parenthetical '(constant, expression, operator, etc.)'. It clearly distinguishes itself from structural siblings like add_shader_graph_node, remove_shader_graph_node, and connect_shader_graph_nodes, as well as other set_*_param tools by naming VisualShader as the target.
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?
There is no explicit when/when-not guidance, no mention of prerequisites, and no reference to alternatives. The agent is not told to inspect existing nodes via read_visual_shader, create nodes first via add_shader_graph_node, or consult get_shader_node_defaults for valid values. Usage must be entirely inferred from the tool name and the minimal examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set shape on CollisionShape2D.
| Name | Required | Description | Default |
|---|---|---|---|
| points | No | Points for polygon shapes | |
| radius | No | Radius for circle/capsule shapes | |
| extents | No | [width, height] for rectangle shapes | |
| node_path | Yes | Node path to CollisionShape2D or CollisionPolygon2D | |
| scene_path | Yes | Path to .tscn scene file | |
| shape_type | No | Shape type (for CollisionShape2D) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for disclosing side effects, but it only says 'Set shape'. It does not state that this modifies the scene file, replaces existing shapes, or requires specific permissions. This is a serious gap 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, which is concise, but it is under-specified rather than appropriately concise. It omits critical operational details and does not earn its place because it adds little to the tool name.
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 description is completely inadequate for a tool with 6 parameters, no annotations, and no output schema. It fails to explain the interplay between shape_type and the geometric parameters, leaving the agent without enough context to invoke the tool 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 description coverage is 100%, so the baseline is 3. The tool description adds no parameter-specific meaning beyond what the schema already provides. It does not explain how shape_type relates to points, radius, or extents, but the schema does describe each parameter individually.
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 'Set shape on CollisionShape2D' is a vague restatement of the tool name. It does not mention 'points' or the shape types (rectangle, circle, etc.) and fails to distinguish this tool from siblings like set_collision_shape. The verb+resource is present but lacks specificity about what 'shape' means in this 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 such as set_collision_shape or create_collision_polygon. There is no mention of prerequisites, supported node types, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a bone pose (position/rotation/scale) in a skeleton.
| Name | Required | Description | Default |
|---|---|---|---|
| bone | Yes | Name of the bone to pose | |
| scale | No | Local scale as [x, y, z] | |
| position | No | Local position as [x, y, z] | |
| rotation | No | Local rotation as quaternion [x, y, z, w] | |
| skeleton | No | Skeleton node name (first found if omitted) | |
| scene_path | Yes | Path to .tscn scene containing a Skeleton3D/2D node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It mentions the components (position/rotation/scale) but does not explain side effects, error handling, or the local-space context. The tool mutates a skeleton pose, yet no information about reversibility or persistence is 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 a single sentence, front-loaded with the action and resource. It contains no filler or redundant wording, earning a high score for 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?
The tool has 6 parameters and no output schema or annotations, yet the description provides minimal context. It doesn't mention how the skeleton is selected (first found if omitted) or what happens if the bone is missing, leaving important edge-case behaviors undocumented.
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 only repeats the parameter names without adding new meaning beyond the schema's detailed descriptions (e.g., 'Local position as [x, y, z]').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Set'), a clear resource ('bone pose'), and scope ('in a skeleton'). It also enumerates the components (position/rotation/scale), distinguishing it from sibling node transform 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?
No explicit guidance is provided about when to use this tool versus alternatives like set_node_position or set_animation_param. The usage is only implied by the description, with no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach a StyleBoxFlat to a Theme type/state.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Control type (e.g. "Button") | |
| state | No | Style state (normal, hover, pressed, focus, disabled) | normal |
| bg_color | No | Background color (e.g. "Color(0.2, 0.2, 0.2, 1)") | |
| theme_path | Yes | Path to .tres Theme file | |
| border_color | No | Border color | |
| border_width | No | Border widths [left, right, top, bottom] | |
| corner_radius | No | Corner radii [top_left, top_right, bottom_right, bottom_left] | |
| content_margin | No | Content margins [left, right, top, bottom] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a mutation (attaching a stylebox) but does not disclose side effects such as overwriting existing styleboxes, whether a new resource is created, or whether the theme file is modified on disk. It also does not mention any required permissions or reversibility, similar to the update_drive example.
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 redundant words. It directly states the main action and target, achieving maximum information density for its length. This is exemplary 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?
The description is severely incomplete for a tool with 8 parameters, 2 required, and no annotations or output schema. It does not describe what the tool returns, side effects, or any contextual prerequisites. The agent receives no guidance beyond the schema, which is insufficient for reliable invocation.
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% for all 8 parameters, so the baseline is 3. The description adds no additional semantic meaning beyond the schema. It does not clarify how parameters like bg_color, border_width, or corner_radius map to the StyleBoxFlat properties, but the schema already provides sufficient descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach a StyleBoxFlat') and the target resource ('a Theme type/state'). This is specific enough to distinguish from sibling tools like read_theme or read_stylebox, which are read operations. The verb is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention when it is appropriate, any prerequisites (e.g., theme file must exist), or refer to related tools like read_stylebox or add_theme_type. The agent is left to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set import flags (compress, mipmaps, etc.) in a .import config.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Image asset path (e.g. "sprites/hero.png"); modifies its .import config | |
| flags | Yes | Import params to set, e.g. {"compress/mode": "2", "process/size_limit": "512"} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says it sets flags in a .import config, but omits whether flags are merged or overwritten, whether the asset must exist, or any side effects. This is minimal disclosure for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and front-loaded, stating the action and target without any filler. It is appropriately concise for a simple setter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema), but with zero annotations the description should explain more about operational behavior (e.g., in-place modification, validation, error handling). It provides only the bare minimum, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both 'path' and 'flags' with an example, so schema coverage is high. The description adds 'compress, mipmaps' as illustrative flag names, but this is marginal since the schema example already conveys the concept.
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 ('Set import flags') and the target resource ('.import config'), with examples of flags (compress, mipmaps). This distinguishes it from generic editing tools, though it doesn't explicitly contrast with the sibling write_import_config.
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 given on when to use this tool versus alternatives like read_import_config or write_import_config. There are no exclusions, prerequisites, or context about typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simplify a polygon via Douglas-Peucker and write it back.
| Name | Required | Description | Default |
|---|---|---|---|
| points | Yes | Array of [x, y] points to simplify | |
| tolerance | No | Douglas-Peucker tolerance (higher = more aggressive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool modifies a polygon ('write it back') but does not specify what resource is changed, whether the operation is destructive, or whether it requires a selected polygon node. This lack of side-effect detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extra words, front-loading the core action. It is appropriately sized and never wastes the reader's attention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is not self-contained: it takes only 'points' as input but claims to 'write it back', implying an existing polygon resource, yet no identifier or selection mechanism is documented. With no output schema and no additional context, the agent cannot reliably infer how to apply this tool 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% and both parameters have clear descriptions in the schema (points as [x,y] array, tolerance with default and aggressiveness hint). The tool description adds no parameter-level detail beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (simplify), the resource (polygon), and the method (Douglas-Peucker). It also mentions the side effect (write it back), which distinguishes it from any sibling tool like set_shape_points or read_collision_polygon.
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. There is no mention of editor selection or how the target polygon is identified, leaving the agent without clear invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop all running Godot processes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool stops all Godot processes, which implies a destructive action. However, it does not mention potential consequences like unsaved data loss or whether this also terminates the editor, leaving some behavioral ambiguity.
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 that immediately states the action and scope. No filler or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, straightforward stop command, the description adequately covers the tool's purpose. It could benefit from noting the effect on the editor, but the description is otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain parameters. Baseline 4 applies since there are no params to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('stop') and resource ('all running Godot processes'), making the tool's purpose clear. However, it does not explicitly differentiate from sibling tools like editor_stop, which could overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as editor_stop or run_project. The description only states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a combined transform (position, rotation, scale) to a node in a scene.
| Name | Required | Description | Default |
|---|---|---|---|
| scale | No | 2D: "Vector2(2,2)" or "2,2" | 3D: "Vector3(1,1,1)" or "1,1,1" | |
| position | No | 2D: "Vector2(100,200)" or shorthand "100,200" | 3D: "Vector3(0,5,0)" or shorthand "0,5,0" | |
| rotation | No | 2D: float radians e.g. "1.57" | 3D: "Vector3(0,1.57,0)" or shorthand "0,1.57,0" | |
| node_path | Yes | Node path (e.g. "Player" or "Main/Player") | |
| scene_path | Yes | Path to .tscn file (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the basic action without saying whether the transform is absolute or relative, whether it modifies the scene file, or any side effects. 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?
Single sentence, efficient and front-loaded. No waste.
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 description is functionally clear but lacks usage guidance and behavioral details about how the transform is applied. Given the schema fully documents parameters, it's minimally complete but could benefit from notes on alternatives and side effects.
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 descriptions cover all parameters with formats and examples, so the baseline is 3. The description's mention of 'combined transform' adds slight context that all three properties can be set together, but doesn't add substantial meaning 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?
Clearly states the verb 'Apply' and resource 'combined transform (position, rotation, scale) to a node in a scene.' It distinguishes itself from single-property siblings like set_node_position/rotation/scale by emphasizing 'combined.'
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 set_node_position, set_node_rotation, or set_node_scale. No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan for missing UIDs.
| Name | Required | Description | Default |
|---|---|---|---|
| check_only | No | Only report missing UIDs, do not fix them |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It states 'Scan for missing UIDs,' which misleadingly suggests a read-only operation, but the parameter description reveals that the default behavior is to fix UIDs (a mutating action). It does not disclose side effects, reversibility, or any other 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 sentence, front-loaded with a verb and resource, so it is concise and structurally efficient. However, it is under-specified and lacks important context, making it less helpful than it could be while still being brief.
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 no output schema, no annotations, and a complex relationship with sibling tools. The description only says 'Scan for missing UIDs,' which fails to explain the tool's actual mutation behavior, what it returns, or how it relates to fix_missing_uids and list_missing_uids. It is severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter, and its description ('Only report missing UIDs, do not fix them') is clear. The tool description itself adds no parameter meaning, but the schema already provides adequate semantics, so 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 says 'Scan for missing UIDs,' but the tool name is 'update_project_uids' and the check_only parameter ('Only report missing UIDs, do not fix them') implies that the default behavior is to fix or update UIDs, not just scan. This is misleading and does not clearly distinguish the tool from siblings like list_missing_uids or fix_missing_uids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as fix_missing_uids or list_missing_uids. There is no mention of prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate project for broken refs, empty UIDs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. 'Validate' implies a non-mutating check, and the specific checks (broken refs, empty UIDs) are mentioned. However, it doesn't disclose what the tool returns (e.g., a report, boolean success, or thrown errors) or any potential side effects, leaving some ambiguity.
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 that directly states the tool's purpose. Every word earns its place, and there is no unnecessary verbosity or repetition.
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 parameterless validation tool with no output schema, the description gives a clear scope of what is validated. It does not explain the return value or how results are presented, but given the simplicity and the context of similar sibling tools, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter information to explain. The description is not expected to add parameter semantics beyond the schema, and the baseline of 4 applies here.
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 'Validate' with the resource 'project' and specifics 'broken refs, empty UIDs'. This distinguishes it from sibling tools like validate_script and validate_shader, which target individual resources rather than the project as a whole.
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. For example, it doesn't mention that this is useful after project modifications or how it relates to list_missing_uids or fix_missing_uids. The description merely says what it does without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate GDScript for common issues.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .gd file to validate (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects and behavior. It states the tool 'validates' but does not clarify whether it is a read-only operation, what specific issues it checks for, or what output it returns (e.g., list of errors or warnings). This lack of detail leaves significant ambiguity for an AI agent.
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 redundant words. It is appropriately sized for a simple one-parameter tool and immediately conveys the core purpose without excessive detail.
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 description is incomplete for a validation tool. It does not explain what constitutes 'common issues,' what the return value or output looks like, or whether the operation has side effects on the file system. Since there are no annotations or output schema, the description should provide this context but fails to do so.
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, including a clear description for 'path' (path to .gd file relative to project root). The tool description itself does not add any additional meaning about the parameter, so the baseline score of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('validate') and resource ('GDScript'), which distinguishes it from sibling tools like validate_shader and validate_project that target different resources. However, 'common issues' is vague and does not specify what type of validation is performed (e.g., syntax, style, or static analysis), preventing a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that one should use this instead of editor_run_gdscript or compile_shader, nor does it exclude any scenarios. The only implied usage is the generic 'validate GDScript,' which is evident from the name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate .gdshader for syntax issues (shader_type, braces, declarations).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .gdshader file to validate (relative to project root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that validation checks shader_type, braces, and declarations, but does not mention side effects, return behavior, or failure modes. Since 'validate' typically implies read-only, this is somewhat transparent but lacks explicit confirmation.
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 that efficiently conveys the tool's purpose without redundancy. Every word earns 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?
The tool is simple with one parameter, but the description does not explain output on success/failure or whether the file is modified. Since there is no output schema, the description should clarify what the validation returns, but it remains adequately scoped for a straightforward validation 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 for the single 'path' parameter is 100%, so the baseline is 3. The description adds no additional parameter-specific detail beyond the schema's 'relative to project root' description.
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 validates .gdshader files for syntax issues, naming specific elements (shader_type, braces, declarations). This specific verb+resource+scope distinguishes it from siblings like read_shader, write_shader, and compile_shader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as compile_shader or validate_script. There are no usage contexts, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write/overwrite 2D and 3D collision layer names in project.godot.
| Name | Required | Description | Default |
|---|---|---|---|
| layers_2d | No | Map of layer number (e.g. "1") to display name for 2D physics | |
| layers_3d | No | Map of layer number to display name for 3D physics |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It conveys that the tool overwrites, but it does not clarify whether it replaces all layer names or only the provided ones, what happens if a parameter is omitted, or any side effects on the project.godot file. This is a significant transparency gap for a mutating operation.
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 redundant content. It efficiently captures the tool's 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?
The tool is relatively simple with two optional parameters and no output schema. The description covers the core action but omits edge-case behavior (e.g., empty objects, merging vs. replacing, error conditions). It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly described in the schema. The description does not add parameter-level meaning beyond what the schema provides, so the 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 'Write/overwrite 2D and 3D collision layer names in project.godot,' using a specific verb ('write/overwrite') and resource ('collision layer names in project.godot'). It distinguishes from the sibling read_collision_layers by indicating a write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (write when you need to set collision layer names) but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It lacks explicit guidance about when to prefer this over write_project_config or other configuration-modifying tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write import settings.
| Name | Required | Description | Default |
|---|---|---|---|
| settings | Yes | Import settings to write (key=value in the [params] section) | |
| asset_path | Yes | Path to the source asset file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It simply says 'Write import settings' with no mention of side effects, overwrite behavior, file modifications, permissions, or whether it creates new files or edits existing ones. The settings parameter description adds a hint about the format ('key=value in the [params] section') but that 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 extremely short ('Write import settings.'), which is brief but under-specified. It does not waste words, but it omits important context. It is neither appropriately sized for the tool's complexity nor front-loaded with key behavioral 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?
The tool is a write operation with no output schema, so the description should explain what happens after writing (e.g., does it modify an .import file? Is there a return value?). It does not address side effects or confirm completion. The presence of 'read_import_config' suggests it writes to import config files, but this is not stated, making the description 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 description coverage is 100% since both parameters have descriptions. The settings parameter description adds some context about the [params] section, but the tool description itself does not enrich the parameter meanings beyond the schema. Baseline 3 is appropriate when schema covers all params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Write import settings.' It clearly indicates the tool writes import settings, and the sibling tool 'read_import_config' helps clarify the context. However, it does not explicitly differentiate from other write tools like 'write_resource' or 'write_project_config', so it's clear but lacks sibling differentiation.
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. It does not mention prerequisites, exclusions, or relationships to related tools such as 'read_import_config' or other write tools. There is no contextual clue about typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new input action.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Input action name (e.g. "jump", "move_left") | |
| deadzone | No | Deadzone for analog inputs (0-1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action and does not reveal potential overwriting behavior, side effects, or required project state. This is a significant gap 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 concise sentence that is front-loaded. It packs the essential purpose without waste, though it is too sparse to address other dimensions.
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 annotations, no output schema, and a mutation operation, the description is insufficient. It lacks behavioral context, relationship to siblings, and any caveats about creating input actions. The schema covers parameters, but the tool's overall semantics remain unclear.
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%: the schema already explains 'action' with an example and 'deadzone' with a default and range. The description adds no additional parameter context, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a new input action' with a specific verb and resource. However, it does not distinguish itself from sibling tools like 'editor_add_input_action' or 'add_input_binding', which have overlapping purposes.
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 given on when to use this tool versus alternatives. There is no mention of prerequisites, whether it operates on the global input map, or differences from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a curve into a Path2D/Path3D node in a scene.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path node name (first found if omitted) | |
| closed | No | Whether the curve is closed | |
| points | Yes | Control points as arrays of [x, y, z] (Path3D) or [x, y] (Path2D) | |
| scene_path | Yes | Path to .tscn scene containing a Path2D/Path3D node | |
| bake_resolution | No | Curve bake resolution |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses only that the operation writes a curve into a node, but does not state whether this overwrites existing curve data, mutates the scene file, or requires any particular scene state. The mutation is only implied by 'Write'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition; it communicates the operation efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema richly documents all five parameters, and the description provides an adequate high-level purpose. However, with no output schema and no annotations, the description leaves gaps around side effects (e.g., overwriting curves, saving the scene) and the distinction from creating curves. It is minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter descriptions, so the baseline is 3. The description adds no additional parameter-level meaning beyond the schema, but it does clarify the high-level relationship between scene_path, path, and points.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Write') and names the resource ('a curve into a Path2D/Path3D node in a scene'), clearly distinguishing it from sibling tools like create_curve (which creates a curve resource) and read_path (which reads path data). It conveys the write-to-existing-node operation.
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 such as create_curve, add_node, or modify_node, nor does it state prerequisites or exclusions. It merely implies a use case through its purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a config value to project.godot.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Config key to set | |
| value | Yes | Config value to set | |
| section | Yes | Section name to add or modify (e.g. "application", "rendering") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It states 'write' but does not disclose whether existing values are overwritten, whether sections are auto-created, whether type coercion occurs (value is string in schema but Godot configs support multiple types), or any side effects like requiring an open project. 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 concise sentence, immediately front-loaded with the verb and target. It contains no wasted words and is easily parseable.
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 is too sparse. It does not mention return values, failure conditions, persistence behavior, or interaction with the editor state. For a tool with three parameters and a write side effect, this is 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 description coverage is 100% with clear parameter descriptions (section, key, value). The description adds no additional meaning beyond the action itself, so it does not enhance parameter understanding. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Write a config value to project.godot' clearly identifies the verb (write), resource (config value), and target (project.godot), distinguishing it from the sibling read_project_config. It does not explicitly mention 'project settings' but the filename is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as read_project_config or diff_project_config. The description lacks any context about editing project settings, prerequisites, or exclusions, so an agent has no basis for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write properties to a resource.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .tres file (relative to project root) | |
| properties | Yes | Properties to set/overwrite in the [resource] section | |
| create_backup | No | Create .bak backup (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Write properties' implies mutation, but it does not explain overwrite semantics, the create_backup behavior (which defaults to true), file handling, or any side effects. The agent is left without critical safety information for a mutation operation.
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 one short sentence with no redundancy or filler. It is front-loaded and easy to parse, though its brevity contributes to the lack of depth in other dimensions.
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, the absence of an output schema, and the need to disambiguate from numerous write_* and create_* sibling tools, this description is not complete. It does not explain what a 'resource' is in this context, the .tres file format, backup behavior, or how this tool differs from create_resource. The description expects the agent to infer too much.
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 description adds no parameter-level meaning, but the input schema already provides thorough descriptions for all three parameters (path, properties, create_backup), covering 100% of them. Therefore, the baseline of 3 is appropriate; the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a clear verb ('write') and resource type, but is vague: it doesn't specify whether this modifies an existing resource or creates a new one, nor does it mention .tres files. It needs to differentiate from sibling tools like create_resource and duplicate_resource, which have overlapping purposes.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention that this writes to an existing resource, nor does it suggest when to prefer create_resource or read_resource. Multiple write_* siblings exist, but no context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write content to a script file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to script file (relative to project root) | |
| content | Yes | New file content | |
| create_backup | No | Create .bak backup (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely restates the action without explaining overwrite behavior, backup creation (despite the create_backup parameter defaulting to true), or any side effects or requirements. This is insufficient for a mutating 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 concise sentence, front-loaded with the verb and object. It is efficient but may be too terse, lacking useful context about file overwriting or backup behavior.
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 no annotations and no output schema, the description is incomplete. It fails to mention whether the file is created if missing, whether content is overwritten, or that backups are created by default. The schema compensates for parameter definitions but not for usage 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 schema covers all parameters with clear descriptions (path, content, create_backup), so the description need not add parameter details. The description adds no extra semantics beyond the schema, but the baseline is 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes content to a script file, using a specific verb and resource. However, it does not distinguish this from similar sibling tools like create_script or write_resource, both of which may also write script-related content.
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. There is no mention of whether it creates new files or overwrites existing ones, leaving the agent without criteria for selecting among siblings like create_script or write_resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write content to a .gdshader.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .gdshader file (relative to project root) | |
| content | Yes | New shader content | |
| create_backup | No | Create .bak backup (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits alone. It only says 'Write content' implying overwrite, but fails to mention the backup behavior (create_backup param), whether the file must exist, or any validation/compile side effects. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded with the verb and object, making it maximally concise for its content.
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 description is under-specified for a write tool. It lacks information about file existence requirements, backup creation, and return values. Since there is no output schema, the description should have hinted at what the tool returns, but it doesn't.
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 each parameter (path, content, create_backup) already described in the input schema. The tool description adds no further parameter semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Write content to a .gdshader' uses a specific verb and target resource, making the tool's purpose instantly clear. It distinguishes from generic write_resource by the .gdshader extension, though it doesn't explicitly contrast with create_shader or compile_shader.
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 like write_resource or set_shader_node_param. The description gives no contextual cue for selection among the many shader-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a full translation CSV (keys + entries).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .csv translation file to write/overwrite | |
| entries | Yes | Map of translation key to its value | |
| language | No | Target language column code | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description provides minimal behavioral disclosure. It does not explicitly state that the file will be overwritten or truncated, nor does it mention any side effects or return behavior. The path schema mentions 'write/overwrite,' but the description itself lacks this 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, front-loaded sentence with no filler. It efficiently conveys the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with no annotations and no output schema, the description is too sparse. It does not cover overwrite behavior, expected CSV format, relationship to existing translation files, or usage context. The agent would need to rely on schema and tool name to infer basic 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?
All three parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds little beyond the schema — 'keys + entries' approximately describes the entries map but offers no additional semantics for path or language.
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 (write) and the resource (full translation CSV). The word 'full' differentiates it from incremental operations like add_translation_key, making the tool's scope evident.
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 given on when to use this tool versus alternatives. It does not mention that add_translation_key is for incremental additions or that create_translation handles resource creation, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.9.0add_animation_libraryadd_animation_trackadd_audio_busadd_autoloadadd_bus_effectadd_input_bindingadd_nodeadd_script_exportadd_script_functionadd_script_signaladd_shader_graph_nodeadd_theme_typeadd_tileset_sourceadd_translation_keyattach_scriptcapture_screenshotclone_nodecompile_shaderconnect_shader_graph_nodesconnect_signalcreate_animationcreate_atlas_texturecreate_audio_bus_layoutcreate_camera_attributescreate_collision_polygoncreate_curvecreate_directorycreate_environmentcreate_gdextensioncreate_gradientcreate_grid_mapcreate_image_texturecreate_jointcreate_mesh_primitivecreate_multimeshcreate_nav_linkcreate_nav_meshcreate_noise_texturecreate_physics_materialcreate_resourcecreate_scenecreate_scriptcreate_shadercreate_shader_includecreate_skycreate_spring_armcreate_sprite_framescreate_themecreate_tilesetcreate_translationcreate_vehicle_bodycreate_visual_shadercreate_worldcreate_world_environmentdelete_filediff_animationdiff_project_configdiff_resourcediff_scenediff_scriptdisconnect_shader_graph_nodesdisconnect_signalduplicate_resourceduplicate_sceneedit_sceneeditor_add_autoloadeditor_add_input_actioneditor_add_nodeeditor_attach_scripteditor_bake_lightmapseditor_bake_navigationeditor_clear_errorseditor_connect_signaleditor_copyeditor_create_cameraeditor_create_csg_boxeditor_create_csg_cylindereditor_create_csg_mergeeditor_create_csg_polygoneditor_create_csg_sphereeditor_create_foldereditor_create_gpu_particleseditor_create_mesh_instanceeditor_create_multiplayer_spawnereditor_create_multiplayer_synchronizereditor_create_sceneeditor_create_scripteditor_cuteditor_debug_breakeditor_debug_continueeditor_debug_stepeditor_debug_step_overeditor_delete_asseteditor_delete_selectededitor_disable_plugineditor_disconnect_signaleditor_duplicate_asseteditor_duplicate_nodeeditor_enable_plugineditor_evaluate_expressioneditor_focuseditor_get_autoloadseditor_get_breakpointseditor_get_cameraeditor_get_class_doceditor_get_class_listeditor_get_class_propertieseditor_get_class_signalseditor_get_debug_variableseditor_get_dependencieseditor_get_editor_settingeditor_get_errorseditor_get_infoeditor_get_input_mapeditor_get_method_listeditor_get_node_propertieseditor_get_open_sceneeditor_get_performanceeditor_get_plugin_listeditor_get_project_directoryeditor_get_project_settingeditor_get_recent_sceneseditor_get_recteditor_get_running_scene_treeeditor_get_scene_changeseditor_get_selectioneditor_get_stack_traceeditor_health_checkeditor_instantiate_sceneeditor_list_filesystemeditor_list_node_signalseditor_move_asseteditor_move_nodeeditor_open_asseteditor_open_dockeditor_pasteeditor_pauseeditor_playeditor_read_current_sceneeditor_redoeditor_reimport_asseteditor_reload_sceneeditor_remove_autoloadeditor_remove_breakpointeditor_remove_input_actioneditor_remove_nodeeditor_rename_asseteditor_rename_nodeeditor_reparent_nodeeditor_run_gdscripteditor_run_specific_sceneeditor_saveeditor_save_alleditor_search_helpeditor_set_animated_sprite_parameditor_set_area_parameditor_set_audio_listener_parameditor_set_audio_player_parameditor_set_breakpointeditor_set_cameraeditor_set_camera_parameditor_set_character_body_parameditor_set_container_parameditor_set_decal_parameditor_set_editor_settingeditor_set_main_sceneeditor_set_marker_parameditor_set_multiplayer_spawner_parameditor_set_multiplayer_synchronizer_parameditor_set_node_propertieseditor_set_occluder_parameditor_set_parallax_parameditor_set_particles_parameditor_set_project_settingeditor_set_rich_text_parameditor_set_selectioneditor_set_soft_body_parameditor_set_tab_container_parameditor_set_video_player_parameditor_set_viewport_parameditor_show_in_filesystemeditor_simulate_keyeditor_stopeditor_take_screenshoteditor_toggle_grideditor_toggle_snapeditor_undoeditor_unpauseexport_projectfind_nodes_in_scenesfind_unused_assetsfix_missing_uidsgenerate_cohesion_reportgenerate_project_reportget_godot_versionget_shader_node_defaultsget_statusget_uidis_editor_runninglaunch_editorlist_all_signalslist_animationslist_audio_fileslist_autoloadslist_cameraslist_csprojlist_environmentslist_groupslist_import_fileslist_jointslist_lightslist_materialslist_missing_uidslist_nav_regionslist_pathslist_physics_materialslist_popupslist_project_fileslist_projectslist_resourceslist_sceneslist_scriptslist_shader_includeslist_shader_node_typeslist_shaderslist_skeletonslist_textureslist_tilesetslist_translationslist_ui_nodeslist_visual_shadersload_spritemodify_nodemonitor_outputmove_fileread_animated_spriteread_animationread_animation_treeread_arearead_audio_bus_layoutread_audio_listenerread_audio_playerread_audio_streamread_cameraread_character_bodyread_collision_layersread_collision_polygonread_containerread_csprojread_curveread_decalread_environmentread_export_presetsread_gdextensionread_gradientread_grid_mapread_import_configread_input_mapread_jointread_light_2dread_markerread_materialread_mesh_instanceread_multimeshread_nav_agentread_nav_obstacleread_nav_regionread_occluderread_parallaxread_particlesread_pathread_physics_materialread_project_configread_project_iconread_raycastread_reflection_proberead_resourceread_rich_textread_sceneread_scriptread_script_structureread_shaderread_shader_includeread_skeletonread_soft_bodyread_spring_armread_sprite_framesread_styleboxread_tab_containerread_texture_inforead_themeread_tilemapread_tilesetread_translationread_vehicle_bodyread_video_playerread_viewportread_visual_shaderremove_animation_trackremove_audio_busremove_autoloadremove_input_actionremove_jointremove_noderemove_shader_graph_noderename_noderun_projectruntime_call_methodruntime_emit_signalruntime_freezeruntime_get_noderuntime_get_treeruntime_inputruntime_pingruntime_resumeruntime_screenshotruntime_set_noderuntime_stepscene_dependency_graphsearch_in_projectsearch_in_scriptssearch_scene_contentsearch_toolsset_animation_paramset_animation_tree_paramset_bus_volumeset_collision_shapeset_environment_paramset_joint_paramset_keyframeset_light_2d_paramset_light_paramset_material_paramset_mesh_surface_materialset_node_positionset_node_rotationset_node_scaleset_shader_node_paramset_shape_pointsset_skeleton_bone_poseset_styleboxset_texture_import_flagssimplify_polygonstop_projecttransform_nodeupdate_project_uidsvalidate_projectvalidate_scriptvalidate_shaderwrite_collision_layerswrite_import_configwrite_input_actionwrite_path_curvewrite_project_configwrite_resourcewrite_scriptwrite_shaderwrite_translationScored across 358 tools
Several near-duplicates exist, such as capture_screenshot and runtime_screenshot, plus multiple status/health-check tools with overlapping purposes. With 358 tools and repeated add_/create_/write_, read_/list_/editor_get_, and set_/editor_set_ namespaces, an agent cannot reliably distinguish intent without searching, which the included search_tools tool implicitly acknowledges.
Tool names are almost entirely lowercase snake_case with a verb_noun shape, and editor_/runtime_ prefixes create recognizable namespaces. However, related operations use inconsistent verbs (add_input_binding vs write_input_action, create_scene vs editor_create_scene, read_ vs list_ vs editor_get_), and a few oddities like get_status and launch_editor break the strict pattern.
358 tools is an extreme mismatch for an MCP server surface; even with good categorization, it is far beyond what an agent can hold or reliably route between. The included search_tools tool is a workaround for tool discovery, not a solution to over-scoping.
The coverage is encyclopedic: editor automation, runtime debugging, scenes, resources, shaders, audio, navigation, physics, UI, project configuration, and exports all have read/list/create/set support. A few lifecycle gaps exist, such as some entity types having readers but no writers or removers, but these are minor relative to the enormous surface.
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.
