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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that by disclosing the calculation method (KP with Placidus cusps), ayanamsa flexibility, and the exact return contents, which is especially important because there is no output schema.

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 core description is front-loaded and useful, but the trailing 'SEO:' block of keyword phrases adds no invocation value for an AI agent and should not have been included. A shorter description ending after the use cases would score higher.

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?

Given there is no output schema, the description does a good job of disclosing return contents and calculation approach. It covers all key output expectations: planets, Ascendant, cusps, nakshatra details, star-lords, sub-lords, and KP horary numbers. It could be more complete about exact response format or edge cases, but the essentials are present.

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?

Input schema description coverage is 100%, so the baseline of 3 applies. The description reinforces parameter context like custom ayanamsa and KP-Newcomb, but those details are already documented in the schema; it does not add new parameter-level semantics beyond what the structured descriptions already provide.

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 opens with a specific verb and resource ('Generate authentic Krishnamurti Paddhati birth charts') and clearly enumerates what the chart contains: 9 planets, Ascendant, cusps, nakshatra details, star-lords, sub-lords, and horary numbers. It distinguishes itself from generic Vedic chart tools by emphasizing KP methodology and Placidus cusps, though it does not explicitly name a sibling alternative.

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 broad use contexts ('Perfect for KP astrology software, horary prediction apps, and event timing analysis') but does not explicitly say when to choose this tool over the many sibling KP endpoints such as kp_planets, kp_cusps, or kp_horary. The word 'complete' implies the alternative of partial KP tools, but no concrete selection guidance is provided.

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