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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds the credit cost (20, Tier 2) and the semantics of what each yoga flag means, which is genuine value. It does not disclose anything further about response shape or computation constraints.

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 yoga enumeration is front-loaded and tight, which is good. However the trailing Phase 2 sentence is stale relative to the shipped siblings and reads as roadmap noise, and the [Group]/[Cost] tags add metadata that isn't about invoking the tool.

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 values needn't be explained, and the common chart-building params are shared across the astroway family. Still, with 15 params at 33% coverage and a mutation-free but multi-option surface (ayanamsa enum, houseSystem enum, zodiacType), the description leaves the invocation contract to the schema alone and adds no prerequisites or defaults.

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?

With 15 parameters and only 33% schema description coverage, the description carries a compensation burden and provides none: it never mentions date, time, latitude, longitude, timezone, ayanamsa, or the fields/precision compact-mode params. An agent gets no added meaning for the under-documented inputs.

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 specific verb+resource work: 'Basic Jaimini-yoga checks based on chara karakas' and enumerates the exact checks (Raja yoga AK in Lagna/Kendra, marriage yoga DK in trine, AK+PK conjunction, AK in dusthana). That is far more precise than a tautology. It only weakly separates itself from the many existing astroway_vedic_jaimini_* and astroway_vedic_yogas_jaimini_* siblings, so it stops short of a 5.

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?

Usage is implied: this is the 'basic' set, and the description points toward dedicated yoga endpoints for fuller analysis. But the pointer is framed as future work ('Phase 2 block 19 will add...') even though siblings like astroway_vedic_yogas_jaimini_raja, _dhana, _daridra, and _viparita already appear in the tool list, so the routing advice is stale rather than an actionable when-to-use/when-not-to-use rule.

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