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

With annotations already covering readOnly/idempotent/closed-world, the description still adds substantial context: determinism (JPL DE440, no LLM), a verifiable meta.result_sha256, cost ($0.02/call), the payment mechanism (x402 or MPP), and a free-call allowance. These are exactly the operational facts an agent cannot get from structured fields.

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?

It is front-loaded with what the tool computes, which is good, but the first and second sentences restate the same content ('exact time each ends' vs 'with their end times (to the minute)'), and the pricing/endpoint sentence is dense with semicolon-separated fragments. It is informative but not tight.

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 9-parameter, no-output-schema tool, the description does describe the returned content (the five limbs with end times, paksha, rashi, sunrise/sunset) and the determinism/hash guarantees, so an agent can anticipate results. Gaps remain around error/warning behavior (e.g. TIME_UNKNOWN) and pagination-free large responses, but the core is covered.

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 89%, so parameters are largely self-documenting and the baseline is 3. The description adds only marginal parameter meaning ('the vara by the sunrise-to-sunrise rule') and does not clarify the date/time vs datetime exclusivity or the options object beyond what the schema states.

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 concrete outputs (tithi, vara, nakshatra, yoga, karana with end times, paksha, Moon/Sun rashi, sunrise/sunset), so an agent knows exactly what this computes. It does not, however, distinguish itself from the similarly-scoped siblings (kundli, natal_chart, nakshatras), so an agent must infer the boundary.

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?

There is no when-to-use or when-not-to-use guidance relative to the 16 sibling tools, nor any stated prerequisites beyond the implicit latitude/longitude requirement. Pricing and endpoint details are present, but selection guidance is entirely absent.

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