Cosmic Chemistry

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds valuable behavioral context: it returns no score or verdict, and specifies the exact astrological data returned. It doesn't cover error handling or rate limits, but those are minor for a read-only 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 front-loaded with the primary use case and examples, then systematically covers output, limitations, and prerequisites. Every sentence serves a purpose; there is no redundant fluff.

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 fully explains the return values and explicitly states what is not returned (score/verdict). It also covers input prerequisites and distinguishes from guna milan, making it complete enough for an agent given the annotations and 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 100%, so the baseline is 3. The description adds meaning by noting that times are optional but make results exact, and that the first person is usually the asker, clarifying the ordering of the two person parameters.

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 (compare/assess compatibility) and resource (two birth charts in Vedic astrology), and explicitly names what it returns. It distinguishes itself from the 36-point guna milan, which helps separate it from sibling tools like manglik_check or vedic_birth_chart.

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 provides explicit when-to-use triggers (compatibility, synastry, comparing charts) with example queries, and a clear when-not: it is not for guna milan and should not be used for gunas. It also states prerequisites (both dates and towns needed; times optional).

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?

Beyond the readOnly/idempotent annotations, it discloses meaningful behavior: results are computed from birth date and town, an omitted birth_time can make the answer vary across the birth day, and in that case each possibility is returned with the hours it holds for. That is exactly the ambiguity an agent needs to anticipate before calling.

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 core usage trigger and the parameter-routing instruction are front-loaded, and the return-value sentence follows. It is dense with parenthetical examples but each clause maps to a distinct fact (trigger, enum, return fields, birth-time caveat), so little is wasted.

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 burden and does so adequately: all seven karakas in order with sign, degree, nakshatra, navamsa sign, and house when a birth time is given. Combined with the birth-time caveat and the two required parameters, nothing essential is missing.

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, and the description still adds value by tying the 'which' enum to the specific karaka asked about and explaining why birth_time precision changes the output. It does not add format/detail beyond the schema for birth_date or birth_place, so it sits above baseline but not maximally.

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 exact deliverables (atmakaraka, amatyakaraka, darakaraka, and all seven chara karakas) in Jaimini/Vedic astrology, distinguishing it from siblings like divisional_chart or vedic_birth_chart that serve different chart needs. An agent can identify the verb+resource without opening any 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 explicitly frames when to trigger ('Use this when someone asks for their...') and supplies literal user phrasings such as 'what is my atmakaraka' and 'darakaraka in navamsa', plus the routing rule to set 'which'. It stops short of naming a sibling alternative for a competing case, so it is clear context rather than full when/when-not guidance.

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 the description goes well beyond them: it describes the depth of output (mahadasha down to sookshma), how on_date shifts the result to past/future days, how mahadasha expands to all nine antardashas, and that birth_time must be exact. That is substantive behavioral context, especially valuable with no output schema.

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 when-to-use triggers and quoted queries, then output shape, then parameter behavior, then the sibling alternative and prerequisites. Dense but no sentence is filler.

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 astrology calculation with no output schema, the description covers trigger conditions, return content and nesting depth, parameter effects, the sibling disambiguation, and required birth data. Nothing an agent needs to invoke it correctly is missing.

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 five parameters including the enum-bound mahadasha are already documented in detail. The description largely restates the on_date and mahadasha semantics rather than adding format or edge-case detail beyond the schema. 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 opens with a concrete use case set (mahadasha/antardasha, timeline, start/end dates) and states exactly what is produced: 'Returns every mahadasha with dates, and the antardasha, pratyantar and sookshma running now.' It also explicitly distinguishes itself from the sibling mahadasha_meaning, so an agent can route between the two without inspecting schemas.

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 explicit triggering user phrasings ('when does my Rahu dasha end', 'which dasha was I in during 2019') and names the alternative for the adjacent case: 'For what a dasha means in general, without birth details, use mahadasha_meaning.' Prerequisites (birth date, time, town) are stated up front.

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 openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral facts the annotations cannot convey: no birth details are needed, and absent a place the result defaults to New Delhi. It stops short of describing output shape or any rate/limit behavior, so it is not a full 5.

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 primary trigger and scope, then the retrieval fields, then the examples, then the exclusion. The parenthetical example queries are functional for intent matching rather than padding, though the run-on first sentence is dense and could be split for faster scanning.

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?

