Skip to main content
Glama

logs_read

Retrieve recent log lines from Godot editor, plugin, or game runs, with filtering by source and pagination.

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 provided, the description carries the full burden, and it delivers extensively: buffer sizes (500/2000), retention across runs, boot-time parse errors never included, editor_errors_count/hint semantics, filtering rules, addons dropped, cursor superseding offset, and truncation behavior. This is exemplary behavioral disclosure.

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 every block earns its place given the tool's complexity and the absence of annotations. It is front-loaded with a one-sentence purpose, then structured into source categories and tail-pattern guidance. It is dense rather than padded, though slightly longer than strictly necessary.

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?

The description covers return-field semantics (run_id, current_run_id, stale_run_id, dropped_count, editor_errors_hint), source-specific entry shapes, cursor/run lifecycle, edge cases like lost scripts, and polling patterns. Combined with the existing output schema, an agent has everything needed to invoke and interpret results correctly.

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 the schema covers all 7 parameters (100%), the description adds substantial meaning beyond the schema: since_cursor supersedes offset, since_run_id reads retained prior runs, include_details returns Errors-tab metadata, and source determines entry shape. It transforms the parameters into a coherent replay/pagination model.

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 specific verb and resource: 'Read recent log lines from the Godot editor, plugin, or running game.' It then enumerates the exact source modes (plugin/game/editor/all) and the resource form, making the tool's scope unambiguous and clearly distinct from the unrelated 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 Guidelines5/5

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

The description gives 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.' It also explains the default source, when to use since_run_id versus since_cursor, and how to poll game logs with offset and run_id. This is far beyond minimal guidance.

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