Skip to main content
Glama

Read a file from the server

ptero_read_file
Read-onlyIdempotent

Read text files from a Pterodactyl game server to inspect logs, configs, and crash reports, returning content and file size while refusing oversized files.

Instructions

Read a text file from the game server, relative to the server root. Returns the contents plus the file size.

THIS IS THE WAY TO GET FULL BOOT-TIME OUTPUT. Read logs/latest.log. The live console (ptero_get_console_log) only keeps roughly the last 150 lines, so within an hour of boot the plugin startup lines — which port Geyser bound to, which plugin failed to load, why the world took so long — have already rolled out of it. logs/latest.log has the whole history of the current boot; older boots are gzipped in logs/ as <date>-<n>.log.gz (this tool cannot decompress those). If a question is about what happened at startup, read the log file — do not answer from the console buffer and do not assume the buffer is complete.

Other good uses: plugin configuration (plugins/Geyser-Spigot/config.yml), server.properties, eula.txt, crash reports in crash-reports/.

Size guard: the tool first checks the size in the directory listing and REFUSES to fetch anything larger than max_bytes (default from PTERODACTYL_MAX_READ_BYTES, hard cap 4 MiB, which is the panel's own limit). It never partially downloads a huge file. head_lines / tail_lines trim AFTER the download, so they do not help you get past the size guard — the panel has no range-read endpoint.

Binary files (jars, region files, images) are not readable this way; use ptero_list_files to inspect them by size and date instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesFile path relative to the server root, e.g. `logs/latest.log` or `plugins/Geyser-Spigot/config.yml`. Leading slashes are optional. Use ptero_list_files if you are unsure of the exact path.
serverNoServer short identifier (e.g. 1a2b3c4d). Omit to use PTERODACTYL_DEFAULT_SERVER. Call ptero_list_servers to discover valid identifiers.
max_bytesNoRefuse to read a file larger than this many bytes. Defaults to PTERODACTYL_MAX_READ_BYTES. Hard-capped at 4194304 (4 MiB), the panel's own edit-size limit. Raise it deliberately when a refusal tells you the file is bigger than the default but still within the cap.
head_linesNoReturn only the first N lines. Applied after the full file is fetched. Mutually exclusive with tail_lines.
tail_linesNoReturn only the last N lines. Applied after the full file is fetched, so it reduces context, not download size. Mutually exclusive with head_lines. This is usually what you want for `logs/latest.log`.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesServer-relative path that was read.
serverYes
contentYesFile contents, after any head_lines/tail_lines trimming. Verbatim otherwise.
size_bytesYesFull size of the file on disk, per the directory listing.
truncated_toYesnull when the whole file is returned. Otherwise describes the trim that was applied, e.g. "last 200 of 5310 lines".
lines_returnedYesNumber of lines in `content`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses key behaviors: the size guard that refuses oversized files, the fact that head/tail trimming happens after download (so it doesn't bypass the size limit), and the inability to read binary files. These are critical operational details not visible in the annotations or schema.

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 thorough yet organized with clear paragraphs and bullet-like separation. It front-loads the most critical use case (boot logs) and then covers other uses, followed by limitations. No unnecessary filler; every sentence adds value, making it easy for an agent to parse quickly.

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 is comprehensive for a complex tool with an output schema and rich annotations. It covers key use cases, critical limitations, and operational constraints. The presence of an output schema means return values are already documented, so the description focuses on when and how to use the tool, which it does fully.

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?

Even though the input schema already covers all parameters at 100%, the description adds substantial semantic context. It explains the default and hard cap for max_bytes, the relationship between head_lines and tail_lines (mutually exclusive, post-download), and practical advice like using tail_lines for logs. This goes well beyond the schema 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 specifies the action ('Read a text file from the game server') and the resource (file relative to server root), with concrete examples. It distinguishes itself from siblings by emphasizing that this is the definitive method for retrieving full boot logs, unlike the console log tool.

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 provides explicit when-to-use guidance, including a critical scenario (boot-time diagnostics) and names the alternative tool (ptero_get_console_log) with a concrete reason to prefer this one. It also lists other common use cases (config files, crash reports) and notes when not to use it (binary files, large files).

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