Jagannatha Hora — Vedic Astrology (Jyotish, Kundli, Horoscope, Panchang)

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful behavioral context beyond those annotations: the tool caches its computed chart and must be called before later tools. No contradiction with annotations is 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 two focused sentences: the first defines purpose and output, the second defines usage ordering. Every sentence earns its place with no 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 the rich schema and annotations, the description provides the essential missing context: what the tool returns and that it initializes a cache reused by later tools. No output schema exists, but the summary fields are explicitly listed, so the agent knows what to expect.

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 every parameter, including the detailed optional gender behavior. The description's phrase 'birth date, time and place' adds only a high-level summary and no new parameter-level meaning.

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: generate a Vedic (sidereal) birth horoscope and return a concise summary with ascendant/lagna, moon sign, sun sign, and birth nakshatra/pada. It also differentiates this tool from the many get_* siblings by positioning it as the first/caching 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?

It explicitly says 'Call this first' and explains that later tools reuse the same cached chart. This gives the agent a clear ordering rule versus all sibling tools: initialize here before requesting derived astrological components.

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 behavior. The description adds useful behavioral context beyond that by explicitly saying 'Data only — no interpretation is added' and by detailing the entry fields and the comprehensive point coverage. It does not discuss calculation caveats or edge cases, but the annotation burden is already satisfied.

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 main behavior and then organized into output fields and point coverage. The enumeration is long but necessary to clarify the tool's full scope and differentiate it from specialized siblings. There is no filler; the use of 'etc.' keeps an otherwise exhaustive list manageable.

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?

Since there is no output schema, the description does well to explain the return payload fields and the full range of chart points, which is the key information an agent needs. The 'Data only' note also prevents an agent from expecting interpretive prose. Minor gaps, such as not specifying the exact division basis of the amsa calculation, are not critical because the output fields are self-descriptive.

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?

The input schema provides 100% coverage for all seven parameters, including formats and optionality, so the baseline applies. The description adds no parameter-level guidance, but it does not need to compensate because the schema already carries the semantic weight.

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: 'Return the amsa (fine sub-division) ruler for every point in the chart.' It goes further by naming the exact output fields and enumerating the point categories, which makes the tool clearly distinct from siblings that focus on single subsets like upagrahas or sphutas.

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 implies when to use this tool: whenever an amsa ruler is needed across all chart points, including upagrahas, special lagnas, varnada lagnas, and sphutas. However, it never names alternative tools or states when to prefer them, such as get_sphutas or get_upagrahas, so the choice 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond those annotations: the exact key naming scheme, the default D-1 behavior, the single-chart-per-call limitation, and the explicit 'data only — no interpretation' disclaimer.

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 longer than average but every sentence carries relevant information, especially the 12-pada list and varga token list that support the lack of an output schema. It is organized well, though the varga token list is repeated in the input 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?

With no output schema, the description fully compensates by specifying the key-value return shape, all possible pada names, the default chart, and the allowed varga tokens. An agent has enough information to invoke the tool correctly and to interpret the returned object.

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 every parameter. The description still adds meaning for the 'varga' parameter by explaining the default behavior, insisting on exact token text, and clarifying that only one chart is returned per call. It also explains the output key semantics, which helps the agent map parameters to results.

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 specific verb and resource: 'Return the arudha padas ... for the divisional charts.' It enumerates all 12 padas and defines the output key format, which clearly separates this house-based arudha tool from sibling tools like get_graha_arudhas, get_chandra_arudhas, and get_surya_arudhas.

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 usage context: D-1 is the default, the 'varga' argument chooses another chart, the exact hyphenated token list is supplied, and only one chart is returned per call. It does not explicitly say 'use get_graha_arudhas instead for planetary arudhas,' but the scope is clear enough from the content.

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 read-only and idempotent, and the description adds substantial internal behavior: it explains what BAV, SAV, and SoAV mean, that SoAV is computed via Trikona and Ekaadhipatya sodhana, that SAV sums to 337, and that pindas derive from the reduced grid. It also explicitly notes the prastara grid is not included. This goes well beyond the annotation baseline.

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 dense but every clause contributes: it front-loads the core return statement and then explains each output field, row counts, summation behavior, and exclusions. No filler or redundant repetition; the details are structured and necessary for correct use. This is appropriately sized for a complex, output-schema-less tool.

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?

Since there is no output schema, the description carries the full burden of documenting the return value. It does so thoroughly: every key is defined, row counts are explicit, the meaning of SAV totals and SoAV is explained, and the relationship between pindas is clarified. Combined with the schema, an agent has everything needed to invoke and interpret the 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?

The input schema already provides descriptions for all 7 parameters (100% coverage), including formats and examples, so the baseline is 3. The tool description adds parameter-specific meaning only through the term 'data only', but it correctly relies on the schema for parameter documentation. No parameter information is missing.

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 specific verb ('Return'), names the exact resource (Ashtakavarga bindu scores), and labels results by planet and sign. It then enumerates every output field (BAV, SAV, SoAV, pindas), which fully distinguishes it from the many sibling yaga/dosha tools. This is a clear statement of what the tool does and what it returns.

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 states the data-only scope ('Data only — no interpretation is added') and explicitly excludes the prastara contributor grid, giving an agent clear boundaries for when this tool is relevant. It does not name sibling alternatives, but the stated exclusions and scope make the intended use case evident. This is clear context with exclusions, though not a full when-to-use routing guide.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the exact result shape, the computation of rupas and strength_ratio, the threshold interpretation ('above 1 means the house meets the strength threshold'), and the explicit statement that no interpretation is included. No contradiction with annotations exists.

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 composed of four tightly packed sentences: purpose, key structure, field semantics, and a behavioral caveat. There is no filler or repetition, and the most important information is front-loaded. Every sentence contributes to the agent's ability to invoke and understand the result.

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?

