VedaVisor Vedic Astrology MCP

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

No annotations are provided, so the description carries the full burden, and it does substantial work: it discloses the AI/non-template nature, the internal pipeline (full chart computation, yogas, dashas, transits, dignity, house lords), multi-paragraph output, domain routing, and a licensing/usage policy restricting resale and requiring attribution. It stops short of disclosing latency, determinism, or rate/cost characteristics that an agent weighing an expensive AI call would want.

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?

Heavily front-loaded with clear labeled sections (WHEN TO USE, WHAT IT DOES, RETURNS, USAGE POLICY, NEXT) that map directly to the agent's decision. It is longer than strictly necessary, and the licensing paragraph is more contract language than invocation guidance, but the structure keeps it navigable.

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 10-parameter AI interpretation tool with no annotations and an existing output schema, the description covers purpose, triggering conditions, internal behavior, domain routing, output shape, policy constraints, and fallback siblings. An agent has everything needed to decide whether and how to call 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 0%, so the description must compensate across 10 parameters. It usefully enumerates the valid domain values (career, relationships, health, finance, education, travel, property, general) which the schema leaves as a bare string, but it says nothing about the birth-data parameters (year/month/day/hour/minute, latitude, longitude, timezone_offset) or their formats and India-centric defaults.

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 ('Ask an in-depth, chart-aware astrological question') and immediately differentiates itself as 'AI-powered, not template-based'. It also names the sibling tools it is not (calculate_birth_chart for raw data, ask_prashna for yes/no horary), 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?

The WHEN TO USE block defines the triggering condition precisely ('open-ended question about their life, chart, or future that needs deep Vedic interpretation'), and the NEXT block explicitly names alternatives and their use cases. Exclusions ('not a simple lookup table or template prediction') 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?

With no annotations, the description carries the full burden, and it does meaningful work: it discloses that the verdict is deterministic, that a confidence score and contributing factors are produced, and that the result is grounded in a chart cast for the question moment. It does not state read-only/permission properties, but the described computation makes the non-mutating nature evident.

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 labeled WHEN TO USE / WHAT IT DOES / RETURNS structure is front-loaded and scannable, with no filler. The inline RETURNS paragraph is somewhat redundant given an output schema exists, which is the only small 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?

For an 8-parameter tool the description is silent on how to supply the inputs, which is the main gap; however, an output schema exists so enumerating the return shape is not strictly required. It is adequate for selection but thin for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 8 parameters, so the description must compensate and largely does not. It hints at a 'moment chart' (implying year/month/day/hour) but says nothing about latitude/longitude being required geolocation, the question string format, or the timezone_offset default of 5.5.

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: 'Answer a Prashna (horary) question using a moment chart', and the WHAT IT DOES section pins down the mechanism (cast chart, map domain, produce verdict). This is clearly distinguishable from siblings like calculate_birth_chart or ask_cosmic_advisor 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?

The WHEN TO USE block gives an explicit trigger condition: a focused yes/no/maybe question wanting horary guidance. It lacks any exclusions or named alternatives (e.g., when to prefer ask_cosmic_advisor instead), so an agent could still hesitate between the two advisory tools.

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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: it computes the birth chart, detects which dasha systems apply, and returns the current period per system. It lacks disclosure of edge cases (e.g. sensitivity to birth-time accuracy, computation cost) and whether any permissions/limits apply, so it falls short of exhaustive.

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?

Labeled sections (WHEN TO USE / WHAT IT DOES / RETURNS / NEXT) front-load the routing decision and keep each sentence earning its place. No filler or redundancy.

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 the description needn't define return values, and its RETURN summary plus NEXT guidance round out a 9-param tool. The one real gap is the complete absence of parameter explanation against 0% schema coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% with 9 parameters, so the description must compensate and largely does not. Only 'depth' is indirectly referenced ('sub-periods at the requested depth'); birth date/time, latitude, longitude, timezone_offset, and their defaults are never explained. Parameter names are mostly self-evident, which keeps this above a 1.

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 ('Calculate all applicable dasha systems') and explicitly distinguishes itself from Vimsottari-only analysis, naming the sibling systems (Ashtottari, Kalachakra, Narayana, Shoola). An agent can tell it apart from calculate_vimsottari_dasha and calculate_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?

