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

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

Annotations already declare read-only, idempotent, and non-destructive behavior, lowering the burden. The description adds valuable behavioral context by disclosing the caching side effect and that later tools reuse the chart, which 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?

Two sentences, front-loaded with the action and output, followed by a concise usage note. Every sentence 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?

For a tool that generates a base chart with no output schema, the description explicitly lists the return summary and caching behavior, making it sufficient for an agent to select and invoke correctly. The input schema fully covers parameter details, and the sibling context indicates this is the foundational 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 well-documented. The description only summarizes inputs as 'birth date, time and place' without adding syntax or format details beyond what the schema provides, matching 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 uses a specific verb 'Generate' with a clear resource 'Vedic (sidereal) birth horoscope' and lists the exact output fields (ascendant/lagna, moon sign, sun sign, birth nakshatra and pada). It distinguishes itself from the many sibling get_* tools by explicitly instructing 'Call this first' and noting cache 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?

Provides explicit when-to-use guidance: 'Call this first' and explains the relationship to later tools that 'reuse the same cached chart.' This clearly tells the agent the correct sequencing and that this is the prerequisite for other chart-related 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 and idempotent behavior. The description adds meaningful behavioral context: the exact fields returned, the comprehensive list of points covered, and the explicit statement 'Data only — no interpretation is added.' 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 dense but well-structured: it leads with the core purpose, then itemizes output fields and covered point categories. Every sentence adds useful information, and there is no filler or repetition of schema details.

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

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

With no output schema, the description carries the burden of explaining return values, and it does so clearly by naming the fields (sign, longitude, division_index, amsa_index, amsa_name) and the full set of chart points. It is comprehensive for a read-only data-retrieval tool, though it omits potential edge cases like sidereal/ayanamsa options.

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 six parameters with clear descriptions and 100% coverage. The tool description adds no additional parameter-specific semantics, so it meets the baseline but does not exceed it.

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 amsa (fine sub-division) ruler for every point in the chart.' It then enumerates the exact points covered and the output fields, clearly distinguishing this tool from sibling tools that return only upagrahas, sphutas, or 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 makes the tool's scope explicit—it covers all points and returns raw data with no interpretation—which gives clear context for when to use it. However, it does not explicitly name alternatives or state when not to use this tool, so it falls just short of the fullest 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 indicate read-only and idempotent behavior. The description adds valuable context beyond annotations: the exact key naming convention, the list of 12 padas, the one-chart-per-call limit, and the '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 well-organized: purpose first, then key format, then pada list, then parameter guidance. It is somewhat lengthy due to the full enumeration of padas and varga tokens, but every element serves a purpose and adds clarity.

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 explaining the output key-value structure, the default chart, and the one-chart limit. It covers the main behaviors for a 7-parameter read-only tool, though it does not discuss error cases or output sign format in detail.

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 carries most parameter documentation. The description supplements the 'varga' parameter with explicit usage instructions (exact tokens, hyphenation, default behavior), adding meaning beyond the schema. Other parameters already have clear examples in 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 clearly states the tool returns arudha padas for divisional charts, specifies the 12 padas per chart, and explains the key format. It distinguishes from sibling tools like get_graha_arudhas or get_chandra_arudhas by focusing on house-based padas for any divisional chart.

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

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

The description gives clear context on default behavior (D-1 chart) and how to specify a different chart via the 'varga' parameter, including the exact tokens and the 'only one chart per call' rule. It does not explicitly name sibling alternatives for when to use them instead, but the scope is well understood.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds behavioral detail: it enumerates exactly which outputs are returned, clarifies that higher SAV signs are stronger, explicitly says no interpretation is added, and notes the prastara grid is excluded. This is rich contextual disclosure.

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

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

The description is dense with technical detail, using compact notation like 'BAV' and 'SAV', and every sentence serves a purpose. It is not overly long for the complex output it describes, though the multi-clause structure could be slightly streamlined.

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

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

Since there is no output schema, the description carries the full burden of explaining return values. It does so comprehensively: it names all result fields, their meanings, the keying structure, and even what is intentionally omitted. For a chart-calculation tool, this is complete contextual 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?

