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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new operational context: the credit cost (20 credits, Tier 2), the interpretation semantics of the returned flag, and the fact that a KP Moon sub-lord chain accompanies the result. It stops short of noting any limits on chart input or result caching.

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?

Three tight sentences front-loaded with the defining rule, followed by output semantics and attached data, then the group/cost tags. Every clause carries information and nothing is padded.

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?

With an output schema present, return values need not be explained, and annotations carry the safety profile, so the remaining burden is light. The main gaps are routing against kp_full and any guidance for the shared 15-parameter birth-data input, but the tool is otherwise well enough specified to invoke.

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% across 15 parameters, and the description contributes nothing about any of them — not even that the required date/time/latitude/longitude define the natal chart being tested. Nothing hints that ayanamsa should be KP-flavored for a KP dosha, leaving the agent to infer it from the schema alone.

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 yoga being evaluated and spells out its detection rule (no planet other than Sun/Rahu/Ketu in the 2nd or 12th from Moon), so an agent knows precisely what is computed. It also states what the output flag means (Moon-isolation, emotional/financial volatility) and what extra payload is attached (KP Moon sub-lord chain), which separates it from siblings like kp_manglik or kp_kalasarpa.

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?

There is no statement of when to call this versus alternatives — notably the sibling astroway_vedic_doshas_kp_full, which likely returns this dosha alongside others, or the Parashara/Lal Kitab Kemadruma variants. No prerequisites, no exclusions, and no trigger conditions beyond the astrological definition.

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