Skip to main content
Glama

Wait for a line to appear in a log

log_watch
Read-only

Block until a log line matches the given text in a tModLoader log, then return it. Offset tracking prevents missed or duplicate lines; a timeout returns matched: false.

Instructions

Block until a log line matches, instead of polling log_since by hand.

Args: name: A log filename from log_files. contains: Case-insensitive text to wait for. REQUIRED — without one this matches the first line written and is log_since wearing a longer name. offset: Where to start reading. 0 includes the log's HISTORY, which is usually what you want ("did the mod load" is a question about a line that is already there). Pass a previous call's next_offset to watch only what comes after it. fingerprint: The fingerprint from an earlier log_since/log_watch, when resuming — see log_since for the rotation it catches. Within one call the polls carry it themselves. timeout: Seconds for the WHOLE call, spent across every poll. poll: Seconds between reads.

THE OFFSET IS THE MECHANISM. Each poll resumes where the last stopped, so a line is matched exactly once — never missed in the gap between two polls, and never re-reported on the next. A watch that re-read the file from the top would match a line written before the wait began and call it news, which is how "wait for the crash" passes on the crash from the PREVIOUS run.

Not matching is an ANSWER, not an error: it returns matched: false with the resume point, so "nothing was logged for 30s" is as expressible as waiting for something. A MISSING log still raises, because that is nobody having been asked rather than a line failing to arrive.

restarted means the log rotated during the wait — tModLoader zips the previous run's logs and starts fresh, so your offset stopped meaning anything and the lines you are holding came out of a different file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
pollNo
offsetNo
timeoutNo
containsYes
fingerprintNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
linesYes
pollsYes
elapsedYes
matchedYes
restartedYes
fingerprintYes
next_offsetYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.3

TDQS

A4.9/5.0
Behavior5/5

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

The description goes far beyond the readOnly/destructive annotations. It discloses that the tool blocks, that it polls internally, that each line is matched exactly once, that a non-match returns `matched: false` rather than raising, that a missing log raises, and that `restarted` indicates log rotation. This is rich behavioral context that annotations alone could not provide.

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 paragraph earns its place: the first paragraph defines the parameters, the second explains the core mechanism, and the third clarifies error semantics. The 'THE OFFSET IS THE MECHANISM' section is front-loaded with the most important behavioral insight. It could be tightened slightly, but the length is justified by the tool's complexity.

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 blocking, stateful, polling tool with 6 parameters and no schema descriptions, the description covers all the essential context: how to resume, what history means, what happens on timeout/non-match, what rotation means, and how it differs from `log_since`. The output schema exists, so return values don't need to be spelled out in prose. Nothing critical is missing.

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 the full burden, and it delivers. It explains `name` as coming from `log_files`, `contains` as case-insensitive and required, `offset` as the resume mechanism with history semantics, `fingerprint` as a resume token from earlier calls, `timeout` as whole-call budget, and `poll` as seconds between reads. This is far more than the schema's bare titles.

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: 'Block until a log line matches' a named log file, and immediately contrasts itself with the sibling `log_since` ('instead of polling `log_since` by hand'). This clearly distinguishes it from the closest alternative and states the tool's core behavior.

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 explicitly explains when to use this tool versus `log_since`, including the offset mechanism for resuming, the meaning of `contains` being required, and the semantic difference between 'not matching' and a missing log. It also gives concrete guidance like 'did the mod load' being a question about history, which tells an agent exactly when to use offset 0.

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