Vedic Astrology and Kundli MCP Server by RoxyAPI

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

Annotations already declare the tool read-only and non-destructive. The description adds useful behavioral context by specifying the return content (short label plus what each state means for the graha's results) and the three system groups, which helps the agent format the expected output even without an output schema.

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

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

The key purpose and usage guidance are front-loaded and clear. However, the final sentence, 'Avastha meaning API, Baladi avastha, Jagradadi, Deeptadi, planetary state Vedic astrology,' reads like keyword stuffing and adds no value for an agent selecting or invoking the tool.

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

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

Given that this is an optional-parameter, read-only reference list with full schema coverage and no output schema, the description adequately covers the three groups of states, the intended comp, and the optional system filter. It stops short of describing output structure or error behavior, but those are not critical for this simple 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 lang, system, and compact, so the schema already fully documents the parameters. The description only echoes the system filtering option and adds no new parameter-level insight beyond what the schema provides.

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

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

The title and first sentence both clearly state the action and scope: 'List all 17 avastha states' and 'Reference list of every avastha.' The description also names each classical system, so the tool's purpose is explicit and distinct from sibling reference endpoints like 'get_vedic_astrology_avasthas_id'.

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

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

The description gives explicit guidance on when to use the tool: 'Use it to turn the bare state names a birth chart returns into readable output, filtered by system if you only need one.' However, it does not explicitly state when not to use it or mention the _id sibling as an alternative for getting a single avastha.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by explaining what the tool returns ('the system it belongs to, a short label, and what the state means for the results the graha delivers'), which is useful beyond the annotations and helps the agent understand the operation's scope. It does not contradict 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 core action and identifier, and includes the return summary. Every sentence earns its place; there is no redundant wording or unnecessary detail.

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 an output schema present and annotations covering safety, the description is complete for this simple read-only lookup. It explains the slug's origin, what the tool returns, and is sufficient for an agent to decide when to call it and how to interpret the result. No missing information is needed for correct invocation.

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

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

Schema description coverage is 100% for all three parameters, so the schema already documents id, lang, and compact thoroughly. The description adds minimal extra semantics beyond clarifying that the id is a 'slug' and its source (already partially in the schema's enum description). It does not introduce new meaning for lang or compact, 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 states a specific verb ('look up'), a specific resource ('a single avastha state'), and an identifier ('by its slug'), which clearly differentiates it from the sibling plural tool get_vedic_astrology_avasthas. It also explains the slug's origin ('lowercased state name a Vedic birth chart returns in awastha, jagradadi or deeptadi'), 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?

The description implies usage when you have a specific slug (from a birth chart field), and the 'single' wording contrasts with the plural sibling. However, it does not explicitly name the alternative tool or state when not to use it. The context of the slug source provides strong guidance, but a direct reference to the plural list tool would have made it explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat that. It adds valuable context: the ayanamsa is computed continuously rather than looked up, it tracks the exact moment, it is the precession offset subtracted from tropical longitude, and it returns the same value as all KP endpoints. This goes beyond the schema and 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 moderately long but every sentence contributes: purpose, calculation method, usage patterns, and relation to KP charts. It is front-loaded with the main purpose and then provides supporting detail. It could be trimmed slightly (e.g., the phrase 'dynamic daily calculation' in the title is redundant with the description), but overall it is well-structured and informative.

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

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

An output schema exists, so return values are already documented. The description covers what the tool does, when to use it, how to provide inputs, and what the result represents. For a read-only tool with optional parameters, nothing essential is missing.

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

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

Schema coverage is 100%, so all four parameters have descriptions. The tool description adds extra nuance: it explains the effect of date ('changes by ~0.01 degrees per month') and time ('moves about 0.14 arcseconds across a day'), which helps agents understand precision requirements. This adds meaning beyond the schema alone.

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

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

The description clearly states it retrieves the KP-Newcomb ayanamsa for any instant, computed dynamically from precession theory. It distinguishes itself from any sibling by naming the specific ayanamsa variant and its calculation method, and no other tool in the sibling list targets ayanamsa, so differentiation is inherent.

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 says when to use it: 'Use it as a dynamic KP Newcomb ayanamsa calculator when you need the Krishnamurti ayanamsa for today, for a birth moment, or for any instant a chart is being rectified against.' It also explains how to supply date/time/timezone. It does not explicitly mention when not to use it, but since there are no alternative ayanamsa tools, this is not a significant gap.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful behavioral context like 'complete list' and 'from Ashwini to Revati', but it does not describe response shape, pagination, or any other runtime behavior. This is adequate given the annotations.

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

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

Three sentences with no wasted words. The opening sentence front-loads the main 'list all 27' intent, the second sentence enumerates the return fields, and the third sentence gives practical usage context.

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 is rich enough for a list operation with no output schema: it covers the 27-item scope, the exact fields returned, and practical use cases. A minor omission is lack of explicit routing to the ID-based sibling, but the singular/plural distinction and 'complete list' wording make it inferable.

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 enum, defaults, and behavior offall lang and compact parameters are fully documented in the schema. The description adds no parameter details, but that is fine because the schema already carries the burden.

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

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

The description states a specific verb and resource: 'Get the complete list of 27 nakshatras (lunar mansions) in Vedic astrology.' It clearly distinguishes this list/sibling from get_vedic_astrology_nakshatras_id by emphasizing completeness ('all 27', 'from Ashwini to Revati').

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 concrete use cases: 'nakshatra lookup tables, dasha period calculations, muhurta selection, and astrology app reference data.' It does not explicitly mention when not to use it or point to the ID variant, but the use 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 and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the specific content of the response (name, zodiac range, ruling planet, remedies, etc.), which goes beyond the schema's parameter definitions. It does not mention potential edge cases like invalid IDs or error handling, but for a read-only lookup this is acceptable.

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 sentence that front-loads the purpose and then lists the key returned fields. There is no redundancy or filler; every clause contributes useful information. It is appropriately sized for 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?

The tool has an output schema, so the return structure is already defined elsewhere. The description covers the purpose, the parameter (ID), and the nature of the response. With the schema and annotations in place, nothing an agent needs to invoke the tool correctly is missing—including language options and compact mode, which are documented in the schema.

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

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

Schema description coverage is 100%, so all three parameters are already well-documented with types, enums, defaults, and examples. The tool description does not add meaning beyond what the schema provides—it merely repeats 'ID slug' without additional syntax or format details. This aligns with the baseline score of 3 when the schema carries the explanatory burden.

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

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

Description clearly states the verb 'Get' and the resource 'single nakshatra (lunar mansion) by its ID slug', and lists the specific data returned (name, zodiac range, ruling planet, etc.). It is distinct from the sibling list tool (get_vedic_astrology_nakshatras) and other ID-based lookups by naming the exact domain and entity.

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 a single nakshatra by ID, and the context of siblings (plural vs. singular) makes the intended use clear. However, it does not explicitly mention when not to use it or point to the alternative list tool, so it falls short of the explicit 'when/when-not' guidance seen in top-tier definitions.

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 that the tool is read-only and non-destructive, so the description need not relitigate safety. It adds behavioral value by disclosing the full response field spectrum (Sanskrit names, Western equivalents, dates, symbols, Adityas, personality traits) and framing the output as complete and deterministic. This is meaningful context beyond the static read-only flag, especially given there is no output schema.

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

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

The description is appropriately concise and front-loaded: the first sentence states exactly what the tool returns, and the second sentence immediately spells out use-case implications. There is slight overlap with the title (both mention listing all 12 Rashis), but the description earns its place by adding downstream usage guidance. It is shorter and more navigable than average.

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

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

For a simple read-only reference list with zero required parameters and a fully described schema, the description is largely complete. It tells the agent what data will be present and what the data is useful for, even without an output schema. The one notable gap is that it does not explicitly highlight the sibling get_vedic_astrology_rashis_id for the single-rashi case, but the naming convention and reference framing make the distinction transparent enough.

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

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

The input schema fully documents the two parameters, with default values, examples, and complete descriptions; schema coverage is 100%, so the description does not need to re-explain them. The description does not add any extra color about lang behavior or compact encoding—everything parameter-wise lives in the schema already, so the description carries no added value here.

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 action ('Get the complete list of 12 rashis') and enumerates the resource ('list of 12 rashis'), with specific returned content (Sanskrit names, Western equivalents, sidereal date ranges, symbols, governing Adityas, personality characteristics). It immediately stands apart from the sibling get_vedic_astrology_rashis_id because it explicitly is the all-rashis reference, not a single-entry lookup.

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 contextualizes when the tool is valuable: 'essential for zodiac sign lookup tables, astrology apps, and rashi-based UI components.' This emphasizes that it is a static reference list rather than a calculation, rather than anything about per-rashi lookup. It stops short of explicitly naming the sibling-by-ID tool as the alternative for single-rashi requests, so it is omitted a clear exclusion, but the context is otherwise 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 and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by listing the exact fields returned and emphasizing the rashi-specific nature. It does not disclose any side effects, rate limits, or potential error conditions, but for a simple read-by-ID operation with no exclusions, the annotation coverage plus the descriptive content justify a score above baseline.

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

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

A single, dense sentence that front-loads the primary action, then enumerates the return fields without repetition or fluff. Every element serves a purpose; no wasted words. The length is appropriate given the need to list the seven distinct data categories returned.

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

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

Given that an output schema exists (so return structure is documented elsewhere), the description sufficiently covers the purpose, the identifier mechanism, and the content scope. It is complete for an agent to correctly call this tool—it clearly states what is returned and by what key, with no missing prerequisites or ambiguous behavior. The presence of the sibling list tool and the ID slug enum in the schema complete the picture.

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

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

The input schema provides 100% coverage with detailed descriptions for all three parameters (id with enum, lang with default and coverage note, compact with shape explanation). The description itself does not add extra semantic value beyond restating 'by its Vedic ID slug', which is already captured in the schema. With full schema coverage, the baseline of 3 applies.

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

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

The description states a specific verb ('Get'), a precise resource ('detailed information for a single rashi (zodiac sign)'), and the identifier ('by its Vedic ID slug'). It then enumerates the returned content (Sanskrit name, Western equivalent, sidereal date range, symbol, governing Aditya, personality characteristics), making it unmistakably distinct from the sibling list tool get_vedic_astrology_rashis.

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 the tool is used when you have a specific rashi ID slug and need details for that one sign, rather than getting all rashis. However, it does not explicitly state when to use this versus the list variant, nor does it mention any exclusions or alternate selection criteria. The sibling tool get_vedic_astrology_rashis is likely the counterpart, but no comparison is made.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it is a pure catalog listing, not chart-driven, and returns id/name for the whole catalog. 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 front-loaded with the resource and return shape, then immediately clarifies the critical scoping fact (dictionary, not chart-driven). It names sibling routes and use cases without wasted filler, and every sentence adds selection-relevant information.

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

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

For a read-only glossary listing with an output schema and 100% schema-covered parameters, the description covers purpose, scope, return content, exclusions, and routing alternatives. Nothing an agent needs to decide whether to call this tool is missing.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (lang, family, compact) with defaults, enums, and descriptions. The tool description does not repeat or augment parameter details, which is acceptable given the schema's completeness; the baseline of 3 applies.

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

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

The description states a specific verb ('Browse') and resource ('301-entry Vedic planetary-yoga glossary') and explicitly says it returns id and name for every cataloged yoga. It also distinguishes itself from the sibling GET /yoga/{id} and POST /yoga/detect by clarifying it is a dictionary lookup, not chart-driven detection.

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 says when to use this tool ('Ideal for yoga-browser UIs, search, and progressive data loading') and what it is not for ('does not inspect a birth chart'). It names the alternatives: GET /yoga/{id} for a full entry and POST /yoga/detect for rule-based detection against a kundli, which is clear routing 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. The description adds meaningful behavioral context beyond that: the operation is a static catalog lookup, it does not analyze a birth chart, and it returns classification and results rather than performing calculations. This gives the agent clarity about scope with no hidden side effects.

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

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

Three sentences, each earning its place: the first states the purpose and return data, the second clarifies the non-chart scope, and the third routes to the correct sibling for chart-driven use. The parenthetical detail on detection-grade yogas is verbose but directly serves differentiation.

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 a simple ID-based lookup with an output schema that already documents return shape, and the description covers scope, returns, and the key sibling alternative. Nothing needed for correct invocation is missing; language and compactness are fully covered in the schema.

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

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

Schema description coverage is 100%, with per-parameter descriptions for id (lowercase hyphenated identifier), lang (BCP 47, default, fallback behavior), and compact (columnar shape, token savings). The description adds no additional parameter-level meaning beyond the schema, 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 uses a specific verb and resource: 'Look up the dictionary entry for a specific named yoga from the 301-entry Vedic planetary-yoga glossary.' It also states what is returned (formation conditions, life results, quality classification) and explicitly contrasts itself with chart analysis, clearly differentiating it from the sibling post_vedic_astrology_yoga_detect.

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 says this is a glossary lookup, states it does NOT analyze a birth chart, and directs the agent to POST /yoga/detect with birth data when the caller needs detection-grade verdicts. This provides both when-to-use and when-not-to-use guidance with a named alternative.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it explains the astrological meaning of an Arudha pada, states that the classical exception (Parivrajika/exception rule) is reflected via a flag, and notes that the Upapada is included. It also clarifies the return shape (each pada with lord, count, sign, house, flag). This goes beyond the annotations without contradicting them.

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

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

The description is a single focused paragraph that front-loads the core function ('Calculate the Arudha Lagna and all twelve Arudha padas') before explaining the concept and output. The trailing keyword-like phrases ('Arudha Lagna calculator API, Jaimini pada, Upapada Lagna, Vedic astrology public image') are somewhat redundant and add little for an AI agent, but they don't bloat the description enough to drop below a 4.

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 an output schema, so the description doesn't need to enumerate return fields in detail, but it does summarize them helpfully. With 9 parameters, 100% schema coverage, and read-only annotations, the description covers the conceptual 'why' and the key output highlights. It doesn't mention pagination or rate limits, but for a single-shot calculation API with an output schema, this is adequate. A 4 is appropriate; a 5 would require explicit alternative routing or edge-case guidance.

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 9 parameters thoroughly. The description adds no parameter-specific detail beyond what the schema provides, but it doesn't need to. The baseline of 3 applies because the schema carries the heavy lifting and the description correctly focuses on the output semantics rather than repeating parameter docs.

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

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

The description states a specific verb ('Calculate'), a specific resource ('Arudha Lagna and all twelve Arudha padas'), and explains the astrological concept (perceived/projected form of a bhava). It also names the output components (bhava lord, count, sign, house, exception flag, Upapada), which distinguishes it from sibling tools like rashis or nakshatras that return different chart elements.

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

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

The description implies when to use it: when you need the Arudha Lagna, the twelve padas, or the Upapada for marriage-related readings. However, it does not explicitly state when NOT to use it or name alternative tools (e.g., use get_vedic_astrology_rashis for rashi positions, or post_vedic_astrology_birth_chart for the full chart). The context is clear but exclusions are absent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds what analysis is performed and the specific components returned, which is useful. But it does not disclose edge cases, limitations, or any behavioral caveats (e.g., dependencies on ayanamsa precision), leaving some burden uncovered. With annotations present, the additional value is modest but non-trivial.

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

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

The first two sentences are dense and informative, front-loading the core action and outputs. However, the final sentence ('Ashtakavarga calculator API, bindu rekha points, Shodhya Pinda, Vedic astrology.') is keyword stuffing that earns no place for an agent selecting or calling the tool. This noise pulls the structure score down from a clean 4.

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 existence of a detailed output schema and 100% documented parameters, the description covers the essential context: what is calculated, the authoritative source (BPHS), the exact components, and the use cases. It could add guidance on when Ashtakavarga is preferred over shadbala, but that is a minor gap. For a complex astrological tool, the description is adequately complete.

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

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

Schema description coverage is 100% (all 8 parameters are fully described inline), so the baseline is 3. The tool description does not add any parameter-specific semantic information; it only mentions domain concepts like 'bindu rekha points' that do not map to specific parameters. Thus it neither improves nor harms the schema's already thorough 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 opens with a specific, actionable verb-resource pair: 'Calculate complete Ashtakavarga analysis per Brihat Parashara Hora Shastra (BPHS).' It names concrete outputs (Bhinnashtakavarga, Sarvashtakavarga, Reduced Ashtakavarga, Shodhya Pinda) that distinguish it from every sibling tool, none of which mention Ashtakavarga. An agent can reliably tell what this tool does without opening the schema.

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

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

The description provides clear application context: 'Essential for transit prediction timing, house strength analysis, dasha result evaluation, and planetary strength comparison.' This tells an agent when to reach for this tool. However, it does not name sibling alternatives (e.g., post_vedic_astrology_shadbala) or state explicit exclusion conditions, so it stops short of full when-not guidance.

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

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

Even with readOnlyHint=true and destructiveHint=false in annotations, the description adds meaningful behavioral detail: it states the tool 'Returns full aspects...', includes a table, mutual aspects, and 'individual aspect details with orb calculation.' This goes beyond the annotation safety profile, though it does not cover edge behaviors like error conditions or rate limits.

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

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

The core description is front-loaded with the primary purpose, but the final sentence is a keyword block ('Planetary aspects API, drishti calculator, vedic astrology aspects, graha drishti') that adds no functional information and is noise for an agent. This bloat prevents a higher score.

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

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

Given the presence of an output schema, full parameter descriptions, and annotations covering read-only safety, the description covers the essential use context and key output contracts (full vs. special aspects, orb calculation). It is complete enough for an agent to invoke correctly, though it omits any mention of coordinate system or timezone handling, which are already documented in the schema.

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

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

Input schema coverage is 100%, with all seven parameters fully described, so the description is not required to repeat them. It refers to 'a given time' and the aspect calculation but adds no parameter-specific meaning beyond the schema. Baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Calculate all planetary aspects (Drishti) for a given time.' It further distinguishes its scope by enumerating full 7th-house aspects and special aspects for Mars, Jupiter, and Saturn, which clearly separates it from sibling tools like aspects_lunar and aspects_monthly that target narrower subsets.

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

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

It provides clear usage context by stating it is 'Essential for birth chart analysis, compatibility checking, and transit predictions.' However, it does not explicitly name alternatives or state when not to use this tool versus related aspect endpoints such as post_vedic_astrology_aspects_lunar.

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

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

Annotations already declare a safe read-only operation, and the description adds real behavioral context beyond them: results are refined 'to the minute' via ternary search, and the compact flag is described as lossless. It stops short of describing pagination or response volume for a month of 22 aspect types per planet.

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

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

The core purpose and the defaulting behavior are front-loaded and useful, but the exhaustive list of 17 minor aspects consumes substantial space for little decision value, and the trailing keyword line ('Monthly lunar aspects API, Moon transit calendar, chandra drishti ephemeris, minor lunar aspects') is pure SEO padding that earns no 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?

An output schema exists so return values need no explanation, and the description covers the key defaults plus intended use cases. The one gap is that it never clarifies how it differs from the closely-named aspects_monthly sibling, which an agent choosing between them would need.

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 parameters (lang fallback behavior, year/month defaults, timezone resolution, coordinateSystem) are all fully documented in the schema. The description only restates the year/month omission default, adding no parameter semantics beyond what the schema provides. Baseline 3 is correct.

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 gives a specific verb and resource — track all lunar aspect events for a month — and enumerates the aspect taxonomy, so the agent knows exactly what is produced. It does not, however, differentiate itself from the very similar sibling post_vedic_astrology_aspects_monthly, which is a meaningful ambiguity given the near-identical scoping.

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

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

Usage is implied through the stated default behavior ('Omit year and month to get the month in progress') and the named downstream applications (muhurta, panchang, chandra gochar). There is no explicit when-to-use versus the aspects_monthly or daily siblings, so the agent must infer the 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=true and destructiveHint=false, so safety is covered; the description adds genuinely new behavior: ternary-search refinement for closest approach, degree-based methodology on Lahiri sidereal positions, and the default-to-current-month behavior. It stops short of noting rate limits or response size characteristics, but the additions are substantive.

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

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

The core is front-loaded and readable, but the enumeration of all 17 minor aspect names adds bulk with little decision value, and the closing keyword tail ('Monthly planetary aspects API, graha drishti calendar, mutual aspect ephemeris, minor aspects') is SEO padding that earns no place in an agent-facing definition.

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

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

With an output schema present, return-shape explanation is not required, and annotations plus the full-coverage input schema cover the structured fields. The description supplies scope, methodology, and defaulting behavior, leaving only sibling selection against the non-monthly aspects tool under-specified.

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

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

Schema coverage is 100%, so baseline is 3. The description earns above baseline by explaining the defaulting rule for year/month ('Omit year and month to get the month in progress') and by tying output to sidereal Lahiri positions, which clarifies the coordinateSystem default beyond the schema text.

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

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

States a specific verb and resource ('Calculate all planetary aspect events ... for a given month') and explicitly carves out scope with '(excluding Moon)'. It names the aspect count (22) and the lunar sibling endpoint, so an agent can distinguish it from post_vedic_astrology_aspects_lunar and the non-monthly aspects tool without opening a schema.

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

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

Gives an explicit alternative ('For Moon-specific aspects, use the /aspects/lunar endpoint') and a clear operational context ('Essential for transit timing, muhurta selection, and monthly astrological forecasting'). It does not, however, say when to prefer this monthly variant over the sibling post_vedic_astrology_aspects, leaving that boundary to inference.

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

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

Annotations already mark the tool read-only/non-destructive, and the description adds substantive behavioral detail: it enumerates the three computed components, the virupa/rupa totals and strength ranking, and the use of unequal Sripati mid-cusps rather than sign boundaries. There is no contradiction with the annotations.

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

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

Front-loaded: the first sentence states the operation and scope, followed by components and method. However, the final keyword sentence ('Bhava Bala calculator API, house strength Vedic astrology...') is filler that adds no agent-facing value and could be deleted.

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

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

For a complex 10-parameter calculation, the description covers output (components, units, ranking), computational basis (Sripati mid-cusps), and the relationship to the Shadbala sibling; the output schema covers return structure. Nothing essential for selecting or invoking the tool appears missing.

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

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

Schema description coverage is 100%, so the input parameters are already fully documented and the description need not repeat them. The description adds conceptual context about what the computation depends on but no new parameter syntax or defaults. Baseline 3 is appropriate.

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

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

Description names a specific verb ('Calculate') and resource ('Bhava Bala (house strength) for all twelve bhavas'), and ties it to classical sources (BPHS, BV Raman). It also distinguishes from the likely sibling by explaining that Shadbala measures planet strength while Bhava Bala measures life-area strength. This is clearly not a tautology and would let an agent pick it among the Vedic siblings.

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

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

It implies strong usage context: if the question is about strong life areas, choose Bhava Bala; if it's about which graha is strong, use Shadbala; and it advises using both to separate a strong planet in a weak house from a weak planet in a strong one. It doesn't explicitly say 'use this instead of X' or list exclusion cases, so it stops one step short of fully explicit routing.

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

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

Beyond the readOnlyHint=true annotation, the description details the output: 'Returns the twelve bhava boundaries with their madhyas and spans, every graha in both frames, and a moved flag on the placements that differ.' This gives the agent a concrete picture of the response shape and behavior, adding significant value over the annotation.

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 main body is well-structured and front-loaded with the purpose, but the trailing keywords ('Bhav Chalit API, Chalit Kundli calculator, bhava chalit chart, Sripati house cusps, cusp based house chart Vedic astrology') are redundant and add noise. The description could be shorter by removing the keyword list without losing meaning.

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

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

With an output schema present, return-value details are adequately covered. The description explains the tool's purpose, why it differs from Rashi, and what it returns, which is sufficient for an agent to decide to call it. Minor gap: it does not explicitly route to or away from sibling tools like kp_cusps or birth_chart, relying on the conceptual contrast.

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?

All 10 parameters are fully described in the input schema (100% coverage), so the baseline is 3. The description adds conceptual context about 'Sripati bhava cusps' but does not provide additional parameter-specific syntax or format details beyond the schema, so it does not exceed the baseline.

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 calculates the Bhav Chalit chart using unequal Sripati bhava cusps instead of whole sign, and contrasts it with the Rashi (D1) chart. The verb 'Calculate' and the specific resource make the purpose unambiguous, and it distinguishes itself from the whole-sign approach that sibling tools likely use.

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

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

The description explains when to use the tool: 'practitioners check it before reading house results, house lordship strength or transit effects.' It also clarifies the difference from the Rashi chart, implying when the Chalit chart is preferred. However, it does not explicitly name alternative sibling tools or state when not to use it, so it lacks a hard exclusion.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine behavioral detail: it discloses the return shape (positions grouped by zodiac sign with nakshatra/pada) and the specific node convention (Rahu/Ketu as mean lunar node referred to the true equinox, Ketu opposite Rahu).

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?

Core purpose and scope are front-loaded in the first sentence, which is appropriately dense. The middle two sentences are mildly promotional (audience/use-case framing) and partially redundant, but overall it remains compact and free of bloat.

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

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

An output schema exists, so return-value explanation is unnecessary. The description supplies scope, return grouping, and node convention; with full schema coverage and read-only annotations, an agent has nearly everything needed. Only the absence of sibling-routing guidance leaves a small gap.

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

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

Schema description coverage is 100%, so the schema already documents all 12 parameters thoroughly (timezone, ayanamsa, focus, compact, etc.). The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Calculate) and resource (complete Vedic birth chart / Janam Kundli / D1 Rashi) with explicit scope: all 9 grahas plus Ascendant, grouped by rashi with nakshatra and pada. This precisely distinguishes it from sibling tools like divisional_chart, navamsa, and kp_chart without the agent opening a schema.

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

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

Intended applications are named ('kundli generation, horoscope matching, Vedic astrology software integration'), giving implied context. However, no explicit when-to-use vs alternatives guidance is offered, and no sibling (e.g., planetary_positions, divisional_chart) is referenced or routed to.

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

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

The description adds substantial behavioral detail beyond the already-present readOnlyHint and destructiveHint annotations: it explains that Rahu's degree is reversed in the eight-karaka scheme, that Ketu is excluded because it mirrors Rahu exactly, and that the two schemes can yield a different Atmakaraka for the same chart. This tells the agent what to expect from the calculation 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 main explanation is front-loaded with the core purpose and is appropriately detailed for a specialized astrological calculation. The trailing comma-separated keyword list ('Atmakaraka calculator API, Darakaraka, Jaimini chara karaka...') is redundant filler and keeps it from a perfect score.

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

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

Given the richness of the input schema, the presence of an output schema, and the read-only annotations, the description is complete enough for an agent to call the tool correctly. It covers the core algorithm, the scheme variants, and the key astrological distinction that affects results.

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?

Parameter schema coverage is 100%, so the baseline is 3 even though the top-level description does not repeat parameter details. The description does add astronomical context about scheme differences, but those semantics are already echoed in the 'scheme' parameter description.

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

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

The description uses a specific verb and resource: 'Calculate the Chara Karakas of Jaimini astrology from birth details' and precisely defines what Chara Karakas are. It clearly differentiates this endpoint from the many sibling Vedic astrology tools by naming the exact outputs (Atmakaraka, Amatya, Bhratri, etc.) and the two karaka schemes.

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

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

The description gives clear context for when this tool is appropriate: when the user needs Chara Karakas, Darakaraka, or the Atmakaraka specifically. It also provides actionable selection guidance for the 'seven' vs 'eight' scheme based on the user's reference software, though it does not explicitly name alternatives among the sibling tools.

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

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

Annotations already cover read-only and non-destructive hints, so the description doesn't need to repeat that. It adds valuable behavioral context: the specific calculation rules (Muhurta Martanda and BPHS), dosha detection, and marriage recommendation, going beyond the structured annotations.

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

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

The description is three sentences, front-loaded with the primary function, and contains no redundant or fluff language. It efficiently communicates the tool's scope and output without waste.

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

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

Given an output schema exists, the description needn't detail return values. It covers the core functionality, the 36-point scale, koota breakdown, dosha detection, and recommendation, which is sufficient for an agent to understand the tool's role. It doesn't mention prerequisites (e.g., accurate birth time), but those are already in the parameter schema.

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

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

Schema coverage is 100%, with detailed descriptions for every parameter (e.g., time being critical, location examples). The tool description itself adds no parameter-specific guidance beyond what the schema already provides, 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 tool calculates Ashtakoot compatibility (Gun Milan) between two individuals, specifies the 36-point scale and the 8 kootas, and distinguishes it from sibling tools like dashakoot and papasamyam by naming the specific system. The verb and resource are explicit.

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

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

The description gives clear usage context ('Perfect for kundli matching for marriage, matrimonial platforms...') and implicitly differentiates from other compatibility tools by naming Ashtakoot. However, it does not explicitly state when not to use it or name alternatives, leaving some inference to the agent.

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

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

Annotations already carry readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description adds substantial behavioral context on top: Rajju and Vedha act as 'explicit hard vetoes that disqualify a match whatever the rest of the sheet reads', and five of the ten poruthams are direction-sensitive counting from bride to groom. These are non-obvious behaviors an agent must know to interpret results correctly, and they go well beyond what the annotations state.

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

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

Roughly three dense sentences, each earning its place: the calculation and return shape, the sibling-system distinction with use context, and the direction warning. It is front-loaded with the verb and resource, and lists the ten poruthams compactly. Slightly long, but the complexity (ten named components, veto rules, Ayanamsa context) justifies the length; no filler or tautology.

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

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

Given an output schema (returns covered), 100% schema coverage on 6 parameters including nested objects, and annotations covering the safety profile, the description is nearly complete. It supplies the essential missing context: the system identity, the sibling distinction, the veto semantics, and the groom/bride ordering constraint. It could add failure or boundary behavior, but nothing an agent needs to invoke this correctly is absent.

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

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

Schema coverage is 100%, so the schema already documents every parameter thoroughly, including person1=GROOM and person2=BRIDE. The description adds value by explaining WHY the direction is load-bearing ('five of the ten poruthams count from the bride birth star to the groom birth star'), reinforcing the role semantics beyond what parameter names alone convey. This is a meaningful increment over the schema baseline of 3.

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

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

The description opens with a specific verb and resource: 'Calculate the South Indian ten porutham marriage match (Dashakoot...)'. It enumerates all ten poruthams, states the return shape (pass/fail each, total out of ten, vetoes), and explicitly disambiguates itself from the sibling 'POST /vedic-astrology/compatibility' 36-point Ashtakoot system. An agent can tell exactly what this tool computes and how it differs from its nearest sibling without opening either schema.

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

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

The description names the alternative ('the 36 point Ashtakoot Gun Milan on POST /vedic-astrology/compatibility'), states that the two are never reconciled, and gives a concrete audience ('a Tamil, Malayalam or Telugu matrimonial desk can read the sheet it actually uses'). It also warns that direction matters and person1/person2 are not interchangeable. The when-to-use is clear, though the when-not-to-use is conveyed by contrast rather than an explicit routing instruction.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description goes well beyond this by disclosing the directional verdict rule ('the bride total must be equal to or below the groom total'), the weighting scheme (Lagna 1, Moon 0.5, Venus 0.25), and the consequence that swapping the two inputs can flip the verdict. This is substantive behavioral context that an agent needs to interpret results correctly and that no annotation or schema field conveys.

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

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

The description is dense and long, but every sentence earns its place: purpose, computational method, return contents, verdict interpretation, and usage context. It is front-loaded with the core action in the first sentence. The middle sentence packs a lot of technical specificity (planets, bhavas, weights) that could have been trimmed, but it is all relevant to correct invocation and interpretation, so only a small deduction for density.

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

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

For a complex domain tool with nested person objects, the description, combined with a fully documented schema and an output schema, tells the agent everything needed: what it computes, how to interpret the directional verdict, what the response includes, and when to use it relative to other compatibility checks. The sibling list shows related tools, and the description's explicit differentiation from koota-based matching prevents confusion with compatibility_dashakoot. Nothing essential is missing.

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

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

The input schema has 100% description coverage, with detailed explanations for person1 (groom), person2 (bride), ayanamsa, timezone, and the rest. The tool description adds no parameter-level detail beyond what the schema already provides, which matches the baseline of 3 when the schema carries the weight. The directionality nuance is already captured in the person1/person2 property 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 opens with a specific verb and resource: 'Calculate Papasamyam, the balance of malefic (papa) points between two birth charts, for Vedic marriage matching.' It enumerates exactly which planets, bhavas, and reference points are used, which clearly differentiates it from sibling compatibility tools like dasxxakoot or general compatibility. The sentence 'The verdict is a comparison and never a judgement on one person' further pins down the tool's unique semantic.

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 says when to use it: 'Use it beside Gun Milan and the ten porutham sheet on a matrimonial platform' and gives the rationale: 'since a koota score says nothing about malefic balance.' This is clear contextual guidance. It stops short of naming the specific sibling API (e.g., post_vedic_astrology_compatibility_dashakoot) as the Gun Milan tool or listing explicit 'do not use when' conditions, so it earns a 4 rather than 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 only cover the safety profile (readOnly, non-destructive), and the description adds substantial context beyond that: the gate pipeline semantics (a graha lands in ONE cited state, not a partial bar), panchanga days running sunrise-to-sunrise with validity windows on every limb, the Lahiri sidereal frame for positions versus KP-Newcomb for finance significators, and an explicit disclosure of which parts are classical versus a RoxyAPI counting convention. It stops short of describing response size or latency, which keeps it off a 5.

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

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

The purpose is front-loaded in the first clause, which is good. But the remainder is a single dense paragraph of run-on sentences loaded with jargon and editorial phrasing ('rather than a bar of a chart', 'Ships a hand-reproducible strength score'), which costs parseability for an agent that mainly needs selection and invocation signals.

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

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

For a 10-parameter composite tool with an output schema already present, the description covers scope, computational frames and the composed sub-readings thoroughly, so nothing needed to invoke it is missing. The only shortfall is the absent comparative guidance against the granular sibling endpoints.

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 every parameter (including date, timezone, nodeType, compact and focus) is already documented in the schema. The description itself adds no parameter-level detail beyond naming the Lahiri/KP-Newcomb frames, so the baseline 3 for high-coverage schemas 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?

Opens with a specific verb+resource+scope: 'The composed Vedic daily reading for one native on one date, in one call.' The phrase 'in one call' plus the enumeration of composed parts (Gochara, panchanga, tarabala/chandrabala, Vimshottari, KP finance) distinguishes it from the many granular siblings such as post_vedic_astrology_transit, post_vedic_astrology_panchang_detailed and post_vedic_astrology_dasha_current.

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

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

Usage is implied rather than stated: 'in one call' signals this is the aggregation route instead of calling several topical tools, and the 'focus: finance' vocabulary hints at KP wealth questions. But there is no explicit when-to-use / when-not-to-use clause and no sibling is named as an alternative, so the routing decision is left to inference.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral context: it returns a timeline with start/end dates for every level, can evaluate any datetime instead of only now, and significators adds KP lords and strength grades. It does not mention auth or rate limits, but those are not central here.

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

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

The core purpose is front-loaded and clear, but the paragraph contains marketing-style filler such as 'Accurate dasha calculator API for life phase prediction and planetary period analysis' and 'Essential for understanding current planetary influences.' It is adequate but could be tightened.

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 complex with 13 parameters, but the schema is richly documented and an output schema exists. The description covers the essential behavior: five dasha levels, remaining time, datetime evaluation, significators, and ayanamsa selection.

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

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

Schema description coverage is 100%, so the schema already fully documents all 13 parameters. The description reinforces datetime, significators, and ayanamsa behavior, but adds little meaning beyond the already detailed schema 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 first sentence names a specific action and resource: 'Calculate all five running Vimshottari Dasha levels with remaining time in each.' It explicitly lists all five levels, including Mahadasha through Prana, which separates it from the sibling tools that expose only partial dasha depth.

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

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

The description gives clear usage contexts: datetime is for future readings or backtests, significators is for KP star/sub-lord analysis, and finance focus is for wealth and market timing. It does not explicitly route the agent away from sibling dasha tools, so it is strong but not 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 cover the safety profile (readOnlyHint=true, destructiveHint=false), so the description's added value is scope disclosure: the full 120-year cycle from birth, anchored to birth dasha balance and Moon nakshatra. It does not cover error behavior or the significators/polar-latitude constraint, but those are already documented in the schema.

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

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

Three dense sentences with no filler: what is returned, what each period contains, and where it sits in the report hierarchy. The entry-point framing is front-loaded before the drilling-down hint.

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 an output schema present, the description needn't explain return values, and annotations carry the safety profile; what remains is purpose and placement in the tool family, both handled. A minor gap is that it doesn't surface the ayanamsa-dependence of dasha boundaries, which the schema calls out as shifting every boundary by weeks.

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 parameters are richly documented there (ayanamsa frames, timezone resolution, focus vocabulary, compact shape, polar latitude limit). The description adds no parameter-level guidance of its own, so the baseline 3 applies.

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

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

States a specific verb and resource (returns the complete Vimshottari dasha cycle, all 9 Mahadasha periods across 120 years) and enumerates the payload: ruling graha, exact start/end dates, signified houses, birth dasha balance, Moon nakshatra. This is clearly distinguishable from the sibling sub-period and current-dasha tools without opening any schema.

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

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

Positions the tool as 'the top level timeline a Vedic astrology report opens with' and 'the entry point for drilling into Antardasha and finer sub periods', which tells the agent to start here before the sub_mahadasha siblings. It stops short of naming the alternative tools or stating when NOT to use it (e.g. for the currently running dasha, where post_vedic_astrology_dasha_current would apply).

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the derivation rule (periods proportional to each lord's Vimshottari years) and what each period carries, but since an output schema exists this return-shape detail is largely redundant, and no caveats (ayanamsa-dependent boundaries, significators prerequisite) are surfaced.

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 resource and level, then the use cases. No filler, and the domain detail about Vimshottari proportionality earns its place.

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

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

With 13 parameters, full schema coverage, an output schema, and read-only annotations, the description covers what the tool produces and when to reach for it. The only gap is that it does not route explicitly among the neighboring dasha-depth tools.

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

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

Schema description coverage is 100%, so every one of the 13 parameters is already documented in detail. The description only references a "chosen Mahadasha" and adds no format, default, or interaction guidance beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource with exact scope: "Returns the 9 Antardasha sub periods inside a chosen Mahadasha." The level in the dasha hierarchy is unambiguous, so an agent can distinguish it from dasha_major above and the pratyantardasha tool below, though no sibling is named explicitly.

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

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

Gives concrete use cases (event prediction, muhurta selection, dasha timeline UIs) and frames the tool as narrowing a multi-year Mahadasha to actionable months. It does not state when to skip this level in favor of the parent or deeper dasha tools, so routing is left partly to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description adds the useful proportionality rule (each period scales with its lord's Vimshottari years). It says nothing about cost, failure modes, or the polar-latitude 400 on significators, and an output schema already covers the return shape.

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

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

Four sentences, front-loaded with what is returned before the use cases. Slight redundancy in opening with "Pratyantardasha calculator API for Vedic astrology," which largely restates the tool name, but the rest earns its space.

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 14-parameter tool with rich schema descriptions and an output schema, the description covers purpose, hierarchy level, and use cases adequately. The gaps (significators polar-latitude limit, ayanamsa frame effects) are already documented in the schema, so nothing critical is missing from the definition as a whole.

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

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

With schema description coverage at 100% across all 14 parameters, the schema already carries the full burden of parameter meaning. The description mentions no parameter at all — not mahadasha/antardasha selection, ayanamsa frames, or the significators toggle — so the baseline of 3 is correct.

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

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

States a specific verb and resource: it returns the 9 Pratyantardasha periods inside a chosen Antardasha, and it explicitly locates itself as "the third level of the Vimshottari dasha hierarchy." That level statement is what separates it from the Antardasha and Sookshma siblings in the hierarchy, though no sibling is named outright.

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?

"Use it to drill from a Mahadasha into month level timing for event prediction, muhurta selection, and dasha timeline UIs" gives clear conditions for invocation. Nothing is said about when not to use it or which sibling to pick when the agent needs a coarser or finer level, so it misses the explicit-alternatives bar of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful scale information ('9 Sookshma periods', 'typically 3 to 30 days per period') and the drill-down framing, but says nothing about error conditions, the invalid-dasha-combination case, or the significators polar-latitude limit that lives only in the schema.

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

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

Three sentences, front-loaded with the return value, then the hierarchy position, then use cases. Little waste apart from the redundant opening fragment 'Sookshma dasha API.' which merely restates the name.

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

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

An output schema exists so return structure need not be explained, and the schema covers all inputs. What is missing is the critical operational context for a 15-parameter drill-down tool: that mahadasha/antardasha/pratyantardasha values must come from the parent dasha endpoints, since an arbitrary combination will not exist for a given birth chart.

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% across all 15 parameters, so the schema fully documents date, time, ayanamsa, significators, and the three planet enums. The description contributes no additional parameter meaning beyond what the schema already provides, which is the baseline-3 case.

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

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

It names a specific verb and resource — 'Returns the 9 Sookshma periods inside a chosen Pratyantardasha' — which is far more than the tautological name alone would convey. However, it is muddied by calling Pratyantardasha 'the fourth and finest level' while the return value is the fifth (Sookshma) level, and it never distinguishes itself from the near-identical sibling post_vedic_astrology_dasha_sub_mahadasha_antardasha_pratyantardasha_sookshma.

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 'Built for dasha drill down tables, current DBA readouts, and precise event timing' clause implies usage but never states when to pick this over the sibling dasha endpoints or what prerequisites apply. There is no explicit when/when-not or alternative routing, so the agent must infer from the tool name chain.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds useful behavioral context about period length (20 minutes to 4 days) and that exactly 9 periods are returned. It does not mention error conditions or how the parent chain is validated, which is where a 16-parameter computation tool typically fails.

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

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

Four sentences, front-loaded with the return payload before the hierarchy context and use cases. The opening "Prana dasha API for Vedic astrology" is largely filler, and the hierarchy framing is repeated in two sentences, but nothing else is wasted.

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

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

With an output schema present and annotations covering the safety profile, the description correctly focuses on scope, timing granularity and use cases. What remains thin is the validation story for the four-level parent chain, which matters for a tool whose required params are all hierarchy names plus birth data.

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

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

Schema description coverage is 100% across all 16 parameters, so the schema carries the semantic load. The description only implies the parent chain through "inside a chosen Sookshma dasha" and adds no syntax or constraint detail beyond that, so baseline 3 applies.

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

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

States a specific verb and resource: returns the 9 Prana periods inside a chosen Sookshma dasha, explicitly placed as the finest level of the Vimshottari hierarchy. This lets an agent distinguish it from the shallower dasha siblings (sub_mahadasha, antardasha, pratyantardasha) by level, though no sibling is named outright.

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?

"Built for five column dasha drill down tables, muhurta selection, and pinpointing the trigger moment inside an event window already found at the Sookshma level" tells the agent the precondition (a Sookshma period is already identified) and the use cases. No explicit when-not or named alternative, 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 declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat that. It adds behavioral context by mentioning it is based on BPHS Shodasha Varga system and detects Vargottama planets, which is a specific feature. However, it doesn't disclose any other behavioral traits like computational specifics, limitations, or what happens with invalid inputs beyond the schema. It adequately supplements 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 moderately long but front-loads the purpose and immediately lists the divisions with their life areas. Each sentence contributes value, though the enumeration is verbose. It avoids fluff and uses a clear, structured list. It is efficient for the richness it conveys, warranting a 4 rather than a 5 due to its length.

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

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

With an output schema present, the description need not explain return values. Given the complexity (10 parameters, 5 required, 2 enums), the description covers the key decisions (which division, what each means) and the astrological basis. All parameters are documented in the schema, so nothing essential is missing. It is complete for an agent to correctly invoke the tool, though it could mention edge cases like ayanamsa interplay, which is already in the schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description enhances the 'division' parameter by mapping each number (2, 3, 4, 7, 9, ...) to life areas (wealth, siblings, property, children, marriage, etc.), which provides meaning beyond the schema's simple enumeration. This helps agents understand which division to request. The description does not cover other parameters, but they are already well-documented in the schema, so the extra semantic value is sufficient for a 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 clearly states the tool calculates any Vedic divisional chart (Varga) from D2 to D60, with a specific verb and resource. It enumerates the life areas for each division, distinguishing it from sibling tools like navamsa that focus on a single division. The purpose is unambiguous and not a tautology.

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

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

The description explains what the tool does and lists the life areas for each division, which helps select the appropriate division number, but it doesn't explicitly state when to choose this tool over alternatives like post_vedic_astrology_navamsa. There is no mention of when-not-to-use or comparison with siblings, leaving usage guidance implicit rather than explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so no safety disclosure is needed. The description adds behavioral substance beyond that: it specifies the planetary condition required, the 12 recognized types, and that severity/effects depend on Rahu's house position.

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

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

The core detection logic is front-loaded and the description is reasonably compact. Some marketing-style phrases ('Accurate kalsarpa dosha calculator', 'significant dosha affecting life obstacles') add mild padding, but they do not obscure the functional information.

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

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

The description states what the tool computes, the types it identifies, and what it returns (severity and effects). With an output schema present, rich parameter schemas, and 100% schema coverage, nothing essential for invoking the tool is missing.

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

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

Schema description coverage is 100%, and the schema itself provides rich semantics for date, time, location, ayanamsa, timezone, and compact output. The tool description adds no parameter-level meaning, 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 names a precise verb ('Detect') and resource ('Kalsarpa dosha'), defines the exact detection condition (all 7 planets hemmed between Rahu-Ketu), and enumerates the 12 output types. It is clearly distinguishable from sibling dosha tools like dosha_manglik and dosha_sadhesati without needing to inspect 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 gives clear context: it is for Vedic dosha analysis, birth chart evaluation, and matrimonial compatibility. It does not explicitly state exclusions or name alternatives such as dosha_manglik, but the intended domain is clear enough for an agent to select it appropriately.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond that: it detects based on Lagna-based house positions, returns severity levels, includes cancellation factors, and mentions exceptions that reduce dosha effects. This helps the agent predict behavior without 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 first two sentences are informative and the fourth adds useful detail about exceptions. However, the third sentence ('Accurate mangal dosha calculator... matrimonial compatibility...') is largely promotional and repeats the matrimonial/marriage purpose already stated in the second sentence.

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 high schema coverage, existing output schema, and safety annotations, the description is largely complete. It covers what the tool detects, how it works, what it returns, and when it is useful. It could be slightly stronger by naming sibling dosha tools for exclusion, but the Mars-house specificity already makes selection clear.

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

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

Schema description coverage is 100%, so the schema already explains date, time, location, timezone, ayanamsa, and related parameters. The description's mention of 'from Lagna' indirectly reinforces the importance of birth time and location but does not add meaningful parameter-level semantics beyond the schema.

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

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

The description uses a specific verb ('Detect') with a specific resource ('Manglik dosha') and states the exact technical basis: Mars position in houses 1, 2, 4, 7, 8, 12 from Lagna. It also names the output (severity levels, cancellation factors), which clearly distinguishes it from sibling dosha tools like kalsarpa or sadhesati.

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

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

The description gives clear usage context: matrimonial compatibility checks, kundli matching for marriage, and matrimonial sites. It does not explicitly name alternative sibling tools or state when not to use this tool, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds genuinely useful behavioral content: it identifies the phases (Rising/Peak/Setting), confirms the tool returns both dates and life effects, and frames the 7.5-year tracking behavior. No contradiction with annotations and no open safety questions.

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

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

The description is front-loaded with the core calculation and phase information, but it contains redundancies: 'Accurate sade sati calculator' repeats the calculation claim, 'Shani sadhesati 7.5 year period tracker' restates the period already mentioned, and the final two 'Essential...'/'Important...' sentences cover similar use-case ground. Several sentences could be trimmed without losing meaning.

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

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

With an output schema present, return-value details are already covered. The description adequately conveys the calculation scope, the phases, the return of dates and effects, and the use cases for a 9-parameter, 4-required tool. An agent has enough to decide whether to call it and what it will produce. Lacks only an explicit statement of exclusion versus sibling dosha tools, which is minor.

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

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

Schema description coverage is 100%, so the parameters are fully documented in the schema itself. The description adds context like 'natal Moon' and 'houses from natal Moon,' which hints at the birth data inputs, but it does not add format, range, or interaction details beyond the schema. Baseline 3 is appropriate.

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

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

Opens with a specific verb and resource: 'Calculate Sadhesati (Sade Sati) periods when Saturn transits 12th, 1st, and 2nd houses from natal Moon.' It names the exact phases (Rising/Peak/Setting), the 7.5-year period, and the return of transit dates plus effects, making it distinct from the many sibling dosha, transit, and dasha tools without needing to open any schema.

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

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

The description provides clear application context: 'Essential for Saturn transit analysis, sadhesati remedies timing, and understanding challenging Saturn periods... Important for timing major life decisions.' It tells an agent when this tool is relevant, though it never explicitly contrasts it with alternatives like dosha_manglik, dosha_kalsarpa, or generic transit tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety needs no restating. The description usefully adds domain behavior beyond that: the ascending/descending node mapping, crossing frequency, and the fact that results are returned in the requested coordinateSystem (sidereal default). It does not mention pagination limits or how many rows a busy year might return, but the added context is substantive.

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

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

The opening is well front-loaded with purpose and a definition of the phenomenon, and the frequency sentence earns its place. However, the trailing phrase 'Ecliptic crossing API, planetary node crossing, ascending descending node ephemeris' is keyword stuffing that adds no selection or invocation value and should be cut.

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 an output schema present, return-field explanation is optional, yet the description still names date, time, direction, longitude, and sign, which is helpful. Combined with annotations covering the read-only profile and a fully documented schema, an agent has enough to invoke correctly; only alternative-tool routing is missing.

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

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

Schema description coverage is 100%, so all five parameters (lang, year, compact, timezone, coordinateSystem) are already documented in the schema, including defaults, ranges, and formats. The description adds nothing about parameters beyond restating the coordinateSystem default, so the baseline 3 applies.

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

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

States a specific verb and resource ('Find all ecliptic plane crossings for visible planets during a given year') and immediately defines the phenomenon so the agent knows exactly what event is being computed. This is clearly distinguishable from siblings like parallels, heliacal, and transit, which cover different astronomical events.

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

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

The description explains what a crossing is and gives frequency context (Moon ~2×/month, outer planets less often), which implicitly helps an agent judge relevance. However, it never states when to choose this over cousins such as post_vedic_astrology_parallels or post_vedic_astrology_transit, nor any prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety traits. It adds useful behavioral context: the calculation follows the Surya Siddhanta rule, the verdict is read at sunrise/sunset, and latitude is restricted to avoid polar horizon geometry. 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 verbose and includes a trailing keyword list (e.g., 'Graha asta API, Guru Asta Shukra Asta dates...') that adds no value for an agent. It front-loads the main purpose but could be trimmed significantly. It is structured with the core function first, but the extra SEO-like text detracts from conciseness.

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 an output schema present, the description does not need to detail return formats. It explains what the tool returns, the underlying rule, and the distinction from birth chart combustion. The description is adequate for an agent to understand when and why to call it, though it could mention edge cases like invalid date or timezone handling.

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 descriptions cover 100% of parameters, so baseline is 3. The description text reinforces location-awareness and the classical rule but adds no new semantic meaning beyond what the schema already provides for date, latitude, longitude, timezone, and compact. The value comes from the schema, not the description.

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

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

The description clearly states the tool calculates heliacal rising (udaya) and setting (asta) of the six visible grahas for any date and place, using the Surya Siddhanta rule. It explicitly lists the return values (whether graha clears solar glare, separation from Sun, visibility change dates) and differentiates itself from a birth chart combustion flag by being location-aware. This distinguishes it from sibling tools like planetary_positions or birth chart.

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

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

The description provides concrete usage context: it is the calculation behind Guru Asta and Shukra Asta, the periods classical muhurta withholds marriage and ceremonies. It also contrasts with a birth chart combustion flag, implying when to prefer this tool for location-aware heliacal visibility. However, it does not explicitly name sibling tools or state when not to use, leaving some inference required.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the description's job is to add operational context, and it does: the polar-latitude limit is explained with the underlying reason (Placidus has no solution beyond 66.56 degrees) and the exact failure mode (returns 400). That is the single most likely cause of a failed call on this tool and it is disclosed. No mention of cost, rate limits, or latency, but nothing is contradicted.

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

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

Front-loaded well with the verb and the payload inventory, but the third sentence restates the first two ("One call is a complete Krishnamurti Paddhati chart generator, returning the Placidus cusps and the planets with their sub lords together") and the closing polar-latitude sentence duplicates the latitude parameter's own description verbatim. The "Perfect for KP astrology software..." line is marketing filler that does not help an agent decide anything.

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 a 100%-documented 11-parameter schema, explicit readOnly annotations, and an output schema, the description need only supply what structured fields cannot. It does supply the key edge case (polar latitude → 400) and confirms the single call returns cusps and planets together. Nothing an agent needs in order to invoke it correctly is missing; it is only mildly padded.

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 already 100%, including detailed rationale for ayanamsa, nodeType, focus, and the polar latitude bound, so the baseline here is 3. The description's only parameter-adjacent content — "supports custom ayanamsa and dynamic KP-Newcomb ayanamsa calculation" and the polar-latitude warning — is a restatement of text that already appears in the ayanamsa and latitude schema entries, adding no syntax, constraint, or interaction details 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?

States a specific verb and resource ("Generate authentic Krishnamurti Paddhati birth charts") and lists the exact contents: Placidus cusps, 9 planets, nakshatra details, star-lords, sub-lords, KP horary numbers. The sentence "one call is a complete Krishnamurti Paddhati chart generator, returning the Placidus cusps and the planets with their sub lords together" implicitly separates it from the narrower post_vedic_astrology_kp_cusps and post_vedic_astrology_kp_planets siblings, but never names them, so differentiation is inferential rather than explicit.

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?

"Perfect for KP astrology software, horary prediction apps, and event timing analysis" gives domain context but not tool routing. There is no statement of when to pick this over post_vedic_astrology_birth_chart, post_vedic_astrology_kp_cusps, or post_vedic_astrology_kp_horary, which are the obvious neighbouring choices in a 60-tool family. Usage is implied, not prescribed.

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?

Goes meaningfully beyond the readOnlyHint/destructiveHint annotations with a concrete failure behavior: latitudes at or beyond 66.56 degrees "returns 400," with the geometric reason (Placidus has no solution inside the polar circles). It also discloses the return shape (all 12 cusps with sub-division details) and ayanamsa computation behavior. It does not cover volume, latency, or default house-system overrides, keeping it short of a 5.

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

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

The purpose is front-loaded, but the middle section is redundant: "used in KP horary astrology" and "what Krishnamurti Paddhati horary work reads first" restate the same point, and the final latitude sentence duplicates the latitude parameter's schema description almost verbatim. Trimming those would lose no information.

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

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

Given 10 parameters, an output schema, and full schema coverage, the description supplies what is missing: the analytical use cases, the return contents, and a hard input constraint with its error mode. The only real gap is that an agent reading this cannot tell from the description alone whether kp_chart or kp_horary is the better call, which for a dense KP tool family is worth naming.

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

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

Schema description coverage is 100% and every one of the 10 parameters is documented in the schema, so the baseline is 3. The description adds only that KP-Newcomb and custom ayanamsa are supported, which the ayanamsa enum and ayanamsaValue description already convey; it says nothing about focus, compact, lang, or timezone 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?

States a specific verb and resource: "Calculate unequal Placidus house cusps with ruling sign-lord, nakshatra-lord, and sub-lord for each cusp," and the closing sentence reinforces the distinguishing feature (star lord and sub lord per cusp). However, it never names the near-siblings that an agent would have to choose between — post_vedic_astrology_kp_chart, kp_horary, and kp_sublord_changes — so differentiation is left implicit.

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?

Clear usage context is given: "Used in KP horary astrology, cusp sub-lord analysis, and birth chart rectification," plus the framing "Use it as a Placidus house cusp calculator." There are no explicit exclusions or named alternatives, which is the main shortfall, but the agent can tell when this tool is applicable.

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

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

Annotations already declare read-only and non-destructive, so the bar is lower, and the description still adds substantial context: the 400 failure mode at polar latitudes, the fact that the layer weights are a house convention with no classical KP source, and that the result is auditable line by line. The disclaimer that the score measures method output, not gain/loss probability, is exactly the kind of behavioral framing structured fields cannot carry.

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

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

Front-loaded and well organized into layer, weight and audit claims, but the back half repeats itself: the 'no classical KP text weighs these layers / tables printed so it can be checked' point lands twice in near-identical wording, and the polar-latitude rule is duplicated from the latitude schema field.