Vedic Astrology and Kundli MCP Server by RoxyAPI

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds useful behavioral context by specifying that entries include a label and meaning, and that the list spans exactly 17 states across three systems. 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 first two sentences are informative and front-loaded, but the final keyword-stuffed phrase ('Avastha meaning API, Baladi avastha, Jagradadi, Deeptadi, planetary state Vedic astrology.') adds no agent value and reads as SEO filler. This undermines an otherwise compact description.

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

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

With no output schema, the description responsibly covers what the returned items contain ('short label and what the state means') and the overall taxonomy. Parameter semantics are well covered by the schema, and the use case is clear. Minor gaps around exact response shape are acceptable for a simple reference-list 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% and includes defaults, enums, and examples for lang, system, and compact. The description only adds a brief mention of system filtering, which doesn't meaningfully extend 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?

Description opens with a specific verb and resource: 'Reference list of every avastha (planetary state)' and clearly scopes the content by naming all three classical systems and their counts. This distinguishes it from sibling tools like get_vedic_astrology_avasthas_id (single lookup) and other reference lists.

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?

States a clear usage context: 'Use it to turn the bare state names a birth chart returns into readable output,' and mentions filtering by system when only one is needed. It doesn't explicitly mention when not to use it or point to the _id sibling for single-state lookups, but the context is strong.

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 known. The description adds value by disclosing the output structure (system, short label, meaning) and the origin of the slug (birth chart fields `awastha`, `jagradadi`, `deeptadi`), which exceeds what annotations convey.

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

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

The description is two sentences with no redundant information. It front-loads the action ('Look up a single avastha state') and immediately follows with the identifier source and return value. 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?

Given the tool's simplicity (3 params, 1 required, annotated safe, no output schema), the description covers input semantics and output contents sufficiently. The schema fully documents parameters, and the description explains the slug source and results, making it complete for an agent to select and invoke 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%, including a detailed enum for id and defaults for lang and compact, so the schema carries the parameter documentation burden. The description adds minimal extra meaning by clarifying that id is a slug, but the schema already describes that thoroughly, so the description does not significantly compensate.

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 'Look up a single avastha state by its slug', which is a specific verb and resource. It distinguishes itself from the sibling `get_vedic_astrology_avasthas` by emphasizing 'single' and specifies the return contents (system, short label, meaning). The source of the slug is also explained, 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 avastha slug returned from a birth chart, which provides clear context. It does not explicitly name alternative tools or when-not-to-use, but the sibling `get_vedic_astrology_avasthas` suggests a list-all counterpart, making the intended use case evident.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the ayanamsa is computed continuously rather than table-looked-up, that it tracks the exact requested moment, and that it 'Returns the same value every KP endpoint applies internally.' It does not explicitly state the output format or potential error conditions, but for a simple GET calculation tool the key behaviors are transparent.

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, but the final sentence is keyword stuffing ('KP Newcomb ayanamsa API, dynamic ayanamsa calculator, Krishnamurti ayanamsa today, current KP ayanamsa') that provides no value to an AI agent and should be removed. This filler undermines conciseness and 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?

The tool has 4 optional parameters and no output schema. The description compensates by explaining the returned value's meaning (precession offset), its consistency across KP endpoints, and the JSON shape via the compact parameter description ('Default false returns standard indented JSON'). While it does not show an example output, it gives enough context for a competent agent to use the tool correctly.

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

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

The input schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by clarifying parameter relationships: how date, time, and timezone combine to pin a birth moment and that omitting time means midnight UTC. This goes beyond what the schema individual parameter descriptions provide.

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: 'Get the KP-Newcomb (Krishnamurti) ayanamsa for any instant.' It clearly distinguishes from siblings by emphasizing the dynamic computation ('computed continuously from Newcomb precession theory rather than looked up in a preset table') and its internal use across KP endpoints. This leaves no ambiguity about what the tool does.

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

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

The description gives clear usage context: 'Supply date alone for midnight UTC, or add time and timezone to pin a birth moment exactly.' It also explains the purpose ('precession offset subtracted from a tropical longitude to obtain the sidereal one') and why it matters for KP chart reproduction. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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

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

With no annotations, the description carries the burden of disclosing behavior. It details the return content (names, zodiac ranges, ruling planets, deities, symbols, characteristics, remedies) and explicitly states it returns all 27 nakshatras in order. This is transparent for a read-only reference tool, though it doesn't disclose response structure or error handling.

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, tightly written, with the primary action and scope front-loaded, followed by return content and use cases. Every sentence adds value with no redundancy or filler.

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

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

For a simple list tool with no output schema, the description covers the return fields and use cases, and the schema covers parameters. It does not specify the exact JSON structure (e.g., whether it returns an array of objects), but the word 'list' implies it. The description is adequate but could slightly clarify the response shape.

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 both parameters (lang and compact), each with detailed descriptions including defaults and effects. The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool returns the complete list of 27 nakshatras with specific data fields (names, zodiac ranges, ruling planets, etc.), using a specific verb 'Get' and resource. It distinguishes from siblings by emphasizing 'complete list' and 'from Ashwini to Revati', which contrasts with the likely single-item get_vedic_astrology_nakshatras_id 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?

The description provides concrete use cases: 'nakshatra lookup tables, dasha period calculations, muhurta selection, and astrology app reference data.' This gives clear context for when to use the tool, though it does not explicitly mention when not to use it or name the ID-based sibling as an 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It states the return content (name, zodiac range, etc.), which implies a read-only operation, but it omits information about error behavior, authentication, rate limits, or any side effects. The description adds some transparency about outputs but is not thorough for an unannotated tool.

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, front-loaded sentence that efficiently conveys the tool's purpose and return payload. The list of return fields (name, zodiac range, ruling planet, etc.) is informative without being verbose; every part earns its place.

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

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

Given the tool's simplicity, rich parameter schema, and absence of output schema, the description adequately covers the essential purpose and return fields. However, it does not explicitly guide on using the list sibling or handle edge cases (e.g., invalid ID), and no annotations exist to supplement behavioral context. Still, it is reasonably complete for a straightforward get-by-ID operation.

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 thoroughly documents all three parameters: id with full enum, lang with language fallback note, and compact with a detailed token-optimization explanation. The description adds no parameter-level 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 uses a specific verb and resource: 'Get detailed information for a single nakshatra (lunar mansion) by its ID slug.' This clearly distinguishes it from sibling list tool get_vedic_astrology_nakshatras and other ID-based tools like rashis_id, 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 ('by its ID slug' suggests single-item lookup) but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or the list sibling. Context signals show sibling get_vedic_astrology_nakshatras for list operations, but the description itself provides no such guidance, so it remains implied rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. It enumerates the exact return fields: 'Sanskrit names, Western equivalents, sidereal date ranges, symbols, governing Adityas, and personality characteristics,' and labels itself 'Reference data,' which implies a safe read operation. It doesn't mention potential response behaviors like language fallback, but that is covered in the lang parameter description.

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 the core action in the first sentence, return content in the second, and use cases in the third. No filler or redundancy.

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

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

For a simple read-only reference list, the description fully covers purpose, return content, and common use cases. It includes enough detail for an agent to decide when to invoke it without needing an output 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 covers both parameters (lang and compact) with enum constraints, defaults, examples, and descriptions, so schema coverage is 100%. The description adds no parameter-specific guidance beyond what the schema already provides; 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?

Description opens with 'Get the complete list of 12 rashis (zodiac signs) in Vedic astrology,' a specific verb+resource. It clearly distinguishes from sibling tools like get_vedic_astrology_rashis_id by emphasizing 'complete list of 12' and 'Reference data for Mesha through Meen.'

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?

States it is 'Essential for zodiac sign lookup tables, astrology apps, and rashi-based UI components,' providing clear use contexts. However, it doesn't explicitly mention when to prefer the sibling get_vedic_astrology_rashis_id for single rashi lookups, so it stops short of full exclusion 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?

With no annotations provided, the description carries the full burden and adds value by enumerating the returned fields (Sanskrit name, Western equivalent, sidereal date range, symbol, governing Aditya, personality characteristics). It does not discuss error handling or side effects, but 'Get' implies read-only. The description is transparent about output content.

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 short sentences, front-loaded with the core action and followed by the return payload list. Every word contributes; no filler or redundancy.

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

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

Given a simple lookup tool with fully self-describing parameters (enums, defaults, and descriptions) and no output schema, the description's return-field list provides sufficient context for an agent to invoke it correctly and interpret the result. No additional side-effect or pagination constraints exist.

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 of id, lang, and compact, so the baseline is 3. The tool description does not add additional meaning beyond the schema; it only restates that id is a 'Vedic ID slug,' which is already in the schema.

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

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

