Naksha Vedic Astrology

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context not in the annotations: the city is resolved from an in-memory lookup and is not persisted, which tells the agent about privacy/state behavior. It stops short of describing the returned chart payload or any limits.

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?

A single compact paragraph, front-loaded with the primary triggers and followed by the exclusions, with no filler sentences. The dense trigger enumeration is slightly run-on but every clause serves routing or exclusion.

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?

With no output schema, the description compensates reasonably by naming the outputs an agent should expect (lagna, rashi, nakshatra, planetary placements). Annotations cover the safety profile, so the main residual gap is that it never states what the response looks like or that time is optional, which leaves a small mismatch with the required-parameter list.

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 100%, so all three parameters (date, time, placeName) are already documented in the schema, including that placeName is city text geocoded in memory. The description repeats the city-text rule rather than adding format guidance for date/time, so the baseline of 3 applies. It also implies time is always supplied even though time is not in the required list.

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 concrete operation (compute a Vedic birth chart / kundli from birth details) and enumerates the specific artifacts produced: lagna/rising sign, rashi/moon sign, nakshatra and planetary placements. It is clearly separable from siblings like naksha_compatibility, naksha_daily, naksha_mangal_dosha and naksha_sade_sati, which cover different astrology products.

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?

Explicit when-to-use triggers are listed in the user's own vocabulary ("kundli", "janam kundli", "kundli banao", "what is my rashi"), plus explicit when-not-to-use cases: Western sun-sign horoscopes, deriving a rashi from a name alone, and medical/legal/financial decisions. It also states the required input precondition (birth date, time and city).

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real context beyond them: city text is geocoded in memory and never saved, and a guardrail against deterministic relationship claims. It doesn't state what the response contains or how the score is computed.

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?

Roughly two sentences with no filler, front-loaded on the trigger conditions followed by the exclusions. Every clause carries routing or behavior information; slightly dense but appropriately sized.

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 read-only comparison tool with no output schema, the description covers triggers, exclusions, and input conventions well. The mode parameter's meaning and the shape of the returned compatibility output are the only notable gaps.

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 coverage is 67% and the schema already documents date/time/placeName, so the schema does most of the work. The description reinforces placeName semantics ('city text only', no coordinates) but says nothing about the mode enum values (romantic vs friendship), leaving that parameter only describable from the schema.

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 deliverable (guna milan / ashtakoota score out of 36) and the domain (Vedic compatibility between two people), so the agent knows this compares two birth charts rather than analyzing one. It does not name the sibling tools, but their single-person scope (naksha_chart, naksha_daily) makes the contrast inferable.

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?

Explicit triggering conditions ('kundli milan', 'kundli matching for marriage', 'both birth details are provided') are paired with explicit exclusions ('Do not use for name-only matching or Western synastry'). This is exactly the when/when-not routing an agent needs.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond them: the birth city is looked up in memory and not persisted, and there is a scope limitation on the kinds of claims the reading may make. It stops short of describing what the reading output contains.

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?

Two dense sentences with the usage triggers front-loaded and the exclusions trailing; nothing is wasted. Slightly run-on, but every clause carries routing or constraint information.

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?

Usage, exclusions and privacy behavior are well covered, but with no output schema the description should carry the return-value burden and says nothing about what a reading contains (sections, length, format). That is the main missing piece for a tool of this complexity.

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 coverage is 100%, so the baseline is 3. The description reinforces the placeName semantics ('city text only ... looked up in memory') which the schema already states, but adds nothing about the date parameter, whose schema label ('YYYY-MM-DD birth date') is the most ambiguity-prone part of the call.

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 verb and resource: produce a daily/weekly Vedic astrology reading (gochar/transits) from the user's birth details. It is readily distinguishable from siblings like naksha_chart, naksha_compatibility, naksha_mangal_dosha and naksha_sade_sati, which cover different astrological scopes.

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?

Explicit when-to-use triggers are given (today/this week astrologically, the Hindi phrase 'aaj ka din kaisa rahega', current transits/gochar, daily reading from birth details) plus explicit exclusions ('do not use for general panchang or rahu kaal with no birth details'). It also states a content guardrail about not making deterministic health/death/finance claims.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description still adds real behavioral context: output is factual, the governing rule is disclosed, remedies are out of scope, and it must not be read as a marriage verdict. It does not discuss accuracy caveats or edge cases like missing time.

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?

Two tight sentences: the first front-loads the trigger and required inputs, the second covers output shape and scope limits. No filler, no restating the tool name.

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?

With no output schema, the description carries the burden of describing results and does so (Mars placement plus the rule used). The gap is that it never addresses the optional time parameter's effect or what happens when time is omitted, which matters for an astrological calculation.

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 100%, so the schema already documents date, time and placeName with formats, making 3 the baseline. The description restates the inputs as 'birth date, time and city' but adds no format or fallback guidance, and it implies time is always supplied even though the schema only requires date and placeName.

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 resource (mangal dosha / Mars placement) and states exactly what the tool emits: the Mars placement factually plus the rule applied, with no remedies. It implicitly separates itself from naksha_compatibility by declaring it is 'not a verdict about a marriage', though it does not name that sibling explicitly.

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 concrete trigger phrases ('am I manglik', manglik status for marriage matching) and the precondition (birth date, time and city). It also states an explicit exclusion: 'Do not use without birth details or as a verdict about a marriage.' Both when-to-use and when-not are covered.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds meaningful behavioral context beyond that: it only reports the current phase and deliberately avoids remedies or fear language, setting output-scope expectations. It does not describe response formatting, but that gap is minor given the annotation coverage.

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 the trigger intent and the input requirement, and every sentence serves selection or scoping. The quoted user phrasings add some length but do real work for intent matching, so the size is justifiable.

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?

With no output schema, the description carries the return-value burden and does state that it reports the current phase only. Combined with the annotations, an agent has enough to call it correctly; only the exact response shape is unspecified.

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 100%, so all four parameters (date, time, rashi, placeName) are already documented in the schema. The description's 'rashi OR birth details' note restates what the schema's rashi description already says, adding no new syntax or format detail, so the baseline 3 applies.

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 and resource (check whether sade sati is running, report its current phase) tied to Saturn's transit over the moon sign. It distinguishes itself from adjacent domains by ruling out general Saturn news and Western astrology, though it does not explicitly differentiate itself from the sibling tools like naksha_chart or naksha_daily.

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 concrete trigger phrases the user might say, specifies the required input either as rashi or birth date/time/city, and includes an explicit exclusion ('Do not use for general Saturn news or for Western astrology'). This is exactly the when/when-not guidance an agent needs.

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