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=false. The description adds meaningful behavioral context beyond those annotations by revealing that the result is cached and later tools reuse that same chart, and by enumerating the returned summary fields. 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?

Two sentences, zero filler: the first sentence states purpose and output; the second states invocation ordering and caching. Key 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?

With no output schema, the description compensates by specifying the returned summary contents. It also explains the caching dependency that ties this tool to the large sibling set. For a chart-generation tool with a fully-covered input schema and safety 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 baseline is 3; the schema already documents each parameter including formats and the cosmetic nature of 'place'. The description adds no extra semantic detail about the parameters; it merely mentions 'birth date, time and place' in passing, which is slightly less precise than the schema's required latitude/longitude/timezone 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 uses a specific verb ('Generate') and names a concrete resource ('Vedic (sidereal) birth horoscope'), then details exactly what the concise summary will contain (ascendant/lagna, moon sign, sun sign, birth nakshatra and pada). It also differentiates this tool from the many get_* siblings by framing it as the foundational generation step whose cache later tools reuse.

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 explicit when-to-use guidance: 'Call this first; later tools reuse the same cached chart.' This directly tells an agent to invoke this tool before all the sibling retrieval tools and explains the dependency relationship.

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 and destructiveHint=false, so the safety profile is covered. The description adds the behavioral trait 'Data only — no interpretation is added' and enumerates all point categories covered, giving the agent a clear expectation of output scope. This exceeds the minimal annotation coverage without contradicting it.

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 leads with the core purpose, and subsequent sentences efficiently add output structure and coverage. The third sentence is a long enumeration, but it earns its place by removing ambiguity about which point types are included. The 'Data only' closer is a compact, useful boundary statement.

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 explicitly listing the output keys and the full set of point categories (ascendant, planets, upagrahas, special lagnas, varnadas, sphutas). An agent can predict the response shape and scope accurately before calling. The required birth-data parameters are self-evident from the schema, so 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%, with each of the seven parameters individually documented in the input schema. The description adds no parameter-level detail beyond what the schema already provides, so the baseline of 3 applies. It neither hurts nor improves parameter understanding.

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 object ('Return the amsa ruler for every point') and then enumerates the exact output fields and the full universe of points covered. This makes the tool's job unambiguous and implicitly distinguishes it from sibling tools that cover only one subset (e.g., get_upagrahas, get_sphutas). The 'Data only' coda further clarifies it is a raw lookup, not an analysis tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not name alternatives or explicitly state when to choose this tool over get_upagrahas, get_special_lagnas, or get_sphutas. The coverage list and 'Data only' clause imply a general-purpose raw-data use case, but the when-not conditions are left to inference. An agent can reasonably infer usage from the 'every point' scope, but explicit routing or exclusions are absent.

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 description only needs to add non-safety behavior. It does: the output is a mapping with keys like 'D-1-Arudha Lagna (AL)', the default is D-1, only one chart is returned per call, and the result is data-only with no interpretation. This adds useful behavioral context without contradicting the annotations.

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

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

The description is front-loaded: purpose first, output shape second, default behavior third, and constraints near the end. It is longer than average because it repeats the full 23-token varga list already present in the schema enum, but the emphasis on exact hyphenated text and the 12 padas list are genuinely useful for correct invocation.

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. It specifies key construction, value semantics, the complete 12-pada set, default chart behavior, accepted varga tokens, and the per-call limit. For a domain-specific Vedic astrology tool, 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by emphasizing the exact hyphenated varga token format, the default D-1 behavior when varga is omitted, the one-chart-per-call constraint, and by enumerating the 12 pada names that appear in the output keys. This helps the agent understand how the varga parameter affects the result.

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' and clarifies that each pada is the 'perceived/reflected sign of each house.' It names all 12 padas and the key format, so an agent can distinguish this house-based arudha tool from sibling tools like get_graha_arudhas or get_chandra_arudhas without opening their 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 gives explicit usage instructions: omit 'varga' for the D-1 default, or set it to exactly one hyphenated token for another chart. It also warns that only one chart is returned per call. It does not explicitly name sibling tools or provide when-not-to-use exclusions, which keeps it just below a 5.

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

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

Annotations already declare the call read-only and idempotent, so the description correctly focuses on output behavior: it spells out what each returned dictionary maps, that SAV sums to 337, that SoAV is the sodhana-reduced grid actually used for pindas, and that no interpretation is added. It also discloses the main omission (prastara contributor grid), which goes well beyond the annotation signal.

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 the domain output is genuinely complex and every clause earns its place by defining a distinct returned structure or a relationship between them. It front-loads the core purpose and only then layers in definitions; the only minor redundancy is the parenthetical pinda formula, which is already contained in the names.

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 carries the full burden of explaining return values, and it does so exhaustively: all keys are named, their shapes and counts are described, the meaning of higher SAV is given, and the two most likely questions (what does SoAV mean and why is the Ascendant absent) are answered. Nothing needed for a correct call or a correct reading of the result 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 input fields are already fully documented in the schema and the description does not need to restate them. The description adds no parameter-specific meaning beyond context terms like 'sign', which is acceptable given the complete 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?