Without an output schema, the description fully carries the responsibility of explaining the return value. It precisely defines keys ('House 1' through 'House 12'), the three fields per house, units, and the meaning of strength_ratio. Combined with the annotations and complete input schema, an agent can both call this tool and correctly interpret the response without ambiguity.

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 every parameter has a rich description, including the optional role of place and the gender rule for yogas. The tool description adds no parameter-specific meaning beyond the schema, so it correctly rests at the baseline of 3.

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 specific verb and resource: 'Return the Bhava Bala (strength of the 12 houses/bhavas), labelled by house.' It goes on to specify the exact output keys and fields, making it unmistakable what this tool does. The phrase 'Data only — no interpretation is added' further distinguishes it from interpretive astrology tools among its siblings.

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 gives clear context about what the tool returns and explicitly says no interpretation is added, which hints at when to use it. However, it never mentions alternatives or when NOT to use it—particularly relevant given the many sibling bala tools like get_shad_bala, get_vimsopaka_bala, and get_other_bala. No explicit routing or exclusion criteria are provided.

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. The description adds valuable behavioral detail beyond those annotations by specifying the exact key naming convention, the value type, and that no interpretation is appended. This makes the tool's output behavior concrete for an agent.

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 two sentences with no filler. The core purpose and output contract are front-loaded, and the 'data only' caveat is placed at the end without bloating the definition.

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 present, the description compensates by fully specifying the output keys and value semantics. Given that the input contract is fully covered by the schema and the annotations declare a safe read-only operation, the definition is complete enough for reliable 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 effectively complete, with each input parameter carrying format and example information directly in the schema. The description does not add parameter-level meaning beyond what the schema already provides, which is appropriate given the high schema coverage.

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 begins with a specific verb and resource: 'Return the chandra arudhas' and immediately defines the scope as arudha signs for 12 houses counted from the Moon. It also states the exact output keys, which distinguishes it from sibling tools like get_surya_arudhas or get_graha_arudhas without ambiguity.

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 phrase 'from the Moon (Chandra Lagna)' clearly identifies the intended selection context among the arudha-related sibling tools. The explicit statement 'Data only — no interpretation is added' also tells the agent this is the raw-data variant rather than an interpretive report. However, it does not explicitly name alternatives or state when not to use this 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?

Annotations already indicate the tool is read-only and idempotent, so the safety profile is covered. The description adds useful behavioral context beyond that: roles are assigned by descending planetary longitude, and the output is raw data with no added interpretation.

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 core purpose and each sentence earns its place: role definitions, output field shape, assignment rule, and the no-interpretation caveat. It is informative without being bloated.

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 fully explains the return structure: each role maps to a value containing 'planet', 'sign', and 'longitude'. It also explains the assignment mechanism and explicitly states that no interpretation is added, so an agent can invoke and interpret the result 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%, so the input parameters are already fully documented in the schema. The description does not add parameter-specific guidance, but none is needed because the schema carries the detail. This matches the baseline for high schema coverage.

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 specific verb and resource ('Return the eight Jaimini chara (variable) karakas'), making the tool's purpose immediately clear. It also enumerates the exact role names and their meanings, which distinguishes it from the many other get_* astrology tools.

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 implies when to use it: whenever Jaimini chara karakas are needed. However, it does not explicitly discuss alternatives or state when not to use this tool, leaving the agent to infer the boundary from the tool name and sibling list.

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 readOnly and idempotent annotations already covering safety, the description adds substantive behavioral detail: level availability differs by system ('rasi systems have two levels, no pratyantar; level 4 sookshma is graha-only'), and the call intentionally serves data without interpretation. This shapes expectations about returned structure and limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, then output shape, then parameter-specific behavior. It is long but dense; every sentence adds operational or structural detail that is not available elsewhere, and it avoids restating the schema's property descriptions.

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 result fields and node shape ('level', 'ruler', 'start', 'end', 'relation', 'current', 'maha_timeline', 'selected_maha'/'selected_antar'). It also covers defaults, system enum reference, and the as_of_date anchor, leaving no major gap for an agent to call the 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?

Although the schema already describes each parameter, the description adds relational meaning: the system parameter 'routes it automatically', birth date is distinct from the anchor 'as_of_date', and maha/antar select a specific period regardless of date. These clarifications go beyond the isolated schema entries.

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 precise verb ('Return') and resource ('dasha timeline as a nested tree anchored on a date'), and immediately distinguishes its scope: past, present and future in one call, for both graha and rasi systems. This makes it easy to differentiate from sibling astrology tools such as gochara or planetary states.

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 clear operational context: default system, anchor, depth, and instructions for drilling into a specific period with 'maha'/'antar' or re-anchoring with 'as_of_date'. It does not name alternative sibling tools or explicit when-not-to-use conditions, only 'Data only — no interpretation' as a boundary.

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/destructive annotations, the description discloses the response shape, the defaulting behavior when varga is omitted, and the error behavior when an unrecognized value is sent (returns the list of valid tokens). It also alerts callers that no interpretation is performed, which is important behavioral context for an astrology API.

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?

