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

Annotations already declare a safe read-only, idempotent profile, but the description adds valuable context beyond them: no birth data storage or logging (including request bodies, logs, stats, errors), language fallback behavior for unsupported codes, and the concrete behavior change when the time is unknown (no Ascendant/houses, multiple Moon signs).

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 in the opening clause, and the dense paragraph packs trigger phrases, constraints, edge-case behavior, and privacy into a few sentences. It is long and clause-heavy, but nearly every clause adds operational value rather than repetition.

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 an 11-parameter tool with an output schema, the description supplies the missing behavioral context an agent needs: input fallback rules, unknown-time handling, window semantics, and a privacy guarantee. Return-value details are correctly omitted since the output schema covers them.

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 9%, so the description carries real weight, and it does explain the trickiest parameters: the ±15/30/60/120 window, fold/ambiguity choice, historic offset override, and the unknown-precision semantics. It leaves lang, timezone, latitude/longitude, place_id, birth_date, and birth_time format unaddressed, so coverage is strong but incomplete.

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 and resource ('Calculate a complete natal chart') and enumerates the outputs (planets, Ascendant, Whole Sign houses, major aspects, uncertainty). It also lists multilingual trigger phrases and clearly occupies the comprehensive-chart slot, distinguishing it from narrower siblings like get_big_three or get_planet_positions.

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?

Gives explicit operational guidance: ask for missing birth time and birthplace rather than guessing, and use time_precision=unknown when the time is unknown with defined consequences. It does not, however, explicitly route between this tool and the other chart-related siblings, so the when-not-this-tool guidance is absent.

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