The input schema covers 100% of parameters with meaningful descriptions, so the baseline is 3. The tool description does not add any parameter-level detail, but it also does not need to because the schema already explains date/time/location fields fully.

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 precise verb-object statement: 'Return the Ashtakavarga bindu (benefic point) scores for the chart, labelled by planet and sign.' It names the exact output (BAV, SAV, pindas) and is clearly distinct from sibling tools like get_shad_bala or 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 description says the tool returns 'Data only — no interpretation is added,' which implies it is for raw retrieval rather than interpretive guidance. However, it does not explicitly state when to use this tool versus an alternative, nor does it mention exclusions such as 'use get_gochara for transits.'

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 and idempotent behavior, lowering the bar. The description adds that no interpretation is provided and explains the strength threshold meaning, offering useful behavioral context beyond annotations. It does not cover error handling or edge cases, but the added context is valuable.

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 well-structured, with the main purpose front-loaded. Each sentence provides useful detail, though 'A higher value means a stronger house' is slightly redundant given the strength_ratio explanation. Overall, it is efficient and clear.

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 fully specifying the return keys and field semantics. It covers the tool's output comprehensively for a read-only computation. It lacks edge-case notes, but given the closed, non-destructive nature, it is reasonably 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?

The schema already describes all parameters with 100% coverage, so the baseline is 3. The description does not add anything new about parameter meanings or usage; it focuses on output structure, which is appropriate given the schema's thoroughness.

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 that it returns Bhava Bala (strength of the 12 houses) with a specific output structure. However, it does not explicitly differentiate from sibling tools like get_shad_bala or get_other_bala, which are also strength-related.

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 as a raw data source for bhava strengths and includes the note 'Data only — no interpretation is added', giving some context. But it lacks explicit when-to-use guidance or alternatives, so it only partially fulfills this dimension.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context: the output key scheme, that values are zodiac signs, and that no interpretation is added. 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 three focused sentences, front-loaded with the action and purpose. It includes output format and a caveat about no interpretation, with zero wasted words.

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 output keys and value type, which is essential for an API client. It does not cover error cases or edge conditions, but for a read-only calculation tool with well-documented parameters, this is a reasonably complete description.

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%, with all six parameters described in the input schema. The description does not add any parameter-level details beyond the schema, so 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 the verb 'Return' and the exact resource: chandra arudhas for each of the 12 houses counted from the Moon. It distinguishes itself from sibling tools like get_surya_arudhas by explicitly mentioning Chandra Lagna and providing a specific key pattern.

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

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

The description implies when to use this tool (when you need Moon-based arudhas) but does not explicitly state when not to use it or mention alternative tools. This is adequate implied guidance, but lacks exclusions or direct sibling comparisons.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context by explaining the assignment rule ('descending planetary longitude') and the scope ('Data only — no interpretation is added'), which go 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 focused paragraph that front-loads the main action and resource. The role enumeration is lengthy but necessary to define the output structure; every sentence contributes to understanding the tool's purpose or output.

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

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

With no output schema, the description fully compensates by describing the return format: each role maps to a value with 'planet', 'sign', and 'longitude', and the assignment method is stated. Input parameters are completely covered by the schema, and the data-only note clarifies expectations.

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

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

Schema description coverage is 100%, with all five required parameters and the optional 'place' parameter fully described. The description does not add parameter-specific details beyond this, but the schema itself already provides sufficient semantics, so a 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 opens with 'Return the eight Jaimini chara (variable) karakas', using a specific verb and resource. It distinguishes itself from sibling tools by naming the Jaimini chara karaka system and listing the exact roles, unlike tools for other astrological components.

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

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

The description states clear context: it returns the eight chara karakas and explicitly notes 'Data only — no interpretation is added', implying this tool is for raw data retrieval. However, it does not explicitly mention when not to use it or point to alternative tools for interpretation.

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, but the description adds substantial behavior beyond that: it explains the one-call past/present/future design, node shape, response fields, default depth behavior (3 for graha, 2 for rasi), system routing, and selection echo behavior. This is rich behavioral context.

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 well-structured with clear sections (purpose, response shape, request instructions) and front-loaded with the core purpose. The main inefficiency is repeating the full system enum list that already exists in the schema, which adds redundancy. Still, every other sentence earns its place given the tool's complexity.

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

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

With no output schema, the description fully compensates by detailing the response structure, node fields ('level', 'ruler', 'start', 'end', 'relation'), top-level keys ('current', 'maha_timeline', 'selected_maha'), and differences between graha/rasi systems (e.g., rasi has no pratyantar). It also covers defaults, depth limits, and selective drilling, making it complete for this complex 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%, establishing a baseline of 3, but the description adds meaningful semantics: it clarifies that 'system' must be EXACTLY one enum token, that 'as_of_date' is separate from birth date, how depth levels map to tree levels, and how 'maha'/'antar' selection works regardless of date. This goes well beyond the schema's field descriptions.

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

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