The WHEN TO USE block gives an explicit trigger (need analysis beyond Vimsottari), and the NEXT line names the alternative (calculate_birth_chart) with the exact condition that selects it ('if you only need Vimsottari dasha'). 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?

With no annotations, the description carries the full burden. It discloses the computation and the return shape, and 'Calculate' reasonably implies a pure, side-effect-free operation, but it says nothing about determinism, prerequisites (what date/place basis is needed), latency, or error behavior.

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 labeled WHEN TO USE / WHAT IT DOES / RETURNS structure is front-loaded and scannable, and no sentence is pure filler. The WHEN TO USE claim is somewhat redundant with WHAT IT DOES, keeping it just short of a 5.

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 describing return values is optional rather than required. The definition is still incomplete on the input side: for a calculation that needs an 8-parameter date/time/place tuple, nothing tells the agent which datetime and location to supply.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 8 parameters, so the description must compensate and does not. It never explains that year/month/day/hour form the birth or reference datetime, nor that latitude/longitude/timezone_offset default to India (20.59, 78.96, 5.5) — a default an agent could easily apply unintentionally.

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 verb and resource ('Calculate Ashtakavarga (eight-fold strength) tables') and spells out the two table types produced (bhinna- and sarva-ashtakavarga bindus). It does not, however, differentiate this from sibling calculations like calculate_transits or calculate_birth_chart, which an agent must distinguish between.

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 WHEN TO USE section states a context ('for transit analysis and planetary strength'), but it largely restates the tool's own output ('needs the bhinna-ashtakavarga and sarva-ashtakavarga bindus'). There are no exclusions or named alternatives, so the agent is left to infer when this beats calculate_transits or calculate_birth_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?

With no annotations, the description carries the full burden, and it discloses the calculation method (sidereal/Lahiri, professional-grade engine) and the exact return shape. It does not state whether input time is local or UTC beyond the timezone_offset param, nor any constraints on date ranges, which leaves a behavioral gap for a computation-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?

Labeled sections (WHEN TO USE / WHAT IT DOES / RETURNS / NEXT) make it skimmable and front-loaded, with no redundant or filler sentences. Every line carries actionable content.

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 an 8-param, output-schema-backed calculation tool with no annotations, the description covers purpose, invocation context, and downstream routing well. The remaining hole is parameter interpretation (time basis, geo defaults), which is the one thing an agent can most easily get wrong.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description adds nothing about the 8 parameters. It never explains that hour/minute are local clock time interpreted via timezone_offset, nor the meaning of the India-centric latitude/longitude defaults, so an agent must guess at the most error-prone 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?

It names a specific verb+resource ('Calculate a complete Vedic birth chart (Kundli)') and scopes it precisely (high-precision sidereal positions, Lahiri ayanamsa). This distinguishes it from siblings like calculate_varga_charts or calculate_all_dashas, which build on the chart rather than produce it.

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 WHEN TO USE block gives a clear triggering condition (needing a chart to analyze planets, houses, nakshatras, yogas) and the NEXT line routes to calculate_vimsottari_dasha/ask_cosmic_advisor as downstream consumers. It stops short of explicit exclusions, e.g. telling the agent not to call this when only a dasha or transit is needed.

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?

With no annotations, the description carries the full disclosure burden. It does explain what is computed and roughly what comes back, which is more than nothing, but it says nothing about determinism, side effects, the timezone assumption underlying the inputs, or whether the two charts must share a timezone — relevant context for a 15-parameter computation.

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 core purpose, then cleanly labeled WHEN TO USE / WHAT IT DOES / RETURNS blocks. The RETURNS section is partly redundant with the output schema, but the whole thing stays tight and scannable.

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?

