game_log

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

With no annotations, the description carries the full burden of behavioral disclosure. It states 'since the last read' which implies stateful consumption (reading marks progress), and mentions the regex filter. However, it does not clarify whether logs are cleared, how 'last read' is tracked, or any side effects of calling this tool repeatedly.

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?

The description is extremely concise at two sentences, front-loading the core purpose. It is efficient and free of fluff, though it sacrifices necessary detail. This is good conciseness, but for a tool with three parameters, it leans toward under-specification rather than optimal economy.

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?

Given the tool has three parameters and an existing output schema, the description still fails to explain the semantics of `limit` and `since` or how they interact with the 'last read' pointer. It does not specify whether `since` is a timestamp or line number, nor the default behavior when null. The output schema exists, so return value details are not required, but the parameter semantics and stateful behavior are essential and missing.

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 for all parameters. Only `pattern` is explained as a regex filter. The meanings of `limit` and `since` are left entirely to the schema defaults and titles, providing no additional context about their units, semantics, or interactions with the 'last read' behavior.

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 clearly states it returns new log lines since the last read, which is a specific verb (read) and resource (game logs). It is not a tautology and is distinguishable from siblings like game_state or game_observe, though it doesn't explicitly name an alternative.

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 description gives a hint that it is used to fetch fresh log lines, but provides no explicit when-to-use or when-not-to-use guidance. There is no mention of alternatives such as game_wait_for_log for waiting on logs or game_observe for observations, leaving the agent to infer the appropriate context.

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