Although long, every sentence is load-bearing: response format, exact token syntax, semantic mapping table, default, and error fallback. The critical 'Return ONE...' behavior is front-loaded, and the token list is formatted for quick scanning rather than buried in prose.

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 specifying the response structure and all body keys, plus the sign/longitude object format. It covers defaults, error handling, sibling routing, and leaves the five required birth-data fields to a schema that already documents them completely. An agent has everything needed to call and interpret the result 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 already 100%, but the description adds substantial parameter value by mapping each varga token to an area of life and warning against sending names like 'Rasi' or 'Navamsa'. This exceeds the baseline-3 for high schema coverage because varga, the parameter that most affects the result, is fully disambiguated in the description rather than just listed as an enum.

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 verb-resource pair: 'Return ONE divisional (varga) chart for the birth' and specifies exactly what the response will contain as a body-to-sign/longitude mapping. This clearly separates it from the sibling tools, which target different calculations or interpretations, and it names list_divisional_charts as the browsing companion.

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 when-to-use guidance: select a D-token by life area (D-9 marriage, D-10 career, etc.), use the exact hyphenated token, and omit varga to get D-1. It also states the boundary condition ('Data only — no interpretation') and directs callers who want to browse options to list_divisional_charts, giving the agent concrete routing rules.

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 read-only, idempotent, non-destructive behavior. The description adds genuinely useful behavioral context beyond those annotations: the result is a mapping of dosha name to verdict and reasoning, the verdict text may include light HTML markup, and no interpretation is added beyond the engine's report. This sets clear expectations for a tool 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?

The first sentence front-loads the action and result, the dosha list is compact but complete, and the HTML and data-only caveats are each one short sentence. Every sentence contributes useful information with no 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?

With no output schema, the description carries the burden of explaining the return shape and content, and it does so clearly: a map of dosha names to presence verdicts and reasoning, with possible HTML and no added interpretation. Input context is fully handled by the high-coverage schema, so nothing essential is missing for an agent to 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?

The input schema has 100% parameter description coverage, so the structured data already explains all parameters. The description adds no parameter-specific semantics beyond saying they define the chart, so the baseline score of 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?

The description states a specific verb and resource: 'Return the standard dosha (planetary affliction) checks for the chart.' It further lists every dosha covered, so an agent unambiguously knows what this tool does and can distinguish it from sibling tools like get_yogas or get_planetary_states.

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?

Usage is implied rather than explicit: the description implies the tool is for computing dosha verdicts, and the data-only note narrows interpretation. However, it never states when to prefer this over alternatives or when not to use it, nor does it name any sibling 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?

Annotations already carry readOnly/idempotent/non-destructive, so the bar is lower. The description adds genuinely useful behavioral details: Rahu/Ketu default to Mean node, a clean Abhijit window excluding Rahu/Gulika/Yamaganda overlap, the gender-sensitive yoga behavior, and the 'Data only — no verdict' boundary. These are beyond what annotations state.

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 compact for the amount of content it covers. It front-loads the primary purpose (transit snapshot for a given date vs natal chart), then lists return sections and key behaviors. It could be a touch shorter, but every clause adds information about scope, defaults, or exclusions.

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 complex tool with 16 parameters and no output schema, the description covers the main return categories, the default node behavior, and the no-verdict boundary. It doesn't spell out every default (target_time default, event_place default), but the schema already documents those defaults, so the description needn't repeat them. The main gap is not describing the shape of the transit_charts output, but the schema and the description together are adequate.

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 fully documents all 16 parameters. The description restates a few schema concepts (node_type default, gender optionality) but doesn't add much new meaning. It correctly orients the agent to the birth vs target_date distinction, but the schema already does that. 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?

The description is specific: it names the resource (planetary transit snapshot vs natal chart), the date (target date vs birth), and enumerates concrete content: panchanga, muhurta windows, 9 planets, Tara Bala, D-1/D-9 charts, node behavior. It clearly distinguishes itself from get_gochara_range and other astrological siblings by focusing on a single target date.

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 clearly states what data is returned and that no verdict is provided ('Data only — no verdict'), which tells the agent when not to use it for interpretive judgment. It also mentions node_type='true' for True nodes, implying the default Mean behavior is the common case. It doesn't explicitly name alternatives, but the richness of the content and the date-vs-range distinction vs get_gochara_range is 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 mark the tool as read-only, idempotent, and non-destructive, and the description does not contradict them. Beyond annotations, it discloses behavioral constraints: range capped at 60 days, natal reference computed once, per-day snapshot contents enumerated, and no scoring/'best date' selection. It could have added rate-limit or pagination details, but the disclosed behavior is substantive.

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 a solid paragraph, front-loaded with the core purpose and most decision-relevant detail. The list of included data is long but largely earned because it tells the AI what's available for reasoning. A slight reduction could be made by skipping some enumerations, but the structure is clear and purposeful.

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 complex tool returning bulk per-day data with no output schema, the description explains the input, the safety profile (via annotations), the range cap, the optional enrichment behavior, and how this differs from the rule-based alternative. It does not detail the exact output JSON shape, but the enumerated contents give a solid mental model of what is returned.

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 the input schema thoroughly explains every parameter such as date, time, place, gender, include, and coordinates. The description does not repeat parameter docs, but it does tell the agent that the range is capped at 60 days (relevant to from_date/to_date) and that 'include' defaults to all enrichment sections. Baseline 3 applies because the schema already does the heavy lifting.

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 ('Raw transit details for EVERY day in a date range') and distinguishes it from the closest sibling by naming get_muhurta and get_gochara. It clearly states the unique value: one-call bulk retrieval for an 'AI decides' flow, with no scoring.

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: when the AI should reason over raw per-day data and decide for itself. It also names the alternative tool (get_muhurta) and the condition to choose it ('if you want the system to rank dates by rules'). This is the model example of usage 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 readOnlyHint, idempotentHint, and destructiveHint, so the description's main job is to reveal output behavior. It does this well by listing every response key, stating that values are zodiac signs, and clarifying that no interpretation is added. This goes beyond annotations without contradicting them.

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 two sentences with zero filler. The core action is stated first, followed by a compact enumeration of all output keys and a final clarifying note about interpretation. Every sentence earns its place.

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 present, the description compensates by fully enumerating the return keys and their value type. It is sufficient for an agent to invoke the tool correctly. The only minor gap is the lack of a sibling-tool pointer, though the scope of 'all nine grahas plus Ascendant' mostly resolves that ambiguity.

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 tool description itself adds no parameter-specific guidance, but it doesn't need to because each parameter already has a clear schema description with examples.

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 ('Return'), a specific resource ('graha arudhas'), and precisely enumerates all ten output keys plus their value semantics. It also distinguishes itself from sibling tools like get_chandra_arudhas or get_surya_arudhas by stating it covers the Ascendant and all nine grahas.

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 phrase 'Data only — no interpretation is added' implies this is for raw astrological data rather than interpreted readings, and the 'each of the nine grahas' wording indicates broad coverage. However, it never explicitly states when to choose this tool over siblings such as get_arudha_padas, get_chandra_arudhas, or get_surya_arudhas.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying that the result is raw data with no interpretation and by defining the output contract (keys V2–V12, each with sign and longitude). This goes beyond what annotations alone provide.

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 two sentences with zero redundancy. The first sentence is front-loaded with the core action, and the second provides a precise output contract. Every word earns its place.

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?