Opens with a specific verb and resource: 'Return the Ashtakavarga bindu (benefic point) scores for the chart, labelled by planet and sign.' It then explains the distinct output keys (BAV, SAV, SoAV, pindas) and explicitly states 'Data only — no interpretation is added,' so an agent can clearly distinguish this from sibling chart-analysis 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 does not name sibling alternatives, but it gives an implicit eligibility test: use this when raw Ashtakavarga bindu data is requested, and not when interpretation or the detailed prastara contributor grid is wanted, since those are explicitly excluded. This is clearer than typical tool descriptions but stops short of naming the alternative tool for those needs.

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

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

Beyond the readOnly/idempotent annotations, the description discloses the return structure, the exact formulas (rupas = virupas / 60, strength_ratio = rupas / required minimum), the meaning of values above 1, and the absence of interpretation. This is rich behavioral context that annotations alone do not 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?

Four sentences, each adding necessary information: purpose, key names, value semantics, and the data-only caveat. The most important identifying information is front-loaded, and there is no filler or redundant restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Since there is no output schema, the description fully compensates by specifying the exact keys, the three value fields per house, the units, the threshold interpretation, and the ordering convention (House 1 = Lagna). An agent has enough context to call the tool and interpret its 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%, and the input schema already documents all seven parameters with formats and examples. The natural-language description focuses on output semantics rather than repeating parameter details, which is appropriate; it adds nothing about parameters, so baseline 3 applies.

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

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

Begins with an explicit verb-object pair ('Return the Bhava Bala') and identifies the resource as the 12 houses/bhavas. The detailed key naming and mention of strength ratio distinguish it from sibling tools like get_shad_bala or get_other_bala without needing to open their 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 closing 'Data only — no interpretation is added' gives clear context about when this tool is appropriate: when raw house-strength values are needed, not an interpreted reading. It does not name a specific alternative tool for interpretation, so it falls just short of explicit when-not-to-use 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations by specifying the exact output shape (chandra_arudha_house_1 through 12, each value a zodiac sign) and emphasizing that no interpretation is added.

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: it states the purpose first, then the output keys and value semantics, then the interpretive boundary. Every sentence contributes useful information 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 explaining the return structure and the calculation basis. It is slightly incomplete in that it does not explicitly point to sibling alternatives for non-Moon arudhas, but this is more a usage-guidance gap than a completeness one.

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 in detail. The description does not add parameter-level semantics beyond mentioning the Moon-based calculation, 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 uses a specific verb ('Return') and resource ('the chandra arudhas: the arudha sign for each of the 12 houses counted from the Moon') and details the exact output keys and value semantics. This clearly distinguishes it from sibling arudha tools such as get_surya_arudhas or get_graha_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?

The phrase 'Data only — no interpretation is added' implies a raw-data use case, and the 'Chandra Lagna' basis gives context. However, it does not explicitly state when to choose this over closely related sibling tools like get_arudha_padas, get_graha_arudhas, or get_surya_arudhas, leaving the selection partly 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 and idempotentHint=true; the description adds meaningful context beyond that by specifying the exact assignment rule ('Roles are assigned by descending planetary longitude') and by explicitly stating the output is raw data with no interpretation. This is useful behavioral disclosure without contradicting 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 front-loads the core purpose in the first sentence and spends the rest of its length productively enumerating the eight roles, their meanings, and the per-value fields. No sentence is wasted; the final 'Data only' sentence earns its place as usage 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?

With no output schema, the description fully specifies the return structure: eight roles, each with 'planet', 'sign', and 'longitude', plus the assignment rule. Combined with the schema's complete parameter documentation, an agent has everything needed to select and invoke this tool correctly.

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

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

The input schema documents all 100% of parameters with types, formats, and examples, so the baseline is 3. The description adds no parameter-level meaning beyond the schema; it focuses on output and roles, which is appropriate but not a semantic enhancement to any input parameter.

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.' It then enumerates the eight roles and their data shape, which clearly distinguishes this from the many sibling get_* tools that return different astrological constructs.

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 closing statement 'Data only — no interpretation is added' gives a clear usage context: call this when raw Jaimini karaka values are wanted rather than interpretive astrology. It does not name an alternative tool or explicitly state when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description goes well beyond them by detailing the returned node shape, relation labels (past/current/future), depth behavior, graha vs rasi level differences, selected_maha/selected_antar routing, and the default vimsottari/depth behavior.

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

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

The description is front-loaded with the core capability, followed by a compact response contract and request instructions. The system lists are long, but they add categorical grouping absent from the flat schema enum; still, some token repetition could be trimmed without losing meaning.

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 effectively supplies the full response contract: node fields, result keys, defaults, depth semantics, and branch-selection behavior. It is complete enough for an agent to know exactly what will be returned and how to request the desired view.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics not present in the schema: antar requires maha, depth applies differently to graha vs rasi, as_of_date is separate from birth date, and the flat enum is categorized into planetary vs sign systems.

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: 'Return a dasha (planetary period) timeline as a nested tree anchored on a date', and immediately clarifies it covers both graha and rasi systems. It also marks the tool as 'Data only — no interpretation', which helps distinguish it from sibling interpretation-oriented 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?

There is explicit request guidance under 'HOW TO REQUEST': send birth details for the default, pass exactly one enum token for system, and optionally set as_of_date. It also explains the drill-down mode via maha/antar and depth defaults, but it does not explicitly compare against sibling tools or state when not to use it.

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

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

