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

Annotations already provide readOnly, idempotent, and openWorld hints, and the description adds substantial non-obvious behavior: it uses Swiss Ephemeris rather than AI or guessing, returns an exact tropical chart, and enumerates the full result shape including aspects, orbs, applying/separating flags, house cusps and angles. Nothing in the description contradicts the annotations.

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 usage condition and prerequisite before the output details. It is dense and somewhat run-on in the first sentence, but every clause carries information about behavior or return shape, so it earns a high score rather than a maximum.

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?

This is a complex calculation tool with no output schema, and the description compensates fully by specifying the 14 points, house cusps, angles, aspect types, orbs, applying/separating status and zodiac. Combined with the fully described input schema, an agent has everything needed to invoke and interpret the call.

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 100% and every parameter already has a thorough description, so the baseline is 3. The description adds useful context by explaining that the birth place and local time must be resolved through resolve_birth_place before supplying latitude, longitude and birth_datetime, and by tying the result fields to the input birth moment and place.

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 names the exact resource (natal chart / birth chart / personal horoscope) and a specific action (compute with Swiss Ephemeris). It also distinguishes itself by explicitly forbidding self-computation or web-search and pointing to resolve_birth_place for place-name-only inputs, so an agent can tell it apart from siblings.

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 states when to use the tool: for ANY natal chart or personal horoscope request. It gives an explicit when-not by saying never compute or recall positions yourself and never web-search them, and it names the alternative resolve_birth_place as a prerequisite when only a place name and local time are available.

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