Purpose and output shape are covered, and an output schema exists so return values need no elaboration. However, for a tool with 14 required parameters and zero schema documentation, the description should at minimum explain the dual-birth-detail input contract and the timezone default; that gap is the main incompleteness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description explains none of the 15 parameters. Field names like year1/lat1/minute2 are mostly self-evident, but the description never states that two full sets of birth date/time/coordinates are required, nor does it clarify tz_offset semantics or that its 5.5 default is India Standard Time — a significant omission for global 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 verb (Calculate) and resource (Vedic compatibility / Kundli matching) plus the named framework (Ashtakoota, Guna Milan, Manglik dosha, Nadi). Among siblings full of single-chart tools (calculate_birth_chart, calculate_varga_charts, calculate_yogas), this is the only two-person relationship tool, so it is trivially distinguishable.

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 explicit WHEN TO USE line gives a clear triggering condition (an agent needs to evaluate relationship compatibility). It does not name an alternative or an exclusion, but no sibling performs compatibility scoring, so there is little ambiguity to resolve.

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?

No annotations are provided, so the description carries the full burden; it discloses that this is a computation scoped to a supplied location and timezone offset and details the returned data (muhurat windows, choghadiya divisions). It stops short of noting behavioral caveats such as the effect of ayanamsa_mode or the 0,0 latitude/longitude defaults, keeping it from 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?

The labeled sections (WHEN TO USE / WHAT IT DOES / RETURNS / NEXT) are front-loaded and scannable, with no filler. The RETURNS section is somewhat redundant given the output schema exists, costing a point on pure economy.

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?

Purpose and return content are well covered (and the output schema handles structured returns), but for an 8-parameter tool with zero schema description coverage the semantics of the inputs are left to inference. Adequate at the top level but incomplete on parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 8 parameters, so the description must compensate but largely does not. It only gestures at 'supplied location and timezone offset,' leaving year/month/day, hour, and especially ayanamsa_mode entirely unexplained.

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 (Calculate) and resource (Panchanga/Vedic calendar factors) and enumerates the exact factors produced (tithi, nakshatra, yoga, karana, weekday). It also differentiates from a sibling by directing person-specific work to calculate_birth_chart, so an agent can distinguish it 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?

The 'WHEN TO USE' line gives a concrete context (planning or interpreting a date) and the 'NEXT' line names the alternative (calculate_birth_chart) for person-specific interpretation. It lacks explicit when-not/exclusion conditions, but the routing guidance is clear.

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?

No annotations are provided, so the description carries the full burden. It discloses the computation's inputs and outputs, and 'Calculate' implies a pure, side-effect-free computation, but it never explicitly states that nothing is mutated, whether it is deterministic, or any auth/permission needs. Adequate but not rich behavioral disclosure.

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?

Cleanly organized with WHEN TO USE / WHAT IT DOES / RETURNS headers, front-loading the purpose. Every sentence carries substantive information with no filler, and the size fits the tool's complexity.

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 pure calculation tool with an output schema already present, the description covers purpose, usage trigger, computed components, and output shape. The main gap is parameter semantics (defaults, ranges), which is a minor shortfall given the tool's otherwise simple, stateless nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for all four parameters. 'From name and birth date' plus 'radical number (from day)' and 'destiny number (from full date)' loosely map name/day/month/year to their roles, but format, valid ranges, and the meaning of the defaults (day=1, name='', year=2000, month=1) are never explained.

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 (Calculate) and resource (full numerology profile from name and birth date), and names the exact techniques involved: Chaldean name numerology, radical number from day, destiny number from full date. The domain is clearly distinct from every sibling, which are all Vedic astrology tools (dashas, vargas, transits), so an agent can route to it unambiguously.

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 'WHEN TO USE' section gives a clear triggering condition: when the agent needs Chaldean name numerology plus DOB-based radical/destiny numbers with life-aspect scores. It does not name alternatives or state when NOT to use it (e.g., vs. calculate_birth_chart for astrology), but the context is explicit enough to select the tool.

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?