The description clearly states the tool returns a dasha timeline as a nested tree anchored on a date, covering past, present, and future in one call. It explicitly distinguishes graha vs rasi systems and adds 'Data only — no interpretation', making the purpose specific and distinct from the many sibling astrological 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 provides explicit request guidance: 'HOW TO REQUEST: send only birth details for the default', optional system selection, as_of_date anchoring, and how to drill into specific periods using 'maha'/'antar'. It does not explicitly name alternative tools for exclusion, but the usage context is clear and actionable.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar for added disclosure is lower. The description still goes beyond annotations: it specifies the default behavior when 'varga' is omitted (D-1), what happens on an unrecognised value (returns the token list), and the exact output format. It also explicitly states 'Data only — no interpretation is included,' an important behavioral constraint not present in annotations. 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 well-structured with bolded section labels and front-loaded purpose, making it easy to scan. However, the 'HOW TO REQUEST' section redundantly lists all 23 enum tokens that already appear in the schema, adding length without new information. Most content earns its place, but this duplication is a minor inefficiency.

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 has 7 parameters, no output schema, and a complex enumeration of 23 varga tokens. The description fully compensates: it explains the return structure, default, error handling, the absence of interpretation, and provides a semantic mapping table. Given the high complexity and complete schema coverage, this description is comprehensive enough for an agent to 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 coverage is 100%, so the baseline is 3, but the description significantly enriches parameter semantics. For the 'varga' parameter, it gives step-by-step instructions on exact token usage (including hyphen), clarifies that names like 'Rasi' or 'Navamsa' are not accepted, offers a domain-to-token mapping table, and documents default/error behavior. This adds far more meaning than the raw enum.

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

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

The description opens with a specific verb and resource: 'Return ONE divisional (varga) chart for the birth.' It clearly distinguishes this tool from siblings like list_divisional_charts by emphasizing single-chart retrieval and by providing an explicit pointer to browse the full menu. The response shape is also described, making the tool's core function 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 provides an explicit decision guide mapping each varga token to its astrological domain (D-1 body, D-2 wealth, etc.), so an agent knows exactly when to use which token. It also states that the tool returns data only with no interpretation, and suggests calling list_divisional_charts first to browse the menu — clear when-to-use and 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 the tool read-only, idempotent, and non-destructive. The description adds value by disclosing that the result maps dosha names to verdicts with reasoning, that verdict text may contain light HTML markup, and that it is 'Data only — no interpretation is added beyond what the engine reports.' These details go beyond the annotations and inform the agent about output style and neutrality.

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 appropriately sized—a few sentences that front-load the main purpose, then detail the output mapping, list covered doshas, and add a necessary HTML caveat. There is no fluff or redundant 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?

Without an output schema, the description does a good job of explaining the return structure (mapping of dosha names to verdicts) and the nature of the content (reasoning, HTML markup, data-only). The parameters are standard and fully described in the schema. It is complete enough for a read-only data tool, though it could theoretically mention exact response keys or error behavior.

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 detailed descriptions, so the schema does the heavy lifting. The description does not add any parameter-specific meaning beyond what the schema already states, which aligns with the baseline score of 3 for high schema coverage.

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

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

The description opens with a specific verb+resource: 'Return the standard dosha (planetary affliction) checks for the chart.' It then enumerates the exact doshas covered, which clearly differentiates it from sibling tools like get_yogas or get_arudha_padas. This is unambiguous and specific.

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

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

The description provides clear context for when to use the tool by stating it returns dosha checks and listing the doshas covered. It does not explicitly mention alternatives or when not to use it, but the scope is so clearly defined that an agent can easily decide this is the right tool for dosha-related inquiries.

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, but the description adds valuable context: 'Data only — no verdict' clarifies it does not interpret results, and it explains the Mean node default with the option to switch to True nodes. These go beyond the structured annotation data.

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 opens with a clear purpose sentence, then systematically enumerates all major output groups. Every sentence adds distinct information, and the length is justified by the tool's complexity. No fluff, tautology, 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?

Given the lack of an output schema, the description is remarkably complete. It lists all return components (panchanga, muhurta windows, planetary details, Tara/Chandra/Sade Sati, transit charts) and key defaults (Mean node, include sections), plus the 'no verdict' caveat. This is sufficient 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%, and the description mostly restates what the schema already provides (e.g., node_type default and include options). It adds little new semantic meaning for parameters, so 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?

Clearly states it provides a planetary transit (Gochara) snapshot for a given date vs the natal chart. This is a specific verb+resource+scope, and the detailed description of return sections distinguishes it from siblings like get_gochara_range and get_saturn_transit.

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 establishes clear context for a single-date transit snapshot and notes optional parameter behavior (node_type, include sections). However, it does not explicitly compare to alternatives such as get_gochara_range or get_muhurta, so there is no 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?

