Skip to main content
Glama
robertobendi

WazziCode Godot

by robertobendi

editor_manage

Manage a live Godot editor: retrieve editor state, selection, and performance; clear logs; quit; and evaluate GDScript in the running game.

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, or the game is parked in a debugger break (stop and relaunch); EVAL_HUNG for a 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). 'await' only progresses while the game window is focused.

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
NameRequiredDescriptionDefault
opYes
paramsNo
session_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

With no annotations, the description takes full responsibility for behavioral disclosure, and it delivers by explaining error codes for game_eval, the await focus behavior, return counts for logs_clear, and the replacement semantics of selection_set. It could add a bit more about side effects or prerequisites, but overall it is very transparent.

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

Conciseness5/5

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

The description is lengthy but well structured with a summary, resource forms, and bullet-pointed ops, with every line containing actionable information. It is front-loaded with the purpose and avoids unnecessary verbosity.

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

Completeness5/5

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

It covers all seven ops, their parameters, return values, error handling, and call-shape variations, and the presence of an output schema means return values don't need over-explanation. The description leaves little room for ambiguity.

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?

The schema has no property descriptions, but the description thoroughly documents each op's parameters within the op listings, including the canonical call shape and flat-parameter compatibility alias. This fully compensates for the schema gap and gives the agent clear parameter meaning.

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

Purpose5/5

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

The description opens with a clear summary of covered operations and then lists seven specific ops with their purposes, making it easy to understand what the tool does. It distinctly covers editor state, selection, performance monitoring, quit, log clearing, and game eval, setting it apart from sibling tools.

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?

The description mentions 'Resource forms (prefer for active-session reads)' and describes each op's intended scenario, such as passing monitor names to filter and opting into debugger errors. Though it doesn't explicitly compare to sibling tools, the context is clear enough to determine when to use each operation.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/robertobendi/wazzicode-godot'

If you have feedback or need assistance with the MCP directory API, please join our Discord server