No annotations are provided, so the description carries the full burden. It discloses the computation basis (planetary degrees), the two karaka families, and the JSON return payload with named fields — useful context. It omits dependency/prerequisite behavior, whether results are deterministic, and whether it fetches chart data itself.

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 WHEN TO USE / WHAT IT DOES / RETURNS headers make it scannable and front-loaded, with no filler sentences. The RETURNS block is slightly redundant given an output schema exists, but the overall structure is efficient.

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 an 8-parameter tool with zero schema documentation and no annotations, the description leaves the most important question unanswered: whether the datetime is the birth moment or the current moment, and what the location/timezone defaults mean. Having an output schema excuses it from explaining returns, but the input story is materially incomplete.

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?

Eight parameters with 0% schema description coverage, and the description says nothing about any of them. The four required fields (year/month/day/hour) are ambiguously birth data vs. query time, and the India-centric latitude/longitude/timezone defaults are never surfaced. It does not compensate for the coverage gap.

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 ('Calculate Chara and Sthira Karakas') and explains both variants — variable significators from planetary degrees vs. fixed significators. It never names a sibling tool or distinguishes itself from calculate_birth_chart, calculate_yogas, etc., so it falls short of the 5 bar.

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?

'WHEN TO USE: When an agent needs to identify the key planetary significators in a chart for specific life areas' gives a genuine trigger condition, which is more than most. But there are no exclusions, no mention of prerequisites (e.g., that planetary longitudes must already be known), and no routing against the many sibling calculation tools.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that this is a pure computation with defined outputs and reveals downstream sequencing, which is useful. However, it says nothing about permission/auth needs, determinism versus ephemeris recalculation, or how missing/partial inputs behave across the 9 parameters.

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?

Labeled WHEN TO USE / WHAT IT DOES / RETURNS / NEXT blocks make it front-loaded and scannable, and each section carries information. The RETURNS section partially duplicates the existing output schema, which is the one mildly wasteful element.

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 not explaining return values in depth is acceptable, and the when/next guidance is complete. But for a 9-parameter tool with 0% schema description coverage, the complete absence of parameter guidance is a real gap an agent cannot fill from structured data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 9 parameters, so the description must compensate and largely does not. It only incidentally implies target_year ("for the target year") and never explains units or formats for hour, minute, latitude, longitude, or timezone_offset, nor that lat/long have defaults.

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?

Uses a specific verb and resource ("Calculate the annual Tajaka solar return chart and aspects") and immediately disambiguates the sub-domain: Varshaphala chart, Muntha, and Tajaka aspects. This is distinguishable from Vedic siblings like calculate_birth_chart or calculate_varga_charts without opening 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?

Has an explicit WHEN TO USE clause plus a NEXT clause that routes to calculate_varshaphala for the full report and ask_cosmic_advisor for interpretation. The condition selecting each alternative is stated, not 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?

No annotations are present, so the description carries the full behavioral burden. It does disclose the computed outputs and return shape, which is useful, but it never states that this is a read-only, side-effect-free calculation, nor does it address the India-centric defaults (lat 20.59, lon 78.96, tz 5.5) or ayanamsa sensitivity that materially affect results.

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 one-line purpose, then cleanly partitioned into WHEN TO USE / WHAT IT DOES / RETURNS. Labels are efficient, though the RETURNS block partially duplicates the existing output schema, which adds some redundancy.

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?