Beyond the annotations, the description reveals that the tool returns 'NO scoring or best date selection', that 'Natal reference computed once', and that the range is 'capped at 60 days'. It also enumerates the detailed per-day snapshot sections, giving the agent a clear picture of output behavior and constraints.

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 three sentences, each carrying distinct value: purpose, behavior/use-case, and alternative/constraint. It is front-loaded with the main purpose and contains no filler.

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

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

It lists the actual returned sections (panchanga, muhurta windows, planets, Ashtakavarga, Gochara-phala/Vedha, Tara/Chandra bala, Sade Sati), states the no-scoring behavior, the 60-day cap, and the alternative tool. Combined with the read-only/idempotent annotations and 100% schema coverage, this gives the agent sufficient information for selection and invocation.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds only general range semantics ('EVERY day in a date range', 'capped at 60 days') and does not explain the include, time_of_day, or event_* parameters, leaving those to the schema.

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

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

The opening sentence clearly states 'Raw transit (Gochara) details for EVERY day in a date range, in one call' – a specific verb, resource, and scope. It distinguishes itself from the sibling get_muhurta by explicitly contrasting raw no-scoring output vs. system-ranked dates. The 'range' in the name also differentiates it from single-day get_gochara.

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

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

The description explicitly frames usage as 'For the AI decides flow' and says 'you reason and decide', giving a clear when-to-use context. It also provides a direct alternative: 'Use get_muhurta instead if you want the system to rank dates by rules.' The 60-day cap is a concrete usage boundary.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context with 'Data only — no interpretation is added,' clarifying the tool does not provide analysis. The explicit key mapping also sets expectations for output. No contradiction with annotations.

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

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

The description is front-loaded with the primary purpose, then provides the exact output keys and values, and ends with a brief behavioral note. The list of ten keys adds length but is directly useful for an agent. No redundant phrases.

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 lacks an output schema, so the description fully specifies the return structure (keys and values). It also clarifies the scope (Ascendant + nine grahas) and the data-only nature. This is complete for a read-only calculation tool with well-documented parameters.

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

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

Schema coverage is 100% with descriptive parameter definitions, so the description does not need to add parameter-level detail. The description does not mention parameters, but it is not necessary given the schema's thorough 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 clearly states the tool returns graha arudhas (reflected/perceived signs) for the Ascendant and all nine grahas, listing the exact key names and value meaning. It distinguishes itself from sibling tools like get_chandra_arudhas or get_surya_arudhas by covering the full set.

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 its usage by specifying the complete set of arudhas returned, but it does not explicitly state when to prefer this tool over alternatives (e.g., get_surya_arudhas for Sun only). No when-not-to-use guidance is provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds the output format and the 'data only' nature, but does not disclose potential behavioral nuances like missing houses, computation basis, or error conditions. It provides moderate value beyond 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 two sentences, front-loaded with the main purpose and then the output structure. Every sentence 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?

The description explicitly covers the return structure (keys, values, 'no interpretation'), which is useful given no output schema. It does not explain the conceptual meaning of varnada lagnas or edge-case behavior, but given the strong schema coverage and annotations, the description is largely complete for a data-retrieval 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% for all six parameters, so the schema already documents each parameter. The description does not add any parameter-specific meaning beyond what the schema provides, 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 clearly states the tool returns varnada lagnas for houses, with a specific key range (V2–V12) and value structure (sign and longitude). It is a specific verb+resource, though it does not explicitly differentiate from sibling tools like get_special_lagnas 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 provided on when to use this tool versus the many sibling tools. The phrase 'Data only — no interpretation is added' hints at a use case but does not name alternatives or exclusions, leaving the selection context unclear.

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

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

The description goes beyond the read-only annotation by revealing that the tool returns raw classical signals side-by-side, does not reconcile them into a verdict, and includes method notes and cited references. This gives the agent a clear picture of the tool's non-committal interpretive 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 long but densely structured, front-loaded with a one-sentence purpose, then systematically enumerating each return field. Every sentence describes a distinct and relevant behavioral aspect, so it 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?

Without an output schema, the description carries the full burden of explaining the complex return structure, and it does so thoroughly, covering all fields, method caveats, and the interpretive stance. This makes it complete for an agent to understand what the tool returns.

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

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

The input schema already provides full coverage (100%) with descriptive, example-bearing parameter explanations. The description adds no parameter-specific semantics, so 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 first sentence states a specific verb ('Return') plus a resource ('classical Ayurdaya computations') and the intended use ('for astrologer interpretation'). It clearly distinguishes from sibling tools by focusing on classical longevity signals rather than a verdict.

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

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