The description uses a specific verb ('Get') and resource ('detailed information for a single rashi') and clearly indicates the lookup is by Vedic ID slug. This distinguishes it from sibling get_vedic_astrology_rashis (list) and other ID-based tools. The title and description align.

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

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

The phrase 'for a single rashi ... by its Vedic ID slug' provides clear context for when to use this tool—when a specific ID is known. It does not explicitly name alternatives or exclusions, but the singular scoping is clear. No when-not-to-use guidance is 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?

With no annotations, the description takes on the transparency burden. It discloses key behavior: it's a dictionary lookup, not chart-driven detection, and does not inspect a birth chart. It also states it returns id and name for all cataloged yogas. Minor gap: it doesn't describe ordering or pagination, but for a simple list 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 three sentences, front-loaded with the primary action and resource, then explains what it is not, and finishes with alternatives and use cases. Every sentence earns its place; no redundant or filler content.

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

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

For a simple list endpoint with 0 required parameters, the description is complete: it identifies the resource, return contents, key exclusions (no birth chart), alternatives, and use cases. The schema handles parameter details, and the sibling tools are explicitly referenced for expanded functionality.

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

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

The input schema already provides detailed descriptions for all 3 parameters (lang, family, compact), with 100% coverage. The tool description itself does not add extra parameter-level semantics beyond what the schema states, so the baseline 3 applies.

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

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

The description clearly states the tool's function: 'Browse the 301-entry Vedic planetary-yoga glossary' and 'Returns id and name for every cataloged yoga'. It names specific yoga types (Raja, Dhana, etc.) and explicitly distinguishes itself from the related GET /yoga/{id} and POST /yoga/detect endpoints, making its purpose unambiguous relative to siblings.

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

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

Provides explicit guidance on when to use this tool versus alternatives: 'Use GET /yoga/{id} for the full glossary entry, or POST /yoga/detect to run all 48 detection rules against a specific kundli.' It also clarifies that this tool is not for chart-driven detection and suggests ideal use cases ('yoga-browser UIs, search, and progressive data loading'), covering both when and when-not.

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

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

With no annotations, the description carries the burden. It discloses the static, non-mutating nature ('glossary lookup against the static catalog') and explicitly states what it does NOT do. It also describes the return content (formation conditions, life results, quality classification). While it doesn't mention auth or rate limits, for a simple read-only lookup this is adequate and useful.

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

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

Two tightly written sentences. First sentence states the core action and return value; second sentence clarifies the boundary and directs to alternatives. No filler or redundant 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 simple lookup tool with 3 documented parameters and no output schema, the description is complete. It tells the agent what to expect (formation conditions, life results, classification), what not to expect (no chart analysis), and where to go for chart-based detection. The sibling context and schema fill in remaining 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 coverage is 100%: all three parameters (id, lang, compact) have descriptions in the schema. The description adds no additional parameter semantics beyond framing the lookup, but the schema already provides full details. Baseline 3 is appropriate 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 'Look up the dictionary entry for a specific named yoga from the 301-entry Vedic planetary-yoga glossary' with specific verb+resource. It distinguishes itself from sibling tools by noting it is a glossary lookup and explicitly contrasting with chart-driven detection in POST /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 gives explicit usage guidance: 'This is a glossary lookup against the static catalog; it does NOT analyze a birth chart. For chart-driven present/absent verdicts... call POST /yoga/detect with birth data.' This clearly tells the agent when to use this tool versus the alternative, naming the sibling tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing the safety profile. The description goes further by detailing the output fields (bhava lord, count, sign, house from Lagna, exception flag, Upapada), which helps the agent understand what the tool actually returns 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 core explanation is informative and well-structured, but the final sentence 'Arudha Lagna calculator API, Jaimini pada, Upapada Lagna, Vedic astrology public image' reads as keyword stuffing and adds no practical value. This unnecessarily lengthens the description and reduces its overall 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?

Even without an output schema, the description enumerates the key returned fields and includes the Upapada, providing a solid understanding of the result. For a complex 9-parameter calculator, it is mostly complete, though it does not describe the exact JSON response shape or potential errors, leaving a small gap.

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

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

The input schema has 100% description coverage for all 9 parameters, so the schema already provides thorough meaning. The description's generic reference to 'birth details' does not add anything beyond the schema, warranting the baseline score 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 clear statement: 'Calculate the Arudha Lagna (AL) and all twelve Arudha padas of Jaimini astrology from birth details.' This uses a specific verb and resource, distinguishing it from all sibling astrology tools. It also explains the conceptual distinction between Lagna and Arudha Lagna, reinforcing its unique purpose.

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 use case is clearly implied—any request for Arudha padas or the Upapada should use this tool. The description provides context about what Arudha represents and what the output contains. However, it does not explicitly name alternative tools or state when not to use it, so it falls just 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently reveals what the tool returns—listing every output component (BAV, SAV with total 337, Reduced Ashtakavarga, Shodhya Pinda) and cites the specific chapters of BPHS used. This goes beyond a generic 'compute ashtakavarga' and gives the agent a clear expectation of the result structure. It does not mention limitations or prerequisites, but for a pure calculation tool 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 first two sentences are dense and valuable, packing output details and use cases. However, the trailing keyword string 'Ashtakavarga calculator API, bindu rekha points, Shodhya Pinda, Vedic astrology' is redundant SEO filler that adds no new information. This unnecessary padding lowers the conciseness from an otherwise efficient description.

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 Vedic astrology tool with no output schema, the description is quite complete: it enumerates all returned components (BAV, SAV, Reduced Ashtakavarga, Shodhya Pinda) and their derivation context (BPHS chapters). It also explains why the tool matters (transit, house strength, dasha evaluation, planetary strength comparison). This gives an agent enough understanding to select and invoke the tool appropriately without confusion.

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

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

The input schema covers 100% of parameters with rich descriptions including examples, caveats, and units (e.g., time format, ayanamsa types, timezone handling). Therefore, the description does not need to compensate; the baseline of 3 applies. The description adds no new parameter-specific detail beyond what the schema already provides.

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

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

The description clearly states the tool 'Calculate complete Ashtakavarga analysis' and identifies the specific resource (Ashtakavarga). It distinguishes itself from sibling tools by focusing on this niche astrological technique, listing precise outputs like BAV, SAV, Reduced Ashtakavarga, and Shodhya Pinda, and even references the authoritative text (BPHS chapters).

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

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

The description provides explicit use cases: 'Essential for transit prediction timing, house strength analysis, dasha result evaluation, and planetary strength comparison.' It does not explicitly mention alternatives or exclusion criteria, but given the unique nature of Ashtakavarga among siblings, this is sufficient context for when to invoke it.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: returns an aspect table grouped by planet, mutual aspects, and individual aspect details with orb calculation. This goes beyond the schema, though it omits any mention of error conditions or side effects (likely none for a calculation API).

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

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

The core description is efficient and front-loaded with the purpose and return contents. However, the trailing sentence 'Planetary aspects API, drishti calculator, vedic astrology aspects, graha drishti' adds keyword noise with no informational value, reducing conciseness slightly.

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

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

Given the absence of an output schema and annotations, the description adequately explains the tool's purpose, return sections, and use cases. It does not detail the exact response structure, but the enumeration of returned data is sufficient for a user to decide whether this tool meets their needs.

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

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

Schema description coverage is 100%, so the baseline is 3. The tool's description only reiterates 'a given time' and does not add parameter-level semantics beyond what the detailed schema already provides. The parameter names and descriptions in the schema fully cover semantics.

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

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

The description clearly states the tool calculates all planetary aspects (Drishti) for a given time, with a specific verb and resource. It enumerates return contents (full aspects, special aspects, aspect table, mutual aspects, individual details with orbs) and differentiates itself from siblings like lunar/monthly aspects 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 by stating it is 'essential for birth chart analysis, compatibility checking, and transit predictions.' However, it does not explicitly exclude alternatives or name sibling tools for when not to use it, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses key behaviors: the 22 aspect types, ternary search refinement to the minute, and the 'month in progress' default when year/month are omitted. It does not discuss potential output size, error behavior, or rate limits, but for a read-only calculation tool this is reasonably transparent.

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 includes useful details about aspect types and precision. However, the final sentence 'Monthly lunar aspects API, Moon transit calendar, chandra drishti ephemeris, minor lunar aspects' is keyword-stuffed and adds no functional value. The list of 22 aspects is informative but somewhat lengthy.

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

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

The tool has no output schema, yet the description only says 'Returns exact date and time of each Moon aspect event' without describing the response structure (e.g., fields per event, planet names, aspect type representation). It covers the tool's purpose and use cases well, but the missing output shape is a notable gap for a complex 6-parameter tool.

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

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

