Site history

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

With no annotations, the description carries the transparency burden. It discloses caps (20, 25), ordering (most-recent-first), degradation to empty lists, and the error response. It does not explicitly state 'read-only,' but the return-oriented language and lack of side-effect description imply a safe query.

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 dense but front-loaded with the core identity. It packs many details (fields, caps, order, edge cases) efficiently, though a structured list would improve scannability without losing content.

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?

Even without an output schema, the description fully enumerates what is returned, including field groups, ordering, caps, and error cases. It also covers young-fort degradation and the no-fort error, making it complete for a read-only query tool.

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?

The input schema has zero parameters, so the baseline is 4. The description adds no parameter details (none exist) but compensates by thoroughly describing the output context, making the tool's behavior unambiguous.

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 identifies the tool as retrieving the loaded fort's permanent world saga entry, listing exact data types (founding info, name etymology, sieges, deaths). It distinguishes itself from the 'pruned live report stream' and sibling tools like chronicle by emphasizing durability and scope.

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 specifies the tool is scoped to the loaded site and contrasts the permanent saga with the live report stream, giving context on when to use it. It also notes error/degradation behavior for no fort or young forts, but stops short of explicitly naming alternative tools or exclusion criteria.

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