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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description usefully anchors the computation to asOfIso, clarifying that this is a snapshot evaluation rather than a forecasting timeline. It adds no notes on cost, limits, or how the birth-data inputs must be supplied relative to the as-of date.

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 tool name and core concept, then a single dense enumeration of outputs, then the usage cue. No filler sentences, though the undifferentiated jargon list is heavy to parse in one pass.

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 nine-parameter analytical tool with an output schema present and annotations covering safety, the description is complete enough: it enumerates the computed factors (houses from Moon and Lagna, Vedha, Ashtakavarga bindus, Kakshya, Murthy Nirnaya, Sade Sati, double-transit houses) and names the triggering user question.

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 78%, so the schema carries most parameter meaning and a 3 is the baseline. The description only ties asOfIso to the output ('for each graha at asOfIso'); it does not explain the place-vs-explicit-coordinates branch, the timezone/timezoneOffset relationship, or the date/time birth inputs.

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?

States a specific computation (current Gochara transits against the natal chart) and enumerates exactly what each graha output includes. An agent knows precisely what the tool returns, but the description never distinguishes it from close siblings such as calculate_gochara, calculate_gochara_from_known_place, or analyze_transit_activation, all of which sit in the same domain.

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?

"Use for 'how are my transits now / this month'" gives a clear intended scenario, but there are no exclusions and no routing advice despite heavy sibling overlap with calculate_gochara and analyze_transit_activation. Usage is implied rather than scoped.

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