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 declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral details: 'Returns exact date and time of each Moon aspect event with ternary search refinement to the minute' and explains the default behavior of omitting year/month for a current calendar. These go beyond the annotations and help the agent understand precision and default behavior, though it doesn't mention any limitations like pagination 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 description is front-loaded with the main purpose and then provides useful technical details (aspect types, precision, default behavior, use cases). It is somewhat long due to enumerating all 22 aspect types, but each sentence contributes meaningful information. The trailing keywords ('Monthly lunar aspects API...') are arguably redundant, but they don't detract significantly from clarity. Overall, 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?

Given the tool has an output schema (not shown but present), the description need not detail return values. It covers the core functionality, precision, default behavior, and use cases. It does not mention timezone handling, coordinate system, or response format, but these are all documented in the input schema. For a read-only tool with six optional parameters, the description is sufficiently complete for an agent to invoke it correctly.

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

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

The input schema has 100% description coverage for all six parameters, so the baseline is 3. The description mentions the year/month default behavior ('Omit year and month to get the month in progress') which aligns with the schema's default values, but adds no new parameter-specific semantics. The detailed list of aspect types does not relate to parameter usage, so the description provides minimal value 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 clearly states the tool's function: 'Track all lunar aspect events for a given month including major and minor aspects.' It specifies the resource (lunar aspects), scope (monthly), and enumerates the aspect types. It distinguishes itself from siblings by explicitly focusing on lunar aspects, and mentions it returns exact dates/times, making the purpose unmistakable.

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

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

The description provides clear context on when to use it: 'Essential for muhurta selection, daily panchang analysis, and chandra gochar predictions.' It also implies that omitting year/month gives the current month, which is a usage nuance. However, it does not explicitly mention alternatives or when not to use it, such as pointing to post_vedic_astrology_aspects_monthly for non-lunar aspects, so it lacks explicit 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 safety profile is covered. The description adds meaningful behavioral context beyond the annotations: it discloses the calculation method ('degree-based aspect methodology on sidereal positions (Lahiri ayanamsa)'), the refinement technique ('ternary search refinement'), and the exact output ('exact date and time of closest approach'). It also explains the default behavior when year/month are omitted. This goes beyond what annotations provide, though it doesn't describe pagination or response shape (output schema exists).

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

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

The description is information-dense but well-organized: it leads with the core function, then lists aspect types, then methodology, then usage guidance, then the sibling reference. The final sentence is a keyword-stuffed list ('Monthly planetary aspects API, graha drishti calendar, mutual aspect ephemeris, minor aspects') that adds little value and reads like SEO filler. That slightly detracts from an otherwise efficient structure.

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

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

For a read-only calculation tool with 0 required parameters, a complete output schema, and 100% schema coverage, the description covers the essential context: what it calculates, how it calculates, when to use it, and when not to. The only minor gap is that it doesn't describe the output structure, but the output schema exists and the description's mention of 'exact date and time of closest approach' gives a preview. This is nearly complete for the tool's complexity.

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

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

Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds some context about the coordinateSystem parameter by mentioning 'sidereal positions (Lahiri ayanamsa)' and the default month behavior, but it doesn't add significant meaning beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb ('Calculate'), a precise resource ('all planetary aspect events excluding Moon for a given month'), and enumerates the exact aspect types detected (5 major, 17 minor). It also distinguishes itself from the sibling post_vedic_astrology_aspects_lunar by explicitly excluding the Moon and pointing to the lunar endpoint. This is a clear, specific purpose that an agent can act on 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 gives explicit usage context: 'Essential for transit timing, muhurta selection, and monthly astrological forecasting.' It also provides a clear when-not-to-use rule: 'For Moon-specific aspects, use the /aspects/lunar endpoint.' The 'Omit year and month to get the month in progress' note gives practical guidance for keeping a published calendar current. This is strong 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 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 the safety profile is covered and the bar for additional disclosure is lower. The description adds that results are 'grouped by zodiac signs (rashis) with nakshatra details and pada,' which is useful output-shape context, but 'accurate' and 'complete' are quality claims, not behavior, and nothing is said about pagination, size, or response structure beyond that grouping.

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 payload is front-loaded in the first sentence, but the remaining sentences include filler: 'Kundli calculator API for astrology apps, matrimonial sites' adds no operational information, and 'Perfect for kundli generation, horoscope matching, and Vedic astrology software integration' largely restates what the tool is. The third sentence on grouping is the only one that earns its keep beyond the opener.

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 12-parameter tool with an output schema present, the description is functionally adequate — it states what the chart contains, and the schema's rich parameter documentation plus output schema cover the rest. The main gap is that, amid a very large sibling family, it offers no routing guidance and leaves the agent to infer when this is the right tool versus planetary_positions, navamsa, or kp_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 coverage is 100%, with every one of the 12 parameters carrying a detailed description (date format, time criticality, ayanamsa behavior, focus semantics, compact shape, etc.), so baseline 3 applies. The description adds no parameter-level meaning beyond what the schema already states; the mention of grahas and rashis maps to output, not inputs.

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

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

