Skip to main content
Glama

logs_read

Retrieve recent log entries from the Godot editor, plugin, or running game to identify script errors, game output, and plugin events.

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 provided, the description fully carries the burden of behavioral disclosure. It explains buffer sizes (500 for plugin, 2000 for game), retention across runs, cursor mechanics, game helper requirements, and edge cases like editor_errors_count. It is exceptionally transparent about what the tool does and its limitations.

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 every sentence earns its place by adding unique, necessary detail. It is front-loaded with the core purpose and resource form, then organized by source with separate paragraphs. Despite its density, it remains well-structured and efficient, with no redundant information.

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?

Given the tool's complexity (multiple sources, tail patterns, and an output schema), the description is highly complete. It explains buffer limits, run_id retention, cursor behavior, and even edge cases like boot-time errors and stale runs. It references output fields (e.g., run_id, current_run_id) adequately, and the presence of the output schema reduces the need for further detail on return values.

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?

Despite 100% schema description coverage, the description adds significant value beyond the schema. For example, it explains the tail pattern for 'since_cursor' and 'since_run_id', how 'include_details' affects output, and the relationship between 'offset' and 'since_cursor'. This goes far beyond the schema's brief parameter descriptions.

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 clearly states 'Read recent log lines from the Godot editor, plugin, or running game.' It specifies the resource form and distinct sources, each with a clear purpose and differentiation. The verb 'read' and the resource 'logs' directly convey the tool's function, making it unambiguous.

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 provides detailed guidance on when to use each source (e.g., 'plugin' for MCP traffic, 'game' for stdout/stderr, 'editor' for script errors) and how to tail logs (using cursors and run IDs). While it implicitly suggests when to use each, it lacks explicit 'when not to use' or mention of alternative tools, though no direct log-related siblings exist.

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/hi-godot/godot-ai'

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