Since there is no output schema, the description compensates by explaining the return format precisely. It covers the essential facts an agent needs: what is returned, key names, and value structure. Minor omissions like unit of longitude or ayanamsa convention are not critical for correct invocation, so this is nearly 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%, and each parameter already has a meaningful description (format, examples, optionality). The tool description does not add any parameter-level semantics, but the schema fully carries that burden. No gap in parameter understanding exists.

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 clearly states a specific verb and resource: 'Return the varnada lagnas for the houses.' It also details the output keys (V2–V12) and value structure, which makes the purpose unambiguous. However, it does not explicitly differentiate itself from sibling tools such as get_special_lagnas, 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 phrase 'Data only — no interpretation is added' implies a boundary: use this tool when raw data is needed rather than interpretive output. But no explicit when-to-use or when-not-to-use guidance is given, and no alternative sibling is mentioned. This is implied usage context, not direct 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 establish readOnly, idempotent, and non-destructive behavior, so the description's job is to add context beyond those. It does: it discloses that only the sign-modality method is represented, that 'overall_assessment' is not a reconciled verdict, and how 'checks_summary' and the check lists are structured. No contradiction with 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 longer than average, but every sentence earns its place by explaining a distinct part of the output that would otherwise be opaque given no output schema. It is front-loaded with the core purpose and the key caveat ('does not issue a longevity verdict') before diving into field-level details.

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 full burden of explaining the response, and it does so thoroughly: it covers 'overall_assessment' semantics and its category codes, 'method_note', 'checks_summary', each set of check combinations, and the calculation basis fields. Nothing essential about the return value is left unexplained.

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 all seven parameters in detail. The description focuses on the output structure rather than the input parameters, which is acceptable at the baseline. It does not add parameter-specific meaning, but it does not need to given full schema coverage.

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 specific verb-resource pair: 'Return the chart's classical Ayurdaya (longevity) computations.' It immediately distinguishes the tool's scope by stating it does not issue a verdict but exposes classical signals side-by-side, which clearly differentiates it from general horoscope and yoga tools among the siblings.

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 clear context for when this tool is appropriate: for astrologer interpretation of classical longevity signals. The explicit caveat that it 'does not issue a longevity verdict' and that 'method_note' is not a reconciled verdict tells the agent when not to treat this as a definitive answer. It does not name alternative sibling tools, so it stops short of a fully explicit when-to-use-vs-alternatives 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered and the bar is lowered. The description adds real operational context beyond annotations: 'Data only — no interpretation is added' discloses the output policy, and domain semantics like 'mars_dosha>0 means Manglik' plus the default 'both systems' behavior tell the agent what to expect from the payload.

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 long but each section earns its place: purpose, sibling differentiation, parameter shape, then a complete return-structure map that compensates for the missing output schema. It is well front-loaded, though the full enumeration of the eight kootas and four poruthams could be condensed without losing essential guidance.

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 a high-complexity tool — two required nested objects, an enum parameter, and a six-part composite return — with no output schema. The description documents every return section ('summary', 'north_indian', 'south_indian', 'boy'/'girl', dosha data, 'beeja_rasi'/'kshetra_rasi'), the default, and enum options, so an agent can invoke it correctly without schema spelunking. Nothing necessary for a correct call 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. The description adds meaning beyond the schema by linking the 'system' parameter to the shape of the returned payload and by framing the two structurally identical nested objects as boy vs. girl (groom vs. bride), which clarifies the schema's terse 'birth details' labels. The prose mirrors format examples from the schema rather than contradicting or expanding them.

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 opening sentence states the exact function — 'Check Vedic marriage compatibility between a couple' — with a specific verb and resource. The phrase 'Unlike the other tools, this needs TWO births' explicitly differentiates it from the 31 sibling get_* tools, which all operate on a single birth. The title 'Marriage Compatibility (Guṇa Milan)' adds a searchable alias for further disambiguation.

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 selection context: it names the unique prerequisite (two birth records) and gives explicit guidance for the 'system' parameter ('By default both systems are returned; set system to north or south to get just one'). It does not, however, name concrete alternatives or state when not to use this tool — e.g., pointing single-birth Manglik checks toward a sibling like get_doshas.

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, the description discloses meaningful behavior: deterministic scoring, breakdown and weights, cap on failed mandatory rules, best-window and avoid-windows, and the 'data only — caller writes recommendation' boundary. This gives the agent an accurate model of what the tool returns and how it behaves.

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 dense but front-loaded with the core purpose and then packed with useful behavioral details. The event_type enum list is redundant with the schema, but the rest of the content earns its place for a complex astrological tool.

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 does a good job listing the outputs: ranked candidates with breakdown and weights, Abhijit/clean best-window, and Rahu/Gulika/Yamaganda avoid-windows. It could be more explicit about response shape or edge cases, but it is sufficient 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 coverage is 100%, so the input schema already documents all 17 parameters. The description restates the event_type enum but adds no new parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Find auspicious dates for an event across a date range' and explains the system ranks dates by classical rules. It distinguishes the tool from get_gochara_range by noting this tool returns ranked candidates while the sibling gives raw per-day details.

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 provides an alternative: 'Use get_gochara_range instead to get raw per-day details and decide yourself.' It also clarifies the tool is data-only and the caller writes the recommendation, preventing misuse of the result as a final recommendation.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is already communicated. The description adds value by disclosing the exact output contract: which bodies are included, what fields each entry contains, and that no interpretation is returned. This goes beyond the annotations without contradicting them.

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 longer than average but each sentence contributes: the first specifies the returned data and scope, the second enumerates the exact per-entry fields, and the final sentence clarifies the purely data-oriented nature. Some redundancy exists in listing both the field names and their examples, but it remains efficient and readable.

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 present, the description effectively serves as the output specification, listing all returned fields, their value ranges, and the full set of chart bodies included. Combined with a 100%-covered input schema and safety annotations, an agent has everything needed to call 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 description coverage is 100%, so the schema already documents all parameters clearly. The description does not add parameter-level detail, but it does not need to; the baseline of 3 applies because the schema carries the full parameter documentation burden.

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 starts with a specific action ('Return the birth (sidereal) nakshatra...') and precisely identifies the resource: nakshatra, pada, lord, and degrees for every chart body. It also explicitly differentiates itself from interpretive tools by stating 'Data only — no interpretation is included,' making its scope clear relative to siblings.

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 makes it clear what data will be returned, so an agent can infer that this tool is for raw nakshatra/pada data rather than interpretation or synthesis. However, it provides no explicit when-to-use guidance, no exclusions, and does not name or contrast any sibling tool, leaving selection 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?