The description states a specific verb and resource — 'Calculate complete Vedic birth chart (Janam Kundli, natal chart)' — and enumerates exactly what the chart contains: all 9 grahas Sun through Ketu plus Lagna, grouped by rashi with nakshatra and pada. The title's 'D1 Rashi chart' helps distinguish it from D9 navamsa and raw planetary-position siblings, though the differentiation is implicit rather than naming any sibling.

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 offers use-case context ('Perfect for kundli generation, horoscope matching, and Vedic astrology software integration'), but kundli generation is a tautology of what the tool itself is. No sibling is named and no exclusion is given — an agent is never told when to prefer planetary_positions for raw positions, navamsa for D9, or kp_chart for the KP frame, despite 55+ siblings.

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

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

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 already mark the operation safe/read-only, and the description goes well beyond them by exposing computational conventions: Lahiri vs KP-Newcomb sidereal frames, sunrise-to-sunrise panchanga limbs with validity windows, windows rather than scalar balas, and a strength score with its arithmetic published. It even separates classical rules from the RoxyAPI counting convention, which is unusually honest about provenance.

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?

Though dense, the description front-loads the core purpose in the first sentence and every subsequent sentence adds a distinct behavioral fact—pipeline, joins, scoring, frames, and provenance. The length is justified by the tool's complexity, and nothing appears repeated or padded.

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, multi-system tool, the description plus a 100%-covered schema and an output schema covers selection and invocation. It explains what is classical, what is a counting convention, the exact astronomical frames, and the day-boundary behavior, leaving no major behavioral 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?

Because schema coverage is 100% and each parameter already has a rich description, the tool description does not need to reiterate parameter syntax, defaults, or formats. The description focuses on the composition pipeline and coordinate frames rather than per-parameter meaning, which is appropriate at the baseline of 3.

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

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

The description defines a concrete deliverable—a composed daily reading for exactly one native on exactly one date—and enumerates the systems it stitches together (gochara, panchanga, dasha, KP finance). This clearly differentiates it from sibling read-only chart, panchanga, and dasha tools because it is explicitly an integrated one-call composition rather than a single measurement.

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

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

It gives clear selection context: this is the one-call daily reading for one native and one date, combining gochara, panchanga, dasha, and KP finance. It also tells callers what the output is designed to do—place every graha in one cited state, produce validity windows, and publish the strength-score arithmetic. It does not explicitly name alternatives, so an agent seeking only a transit or only a panchanga would have to infer that from the sibling names.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the output format (dasha timeline with start/end dates, hour-level timing), the optional significators behavior, and the 120-year Vimshottari system based on Moon nakshatra. 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 a single long paragraph with promotional phrases like 'Accurate dasha calculator API' and 'Essential for understanding' that add fluff. The key information is present and the core purpose is front-loaded, but the structure is not tight or scannable.

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

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

Given the complexity (13 params, output schema present), the description adequately covers the main behavior, optional features, and use cases like backtesting and future readings. It does not explicitly compare with sibling dasha tools, but that is partially covered by the purpose statement. The description complements the rich schema well.

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 all 13 parameters, including datetime, significators, and ayanamsa. The tool description reinforces these points (e.g., 'Pass datetime to read the five lords') but does not add substantially new meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description explicitly states it calculates all five running Vimshottari Dasha levels (Mahadasha, Antardasha, Pratyantardasha, Sookshma, Prana) with remaining time, which is a specific verb+resource. It differentiates from sibling tools like post_vedic_astrology_dasha_major or dasha_sub_mahadasha by covering the full hierarchy of levels.

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 datetime parameter (for future readings or backtests) and when to set significators, but it does not explicitly state when to choose this tool over the other dasha endpoints or provide exclusions. The differentiation is implied through the level depth but not spelled out.

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 detail about what each period carries, such as ruling graha, exact start/end dates, house significations, birth dasha balance, and Moon nakshatra, but it does not disclose limitations, error behavior, or other operational traits. The added content is more about output shape than behavioral disclosure.

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

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

The description is three sentences with no filler. It front-loads the action and scope, then closes with placement guidance about being the entry point for sub-periods. Every sentence earns its place.

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

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

