briefing

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

With no annotations, the description carries the full burden and does well: it discloses the gate/`withheld` behavior, that `decisions` is never truncated, that every other list caps at limit (default 8, max 50) with `omitted`/`more` pointers, and the read-scope constraint ('five game reads; nothing another seat can see is read'). It omits error/failure behavior and performance characteristics, so it is not exhaustive.

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?

It is front-loaded with the purpose and almost every clause carries information, but it is delivered as long semicolon-chained run-ons rather than a structured list of the returned keys, making it harder to parse than it needs to be. No filler, but the density hurts scanability.

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 no output schema and no annotations, the description covers the full return surface key-by-key (decisions, warnings, opportunities, changes, empire, cities, units, threats, camps, civ_rules, notes, assignments, orders), plus the gate case and where to find field documentation. Nothing material for calling it correctly appears to be 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 coverage is 0%, so the description must compensate, and it largely does: limit gets a default and max, since="turn" is defined against the previous turn boundary, notes is explained for its 'all' value and against the last briefing/finish_turn, and detail="full" is described. The default notes="auto" behavior and the default since="previous" semantics are not spelled out, leaving one real gap.

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 opening sentence gives a clear verb+resource: a compact per-turn read for deciding and for recovering after a context reset, enumerating what it returns (decisions, changes, board state). It also differentiates from at least one sibling by noting turn_digest keeps its own cursor. The phrasing is idiosyncratic and dense, so the purpose takes work to extract, which keeps it below a 5.

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?

It states the two motivating situations explicitly ('for deciding' and 'recovering after a context reset') and reinforces the reset case with 'since="turn" ... use it after a context reset'. It also discloses the gated case where only `gate` returns. However, it never names an alternative tool to use instead in a given situation, so it stops short of full when/when-not routing.

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