The description adds substantial behavioral context beyond the annotations: it names the measures, explains the formulas for ishta_phala and kashta_phala, clarifies that they are independent and 'do NOT sum to 60,' specifies value ranges, and states the output shape ('Each is a map of planet name to its value'). The annotations already mark it read-only and idempotent, and nothing here contradicts them.

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 dense but each sentence earns its place: it front-loads the purpose, then lists the measures, explains the key formula and its consequence, and ends with the return format and scope. It is somewhat long, but nothing is superfluous.

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 full burden of explaining return values, and it does so thoroughly: exact field names, meanings, ranges, formulas, and the map-shaped structure. It also notes the seven-planet scope and the lack of interpretation. For a data-only read tool, this is 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 parameters are fully documented in the schema. The description adds no parameter-specific meaning, which is acceptable under the baseline; it focuses instead on output semantics rather than 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?

The description opens with a specific verb and resource: 'Return the additional planetary strength measures for the seven planets (Sun..Saturn).' It enumerates the exact measures included, which clearly distinguishes it from sibling tools like get_shad_bala or get_bhava_bala and sets an unambiguous scope.

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 explains what the tool returns but gives no explicit guidance on when to choose it over sibling tools such as get_shad_bala, get_bhava_bala, or get_vimsopaka_bala. The phrase 'Data only — no interpretation is added' hints at a use case, but there is no when-to-use or when-not-to-use direction.

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 destructiveHint false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: each output list's meaning, the neutral-sign behavior for planets absent from all lists, and the explicit 'Data only — no interpretation is included' boundary. This fully discloses what the tool will and will not do.

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 core purpose, then systematically defines all seven output fields in a compact list. Every sentence adds necessary semantic detail—none is wasted. The length is proportionate to the complexity of the output 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?

There is no output schema, so the description carries full responsibility for explaining return values. It does so exhaustively by naming every field, defining each condition, and covering the neutral-sign fallback. Inputs are fully documented in the schema, and annotations cover safety, so nothing needed to invoke the tool 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%, with all 7 parameters clearly documented including examples and format specifics. The description adds no parameter-level information, but per the baseline rule, when schema coverage is high the description need not repeat it. A score of 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?