The input schema already provides descriptions for all 6 parameters, achieving 100% coverage. The main description adds little beyond reiterating that omitting year/month yields the current month, which is already implied by schema defaults. No additional parameter meaning or format details are provided 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 tracks lunar aspect events for a month, enumerates the 22 aspect types, and specifies it returns exact dates and times. It distinguishes itself from sibling tools like post_vedic_astrology_aspects (general aspects) and post_vedic_astrology_aspects_monthly by focusing specifically on Moon aspects (lunar).

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, stating it is essential for muhurta selection, daily panchang analysis, and chandra gochar predictions. It also explains how omitting year and month gives the month in progress, which is practical guidance. However, it does not explicitly contrast with alternative sibling tools, so it lacks a direct when-not-to-use statement.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It reveals key implementation details: 'uses degree-based aspect methodology on sidereal positions (Lahiri ayanamsa),' 'returns exact date and time of closest approach using ternary search refinement,' and the optionality of year/month. These go beyond the schema and give the agent meaningful insight into how the tool behaves, though it omits details like response structure or error conditions.

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

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

The description is well-structured and front-loaded with the core purpose, but it is longer than necessary. Listing all 17 minor aspects verbosely inflates length, and the final sentence ('Monthly planetary aspects API, graha drishti calendar, mutual aspect ephemeris, minor aspects.') reads as redundant keyword stuffing. Some sentences earn their place, but the description could be tighter without losing value.

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

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

Given the tool's complexity (6 params, many sibling tools, no output schema), the description does a reasonable job explaining purpose, alternatives, methodology, and defaults. However, it does not describe the response format beyond 'returns exact date and time of closest approach,' leaving the agent to infer the full structure of the returned data. With no output schema, this is a notable omission that keeps it from being fully complete.

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

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

The input schema has 100% description coverage for all six parameters, so the baseline is 3. The description adds marginal value by explaining the effect of omitting year/month (use case for a published calendar) and mentioning the sidereal coordinate system, but most parameter semantics are already fully described in the schema. No additional parameter details are needed to bridge a coverage gap.

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: 'Calculate all planetary aspect events (excluding Moon) for a given month.' It specifies the resource (planetary aspects), the scope (monthly), and distinguishes itself from siblings by explicitly excluding the Moon and pointing to the lunar endpoint. Listing the 22 aspect types further reinforces a precise and unambiguous purpose.

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: 'For Moon-specific aspects, use the /aspects/lunar endpoint,' which directly steers users away from an appropriate alternative. It also provides a concrete use case ('Essential for transit timing, muhurta selection, and monthly astrological forecasting') and explains the behavior of omitting year/month for a self-updating calendar. It does not explicitly contrast with the non-monthly 'aspects' sibling, leaving a minor 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 safety profile is covered. The description adds valuable behavioral details: the returned components (Bhavadhipati Bala, Bhava Digbala, Bhava Drishti Bala), output units (virupas/rupas), strength ranking, and the use of unequal Sripati mid-cusps so a house near a sign boundary is measured where it actually falls. No contradictions with annotations.

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

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

The main body efficiently front-loads purpose and key return values, but the trailing keyword dump ('Bhava Bala calculator API, house strength Vedic astrology, bhava bala virupas, Bhavadhipati Bala, Bhava Digbala, Sripati bhava madhya') is pure SEO noise that adds no agent value. This 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 there is no output schema, the description compensates by naming exactly what is returned: the three classical components, totals in virupas and rupas, and a strength ranking. It also explains the underlying house system and the conceptual relationship to Shadbala. While the exact response shape (e.g., array format) is not specified, the description provides enough context for correct invocation and interpretation.

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

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

Schema coverage is 100%, with each of the 10 parameters individually described in the input schema. The description itself does not add parameter-specific semantics beyond mentioning the methodology (e.g., Sripati mid-cusps), so it meets the baseline of 3 as the schema carries 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: 'Calculate Bhava Bala (house strength) for all twelve bhavas', and immediately cites authoritative sources (BPHS, BV Raman). It clearly distinguishes this tool from its sibling post_vedic_astrology_shadbala by stating 'Shadbala measures which graha is strong, Bhava Bala measures which life area is strong', 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 by explaining the difference between Shadbala and Bhava Bala and notes they are read together to separate a strong planet in a weak house from a weak planet in a strong one. This implies when to use this tool versus the shadbala sibling, though it stops short of explicit 'use this when' or 'do not use when' 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 already declare readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral context beyond this: it details the calculation method (Sripati bhava cusps), explains what the output contains (twelve bhava boundaries with madhyas and spans, every graha in both frames, moved flag), and describes the practical rationale. This goes far 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 opening sentence is clear and front-loaded, but the description includes a long explanatory paragraph that, while valuable, is followed by a string of SEO-style keywords ('Bhav Chalit API, Chalit Kundli calculator, bhava chalit chart, Sripati house cusps, cusp based house chart Vedic astrology') that add no value for an agent. This filler 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?

With no output schema, the description supplies a solid summary of the return data: twelve bhava boundaries, madhyas, spans, every graha in both frames, and a moved flag. It also explains the tool's purpose relative to the Rashi chart. It is complete enough for an agent to understand what to expect, though it doesn't enumerate every possible response field.

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 does not add any parameter-level guidance beyond the schema; it only refers to the chart calculation and output. The schema itself provides rich parameter documentation, so no deduction is made, but the description offers no extra 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 opens with 'Calculate the Bhav Chalit chart' — a specific verb plus resource — and immediately distinguishes it from the Rashi (D1) whole-sign chart. It clearly names the scope (unequal Sripati bhava cusps) and explains why this matters, separating it from sibling tools like birth_chart and bhava_bala.

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

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

The description gives clear context: 'practitioners check it before reading house results, house lordship strength or transit effects.' It contrasts with the Rashi chart and explains when the Chalit chart resolves boundary issues. It doesn't explicitly name alternative tool names, but the use cases are well implied.

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

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

With no annotations provided, the description carries full behavioral burden. It reveals output grouping behavior (by rashi, nakshatra, pada) and indicates accuracy, but does not discuss side effects, permissions, rate limits, or error behavior. As a POST compute tool with no obvious mutation, the lack of explicit safety notes is a moderate gap.

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 long, front-loaded with the action and primary resource. It includes useful keywords and use-case context without fluff. The 'Perfect for...' phrase is slightly promotional but serves to clarify intended scenarios, so it earns its place.

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

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

Despite 12 parameters and no output schema, the description provides a solid high-level picture of the tool's output (planets, nakshatra, pada, rashi grouping) and its role in a broader astrology software context. It does not detail the response structure, but the essential output dimensions are covered, making it sufficiently complete.

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

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

Schema description coverage is 100% and the schema itself is extremely detailed, with parameter-level descriptions, examples, defaults, and enums. The description adds no parameter-specific details 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 the specific verb 'Calculate' and names the exact resource: 'complete Vedic birth chart (Janam Kundli, natal chart)' with detailed contents (9 planetary positions plus Ascendant). It also specifies output structure (grouped by rashis with nakshatra and pada), making it clearly distinct from siblings like planetary_positions or navamsa.

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 useful context for when to use the tool ('kundli generation, horoscope matching, and Vedic astrology software integration') but does not explicitly mention alternatives or when-not-to-use. Given the large sibling list, naming a more basic option like planetary_positions for raw positions without grouping could have improved 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 this tool read-only and non-destructive. The description adds useful behavioral context: it explains that the tool supports two schemes which can produce different Atmakaraka, and that Rahu's degree is reversed in the eight-karaka scheme while Ketu is excluded. This goes beyond the annotations and helps predict output variability.

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 explanation is front-loaded and informative, but the final sentence is a keyword-stuffed string ('Atmakaraka calculator API, Darakaraka, Jaimini chara karaka, Vedic astrology soul significator') that adds no functional value for an AI agent. This makes the description longer than necessary.

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

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

For a tool with 10 parameters and no output schema, the description gives a strong conceptual overview, names all the resulting karaka offices, and explains the scheme difference. It doesn't specify exact response formatting, but the office naming and ranking logic give sufficient expectation for an agent.

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

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

The schema already provides 100% coverage of all parameters with detailed descriptions, so the description carries no additional parameter burden. The description's mention of schemes and ranking is conceptually related but not necessary for parameter understanding beyond what the schema already offers. Baseline 3 applies.

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

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

The description explicitly states 'Calculate the Chara Karakas of Jaimini astrology from birth details' with a specific verb and resource, and elaborates the ranking mechanism and resulting offices. This clearly distinguishes it from the many sibling Vedic astrology tools by focusing exclusively on karakas.

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 this tool: whenever Jaimini Chara Karakas are needed. It also gives within-tool guidance on choosing between the seven- and eight-karaka schemes based on the reference software. However, it does not explicitly name alternatives or exclusion criteria relative to 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?