The annotations already provide readOnly, idempotent, and non-destructive hints; the description adds valuable behavioral context beyond that: the data-only nature, the default to D-1, the fallback behavior for unrecognized varga tokens, and the exact output mapping format. This is more than sufficient for an agent to predict tool behavior.

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

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

The description is longer than most, but every section earns its place: the core behavior is front-loaded, the token list is necessary for exact invocation, and the area mapping prevents guesswork. The clear spacing and bolded formatting make the 23-value mapping scannable rather than overwhelming.

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?

Despite having no output schema, the description specifies the response shape. Required parameters are fully covered by the input schema, the varga enum is semantically explained, defaults and error responses are documented, and the relationship to list_divisional_charts is clarified. An agent has everything needed 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?

Schema coverage is 100%, so the baseline is 3; the description adds real value by mapping each D-token to a meaningful area (e.g., D-9 marriage, D-10 career), emphasizing exact token formatting, and documenting the default. The other parameters are already well described in the schema, so the description does not need to repeat 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?

States a specific verb + resource ('Return ONE divisional (varga) chart') and describes exactly what the response contains, including the body-to-position mapping. This distinguishes it from related tools like list_divisional_charts, which is explicitly referenced as the menu-browsing alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit guidance for choosing each varga token via area mappings, states the default behavior when 'varga' is omitted, and points to list_divisional_charts when a menu is desired. It does not explicitly contrast this tool with all sibling tools, but the 'data only, no interpretation' note helps separate it from interpretation-focused 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 mark the tool read-only and non-destructive. The description adds useful behavioral detail beyond that: the result structure, the presence of reasoning, potential HTML markup in verdict text, and a 'data only, no interpretation' 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?

The description is compact, front-loaded with the action, and every sentence earns its place. The dosha list is long but necessary for disambiguation, and the HTML and data-only caveats are brief and valuable.

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 sufficiently explains the return shape: a mapping of dosha names to verdicts with presence and reasoning. It also covers the HTML caveat and confirms the tool adds no interpretation. Required parameters are fully handled by the schema.

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

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

The input schema already documents all parameters with 100% coverage, so the description does not need to re-explain them. It adds no parameter-specific meaning beyond the overall chart context, which matches the baseline for 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 names a specific verb and resource: 'Return the standard dosha checks for the chart.' It goes further by enumerating the exact doshas covered, which distinguishes it clearly 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?

The description gives clear context for when to use it: when standard dosha affliction checks are needed. It does not explicitly name alternatives or exclusions, but the scope is specific enough that an agent can route to it confidently.

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 signal read-only, idempotent, non-destructive behavior, so the description adds valuable extras: the 'Data only — no verdict' caveat, the default Mean node behavior for Rahu/Ketu with node_type='true' override, and the presence of D-1/D-9 charts under 'transit_charts.' These are real behavioral details not available in annotations or 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 description is dense but every clause earns its place: purpose, output contents, chart sections, node default, and the no-verdict boundary. The purpose is front-loaded, and the long enumeration is justified by the tool's broad output surface. There is no filler or repetition of schema data.

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 return content, and it does so thoroughly: panchanga components, muhurta windows, planet attributes, Tara Bala, Chandra Bala, Sade Sati, and transit charts are all enumerated. Combined with the full schema coverage for inputs, 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 baseline is 3. The description adds meaningful semantics beyond the schema by stating the default node type for Rahu/Ketu ('Mean node by default; pass node_type='true'') and by clarifying that the result covers a single target date snapshot. This goes beyond simple restatement of parameter names.

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: 'Planetary transit (Gochara) snapshot for a given date vs the natal chart.' The word 'snapshot' and the 'given date' scope distinguish it from sibling get_gochara_range, and the extensive output list makes the tool's role unmistakable.

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 frames when to use it: for a single-date gochara snapshot against a natal chart. It also states 'Data only — no verdict,' which is an explicit when-not for interpretation. It does not name sibling alternatives like get_gochara_range or get_muhurta, but the context is clear enough.

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 provide readOnly/idempotent/destructive hints, but the description adds meaningful behavioral context: no scoring or 'best date' selection, natal reference computed once, 60-day cap, and per-day snapshot composition. It doesn't cover rate limits or pagination, but the core behavior beyond annotations is disclosed.

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?

Description is appropriately sized, no wasted words, and the key differentiators are front-loaded. The 'AI decides' framing and the get_muhurta alternative sentence earn their place; only the long list of included sections borders on redundancy but it does clarify scope.

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 range query with full schema documentation, the description covers use case, scope, constraints, and alternative routing. It doesn't detail output structure, but there is no output schema and the description enumerates the main output sections, making the response shape predictable enough.

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 16 parameters meaningfully. The description adds context for the range semantics (from_date/to_date, 60-day cap) and mentions that natal reference is computed once, but this is supporting context rather than new parameter meaning. 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?

