divine_get_kp_cuspal

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate safety. It adds useful behavioral context by disclosing the calculation method ('KP ayanamsha and unequal house system') and the output content ('cuspal positions with sign, star, and sub divisions'). No contradictions with annotations exist, but it does not go beyond these basics.

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 description is two concise sentences with no redundant wording. The core action and target are front-loaded in the first sentence, and the second sentence adds necessary technical context about the return content and calculation system. Every sentence earns its place.

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 a read-only chart tool with annotations covering safety and an output schema present, the description is largely sufficient. It explains what is returned and the astrological system used, which is enough to guide invocation. The only minor gap is the lack of explicit sibling differentiation, but this does not severely hinder completeness given the clear tool name and purpose.

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?

The top-level parameter schema has 0% description coverage, so the description must compensate for parameter meaning. It only says 'for a birth chart' and does not explain the required params field or its nested birth details. Although the nested KundliInput schema has rich descriptions, the tool description itself adds little parameter-level semantic value.

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 clearly states the tool retrieves 'KP Cuspal chart data' and specifies it returns cuspal positions with sign, star, and sub divisions. This is a specific verb-resource combination that conveys the core function. However, it does not explicitly distinguish itself from closely named siblings like divine_get_kp_cuspal_sub or divine_get_kp_cuspal_significator, so it falls short of full differentiation.

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?

The phrase 'for a birth chart' gives clear context that this tool applies to birth chart data, implying the general use case. There is no explicit guidance on when to prefer this tool over related KP cuspal siblings, nor any exclusions or alternative recommendations. The usage is implied rather than explicitly stated.

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