Runic Calendar (runstaff)

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

Annotations already declare this as a safe, idempotent, non-destructive read with closed-world scope, so the description does not need to repeat that. It adds useful behavioral detail about the runic mapping conventions, including the A-G day-rune assignment from 1 January, two dominical runes in leap years, and the sixteen Younger Futhark runes plus arlaug, tvímaðr, and belgþór for the golden number.

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 front-loaded with the resource and scope, then efficiently lists the returned runic elements. The parenthetical technical details are dense but each earns its place by clarifying the calendar conventions.

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?

For a one-parameter read-only lookup with full schema coverage, supporting annotations, and an output schema, the description supplies enough context to invoke and interpret the tool correctly. It explains the key return concepts without redundantly describing the full response schema.

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 100%, and the schema already documents the YYYY-MM-DD pattern and the today-UTC default. The description reinforces that the calendar is computed for a date but adds no parameter syntax or formatting detail beyond the schema.

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 resource and scope: the medieval Scandinavian runic calendar for a date. It also names the exact runic outputs, including day rune, Sunday rune/dominical letter, and golden-number rune, so an agent can distinguish this from generic calendar or other rune tools.

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 usage is implied by the phrase 'for a date', and the schema makes the single optional date parameter clear. However, the description does not state when to choose this tool over sibling rune tools or calendar tools, nor does it provide explicit alternatives.

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