Waits until a regex matches a new line in Prism Launcher's latest.log or times out, letting automation detect game events such as user setting, backend startup, or stopping.
Wait until a regex matches a new line in latest.log (e.g. 'Setting user|Backend library|Stopping!'), or timeout.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| pattern | Yes | ||
| timeoutMs | No |
Changes observed during successful MCP inspections.
v0.9.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose that the tool blocks until a match appears in new lines of latest.log or a timeout occurs. However, it doesn't say what happens on timeout (error vs. empty result), what the result looks like on a match, or whether it observes only lines appended after the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with an example that earns its place. It is not bloated, though the example compresses several concepts into one clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a blocking, side-effect-free but semantically rich tool with no annotations and no output schema. The description omits what is returned on match or timeout, the meaning of 'id', and timeout boundaries, leaving key call semantics unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not. It explains 'pattern' via example and hints at 'timeoutMs', yet the required 'id' parameter is never defined (presumably an instance id), and timeout units/defaults/maximums and regex flavor are unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: waiting until a regex matches a new line in latest.log, with an illustrative example pattern. It implicitly differs from sibling tools like tail_log and get_instance_status, but it never names or explicitly contrasts them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The blocking wait behavior suggests when the tool is useful (awaiting a log event rather than reading logs), but there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as tail_log.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.