Compatibility: Dasha (concurrent Vimshottari)

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

Annotations already declare a read-only, idempotent, non-destructive, closed-world call, so the safety bar is low. The description still adds real behavior beyond them: output is cut into segments where all four lords hold constant, it includes mahadasha change points and per-relation share of the window, and it explicitly yields 'No verdict'. The metadata line also discloses cost (50 credits, Tier 3) and the POST endpoint, which is genuine pre-call context.

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 sentence is front-loaded with the resource and segment definition, and the bracketed metadata (group, endpoint, required fields, cost) is compact and scannable. The main sentence is dense — four clauses chained with commas — but every clause conveys distinct output structure rather than filler.

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?

An output schema exists, so return-shape explanation is unnecessary, and the description still conveys enough of the result semantics (constant-lord segments, mahadasha transitions, share by relation) to interpret it. With cost, endpoint, required fields, and both chart roles supplied, an agent has everything needed to call it correctly.

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?

At 50% schema coverage the description carries partial burden. It restates `years` (1-30, default 10) and ties the window start to `fromDate`, matching the schema defaults. It says 'both partners' but never clarifies which chart is bride versus groom, leaving the asymmetric Porutham counting direction to the nested schema descriptions.

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 a specific verb-plus-resource: Vimshottari mahadasha and antardasha computed for both partners over a date window, segmented by constant lord sets, with relations shown. The closing 'No verdict' distinguishes it from the many verdict-producing compatibility siblings. It stops short of naming the sibling it displaces (e.g. the single-chart vimshottari tools), which is why it is not a 5.

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?

Usage is implied rather than stated: the tool is for overlaying both partners' dasha timelines, and 'No verdict' signals it is not a scoring/match tool. There is no explicit 'use this when you need X instead of compatibility_full / jaimini_dasha_summary' routing, so an agent must infer selection from the resource phrase alone.

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