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

Annotations already declare readOnly/idempotent/non-destructive, so the safety load is largely carried. The description adds real behavioral context beyond that: the cacheable-result rationale for why isCurrent is omitted rather than false, and the note that hours are rarely 60 minutes long. It does not mention auth, rate limits, or credit cost.

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?

Purpose is front-loaded, followed by the structural detail and the parameter behavior. Sentences are dense but each carries information; the truncated trailing clause suggests the entry is tight rather than padded.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. What remains — the purpose, the hour structure, and the isCurrent/atLocalHour contract — is all present, so an agent has what it needs to call the tool correctly.

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 63%, and the schema itself already documents atLocalHour, timezone, timezoneOffset, fields, and precision in detail. The description's atLocalHour explanation largely duplicates the schema, and startHour/endHour it references are outputs, not inputs, so net added parameter meaning is marginal.

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 gives a precise verb+resource: 'Chaldean planetary hours for a date and place,' and even explains the 12+12 unequal-hour structure, so an agent immediately knows this is the planetary-hours calculator rather than a general calendar tool. It stops short of naming any sibling (e.g. moon_phase, hours vs. sun_times) to disambiguate within the dense calendar group.

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?

There is no when-to-use or when-not-to-use guidance and no routing to alternatives among the many calendar siblings. The only conditional logic explained is the internal atLocalHour toggle, which is about output shape, not about selecting this tool.

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