No annotations are provided, so the description carries the full burden. It discloses what is returned: 36-point scale, per-koota breakdown, Nadi/Bhakoot dosha detection, cancellation analysis per Muhurta Martanda and BPHS rules, and a marriage recommendation. The verb 'Calculate' signals a non-mutating read operation, though it does not detail response shape or error behavior.

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

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

The description is two sentences, front-loaded with the core purpose and followed by a detailed output breakdown and use-case list. It is efficient, though 'accurate' adds little and the marketing tail could be trimmed.

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

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

Given no output schema and nested birth-data objects, the description gives sufficient high-level output detail (score, breakdown, dosha, recommendation) and use cases to orient an agent. It would benefit from describing top-level response fields, but it is not incomplete for a calculation tool of this complexity.

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

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

Schema coverage is 100%, and the schema already provides rich descriptions for person1, person2, ayanamsa, lang, and compact. The description adds little parameter-level meaning beyond the schema, so it earns the baseline 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 detailed Ashtakoot compatibility (Gun Milan) for kundli matching between two people.' It clearly names the exact output (36-point Guna Milan scale across 8 kootas) and distinguishes this tool from sibling dosha/panchang tools by focusing on pairwise compatibility.

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 use cases ('Perfect for kundli matching for marriage, matrimonial platforms, horoscope compatibility, and Vedic matchmaking services'), which tells an agent when to invoke it. It does not explicitly mention alternatives or when not to use it, so it falls just 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?

The description goes far beyond the annotations, detailing the gochara gate pipeline, sidereal frames (Lahiri vs KP-Newcomb), the reproducibility of the strength score with published arithmetic, and explicit statements about classical vs. convention. This provides valuable behavioral context without contradicting the readOnlyHint/destructiveHint 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 dense, run-on paragraph that front-loads the purpose but becomes unwieldy. It ends with a keyword-stuffed list ('Vedic daily horoscope API, gochara API, daily panchang prediction...') that does not serve an AI agent. While rich in content, it is not concise and contains fluff that should be removed.

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

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

With no output schema, the description carries the burden of explaining what the tool returns. It enumerates the major components (gochara, panchanga, tarabala, chandrabala, Vimshottari chain, KP finance) and the strength score, which is sufficient for selecting the tool. However, it lacks a concrete response structure or field-level detail, leaving some uncertainty about the returned shape.

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

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

With 100% schema coverage and detailed per-parameter descriptions in the input schema, the description only needs to add contextual meaning. It ties parameters to the native and the composed reading but doesn't add essential per-parameter semantics beyond what the schema already conveys. Baseline 3 applies.

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

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

The description clearly states the tool's function as a composed Vedic daily reading for one native on one date, combining gochara, panchanga, dasha, tarabala, chandrabala, and KP finance. It explicitly distinguishes from sibling tools by emphasizing 'one call' and 'composed,' and contrasts with a chart bar ('rather than a bar of a 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 conveys when to use the tool: for a holistic daily reading of one native. It provides context that this replaces separate calls for gochara, panchanga, dasha, etc., but it does not explicitly name alternative sibling endpoints or state exclusions like 'for just gochara use transit endpoint.' The 'focus' parameter adds finance-specific usage guidance but not in the main description.

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

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

With no annotations provided, the description carries the full burden. It discloses the return shape ('dasha timeline with start/end dates for every level'), the optional 'significators' behavior, and the ayanamsa dependency. It does not discuss authentication or rate limits, but for a calculation API the disclosed behavior is substantial and non-contradictory.

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 function and includes useful details about levels, timeline, and optional significators. It contains some marketing filler ('Accurate dasha calculator API', 'Essential for understanding') but is still compact and organized for a tool of this 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 12 parameters, no output schema, and no annotations, the description covers the essential aspects: what it calculates, the returned timeline, optional significators, the nakshatra basis, and ayanamsa choices. It could more explicitly contrast with sibling dasha endpoints, but the specificity of 'all five running levels' provides enough orientation.

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 references 'significators true' and 'selectable Lahiri or KP ayanamsa', but the input schema already documents these parameters in detail. The description adds little beyond what the schema provides for parameter meaning.

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

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

The description opens with a specific verb and resource: 'Calculate all five running Vimshottari Dasha levels' and explicitly lists Mahadasha, Antardasha, Pratyantardasha, Sookshma, Prana. This clearly distinguishes it from sibling dasha tools like post_vedic_astrology_dasha_major or sub_mahadasha variants. The title also reinforces the exact scope.

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

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

The description gives clear context and use cases: 'life phase prediction', 'current DBA readout', 'timing events in Vedic astrology'. It implies this tool is for current running periods, contrasting with sibling dasha endpoints. However, it never explicitly names alternatives or states when not to use this tool, so it falls short of a 5.

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

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

Annotations are absent, and the description only restates the basic output (complete cycle, all major periods). It does not disclose specifics like response structure, whether accurate birth time is critical, or any limitations. With no annotations, the agent remains under-informed.

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

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

Two concise sentences, front-loaded with the key behavior; no filler or redundant information. Every word earns its place.

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

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

The tool has 12 parameters and no output schema, but the description conveys essential scope. However, it omits details about the returned data (e.g., period lords, start/end dates) and does not leverage sibling differentiation. Adequate but not rich.

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

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

Schema coverage is 100% and each parameter schema description is detailed. The tool description itself adds no parameter-level meaning, but the baseline of 3 applies when schema fully covers parameters.

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

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

Title and description clearly identify the tool as returning the complete Vimshottari Dasha cycle of all 9 Mahadasha periods spanning 120 years, distinguishing it from siblings like dasha_current or sub_mahadasha.

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?

Description explains scope (full cycle from birth to 120 years) but does not explicitly state when to prefer this over dasha_current or sub_mahadasha, nor mention any exclusions. Differentiation is implicit from the title rather than explicit guidance.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only states that it returns 9 proportional sub-periods, without describing the returned fields, dependencies on ayanamsa, or any side effects. This is minimal for a computation tool that requires 13 parameters.

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 extremely concise: two sentences with no waste. The first sentence front-loads the core return value. It is slightly under-specified, but every word earns its place in a minimal way.

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

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

Given no output schema and a complex astrological domain, the description is too skeletal. It doesn't explain what fields each Antardasha contains (e.g., start/end dates, planet), what 'proportional' means exactly, or how deeper levels like antardasha-of-antardasha are handled. This is inadequate for a tool with 13 parameters and no response schema.

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

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

Schema description coverage is 100%, so the schema already thoroughly documents all parameters. The tool description adds no parameter-level meaning beyond the schema. Baseline of 3 is appropriate because the description neither harms nor enriches parameter understanding.

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

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

The description clearly states 'Returns 9 Antardasha sub-periods within a Mahadasha' with a specific verb and resource. It distinguishes from siblings by naming the exact subdivision level. However, it does not explicitly contrast with sibling tools like dasha_current or dasha_major, so it's not a 5.

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

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

No when-to-use guidance is provided. With 30+ sibling Vedic astrology tools, the description does not help an agent choose between this tool and alternatives like get_vedic_astrology_dasha_major or get_vedic_astrology_dasha_current. It only states what the tool returns, not when to invoke it.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It frames the tool as a 'calculator API' (implying read-only computation), states exactly what it returns (9 periods), and adds algorithmic context ('Each period is proportional to the Vimshottari years of its lord'). It does not discuss error cases or details like ayanamsa sensitivity, but the core behavior is transparent.

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 long, immediately front-loaded with the tool's purpose ('Pratyantardasha calculator API'), and every sentence adds value: what it returns, when to use it, and how periods are calculated. No filler or repetition of schema details.

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

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

The tool has 14 parameters, no output schema, and no annotations, so the description must compensate. It clearly explains purpose and use cases, but does not describe the return structure (e.g., start/end dates, lord names per period), which is a significant gap given no output schema exists. The input schema is rich and covers parameters, but the response shape remains unspecified.

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 does not add parameter-level meaning beyond what the schema already provides; it mentions 'chosen Antardasha' and 'Mahadasha' but these are already fully enumerated in the schema. No additional parameter semantics are contributed.

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 ('Returns') and resource ('the 9 Pratyantardasha periods'), and clearly identifies the tool's place in the Vimshottari hierarchy as 'the third level'. It distinguishes from sibling dasha tools by name and by level ('inside a chosen 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 explicitly states the intended use: 'drill from a Mahadasha into month level timing for event prediction, muhurta selection, and dasha timeline UIs.' It provides clear context and use cases, but does not explicitly mention when not to use it or name alternatives (e.g., deeper sookshma levels), so it lacks 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?