The description clearly states it is for astrologer interpretation and explicitly says it does NOT issue a longevity verdict, which is a helpful exclusion. However, it does not name alternative tools or explicitly say when to use 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 read-only/idempotent/non-destructive behavior. The description adds substantial depth: it explains the scoring components (vara, nakshatra, tithi, paksha), the deterministic score with breakdown/weights, the Abhijit/clean best-window, avoid-windows, and the cap on score when a mandatory rule fails. It also clarifies that the caller is responsible for writing the recommendation.

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

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

The description is efficient: four sentences, each earning its place. It is front-loaded with the primary purpose, then details scoring/output, event types, and ends with the alternative tool. No filler or redundancy.

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

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

With 16 parameters and no output schema, the description still conveys the core output shape (sorted candidates, breakdown/weights, best-window, avoid-windows) and key edge-case behavior (failed mandatory rule caps score). It also sets caller expectations with 'Data only' and provides enough context for a complex astrological 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 baseline is 3. The description adds modest context for event_type by referencing the 'rule table' and classical scoring factors, but most parameter meanings are already well explained in the schema. It does not significantly go beyond structured field descriptions.

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

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

The description clearly states the tool's main action: 'Find auspicious dates for an event across a date range'. It distinguishes itself from siblings by detailing ranking logic, score breakdown, and explicitly naming get_gochara_range as the alternative for raw per-day details.

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

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

The description provides explicit guidance on when to use get_gochara_range instead ('to get raw per-day details and decide yourself'), establishing an alternative use case. It also enumerates all valid event_type values and clarifies that the tool only supplies data, leaving the recommendation to the caller.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond these: it enumerates the exact planets including outer planets (Uranus, Neptune, Pluto), specifies the degree range (0-13.333), and emphasizes the absence of interpretation. This helps the agent understand the tool's scope and output format, which is valuable given the annotations only cover safety traits.

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 moderately concise, containing two sentences that pack substantial information: the first lists bodies and output fields with examples, the second clarifies the data-only nature. While the first sentence is long, it uses enumeration efficiently and every part adds value. There is no fluff or repetition, making it well-structured for the complexity it covers.

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 format. It does so thoroughly by listing each field ('nakshatra', 'nakshatra_number', 'pada', 'nakshatra_lord', 'degrees_in_nakshatra') with ranges and examples. It also enumerates all chart bodies included and states the absence of interpretation. Combined with the detailed input schema and annotations, the description is complete for an agent to successfully invoke and understand 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?

The input schema already provides 100% description coverage for all 6 parameters, each with format examples (e.g., 'YYYY-MM-DD', 'HH:MM:SS', decimal degrees). The tool description does not add further parameter semantics; it focuses on output. Since schema covers the parameters, a baseline score of 3 is appropriate, and no additional compensation is needed.

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

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

The description clearly states the tool's purpose: 'Return the birth (sidereal) nakshatra, nakshatra number, pada (quarter), nakshatra lord and degrees-within-nakshatra for every body in the chart.' It lists all bodies (lagna, Sun, Moon, etc.) and the exact output fields. This specific verb+resource combination distinguishes it from siblings like get_arudha_padas or get_amsa_rulers, which focus on different astrological components.

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

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

The description provides clear context by specifying the returned data covers all chart bodies and clarifying 'Data only — no interpretation is included.' This implies the tool is for raw computational data rather than interpretive readings, which helps an agent choose it over more interpretive siblings. However, it does not explicitly name alternatives or state exclusion conditions, so it stops short of full explicit 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 and destructiveHint=false, and the description adds useful behavior details: it mentions the output structure (maps) and explicitly states no interpretation is added. This is consistent with annotations and provides context beyond 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?

Two sentences, front-loaded with purpose, followed by a compact list of returned fields and a concluding note about no interpretation. Every sentence earns its place without 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?

No output schema exists, but the description compensates by explaining the return structure (maps of planet name to value) and defining each result key. The input schema fully documents parameters. A minor ambiguity around 'seven planets (Sun..Saturn)' is acceptable given astrological conventions.

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%, with all six parameters already described in the input schema. The description does not discuss parameters further, so it adds no meaning beyond what the schema provides, meeting the baseline but not exceeding it.

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 names the resource ('additional planetary strength measures for the seven planets'), then enumerates five concrete data fields. This clearly distinguishes it from sibling bala tools by its unique content (harsha_bala, pancha_vargeeya_bala, etc.).

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

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

The description implies usage context ('additional', 'Data only — no interpretation is added') but does not explicitly state when to use this tool versus alternatives like get_shad_bala or get_vimsopaka_bala. No exclusions or named alternatives are provided.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds valuable behavior: the grouping logic, the meaning of each list, and the neutral-sign fallback. It does not discuss edge cases like calculation errors, but for a read-only data tool, the transparency is strong.

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

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

