compute_panchanga

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so excellently. It explains the fallback behavior for vara at polar latitudes, the meaning of from_sunrise, the distinction between null rahu_kalam and from_sunrise, and the UT1 time scale used for all returned instants. It also warns about the impact of elevation on sunrise and the need to pass consistent values with search_muhurta. This is rich behavioral context beyond what any schema could convey.

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 dense but well-structured, front-loading the core purpose and then providing critical caveats. Every sentence adds value, covering the five limbs, the time scale, the vara fallback, and the rahu_kalam distinction. It is longer than a typical description but justified by the complexity of the tool and the need to prevent misuse. The structure is logical, moving from what it computes to how to interpret the results.

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 the tool's complexity (7 parameters, no output schema, no annotations), the description is remarkably complete. It covers the input requirements (sidereal longitudes, observer location), the output structure (five limbs with specific details), the time scale (UT1), and the edge cases (polar day/night, elevation effects, consistency with search_muhurta). An agent has everything needed to call this tool correctly and interpret its results, even without an output schema.

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 schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds value by explaining the critical distinction between UT1 and TT/TDB for the jd parameter, the dependency of vara on local sunrise (latitude), and the consistency requirement for elevation_m with search_muhurta. It reinforces the importance of these parameters without repeating the schema verbatim, though it doesn't add new syntax details beyond what the schema provides.

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 computes the panchanga and enumerates all five limbs (tithi, vara, nakshatra, yoga, karana) with specific details for each. It distinguishes itself from sibling tools like compute_natal_chart or compute_gochara by focusing on the almanac computation. The verb 'compute' and the resource 'panchanga' are specific and unambiguous.

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 description provides clear context on when to use this tool (computing the five limbs of the Vedic almanac) and includes important usage caveats, such as checking vara.from_sunrise at high latitudes and the distinction between null rahu_kalam and from_sunrise being false. However, it does not explicitly name alternative tools or state when NOT to use this tool, though the sibling list implies other tools handle different astrological computations.

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