The description opens with a specific verb and resource: 'Return the dignity and motion state of the planets, grouped by condition.' It then enumerates every output field with precise definitions, making the tool's scope unmistakable. The closing 'Data only — no interpretation is included' clearly separates it from interpretive sibling tools like get_yogas or get_doshas.

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 implies usage context by stating it returns raw data only, which suggests it is for callers wanting uninterpreted planetary states rather than interpretive tools. However, it does not explicitly name alternatives or specify when to choose this tool over siblings such as get_planet_ingress or get_gochara. The usage guidance is implied rather than 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 establish readOnly/idempotent/non-destructive behavior, and the description adds substantial context: retrograde awareness, default planets, forward/retrograde flags, final_settling semantics, data-only output, and range cap. This goes well beyond what annotations alone communicate.

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 compact and front-loaded with the core action. It slightly repeats what the schema already states (default planets and ~5-year cap), but the repetition is brief and useful as a caution. No wasted filler sentences.

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?

Even without an output schema, the description explains what returned data looks like: every sign change, retrograde back-out/re-entry, flags, and final_settling. Combined with schema-covered parameters and safety annotations, an agent has enough context to select and invoke the 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 description coverage is 100%, so the schema already documents all five parameters. The description reinforces the planets default and date-range cap but does not add meaningful parameter-level semantics beyond the schema, which matches the baseline for high schema coverage.

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 operation—sign-change/ingress dates for one or more planets across a date range—and clarifies the exact resource: sidereal sign changes, including retrograde back-out/re-entry and final_settling. The title and phrase 'Use for when does Saturn/Jupiter change sign timing' distinguish it from general transit or current-position sibling tools.

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 explicitly gives a use case: 'Use for when does Saturn/Jupiter change sign timing.' It also sets expectations with 'Data only' and a ~5-year range cap. It does not explicitly name alternative tools or state when not to use it, so it stops 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?

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the bar is lower. The description adds genuinely useful behavioral context: the exact return format (sign + degrees/minutes/seconds), coverage of the full set of sahams, and the guarantee that no interpretation is included. This goes beyond the annotations without contradicting them.

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 compact and well-structured. The first sentence states the action and resource, the second clarifies the output format with a concrete example, and the third sets expectations about interpretation. Every sentence earns its place with no 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 that there is no output schema, the description does a good job of defining the return shape and scope. It explains the result format, the set of sahams, and the data-only nature. Minor omissions like error behavior or handling of invalid birth data are not significant given the strong schema coverage and read-only annotations.

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 of 3 applies. The description does not add parameter-level detail, but the schema already documents each parameter sufficiently, so no compensation is needed.

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 ('Return the sahams') and clearly describes the output as a mapping of saham names to zodiacal positions, with examples. It is clear what the tool does, though it does not explicitly differentiate itself from sibling tools like get_sphutas or get_yogas.

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?

No explicit guidance is given about when to prefer this tool over alternatives. The note that it returns 'data only — no interpretation' hints at a limitation, but it does not name sibling alternatives or state conditions for selection, leaving usage mostly 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 flag readOnlyHint and idempotentHint, and the description adds valuable behavioral context beyond that: it explicitly states 'Data only — no interpretation is added,' explaining that the tool returns computed periods without interpretive commentary. It also discloses the two computational bases for Sade Sati and the structure of the periods, which is exactly the kind of beyond-schema behavior an agent needs to know.

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 long but every sentence carries information about output structure, naming conventions, or behavioral boundaries. It is front-loaded with the core purpose, then organized by key output groups, and ends with an explicit data-only caveat. Nothing feels wasted, and the detailed structure compensates for the lack of an 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?

With no output schema available, the description carries the full burden of explaining return values, and it does so thoroughly: it names the main keys, describes degree-based vs sign-based Sade Sati, lists the phases, and clarifies that each period contains startDate, endDate, and a description. Given the complexity of the tool and the read-only annotations, this is complete enough 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?

Input schema coverage is 100%, so every parameter already has a meaningful description. The tool description does not add new parameter-level semantics, but it does clarify the conceptual purpose of some inputs by referencing the natal Moon and Ascendant, which helps connect the parameters to the computed output. This matches the baseline for a fully documented 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 opens with a specific verb and resource: 'Return Saturn's Sade Sati and related transit windows for the chart, with dates.' It goes on to enumerate exact sub-results (degreeBased, signBased, moonTransits, ascendantTransits), making the tool's scope unmistakable and clearly distinct from sibling transit tools like get_gochara or get_planet_ingress.

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?

Although the description does not explicitly name alternative tools or exclusion criteria, it provides a rich, concrete inventory of what this tool returns — Sade Sati periods, Moon transits, and Ascendant transits — so an agent can infer when it is the right choice. It does not go as far as saying 'use X instead when Y,' but the practical context is very 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by explaining that the tool returns data only with no interpretation, and defines the meaning of strength_ratio relative to a required minimum.

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 information-dense but not bloated, front-loading the core purpose before enumerating components and derived values. Every sentence contributes needed detail, especially since there is no 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?

With no output schema, the description thoroughly covers what the agent can expect: the seven planets, six component names, total_virupas, total_rupas, and the strength_ratio threshold meaning. Combined with the fully described parameters and annotations, 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 description coverage is 100%, so the schema already documents all seven parameters. The description adds no parameter-specific meaning, which is acceptable at the baseline of 3.

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 uses a specific verb ('Return') with a specific resource ('Shadbala (six-fold strength) of the seven planets') and explicitly lists the six components and derived totals. This makes it easy to tell apart from sibling bala tools like get_bhava_bala or get_other_bala.

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 makes the use case clear: if an agent needs Shadbala strengths, this is the tool. However, it never mentions alternatives or states when not to use it, despite a sibling list full of other bala 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?

Annotations already declare readOnly, idempotent, and non-destructive. The description goes beyond them by clarifying that results are raw derived lagnas with no interpretation, and that each lagna maps to a sign and longitude. There is no contradiction with 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?

