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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral facts the annotations lack: a cost of 10 credits (Tier 1) and the POST endpoint. However it says nothing about what the operation evaluates or how expensive/large the result is; the cost line is the only substantive addition. The POST endpoint alongside readOnlyHint=true is unusual but not a contradiction, since POST is a transport detail rather than a side-effect claim.

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?

Very short and scannable, with the bracketed metadata lines front-loading group, endpoint, required params, and cost in a consistent format. The trade-off is that the brevity reflects under-specification rather than efficient compression: the opening line carries almost no information and no sentence explains the tool's actual behavior.

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 15-parameter tool with only 33% schema coverage, the description is far too thin. An output schema exists, so return values need not be explained, but the description never clarifies which branch parameters (zodiacType tropical vs sidereal, ayanamsa, houseSystem) matter for this Hellenistic technique, nor how it differs from the sibling helg_sphaera_barbarica duplicate.

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 only 33%, so two-thirds of the 15 parameters (zodiacType, houseSystem, cosmogram, name, city, and others) are undocumented in both schema and description. The description's only parameter content is '[Required: date, time, latitude, longitude]', which merely restates the schema's required array and adds no syntax, format, or default guidance. It does not compensate for the coverage gap.

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 is a four-word gloss of the Latin name ('Constellations beyond the zodiac') with no verb and no statement of what computation or output the tool produces. An agent cannot tell from this whether the tool returns paranatellonta/extra-zodiacal star risings, a text passage, or a rendering. It also does nothing to distinguish itself from the near-identical sibling astroway_helg_sphaera_barbarica.

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?

No when-to-use, when-not-to-use, or alternative-tool guidance appears anywhere. The only routing signal is the bracketed '[Group: Hellenistic: Greenbaum tradition]' label, which hints at the tradition family but does not say why an agent would pick this over the Brennan, Schmidt, Hand, or helg variants, nor over the duplicate helg_sphaera_barbarica.

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