Skip to main content
Glama

logs_read

Read recent log lines from Godot editor, plugin, or running game to diagnose issues 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 provided, the description carries the full burden and does so admirably. It discloses buffer sizes (500/2000), retention across runs, run_id semantics, stale_run_id behavior, editor cursor mechanics (since_cursor supersedes offset), boot-time parse errors not captured, editor_errors_hint logic, and the effect of include_details. This is exceptionally transparent.

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 section earns its place: source breakdowns, buffer sizes, run/cursor handling, and edge cases are all relevant. It is well-structured with clear labels. A slight deduction for length; it could potentially be tightened without losing critical details, but it avoids fluff.

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 tool is complex with 7 parameters, multiple sources, and an output schema, but the description covers all aspects: sources, return fields (run_id, current_run_id, game_status, dropped_count, etc.), edge cases (boot-time errors, plugin-enable timing), and tail patterns. It is fully complete for a tool of this complexity, even with an output schema present.

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 already provides 100% coverage with descriptions for all 7 parameters, the tool description goes far beyond the schema. It explains the intricate relationships between parameters, such as since_run_id reading prior runs, current_run_id vs run_id, since_cursor superseding offset, and the meaning of include_details. This adds substantial semantic value beyond the schema's field-level 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 opens with a specific verb and resource: 'Read recent log lines from the Godot editor, plugin, or running game.' It immediately distinguishes the tool by enumerating four sources (plugin, game, editor, all) and their purposes, which clearly separates it from sibling tools that manage scenes, scripts, nodes, etc.

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 offers concrete guidance on when to use each source, 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 polling patterns for game and editor logs. However, it doesn't explicitly state when *not* to use this tool or name alternative tools, so it falls short of a 5.

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