The description, combined with 100% schema coverage, an output schema, and read-only annotations, gives an agent enough to select and invoke the tool correctly. It could be slightly more complete by explicitly routing to dasha_current or naming the sub-period sibling tools, but those are minor gaps.

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 12 parameters are already documented in the schema with detailed semantics. The description adds no parameter-level meaning beyond naming output concepts like birth dasha balance and Moon nakshatra. The baseline 3 applies because the schema 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 opens with a specific verb and resource: 'Returns the complete Vimshottari dasha cycle from birth, all 9 Mahadasha periods across the full 120 year span.' It also distinguishes itself from the finer dasha siblings by presenting itself as the 'top level timeline' and the 'entry point' for drilling into Antardasha and finer sub-periods, making selection 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 gives clear context on where this tool fits: it is the top-level timeline a Vedic astrology report opens with and the starting point before drilling into Antardasha and finer sub-periods. It does not explicitly name alternatives or state when not to use it, such as when only the current dasha is needed, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral detail about the output: exactly 9 sub-periods, each with its ruling graha, start/end dates, houses, and parent Mahadasha. This goes beyond the annotations and informs the agent what to expect, 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 compact three-sentence paragraph that front-loads the primary function, then details the output contents, and finally states the use case. Every sentence contributes value with no redundancy or fluff.

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

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

Given the tool has 13 parameters (5 required), a rich schema with 100% coverage, and an output schema, the description adequately completes the picture. It explains the purpose, output shape, and use cases. It does not need to repeat parameter details since the schema handles them, and it provides enough context for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so every parameter already has a detailed description. The tool description does not add parameter-level meaning beyond referencing 'a chosen Mahadasha', which is also covered in the schema. This meets the baseline for high schema coverage without adding extra semantic value.

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 ('Returns'), a clear resource ('the 9 Antardasha sub periods'), and defines the scope ('inside a chosen Mahadasha'). It distinguishes itself from sibling tools by specifying the sub-period level and the content (ruling graha, dates, houses, parent Mahadasha), making its function 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 provides clear usage context ('narrow a multi year Mahadasha down to the months that matter for event prediction, muhurta selection, and dasha timeline UIs') and implies that it operates on an already-selected Mahadasha. However, it does not explicitly contrast with sibling tools like dasha_major or the deeper antardasha_pratyantardasha levels, so no explicit exclusions or alternatives are given.

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 declare readOnlyHint=true and destructiveHint=false, so the description correctly adds value by explaining output structure: it returns 9 periods, each proportional to the Vimshottari years of its lord. It also implies the API is a pure calculator. It does not contradict annotations, and adds context beyond the basic safety profile.

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

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

The description is compact, with the core function and use case front-loaded in the first sentence. It provides essential context without verbosity, though additional detail on output shape or examples could be included without much penalty. The two sentences are efficient and focused.

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 complexity (14 parameters) but full schema coverage and an output schema, the description is sufficiently complete for an agent to call it correctly. It explains the tool's place in the hierarchy, its inputs, and its output behavior, leaving no critical gaps for selection or invocation.

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

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

Schema coverage is 100%, so the schema already documents all parameters in detail. The description does not add new parameter-level semantics beyond what's in the schema, but it does emphasize the two parameters (mahadasha and antardasha) that are central to this tool, which is useful. The baseline of 3 applies since schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: it returns the 9 Pratyantardasha periods inside a chosen Antardasha, explicitly positioning it as the third level in the Vimshottari dasha hierarchy. It distinguishes itself from sibling tools like the one for Antardasha and the deeper Sookshma level, providing clear differentiation.

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 this tool: to drill from a Mahadasha into month-level timing for event prediction, muhurta selection, and dasha timeline UIs. It implicitly contrasts with the more granular Sookshma tool and the coarser Mahadasha/Antardasha tools, giving the agent a clear decision framework.

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

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

Annotations already mark this as read-only, so the description's job is to add behavioral specifics, which it does: 9 Sookshma periods, typical durations of '3 to 30 days per period', and the level of timing granularity. There is no contradiction with the readOnlyHint, and the description conveys the computational scope without needing to repeat safety information.

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 tight sentences with no filler. The first sentence immediately states what the API does, the second explains the hierarchy and output count, and the third gives concrete use cases. Every sentence earns its place and is front-loaded with the most important 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 the rich input schema, annotations, and output schema, the description covers the essential conceptual context: the dasha hierarchy level, result count, typical duration, and intended use cases. The main gap is not explaining how this endpoint relates to the sibling tool post_vedic_astrology_dasha_sub_mahadasha_antardasha_pratyantardasha_sookshma, which could confuse an agent selecting between them.

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

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

