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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real context beyond that: the explicit degradation behavior without a time, and 'Calculations only', which signals no interpretive commentary is produced.

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?

Dense and front-loaded: the return contents come first, then the two operational caveats as short sentences. No filler, though the single long enumeration sentence is heavy and could be split for scanability.

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-value explanation is not required, yet the description spends most of its length listing outputs. With 9 parameters and an unlabeled house_system enum, the description leaves the important 'whole vs placidus' and place-vs-coordinates decisions entirely to the schema.

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 89%, so most parameters (tz, lat/lon alternates, date range, lang, node, place) are already documented. The description only contributes the time-dependency note for 'time'; it adds no format or interaction detail beyond the schema (e.g., place vs lat/lon precedence, house_system choice).

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 specific artifact (a sidereal/Lahiri birth chart) and enumerates its contents: lagna, nine grahas with rashis/nakshatras/padas, whole-sign houses, navamsa, and Vimshottari periods. The 'sidereal zodiac (Lahiri ayanamsa)' qualifier implicitly separates it from the tropical sibling birth_chart, though no sibling is named explicitly.

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 gives one useful eligibility rule — omitting the hour drops lagna and houses — which tells an agent when the tool is appropriate versus insufficient. However, there is no guidance on choosing between this and birth_chart, astro_calendar, or planet_returns, and no exclusions.

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