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

Annotations already establish a safe, idempotent, closed-world read, so the description's extra context is what counts: it discloses that IANA history governs time zone and summer time, that output is calculations only with no interpretation, that a link opens the full result on the site, and that it reports how near the ascendant and cusps are to changing. Those are genuine behavioral facts not present in the structured fields.

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 purpose is front-loaded in the first clause and every later clause adds a distinct output category, so little is pure filler. The single sentence is dense and the long enumeration of computed artifacts could be trimmed or bulleted for faster scanning.

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?

With an output schema present, the description need not document return values, and it still covers the non-obvious cases: missing birth time, DST resolution via IANA history, and no-interpretation scope. For a 9-parameter astronomical tool it is close to complete, with only parameter interrelationships left unaddressed.

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%, including enum values and range hints, so the schema carries parameter meaning on its own. The description adds only marginal semantic value, mainly the effect of omitting the time parameter; it does not clarify interactions such as place versus lat/lon/tz or the 'later' flag for repeated clock times.

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 opens with a specific verb and resource ('Computes a natal (birth) chart from the date, local clock time and place of birth') and enumerates the outputs, so an agent can tell this apart from sky_at or chinese_year by the natal/birth framing. It does not explicitly name any sibling, so full differentiation is left implicit.

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 useful conditional guidance — 'Without a time it gives what does not depend on the hour' — which tells the agent the time parameter is optional and what happens without it. However, there is no explicit statement of when to choose this over astro_calendar, chinese_year or sky_at, so routing is implied rather than instructed.

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