Skip to main content
Glama

Logs Read

logs_read

Retrieve recent log lines from Godot editor, plugin, or running game to debug 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. 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 and 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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.1.4
  2. Removedv3.0.7
  3. First observedv2.9.1

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations to lean on, the description fully carries behavioral disclosure: buffer sizes, retention across runs, run_id/cursor semantics, truncation behavior, boot-time error caveats, filtering to .gd/.cs, and the meaning of include_details. This is exceptionally transparent about edge cases and response fields.

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 the complexity of four sources plus cursor/run tracking justifies most of the length. It is logically organized by source and then by tail pattern, though some repetition of run_id/current_run_id/stale_run_id across sections could be trimmed.

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 high complexity, the description covers every parameter, source behavior, retention rule, edge case, and response field relevant to calling it correctly. An output schema exists, so not over-explaining return types is appropriate; the narrative adds the operational context an agent needs.

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?

Though the schema already covers all parameters, the description adds substantial meaning: buffer sizes per source, how since_run_id and since_cursor interact with offset, when truncated appears, and what include_details actually enriches. Only session_id is not elaborated beyond the schema, but the overall enrichment is extensive.

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?

Opens with a specific verb and resource ('Read recent log lines from the Godot editor, plugin, or running game') and further enumerates four distinct sources. No sibling tool covers log reading, so there is no risk of confusion with the listed alternatives.

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 guidance on when to prefer each source, including the editor-source trigger ('when the editor Output or Debugger Errors panel shows red/yellow rows but other sources turned up nothing'). It also explains the default source and gives concrete tail/polling patterns for game and editor logs.

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