Godot MCP

Overview Schema Source Related Servers Discussions Admin

editor_manage

Control Godot editor sessions: inspect state/selection/performance, clear logs, quit, and run GDScript in the live game for autonomous development.

Instructions

Editor selection, performance monitors, quit, log clearing, game eval.

Resource forms (prefer for active-session reads): godot://editor/state, godot://selection/current, godot://performance

Ops: • state() Editor version, project name, current scene, readiness, play state. • selection_get() Currently selected node paths in the editor. • selection_set(paths) Replace the selection with the given list of scene paths. • monitors_get(monitors=None) Performance singleton values (FPS, memory, draw calls, etc.). Pass a list of monitor names to filter; None returns everything. • quit() Gracefully quit the Godot editor on next frame. • logs_clear(clear_debugger_errors=False) Clear the MCP log buffer. Returns cleared_count. Pass clear_debugger_errors=True to also clear the Debugger dock's visible Errors-tab rows (user-facing UI, so opt-in only); the response then includes debugger_errors_cleared. • game_eval(code) Execute GDScript in the running game with return values. Uses 'await' so user code can await internally. Errors return fast and actionable: EVAL_COMPILE_ERROR for a syntax/parse error, EVAL_RUNTIME_ERROR (with the real message + line) for a runtime error; EVAL_GAME_NOT_READY if the game can't service evals — still launching (retry once it's up), the _mcp_game_helper autoload is missing/disabled, its main loop is not advancing (focus the game), or its debugger session closed; EVAL_HUNG for a live game's genuine infinite loop / never-firing await; EVAL_RESULT_TOO_LARGE if the returned value serializes past the debugger channel's capacity (return a smaller slice).

Canonical call shape: {"op": "<verb>", "params": {...}}. Flat op parameters are accepted as a compatibility alias when the client transmits them; op and session_id remain top-level.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`op`	Yes
`params`	No
`session_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv4.1.0Oct 1, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden—and it does: it discloses that quit() is graceful and next-frame, logs_clear returns counts and only clears the visible Debugger errors when explicitly requested, selection_set replaces the selection, and game_eval enumerates fast, actionable error codes including hung and oversized results. This is high-value behavioral disclosure beyond what the generic schema could convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but organized with a summary, resource-form note, bulleted ops, and a canonical call shape. Each section adds needed information; it is front-loaded and scannable, though a little more trimming around resource-form vs op duplication would tighten it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a seven-op dispatcher with no annotations and a generic input schema, the description covers call shape, operation semantics, defaults, and error behavior thoroughly; an output schema exists so return-value details need not be repeated. It still leaves some contextual gaps such as session_id usage and explicit prerequisites for selection_set, but nothing critical for basic invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and params is only a free-form object, so the description is the only source of parameter meaning. It defines every operation signature, defaults, value types, and effects (paths list, monitors list or None, clear_debugger_errors boolean, code string), fully compensating for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a compact enumeration of the tool's domains (selection, performance monitors, quit, log clearing, game eval) and then names each operation with a clear verb and target. It does not explicitly differentiate itself from sibling tools like editor_state or logs_read, so it stops short of a full 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides concrete routing cues: resource forms are preferred for active-session reads, logs_clear requires opt-in for the user-facing Debugger dock, and game_eval explains retry conditions for EVAL_GAME_NOT_READY. However, it never explicitly names sibling tools or states 'use this tool when X instead of Y', leaving some alternation to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.