Schema description coverage is 100%, and each parameter already carries rich documentation about formats, defaults, and meaning. The tool description adds no parameter-level detail; it only contributes context about output granularity, which is appropriate for the schema but does not push this dimension above 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 identifies this as the 'Sookshma dasha API' and states exactly what it returns: 'the 9 Sookshma periods inside a chosen Pratyantardasha.' It anchors the tool in the Vimshottari hierarchy ('fourth and finest level'), making it easy to distinguish from coarser dasha siblings such as dasha_sub_mahadasha_antardasha.

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: it completes a drilled-down Vimshottari computation down to day-level timing and is intended for 'dasha drill down tables, current DBA readouts, and precise event timing.' However, it does not explicitly state when NOT to use this tool or name alternative sibling tools, such as the coarser antardasha endpoint or the similarly named _sookshma variant.

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 it read-only and non-destructive, so the bar for extra disclosure is lower. The description adds genuinely useful behavior: it returns exactly 9 periods, spans from the '120-year cycle to hour level timing,' and gives typical period lengths of '20 minutes to 4 days depending on the parent Mahadasha.' No contradiction with the annotations.

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

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

Three sentences, front-loaded with the core behavior, then hierarchy context and use cases. Every sentence earns its place for a tool with this complexity, and there is no fluff or repetition of the schema.

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

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

With a full input schema, an output schema, and readOnly/destructive annotations, the description supplies the missing judgment layer: what the Prana level is, how fine its timing is, and what applications it serves. Nothing an agent needs in order to select or call this tool correctly is missing.

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

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

Schema coverage is 100%, so each of the 16 parameters is already documented in the input schema. The description adds only indirect parameter context, such as the parent Mahadasha affecting period length, but does not redefine or clarify any specific parameter, 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 9 Prana periods inside a chosen Sookshma dasha.' It also situates itself in the Vimshottari hierarchy as the 'fifth and finest level,' which separates it from sibling dasha tools at the Mahadasha, Antardasha, and Pratyantardasha levels.

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?

Names concrete use cases: 'five column dasha drill down tables, muhurta selection, and pinpointing the trigger moment inside an event window already found at the Sookshma level.' This tells an agent when this level is appropriate, though it does not explicitly say when to prefer a coarser dasha sibling or list 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 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 indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond that: the ascending/descending node distinction, crossing definition, expected frequency, and the return of date, time, direction, longitude, and zodiac sign.

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

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

The description is front-loaded with the core purpose and uses an appropriate length for a tool with five parameters. The final keyword-like tag line adds little value, but the rest of the sentences are informative and purposeful.

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

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

Given a full input schema, an output schema, and read-only annotations, the description is largely complete. It explains what an ecliptic crossing is, what output is returned, and the default coordinate system; the main residual gap is not listing exactly which planets count as 'visible planets.'

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 year, timezone, coordinateSystem, compact, and lang. The description mentions sidereal default and coordinate system, but adds little beyond what structured fields already provide, matching 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 opens with a specific verb and resource: 'Find all ecliptic plane crossings for visible planets during a given year.' It clearly defines what is being computed and is distinct from any sibling tool, including heliacal, parallels, and planetary positions.

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

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

The description provides clear context for when this is relevant, such as the year range, visible planets, and crossing frequency. However, it does not state when to prefer this over sibling tools like post_vedic_astrology_heliacal or post_vedic_astrology_planetary_positions, nor does it give explicit 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds meaningful behavioral context: it supports custom and dynamic ayanamsa calculation, specifies that nodeType choice can move a KP sub-lord in narrow boundary cases (via the schema description, though the tool description itself mentions the ayanamsa support), and explains that fields without translation return English in the lang parameter. The main description text advertises the ayanamsa flexibility and the complete-chart behavior. It does not describe pagination or size of the response, but the output schema exists and the read-only behavior is already annotated, so this is adequate.

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 and front-loads the core deliverable in the first sentence, with use cases following. There is some redundancy at the end ('One call is a complete... returning the Placidus cusps and the planets with their sub lords together') that partially repeats the first sentence, which is why it loses one point. Overall it is compact and readable for an 11-parameter 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?

For a complex 11-parameter tool with a rich output schema and full schema coverage, the description covers the main deliverable, ayanamsa flexibility, and use cases. It could explicitly mention the output schema or the key parameters (date/time/location) but those are fully documented in the schema and an output schema exists, so the definition is complete enough for an agent to select and invoke the tool correctly. Minor gap: no explicit statement about what the response contains structurally (e.g., houses, planets, cusps objects), but the output schema covers that.

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

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