There is no output schema, and the description compensates by enumerating the returned fields (tithi, nakshatra, Rahu kaal, choghadiya, sunrise/sunset, festivals) plus the default-place behavior and the no-birth-details precondition. For a 2-optional-param read-only tool, an agent has everything needed to call it correctly.

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?

With 100% schema coverage the baseline is 3, and the description earns an extra point by disclosing the defaulting rule for `place` (New Delhi when omitted) and confirming `date` can be any date, not just today. That is real semantic value beyond the schema's format-only descriptions.

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 resource (today's panchang / Hindu calendar for a place) and enumerates exactly what is returned: tithi, nakshatra, yoga, karana, Rahu kaal, Yamaganda, Gulika, Abhijit muhurat, choghadiya, sunrise/sunset, festivals. It also draws an explicit boundary against the birth-chart siblings, so an agent can separate it from vedic_birth_chart 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?

Gives concrete triggering utterances ("aaj ka panchang", "Rahu kaal today in Pune", "is today Ekadashi"), notes it also works for another date, and states the negative case explicitly: do not use for a person's birth chart or birth star. That is when-to-use, when-not-to-use, and alternative routing all in one place.

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 only cover the read-only/idempotent safety profile; the description adds substantial behavioral detail beyond them: the exact return contents (rising sign plus every planet's sign and house), the extra D9-only ishta/palana deities from the karakamsha and the D10 per-planet deity, and the precision sensitivity of the rising sign (~13 and ~12 minutes of birth 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?

Four sentences, front-loaded with the usage trigger and no filler. The parenthetical example phrases make it dense but each sentence carries new information (triggers, chart param, return shape, birth-data precision).

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?

There is no output schema, so the description must carry the return contract — and it does, spelling out the rising sign, planetary placements per chart, and the chart-specific deity fields. Combined with the birth-time precision warning, an agent has everything needed to call and interpret the tool.

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, but the description adds astrological meaning the schema lacks: it explains that 'chart' selects d9 vs. d10 for marriage vs. career, and that birth_time accuracy matters because the D9 rising sign shifts roughly every 13 minutes. Format syntax itself is left to 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 a specific resource (navamsa/D9 and dashamsha/D10 divisional charts) and its interpretive purpose (marriage and inner strength vs. career), which separates it from the generic vedic_birth_chart sibling. Example user phrasings make the target 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?

It gives explicit trigger conditions — 'Use this when someone asks for their navamsa (D9) chart... or their dashamsha (D10) chart' — plus concrete utterance examples. It does not, however, state when NOT to use it or name the sibling (vedic_birth_chart, vedic_rising_sign) that handles the base rasi chart.

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 the description adds substantive context beyond them: the 120-day cap, today as default start, New Delhi as default location, city-to-city date variance, and that no birth details are needed. That is a meaningful behavioral layer, though return shape and pagination are not discussed.

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 triggering question patterns, then the mechanics (place, date, cap). Every sentence carries information, though the quoted-example list makes it slightly denser than necessary.

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 still conveys what comes back ('the dated list for a place, from a start date'), the default behaviors, the coverage window, and the geographic caveat. Nothing material is missing for an agent to call it correctly.

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, but the description genuinely enriches parameter meaning: it explains the default place (New Delhi when omitted), the default start date (today), the 120-day ceiling, and example filter values for 'name'. This exceeds what the schema fields alone convey.

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+resource (returns dated Hindu festival/vrat list) with concrete query examples that map directly to intent. It is clearly distinct from siblings like daily_panchang, current_dasha, or saturn_return_dates, which serve other astrological purposes.

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?

Gives rich trigger phrasing ('when is Diwali', 'next Ekadashi', 'festivals in November') and a tactical rule for far-future festivals (set 'from' about a month before the usual season). It does not explicitly name a sibling alternative or state when NOT to use it, so it stops 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.

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it discloses the method lineage (Jaimini, not in the classical texts the readings are checked against), instructs the agent to present it as a method, and forbids promising wealth or a sum.

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 trigger phrases are front-loaded and each sentence carries distinct payload (triggers, returns, method caveat, safety guardrail). It is dense but slightly overloaded with parenthetical example queries, which cost a little tightness.

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 by enumerating the returned fields in detail, states the required inputs, and adds the interpretive caveat needed to use the result responsibly. Nothing an agent needs to invoke and present this tool is missing.

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% and all three parameters carry format examples, so the schema does the heavy lifting. The description only restates "Needs birth date, time and town," adding no syntax or precision guidance beyond what the schema already documents.

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 (Indu Lagna / money sign) and the exact user phrasings that should trigger it ("my wealth sign in astrology", "which planet brings me money"). It enumerates what is returned (money sign, its house, 9th lords and kalas, planets in/aspecting it, nakshatra, key planet), so an agent can distinguish it from generic chart tools like vedic_birth_chart.

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 opening clause gives clear when-to-use triggers via several natural-language prompts. However, it never names an alternative or an exclusion (e.g., when to prefer vedic_birth_chart or chara_karakas instead), so routing among siblings is left partly implicit.

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 (readOnlyHint, idempotentHint, non-destructive, closed-world), so the description focuses on substantive behavior: it itemizes the return contents (period length, planetary significations, effects, antardasha list with lengths and notes) and gives an interpretive framing rule ('read a period by where the planet sits in the chart, never as good or bad in itself; no fear'). It does not mention output format structure or error behavior, but the added context is well beyond the annotations.

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 trigger conditions and example queries are front-loaded, and every clause carries information (use cases, return contents, alternative tool, interpretive rule). It is dense and somewhat long, especially the enumerative middle, but no sentence is pure filler.

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?

There is no output schema, and the description compensates by enumerating exactly what comes back (length, planetary meaning, effects, timing of support vs strain, ordered antardashas with lengths, and an antardasha note). Combined with 100% schema coverage, an agent has everything needed to select and call it correctly.

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% with enums for both parameters, so the baseline is 3. The description adds meaning by explaining the relationship between the two: antardasha is a sub-period inside the mahadasha, and supplying it changes the output to include that antardasha's note.

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+resource: it explains what a mahadasha or antardasha MEANS in Vedic astrology, and it enumerates concrete query shapes it answers. It also distinguishes itself from the sibling current_dasha by scoping itself to general meaning rather than the user's own dates.

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?

Explicitly gives the when ('what does Rahu mahadasha mean', 'how long is Ketu dasha') and the when-not ('without asking for their own dates'), plus the named alternative: 'For the person's own dates use current_dasha.' Nothing is left to inference.

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 the description adds real value: it discloses what is returned (Mars position from the rising sign, Moon and Venus, and which counts flag it) and warns that the birth time drives the main count. It also sets interpretive expectations ('about half of all charts count as Manglik'), which is behaviorally useful. It stops short of covering error handling or result formatting.

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?

Four sentences, front-loaded with the triggering question before the mechanics and the interpretive caveat. Each sentence carries distinct information, with only minor redundancy around the birth-time dependency.

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 still explains what the tool returns and how accuracy depends on inputs, which is adequate for a 3-parameter read-only check. Only the response shape and edge cases (e.g. unknown birth time) are left implicit.

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, but the description adds meaning beyond the schema by explaining that birth date and town are sufficient while birth time supplies the main rising-sign count. That tells an agent why the optional parameter matters.

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 ('check' whether someone 'is Manglik or has Mangal dosha') and names the exact question it answers. It is clearly distinguishable from siblings like birth_chart_compatibility or sade_sati_check.

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?

Opens with an explicit trigger: 'Use this when someone asks if they are Manglik or have Mangal dosha.' That gives clear usage context, though it does not name the nearest alternative (e.g. compatibility matching) or state when-not to use it.

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 read-only, idempotent, non-destructive and closed-world behavior, and the description adds genuinely useful context beyond them: what is returned by default (the period running now or the next one, plus shadow dates, signs, and subsequent periods), that it needs no birth details or place, and a reassurance that this is calendrical rather than a warning. No output schema exists, so describing the payload here is valuable; batch limits or date-range bounds are not mentioned.

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 trigger conditions and example queries, then the return description. Slightly padded by the rhetorical closer 'Say it without fear: it is a stretch of the calendar, not a warning,' which costs space but does counter a common misreading.

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 zero-required-parameter read tool with strong annotations and no output schema, the description covers the when, the two output modes, and the return contents. Only the year bounds (2024-2031) visible in the schema are left unmentioned in prose, which is a minor omission.

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, but the description goes further by contrasting default behavior (current/next period) with the year parameter's effect (list every retrograde of that year), clarifying the mode switch rather than just repeating the schema text.

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?

Names a specific resource (Mercury retrograde periods) and scope (current, next, or all dates for a year) with concrete example queries, so an agent can distinguish it from the chart-based siblings like vedic_birth_chart or sade_sati_check even though no sibling is named.

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?

Gives explicit trigger conditions ('when someone asks whether Mercury is retrograde now, when the next starts or ends, or ... dates of a year') backed by three quoted user phrasings. It does not name alternative tools or state when not to use it, but the niche is narrow enough that routing is unambiguous.

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 readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds a real behavioral nuance beyond them: results are computable from date+place, and birth_time only matters on days when the Moon changes sign, which lets the agent set accuracy expectations. It does not describe pagination or output format, but neither applies meaningfully here.

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?

Compact and front-loaded with usage guidance, then boundaries. The quoted-trigger list is slightly redundant with the leading clause but earns its place by matching how agents encounter user phrasing.

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?

No output schema exists, yet the description implicitly identifies the returned values (Moon sign/rashi, nakshatra, pada), which is what an agent needs to decide the tool fits. Given a 3-parameter, closed-form astrology lookup with full annotation coverage, this is adequately complete.

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 carries the per-parameter detail and the baseline is 3. The description adds value above that baseline by explaining the dependency structure: birth_date and birth_place alone suffice, while birth_time sharpens the result only around a Moon sign change.

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?

Names the specific resource (Moon sign/rashi, nakshatra and pada) in Vedic astrology and gives the exact computation basis (birth date and town). It also draws a boundary against adjacent siblings, explicitly excluding Western sun signs, horoscopes and the rising sign (vedic_rising_sign).

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 with several natural-language trigger phrases ("birth star", "janma nakshatra", "what is my rashi"), plus an explicit when-NOT-to-use clause routing the agent away from sun-sign/horoscope/rising-sign queries. Nothing is left to inference.

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, so the bar is lower. The description adds genuinely useful behavior: no birth details required, that supplying a town converts times to local clock time, and that omitting it yields UTC. It stops short of noting output format or whether 'next full moon' can be beyond the queried date, but the added context is solid.

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?

Single front-loaded paragraph that leads with the use case before examples and the exclusion. The parenthetical example queries are slightly verbose but they double as disambiguation cues, so little is wasted.

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?

No output schema exists, but the description names the returnable facts (sign, nakshatra, phase, next full/new moon) and both timezone behaviors. Combined with annotations covering safety, an agent has everything needed to call it correctly.

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 baseline is 3, but the description adds the UTC-default fallback when 'place' is omitted, which the schema does not state. It also reinforces that date yields the Moon at midday while omission means right now. Meaningful value beyond 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?

States a specific verb+resource (where the Moon is, its sign/nakshatra/phase/next full-new moon) and scopes it to right now or a given date. It explicitly separates itself from moon_sign_nakshatra, so an agent can route without opening either 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?

Gives concrete triggering queries, states 'Needs no birth details', and names the exclusion plus the correct alternative: 'Do not use for a person's own Moon sign at birth: use moon_sign_nakshatra for that.' When-to-use, when-not, and alternative are all explicit.

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 readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior: it returns twelve day and twelve night hours counted from sunrise with clock times for the place plus the currently running hour, and it states that birth details are not required, which prevents unnecessary prompting.

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 trigger condition, then the return shape, then prerequisites. Example utterances and the 'needs the town / needs no birth details' clauses each remove real ambiguity rather than padding.

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?

No output schema exists, so the description carries the return contract and it does so adequately: hour counts, sunrise-based counting, clock times, and the current hour. Required parameter, default for date, and the no-birth-details constraint are all 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 coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: it instructs the agent to ask for the town when the user has not supplied one, and it explicitly rules out birth details as inputs. That reduces the risk of wrongly soliciting extra parameters.

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+resource: returns planetary hours (hora) for a day and place, twelve day and twelve night hours from sunrise. Clearly separable from siblings like daily_panchang, current_dasha, or moon_today, all of which answer different astrological questions.

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?

Gives explicit trigger conditions with four realistic utterances ('planetary hours today in London', 'what planetary hour is it', 'when is the Venus hour today'), which is strong context for selection. It does not name an alternative sibling or state when-not to use it, so it stops 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.

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 still adds real behavioral value by enumerating what the response contains (house meaning, planet contribution, 'our line', daily-life expression, favorable/strained conditions, optional article) and by stating no birth details are required. It adds little on caching or data recency, keeping it just under a 5.

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 dense and front-loaded: routing condition first, then examples, then the not-this-tool clause, then return contents. The long trailing enumeration of return fields is the only mildly heavy part, but each clause carries information, so there is little genuine waste.

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 must describe returns and it does so field by field, including the conditional 'our article when one exists'. Combined with explicit routing, exclusions, and the no-birth-details rule, an agent has everything needed to select and call it correctly.

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 50%: house carries a numeric range description while planet is an undocumented enum. The description compensates only indirectly, via examples that reveal accepted lowercase planet names and house values, but it defines no parameter semantics beyond what the examples imply. Baseline 3 for a partially documented two-param schema is appropriate.

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+resource combination ('what a planet in a house means in Vedic astrology') and anchors it with three concrete query examples ('Venus in the 8th house'). It explicitly distinguishes this tool from vedic_birth_chart, so an agent can route correctly without opening either 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 an explicit when-to-use condition (the person names a planet and a house, even in first person), names the alternative (vedic_birth_chart), states a usage instruction ('do not ask for birth details'), and lists out-of-scope domains (daily horoscopes, gemstones, tarot, predictions). This is a near-complete routing spec.

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 the description goes further by disclosing the return contents (each yoga, how it forms, strength band, dasha activation window, sample frequency) and the strength methodology (shadbala against classical thresholds). It doesn't note accuracy limits around inexact birth times, which matters for a time-sensitive calculation.

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 trigger conditions before the return description, which is the right ordering. The middle sentence is long and packs the yoga taxonomy in, but that vocabulary is what lets the agent match user phrasings, so it largely earns its length.

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 contract and does so thoroughly: every yoga family, per-yoga strength, timing window, and rarity benchmark. Combined with full schema coverage on inputs, an agent has everything needed to call and interpret it.

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 formats and examples for all three required parameters. The description only restates 'Needs birth date, time and town', adding no format or precision guidance beyond the schema — baseline 3 is appropriate.

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?

Names a specific verb (detect/report) and a specific resource (classical yogas in a kundli), and enumerates the exact yoga families returned, so an agent can distinguish it from a general chart tool like vedic_birth_chart. Example user phrasings further pin down what the tool answers.

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 opening 'Use this when someone asks whether they have raj yoga... how strong... when will it activate' plus five quoted sample queries gives a very clear trigger context. It does not explicitly name a sibling to prefer for full-chart questions, so it stops short of a full when/when-not routing statement.

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 readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavioral value by disclosing the return content (running now, three phases with dates, next occurrence) and the birth-data requirement, though it doesn't say what happens with an imprecise birth_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?

Front-loaded usage triggers, then return shape, then inputs — three tight sentences with no filler. Nothing is wasted, and the routing-critical condition comes first.

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?

No output schema exists, and the description compensates by summarizing the return (current status, three phases with dates, next occurrence). Annotations cover the safety profile and the schema covers inputs, so an agent has everything needed to call this correctly.

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 schema already documents format and examples for birth_date, birth_time and birth_place. The description only restates 'needs birth date and town' and adds no format or accuracy guidance beyond the schema, so the baseline 3 is appropriate.

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+resource (check Sade Sati / Saturn's 7.5-year transit) and gives the exact user phrasings it maps to, including 'Shani sade sati'. It is clearly distinguishable from siblings like saturn_return_dates and manglik_check.

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?

Explicitly states when to use it via multiple trigger phrases ('whether they are in Sade Sati', 'when it starts or ends', 'seven and a half years'), which is exactly what an agent needs for routing. It also states the required inputs at the end.

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 a pure read (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the safety profile is covered. The description adds genuinely useful behavior beyond that: the sidereal rather than tropical convention, that ALL Saturn returns are returned (not just the first), and that birth date and town are mandatory inputs to be requested if absent.

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?

Three short sentences, front-loaded with the usage triggers and closing with the input precondition, so the most decision-relevant information comes first. The quoted keyword list ('Saturn return at 28/29', Shani return) is slightly stuffed but earns its place for query matching.

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 three-parameter tool with no output schema, the description covers what is returned (dates and ages for every Saturn return) and the required inputs. The only soft spot is that it does not mention that birth_time is optional yet improves accuracy, leaving that 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 100%, so the schema already explains birth_date format, birth_place format, and the optional birth_time with its precision guidance. The description only restates that birth date and town are needed, adding no syntax or precision detail beyond the schema — baseline 3 is appropriate.

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 (returns) and resource (every Saturn return with dates and ages) and pins the reckoning system as Vedic/sidereal, which separates it from the tropical-astrology siblings. It also names colloquial variants (Shani return, 'Saturn return at 28/29') so an agent can match natural user phrasing.

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?

Gives explicit trigger conditions: when someone asks when their Saturn return is, whether they are currently in it, or at what ages it occurs. It does not explicitly name the nearest alternative (sade_sati_check, the other Saturn-transit tool), so the agent must infer the boundary, but the stated conditions are clear enough to route correctly.

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 readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, covering safety. The description adds valuable behavioral context: it specifies the returned calculations (Sun, Moon, all planets both ways, ayanamsa, and rising sign when birth time is given), which goes beyond the annotations.

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 front-loaded with the usage trigger, followed by a clear statement of outputs and input requirements. Every sentence serves a distinct purpose without redundancy, and the embedded example queries are useful for an agent without bloating the text.

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?

Given no output schema and simple annotations, the description fully covers what the agent needs: when to use it, what it returns, and how the optional birth time affects output. It is complete for a read-only calculation tool with a fully documented input 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 100%, so the baseline is 3. The description adds minor semantic value by noting that with a birth time the rising sign is returned both ways, implicitly clarifying the role of the optional birth_time parameter, but it does not elaborate on the required inputs beyond what the schema already documents.

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 purpose: comparing Vedic (sidereal) and Western (tropical) zodiac signs, with concrete example user questions. It clearly distinguishes this tool from Vedic-only siblings like vedic_birth_chart by emphasizing the side-by-side comparison and the inclusion of Western signs.

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 provides clear triggering contexts with example queries (e.g., 'I am a Leo, what am I in Vedic astrology'), which tells the agent exactly when to use it. However, it does not explicitly state when to avoid this tool or name alternative tools for related tasks.

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 establish read-only, idempotent, non-destructive behavior, so the description's job is to add context — which it does by detailing the nine-planet output with sign, degree, house, nakshatra/pada, and D9 sign, and by flagging that house data depends on birth time. It does not cover any auth or rate-limit behavior, but none is evidently relevant here.

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?

Dense but every sentence carries load: synonyms first, then return contents, then the routing rule, then prerequisites, then exclusions. Front-loaded and free of filler.

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?

There is no output schema, but the description compensates by enumerating the returned fields. Combined with the routing and exclusion guidance, an agent has everything needed to select and invoke this tool correctly.

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 baseline is 3; the description adds real meaning by explaining the conditional role of birth_time (needed for houses) and clarifying that birth_place is a town/city with region or country. That goes beyond the schema's format-only descriptions.

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+resource ('Vedic birth chart') and enumerates the user phrasings it covers (kundli, janam kundali, sidereal chart) plus the exact output contents (signs, houses, nakshatras, rising sign). This clearly separates it from siblings like vedic_rising_sign or moon_sign_nakshatra.

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?

Explicitly routes narrower requests ('rising sign, Moon sign, dasha, Manglik') to other tools and states exclusions ('Do not use for Western/tropical charts or daily horoscopes'). It also gives the prerequisite-filling instruction ('ask if missing') for a required input.

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. The description goes beyond them by disclosing the return contents (rising sign, ruler, and a Western sign for comparison) and flagging that it needs the birth time, which no annotation conveys.

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?

Three short sentences, front-loaded with the trigger and then the return contents. Only the closing 'Needs the birth time' is mildly redundant with the schema's required list.

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 usefully enumerates what comes back (Vedic rising sign, ruler, Western rising sign), covering trigger, inputs, and outputs. It is complete enough, though it could note why birth-time precision affects the result.

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% and each field's format is documented there. The description adds only 'Needs the birth time,' which restates a required parameter without new syntax or precision guidance, so 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?

Specific verb+resource: it returns the Vedic rising sign (lagna), its ruler, and the Western rising sign. That scope is clearly distinct from siblings like moon_sign_nakshatra or vedic_birth_chart, so an agent can route without opening the 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?

Explicit trigger phrasing: 'Use this when someone asks for their rising sign, ascendant or lagna... or why their Vedic rising sign differs from a Western app.' It covers intent well but names no alternative tool and gives no when-not condition.

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), and the description goes well beyond them: it discloses that the day rules are a custom and not in the classical texts used for validation, and explicitly instructs the agent to say so. That is a genuine limitation/authenticity caveat an agent must relay, plus input prerequisites (birth date and town).

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 trigger scenario, then the return shape, then the caveat and requirements. Dense and mostly waste-free, though the long run-on sentence listing tarabala/chandrabala and the explicit 'say so' instruction make it longer than strictly necessary.

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?

No output schema exists, and the description fully covers what comes back: a 60-day range, each day's weekday, nakshatra, tithi, tarabala and chandrabala counts, favouring flags, and the vehicle-linked planet. Combined with the caveat and input requirements, an agent has everything needed to call and interpret it.

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 baseline is 3. The description's parameter-relevant content ('Needs birth date and town; town_now sets the time zone of the days') largely restates what the schema already says for town_now (

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+resource: computing auspicious days (muhurat) to buy a vehicle from birth details. The returned content (next 60 days with nakshatra, tithi, tarabala, chandrabala, vehicle planet) is distinctive enough to separate it from siblings like daily_panchang or festival_and_vrat_dates.

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?

Opens with an explicit trigger ('Use this when someone asks for a good day or muhurat to buy a car, bike or other vehicle') and supplies three literal user phrasings, which is strong routing guidance. It does not name a sibling alternative or state when not to use it, so it stops 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.

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. Beyond that, the description adds useful context about output components (shadow dates, signs in both zodiacs, Sun conjunction), the default behavior when no year is supplied, and the cycle frequency (about every 19 months for six weeks). It does not fully explain pagination or response shape, but no output schema exists and the important behavioral notes are present.

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 front-loaded with use cases and return contents, and every sentence largely earns its place. The final reassurance ('Say it without fear...') is stylistic rather than strictly selection-critical, keeping it just below the highest score.

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 explaining what is returned, which it does: periods, shadow dates, signs in both zodiacs, and Sun conjunction dates. It also covers prerequisites (none) and cadence, making it complete for this tool's 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 year parameter is already documented. The description adds meaning by stating the default behavior: with no year it returns the period running now or the next one, while specifying a year lists every Venus retrograde touching that year. That is value beyond 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 states a specific subject and resource—Venus retrograde dates—and enumerates the exact questions it answers, including 'is Venus retrograde now' and 'Venus retrograde 2026'. It implicitly distinguishes itself from nearby planetary tools like mercury_retrograde and saturn_return_dates by focusing solely on Venus.

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 explicit triggering conditions and example phrasings, and explains that the tool needs no birth details or place. This is exactly the when-to-use guidance an agent needs, with alternatives implicitly excluded by the Venus-specific scope.

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