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

Annotations already cover readOnly/idempotent/non-destructive, so the bar is lower. The description adds genuine value beyond them: determinism of the plan, the plan's contents, and the guarantee that it 'makes no astrological claim'. It does not detail latency or failure modes, but for a read-only router this is solid.

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?

Front-loaded with 'Router / planner.' and free of filler; each clause carries information (the output plan, the safety note, the call-first rule). Dense but not padded, though the em-dash list of plan contents is slightly long-winded.

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?

Output schema exists so return values needn't be spelled out, yet the description still characterizes the plan usefully. With annotations handling safety and the output schema handling structure, the only real gap is the undocumented nested context flags — an agent can still call the tool with just 'question'.

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 carry parameter meaning. It covers the required 'question' ('natural-language question') and acknowledges 'optional context flags', but never explains the four nested flags (language, hasProfileRef, hasBirthDetails, hasSecondPerson), leaving their semantics entirely opaque.

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?

States a specific verb+role ('Router / planner') and precisely what it returns ('deterministic, ordered call plan — the primary tool, why, the arguments it needs, alternatives and relevant resource URIs'). This immediately distinguishes it from the ~80 analysis/calculation siblings, which none of them are.

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?

Explicitly states the trigger condition: 'Call this first when unsure which of the many tools fits.' Given the enormous sibling set, this routing instruction is exactly the when-to-use guidance an agent needs, and it names no alternative because it is the meta-entry point.

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