No annotations are provided, so the description carries the full burden for behavior disclosure. It discloses the result count (9 periods), typical duration (3-30 days), and position in the Vimshottari hierarchy, but does not describe response structure, error behavior, or operational constraints. Adequate but not rich.

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

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

Four short sentences, front-loaded with the API name and core function. Each sentence adds value: result, hierarchy level, typical duration, and use cases. No redundancy or wasted words.

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

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

Given 15 parameters, no annotations, and no output schema, the description plus the rich schema parameter descriptions are sufficient for selecting and invoking the tool. It gives clear purpose and use cases, though it could mention output fields since no output schema exists.

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 a baseline of 3 applies. The description adds context about the chosen Pratyantardasha and the nine periods but provides no additional parameter syntax or usage details beyond the well-documented schema.

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

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

The description clearly states the tool returns the 9 Sookshma periods inside a chosen Pratyantardasha, the fourth level of the Vimshottari dasha hierarchy. This specific verb+resource+scope distinguishes it from sibling dasha tools that cover Mahadasha or Antardasha 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 states it is built for dasha drill down tables, current DBA readouts, and precise event timing, giving clear use context. It does not explicitly contrast with higher-level dasha siblings, but the naming and hierarchy reference make the intended use 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 read-only nature is known. The description adds valuable context beyond annotations, including the number of periods returned (9), the typical duration range (20 minutes to 4 days), and its position in the Vimshottari hierarchy, which helps set expectations about the output.

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 the first sentence immediately stating the core purpose. Each subsequent sentence adds non-redundant context (hierarchy position, duration range, use cases). There is no fluff or unnecessary repetition.

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

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

Despite having 16 parameters and no output schema, the description adequately communicates the tool's role and output concept. The exhaustive schema descriptions cover parameter details. The description could optionally mention the response shape (e.g., start and end dates for each period), but it is not essential given the schema's richness.

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

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

Schema description coverage is 100%, with each of the 16 parameters already having a detailed description. The tool description does not add parameter-specific semantics beyond what the schema provides; baseline 3 is appropriate because the schema carries 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 function: 'Returns the 9 Prana periods inside a chosen Sookshma dasha, the fifth and finest level of the Vimshottari dasha hierarchy.' It also names the specific hierarchy level (Prana) and distinguishes it from sibling dasha tools by emphasizing it completes the drill-down to hour-level timing.

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 use cases: 'Built for five column dasha drill down tables, muhurta selection, and pinpointing the trigger moment inside an event window already found at the Sookshma level.' This implies the tool should be used after the Sookshma level is already determined, but it does not explicitly name alternatives or state when not to use it.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context (based on the BPHS Shodasha Varga system and detection of Vargottama planets) but does not disclose output structure, edge cases, or limitations such as how the returned chart is formatted or whether certain inputs produce unreliable results.

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 four sentences long, front-loading the main verb and scope in the first sentence. The long enumeration of divisions is dense but purposeful, though it prevents the description from being as lean as the best two-sentence examples.

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 tool with no output schema and no annotations, the description covers conceptual purpose and a key output feature (Vargottama detection) but does not explain return format or when results might be inaccurate. The schema carries a lot of the burden, making this adequate but not fully complete.

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

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

The input schema has 100% parameter coverage with detailed descriptions, including the `division` parameter listing all 15 supported values and their meanings. The tool description adds no new parameter-level information beyond repeating this division-to-life-area mapping; the only extra detail (Vargottama detection) is an output feature, not a parameter semantic.

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

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

The description starts with 'Calculate any Vedic divisional chart (Varga) from D2 Hora to D60 Shashtiamsa,' which clearly states a specific verb and resource scope. It distinguishes itself from siblings like `post_vedic_astrology_navamsa` by covering all 15 supported divisions, not a single 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 clear usage context by mapping each division to a life area (e.g., 'wealth (D2), siblings (D3), property (D4)'), telling users which division to request for a given concern. However, it does not explicitly mention when to use this tool over alternative sibling tools such as the dedicated Navamsa endpoint, 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It discloses the detection logic, the 12 types, and that it returns severity and effects. However, it does not describe the response structure, error behavior, or any input constraints beyond the schema. The core calculation behavior is clear, but some gaps remain, justifying a mid-range score.

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 remains structured across five sentences. However, phrases like 'Accurate kalsarpa dosha calculator' and 'Considered significant dosha affecting life obstacles' are somewhat promotional and add only marginal value. It is concise enough but not perfectly economical.

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's complexity (12 subtypes, multiple inputs) and the absence of an output schema, the description does a reasonable job by covering the detection condition, the subtype identification, and the return of severity/effects. It does not describe the full output structure, but for a dosha calculator this level of detail is largely sufficient for an agent to select and call the tool correctly.

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

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

Schema description coverage is 100%, so the input schema already documents all 9 parameters in detail. The tool description adds no parameter-specific information beyond what the schema provides. Per the calibration rubric, with high schema coverage a baseline of 3 is appropriate, and there is no extra semantic value to raise the score.

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: 'Detect Kalsarpa dosha (Kalsarpa yoga) when all 7 planets are hemmed between Rahu-Ketu axis.' It clearly distinguishes from sibling dosha tools (manglik, sadhesati) by naming the exact condition, the 12 subtypes, and the key output (severity/effects based on Rahu house). This fully differentiates it from other Vedic astrology endpoints.

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

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

The description provides clear context for when to use: 'Essential for Vedic astrology dosha analysis, birth chart evaluation, and matrimonial compatibility.' It implies use for Kalsarpa-specific assessments but does not explicitly contrast with alternatives or state when not to use it. This is clear context without exclusions, matching a 4.

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

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

With no annotations, the description carries the full burden. It discloses key behavioral traits: returns severity levels (Mild/Moderate/Severe), includes cancellation factors, and accounts for exceptions that reduce dosha effects. It also states the underlying logic (Mars in houses 1,2,4,7,8,12 from Lagna), which is valuable context beyond the schema.

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

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

The description is four sentences and front-loaded with the primary purpose. It is efficient but contains some redundancy (e.g., repeated 'matrimonial' references). Overall it earns a 4 for being structured and to the point without wasting words.

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

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

Given no output schema, the description sufficiently communicates the return value ('severity levels', 'cancellation factors', 'exceptions'). It also conveys the tool's role within a broader set of Vedic astrology tools. It doesn't detail the full response structure, but it's adequate for selection and invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter-level semantics—it mentions Lagna and Mars position, but the schema already thoroughly explains date/time/location importance. No extra value 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 description clearly specifies the verb ('Detect') and the resource ('Manglik dosha' based on Mars position in specific houses from Lagna). It distinguishes this from sibling dosha tools (e.g., kalsarpa, sadhesati) by naming the exact dosha type and its astrological basis.

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

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

The description provides clear context for when to use this tool ('matrimonial compatibility checks', 'kundli matching for marriage', 'matrimonial sites'). However, it doesn't explicitly name alternatives or state when *not* to use it, stopping short of full exclusion 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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It does disclose that the tool 'Returns Saturn transit dates and effects on life' and identifies phases (Rising/Peak/Setting), which gives some indication of output. However, it lacks details on potential limitations, prerequisites beyond required parameters, or the nature of 'effects on life,' leaving the response structure largely unspecified.

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 a clear opening sentence, but it contains redundancy. Phrases like 'Accurate sade sati calculator' and 'Shani sadhesati 7.5 year period tracker' largely restate the first sentence, and two consecutive sentences ('Essential for...' and 'Important for...') convey similar usage guidance. A more concise version would remove this duplication, though it is not overly long.

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 gives a high-level overview of what the tool computes and returns, but with no output schema, it should provide more detail about the response shape, phases, and effects. It does not mention possible error conditions, interpretation guidance, or how the 'effects on life' are represented. Given the tool's complexity (9 parameters, no output schema), the description is adequate but not complete.

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

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

The input schema provides 100% parameter descriptions with examples, so per the baseline, a score of 3 is appropriate. The description does not add any additional parameter semantics beyond the schema—it never mentions date, time, latitude, longitude, or other parameters directly. Thus, it neither enhances nor detracts from the schema's coverage.

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

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

The description clearly states the tool's function: 'Calculate Sadhesati (Sade Sati) periods when Saturn transits 12th, 1st, and 2nd houses from natal Moon.' It also specifies the deliverable (current status, phase identification, transit dates, and effects) and differentiates from sibling tools like general transit or other dosha calculators by focusing specifically on Sadhesati/Sade Sati and Saturn's transit relative to the natal Moon.

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: 'Essential for Saturn transit analysis, sadhesati remedies timing, and understanding challenging Saturn periods in Vedic astrology. Important for timing major life decisions.' It implies appropriate scenarios but does not explicitly mention alternatives or when not to use this tool, such as comparing with general transit tools or other dosha calculators.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explains the astronomical meaning of ascending/descending nodes, the restriction to visible planets, and the return fields. While it does not explicitly state read-only behavior, the 'Find' verb and explanatory detail are 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 core description is a clear paragraph that front-loads the purpose. However, the trailing keyword list ('Ecliptic crossing API, planetary node crossing, ascending descending node ephemeris') is redundant and doesn't add value, reducing overall 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?