Because an output schema exists, the return enumeration is not strictly needed, and the main gap is the undocumented parameter set at 0% coverage for a complex 8-parameter astronomical calculation. The description is serviceable for invocation but incomplete on the inputs an agent must reason about.

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 0% across 8 parameters, so the description must compensate. It conveys date and location inputs generally ('at the given date and location') but says nothing about hour, timezone_offset, or ayanamsa_mode, which are all result-affecting. Five of eight parameters remain semantically undocumented.

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 ('Calculate current planetary transit positions for a date') and defines what is computed (sidereal longitudes, nakshatras, signs, houses, retrograde status). It gives strong domain framing (gochara, mundane astrology) but does not explicitly distinguish itself from siblings like get_weekly_transit_events, so it stops short of a 5.

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 'WHEN TO USE' line gives clear triggering context ('where planets are right now or on a specific date for transit analysis'). However, it names no alternatives or exclusions, leaving the agent to infer when this beats get_weekly_transit_events or find_auspicious_times.

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?

No annotations are provided, so the description carries the full burden. It discloses the computation basis (classical Vedic varga rules) and the return shape, which is useful, but says nothing about permission needs, computational cost, error behavior on invalid D-N codes, or how the birth data is interpreted.

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 labeled sections (WHEN TO USE / WHAT IT DOES / RETURNS) front-load the decision-relevant information and there is no filler prose. The long literal D-N enumeration is the only part that borders on bloat, though it is genuinely useful.

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 9-parameter tool with zero schema coverage and no annotations, the description is incomplete: it never explains that latitude/longitude/timezone default to India-centric values, nor how date/time inputs are interpreted. The output schema exists, so the RETURNS sentence is acceptable rather than necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does add genuinely useful syntax for varga_list (comma-separated D-N names with a full example), but leaves the required year/month/day/hour plus latitude, longitude, and timezone_offset completely undocumented in both places.

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 (calculate divisional/Varga charts) and immediately distinguishes itself from the D-1 baseline produced by calculate_birth_chart. An agent can tell this apart from calculate_ashtakavarga or calculate_yogas 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?

The 'WHEN TO USE' block gives a clear triggering condition (needs charts beyond D-1) plus concrete examples (D-9 for relationships, D-10 for career). It lacks an explicit negative case or a named sibling alternative, but the boundary against calculate_birth_chart is implied clearly.

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?

With no annotations, the description carries the burden and does disclose the output structure in detail ('RETURNS: JSON with all Varshaphala sections: solar_return_chart, varshesha, muntha...'), making the result shape predictable. It omits prerequisites (birth data is mandatory), whether anything is persisted, and any performance/cost expectations, so it is good but not complete.

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 WHEN TO USE / WHAT IT DOES / RETURNS structure is front-loaded and scannable. The component list is partially repeated between the WHEN TO USE and WHAT IT DOES blocks, which is mild redundancy rather than 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?

This is an 11-parameter tool with 5 required parameters and 0% schema coverage, and the description gives no guidance on supplying birth data, coordinates, timezone offset, or ayanamsa selection. The output schema exists, so explaining return values is optional, but the invocation side is materially under-specified 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 description coverage is 0% across 11 parameters, and the description adds no parameter-level meaning whatsoever — target_year, ayanamsa_mode, house_system, tz_offset, and the birth date/time fields are all left for the agent to infer. Only indirectly does 'annual prediction' hint at target_year's role.

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 and resource ('Calculate the full Varshaphala (annual prediction) report') and enumerates the pipeline components (solar return chart, Muntha, Varshesha, Mudda dasha, Sahams, Tajaka yogas, monthly outlook), which lets an agent distinguish it from narrower siblings like calculate_tajaka or calculate_vimsottari_dasha.

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 'WHEN TO USE' block gives an explicit trigger condition: a comprehensive annual forecast for a person. It lacks any when-not guidance or named alternatives (e.g., use calculate_tajaka for only the Tajaka portion), so it falls short of a full 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?

