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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the run is deterministic, never invokes another AI model, performs a fixed full-domain screen, checks contradictions and reports coverage. It does not describe latency, output size, or what happens if inputs are inconsistent (e.g., place vs lat/long).

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?

Front-loaded with the routing claim in caps so the primary-vs-specialist decision is immediate. The middle sentence is a long run-on domain list, but each remaining sentence (extra depth, specialist routing, determinism) carries distinct information rather than restating the schema.

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 values and coverage reporting need not be restated. However, for an 18-parameter tool with a nested consent object and low schema coverage, the description should at least say when profileRef and readingMode matter and what the consent block gates — it currently leaves that entirely to the 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?

Schema description coverage is only 22% across 18 parameters with a nested remedyPreferences object, and the description explains none of them: no mention of how focus, question, detail, language, readingMode, traditions, asOfDate, or the remedyPreferences consent block interact. It does not compensate for the large under-documented surface, leaving the agent to infer how a 'normal question' maps onto focus vs question vs readingMode.

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 scope for a specific resource: a complete person-first Jyotisha screen across named life domains plus targeted Varga/timing depth on the exact question. It explicitly positions itself against siblings ('PRIMARY TOOL... use specialist tools only when...'), so an agent can tell it apart from analyze_chart_topic or get_depth_analysis without opening a schema.

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?

It gives a clear when-to-use rule ('EVERY NORMAL USER QUESTION AND FIRST READING') and an explicit when-to-use-something-else rule ('use specialist tools only when this result requests additional inputs or the user asks for technical matrices'). The user-question vs technical-matrix split is a concrete routing condition.

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