Three short, purposeful sentences: the main action, the output shape, and the data-only boundary. The list of lagna names is long but necessary to define the tool's scope precisely.

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 simple read-only data retrieval tool, the description is largely complete: inputs are fully documented in the schema, and the output shape plus no-interpretation contract are described. Because there is no output schema, slightly more detail about exact sign representation or response structure would fully close the 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?

The input schema has 100% description coverage for all 7 parameters, so the baseline is 3. The description adds no parameter-level guidance, but the schema already carries that burden effectively.

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: 'Return the special (derived) lagnas of the chart.' It also enumerates the exact lagnas included, which distinguishes it from sibling tools like get_sahams or get_arudha_padas that might otherwise sound similar.

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 clear usage context by stating 'Data only — no interpretation is added,' telling an agent this endpoint returns raw data and is not for interpretive readings. It does not name a sibling alternative, so it stops just short of explicit 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail: exact output mapping, the full list of sphutas included, the output format with an example, and the explicit statement that no interpretation is added. This goes beyond what annotations provide.

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 efficient and information-dense without fluff. It opens with the action, immediately describes the output format with a concrete example, lists the included sphutas in a compact enumerative sentence, and closes with a one-line behavioral boundary. Every sentence contributes essential decision-making or invocation 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?

There is no output schema, so the description correctly takes on the burden of explaining the return format and the full set of results, which it does thoroughly. It also clarifies that this is raw data, not interpretation, which is an important contextual signal. For a read-only, idempotent computable tool, 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?

The input schema already describes all parameters with 100% coverage, so the baseline is 3. The description does not add parameter-specific semantics beyond 'of the chart' and the note that data-only output; it does not document date/time/coordinates because those are already fully covered in the schema. It neither harms nor significantly enhances schema coverage.

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: 'Return the sphutas (special computed sensitive points) of the chart.' It clearly explains what the output is (sphuta name → zodiacal position in sign/degrees/minutes/seconds) and enumerates all included sphuta types, leaving no ambiguity about what the tool provides.

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 gives clear context by noting 'Data only — no interpretation is added,' which tells the agent to reach for this tool when raw computed sphuta positions are needed rather than interpretive analysis. It does not explicitly name an alternative tool or state exclusionary conditions, but the usage context is clear enough among the many sibling 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?

Annotations already declare the tool read-only, idempotent, and non-destructive, so the bar for additional disclosure is lower. The description adds useful behavioral context beyond annotations: 'Data only — no interpretation is added' and the exact key naming convention for the result. It does not cover edge cases, but that is acceptable given the annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, with the core action and output keys front-loaded in the first sentence and the data-only caveat in the second. Every sentence contributes meaningful information and there is no redundant or filler 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?

For a simple read-only computation with robust annotations and full schema coverage, the description is nearly complete. It compensates for the missing output schema by listing the exact result keys and data type. It could have briefly mentioned the birth-data dependency or contrasted with sibling arudha tools, but nothing essential is missing 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 100%, and each parameter already has clear semantics with formats and examples. The description itself adds no parameter-level information beyond the schema. Per the baseline rule, a 3 is appropriate when the schema carries the parameter-documentation burden without gaps.

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 ('Return'), a specific resource ('surya arudhas'), and a precise scope: arudha signs for all 12 houses counted from the Sun (Surya Lagna). It also enumerates the exact output keys. This clearly differentiates the tool from siblings like get_chandra_arudhas and get_graha_arudhas by anchoring on 'from the Sun'.

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 implicitly conveys usage context by defining the tool as data-only and Sun-based, but it never explicitly states when to prefer this tool over alternatives such as get_chandra_arudhas or get_arudha_padas. No exclusions or alternative routing are provided, so an agent must infer usage from the name and phrasing.

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 indicate read-only, idempotent, and non-destructive behavior, and the description adds substantial context beyond that: calibration against Jagannatha Hora, English-only names regardless of language settings, the civil-midnight meaning of epoch.vaara, no side effects on other tools, and 'Data only — no verdict.' These are non-obvious behaviors an agent needs to know.

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 dense, purposeful sentences. The first front-loads the main purpose and output contents; the second adds calibration and scope; the third resolves naming/epoch ambiguity and the no-verdict caveat. Every sentence earns its place with 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?

With no output schema, the description carries full responsibility for explaining return values, and it does so thoroughly: nine bodies with sign/degree/nakshatra/daily motion/sighra-kendra/retrograde flag, SS lagna, SS ayanamsa with delta, and SS panchanga details. It also clarifies naming, weekday semantics, and the non-verdict nature of the data, covering everything needed to select and call the 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 description coverage is 100%, so the parameters themselves are already fully documented with formats, examples, and optionality. The tool description adds no per-parameter semantics beyond the schema; it only summarizes the output contents. Baseline 3 is appropriate because the schema already carries the parameter documentation burden.

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 specific verb-resource pair: 'Classical Surya Siddhanta ... D-1 positions for a birth instant,' enumerating exactly what is computed. It distinguishes itself from siblings by explicitly stating that every other tool stays Drik, so an agent can tell this tool apart 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?