Description clearly states this returns raw per-day Gochara details for every day in a range, distinguishing it from get_gochara (singular) and explicitly contrasting with get_muhurta. The verb 'get' plus 'raw... for EVERY day... in one call' is specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use it ('AI decides' flow), what it returns, and when to use the alternative ('Use get_muhurta instead if you want the system to rank dates by rules'). This is excellent routing guidance, though it doesn't enumerate all sibling exclusions — the key one is addressed.

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 valuable behavioral context beyond the annotations by enumerating the exact output keys and stating that each value is the zodiac sign of that arudha, which is especially useful because there is no output schema. The 'Data only — no interpretation is added' note further clarifies that the tool returns raw data rather than interpretive commentary.

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: it states the core action and resource in the first clause, then uses the rest of the sentence to specify the exact output keys and value semantics. The final sentence about data-only output is short and earns its place. There is no filler or repetition of schema 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?

Given that there is no output schema, the description competently compensates by listing all ten output keys and their value type, so an agent knows what to expect. The read-only/idempotent behavior is already covered by annotations. Minor gaps remain, such as not describing error behavior or clarifying the relationship with the more specific arudha sibling tools, but the core calling context 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%, and all seven parameters have meaningful descriptions in the schema, including the optional gender enum with a clear explanation of its effect. The tool description itself adds no parameter-level meaning, but because the schema already handles parameter semantics thoroughly, the 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 clearly states a specific verb ('Return') and a precise resource: the graha arudhas for the Ascendant and all nine grahas. It also enumerates the exact output keys and their value type (zodiac sign), making the tool's purpose unambiguous. It does not explicitly differentiate itself from sibling tools like get_chandra_arudhas or get_surya_arudhas, but its scope is clear enough on its own.

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 does not state when to use this tool versus alternatives such as get_arudha_padas, get_chandra_arudhas, or get_surya_arudhas. The phrase 'Data only — no interpretation is added' conveys what the output will be, but it does not provide explicit selection guidance or exclusions. An agent would have to infer usage context from the tool name and sibling names.

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, and non-destructive behavior, lowering the burden on the description. The description adds useful context beyond annotations by stating that the result is raw data with no interpretation added, and by specifying the exact key/value structure. This helps the agent set expectations about the response without seeing an 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 description is two sentences with no wasted words. The main function is stated first, followed by the output format and the 'data only' behavioral note. Every sentence contributes essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a data-only retrieval tool with no output schema, the description compensates well by specifying the output keys and value fields. It does not explain what 'varnada lagnas' are, but that is domain terminology consistent with sibling tools. Minor gaps remain around exact value formats and possible missing houses, but these are not critical for selecting and invoking the tool.

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

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

Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description does not add material meaning about how date, time, location, gender, or other inputs influence the result. It simply describes the output, which is appropriate but does not exceed the baseline for 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 states a specific verb and resource: 'Return the varnada lagnas for the houses.' It then clarifies the exact output shape (keys V2 through V12, each with sign and longitude), making the tool's function unambiguous and distinct from the broader set of astrological data tools. Sibling differentiation is not explicit, but the resource and output contract are precise enough.

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 no guidance on when to prefer this tool over alternatives such as get_special_lagnas or get_sphutas. There is no mention of exclusions, prerequisites, or comparison with sibling tools. The intended usage is only implied by the tool name and the description's focus on varnada lagnas.

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 and idempotentHint=true, and the description adds significant behavioral detail beyond that: it does not issue a verdict, 'overall_assessment' reflects only the sign-modality method, 'method_note' states it is not reconciled, age brackets are cited footnote values rather than claims, and presence booleans are explicitly defined. This goes well beyond the structured 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 long but front-loaded with purpose and non-verdict clarification, then systematically walks through all returned fields. Every sentence adds meaning given the absence of an output schema, though the dense single-paragraph structure could be improved with bullets or shorter 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?

With no output schema, the description carries the full burden of explaining the return payload, and it does so thoroughly: every notable field ('overall_assessment', 'method_note', 'checks_summary', 'baladrishta_checks', 'alpayu_checks', 'madhyayu_checks', 'calculation_basis', 'key_planetary_positions', 'reference_computations', 'longevity_related_yogas') is defined. It also clarifies the tool's interpretive scope, making it complete for an agent deciding whether and how to call it.

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

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

Schema description coverage is 100%, so the schema already fully documents all seven parameters including the optional gender behavior and timezone format. The description adds no parameter-specific semantics beyond referring to the chart generally, so the baseline of 3 applies.

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

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