Since there is no output schema, the description appropriately lists return fields. It covers the core concept and scope, but does not specify the response structure (e.g., array vs. object), pagination, or error cases, leaving gaps given the absence of annotations and output schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema for compact, timezone, or coordinateSystem; it only reinforces 'year' with 'during a given year.'

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 'Find all ecliptic plane crossings for visible planets during a given year,' clearly specifying the action (find), resource (ecliptic crossings), and scope (visible planets, year). It also defines ecliptic crossings, making it distinct from sibling tools like parallels or 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 by explaining what qualifies as a crossing and the frequency (Moon crosses ~2 times per month, outer planets less frequently). It implies when to use this tool, but does not explicitly name alternatives or conditions for non-use.

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

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

The description adds substantial behavioral context that is not in the annotations: it explains the output ('Returns whether each graha currently clears the solar glare, its separation from the Sun in classical degrees of time, and the dates its visibility last changed and next changes'), the deliberate absence of a time field ('heliacal visibility is a once-a-day verdict read at that day sunrise or sunset'), and the latitude restriction with the reasoning that beyond 60 degrees the rule breaks down. This goes beyond the simple readOnly/destructive 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 first sentences are front-loaded with purpose and outputs, which is good. However, the description ends with a keyword-stuffed line: 'Graha asta API, Guru Asta Shukra Asta dates, heliacal rising calculator, planetary combustion muhurta.' This adds no informational value for an AI agent and makes the description feel padded. Overall it is reasonably concise but not 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?

Despite having no output schema, the description provides a complete mental model of what the tool computes, its key outputs, the rule used, the location-awareness distinction, and the practical muhurta use case. It also explains the latitude constraint and the no-time-field design decision. For a complex astronomical tool, this is sufficient for an agent to select and invoke it without ambiguity.

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

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

Schema coverage is 100% with detailed descriptions for every parameter, so the baseline is 3. The description adds extra semantic value by explaining why there is no time field (parameter 'date' is a daily verdict), why latitude is restricted (parameter 'latitude' affects ecliptic-horizon angle), and why timezone matters. This pushes the score above baseline, though the schema itself remains the primary source.

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 ('Calculate') and clearly defines the resource ('heliacal rising (udaya) and setting (asta) of the six visible grahas'), including the governing rule ('Surya Siddhanta rule'). It differentiates itself from a birth chart combustion flag by emphasizing location awareness, making the purpose distinct from sibling tools.

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

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

The description provides clear context for when to use the tool: 'the calculation behind Guru Asta and Shukra Asta, the periods classical muhurta withholds marriage and other auspicious ceremonies.' It also gives an explicit when-not: 'Unlike a birth chart combustion flag it is location aware', which tells the agent this should be used instead of a generic combustion flag for location-dependent visibility. However, it does not name a specific alternative sibling tool by name, 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?

With no annotations, the description carries the full transparency burden. It discloses the calculation methods (Placidus house cusps, star/sub-lord logic, dynamic KP-Newcomb ayanamsa) and the complete return list, giving an agent a clear picture of the operation. It does not mention error handling, authentication, or side effects, but for a chart-generation POST tool these are unlikely to be concerns.

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 appropriately front-loaded and concise, stating what the tool does and returns. The final 'SEO:' keyword list is extraneous for an AI agent and does not earn its place, adding noise without useful guidance. This 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?

For an 11-parameter tool with no output schema, the description adequately inventories the returned data (planets, cusps, sub-lords, horary numbers) and supported options. It does not describe the output shape or mention the 'compact' parameter, but the schema covers those details, making the description sufficient for agent selection and invocation.

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

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

The input schema covers 100% of the 11 parameters with detailed explanations and examples, so the description adds little beyond naming ayanamsa options and horary numbers. The baseline of 3 applies because the schema does the heavy lifting; the description does not enrich parameter understanding in a meaningful way.

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 ('Generate') and resource ('Krishnamurti Paddhati birth charts'), then enumerates the exact output components (9 planets, Ascendant, 12 Placidus cusps, star-lords, sub-lords, horary numbers). This clearly distinguishes it from sibling tools like kp_cusps or kp_planets, which focus on individual 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 states ideal contexts ('Perfect for KP astrology software, horary prediction apps, and event timing analysis') and implicitly positions itself as the complete-chart option. However, it does not explicitly name sibling alternatives or state when NOT to use it (e.g., for single cusp or planet queries), relying on the agent to infer from the tool name and sibling list.

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

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

With no annotations provided, the description carries the full transparency burden. It does disclose the calculation type ('unequal Placidus'), ayanamsa options, and output scope, but it does not explicitly state whether the operation is read-only/side-effect-free, nor does it mention edge cases like high-latitude Placidus issues or the need for ayanamsaValue when selecting 'custom' ayanamsa.

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 four sentences are concise and informative, but the final 'SEO:' line is keyword spam that does not help an AI agent and does not earn its place. Structure is otherwise front-loaded with the core purpose.

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

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

Given the absence of an output schema, the description does a good job stating what is returned ('all 12 house cusps with KP sub-division details' and the three lord types). It also mentions applicable ayanamsa modes and use cases. It does not discuss the 'focus' parameter's effect on house themes or the 'compact' response option, but those are fully explained in the schema, so overall completeness for tool selection is strong.

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 per the rubric the baseline is 3. The description adds marginal value by referencing 'Dynamic KP-Newcomb or custom ayanamsa support,' which ties to the ayanamsa and ayanamsaValue parameters, but it does not meaningfully elaborate on parameter formats or relationships beyond what the schema already provides.

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

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

The description opens with a specific verb-plus-resource statement: 'Calculate unequal Placidus house cusps with ruling sign-lord, nakshatra-lord, and sub-lord for each cusp.' It also states exactly what is returned ('all 12 house cusps'), clearly distinguishing this KP cusp tool from sibling KP tools focused on planets, charts, or ruling planets.

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 three explicit use cases: 'KP horary astrology, cusp sub-lord analysis, and birth chart rectification.' It does not, however, provide explicit 'when-not-to-use' guidance or name alternative tools, so it falls just 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 provide readOnlyHint: true and destructiveHint: false, so the safety profile is covered. The description goes beyond by explaining the internal logic (number maps to 249 sub divisions, sets Ascendant, Placidus cusps from latitude, real planetary positions) and enumerates the return fields, adding valuable behavioral context.

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

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

The description is front-loaded with the main purpose and method, but it ends with a string of repetitive SEO keywords ('KP horary API, Prashna kundali calculator, 249 horary number chart...') that add no decision-making value for an agent. This trailing noise should be removed, making the rest reasonably concise.

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 12-parameter tool with no output schema, the description covers the what, how, and returns at a high level, listing Ascendant, cusps, grahas, ruling planets, and significators. It leaves some advanced concepts (e.g., four-level significators) undefined, but overall it is sufficiently complete for an agent to understand the tool's function.

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 highly detailed parameter descriptions, including an explanation of the horary number and why birth details are excluded. The description adds little beyond summarizing the role of number/moment/place, 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 clearly states the tool casts a Krishnamurti Paddhati horary chart from a number 1-249 plus question moment and place. It explicitly distinguishes itself from sibling KP tools by emphasizing 'NO BIRTH DETAILS ARE NEEDED', making it unmistakable which tool to choose.

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 a clear when-to-use condition: horary is the KP answer when birth time is unknown or unreliable. It does not explicitly name alternative tools, but this context strongly implies the appropriate use case relative to natal chart tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly says 'Get' and 'Returns', implying a read-only computational operation, and specifies the return content. However, it does not cover error behavior, auth, or rate limits, which are not disclosed anywhere else.

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

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

The description front-loads the core purpose and output in two sentences, but then appends a string of SEO keywords ('KP planet positions API, star lord sub lord calculator, KP significator API, Krishnamurti Paddhati planets') that add no value for an AI agent. This noise reduces overall 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?

There is no output schema, so the description must explain return values. It does list key outputs (nakshatra, star-lord, sub-lord, KP horary numbers) but omits explicit mention of actual degree/longitude positions and does not state that it requires date/time/location, though those are covered by the schema. Overall sufficient for a computational tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level meaning beyond what the schema already provides; it only references outputs, not inputs. No compensation is needed given the high schema coverage.

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

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