The description is a single well-structured paragraph: first sentence states purpose, middle enumerates fields with parenthetical definitions, final sentences clarify absence and scope. Every sentence earns its place and 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?

No output schema exists, but the description thoroughly explains the output format, listing all seven fields, their exact meanings, and the neutral-sign default. It also clarifies the tool's scope (data only). This is complete for a tool of this complexity.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description does not add parameter-specific semantics beyond the schema, but it does clarify that 'place' is cosmetic (though schema also says this). It meets the baseline but does not exceed it.

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

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

The description starts with a specific verb and resource: 'Return the dignity and motion state of the planets, grouped by condition.' It then enumerates each output field with exact definitions, making the tool's purpose unmistakable. It distinguishes itself from siblings by focusing on planetary dignity/motion grouping, unlike tools like get_planet_ingress.

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

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

The description clearly states 'Data only — no interpretation is included,' which tells the user when to use this tool (for raw states) versus when to use interpretive tools. It implies alternatives but does not name them explicitly, so it falls short of a 5. Overall, the usage context is clear.

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

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

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, and the description adds useful context beyond those: it specifies that the result is a mapping of saham names to formatted positions, includes the full set, and provides no interpretation. This clarifies behavior in terms of output and scope, which is valuable.

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, front-loaded with the core purpose, and includes a concrete example of the output format. Every sentence adds value: the first defines the action and resource, the second clarifies scope and non-interpretation. No wasted words.

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 clearly explaining the return format (map of saham names to positions with degrees, minutes, seconds) and the full set of sahams. For a read-only calculation tool with well-defined inputs, this is sufficient. It doesn't mention edge cases or prerequisites, but those are not critical for this straightforward 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 all parameters are already described in the input schema. The tool description does not add anything about the parameters themselves, just the output format. This meets the baseline for high schema coverage but does not go beyond it.

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

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

The description clearly states the tool returns sahams (Arabic parts) positions, with a specific verb 'Return' and resource 'sahams of the chart'. It distinguishes itself from sibling tools by naming its unique output and giving an example of the formatted position. There is no ambiguity about what this 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?

The description implies usage for retrieving saham data but does not explicitly say when to use this tool versus alternatives like get_sphutas or get_upagrahas. The phrase 'Data only — no interpretation is added' gives a hint that this is for raw data retrieval, but no direct exclusions or alternatives 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 declare readOnly=true, idempotent=true, destructive=false, and the description adds rich output-structure detail: degree- vs sign-based Sade Sati, phases with start/end dates, Moon/Ascendant transit periods, and reference degrees/signs. It also sets the expectation that no interpretation is added, which is useful 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?

Although longer than average, every sentence earns its place: it front-loads the purpose, then uses a compact field-by-field breakdown with quoted keys, and ends with an important scope caveat ('Data only'). No filler or repeated schema info.

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

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

With no output schema, the description carries the burden of explaining the return value, and it does so thoroughly: both Sade Sati representations, phases, related transit periods, reference fields, and per-period start/end dates and descriptions. The only minor omission is edge-case behavior for empty/unavailable periods, but the structure is clear enough for an agent to invoke and interpret the result.

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

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

The input schema has 100% description coverage for all six parameters, so the description doesn't need to repeat them. It adds no parameter-level detail or usage notes beyond the schema, so 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 opens with a specific verb ('Return') and a precise resource ('Saturn's Sade Sati and related transit windows'), clearly distinguishing this from sibling general-transit tools like get_gochara or get_planet_ingress. It also states the output includes dates, making the tool's function immediately understandable.

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 clearly frames the tool's use case: retrieving Saturn's Sade Sati and Saturn transit windows over the Moon and Ascendant, and explicitly notes this is data-only with no interpretation. It does not explicitly call out alternatives or when-not-to-use, hence not a 5, but the context is strong enough to guide selection among the transit-related siblings.

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 this as read-only and idempotent, and the description adds meaningful behavioral context: 'Data only — no interpretation is added', plus the semantics of 'strength_ratio' (ratio above 1 means threshold met). It also reveals the output structure (component maps planet name to value) without contradictions.

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 sentence contributes: it names the planets, lists six components with their English translations, explains the three totals, and clarifies the output mapping. It is front-loaded with the main purpose and avoids redundancy.

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

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

With no output schema, the description fully explains the return values: components, totals, ratio meaning, and the planet-to-value mapping. This is complete for a data-returning tool with read-only annotations.

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

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

Schema description coverage is 100%, so the input schema fully documents all 6 parameters. The description adds no information about parameters, which is acceptable since the schema already covers them; baseline 3 applies.

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

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

