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

With no annotations, the description carries the full burden. It discloses that output includes explanations with sources and a level (calculated or tradition), and states it avoids predictions. It also notes the need for birth time. This is transparent about the tool's behavior, though it does not explicitly state read-only status or failure modes, which are minor for an explanation tool.

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 a single, dense sentence that front-loads the core purpose and constraints. Every clause adds value: the sections covered, the explanation style, the source/level attribute, the exclusion of predictions, and the birth-time requirement. No wasted words.

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?

While the output schema covers return values, the description does not explain how to provide input (e.g., whether chart_id substitutes for birth data, or the relationship between date/time/place and geonameid). The tool has 8 parameters and only the section is clearly described. It is complete for the core section parameter but incomplete regarding the other optional inputs.

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 0%, so the description must compensate. It only addresses the 'section' parameter (by enumerating its possible values) and mentions the need for birth time, but does not explain date, time, place, ayanamsa, chart_id, or geonameid. Most parameters are left unexplained, making it hard for an agent to know which combinations are valid.

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 states a specific verb ('explain'), the resource ('chart section'), and the specific sections (lagna, Moon, dasha). It also explicitly excludes predictions and advice, which differentiates it from sibling tools like dasha_timeline that provide timelines rather than explanations. The purpose is 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 gives clear context: it explains chart sections and explicitly states it does not provide predictions or advice, which serves as a when-not. It also mentions the prerequisite of birth time. However, it does not name alternative tools or explicitly state when to use this one over others, so it falls short of a 5.

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