The description clearly states 'Get planetary positions' with detailed KP star-lord and sub-lord calculations and enumerates exact outputs (all 9 planets, nakshatra, star-lord, sub-lord, KP horary numbers). This distinguishes it from generic planetary position tools and other KP-specific tools like kp_cusps or kp_horary.

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 identifies use cases ('precise event timing and significator analysis', 'Essential for KP astrology software') but does not explicitly differentiate from sibling KP tools or state when not to use it. Context is implied, but no alternatives or exclusions are mentioned.

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

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

With no annotations, the description carried the full burden. It discloses the output structure, the planet list, the 7-day maximum range, and the 15-minute to 24-hour interval limits. It omits rate limits or error behavior, but for a pure calculation tool these are not critical, and the disclosed constraints are useful beyond the schema.

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

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

The description is three sentences with no fluff: the first states what it does, the second lists returns, and the third provides use cases and constraints. Every sentence earns its place and the key information is front-loaded.

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

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

For a tool with 9 parameters and no output schema, the description covers the essential return fields, planet set, KP hierarchy, and time/interval limits. It does not explain KP-specific jargon or timezone handling, but those are already detailed in the input schema. Overall it gives a complete high-level picture for 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 descriptions cover 100% of the 9 parameters, so the baseline is 3. The tool description only restates interval bounds that already exist in the schema ('15-minute to 24-hour intervals') and adds no new parameter-level meaning. It does not compensate for any schema gaps because there are none.

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 'Calculate positions of all 9 planets... at regular time intervals' and lists specific return fields (longitude, zodiac sign, nakshatra, sublord, sub-sublord, KP number). This clearly distinguishes it from sibling tools like post_vedic_astrology_kp_planets (single snapshot), making its 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 provides explicit use cases: 'Ideal for tracking planetary motion, finding optimal muhurta windows, analyzing transit patterns, and building KP ephemeris tables.' It does not name alternative tools or state when not to use it, but the interval-specific context is clear from the title and body.

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

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

With no annotations, the description carries full behavioral burden. It states that the tool 'returns exact times when planets cross sign boundaries,' which is a clear behavioral claim. However, it does not disclose the structure of the return value, whether the operation is read-only, or how timezone/ayanamsa parameters affect the output. The description is not misleading but leaves significant behavioral gaps.

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

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

The description is three sentences, front-loaded with the core function in the first sentence. The second sentence ('Essential for...') is somewhat promotional and overlaps with the third sentence's use cases, but overall it is relatively concise and well-structured. There is minor redundancy around 'ingress timestamps' and 'returns exact times.'

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

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

The tool has 7 parameters and no output schema, so the description needs to explain what the result looks like. It says 'Returns exact times when planets cross sign boundaries,' which gives a general idea, but it does not specify whether the result is a list of events, what fields are present (planet, time, sign), or how parameters like ayanamsa and timezone shape the output. This is a notable gap for a tool without an output 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 parameter descriptions for all 7 parameters, so the baseline is 3. The tool description adds contextual hints like 'Sun sankranti dates' and 'Moon sign changes' that indirectly inform which planet values to use, but it does not provide per-parameter semantic enrichment beyond the schema. It neither adds nor detracts significantly.

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 'Track when planets enter new zodiac signs (rasi) with precise ingress timestamps,' which uses a specific verb ('track') and resource ('zodiac signs') and clearly distinguishes from siblings like kp_sublord_changes by focusing on rasi ingress times. It also specifies the output ('exact times when planets cross sign boundaries').

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

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

The description provides explicit use cases: 'tracking Sun sankranti dates, Moon sign changes for panchang, or outer planet transits for yearly predictions.' It gives clear context for when to use the tool but does not mention alternatives or when not to use it, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden. It discloses the exact return values (Day Lord, Moon Sign/Star/Sub Lord, Lagna Sign/Star/Sub Lord) and the optional behavior when birth data is provided (significators showing which houses each ruling planet signifies). It does not mention side effects or error cases, but for a calculation tool that primarily returns data, this is adequately transparent.

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 primary purpose, and every clause earns its place. It avoids redundancy and clearly separates the core function from the optional feature without wasting tokens.

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

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

For a tool with 10 parameters, 2 required, no output schema, this description is fairly complete: it lists the output components, explains the optional significator use case, and provides enough domain context. It does not elaborate on every parameter, but the schema covers those details, so the description's brevity is acceptable. It could benefit from a brief mention of how it differs from the interval variant, but that is already implied by 'at any moment'.

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 mentions birthDate and birthTime as the optional pair for significators, but this information is already present in the schema (birthTime states 'Required if birthDate is provided'). The description adds no new semantic information beyond the schema for any other parameters, so it just meets 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 uses a specific verb ('Calculate'), names the exact resource ('5 ruling planets'), and provides context ('at any moment using Krishnamurti Paddhati horary astrology'). It also distinguishes itself from the interval sibling by emphasizing 'at any moment' and from other KP tools by listing the exact return components (Day Lord, Moon Sign/Star/Sub Lord, Lagna Sign/Star/Sub Lord).

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 KP horary astrology and 'essential for KP prediction', and explains when to use the optional birth data (to include significators). It does not explicitly name alternative sibling tools or state exclusions, but the 'at any moment' phrasing implicitly distinguishes it from the interval variant, and the optional significator feature is clearly contextualized.

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

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

With no annotations, the description carries the full burden. It discloses the algorithm (4-level KP hierarchy), the house system (Placidus), and the set of returned values (Day Lord, sign/star/sub/sub-sub lords, unique ruling planets). It could go further on response shape, but this is strong for a calculation tool.

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 given the complexity: five sentences, all carrying distinct information, with the core purpose front-loaded in the first sentence and no filler.

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

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

With 11 parameters and no output schema, the description does well to list returned fields and use cases. It could mention the per-interval output structure, but the schema covers parameters fully, making the description largely 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 coverage is 100%, so the baseline is 3. The description adds context about the interval-based calculation and reinforces the no-birth-data requirement, but does not elaborate on individual parameters beyond the schema.

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

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

The description opens with a specific verb phrase ('Calculate ruling planets and their KP significators at regular time intervals') and names the method (Krishnamurti Paddhati prashna astrology). It clearly distinguishes itself from sibling single-time KP tools by emphasizing 'regular time intervals' and 'for each interval'.

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

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

Explicitly lists use cases ('birth time rectification, muhurta selection, and KP horary number analysis') and clarifies a key condition ('No birth data needed'). It does not explicitly name alternatives or state when not to use, 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?

No annotations are provided, so the description must carry the behavioral disclosure burden. It does so by stating the output (exact timestamps), the scope (planets Sun through Saturn, excluding Rahu/Ketu), and generality (any date range). This is meaningful behavioral information, though it does not cover edge cases like result size or timezone handling (which are in the schema).

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

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

The description is three focused sentences, front-loaded with the core action and output. There is no redundant or filler text; every sentence adds value.

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

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

Without an output schema, the description explains the return type ('exact timestamps') and the purpose. With 7 parameters, the rich parameter descriptions in the schema carry the load, and the description gives enough high-level context for the agent to understand what the tool accomplishes. It does not provide the full output structure, but that is acceptable given the tool's scope.

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

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

The input schema has 100% description coverage for all 7 parameters, so the baseline is 3. The description adds little beyond schema content: it repeats the planet list and mentions 'any date range', but provides no deeper parameter-specific meaning. No compensation is needed.

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

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

The description clearly defines the tool's function with a specific verb and resource: 'Track when planets cross KP sublord boundaries (1-249 divisions)' and 'Returns exact timestamps when a planet transitions between sublords'. This is precise enough to distinguish it from sibling tools like kp_rasi_changes or kp_planets_interval.

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: 'essential for prashna kundali analysis and dasha predictions' and 'Use this to find favorable windows when benefic sublords are active'. It does not explicitly name alternatives or exclusion criteria, but the context is sufficient for an agent to decide when to invoke this tool.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose operational behavior such as read-only nature, response format, or any side effects. Phrases like 'reveals planetary strength' are promotional rather than factual. The mention of Vargottama detection is a feature but not a 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 verbose and repetitive, cycling through nearly synonymous phrases: 'marriage compatibility analysis', 'spouse prediction', 'marital harmony analysis', and 'matrimonial matching'. Key information could be conveyed in one or two concise sentences. The first sentence is useful, but subsequent sentences inflate length without adding value.

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

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

With no output schema, the description should explain what the response contains. It only vaguely mentions 'planetary strength in married life' and Vargottama detection, lacking a concrete list of returned fields. It also does not reference the required inputs (date, time, latitude, longitude) despite them being critical. Overall, the description under-specifies the tool's behavior and outputs.

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

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