The description clearly states the tool returns Shadbala (six-fold strength) for the seven planets, specifying the exact six component names and totals. It is a specific verb+resource statement that distinguishes this from other 'bala' sibling tools like get_bhava_bala or 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 description makes clear that this tool provides raw Shadbala data only, without interpretation, which implies when to use it (when you need numerical strengths) and when not (if you need interpretation). However, it does not explicitly name alternatives or exclusion criteria.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, read-only operation. The description adds valuable context: the output is raw computed data, includes a fixed set of lagnas, and explicitly excludes interpretation. The mention of 'derived' lagnas clarifies the computational nature, and 'Data only' sets behavioral expectations about the response.

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 three sentences, front-loaded with the core purpose ('Return the special (derived) lagnas'), followed by the explicit data mapping and a clear guidance on scope ('Data only — no interpretation is added'). Every sentence earns its place; 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?

The tool has good annotation coverage, 100% schema coverage, and no output schema, so the description doesn't need to document return structure. It fully enumerates the lagnas included, which is the key distinguishing information. Minor gap: it could mention absence of interpretation more broadly (e.g., whether signs/longitudes are in sidereal vs tropical coordinates), but given the annotations and schema, the description is sufficiently 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 documentation covers 100% of the 6 parameters, so the schema already provides full parameter meaning. The description adds no parameter-specific details beyond the schema, but the schema itself is rich with examples and formats. Baseline 3 is appropriate since the description need not repeat what the schema already covers.

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 (special/derived lagnas) and the action (returning them with sign and longitude), naming each included lagna explicitly. It could further distinguish from sibling tools like get_sahams or get_sphutas, but the explicit list of computed lagnas establishes a clear 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 phrase 'Data only — no interpretation is added' implies that this tool is for raw data vs. interpretive analysis, giving some usage context. However, it does not state when to prefer this over siblings like get_sphutas or get_sahams, nor does it mention alternative tools for interpreted insights. Usage is implied rather than explicitly guided.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: it explicitly states the output format, lists the full set of sphuta names, and clarifies that no interpretation is added. This enhances transparency 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 well-structured and front-loaded with the primary action. The long list of sphuta names is necessary for completeness and not redundant. Each sentence contributes value, though the enumeration is somewhat lengthy.

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 explaining the return format (map of name to position with sign and DMS) and comprehensively listing all included sphutas. It also clarifies the data-only nature. Minor gaps include lack of a precise JSON structure example or edge-case behavior, but the description is quite complete for a read-only data 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?

The input schema provides 100% description coverage for all six parameters, so the description need not repeat them. The description does not add any parameter-specific information beyond the schema, aligning with the baseline of 3 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 clearly states the tool returns sphutas, defines them, and gives an example output format. It names the specific resource (sphutas of the chart) and lists all included items, distinguishing it from sibling tools like get_sahams or get_arudha_padas.

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 computed sphuta positions are needed, and the 'Data only — no interpretation' note hints at a use case, but it lacks explicit when-to-use or alternatives. No exclusions or comparisons to sibling tools are provided, so guidance is merely implied.

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 the tool as read-only, idempotent, and non-destructive. The description adds valuable context beyond these: it discloses the exact return key structure and clarifies that no interpretation is added, which is a meaningful behavioral trait not captured by 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 concise, front-loaded, and every sentence earns its place. It states the purpose, specifies the return format precisely, and clarifies the no-interpretation rule, all in three short sentences with no wasted words.

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 fully compensates by explaining the return keys ('surya_arudha_house_1' through 'surya_arudha_house_12') and the value type (zodiac sign). Annotations cover safety, and the schema covers inputs, leaving no significant gaps for an agent to 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%, meaning all parameters (date, time, place, latitude, longitude, timezone) are already described in the schema. The tool description does not add any parameter-specific semantics beyond what the schema provides, 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 clearly states the tool's function: 'Return the surya arudhas: the arudha sign for each of the 12 houses counted from the Sun (Surya Lagna).' This is a specific verb+resource that distinguishes it from siblings like get_chandra_arudhas or get_graha_arudhas by explicitly focusing on the Sun.

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

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

The description implies usage through the name and content, but it does not explicitly state when to choose this tool over alternatives. The note 'Data only — no interpretation is added' hints that interpretation-heavy tools exist, but no specific alternatives or exclusions are mentioned, so guidance remains implicit.

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

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

Annotations already declare readOnlyHint and idempotentHint; the description goes further by detailing the output structure (each upagraha maps to its sign and longitude) and explicitly stating that no interpretation is provided. This adds meaningful 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 three sentences, front-loaded with the primary action, and every sentence earns its place: it states what is returned, the mapping format, and a behavioral caveat. There is no redundancy or 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?

