The Godot Agent Loop MCP Server provides AI agents a complete feedback loop to author, run, observe, playtest, and verify Godot 4 games. Key capabilities include:
Project & File Management
Create new Godot projects (GDScript or .NET/C#), list projects, and retrieve project metadata
Read/write project files, list files with filtering and pagination
Read/modify project.godot settings, set the main scene, and manage input maps
Scene Authoring
Create scenes, add/remove/modify nodes, attach scripts, and save scenes
Parse scene files into structured JSON node trees (headless)
Scripting
Create GDScript files from templates, attach scripts to nodes
Validate scripts individually or in batch (all or git-changed files) for syntax/type errors
Running & Observing the Game
Launch and stop the Godot game, capture logs, print output, and push_error/push_warning messages incrementally
Playtesting & Input Simulation
Simulate mouse clicks, key presses/releases, and input actions
Wait for a specified number of render or physics frames
Take screenshots of the running game
Runtime Inspection
Retrieve the live scene tree (up to 10,000 nodes), inspect node properties/signals/methods, and list visible UI controls
Verification & Testing
Run bounded assertions against a running game (node existence, group counts, log content) with optional screenshot capture
Discover and run native, GUT, and GdUnit4 test suites with structured results
Editor Automation
Launch the Godot editor, inspect/modify open scenes, set properties, rename nodes, open/save scenes, and perform undo/redo
Tool Discovery & Utilities
Query the installed Godot version
Use the godot_tools meta-tool to search, describe, and call tools across the full catalog beyond the default core surface
Provides tools for authoring, running, observing, playtesting, and verifying Godot games, including scene manipulation, script validation, runtime code execution, and more.
Supports scaffolding C# projects, generating C# scripts, and managing .NET projects within Godot.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Godot Agent Loop create a new Godot 4 project with a player scene and a coin to collect"
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.
Build it. Play it. Prove it.
An MCP automation loop for Godot 4.
Other integrations give agents tools. Godot Agent Loop gives them a feedback loop to author, run, observe, playtest, and independently verify Godot games:
author → validate → run → observe → playtest → verify → refine
Watch the 65-second demo · Read the exact run evidence · Inspect the resulting project
claude mcp add godot-agent-loop -- npx -y @beremaran/godot-agent-loopThen point the agent at a project directory—or an empty directory—and describe
the playable result. The default core surface is kept within the generated
tool-surface budget. Use read-only
godot_catalog to find and inspect a hidden capability, then godot_call to
execute it. Runtime injection is transient; watched projects can use the optional
persistent editor addon.
Using Cline, Cursor, or another MCP client? See Configuration.
Related MCP server: godot-ai-mcp
The evaluation guide documents the pinned conformance, Inspector, Inspect AI, real-client, scorer, baseline, and paired-comparison lanes, including exactly which agent and model each lane uses.
A retained representative real-Godot path is enforced in CI.
Historically, a cold agent demonstrated MCP-only operation by building and independently verifying a playable win/lose game with zero human corrections in under seven minutes, using 103 MCP calls and no built-in tools. That launch pre-dates the lean surface reduction, which deliberately removed file, scene-authoring, and project-settings tools whose work host editors and shells do better; see the launch evidence and the changelog.
Privileged reflection and code-execution groups are denied by default, and the editor provides a human Pause Agent control.
Support is deliberately bounded: Godot 4.7 is both the compatibility floor and the primary target. Editor attachment is verified on Linux CI and in a headed macOS 4.7.1 acceptance run; Windows retains the documented portable acceptance path but not an editor-UI claim. Full debugger automation, native extension builds, and unbounded engine control are not claimed. Details in the verified support boundary.
A lean task-oriented core — the default surface advertises 16 tools that
cover the whole loop: catalog and dispatch (godot_catalog, godot_call),
lifecycle (run_project, stop_project), the editor session and
compound scene transactions (editor_session, editor_transaction),
observation (game_screenshot, game_get_scene_tree, game_get_ui,
game_get_node_info, game_get_errors, game_get_logs), structured
interaction and waiting (game_scenario, game_wait_until), and independent
verification (run_project_tests, verify_project).
Everything else is one search away — 40 more tools remain callable through
godot_catalog + godot_call: input primitives (mouse, keyboard, key-hold,
drag, scroll, touch, gamepad), runtime reflection (privileged, opt-in),
node and signal generics, observation extras (performance, visual regression,
camera, audio), editor control, and ship tooling (export readiness, import
pipeline, .NET, add-ons).
Author with your own file tools — coding agents edit
.gd/.tscn/.tres/project.godot directly and validate them with
run_project_tests or headless checks; with an editor attached,
editor_transaction applies undoable
compound scene edits through EditorUndoRedoManager.
Run and observe — launch the game, capture logs and errors incrementally, take screenshots, and run visual-regression comparisons with baselines, masks, and retained diffs.
Playtest like a player — mouse, keyboard, key-hold, drag, scroll, touch,
and gamepad input against the running game, composed deterministically with
game_scenario.
Verify independently — test runners for native/GUT/GdUnit4
(run_project_tests), bounded runtime
evidence (verify_project), export checks (verify_export_readiness), and
static integrity analysis (analyze_project_integrity).
Reach into the runtime — with reflection and code-execution opted in,
inspect and manipulate any node, signal, or property through game_eval and
the generic node tools.
Drive the editor — editor_session ensure discovers the matching
project, editor_transaction applies reversible edits through
EditorUndoRedoManager, and the Agent Activity dock replays the bounded
correlated trace with a human Pause Agent lock.
.NET / C# support — inspect, restore, build, and run .NET projects with a
Godot.NET.Sdk matched to your installed Godot via verify_dotnet_project.
Bounded by design — deterministic pagination and size caps on large responses, structured correlated diagnostics, and least-privilege security defaults.
The full inventory—the 16 advertised core tools plus the hidden catalog of 40 more—lives in docs/tools.md.
Godot Engine 4.7 or later
(Optional) .NET SDK 8.0+ and the
Godot .NET (C#) build, only if you use verify_dotnet_project
Node.js >= 22.0.0 (active LTS)
An AI assistant that supports MCP (Claude Code, Cline, Cursor, etc.)
Development targets the latest stable Godot release. Godot 4.7 is the current compatibility floor and primary target, and CI covers that exact release. The floor may be raised when it blocks useful features or creates meaningful maintenance cost. In that case, the last compatible release remains available, and an older-version maintenance branch will be created only when user demand justifies maintaining it. Such a branch would receive critical fixes rather than new features.
Area | Status | Evidence or limitation |
Linux headed (desktop or Xvfb), Godot 4.7 | Verified in CI | Retained MCP E2E under Xvfb covers representative authoring, runtime, editor attachment, and teardown paths |
GDScript project and running-game workflows | Representative coverage retained | Scene creation, runtime mutation, process ownership, security, and editor discovery remain in the E2E smoke suite |
Privileged runtime commands | Opt-in only | Disabled by default; intended for trusted localhost development |
Godot .NET/C# | Scaffold, compile, and editor-load verification | Godot .NET 4.7 with .NET SDK 8 |
Linux exports | Release/debug template export and smoke-run verification | Godot 4.7 installed templates; other targets are not claimed |
Rendering and screenshots | A headed rendering context is required | Compatibility and Forward+ on Linux software rendering; display-less sessions fail fast with desktop/Xvfb remediation |
Windows | Portable acceptance verified | Godot 4.7 process, Unicode path, runtime input, window query, and teardown workflows; editor UI, rendering, and exports are not claimed |
macOS | Portable acceptance and attached-editor workflow verified | Godot 4.7.1 headed replay opens Godot normally, reconnects the MCP, authors and synchronizes without focus switching/manual reload, exercises undoable transactions, and cleans the discovery record; see the interactive acceptance record |
Editor state and undo/redo bridge | Verified on Linux CI and headed macOS 4.7.1 | Protocol 2 uses private per-project discovery, |
Full debugger control | Not claimed | Breakpoints, stack inspection, and frame-local evaluation remain outside the supported boundary |
Profiler, leak, asset, localization, and accessibility audits | Verified in MCP E2E |
|
GDExtension builds | Not claimed |
|
The quickstart npx command is all most setups need. The
sections below cover other clients and a source checkout.
For a project the user watches, copy
addons/godot_agent_loop into the project at that
same path, enable Godot Agent Loop under Project > Project Settings >
Plugins, and restart Godot once. Thereafter Godot may be opened normally;
editor_session discovers the matching project without launching a duplicate.
The dock remains visible and waits cleanly when no agent is connected.
The addon publishes a private, untracked record at
.godot/godot_agent_loop/editor-session.json with a fresh token and ephemeral
loopback port for each editor start. The token is never returned or logged.
Multiple editors are routed by canonical project path. To uninstall, disable
the plugin, close Godot, remove addons/godot_agent_loop, and optionally remove
a stale .godot/godot_agent_loop directory. MCP cleanup removes only its own
unmodified transient bridge, never this persistent addon.
An editor already started without an enabled compatible addon cannot receive a
new EditorPlugin safely at runtime. Install/enable once and restart. See the
interaction architecture for states,
protocol migration, unsaved-conflict recovery, and fallback semantics.
The repository ships one neutral bundle that starts the matching npm MCP server and provides the same build, debug, verify, and ship skills to Claude Code, Codex, OpenCode, and Pi. For Claude Code:
/plugin marketplace add beremaran/godot-agent-loop
/plugin install godot-agent-loop@godot-agent-loopFor a local checkout, use claude --plugin-dir ./agent-plugin. See the
portable agent bundle guide for verified Claude Code,
Codex, OpenCode, and Pi install paths.
Add to your Claude Code MCP settings:
{
"mcpServers": {
"godot": {
"command": "npx",
"args": ["-y", "@beremaran/godot-agent-loop"],
"env": {
"GODOT_PATH": "/path/to/godot",
"DEBUG": "true"
}
}
}
}Add to your Cline MCP settings (cline_mcp_settings.json):
{
"mcpServers": {
"godot": {
"command": "npx",
"args": ["-y", "@beremaran/godot-agent-loop"],
"disabled": false
}
}
}Create .cursor/mcp.json in your project:
{
"mcpServers": {
"godot": {
"command": "npx",
"args": ["-y", "@beremaran/godot-agent-loop"]
}
}
}For a source checkout, use node as the executable and pass the built server
path as a separate argument:
{
"command": "node",
"args": ["/absolute/path/to/godot-agent-loop/build/index.js"]
}git clone https://github.com/beremaran/godot-agent-loop.git
cd godot-agent-loop
npm install
npm run buildNo setup is required when the game is started through run_project: the server
installs the interaction autoload automatically by generating an override.cfg
(which Godot merges over project.godot at startup) and copying the runtime
scripts into the project, then removes them again on stop_project, game exit,
or server shutdown. project.godot is never modified. If an earlier server
crashed or was killed before cleaning up, the next server detects and removes
the leftover files on first contact with the project; an installation you
manage yourself (declared in project.godot) is never touched.
To run the interaction server without run_project, copy
build/scripts/mcp_interaction_server.gd to your project and register it as an
autoload:
Copy build/scripts/mcp_interaction_server.gd to your project's scripts folder
In Godot: Project > Project Settings > Autoload
Add the script with the name McpInteractionServer
The server listens on 127.0.0.1:9090. Each MCP server launch generates a
cryptographic runtime secret, passes it only to the Godot child process, and
authenticates it during capability negotiation before any runtime command is
accepted. A manually managed runtime should set the same
GODOT_MCP_RUNTIME_SECRET value in both processes. A runtime without a shared
secret refuses unauthenticated sessions unless GODOT_MCP_ALLOW_INSECURE_RUNTIME
is set explicitly; use that only on a trusted machine.
Commands that execute arbitrary GDScript or invoke arbitrary node properties or
methods remain disabled by default even after authentication. These
privileged runtime groups gate only runtime RPC operations over the
authenticated loopback channel — they do not restrict what the project process
itself can do. Running a project executes its GDScript with your OS-level
permissions: project code can read files you can read and make its own network
calls. Grant only the required group with GODOT_MCP_PRIVILEGED_GROUPS:
reflection enables arbitrary property/method access and code-execution
enables eval/script control. The legacy GODOT_MCP_ALLOW_PRIVILEGED_COMMANDS=true
grants both groups. Use either only for a trusted local developer workflow, and
only against trusted project sources. Authentication and policy denials never
echo secrets, source, property values, URLs, headers, or engine errors.
Every Godot process the server launches — long-running games, the editor, and
short-lived CLI runs (script validation, tests, import, export, addon reload,
and the dotnet build/restore/run workflow) — receives a sanitized environment:
only platform essentials (PATH, home and temp directories, display and locale
variables) plus the server's explicit per-launch variables (runtime secret,
timing metadata, privileged-group grants). The server's full environment is
never inherited. Forward additional variables deliberately with
GODOT_MCP_CHILD_ENV_ALLOW. CLI validation runs additionally disable the
runtime transport. Authentication success/failure emits a structured audit
event containing only the event name, runtime component, numeric session ID,
and timestamp.
Variable | Description |
| Path to the Godot executable (overrides auto-detection) |
| Set to |
| Optional. Restrict |
| Optional, default |
| Optional explicit shared runtime secret. The MCP server generates a fresh 256-bit value when omitted and passes it only to Godot processes it launches. Set the same value manually only when connecting to a separately launched runtime. |
| Optional, default |
| Optional, default |
| Optional, default |
| Optional comma-separated least-privilege grants: |
| Optional, default |
| Optional, default |
| Optional, default |
| Optional. Comma-separated names of extra environment variables to forward from the server environment into every Godot process the server launches, including short-lived CLI runs (for example |
With DEBUG=true, the MCP server emits JSON request lifecycle events to
stderr. The Godot runtime emits matching events to its captured stdout. Both
use an internal mcp_<number> correlation ID and controlled event fields;
parameters, response values, secrets, source, URLs, and malformed payloads are
never copied into logs. Runtime process output is capped at the latest 1,000
stdout and stderr lines. Stable JSON-RPC error codes remain the authoritative
machine-readable failure classification.
Large responses are bounded rather than allowed to grow with project size.
game_get_scene_tree returns deterministic pre-order trees of 1,000 nodes by
default (configurable up to 10,000) and reports truncation, and
game_get_ui bounds visible controls. game_get_logs and
game_get_errors return at most 1,000 unread lines per call with hasMore and
remaining, while retaining the latest 1,000 lines per stream. Runtime JSON
responses are capped at 8 MiB, screenshots additionally enforce pixel and
6 MiB PNG limits, and short-lived subprocess/import commands cap captured output
at 16 MiB. Limit failures are explicit; callers can narrow resource/import
queries instead of receiving partial unlabelled data.
The server uses three bounded execution paths:
Scene and resource authoring - coding agents are expected to author
.gd/.tscn/.tres/project.godot with their own file tools. When a
compatible editor session is attached, editor_transaction applies compound
scene edits as one undo step through EditorUndoRedoManager; detached and
CI projects are authored directly on disk.
Running-game socket - run_project launches the user's game headed and
injects the authenticated mcp_interaction_server.gd autoload through
override.cfg for high-fidelity runtime interaction.
Other one-shot subprocess work - Validation, import, and export operations may invoke Godot once and exit. Running games, screenshots, and visual checks still require a desktop display, Xvfb, or another reachable rendering context.
Path | Description |
| MCP server entry point |
| Tool names and JSON schemas |
| Per-tool domain, backend, and action declarations |
| Reviewed core membership, discovery ranking, compatibility modes, and generated size budgets |
| Lifecycle, project, and game handler implementations |
| TCP interaction server autoload |
| Retained Vitest unit and MCP-to-Godot smoke suites |
The project uses Vitest for a deliberately small unit and MCP-to-Godot smoke suite.
npm run check # lint, build, and retained unit suite
npm run test:e2e # built MCP server through a real client and Godot
npm run test:e2e:docker # same suite inside a containerized xvfb+Godot 4.7 environment,
# so no Godot windows open on the host; use -- to pass file filters
npm run test:watch # watch modeEvery npm run test:e2e run ends with an [e2e-metrics] summary of wall-clock
time and MCP/Godot startup counts, so suite overhead can be compared across
runs and CI jobs. The containerized runner (scripts/run-e2e-docker.sh, image
built from tests/e2e/docker/Dockerfile) mirrors the primary Godot 4.7 CI job:
Ubuntu + xvfb + the official Godot build, with node_modules kept in a named
volume so the host install is never touched.
The shipped build, debug, verify, and ship skill scenarios are versioned under
evals/. Their committed status is intentionally not_run until a deliberate
current-model client run records versioned inputs and schema-valid metrics; the
deterministic golden replay is not presented as a substitute for that run.
"Author scripts/player.gd and scenes/level.tscn with your file tools, then
validate them with run_project_tests before launching"
"Run my Godot project and check for errors with game_get_errors"
"Check all my changed GDScript files for syntax errors before I run the game"
"Run the project, wait until the main menu is up, and take a screenshot"
"Hold down the W key for 2 seconds to test walking (find game_key_hold in the
catalog)"
"Run a game_scenario that presses Enter on the title screen and asserts the
scene changed to res://scenes/level.tscn"
"Use verify_project to run bounded assertions and capture evidence"
"Sample performance - what's my FPS and draw call count? (game_performance)"
"Export the project for Linux with verify_export_readiness"
"Restore, build, and run the .NET project with verify_dotnet_project"Contributing guide — development workflow, checks, and PR expectations
Security policy — how to report vulnerabilities
Issues — bug reports and feature requests
This project is licensed under the MIT License - see the LICENSE file for details.
Original project: godot-mcp by Solomon Elias (Coding-Solo), which provided the foundational TypeScript MCP server, headless GDScript operations, and TCP runtime interaction architecture.
Inherited from: Tugcan Topaloglu's godot-mcp, which extended the original project across networking, 3D/2D rendering, UI controls, audio, animation, file I/O, runtime code execution, project creation, and physics while preserving the MIT license.
Godot Agent Loop: maintained and substantially extended by Berke Arslan, preserving the complete Git history and every inherited MIT notice.
Discover, attach, inspect, or discon…
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Session action | |
| projectPath | Yes | Godot project path | |
| launchIfNeeded | No | For ensure, launch an editor only af… | |
| timeoutSeconds | No | For action=ensure only: |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false, destructiveHint=false, idempotentHint=false, providing minimal behavioral signal. The description is truncated and adds no behavioral context about side effects (launching editors, creating sessions, disconnecting), timing implications, or what gets modified. For a session-management tool that can launch editor processes, 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?
Intentionally truncated to a single fragment phrase. While short, this is under-specification rather than conciseness - the truncated content suggests the full description would be longer but valuable context is lost. The visible text provides only a partial action list and no 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?
Despite having an output schema, the tool is complex: it has a oneOf schema with action-dependent parameter constraints, multiple required params, and three distinct operational modes with different semantics. The description addresses none of this complexity - no guidance on when sessions would need to be disconnected, what status inspection returns, or how ensure differs from just launching a project (run_project sibling). A richer description is needed for a tool with this much branching logic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema_description_coverage is 100%, the descriptions are themselves truncated ('For ensure, launch an editor only af…', 'For action=ensure only:'). The schema does clarify that launchIfNeeded only applies to ensure and timeoutSeconds also applies only to ensure via the not{} constraints in the schema, but the description adds the conditional logic context that the schema's bare enum values don't convey. The description bridges some gaps left by truncation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Discover, attach, inspect, or discon…' indicates a multi-purpose session management tool but is truncated and doesn't specify the resource (editor session for Godot) directly. The title and parameter schema reveal it manages Godot editor sessions (ensure/status/disconnect), but the description alone is vague about what the tool does or the resource it operates on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 when-to-use guidance or differentiation from siblings like editor_transaction or run_project. The schema's oneOf structure and action enum imply three distinct usage modes (ensure/status/disconnect), but the description itself doesn't clarify when to choose this over sibling tools or how actions map to scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply one validated compound scene e…
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-readable undo action name | |
| save | No | Save and independently reopen/read t… | |
| rootType | No | Root node type when creating a missi… | |
| focusPath | No | Node to reveal after commit | |
| scenePath | Yes | Project-relative or res:// scene path | |
| operations | Yes | Ordered editor-native scene operatio… | |
| projectPath | Yes | Godot project path whose editor is a… |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate destructiveHint: true, but the truncated description adds no behavioral context beyond that. It does not explain what gets destroyed or the nature of the compound 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 incomplete sentence, which is under-specified rather than concise. It fails to convey essential 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 (7 parameters, 10 operation types) and the existence of an output schema, the description is woefully inadequate. It provides no context about operations, order, or return values.
Complex tools with many parameters or behaviors need more documentation. 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 information. Although the schema has 100% coverage, many parameter descriptions are also truncated, so the schema itself is incomplete. The description does not compensate 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 is truncated ('Apply one validated compound scene e…'), making its purpose vague. It does not clearly state what is being applied, nor does it distinguish from sibling tools like 'modify_scene_node' or '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?
No guidance is provided on when to use this tool versus alternatives such as 'modify_scene_node' or 'create_scene'. 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.
Get new push_error/push_warning mess…
| Name | Required | Description | Default |
|---|---|---|---|
| maxItems | No | Maximum unread error lines returned. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is known to be safe and idempotent. The description adds no behavioral details beyond its basic function, missing context about pagination, ordering, or whether errors are consumed after retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single truncated sentence fragment ('Get new push_error/push_warning mess…'). It is not properly structured and appears cut off, which harms 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?
Despite having an output schema, the description is incomplete and fails to clarify what 'new' means, how errors are ordered, or whether errors are persistent. The tool is simple, but the description lacks key 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 the parameter 'maxItems' is described in the schema as 'Maximum unread error lines returned.' The description adds no additional parameter information, 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 states 'Get new push_error/push_warning messages' which clearly indicates the tool retrieves error/warning messages. The name and title align, and it distinguishes from sibling 'game_get_logs' which likely gets general logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 vs alternatives, any prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get new print output from the runnin…
| Name | Required | Description | Default |
|---|---|---|---|
| maxItems | No | Maximum unread log lines returned. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns 'new print output' from the running game, implying it only fetches unread logs. However, it does not explain if logs are marked read after fetch, or behavior when no logs 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 short but truncated ('runnin…'), which makes it incomplete. While concise, the truncation harms clarity and reduces 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?
Given the simplicity of the tool (1 optional param, no required params, output schema present), the description covers the basic behavior but fails to differentiate from similar tools or provide usage context. Annotations cover safety. Overall 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?
One parameter 'maxItems' with schema description 'Maximum unread log lines returned.' is clear. The tool description adds 'new print output' which aligns but does not provide additional meaning beyond the schema. With 100% 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 'Get new print output from the runnin…' combined with the tool name and parameter 'maxItems' (unread log lines) clearly indicates a read operation for new/unread logs from a running game. However, the truncation of 'runnin…' slightly reduces clarity and completeness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'game_get_errors'. The description lacks context for selection among sibling tools, which is critical for an AI agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get compact or full node info;
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Compact omits methods and signals an… | |
| nodePath | Yes | Path to the node (e.g., "/root/Playe… | |
| propertyNames | No | Exact properties to include; |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating read operation. The description adds no additional behavioral context beyond the file notation, such as whether it returns failures on invalid paths or how errors surface. With annotations covering the safety profile, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions 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 zero wasted words. It front-loads the core purpose. However, given the tool's flexibility (compact vs full modes, property filtering), a bit more guidance could be justified, making it efficient but slightly under-specified for its feature set.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values don't need explanation. With good annotations and 100% schema coverage, the description needn't do much heavy lifting. Still, for a tool that supports two detail modes and optional property filtering, the description offers minimal guidance on how these features interplay, leaving some gaps for the agent to reason through.
Complex tools with many parameters or behaviors need more documentation. 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 (nodePath, detail, propertyNames) are already documented. The description itself adds no parameter-level meaning beyond what the schema provides; it does not clarify how propertyNames interacts with detail modes or give format examples. Baseline 3 is appropriate when schema carries the documentation 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 'Get compact or full node info' clearly states a verb ('Get') and a resource ('node info'), and it mentions the compact/full detail modes. It distinguishes reasonably from siblings like game_get_ui, game_get_scene_tree, and game_get_errors by focusing on node information specifically, though it doesn't explicitly differentiate itself from those 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 implies usage (querying node info) but provides no explicit when-to-use guidance or exclusions. It doesn't mention when to prefer compact vs full detail, or how it differs from related siblings like game_get_scene_tree or game_get_ui. The brief phrase 'compact or full' hints at a usage choice but doesn't elaborate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get scene tree structure of the runn…
| Name | Required | Description | Default |
|---|---|---|---|
| maxNodes | No | Maximum nodes returned in determinis… |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint as true, and destructiveHint as false, so the description adds no additional behavioral context. It does not disclose what the returned tree includes (e.g., all nodes, only visible nodes) or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one truncated sentence) but front-loads the key action. However, the truncation reduces clarity, and it could be more complete without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 an output schema, the description lacks context about the returned structure (e.g., whether it returns the entire hierarchy or just a subset). For a tool that retrieves a tree, more details would help the agent understand the output format and scope.
Complex tools with many parameters or behaviors need more documentation. 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 a description for the only parameter maxNodes, so the description does not need to add much. It provides no extra semantics beyond the schema, such as default behavior or how the limit affects results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Get scene tree structure of the runn…' which clearly identifies the tool's purpose as retrieving the hierarchy of the game scene. It is specific enough to distinguish from sibling tools like game_get_node_info which returns details of a single 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 alternatives such as game_get_ui or game_get_node_info. The description does not mention any prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a bounded list of visible UI ele…
| Name | Required | Description | Default |
|---|---|---|---|
| rootPath | No | Optional runtime subtree root, such… | |
| maxElements | No | Maximum controls returned. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide read-only and idempotent hints. Description adds 'visible' and 'bounded' context, but does not detail more nuanced behaviors. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, short and direct. Could be improved by completing the truncated fragment, but 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?
With annotations and output schema (likely describing return format), the description covers core function. Could mention pagination or limits more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds little beyond 'bounded' and 'visible'—both implicitly covered by schema (maxElements and rootPath description hints at subtree).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'bounded list of visible UI elements', which distinguishes from sibling tools like game_get_scene_tree and game_get_node_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as game_get_scene_tree or game_get_node_info. Misses opportunity to clarify use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Property waits need reflection;
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-readable scenario and parent t… | |
| steps | Yes | Bounded ordered scenario steps | |
| projectPath | No | Godot project path for trace correla… | |
| timeoutSeconds | No | Whole scenario timeout. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers no behavioral details beyond annotations. It does not explain execution flow, side effects, or constraints. No contradiction with annotations, but transparency is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but cryptic, lacking clarity. Conciseness is not beneficial if it sacrifices understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex schema and lack of purpose explanation, the description is severely incomplete. Even with an output schema, the tool's function is 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 coverage is 100%, so the input schema thoroughly describes each parameter. The description adds no value but does not detract. 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 'Property waits need reflection;' is cryptic and does not state what the tool does. It fails to convey that this tool executes a game scenario defined by a sequence of steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 siblings like game_click or game_get_ui. The description provides no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a PNG preview with dimension…
| Name | Required | Description | Default |
|---|---|---|---|
| retainArtifact | No | Retain a PNG in the system temp arti… |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (safe read), idempotentHint=true, and destructiveHint=false. The description adds minimal behavioral context beyond 'Capture a PNG preview', not elaborating on side effects or return details. The annotations carry the burden.
Agents need to know what a tool does to the world before calling 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 truncated mid-sentence ('with dimension…'), making it incomplete. While conciseness is valued, this is under-specification rather than efficient 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 has one optional parameter, an output schema (not shown), and simple functionality, a brief description could be adequate. However, the truncation and lack of parameter explanation leave it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'retainArtifact', but the description does not mention this parameter at all. It 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 begins with 'Capture a PNG preview' which clearly indicates the tool's action (capture) and output format (PNG), and it is distinct from sibling tools like game_click. However, the description is truncated with 'with dimension…', which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as game_get_ui (which also captures visual state). The description does not mention 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.
Property waits need reflection;
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Required bounded substring for a log… | |
| fresh | No | For log conditions, require the text… | |
| value | No | Expected canonical Godot Variant val… | |
| signal | No | Signal name for a signal condition | |
| nodePath | No | Runtime node path for node, property… | |
| property | No | Property name for a property conditi… | |
| condition | Yes | Property waits need reflection; | |
| scenePath | No | Expected current scene resource path… | |
| projectPath | No | Godot project path for trace correla… | |
| pollIntervalMs | No | Internal poll interval. | |
| timeoutSeconds | No | Maximum wait. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (readOnlyHint=false, destructiveHint=false) but the description adds no behavioral context. It does not explain what happens when conditions are met or how the tool affects game 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 extremely short but lacks substantive information. It is concise only in length, not in conveying useful 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?
Given the complex input schema with oneOf for 6 condition types and 11 parameters, the description provides no context about when to use each condition, expected output, or relationship to sibling tools. It is wholly 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 parameter descriptions cover all 11 parameters (100% coverage). The tool 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 'Property waits need reflection;' is cryptic and does not clearly state the tool's purpose. The title and schema indicate waiting for conditions, but the description fails to clarify that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings or which condition to choose. The description lacks any usage context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current debug output and err…
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, giving the agent a clear safety profile. The description is truncated and adds little beyond 'get output and err…', not disclosing details like whether this resets state, whether it's a snapshot vs stream, or how it relates to the engine runtime. With annotations present, the bar is lower, and the additions are minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is truncated mid-sentence with an ellipsis ('err…'), which is a structural failure—it doesn't complete its thought. While brevity is present, the description is under-specified rather than concisely complete. A complete but short description would score higher.
Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 an output schema, zero parameters, and good annotations, so much is structured. However, the description is truncated and doesn't clarify what 'debug output' includes (stdout, stderr, engine messages?) or how it differs from siblings like game_get_errors and game_get_logs. For a simple tool with strong annotations, this is borderline adequate but the truncation creates a 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 no parameter meaning needs to be added. With 0 params, the baseline is 4 per the rubric. The description doesn't need to document parameter semantics 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 states 'Get the current debug output and err…' which identifies the verb (get), resource (debug output), and partially the scope (errors). However, it is truncated with an ellipsis that cuts off mid-thought, and it doesn't distinguish from siblings like game_get_errors or game_get_logs, which could overlap in scope. The name and title reinforce the 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 versus game_get_errors, game_get_logs, or other diagnostic siblings. No context about whether this is the preferred tool for general debugging output or when alternatives should be chosen. The description provides no when/when-not direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the installed Godot version
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which fully disclose the behavioral traits. The description adds no additional behavioral details beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions 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 conveys the tool's purpose with no extraneous 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?
Given the tool's simplicity (no parameters, an output schema exists, and annotations cover behavioral traits), the description is complete. It provides sufficient information for an AI agent to select and invoke 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?
There are zero parameters, so the description has no burden to explain parameter semantics. The baseline of 4 applies, and the minimal description does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the installed Godot version, with a specific verb ('Get') and resource ('Godot version'). This directly distinguishes it from sibling tools that focus on projects, scenes, or game interaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the tool is simple, mentioning that it is useful for verifying the environment before running project operations would improve it. Currently, usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve metadata about a Godot proj…
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Godot project path |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. Description adds no further behavioral details beyond the obvious 'Retrieve 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?
Very short and to the point, but truncated (ends with '…'). No unnecessary words; however, the truncation reduces 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?
For a simple read-only tool with one parameter and annotations covering safety, the description is adequate but could mention what specific metadata is returned, especially given the output schema exists.
Complex tools with many parameters or behaviors need more documentation. 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 already describes projectPath as 'Godot project path'. Description does not add any extra 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?
Description uses clear verb 'Retrieve' and resource 'metadata about a Godot project'. It distinguishes well from sibling tools like get_godot_version or game_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 get_godot_version or verify_project. No exclusions or contextual advice provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute one named hidden Godot tool…
| Name | Required | Description | Default |
|---|---|---|---|
| toolName | Yes | Required hidden tool name. | |
| arguments | No | Arguments validated against the sele… |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, readOnlyHint=false, but description only adds 'hidden' context, which is minimal. No details on side effects, permissions, or what tools are callable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single truncated sentence, lacking necessary information. Under-specification, not efficient 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 (open world, destructive, many siblings), the description fails to explain what hidden tools are, how to discover them, error behavior, or relationship to godot_catalog. Output schema exists but is not 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?
Schema coverage is 100%, but description provides no parameter details beyond what schema already offers. No added meaning for toolName or 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?
Description says 'Execute one named hidden Godot tool' but is truncated, leaving vague scope. The verb 'execute' and resource 'named hidden Godot tool' are present but insufficient to distinguish from siblings like create_scene or run_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. The description does not mention conditions, prerequisites, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search or inspect the complete Godot…
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum ranked search results. | |
| query | No | User intent, Godot concept, action,… | |
| state | No | Optional required-state filter | |
| action | Yes | Read-only catalog action | |
| detail | No | Description detail. | |
| domain | No | Optional owning-domain filter | |
| effect | No | Optional effect-scope filter | |
| backend | No | Optional execution-backend filter | |
| mutation | No | Optional mutation-behavior filter | |
| toolName | No | Required for describe. | |
| privilege | No | Optional privilege filter |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No contradiction with annotations: readOnlyHint=true, idempotentHint=true, destructiveHint=false align with a catalog/read tool. The schema itself describes action as 'Read-only catalog action', which reinforces the safe-read behavior. However, the description adds no behavioral context beyond what annotations already provide — no mention of result ranking, pagination, or how describe differs in output from search. With comprehensive annotations covering the safety profile, the description adds minimal value here.
Agents need to know what a tool does to the world before calling 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 (one truncated sentence), which could be concise — but it's incomplete rather than deliberately minimal. A truncated sentence that trails off ('the complete Godot…') is a structural defect, not concise prose. One would expect at least a full sentence articulating what the catalog contains and its two modes of 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 truncated description, the tool benefits from a 100% documented schema, 8 enum-filtered parameters, comprehensive annotations, and an output schema. The complexity of this tool (11 params, two action modes, 8 filters) is largely self-documented through the schema. However, the description could meaningfully enhance completeness by explaining the search-vs-describe distinction and how filters combine — a gap the schema alone partially fills but doesn't fully cover.
Complex tools with many parameters or behaviors need more documentation. 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 11 parameters have descriptions in the schema itself (e.g., 'Optional required-state filter', 'Required for describe'). The description adds nothing beyond what the schema documents. Baseline 3 is appropriate since the schema does the heavy lifting, and the description doesn't need to duplicate 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 reads 'Search or inspect the complete Godot…' which is truncated and incomplete. The verb is present (Search/inspect) but the resource is truncated mid-sentence ('Godot…'), making the purpose only partially clear. The name 'godot_catalog' and title 'Godot Catalog' suggest a catalog/metadata tool, and the two actions (search/describe) are visible in the schema, but the description itself fails to fully convey 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 gives no guidance on when to use this tool versus alternatives. With 19 sibling tools ranging from run_project to game_screenshot, an agent cannot tell from the description alone when to consult the catalog versus using a specific operation tool. No when-to-use, when-not-to-use, or filtering strategy is given, despite 8 filter parameters (state, domain, effect, backend, mutation, privilege) that would clearly benefit from usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the Godot project and capture ou…
| Name | Required | Description | Default |
|---|---|---|---|
| scene | No | Optional: | |
| timingMode | No | realtime follows display/VSync; | |
| projectPath | Yes | Godot project path |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true but the description adds no behavioral context beyond 'run'. The truncated phrase 'capture ou' suggests output capture but is unclear. No mention of side effects like stopping previous instances or system state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short (one truncated sentence). While concise, it sacrifices crucial information. A good description should be front-loaded but complete; this is not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 given the tool's complexity (3 parameters, destructive, output schema). It fails to explain what capturing output means, how to interpret output, or any prerequisites. Compare to sibling tools, 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?
Input schema has 100% description coverage, but descriptions are also truncated (e.g., scene: 'Optional:', timingMode: 'realtime follows display/VSync;'). The tool description does not add any additional meaning to the parameters; it is too short to explain 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?
Description begins with 'Run the Godot project', which is essentially the same as the tool name, but adds 'and capture ou…' which hints at output capture. However, it's incomplete and does not clearly distinguish from sibling tools like run_project_tests or game_* 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 on when to use this tool versus alternatives such as run_project_tests or individual game interaction tools. The description is too short to include any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover or run native, GUT, and GdU…
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Discover tests or run them | |
| failFast | No | Stop native execution after the firs… | |
| framework | No | Test framework. | |
| testPaths | No | Project-relative test files or direc… | |
| projectPath | Yes | Godot project path | |
| artifactPaths | No | Project-relative report files to ret… | |
| timeoutSeconds | No | Per-run timeout. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (no hints), and the description does not disclose behavioral traits like whether tests are run locally, if files are modified, or if a project must be open. No additional context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single truncated sentence ending with an ellipsis, under-specified and not well-structured. It fails to concisely convey the tool's function despite the schema 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 complex oneOf schema, 7 parameters, and presence of output schema, the description is severely incomplete. It does not explain the distinction between discover and run, frameworks, or return values. The schema compensates partially but the narrative is 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 description coverage is 100%, so the schema already documents parameter meanings. The description adds no extra semantic value beyond restating the action parameter. 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 'Discover or run native, GUT, and GdU…' indicating test operations, but it is truncated and lacks specificity. Without sibling context, the purpose is vague; however, the title 'Run Project Tests' helps. Score 3 as it gives basic verb+resource but with 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 guidelines on when to use this tool versus siblings like run_project or verify_project. No context on prerequisites or scenarios. The description does not address alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the currently running Godot pro…
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false but idempotentHint=false. The description doesn't contradict annotations. However, it adds no behavioral context beyond 'stops the running project' — it doesn't clarify whether stopping is reversible via run_project, whether debug output is preserved, or what happens with pending editor transactions. With sparse annotations, the description carries the burden but adds little.
Agents need to know what a tool does to the world before calling 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 — a single partial sentence. While conciseness is generally good, the truncation ('pro…') suggests incompleteness rather than intentional minimalism. A complete description could add meaningful context like effect on debug sessions or project state.
Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 state-changing operation with 0 parameters and an output schema. Given this low complexity, the description is mostly adequate. However, it's truncated mid-word, and with no annotation coverage for what 'stopping' destroys or affects (e.g., debug session state), a slightly more complete description would help the agent understand 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?
The tool has 0 parameters with schema description coverage at 100%, so there are no parameters requiring documentation. Per the rubric, 0 params earns a baseline score of 4, and with no params to describe, this 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 "Stop the currently running Godot pro…" clearly indicates a verb (Stop) and resource (the running Godot project). It distinguishes from the sibling run_project. However, the description appears truncated (ends mid-word with 'pro…'), losing potentially important context about scope or effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the purpose is implied by the name and truncated description, there's no stated context like 'use after run_project' or prerequisites (e.g., only works if a project is running), nor exclusions about 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.
Batch-check GDScript files (git-chan…
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | "changed" = git-changed .gd (default… | |
| projectPath | Yes | Godot project path | |
| scriptPaths | No | Optional explicit list of .gd paths… |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds minimal behavioral context beyond the action of 'batch-check', which is consistent with the annotations. It does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a truncated single fragment, not a complete sentence. While it starts with the core action, the truncation makes it feel incomplete and lacking clarity. It is not concise in a meaningful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 (one required), an output schema, and annotations covering safety, the description is too minimal. It does not explain the output, the behavior for the two scope options, or any prerequisites. More context is needed for effective use, especially because the text is truncated.
Complex tools with many parameters or behaviors need more documentation. 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 parameters. The description mentions 'git-chan…' which aligns with the 'scope' parameter enum value 'changed', but does not add additional semantic value 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 'Batch-check GDScript files (git-chan…' clearly indicates the verb 'batch-check' and the resource 'GDScript files'. The truncation obscures the full scope, but the inferred 'git-changed' from the schema makes the purpose fairly clear. However, it could be more explicit about batch vs. single validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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. The existence of a sibling 'validate_script' hints at a batch vs. single differentiation, but the description provides no direct usage guidance or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run bounded assertions and capture e…
| Name | Required | Description | Default |
|---|---|---|---|
| scene | No | Optional scene to run | |
| teardown | No | Stop the project after verification. | |
| assertions | No | Bounded assertions evaluated against… | |
| waitFrames | No | Frames to wait before assertions. | |
| projectPath | Yes | Godot project path | |
| captureScreenshot | No | Capture a screenshot and return its… |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | No | |
| meta | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so description must disclose behavior. The truncated description only mentions running assertions and capturing something, but does not clarify side effects, permissions, or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single truncated sentence, which is under-specification rather than conciseness. It fails to provide a complete, well-structured overview.
Shorter descriptions cost fewer tokens and are easier for agents to parse. 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, assertions array) and existing output schema, the description is far too brief to inform an agent about the tool's full capabilities and 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 coverage is 100%, so the baseline is 3. The description adds minimal meaning beyond the schema; it does not elaborate on parameters like assertions or teardown.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description fragment 'Run bounded assertions and capture e…' vaguely indicates running assertions on a project, but it is incomplete and uses jargon. Among sibling tools like run_project_tests or read_scene, this tool's specific role is not clearly distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 verify_project versus siblings like run_project_tests or read_scene. The description lacks 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.0.0attach_scriptcreate_projectcreate_scenecreate_scripteditor_controleditor_sessiongame_clickgame_get_node_infogame_key_holdgame_key_pressgame_key_releaseget_debug_outputgodot_catalog1 field changedInput schema / properties / backend / enumPrevious value: -[
- "process",
- "subprocess",
- "authoring-session",
- "runtime",
- "runtime-buffer",
- "godot-cli",
- "local"
-]New value: +[
+ "process",
+ "subprocess",
+ "runtime",
+ "runtime-buffer",
+ "godot-cli",
+ "local"
+]manage_input_mapmodify_project_settingsmodify_scene_noderead_project_settingsread_sceneremove_scene_nodesave_sceneset_main_scenestop_projectvalidate_scriptwrite_filev1.1.5game_get_node_infogame_key_holdgame_key_pressgame_scenariogame_screenshotgame_wait_untilget_godot_versiongodot_calllaunch_editorread_scenerun_projectrun_project_testsstop_projectv1.1.4add_nodeattach_scriptcreate_projectcreate_scripteditor_controleditor_transactiongame_clickgame_get_errorsgame_get_logsgame_get_node_infogame_get_scene_treegame_get_uigame_key_releasegame_screenshotget_debug_outputget_godot_versiongodot_calllaunch_editormanage_input_mapmodify_project_settings3 fields changedInput schema / properties / value / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ }
+]Input schema / properties / value / descriptionPrevious value: -"Value to set (as a string, will be w…"New value: +"JSON string, number, or boolean."Input schema / properties / value / typeRemoved value: -"string"modify_scene_noderead_project_settingsread_sceneremove_scene_noderun_project_testsset_main_scenevalidate_scriptvalidate_scriptswrite_filev1.1.2add_node7 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / nodeType / descriptionPrevious value: -"Type of node to add (e.g., Sprite2D, CollisionShape2D)"New value: +"Type of node to add (e.g., Sprite2D,…"Input schema / properties / parentNodePath / descriptionPrevious value: -"Path to the parent node (e.g., \"root\" or \"root/Player\")"New value: +"Path to the parent node (e.g., \"root…"Input schema / properties / properties / additionalPropertiesAdded value: +trueInput schema / properties / properties / descriptionPrevious value: -"Optional properties to set on the node"New value: +"Optional properties to set on the no…"Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "oneOf": [
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": true
+ }
+ },
+ "required": [
+ "data"
+ ]
+ },
+ {
+ "not": {
+ "required": [
+ "data"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": false
+ }
+ },
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "data": {},
+ "error": {
+ "type": "object"
+ },
+ "meta": {
+ "type": "object"
+ },
+ "ok": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "meta"
+ ],
+ "type": "object"
+}attach_scriptcreate_projectcreate_scene5 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / rootNodeType / descriptionPrevious value: -"Type of the root node (e.g., Node2D, Node3D)"New value: +"Type of the root node (e.g., Node2D,…"Input schema / properties / scenePath / descriptionPrevious value: -"Path where the scene file will be saved (relative to project)"New value: +"Path where the scene file will be sa…"Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "oneOf": [
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": true
+ }
+ },
+ "required": [
+ "data"
+ ]
+ },
+ {
+ "not": {
+ "required": [
+ "data"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": false
+ }
+ },
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "data": {},
+ "error": {
+ "type": "object"
+ },
+ "meta": {
+ "type": "object"
+ },
+ "ok": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "meta"
+ ],
+ "type": "object"
+}create_scripteditor_controleditor_sessioneditor_transactiongame_clickgame_get_errorsgame_get_logsgame_get_node_infogame_get_scene_treegame_get_uigame_key_pressgame_key_releasegame_scenariogame_screenshot4 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / retainArtifact / descriptionPrevious value: -"Retain a PNG in the system temp artifact directory. Default: false"New value: +"Retain a PNG in the system temp arti…"Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "oneOf": [
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": true
+ }
+ },
+ "required": [
+ "data"
+ ]
+ },
+ {
+ "not": {
+ "required": [
+ "data"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": false
+ }
+ },
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "data": {},
+ "error": {
+ "type": "object"
+ },
+ "meta": {
+ "type": "object"
+ },
+ "ok": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "meta"
+ ],
+ "type": "object"
+}game_wait_untilget_debug_output3 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "oneOf": [
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": true
+ }
+ },
+ "required": [
+ "data"
+ ]
+ },
+ {
+ "not": {
+ "required": [
+ "data"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": false
+ }
+ },
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "data": {},
+ "error": {
+ "type": "object"
+ },
+ "meta": {
+ "type": "object"
+ },
+ "ok": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "meta"
+ ],
+ "type": "object"
+}get_godot_version3 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "oneOf": [
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": true
+ }
+ },
+ "required": [
+ "data"
+ ]
+ },
+ {
+ "not": {
+ "required": [
+ "data"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": false
+ }
+ },
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "data": {},
+ "error": {
+ "type": "object"
+ },
+ "meta": {
+ "type": "object"
+ },
+ "ok": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "meta"
+ ],
+ "type": "object"
+}get_project_info3 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "oneOf": [
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": true
+ }
+ },
+ "required": [
+ "data"
+ ]
+ },
+ {
+ "not": {
+ "required": [
+ "data"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": false
+ }
+ },
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "data": {},
+ "error": {
+ "type": "object"
+ },
+ "meta": {
+ "type": "object"
+ },
+ "ok": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "meta"
+ ],
+ "type": "object"
+}godot_callgodot_cataloggodot_toolslaunch_editormanage_input_mapmodify_project_settings6 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / key / descriptionPrevious value: -"Setting key (e.g., \"run/main_scene\", \"window/size/viewport_width\")"New value: +"Setting key (e.g., \"run/main_scene\",…"Input schema / properties / section / descriptionPrevious value: -"Section in project.godot (e.g., \"application\", \"display\", \"rendering\")"New value: +"Section in project.godot (e.g., \"app…"Input schema / properties / value / descriptionPrevious value: -"Value to set (as a string, will be written as-is)"New value: +"Value to set (as a string, will be w…"Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "oneOf": [
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": true
+ }
+ },
+ "required": [
+ "data"
+ ]
+ },
+ {
+ "not": {
+ "required": [
+ "data"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": false
+ }
+ },
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "data": {},
+ "error": {
+ "type": "object"
+ },
+ "meta": {
+ "type": "object"
+ },
+ "ok": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "meta"
+ ],
+ "type": "object"
+}modify_scene_noderead_fileread_project_settingsread_scene11 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / authoredOnlyAdded value: +{
+ "description": "Return authored storage properties o…",
+ "type": "boolean"
+}Input schema / properties / detailAdded value: +{
+ "description": "Explicit detail mode;",
+ "enum": [
+ "compact",
+ "authored",
+ "full"
+ ],
+ "type": "string"
+}Input schema / properties / includeDefaultsAdded value: +{
+ "description": "Include properties whose values stil…",
+ "type": "boolean"
+}Input schema / properties / includeResourcesAdded value: +{
+ "description": "Include resource-valued properties.",
+ "type": "boolean"
+}Input schema / properties / maxDepthAdded value: +{
+ "description": "Maximum child depth below the select…",
+ "maximum": 64,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / nodePathAdded value: +{
+ "description": "Optional scene-relative subtree path…",
+ "type": "string"
+}Input schema / properties / propertyNamesAdded value: +{
+ "description": "Optional property allowlist",
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 128,
+ "type": "array"
+}Input schema / properties / responseLimitAdded value: +{
+ "description": "Explicit serialized response byte li…",
+ "maximum": 1048576,
+ "minimum": 1024,
+ "type": "integer"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "oneOf": [
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": true
+ }
+ },
+ "required": [
+ "data"
+ ]
+ },
+ {
+ "not": {
+ "required": [
+ "data"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": false
+ }
+ },
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "data": {},
+ "error": {
+ "type": "object"
+ },
+ "meta": {
+ "type": "object"
+ },
+ "ok": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "meta"
+ ],
+ "type": "object"
+}remove_scene_noderun_projectrun_project_tests9 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / oneOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "description": "Allowed option 1",
+ "properties": {
+ "action": {
+ "const": "discover"
+ },
+ "artifactPaths": {
+ "not": {}
+ },
+ "failFast": {
+ "not": {}
+ },
+ "timeoutSeconds": {
+ "not": {}
+ }
+ },
+ "required": [
+ "action"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": true,
+ "description": "Allowed option 2",
+ "properties": {
+ "action": {
+ "const": "run"
+ }
+ },
+ "required": [
+ "action"
+ ],
+ "type": "object"
+ }
+]Input schema / properties / artifactPaths / descriptionPrevious value: -"Project-relative report files to return as artifact metadata"New value: +"Project-relative report files to ret…"Input schema / properties / failFast / descriptionPrevious value: -"Stop native execution after the first failed file. Default: false"New value: +"Stop native execution after the firs…"Input schema / properties / framework / descriptionPrevious value: -"Test framework. Default: auto"New value: +"Test framework."Input schema / properties / testPaths / descriptionPrevious value: -"Project-relative test files or directories"New value: +"Project-relative test files or direc…"Input schema / properties / timeoutSeconds / descriptionPrevious value: -"Per-run timeout. Default: 60"New value: +"Per-run timeout."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "oneOf": [
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": true
+ }
+ },
+ "required": [
+ "data"
+ ]
+ },
+ {
+ "not": {
+ "required": [
+ "data"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": false
+ }
+ },
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "data": {},
+ "error": {
+ "type": "object"
+ },
+ "meta": {
+ "type": "object"
+ },
+ "ok": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "meta"
+ ],
+ "type": "object"
+}save_scene4 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / newPath / descriptionPrevious value: -"Optional: New path to save the scene to (for creating variants)"New value: +"Optional:"Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "oneOf": [
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": true
+ }
+ },
+ "required": [
+ "data"
+ ]
+ },
+ {
+ "not": {
+ "required": [
+ "data"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": false
+ }
+ },
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "data": {},
+ "error": {
+ "type": "object"
+ },
+ "meta": {
+ "type": "object"
+ },
+ "ok": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "meta"
+ ],
+ "type": "object"
+}set_main_scenestop_project3 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "oneOf": [
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": true
+ }
+ },
+ "required": [
+ "data"
+ ]
+ },
+ {
+ "not": {
+ "required": [
+ "data"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": false
+ }
+ },
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "data": {},
+ "error": {
+ "type": "object"
+ },
+ "meta": {
+ "type": "object"
+ },
+ "ok": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "meta"
+ ],
+ "type": "object"
+}validate_scriptvalidate_scriptsverify_project13 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / assertions / descriptionPrevious value: -"Bounded assertions evaluated against the running game"New value: +"Bounded assertions evaluated against…"Input schema / properties / assertions / items / additionalPropertiesAdded value: +falseInput schema / properties / assertions / items / properties / count / descriptionRemoved value: -"Expected group member count"Input schema / properties / assertions / items / properties / group / descriptionRemoved value: -"Group name for group_count"Input schema / properties / assertions / items / properties / kind / descriptionRemoved value: -"Assertion kind"Input schema / properties / assertions / items / properties / nodePath / descriptionRemoved value: -"Node path for node_exists"Input schema / properties / assertions / items / properties / text / descriptionRemoved value: -"Required output substring for log_contains"Input schema / properties / captureScreenshot / descriptionPrevious value: -"Capture a screenshot and return its SHA-256 digest. Default: false"New value: +"Capture a screenshot and return its…"Input schema / properties / teardown / descriptionPrevious value: -"Stop the project after verification. Default: true"New value: +"Stop the project after verification."Input schema / properties / waitFrames / descriptionPrevious value: -"Frames to wait before assertions. Default: 2"New value: +"Frames to wait before assertions."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "oneOf": [
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": true
+ }
+ },
+ "required": [
+ "data"
+ ]
+ },
+ {
+ "not": {
+ "required": [
+ "data"
+ ]
+ },
+ "properties": {
+ "ok": {
+ "const": false
+ }
+ },
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "data": {},
+ "error": {
+ "type": "object"
+ },
+ "meta": {
+ "type": "object"
+ },
+ "ok": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "meta"
+ ],
+ "type": "object"
+}write_filev1.0.2editor_sessioneditor_transactiongame_scenariogame_screenshot1 field changedInput schema / properties / retainArtifactAdded value: +{
+ "description": "Retain a PNG in the system temp artifact directory. Default: false",
+ "type": "boolean"
+}game_waitgame_wait_untillist_project_fileslist_projectsrun_project1 field changedInput schema / properties / timingModeAdded value: +{
+ "description": "realtime follows display/VSync; deterministic uses fixed 60 FPS. Default: realtime",
+ "enum": [
+ "realtime",
+ "deterministic"
+ ],
+ "type": "string"
+}v1.0.0add_nodeattach_scriptcreate_projectcreate_scenecreate_scripteditor_controlgame_clickgame_get_errorsgame_get_logsgame_get_node_infogame_get_scene_treegame_get_uigame_key_pressgame_key_releasegame_screenshotgame_waitget_debug_outputget_godot_versionget_project_infogodot_toolslaunch_editorlist_project_fileslist_projectsmanage_input_mapmodify_project_settingsmodify_scene_noderead_fileread_project_settingsread_sceneremove_scene_noderun_projectrun_project_testssave_sceneset_main_scenestop_projectvalidate_scriptvalidate_scriptsverify_projectwrite_fileMost tools are clearly distinct by domain (editor vs running game vs inspect), but get_debug_output, game_get_errors, game_get_logs, and game_get_debug_output-type overlap in capturing output, creating ambiguity. game_scenario and game_wait_until have identical placeholder descriptions ('Property waits need reflection'), making them indistinguishable.
The naming is mixed: most use verb_noun snake_case (get_godot_version, run_project), but several 'game_*', 'godot_*', and 'editor_*' prefixes follow different conventions, and 'verify_project' vs 'run_project_tests' use similar verb phrases for different actions. The game_* group is consistent internally but the prefixes across the server are arbitrary.
20 tools is on the high end but defensible for the apparent scope of controlling a Godot editor session, running tests, and inspecting a live game. It's slightly heavy, likely bordering the 16-25 range, but each tool maps to a plausible action in the workflow.
The surface covers the full lifecycle well: editor control (session, transaction) is paired with run/stop project, and inspection tools (scene tree, UI, node info, screenshot) cover runtime diagnosis. Minor gaps exist—there's no explicit save/closing_session tool, and debug/log/error retrieval is spread awkwardly across get_debug_output, game_get_errors, and game_get_logs—but core workflows are covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
One MCP tool for verified AI-agent outcomes with success-only charging.
MCP-first toolbox for agents: KV storage, auth, queue, and utility tools. Free in early access.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/beremaran/godot-agent-loop'
If you have feedback or need assistance with the MCP directory API, please join our Discord server