The schema provides 100% coverage with detailed descriptions for all 9 parameters, including examples and formatting notes. The tool description itself adds no parameter-specific guidance beyond what the schema already offers, 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 the Navamsa (D9) divisional chart with a specific scope: marriage compatibility, spouse prediction, and spiritual life assessment. It also mentions detecting Vargottama planets, further specifying functionality. However, it does not explicitly differentiate from the sibling tool post_vedic_astrology_divisional_chart, which may also handle D9.

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 a use case by stating it is 'Essential for matrimonial matching, relationship prediction, and marital harmony analysis.' This gives context but provides no explicit alternatives, exclusions, or when to avoid this tool. It is more promotional than prescriptive.

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?

No annotations are provided, so the description carries the transparency burden. It adds useful behavioral details such as 'Shukla/Krishna paksha' and 'ruling planet,' but it does not disclose output structure, error behavior, or clarify the 'nakshatra today' phrasing against the 'any date' claim.

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

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

The first sentence is strong and front-loaded, but later sentences repeat Tithi and Nakshatra with only minor additions (paksha, ruling planet). The final sentence also repeats 'muhurta' from an earlier sentence, making the description somewhat redundant.

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

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

There is no output schema, but the description lists all four returned elements plus paksha and ruling planet, and explains key use cases. It is complete enough for a basic calculator, though it does not mention the output structure explicitly.

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

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

The input schema already documents all 7 parameters in detail, achieving 100% description coverage. The description adds only high-level context like 'for any date' and does not need to repeat parameter details.

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

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

The description opens with a precise action: 'Calculate Panchang elements (Hindu calendar) for any date' and explicitly lists Tithi, Nakshatra, Yoga, and Karana. This clearly distinguishes the tool from sibling panchang tools like hora or choghadiya.

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 contexts: 'determining auspicious timings (muhurta), festival dates, and planetary influences' and 'Essential for Hindu calendar integration, muhurta selection, and Vedic timekeeping.' It does not explicitly name alternative sibling tools, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool divides day and night into 8 equal periods, names each period with its ruling planet and auspiciousness (e.g., 'Udveg (Sun, bad), Amrit (Moon, good)'), which gives a strong sense of the calculation logic. It does not mention output format or error conditions, but the core behavior is transparent.

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 a clear opening sentence and provides useful conceptual detail. However, the final sentence 'Choghadiya calculator API, daily muhurat timings, auspicious time finder' is keyword-stuffed and redundant, and the full enumeration of eight periods could be trimmed. It is not as lean as it could be.

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

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

There is no output schema, so the description should explain what the response will contain. It mentions 'timings' and the period division, but it does not describe the output structure (e.g., day/night sections, each period's start/end time). This is adequate but incomplete for a tool with notable complexity and 5 parameters.

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

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

The schema already has 100% description coverage for all 5 parameters, including detailed explanations for date, latitude, longitude, timezone, and compact. The tool description itself adds no parameter-specific semantics beyond the schema, so it earns the baseline score 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 clearly states it 'Calculate Choghadiya (Chaughadia) muhurta timings for any date and location,' using a specific verb and resource. It differentiates from sibling Panchang tools by focusing on the unique Choghadiya division into day and night periods, making its 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 usage context by stating it is 'Essential for muhurta selection, daily planning, and traditional Hindu timekeeping.' However, it does not explicitly name alternative tools or state when not to use it, just missing the top tier of explicit 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It transparently lists the exact content returned and states that calculations are based on observer location, plus it notes the inclusion of current planetary hora with start/end times. It does not mention output structure or edge cases, but for a non-destructive data tool this is reasonably transparent.

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 a clearly structured list of included content. It is five sentences, each adding a distinct piece of information, but it is slightly longer than strictly necessary and mixes use cases with feature enumeration.

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's moderate complexity, the rich schema, and the absence of an output schema, the description is largely complete: it enumerates all major output categories and use cases. It does not explicitly distinguish itself from the other panchang siblings or explain the return shape, but the content list substantially covers what an agent needs to know.

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

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

Schema description coverage is 100%, so the parameters are already well-documented. The description only adds the generic 'observer location' dependency already present in the latitude/longitude schema descriptions, and it does not add meaning to date, lang, compact, or timezone beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description opens with 'Complete daily panchang with all five limbs' and enumerates specific components (Tithi, Nakshatra, Yoga, Karana, Vara, sunrise/sunset, inauspicious/auspicious periods, hora), giving a clear, specific verb-plus-resource statement. It also distinguishes this detailed panchang from siblings like panchang_basic, panchang_choghadiya, and panchang_hora by listing the full scope of data.

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 use context with 'Essential for muhurta selection, daily horoscope apps, Hindu calendar integration, and electional astrology,' which tells an agent when this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a perfect score.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It explains the calculation logic (sunrise/sunset boundaries, Chaldean sequence) which is helpful, but does not disclose output format, timezone handling, or edge-case behavior. This is a moderate level of transparency.

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 concise and front-loaded with purpose. However, the trailing keyword phrase 'Hora timings API, planetary hours calculator, Vedic hora chart, electional astrology timing' adds noise without value for an AI agent, reducing 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?

The tool has moderate complexity with 5 parameters and no output schema or annotations. The description explains the core calculation but does not specify the shape of results (e.g., list of periods with start/end times and planets). While the purpose is clear, the lack of output details makes it less complete than ideal.

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 already documented. The description does not add extra meaning for parameters; it merely describes the general context. This meets the baseline of 3 but does not exceed it.

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

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

The description clearly states 'Calculate all 24 Hora (planetary hour) periods for any date and location' — a specific verb and resource. It also distinguishes Hora from sibling tools by detailing its day/night division and Chaldean sequence, leaving no ambiguity about its function.

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

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

The description provides clear context for when to use this tool (when Hora periods are needed) but does not explicitly mention alternatives or exclusions. It implies usage through the specific resource and calculations, but does not contrast with similar panchang tools like choghadiya, earning a 4.

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

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

With no annotations, the description carries the full burden. It discloses that the tool returns declination for each planet and all parallel/contraparallel aspects, and adds interpretive context (equivalents of conjunctions/oppositions). It lacks details on potential limitations or error behavior, but covers the core behavior well.

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 concise and informative, but the final sentence ('Declination parallels API, planetary declination calculator, contraparallel aspects.') is keyword stuffing that adds no new information and could be removed. This waste 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?

The description gives a solid overview of the tool's purpose and output, but with no output schema, it does not specify the exact response structure, which planets are included, or how parallels are represented. Given the 7-parameter complexity, more detail would be helpful, but the description is minimally adequate.

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

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

Schema descriptions cover 100% of parameters, so the baseline is 3. The description adds no parameter-specific guidance; it does not elaborate on orb, date/time, or coordinates beyond what the schema already provides. This is acceptable per the baseline, but no extra value is added.

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 planetary declinations and finds parallels/contraparallels, with a specific verb and resource. It distinguishes itself from sibling tools like post_vedic_astrology_aspects and post_vedic_astrology_planetary_positions by focusing on declination-based aspects.

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: use this tool when you need planetary declinations and parallels/contraparallels. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough to guide selection.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds key behavioral details: 'Scanned daily at noon UTC' and the semantics of parallels/contraparallels (equivalent to conjunction/opposition). It also explains the default month behavior. It does not explicitly mention side effects or safe-to-call status, but since this is a data retrieval API and the description clarifies the operational behavior, it exceeds the baseline.

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

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

The description is efficient, with the primary purpose front-loaded in the first sentence. It explains key concepts in two following sentences and gives a behavioral note. However, the final sentence is a set of keyword phrases ('Monthly declination parallels API, planetary parallel ephemeris, contraparallel event calendar') that adds little beyond what is already stated, creating minor redundancy.

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

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

Given no output schema and moderate complexity (5 parameters, all optional), the description provides enough context to understand what the tool returns (events) and its operational specifics (daily scan, default month). It could be more explicit about the exact response structure (e.g., event dates, planets involved), but the description covers the essential use cases and behaviors, making it complete for a well-scoped API.

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 one extra semantic insight beyond the schema: 'Omit year and month to get the month in progress,' which explains how the year/month parameters combine to yield ongoing month data. This is a meaningful addition to the individual default descriptions already present in the schema.

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

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

The description starts with 'Find all declination parallel and contraparallel events between the 7 visible planets for a given month,' which is a specific verb (Find) plus a clear resource (declination parallel/contraparallel events) and scope (monthly). It distinguishes itself from the non-monthly sibling tool (post_vedic_astrology_parallels) by including 'monthly' in the name and clarifying the month-based scope. It also defines parallels and contraparallels, adding semantic precision.

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 by stating 'Essential for advanced transit analysis and hidden aspect discovery' and explaining the default behavior: 'Omit year and month to get the month in progress.' It does not explicitly name alternative tools or state when not to use it, but the context is clear enough for an agent to select this tool for monthly declination events.

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