The description states a specific verb ('Return'), a specific resource ('the chart's classical Ayurdaya (longevity) computations'), and a clear scope: it exposes classical signals for astrologer interpretation rather than issuing a verdict. This clearly distinguishes it from siblings by emphasizing the classical-signals inventory and the explicit non-verdict nature.

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 usage context: use it when you need classical Ayurdaya signals side-by-side and explicitly clarifies that it does not deliver a longevity verdict. It implies the tool is for astrological interpretation rather than automated conclusion, but it does not name alternative sibling tools or state when to choose another 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 read-only, idempotent, non-destructive behavior. The description adds substantial behavioral context by enumerating the exact return structure and explicitly stating 'Data only — no interpretation is added,' which is valuable beyond the structured fields.

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 information-dense, front-loaded with purpose and followed by a comprehensive but organized breakdown of return fields. Each sentence contributes useful detail, and while it is lengthy, the complexity of the output justifies the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: summary, north_indian, south_indian, boy/girl details, dosha data, and beeja/kshetra fields are all listed. The nested parameter structure is also explained enough for an agent to construct valid calls.

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

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

Schema coverage is 100% and the schema already provides detailed descriptions for the 'boy', 'girl', and 'system' parameters. The description reinforces the parameter structure by restating the required fields and explaining the north/south return systems, but adds limited new semantic meaning beyond what the schema already offers.

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: 'Check Vedic marriage compatibility between a couple.' It also explicitly distinguishes itself from siblings by noting 'Unlike the other tools, this needs TWO births,' making its unique scope unmistakable.

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 indicates when to use this tool (for marriage compatibility) and contrasts with other tools that require only one birth. It also provides guidance on selecting output systems via the 'system' parameter, but does not explicitly state when not to use it beyond the two-birth distinction.

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 and idempotentHint=true, but the description adds substantial behavioral context: deterministic scoring with breakdown and weights, the Abhijit best-window, the Rahu/Gulika/Yamaganda avoid-windows, and the cap on failed mandatory rules. There is no contradiction with the annotations; the description reinforces the read-only, deterministic nature.

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: purpose, scoring factors, output elements, event types, and caller responsibility. It is front-loaded with the main purpose and routes to an alternative in the final sentence, with no filler or repeated schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because there is no output schema, the description carries the burden of explaining return values, and it does so thoroughly: sorted candidates with score breakdown and weights, the Abhijit best-window, and the Rahu/Gulika/Yamaganda avoid-windows. It also covers the failure cap and the data-only behavior, so an agent can predict the tool's output well enough to invoke 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?

The input schema covers all 17 parameters with 100% description coverage, so the description starts at the baseline 3. It adds only a redundant restatement of the event_type enum and general references to the 'event's rule table' and the native's balas, rather than new per-parameter semantics beyond the schema.

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

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

The description opens with a specific action ('Find auspicious dates'), identifies the resource ('the event's rule table'), and enumerates exactly what the tool returns. It also distinguishes itself from get_gochara_range in the closing sentence, so an agent can tell it apart without inspecting the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use this tool versus the raw-data sibling: 'Use get_gochara_range instead to get raw per-day details and decide yourself.' It also clarifies the division of labor with 'Data only — the caller writes the recommendation,' giving the agent a clear directive on its own responsibility.

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 specifying exactly what data is returned, the fields included, value ranges, and the fact that interpretations are deliberately excluded.

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 detailed but every clause earns its place: it lists the bodies, the five output fields with examples and ranges, and the data-only boundary. The most important action and object are front-loaded, and the length is justified by the absence 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?

Despite having no output schema, the description defines the complete return contract: all 13 bodies and all 5 fields with types, ranges, and examples. It also clarifies sidereal basis and excludes interpretation, so an agent has enough context to 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 baseline applies and the schema already explains every input parameter. The description focuses on output semantics rather than adding new meaning to date, time, coordinates, or timezone, which is acceptable 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 names the exact verb and resource ('Return the birth (sidereal) nakshatra...') and enumerates every body and every output field with examples. Even without naming a sibling, the field-level detail and the explicit 'Data only — no interpretation' qualifier make the purpose unmistakable.

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 stating this is raw data only and no interpretation is included, which helps an agent avoid using it when interpretation is desired. It does not explicitly name alternatives or state when-not-to-use it, so it stops short of the strongest 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 readOnlyHint and idempotentHint, so the description does not need to restate those. It usefully adds behavioral detail: outputs are maps keyed by planet, ishta_phala is 0-60, kashta_phala is derived as 60 - ishta, and no interpretation layer is added. This complements 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 a single substantive sentence with a compact enumeration of output keys and parenthetical clarifications. The main action and scope are front-loaded, and every clause earns its place with no filler or repetition.

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 properly explains the return shape: named maps, planet-name keys, value ranges, and the relationship between ishta_phala and kashta_phala. Input requirements are fully delegated to the schema. The main gap is the lack of comparative routing guidance against sibling bala tools, but the essential call-time context is present.

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 fully documents all 7 parameters, including optionality and character of place and gender, so the schema carries the parameter-semantics burden. The description adds no parameter-level guidance, which is acceptable given the 100% schema description 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 additional planetary strength measures for the seven planets (Sun..Saturn).' It then names the exact measures returned, making the tool's scope concrete and distinguishable from sibling bala tools like get_shad_bala and get_vimsopaka_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 'Data only — no interpretation is added' phrase gives some implicit usage context, suggesting this is a raw data retrieval tool. However, it never explicitly says when to use this tool over its several bala-related siblings, nor does it state any exclusion conditions.

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 annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it explains the exact grouping semantics, that the output is lists of planet names grouped by condition, and that absence from all lists means neutral sign. It also discloses that the tool is data-only with no interpretation layer. 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 a single dense paragraph that front-loads the primary action and resource, then enumerates output fields and their meanings. It is longer than a typical tool description, but every sentence earns its place by defining astrological terms that would otherwise be ambiguous. It could be slightly more scannable with bullet formatting, but the structure is logical and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the input schema covers all parameters at 100%, annotations cover the safety profile, and there is no output schema, the description does its job completely: it defines every return field and the neutral-sign boundary condition. An agent can invoke this tool and interpret the JSON response without missing information.

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 schema already fully documents all seven parameters. The description adds no parameter-level information beyond what the schema provides, which is acceptable given the baseline of 3. The optional 'gender' parameter's behavior is already well-documented in the schema, so no additional description burden falls on the tool description.

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

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

The description clearly identifies the resource ('dignity and motion state of the planets'), the action ('Return'), and the grouping ('by condition'). It enumerates all seven output fields with precise astrological definitions, which distinguishes it from sibling tools like get_gochara or get_yogas that also concern planets but return different data. The 'Data only — no interpretation' note further clarifies 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 implicitly communicates when to use this tool: when you need planet dignities and retrograde/combustion states without interpretation. It doesn't explicitly name alternatives or state when not to use it, but the 'Data only — no interpretation' clause and the explicit field listing provide enough context for an agent to differentiate it from interpretation-heavy siblings like get_doshas or get_yogas. A more explicit pointer to a sibling would have earned a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: retrograde back-out and re-entry, forward/retrograde flags, 'final_settling' marker, and the ~5-year range cap. It also clarifies that the tool returns data only.

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 concise: three sentences that front-load the core purpose, then add output details, use case, and limitations. Every sentence contributes value and there is 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?

There is no output schema, so the description takes on the burden of describing the return contents. It mentions every sidereal sign change, retrograde events, flags, and 'final_settling,' along with the range cap and data-only nature. It does not specify a formal response structure, but it gives sufficient information for an agent to understand 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 baseline is 3. The description reinforces the default planet list but does not add meaningful parameter-level details beyond what the schema already provides (e.g., date formats, timezone, ayanamsa mode).

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's purpose: returning sign-change (ingress) dates for planets over a date range, with retrograde awareness. It specifies the default planets (Saturn/Jupiter/Rahu/Ketu) and distinguishes itself from sibling tools like get_saturn_transit by focusing on ingress timing rather than current transit positions.

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 an explicit use case: 'Use for "when does Saturn/Jupiter change sign" timing.' This gives clear context for when to select this tool. However, it does not explicitly name alternative tools or exclusions, which would make the guidance more complete.

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 and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the exact output mapping (saham name to zodiacal position), the formatting (sign + degrees/minutes/seconds), and the 'data only' guarantee. It does not discuss errors or edge cases but does not need to at this level.

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 well-structured and efficient: first sentence states the primary purpose, second sentence details the return format with a concrete example, and third sentence clarifies scope and limitations. Every sentence carries useful information with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description appropriately explains the return value format and lists example saham names, making the tool's output predictable. It does not explicitly mention the ayanamsa or house system used, which could be relevant, but that may be considered a domain detail rather than a selection-facing gap. Overall it is sufficiently complete for an agent 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 parameters are already fully documented in the schema. The description does not need to re-explain parameters; its phrase 'of the chart' implicitly connects the input birth data to the calculation. This is adequate, but no extra semantic value is added beyond the schema.

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

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

The description uses a specific verb ('Return') and identifies the exact resource: sahams (Arabic parts / sensitive points) of the chart. It clearly distinguishes itself from sibling tools by specifying the unique astrological concept and the output format, so an agent can immediately know what this tool computes.

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 implied usage context by stating it returns data only and adds no interpretation, which suggests when not to use it (when interpretation is needed). However, it does not explicitly name alternative tools or give concrete when-to-use/when-not-to-use conditions.

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 behavior, so the safety profile is covered. The description meaningfully adds that the tool returns bare data with no interpretation, and it discloses the dual degree-based/sign-based representation of Sade Sati — useful behavioral context beyond the annotations.

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

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

The description is dense and long, but every clause earns its place: it explains the output structure, field names, phase splits, date ranges, and the no-interpretation behavior. The opening sentence front-loads the core purpose. Minor structure improvements could break the long paragraph into scannable sections, but nothing is redundant.

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 carries the burden of explaining return values, and it does so thoroughly: sadeSati variants, phases, moonTransits, ascendantTransits, reference degrees/signs, and the startDate/endDate/description structure are all covered. It stops short of describing error conditions or edge cases, but for a data-return tool this is a strong, self-sufficient explanation.

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 already fully documented in the schema. The description does not add parameter-level guidance, but it does clarify that the output depends on the natal Moon and Ascendant, which helps explain why those chart inputs are relevant. This meets the baseline for schema-heavy parameter documentation.

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 ('Return') and a clear resource ('Saturn's Sade Sati and related transit windows for the chart, with dates'), making the tool's purpose immediately obvious. It does not explicitly contrast itself with sibling tools, but the resource is specific enough that the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when raw Saturn Sade Sati or transit-window data is needed, and the closing note 'Data only — no interpretation is added' hints that this is not the tool for interpretive output. However, it does not explicitly name alternatives or state when not to use it relative to the many sibling transit/chart 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 indicate read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context: 'Data only — no interpretation is added' clarifies that the tool returns raw values rather than judgments, and 'Each component maps planet name to its value' explains the output structure. It also explains units and the strength-ratio threshold, which 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 compact and well-structured: it front-loads the main verb and resource, then logically lists the six components and derived metrics in a readable sequence. Every sentence adds needed information, and the closing 'Data only' note is a useful clarification without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema present, the description shoulders the full burden of explaining return values, and it does so thoroughly: all six component names with glosses, total_virupas, total_rupas, strength_ratio with its threshold meaning, and the planet-to-value mapping. Required input parameters are already fully covered by the schema. The description is sufficient 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?

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific guidance and focuses entirely on output semantics. Since the schema already documents every parameter with format examples and enum explanations, the description does not need to compensate for any 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 opens with a specific verb 'Return' and names the exact resource: Shadbala of the seven planets. It enumerates the six components and derived metrics, so an agent can identify what the tool produces without ambiguity. It does not explicitly differentiate from sibling bala tools like get_other_bala or get_bhava_bala, so it is clear but lacks explicit sibling distinction.

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?

There is no guidance on when to use this tool versus alternatives among the many sibling tools. The description only states what the tool returns and does not mention when to prefer it over other bala-related tools or any exclusions. An agent must infer usage purely from the tool name and output details.

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. The description adds meaningful context beyond that: it explains the output shape ('each lagna maps to its sign and longitude'), lists the exact lagnas returned, and clarifies that no interpretation is included.

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 concise and front-loaded with the core purpose. The list of the nine included lagnas is informative without being redundant, and the final 'Data only' sentence adds clear behavioral value.

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 return shape and the exact set of lagnas. It omits minor details like the exact representation of 'sign' or 'longitude', but it gives an agent enough to understand what will be 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?

The input schema covers 100% of parameters with descriptions, so the schema carries the burden. The tool description adds no parameter-level detail, but it does not need to; the baseline 3 is appropriate.

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

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

The description uses a specific verb ('Return') and a clearly identified resource: the special derived lagnas of the chart. It names each included lagna explicitly, which distinguishes this tool from sibling tools like get_sahams or get_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?

No guidance is given about when to use this tool versus alternatives, and no exclusions are stated. The closest hint is 'Data only — no interpretation is added,' which implies raw-data use cases but does not name or contrast against any other 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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond that: the response is a name-to-position map, positions use sign/DMS formatting, and no interpretive layer is included. This gives the agent an accurate mental model of the call's behavior without contradicting the annotations.

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

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

The description is front-loaded with the core purpose, followed by the output format with a concrete example, then a comprehensive list of included sphutas, and finally a short no-interpretation caveat. Every sentence earns its place; even the long list is informative rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema to rely on, the description compensates by specifying the exact return structure, the formatting convention, and the full set of expected sphuta names. Combined with the fully documented input schema and strong safety annotations, the tool definition is complete enough for an agent to invoke it correctly and interpret the response.

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 across all seven parameters, including defaults and the gender-omission rule, so the baseline of 3 applies. The description itself adds no parameter-specific semantics, but the schema already carries that burden completely.

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 sphutas (special computed sensitive points) of the chart.' It details the exact output shape — a mapping from sphuta name to zodiacal position with sign and degrees/minutes/seconds — and enumerates the included sphutas, making the scope unambiguous and differentiating it from sibling tools like get_sahams or get_special_lagnas.

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 the tool by defining its output as raw computed positions, and the closing 'Data only — no interpretation is added' gives a clear signal about what the tool will not do. However, it does not explicitly state when-not-to-use it or name any sibling alternatives, so the agent must infer routing from the tool name and output 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 disclose read-only, idempotent, and non-destructive behavior. The description adds the behavioral trait that no interpretation is added, and specifies the exact output shape (12 keys, each value a zodiac sign). This goes beyond what annotations provide, though it doesn't address edge cases or error conditions—acceptable for a simple read-only calculation.

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

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

Two dense sentences carry all essential information: the first defines the resource and calculation basis, the second gives the exact key pattern, value semantics, and the raw-data qualifier. No filler, front-loaded with the core purpose, and 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?

For a read-only tool with no output schema, the description adequately covers what is returned, the key format, the value meaning, and the data-only scope. The input requirements are fully covered by the schema. The only notable gap is explicit sibling differentiation, which is partially addressed by the 'Sun (Surya Lagna)' phrasing.

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 7 parameters are fully documented in the schema. The description adds no parameter-specific semantics beyond implying that the Sun's position, derived from date/time/location, drives the calculation. This meets 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 the specific verb 'Return' and the precise resource 'surya arudhas', then explains exactly what that means: the arudha sign for each of the 12 houses counted from the Sun. This distinguishes it from sibling tools like get_chandra_arudhas and get_graha_arudhas even without naming them. The output key pattern is also specified, removing ambiguity about what the tool does.

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 this when raw Sun-based arudha signs are needed. However, the description doesn't explicitly state when to prefer this over alternatives like get_chandra_arudhas or get_graha_arudhas, nor does it provide any exclusions. The 'Data only' line hints at a raw-data use case but doesn't say when not to use it.

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

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructiveness. The description adds useful behavioral context beyond that: it clarifies the tool returns raw data with no interpretation, specifies the output shape (sign and longitude), and lists all included upagrahas. 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?

Two sentences with no filler. The first sentence front-loads the action and object; the second adds the output structure and the complete member list, which is valuable for an agent deciding whether this tool returns what it needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description compensates by explaining that each upagraha maps to 'sign' and 'longitude' and by enumerating all returned items. It could add edge-case behavior such as missing or uncalculated upagrahas, but for a raw read-only list tool this is adequately complete.

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

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

Schema description coverage is 100%, so the schema already fully documents all parameters. The description adds no parameter-specific semantics, so the baseline of 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?

States a specific verb ('Return') and resource ('upagrahas'), and enumerates the exact set of upagrahas returned. The phrase 'shadowy sub-planets / calculated upagrahas' and the list distinguish it from astrological sibling tools even without naming them.

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 when-to-use or when-not-to-use guidance is given, and no sibling alternatives are mentioned. 'Data only — no interpretation is added' hints at a use case but does not explain how this differs from interpretive tools like get_yogas or 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?

Annotations already establish readOnly/idempotent/non-destructive behavior. The description adds useful context beyond annotations: the result is raw data with no interpretation, and it specifies the exact list structure, string format, and example. No contradiction.

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 action, then packs the four schemes, planet list, string format, example, and data-only note into a dense but focused block. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description carries responsibility for return semantics, and it does so thoroughly: list size, schemes, key names, string layout, and example. It omits only edge-case/error behavior and usage context, which is acceptable for a read-only calculation tool.

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

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

Schema coverage is 100%, so all parameters are already documented in the input schema. The description adds no parameter-specific semantics, but it does not need to because the schema carries the full 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 first sentence names the exact computation and resource ('Vaiseshikamsa Bala — the count of auspicious vargas each planet attains') and the description enumerates the four weighting schemes and the output format, making it easy to distinguish from sibling bala/dignity tools without further research.

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 when-to-use or alternative guidance is provided. It does not mention when to prefer this over get_shad_bala, get_vimsopaka_bala, or get_other_bala, and no exclusions are stated; only a raw-data note is present.

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 description need not restate safety. It adds valuable behavioral context by disclosing the exact return structure: a list of four weighting schemes, the string format 'AmsaName\n(vargas)\nscore', and an explicit statement that no interpretation is added. This goes beyond the annotations in a useful way.

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 purpose and then explains the output format with a concrete example. It is longer than a one-liner, but every sentence earns its place because there is no output schema to carry the return-type details. There is no filler or repetition.

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 no output schema exists, the description compensates by fully specifying the return shape: a list of four entries, mapping of nine planets to amsa/vargas/score strings, with a concrete example. It also clarifies scope with 'Data only — no interpretation is added.' The only notable gap is guidance on when to prefer this tool over sibling bala tools.

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 already documents all seven parameters with formats, defaults, and optionality. The description does not add parameter-specific meaning, though it helps contextualize the inputs by describing the planetary and divisional-chart domain. Baseline 3 is appropriate because the schema 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 states a specific verb ('Return'), a precise resource (Vimsopaka Bala), and explains its core concept: each planet's strength based on the dignity (varga/amsa) it occupies across divisional charts. It is clear and detailed, but it does not explicitly differentiate this tool from related siblings such as get_shad_bala, get_bhava_bala, or get_other_bala, so it misses the top score.

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?

There is no guidance on when to choose this tool over the many sibling bala tools. The description only explains what the tool returns, leaving the selection context entirely implied. No when/when-not conditions, alternatives, or exclusions are mentioned.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond that by detailing the exact output shape, stating that all detected yogas are included with no truncation, and explicitly saying no interpretation is added—so the agent knows this tool returns data, not analysis.

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 efficiently structured, front-loading the core purpose and then explaining the response format with exact keys and a concrete shape. Every sentence adds value, and the inline examples clarify the abstract structure without excessive length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the full burden of explaining return values. It does so thoroughly: both parts of the result, exact summary keys, the yoga_list mapping, the meaning of each element in the 4-element list, and the guarantee that all detected yogas are included. No critical usage 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?

Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description does not add any additional parameter-level meaning, such as how gender affects yoga computation, but it is not required to compensate for gaps because the schema already covers all seven parameters.

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

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

The description states a specific verb and resource: 'Return every yoga (planetary combination) detected in the birth chart.' It also clarifies the scope ('every yoga' and 'All detected yogas are included') and distinguishes itself from sibling astrological computation tools by defining yoga as planetary combinations and noting it provides raw data only.

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 through 'Data only — no interpretation is added,' suggesting this tool is for raw yoga data rather than interpretive output. However, it does not explicitly state when to choose it over alternatives, such as generate_horoscope or get_doshas, and names no sibling alternatives or exclusions.

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 bar is lower. The description adds that it returns request_as, name, and purpose for each chart, takes no birth details, and is data-only with no interpretation, providing useful behavioral context beyond the annotations.

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

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

Four concise sentences provide complete information without filler. The key purpose is front-loaded, and every sentence adds value; no unnecessary repetition of schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with no parameters and no output schema. The description explains what is returned (request_as, name, purpose) and how to use the result, making it fully actionable for the agent. Nothing else is needed.

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 tool has zero parameters and the schema is fully covered. The description expressly says 'Takes no birth details', reinforcing that no inputs are needed, which is useful for the agent. Baseline for 0 params is 4.

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 the specific verb 'List' and clearly identifies the resource as 'the 23 divisional (varga) charts'. It distinguishes itself from sibling 'get_divisional_chart' by explaining it returns the request_as values needed for that tool, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Use this to choose the right chart for a question, then call get_divisional_chart with that varga.' This provides clear when-to-use guidance and names the alternative tool. Also notes it takes no birth details, which further clarifies when it is appropriate.

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