Prashna: chart of the question

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds some behavioral detail beyond that: the Arudha fallback to Udaya Lagna when neither arudhaSign nor number is supplied, and the fact that every returned point carries its chapter and stanza reference. However, the ayanamsa/timezone defaulting behavior it touches is largely restated from the schema, and return shape is delegated to the existing 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 purpose is front-loaded in the first clause, but the body is a long comma-run enumeration of output points (Arudha, Chatra, Gulika, Mandi, Trisphuta, Chatussphuta, Panchasphuta) with no bullets or grouping, which is dense to parse and partly duplicates what the output schema already conveys. Every item is domain-relevant, so nothing is truly filler, but the structure is heavier than it needs to be.

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 an 11-parameter, 20-credit computation with an output schema and full annotation coverage, the description supplies solid domain framing: what the chart is for, what it returns, and the citation practice. The notable gap is sibling disambiguation against astroway_vedic_prashna_analysis and astroway_vedic_prashna_number, which the agent must resolve without help from this text.

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 coverage is 73%, so the schema already documents most parameters in depth (including the arudhaSign/number exclusivity and the timezone-vs-timezoneOffset precedence). The description restates the number/arudhaSign/fallback relationship and the Gulika-vs-Mandi choice rather than adding new syntax or format guidance, so it sits at the baseline for a heavily self-documenting schema.

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 Prasna Marga horary chart for the moment and place of the question) and enumerates the concrete outputs: Udaya Lagna and its navamsa, planetary dignity and combustion, whole-sign houses, Arudha with sphuta, Chatra, Gulika/Mandi, Trisphuta/Chatussphuta/Panchasphuta. It also routes the KP 1-249 number case away to /vedic/kp/horary. It does not, however, distinguish this computation from the sibling astroway_vedic_prashna_analysis, leaving that boundary unstated.

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 only explicit routing is the negative one: 'KP number charts 1-249 are /vedic/kp/horary', which tells the agent where not to send KP-number queries. There is no statement of when to pick this chart tool versus the prashna analysis or number siblings, nor any prerequisite about needing the exact moment and place of the question beyond the required-parameter list in context.

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