compute_dasha

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

With no annotations, the description carries the full behavioral burden. It discloses the output (JSON dasha tree with start/end Julian Days), the read-only nature implied by 'returns', and importantly clarifies that the computation is ephemeris-free and carries the UT1 epoch through rather than converting. This is meaningful context beyond a simple 'compute' statement, though it omits error handling or response edge cases.

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?

Two sentences with no filler. The purpose is front-loaded, the systems and their requirements are grouped logically, and the output is stated. Every phrase earns its place, and the structure makes scanning easy.

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 tool with five parameters, five systems, and no output schema, the description covers the essential points: what it computes, which systems need which parameters, and what the return type is. It also explains the time-scale detail that could trip up users. It does not mention what happens if required params are missing, but that is a minor gap given the schema already marks them required.

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 100% — every parameter already has a clear description, including which systems require which parameters. The tool description repeats this requirement mapping and adds the UT1 scale note, but that is also already in the birth_jd schema description. The description adds no new information beyond what the schema already provides, so it stays at the baseline.

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 ('Compute') and resource ('Vedic dasha sequences'), and immediately enumerates the five supported systems. This clearly distinguishes the tool from siblings like compute_gochara or compute_transit, leaving no ambiguity about what it does.

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 no guidance on when to choose this tool over alternatives such as compute_panchanga or compute_bhavas. It mentions compute_natal_chart only to clarify the time scale, not as a usage comparison. It does explain parameter requirements per system, but that is parameter-level guidance, not tool-selection guidance.

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