Schema description coverage is 100%, so the input schema fully documents all 11 parameters with detailed descriptions, enums, defaults, and examples. The description text adds high-level context for ayanamsa and focus ('dynamic KP-Newcomb ayanamsa calculation', 'KP horary numbers') but does not add per-parameter meaning beyond what the schema already provides. Per calibration, baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description opens with a specific verb and resource ('Generate authentic Krishnamurti Paddhati birth charts') and enumerates the outputs: Placidus house cusps, star-lord/sub-lord calculations, all 9 planets, Ascendant, 12 cusps, nakshatra details, and KP horary numbers. It also distinguishes itself from siblings by stating it is 'a complete KP chart generator' returning 'the Placidus cusps and the planets with their sub lords together,' which separates it from the narrower post_vedic_astrology_kp_cusps and post_vedic_astrology_kp_planets tools. The closing sentence repeats the integration point, reinforcing differentiation.

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 target use cases ('KP astrology software, horary prediction apps, and event timing analysis') and implicitly distinguishes from the more granular KP siblings (kp_cusps, kp_planets) by emphasizing that one call returns everything together. However, it does not explicitly say when to choose this tool over a sibling like post_vedic_astrology_kp_cusps or post_vedic_astrology_kp_planets, nor does it state exclusions/prerequisites. The guidance is clear enough contextually but lacks explicit when-not-to-use instructions.

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 does not need to repeat safety. It adds behavioral context by mentioning 'Dynamic KP-Newcomb or custom ayanamsa support' and noting it 'Returns all 12 house cusps with KP sub-division details.' No contradiction with annotations. It does not mention potential limitations or error conditions, but given annotations cover safety, 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 about four sentences and is mostly front-loaded with the core purpose. It has some redundancy: 'Returns all 12 house cusps with KP sub-division details' and 'Use it as a Placidus house cusp calculator that also carries the star lord and sub lord of each cusp' convey similar information. Still, it is compact and readable, earning 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?

Given the tool has 10 parameters but all are well-documented in the schema, and there is an output schema, the description does not need to detail return structure. It explains what the tool does, its use cases, and its ayanamsa support, which is sufficient for an agent to decide when to call it. No critical information is missing.

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

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

Schema description coverage is 100%, with each parameter (date, time, latitude, longitude, timezone, ayanamsa, focus, compact, ayanamsaValue) having a detailed description. The tool description adds no parameter-specific semantics beyond what the schema already provides; it only mentions ayanamsa support generally. 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 unequal Placidus house cusps with sign-lord, nakshatra-lord, and sub-lord for each cusp. It is specific about the resource (cusps) and the verb (calculate), and it notes the output (all 12 cusps with KP sub-division details). It does not explicitly name a sibling tool to distinguish from, but the unique focus on cusps with sub-lords separates it from other KP tools.

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

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

The description provides clear usage context: 'Used in KP horary astrology, cusp sub-lord analysis, and birth chart rectification.' It also positions the tool as a 'Placidus house cusp calculator that also carries the star lord and sub lord,' which implies when it is appropriate. However, it does not explicitly state when NOT to use it or name alternative tools for different needs, so it lacks explicit 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, so no contradiction. The description adds substantial behavioral context: it explains the scoring method, the weights, the auditability ('every table behind the number is printed'), and clarifies the score measures method output, not probability. It also discloses the KP practitioner convention and the override capability. This goes well beyond the annotations.

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

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

The description is verbose and repetitive, with phrases like 'rather than trusted' appearing twice. It contains multiple long sentences that could be trimmed without losing meaning. While it is structured, it does not meet the standard of every sentence earning its place; some redundancy exists.

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 complexity (13 parameters, nested objects, output schema exists), the description is remarkably complete. It covers the method, weights, arithmetic conventions, auditability, disclaimer about probability, and override capability. The output schema handles return values, so no gap there. Nothing essential is missing for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds conceptual context for weights and layers, but the schema already provides detailed parameter explanations. The description does not introduce new parameter semantics beyond what the schema offers, so it remains at 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 states a specific verb and resource: 'A Krishnamurti Paddhati daily finance reading for one native on one date.' It clearly differentiates from sibling KP tools by focusing on a finance score from four sub lord layers, which is distinct from raw cusps, ruling planets, or chart calculations. The purpose is unambiguous.

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

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

The description implies usage for daily finance readings but does not explicitly state when to use this tool over alternatives. It mentions override options but no exclusions or direct references to sibling tools. The use case is clear but lacks explicit routing guidance.

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