The description clearly signals when to use this tool: when Surya Siddhanta positions are needed, because 'Every other tool stays Drik, and this tool does not change them.' It also adds 'Data only — no verdict,' which tells the agent not to use it for interpretive output. It stops short of naming a specific sibling alternative for Drik charts, so it is slightly less explicit than the highest bar.

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 and idempotentHint, so the safety profile is covered. The description adds real behavioral context by enumerating all 11 upagrahas returned and specifying each maps to sign and longitude, plus the data-only guarantee.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and resource, with a compact list of included upagrahas. No filler; the 'Data only' caveat earns its place.

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, idempotent tool with fully documented parameters, the description covers the output substance: a list of upagrahas and their sign/longitude mapping. With no output schema, slightly more detail on the exact return shape would be ideal, but the fixed enumeration mitigates the 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?

The input schema describes all 7 parameters with 100% coverage, so the baseline applies. The description adds no information about how date/time/place affect the calculation or the meaning of optional parameters beyond what the schema already provides.

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?

Description opens with a specific verb and resource ('Return the upagrahas ... of the chart'), names the exact items returned, and explicitly states raw data vs no interpretation. This is enough to distinguish from siblings such as get_sahams or get_yogas, which cover different astrological elements.

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 'Data only — no interpretation is added' line conveys a clear use-case for raw data consumers, but there is no explicit when-to-use/when-not-to-use guidance or named alternative among the many sibling tools. Usage must be inferred from the tool name and content list.

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, so the description does not need to re-establish safety. It adds useful behavioral context by guaranteeing a bounded result set (exactly four weighting schemes covering the listed nine planets) and explicitly stating that no interpretation is added, which is consistent with openWorldHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences carry the purpose, output shape, planet set, example format, and data-only caveat without repetition. The most important information is front-loaded and every clause earns its place.

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 there is no output schema, the description compensates well by specifying the list length, each entry's structure, the exact string format, and an example. It could be even more complete by flagging which sibling tools cover interpretation or other balas, but an agent has enough to call the tool correctly from this description plus the 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 schema already documents every parameter. The tool description contributes no additional meaning to date, time, location, or optional gender beyond the output context; a baseline of 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?

The description opens with a specific verb ('Return') and a precise resource ('Vaiseshikamsa Bala'), then explains it as the count of auspicious vargas per planet. Naming the four weighting schemes and the exact planet set makes it easy to distinguish from the many sibling bala tools 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?

The description clarifies the scope—pure data, no interpretation—and thereby implies it is not for interpretive answers. However, it never names an alternative tool or states a condition for choosing this bala over get_shad_bala, get_vimsopaka_bala, or get_bhava_bala, so selection among siblings 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 cover the read-only, idempotent, non-destructive nature. The description adds meaningful behavioral detail: exactly four schemes are returned, each value is a multi-line string with amsa name, contributing vargas, and score out of 20, and the tool deliberately adds no interpretation. This goes beyond what annotations provide.

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 core purpose, followed by a compact yet complete breakdown of the return format and an illustrative example. Every sentence adds necessary information without filler, making the description long but appropriately dense for the complexity of the output.

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 carries the burden of explaining the return value. It specifies the four schemes, the planet set, the exact string template, an example, the score scale, and the data-only nature. An agent can reliably predict the output structure without additional documentation.

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 parameters are already fully documented in the input schema. The description does not add extra parameter-level semantics, but given the complete schema coverage, the baseline score of 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?

The description clearly states the tool returns Vimsopaka Bala scores, specifies the exact output structure (four weighting schemes, planet mappings, string format), and gives a concrete example. It is unambiguous and specific, though it does not explicitly differentiate itself from sibling bala tools like get_shad_bala or get_vaiseshikamsa_bala.

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?

Usage context is implied: use when Vimsopaka Bala scores are wanted. The 'Data only — no interpretation is added' line gives some decision-relevant context, but there is no explicit guidance on when to prefer this tool over alternatives or any exclusion criteria.

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 the operation read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by explaining the two-part result structure, that all detected yogas are included, and that no interpretation is added, which goes beyond what the annotations express.

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 purpose and then explains the output structure in an organized way. It is somewhat detailed, but every sentence contributes useful information such as key names, list structure, and the data-only guarantee.

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 carries the full burden of explaining the return value, and it does so thoroughly by naming both parts, the count keys, the map structure, and example values. It also covers the all-inclusive behavior and the no-interpretation guarantee, making it complete enough 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?

The input schema already provides 100% description coverage for all seven parameters, including formats, examples, and optionality. The tool description does not need to repeat parameter semantics, so the baseline of 3 is appropriate as it adds no additional parameter-level meaning.

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 clearly states the tool returns every yoga (planetary combination) detected in the birth chart, using a specific verb and resource. It also differentiates the output as data-only without interpretation, which helps distinguish it from interpretive or predictive sibling tools.

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 makes clear this is the tool for retrieving all detected yogas and describes the exact output structure and scope. It does not explicitly name alternatives or provide exclusionary conditions, but the context is specific enough that an agent can infer when 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 behavior. The description adds what each entry returns (request_as, name, purpose) and explicitly states 'Data only — no interpretation is included,' which prevents false expectations.

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 focused sentences with no filler. The main action and output format are front-loaded, and the usage guidance follows naturally.

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-parameter catalog tool, the description fully covers what it returns, how to use it, and what it does not provide. No important context 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?

There are zero parameters and the schema is empty, so the baseline is 4. The description reinforces that no birth details are required, which is the only relevant parameter-related guidance needed.

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 uses a specific verb ('List'), names the exact resource ('the 23 divisional varga charts'), and explicitly ties itself to 'get_divisional_chart'. It clearly distinguishes its catalog role from the retrieval 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?

It explicitly says when to use it: 'Use this to choose the right chart for a question, then call get_divisional_chart with that varga.' It also clarifies that no birth details are needed, preventing misuse.

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