tmodloader-mcp

Overview Schema Source Related Servers Discussions Admin

Read what a log has gained

log_since

Read-only

Retrieve log entries appended since the previous call, with offset-based resume, rotation detection via fingerprint, and optional case-insensitive filtering.

Instructions

Only what a log has gained since you last looked.

Args: name: A log filename from log_files. offset: The next_offset from your previous call, or 0 to start at the beginning. BYTES, not lines — a line count is not a resume point, because the number of lines you have read is not where the file continues. contains: Case-insensitive filter, applied to the new lines only. fingerprint: The previous call's fingerprint, or omit on the first. It is how a rotation is detected when the NEW log has already outgrown your offset — without it that case reads as a quiet continuation, silently skipping the head of the new run.

NOT A LIVE TAIL, and it cannot be one. Tools here are synchronous and a game session is process-global state, so a launch blocking for five minutes is not something another call watches from the side. What this buys is the read between calls: logs re-reads a file that grows all run, and this returns the new part.

restarted is the field to check. tModLoader ZIPS the previous run's logs and starts fresh, so an offset from a run that has since rotated points past the end of a now-shorter file. Reading there would report an empty log forever, which looks exactly like a quiet game rather than like a log that restarted underneath you. When that happens the read begins again at zero and says so, because handing back the whole file is only correct if the caller is told why.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes
`offset`	No
`contains`	No
`fingerprint`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`lines`	Yes
`restarted`	Yes
`truncated`	Yes
`fingerprint`	Yes
`next_offset`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.3Sep 17, 2026

TDQS

A5/5.0

Behavior5/5

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

The annotations declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral detail: offset is in bytes, fingerprints detect rotation, and on rotation the read restarts at zero while signaling via `restarted`. It also warns about the failure mode of quiet continuation. This is far beyond the annotation baseline.

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 front-loaded with the core meaning, then structured into argument definitions and behavioral caveats. Although it is long, every sentence adds needed context about byte offsets, rotation, or live-tail impossibility. No sentence merely repeats the schema or annotations.

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?

For a tool with four parameters, rotation-sensitive behavior, and a non-obvious resume protocol, the description covers all necessary calling details: how to resume, how filtering works, how rotation is detected, and which return field to check. The output schema covers return structure, so its absence from the description is not a gap.

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?

Schema description coverage is 0%, so the description carries full weight. It explains all four parameters: name, offset (with the crucial 'BYTES, not lines' warning), contains (case-insensitive, applied only to new lines), and fingerprint (rotation detection). This adds real semantic meaning beyond the raw schema.

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 precise statement of scope: 'Only what a log has gained since you last looked.' It names the specific operation (incremental read) and the resource (a log file), and later distinguishes itself from `logs` by saying `logs` re-reads the whole file while this returns the new part.

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?

It explicitly says this is 'the read between calls' and contrasts with `logs`, which re-reads a growing file. It also states a hard exclusion: 'NOT A LIVE TAIL, and it cannot be one,' explaining the synchronous limitation. This is enough for an agent to know when to choose this tool over alternatives.

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

Deploy Server