Skip to main content
Glama
robertobendi

WazziCode Godot

by robertobendi

logs_read

Retrieve recent log lines from the Godot editor, plugin, or running game to diagnose errors and monitor activity.

Instructions

Read recent log lines from the Godot editor, plugin, or running game.

Resource form: godot://logs/recent — prefer for active-session reads.

Sources:

  • "plugin" (default): MCP plugin recv/send/event traffic. Buffer 500.

  • "game": stdout/stderr/push_error/push_warning from playing game via _mcp_game_helper autoload (Godot 4.5+). Buffer 2000, with lines retained across runs and tagged by run_id. Default reads return current-run lines only; pass since_run_id from an earlier response to read that prior run. Entries: {source, level, text, run_id}; response carries run_id, current_run_id, game_status, helper_live, session_active, dropped_count, stale_run_id. helper_live and session_active mirror the same fields inside game_status; is_running is retained as a compatibility alias of session_active. Boot-time parse/load errors fire before the game helper's logger attaches, so they are NEVER in this buffer; when editor-side errors were recorded during the current run the response adds editor_errors_count and editor_errors_hint pointing at source="editor" — treat a clean game log carrying that hint as a run that lost scripts, not a clean launch.

  • "editor": editor-process script errors and the Debugger dock's visible Errors-tab rows — parse errors, GDScript reload warnings, @tool/EditorPlugin runtime errors, push_error/push_warning. Logger-backed entries require Godot 4.5+; Errors-tab rows are read from the editor UI when available. Use when the editor Output or Debugger Errors panel shows red/yellow rows but other sources turned up nothing. Buffer 500 for logger-backed entries; Debugger rows are live UI state. Entries: {source, level, text, path, line, function}. Filtered to .gd/.cs in the user project for Logger-backed entries; addons/godot_ai/ dropped. Logger entries fired before plugin enable are not captured.

  • "all": plugin → editor → game lines (with source per entry).

Tail pattern: for game logs, poll the current run with offset=N and keep the returned run_id. current_run_id identifies the active run; run_id identifies the run being read. Passing since_run_id=old_run_id reads retained lines for that prior run, and stale_run_id: true means the requested run is not the current run. For editor logs, read once to capture next_cursor and pass it back as since_cursor on later calls. since_cursor reads Logger-backed editor entries only; live Debugger Errors-tab rows are included in regular source="editor" reads but do not have stable cursors. When since_cursor is set, it supersedes offset. truncated: true means older entries fell out of the ring before the poll; continue from the returned next_cursor and treat oldest_cursor as the earliest retained sequence. Set include_details=True for Errors-tab style metadata on game/editor entries: original code/rationale, error type, resolved source, and stack frames. Default false preserves compact responses.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoMax lines to return. Default 50.
offsetNoLines to skip. Default 0.
sourceNo"plugin" | "game" | "editor" | "all". Default "plugin".plugin
session_idNoOptional Godot session to target. Empty = active session.
since_cursorNoEditor-log cursor from a previous source="editor" response.
since_run_idNoGame-log run id from a previous response; reads that retained run instead of the current run.
include_detailsNoInclude rich error metadata for game/editor entries.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description fully carries the burden and delivers richly. It discloses buffer sizes, retention across runs, run_id semantics, cursor mechanics (superseding offset), truncation, boot-time parse errors never being captured, editor_errors_hint behavior, source filtering, and details on include_details. This level of disclosure is exemplary.

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 justified for the tool's complexity. It is front-loaded with the core purpose and structured by source types and tail patterns. Every section earns its place, though some repetition (e.g., run_id explanations) could be tightened. Still, it remains organized and scannable.

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?

Despite having an output schema, the description goes beyond it by detailing return fields (run_id, current_run_id, game_status, truncated, next_cursor, editor_errors_count, etc.), explaining edge cases (stale_run_id, boot-time errors), and specifying behavior for prior runs. For a tool with this many parameters and sources, the description is exceptionally complete.

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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema. It explains each source's semantics, since_run_id retention behavior, since_cursor working details and precedence, and include_details purpose. The schema only says 'optional' and defaults; the description turns these into practical usage knowledge.

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 'Read recent log lines from the Godot editor, plugin, or running game.' This uses a specific verb ('Read'), names the resource ('log lines' from distinct sources), and clarifies scope. The resource form and source breakdown further distinguish it from sibling tools, none of which target log reading.

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

Usage Guidelines5/5

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

Provides explicit when-to-use guidance, e.g., 'Use when the editor Output or Debugger Errors panel shows red/yellow rows but other sources turned up nothing' for the editor source. It also explains the tail pattern (poll with offset, use run_id/cursor) and when to prefer the resource form ('prefer for active-session reads'). This goes beyond vague context to actionable selection criteria.

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