No annotations are provided, so the description carries the full burden. It does disclose the computation method (derived from the Moon's nakshatra at birth) and the scope of the timeline with antardashas, and an output schema exists so return shape is covered elsewhere. However, it says nothing about prerequisites, determinism, or that the supplied date/time is the birth moment rather than the current 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?

Uses labeled sections (WHEN TO USE / WHAT IT DOES / RETURNS / NEXT) that are front-loaded and scannable. Every line earns its place and no sentence restates 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?

The output schema means the RETURNS section is a helpful convenience rather than a necessity, and purpose/usage are adequately covered. The gap is parameter documentation: for an 8-parameter, 0%-coverage schema, the description should at minimum clarify that the date/time inputs are the birth moment and what the geo/timezone defaults mean.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 8 parameters, so the description must compensate and largely does not. Only the oblique phrase 'at birth' hints that year/month/day/hour/minute are the birth moment; latitude, longitude, and timezone_offset (defaulted to Indian coordinates and +5.5) are never explained, leaving the agent to guess whether defaults are 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 and resource: 'Calculate the Vimsottari Mahadasha sequence and current period,' and the WHAT IT DOES line adds the computation basis (Moon's nakshatra at birth) and 120-year timeline. It is clear, though it never names the obvious sibling calculate_all_dashas, so the agent must infer the boundary between this and the all-systems tool.

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 WHEN TO USE line gives a concrete trigger: the agent needs the planetary period a person is currently running, plus upcoming periods. It also provides a sequencing hint ('NEXT: Use calculate_birth_chart'). It stops short of explicit when-not conditions or naming calculate_all_dashas as an alternative.

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?

With no annotations, the description carries the full burden and does disclose that yogas are computed from D-1 planetary positions including special lagnas, and that the result is a JSON list. It implies a pure read/computation but never explicitly says nothing is mutated or persisted, leaving a small gap.

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?

Labeled sections (WHEN TO USE, WHAT IT DOES, RETURNS, NEXT) are front-loaded and every sentence carries information. No filler or repetition of the title.

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 need not be detailed, and the description still summarizes the JSON list of names and descriptions. The remaining gap is the un-documented 8-parameter input surface, which matters for a compute tool taking coordinates and timezone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 8 parameters, and the description adds no parameter meaning at all — nothing about latitude/longitude, timezone_offset defaults, or how hour/minute are interpreted. Date/time/location inputs are somewhat self-evident, but the description fails to compensate for the coverage gap.

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 (calculate) and resource (planetary yogas in a birth chart), and enumerates concrete yoga families (Pancha Mahapurusha, Raja, Dhana). This clearly separates it from siblings like calculate_birth_chart or calculate_karakas.

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 'WHEN TO USE' block gives an explicit trigger condition and the 'NEXT' line routes the agent to ask_cosmic_advisor for interpretation. It does not state when NOT to use it or name a competing yoga-related tool, so it falls short of a full 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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: it computes the chart, builds a prompt, and produces a 3-4 paragraph AI-generated message, plus the JSON return shape. It does not mention generation latency, cost, or any auth/rate-limit considerations for an AI-backed tool, leaving a modest gap.

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 headers (WHEN TO USE / WHAT IT DOES / RETURNS / NEXT) make it scannable and each section adds distinct value. It is slightly verbose in prose but no sentence is redundant, so it stays close to an ideal structure.

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 the RETURNS line is a bonus rather than a necessity. Usage, purpose, and behavior are well covered for an AI-backed generation tool, but the total absence of parameter guidance against 9 undocumented inputs is the one real completeness gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 9 parameters, so the description must compensate but says nothing about any input. It never explains the birth date/time fields, the timezone_offset default of 5.5, or the latitude/longitude defaults, leaving the agent to infer everything from parameter names alone.

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 (generate a personalized daily horoscope from a birth chart) and explicitly differentiates itself from sibling get_daily_rashifal by contrasting chart-aware generation against the generic-paragraph service. An agent can distinguish it from calculate_birth_chart and get_weekly_horoscope 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?

Provides an explicit WHEN TO USE clause naming the exact trigger (chart-aware daily prediction using birth chart, transits, dasha) and the anti-pattern it avoids (basic rashifal). The NEXT line routes the agent to calculate_birth_chart when only raw chart data is needed, giving a clear alternative.

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?

With no annotations, the description carries the full burden and does disclose the scoring mechanism (Panchanga factors + task-specific nakshatra rules) and ranked output. It does not state whether the operation is read-only/side-effect-free or mention any rate/permission constraints, but for a deterministic computation tool the disclosure is strong.

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?

Labeled sections (WHEN TO USE / WHAT IT DOES / RETURNS / NEXT) are front-loaded and each sentence earns its place; no filler or repetition of 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?

An output schema exists, so the brief RETURNS summary is sufficient, and the description covers purpose, trigger, and follow-up. The remaining gap is parameter documentation, which is the one thing the rich structured fields do not supply.

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 0% across 6 parameters, so the description must compensate. It only indirectly hints at task_type values (marriage, travel, business, etc.) and says nothing about date formats, latitude/longitude meaning, or the timezone_offset default, leaving five required parameters essentially undocumented.

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 ('Find favorable Muhurta windows') and immediately scopes it as scoring days in a date range by Panchanga/nakshatra rules. It is clearly distinguishable from siblings like calculate_daily_panchanga or ask_prashna, which are named or implied as adjacent but different.

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 WHEN TO USE block names the exact trigger ('best dates or time windows to start an activity') and enumerates concrete task domains, and the NEXT line routes the agent to ask_cosmic_advisor for interpretation. This is explicit when-to-use and alternative routing.

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?

Without annotations, the description clarifies that it returns cached sign-level data, not a personalized chart reading, and specifies the output structure. It does not, however, mention any permission, rate limit, or data freshness/determinism concerns beyond 'cached'.

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?

Well-structured with clear sections (WHEN TO USE, WHAT IT DOES, RETURNS, NEXT). Slightly verbose in places but every sentence provides useful guidance or routing 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?

For a single-parameter, read-only tool with an output schema, the description covers purpose, usage boundaries, return format, and a next step. The only gap is the lack of parameter naming/format guidance, but that is minor given the simple parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the sole parameter 'sign_name' is undocumented in both schema and description. The description's meaning of 'rashi (Moon sign)' gives some context but does not fully specify accepted sign names or format. Baseline 3 reflects partial semantic support.

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 ('Get the daily Vedic horoscope (Rashifal) for a zodiac sign') and distinguishes itself from sibling tools by explicitly noting it is sign-based and not personalized. It names daily_horoscope as the alternative for a more detailed, chart-aware reading.

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 section specifies the condition ('today's prediction for a specific rashi'). It clearly contrasts with daily_horoscope (Pro tier, chart-specific) and even suggests a prerequisite (calculate_birth_chart to find the Moon sign).

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?

With no annotations, the description carries the full burden and does disclose real behavior: it is AI-generated rather than template-based, it computes the natal chart, detects transit events, and accounts for planetary motion between week start and week end. It omits operational traits such as latency/cost of the AI generation and error behavior when birth data is invalid, which keeps it short of 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?

Header-labeled sections (WHEN TO USE / WHAT IT DOES / RETURNS / NEXT) front-load the purpose and make scanning easy. It is slightly verbose for a tool definition, but each block carries distinct routing or behavioral information, 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?

RETURNS is documented and an output schema also exists, so return-shape coverage is adequate, and routing/alternatives are thoroughly handled. However, with 9 parameters at 0% schema coverage, the definition leaves the central birth-data parameter semantics ambiguous, which is a real gap for a required-4-parameter 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 description coverage is 0% across 9 parameters, so the description must compensate and largely does not. It never states that year/month/day/hour/minute/latitude/longitude/timezone_offset are birth date-time and birthplace coordinates (versus the target week), nor what user_name or the timezone default affect, leaving the agent to infer the mapping from 'Computes the birth chart' alone.

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 ('Generate an in-depth, chart-aware weekly horoscope') and immediately differentiates it from 'one-line rashifal predictions' produced by sibling tools like get_daily_rashifal. The WHAT IT DOES section names the exact inputs it operates on (natal placements, transits), so an agent can tell it apart from the deterministic transit and daily horoscope siblings 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?

Explicit WHEN TO USE section describes the user intent that selects this tool ('detailed weekly guidance that accounts for their specific birth chart and this week's exact transits'). It names the alternative explicitly ('Use get_weekly_transit_events for just the deterministic events') and contrasts against one-line rashifal predictions, so both the positive and negative routing conditions 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?

With no annotations, the description carries the full burden, and it does disclose substantive behavior: scope (all nine planets), event categories detected, and the current-or-requested week window. It does not explain the default behavior implied by zeroed day/year/month fields or any auth/limit considerations, so gaps remain for a no-annotation 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?

Labeled sections (WHEN TO USE, WHAT IT DOES, RETURNS, NEXT) make it front-loaded and scannable, with the core purpose in the first line. Each block adds real information, though the RETURNS block partly duplicates the existing output 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?

Purpose, usage, and follow-up routing are complete, and the output schema relieves the description of explaining return values. However, for a five-parameter tool with 0% schema coverage and no annotations, the total silence on parameter meaning leaves the definition only minimally viable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across five parameters, and the description never explains any of them. It only hints that the week can be 'current or requested', leaving the interaction between day/year/month and iso_week, plus ayanamsa_mode, entirely opaque to the agent.

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 ('Get this week's major planetary transit events') and enumerates the event types it detects (sign/nakshatra ingresses, stations). This clearly separates it from a generic 'calculate_transits', though it never names that sibling explicitly to draw the boundary.

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 'WHEN TO USE' block gives a concrete trigger (needing this week's transits for predictions or planning) and 'NEXT' routes the agent onward to calculate_birth_chart for natal aspecting. No exclusion against calculate_transits is stated, but the context and follow-up are clear.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool computes the chart and returns deterministic recommendations, which is helpful, but says nothing about permissions, side effects, rate limits, or whether output is purely advisory.

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 and broken into WHEN TO USE, WHAT IT DOES, and RETURNS sections. Every sentence adds concrete information without redundant restatement.

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?

Because a full output schema exists, the description need not enumerate return values, though RETURN text is still useful. The major gap is parameter semantics at 8 params with zero schema descriptions and no annotation coverage, which makes the definition under-informative for invocation details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for 8 parameters, so the description must compensate. It only implies birth details are needed and does not explain required fields, formats, timezone_offset, or the defaults for latitude, longitude, minute, or timezone.

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: recommend Vedic remedies from a birth chart. It clearly distinguishes itself from calculation siblings by being prescriptive rather than analytical, but it does not name siblings like ask_cosmic_advisor that could also be used for remedial advice.

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 WHEN TO USE section gives a concrete condition: user asking about remedies for planetary afflictions or life challenges with birth details available. It does not state when not to use it or name explicit alternatives such as calculate_birth_chart or ask_cosmic_advisor.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the upstream provider (OpenStreetMap Nominatim) and hedges that timezone_offset is only present 'where available', but it says nothing about rate limits, auth requirements, or error/empty-result behavior for a third-party geocoder.

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 one-liner followed by clearly labeled WHEN TO USE / WHAT IT DOES / RETURNS / NEXT sections — easy to scan. The RETURNS block partially duplicates the existing output schema, which is a small redundancy.

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 an output schema exists, the return-value explanation is a bonus rather than a necessity. The main remaining gap for a zero-annotation, third-party-backed tool is operational context (rate limits, failure modes), but the core call path is fully described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It implies the meaning of 'query' through the resolve framing, but the 'limit' parameter (default 8) is never mentioned or explained, leaving one of two parameters undocumented in both schema and description.

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 (resolve) and resource (place name) with the concrete outputs (geo-coordinates, timezone). It is trivially distinguishable from every sibling, which are all astrology calculations rather than geocoding.

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 WHEN TO USE block gives a precise triggering condition ('agent has a city or place name but needs latitude, longitude, and timezone offset') and the NEXT line routes the agent onward to calculate_birth_chart. It lacks any 'when not to use' clause, but no sibling competes for this job.

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