Despite lacking an output schema, the description adequately explains what the tool returns (sign and longitude per upagraha) and enumerates all included items, making it sufficiently complete for a data-retrieval operation. Minor omissions like longitude coordinate system or whether values are sidereal/tropical are small gaps given the tool's simplicity.

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%, meaning all six parameters are already fully documented in the schema. The description does not add any parameter-specific guidance, which is acceptable because the schema carries the burden of parameter semantics.

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

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

The description clearly states the tool returns upagrahas (shadowy sub-planets) of the chart, using the specific verb 'Return' and naming the resource. It distinguishes from sibling tools by enumerating the exact list of upagrahas included (dhuma, vyatipaata, etc.) and explicitly frames them as calculated, not interpretive.

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

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

The description provides clear context: this tool is for retrieving computed upagraha data. It adds the caveat 'Data only — no interpretation is added,' which sets expectations, but it does not explicitly mention alternative tools or state when not to use it. Given the sibling tool list and the tool name, usage context is clear, but direct comparisons 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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds value by explaining the output format (list of four entries, planetary mappings, amsa name/vargas/count) and the data-only behavior. No contradictions with annotations.

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

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

The description is front-loaded with the primary purpose, then efficiently details the output structure with a concrete example. Every sentence adds necessary information, with no redundancy or filler.

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

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

No output schema exists, so the description fully compensates by explaining the return format precisely, including the four weighting schemes, the planet list, and the string structure with example. Combined with good annotations, this is complete for a complex 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?

The input schema has 100% coverage with descriptions for all parameters, and the description does not mention parameters. Baseline 3 applies since the schema already carries the parameter semantics.

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 'Return the Vaiseshikamsa Bala' with a specific verb and resource, and explains it counts auspicious vargas per planet. It distinguishes from sibling bala tools by naming this specific calculation and detailing the output structure.

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

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

The description gives clear context about what the tool returns and notes 'Data only — no interpretation is added,' which sets expectations. It does not explicitly name alternatives or exclusions, but the specialized nature of Vaiseshikamsa Bala and the detailed output make it clear when to use this tool.

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

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

Beyond annotations (readOnly, idempotent, non-destructive), the description discloses the exact return format: a list of four entries, each mapping all nine named planets to a string pattern 'AmsaName\n(vargas)\nscore', with an explicit example and the score range (out of 20). It also states the data-only nature, which is not in 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 but well-organized: the first sentence states the purpose, then it details the output structure, provides a concrete example, and ends with a behavioral note. Every sentence contributes unique information with no redundant filler.

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

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

With no output schema present, the description fully compensates by specifying the list length (four entries), the exact weighting schemes, the planet set, the string format, an example, and the score ceiling (20). This is sufficient for an agent to know precisely what the tool returns and why no interpretation is included.

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

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

The input schema already provides 100% description coverage for all six parameters. The description adds no parameter-specific guidance beyond what the schema already contains, 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 opens with 'Return the Vimsopaka Bala' — a specific verb and resource — and immediately clarifies that it computes strength from varga/amsa across divisional charts. The detailed output structure (four classical weighting schemes) makes it clearly distinct from sibling bala tools like get_shad_bala, 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?

The description specifies that the tool covers all four classical Vimsopaka Bala schemes in one call, indicating this is the comprehensive option. The final 'Data only — no interpretation is added' provides an exclusion: do not use this if you need interpretive insights. However, it does not explicitly name alternative tools or contrast them, so it falls 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 indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral details: the result includes a summary and a yoga_list, all yogas are included, and no interpretation is added. This goes beyond the annotations.

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

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

The description is front-loaded with the main action, then efficiently explains the two-part result and provides examples. Every sentence contributes necessary detail without redundancy. It is appropriately sized for the tool's rich output.

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

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

With no output schema, the description fully explains the return structure: summary fields, yoga_list key-to-list mapping, and example keys. It also clarifies that all detected yogas are included and no interpretation is added, making it complete for an agent to understand the tool's output.

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%, with each of the 6 parameters described in the schema. The description itself adds no parameter-specific meaning, but the baseline of 3 applies because the schema handles 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 and resource: 'Return every yoga (planetary combination) detected in the birth chart.' It clearly differentiates this from sibling tools like get_doshas or get_sahams by focusing on yogas. The scope ('every yoga') and the result structure are explicitly stated.

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

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

The description makes the tool's usage context clear: it returns all yogas with data only, no interpretation. While it does not name alternatives or when-not-to-use scenarios, the context is sufficiently distinct. The 'Data only' note further sets expectations.

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.