Vedic Astrology and Kundli MCP Server by RoxyAPI

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

Discloses real-time dynamic calculation, precession theory, and formula. No annotations provided, so description carries full burden. Does not mention read-only nature or error handling, but overall good insight into 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?

Starts clearly but includes excessive formula detail and trailing keyword phrases (e.g., 'KP Newcomb ayanamsa API') that do not serve tool selection. 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?

No output schema, so description should hint at return format. Only says 'returns precise ayanamsa' without specifying unit or structure. Adequate for simple tool but could be more 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 covers 100% of parameter, including format and default. Description adds formula but no extra semantic meaning beyond schema. Baseline 3 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?

Clear verb 'Get' and specific resource 'KP-Newcomb ayanamsa value'. Title reinforces dynamic daily calculation. Distinct among 40+ siblings focused on different astrological calculations.

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 essential for KP chart calculations and research, providing context for use. Lacks explicit alternatives or when-not-to-use guidance, but simple tool with one optional parameter reduces ambiguity.

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 behavioral traits such as whether the tool is read-only, how it handles errors, or any requirements (auth, rate limits). The name 'get' suggests idempotency, but explicit confirmation is missing.

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: the first states the core purpose, the second details return content and use cases. Every phrase adds value, no redundancy. Front-loaded and efficient.

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

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

Given the tool's low complexity (one optional parameter, no output schema), the description sufficiently explains return values (names, ranges, planets, etc.) and provides context on usage. It could mention that the list is static or of fixed size, but overall it is complete for the tool's purpose.

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

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

The input schema has 100% coverage for the single parameter 'lang', fully described with enum values, default, and example. The description adds minimal extra context ('Languages without translations yet return English'), which is helpful but not essential. 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 verb 'Get' and the resource 'complete list of 27 nakshatras', distinguishing it from siblings like get_vedic_astrology_nakshatras_id by emphasizing the full list. It specifies Vedic astrology context and enumerates returned data fields.

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 lists use cases ('nakshatra lookup tables, dasha period calculations, muhurta selection, and astrology app reference data'), providing clear context for when to use this tool. However, it lacks explicit exclusions or alternatives, though the sibling name 'get_vedic_astrology_nakshatras_id' implies a single-result 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?

No annotations are present, so the description carries full burden. It states the return fields but omits behavioral details such as idempotency, error handling for invalid IDs, permission requirements, or rate limits. The description is adequate but not comprehensive.

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

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

The description is a single, well-structured sentence that front-loads the action and enumerates return content. No unnecessary words. Could potentially add a brief usage hint for siblings, but current length is efficient.

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

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

For a simple retrieval tool with complete schema coverage and no output schema, the description adequately explains the returned fields. It does not cover error cases or language behavior beyond defaults, but overall it is sufficient for the tool's complexity.

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

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

Schema coverage is 100%, with both parameters having enum and description. The description adds context by listing returned fields ('name, zodiac range, ruling planet...') but does not add new meaning beyond the schema's parameter descriptions. 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 verb 'Get detailed information' and the resource 'single nakshatra (lunar mansion) by its ID slug'. It also distinguishes itself from the sibling tool `get_vedic_astrology_nakshatras` which likely lists all nakshatras, 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 use when needing details for a single nakshatra by ID, but does not explicitly compare to alternatives like `get_vedic_astrology_nakshatras` for listing or `post_*` tools for calculations. No when-to-use or when-not-to-use guidance is provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return data fields but does not mention any constraints, side effects, or authentication requirements. For a read-only list retrieval, the description is adequate but not richly 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 with no wasted words. The first sentence states the purpose and contents, the second provides usage context. Highly concise and 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?

The tool has one parameter and no output schema. The description explains what data is returned (12 rashis with attributes) and use cases. It is sufficiently complete for a simple reference tool, though it could explicitly mention the response format (e.g., JSON array).

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 the single parameter 'lang'. The tool description does not add additional meaning beyond the schema's own description (which lists supported languages and default). With high schema coverage, 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 returns 'the complete list of 12 rashis' and lists specific data fields (Sanskrit names, Western equivalents, date ranges, symbols, etc.). It distinguishes itself from siblings like get_vedic_astrology_rashis_id by implying it provides the full reference list.

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 good context: 'Reference data for Mesha through Meen. Essential for zodiac sign lookup tables, astrology apps, and rashi-based UI components.' It implies usage but does not explicitly state when not to use or mention alternatives (e.g., get_vedic_astrology_rashis_id for a single rashi).

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 provided, so the description carries the full burden. It discloses the return fields (Sanskrit name, Western equivalent, sidereal date range, symbol, governing Aditya, personality characteristics). No side effects mentioned, but for a read-only tool, this is sufficient.

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: first states purpose, second lists return fields. No redundant information. Efficiently communicates core functionality.

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 adequately covers return fields and parameter purpose. It is complete for a simple get-by-ID tool without additional complexity.

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

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

Schema description coverage is 100% with enums and examples for both 'id' and 'lang'. The description adds 'by its Vedic ID slug', reinforcing the id parameter, but does not add new semantic info beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Get detailed information'), the resource ('a single rashi'), and the identifier ('by its Vedic ID slug'). It distinguishes itself from the sibling 'get_vedic_astrology_rashis' by focusing on a single item rather than a list.

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 use for a single zodiac sign detail but does not explicitly mention when to use alternatives like 'get_vedic_astrology_rashis' for a list. The guidance is adequate but could be more explicit about 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?

With no annotations, the description carries the full burden. It discloses it's a dictionary lookup, not chart-driven, and returns only id and name. It mentions language fallback behavior. However, it could be slightly more explicit about the deterministic, read-only nature, but that is implied. No contradictions.

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

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

Four sentences, each earning its place: purpose and scope, clarification of non-chart functionality, alternatives, and use cases. No wasted words, and the most important 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?

Given the tool's simplicity (one optional parameter, no output schema), the description fully covers what the agent needs: what it returns, what it does not do, and how to proceed for more details or detection. It is complete for the given context.

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 only parameter (lang) has 100% schema coverage with enum, default, example, and description. The description repeats the schema's description ('Response language (ISO 639-1)') without adding new behavioral semantics. 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 it browses a 300+ entry glossary, returning id and name. It distinguishes from siblings like get_vedic_astrology_yoga_id (full entry) and post_vedic_astrology_yoga_detect (chart-driven detection), making the tool's purpose unambiguous.

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

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

Explicitly says when to use ('for yoga-browser UIs, search, and progressive data loading'), what it does not do ('does not inspect a birth chart'), and directs to alternatives (GET /yoga/{id}, POST /yoga/detect). This provides clear guidance for the AI agent.

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

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

No annotations are provided, so the description carries the full burden. It discloses what the tool returns (formation conditions, life results, quality classification) and clarifies it is a static catalog lookup with no chart analysis. While it doesn't explicitly state read-only or idempotence, those are implied and sufficient for this simple lookup 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?

Two sentences, no fluff. Front-loaded with the action and resource, then provides scope and return details. Efficient and well-structured.

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 2 parameters, no output schema, and clear sibling differentiation, the description is complete. It covers purpose, scope, return values, and usage boundaries.

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 descriptions and examples for both parameters. The description adds marginal value by noting the id should be lowercase and hyphenated (already in schema) and explaining the lang default behavior (already in schema). Baseline 3 is appropriate as 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 it looks up a dictionary entry for a specific named yoga from a 300-entry glossary. It uses a specific verb ('Look up') and resource ('dictionary entry'), and distinguishes from siblings like chart analysis tools.

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

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

Explicitly states when to use (glossary lookup) and when not to use (not a chart analysis). Provides a direct alternative: 'For chart-driven present/absent verdicts... call POST /yoga/detect with birth data.'

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 describes the calculation methodology (BPHS chapters) and outputs, but does not explicitly state that this is a read-only computation tool with no side effects. The behavioral transparency is adequate but not thorough.

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

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

The description is concise with two main sentences covering purpose and usage, plus a line of keywords. It is well-structured and front-loads the core functionality. Minor improvement could integrate the keywords line into the main text.

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

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

Given the complexity of Ashtakavarga and no output schema, the description provides a good overview of the returned components. It could be more complete by describing the output format or any prerequisites, but it sufficiently covers the essential context for an AI 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?

With 100% schema description coverage, the baseline is 3. The description does not add additional meaning beyond what is already in the schema for parameters. It focuses on the output and usage rather than enhancing 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 explicitly states it calculates complete Ashtakavarga analysis per Brihat Parashara Hora Shastra, and lists the specific outputs (Bhinnashtakavarga, Sarvashtakavarga, etc.). It clearly distinguishes from sibling tools by focusing on a specific astrological system.

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 indicates when to use this tool: for transit prediction timing, house strength analysis, dasha result evaluation, and planetary strength comparison. While it doesn't explicitly mention when not to use it or provide direct alternatives, the context is clear and useful for an AI agent.

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

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

With no annotations, the description details what the tool returns: full aspects, special aspects, aspect table, mutual aspects, and orb calculation. It is transparent about behavior but does not explicitly state it is read-only or note any side effects, which is acceptable 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 relatively short but ends with keyword stuffing ('Planetary aspects API, drishti calculator...') which adds redundancy. The first sentence is informative but the padding 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?

Given 6 parameters and no output schema, the description adequately lists what aspects are returned but lacks details on output format, error handling, or parameter constraints beyond schema. It is sufficient for basic use but not fully comprehensive.

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, so the schema already explains each parameter thoroughly. The tool description does not add additional parameter guidance or syntax details beyond confirming the parameters are used for the calculation.

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 state the tool calculates all planetary aspects (Drishti) for a given time, specifying full and special aspects. It distinguishes from siblings like birth chart or compatibility tools by focusing solely on mutual aspects between all 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?

Description mentions essential uses (birth chart analysis, compatibility, transits) but gives no explicit guidance on when not to use this tool vs. related siblings like lunar or monthly aspects. No alternatives or exclusions are provided.

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

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

No annotations are provided, so the description carries full burden. It discloses precision (ternary search to minute) and Moon's daily motion, but omits details about authentication, error handling, or rate limits.

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

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

The description is front-loaded with the main purpose and provides essential details in a logical order. While it lists many minor aspects, this is relevant information, not wasted. Could be slightly more succinct.

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 only vaguely states it returns date and time of each event. It does not specify the response structure or fields like aspect type or planet involved, which is a gap.

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

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

Schema coverage is 100%, but the description adds meaningful context beyond parameter names, such as the list of aspect types and use cases, enhancing understanding of how parameters like timezone affect output.

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 all lunar aspect events for a month, listing major and minor aspect types. It distinguishes itself from sibling tools like 'post_vedic_astrology_aspects' by focusing specifically on the 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 mentions use cases like muhurta selection and panchang analysis, providing context. However, it does not explicitly contrast with sibling tools that cover all planetary aspects, lacking when-not-to-use guidance.

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

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

No annotations are provided, so the description must carry the full burden. It discloses the 22 aspect types, the ternary search refinement algorithm, the use of degree-based sidereal positions (Lahiri ayanamsa), and the exclusion of Moon. It also mentions timezone conversion behavior. However, it does not describe the output format or what happens when no aspects are found, leaving some 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 well-structured but slightly verbose. It front-loads the main action and then provides details. However, it ends with redundant keyword tags like 'Monthly planetary aspects API, graha drishti calendar, mutual aspect ephemeris, minor aspects' that add noise without value. Some sentences could be merged for brevity.

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

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

Given the complexity (4 parameters, many aspect types, no output schema), the description covers the algorithm, aspect types, and exclusion logic but omits the output structure. It states 'Returns exact date and time of closest approach' but does not specify the format (e.g., list of objects with planets, aspect, timestamp). This incomplete output specification reduces completeness.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining semantic constraints like 'excluding Moon,' listing the aspect types (not in schema), and describing the algorithm ('ternary search refinement'). This goes beyond the schema's parameter descriptions to give deeper 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 what the tool does: 'Calculate all planetary aspect events (excluding Moon) for a given month.' It specifies verb ('Calculate'), resource ('planetary aspect events'), and scope ('for a given month', excluding Moon). It distinguishes from siblings like 'post_vedic_astrology_aspects_lunar' and 'post_vedic_astrology_aspects' by mentioning the exclusion and the monthly granularity.

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 advises: 'For Moon-specific aspects, use the /aspects/lunar endpoint,' providing a clear when-not-to-use case. It states the tool is 'Essential for transit timing, muhurta selection, and monthly astrological forecasting,' indicating appropriate contexts. However, it does not comprehensively cover all sibling alternatives or when to use other tools like the general aspects endpoint.

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 burden of disclosure. It describes the return format (planetary positions grouped by zodiac signs with nakshatra details) but does not disclose any potential side effects, limitations (e.g., rate limits, required permissions), or other behavioral traits. It adequately describes a read-only calculation tool, but could add more about 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 two sentences long, front-loading the core functionality in the first sentence and use cases in the second. Every word contributes value; there is no redundant or filler content. Highly efficient.

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

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

Given the complexity of the tool (6 parameters, no output schema), the description adequately explains what the response contains: planetary positions, ascendant, nakshatra details, and pada. It could be more complete by listing other elements like houses or aspects, but it covers the essential output for a birth chart 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?

Input schema coverage is 100%, and each parameter has a detailed description in the schema itself. The tool description does not add additional meaning beyond what the schema provides; it only gives a high-level context. Baseline of 3 is appropriate because the schema already 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 it calculates a complete Vedic birth chart (Janam Kundli) with all 9 planetary positions and Ascendant. It distinguishes from sibling tools by specifically naming 'birth chart' and listing its components, differentiating it from more specific tools like navamsa or divisional charts.

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 mentions it is 'Perfect for kundli generation, horoscope matching, and Vedic astrology software integration,' which gives context but does not explicitly state when not to use it or compare it to alternatives among the many sibling tools. No exclusions or when-not-to-use guidance is provided.

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

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

No annotations provided, so description carries full burden. It discloses return of 36-point scale, breakdown across 8 kootas, dosha detection with cancellation rules, and marriage recommendation. Lacks mention of rate limits or authentication, but adequately describes 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?

Single paragraph, but somewhat verbose with repeated details. Could be more concise while maintaining clarity.

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

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

No output schema, but description sufficiently explains return content (score breakdown, dosha detection, recommendation). Adequate for an agent to use the tool.

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

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

Schema coverage is 100% with detailed parameter descriptions. The tool description adds overall context but does not add significant meaning beyond schema for individual 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?

Clear verb 'Calculate' and specific resource 'Ashtakoot compatibility (Gun Milan)'. Distinct from sibling tools which focus on individual charts or specific doshas.

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 'Perfect for kundli matching for marriage, matrimonial platforms...', giving clear context. However, does not explicitly state when not to use or compare to alternatives.

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 disclose behavioral traits. It states the output includes a dasha timeline but does not mention any side effects, rate limits, or critical requirements (e.g., accuracy dependence on time precision). The description is insufficient for a mutation tool (POST) that likely has no side effects but could be clearer about read-only nature.

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

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

The description is somewhat verbose with marketing-like phrases ('Accurate dasha calculator API', 'Essential for understanding') that add little value. Key information is front-loaded, but brevity could be improved.

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

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

Given the complexity of dasha calculations and no output schema, the description should be more detailed about the response structure and the hierarchy of periods. It mentions the dasha timeline and basis on moon nakshatra, but lacks concrete examples or limitations. It is 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?

Schema description coverage is 100%, so baseline is 3. The tool description does not add significant value beyond the schema for parameters; it repeats general purpose but does not offer deeper semantics or examples for parameters beyond what 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 it calculates current Vimshottari Dasha periods (Mahadasha, Antardasha, Pratyantardasha) with remaining time and returns a timeline with start/end dates. While it doesn't explicitly differentiate from sibling dasha tools, the purpose is specific and informative.

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 mentions it is 'essential for understanding current planetary influences' but does not provide explicit guidance on when to use this tool versus related sibling tools like post_vedic_astrology_dasha_major or post_vedic_astrology_dasha_sub_mahadasha. Usage context is implied but not fully detailed.

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 provided; description bears full burden but only states what is returned. Does not disclose if it is read-only, authentication needs, rate limits, or side effects. Lacks behavioral traits beyond basic functionality.

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 with no wasted words. Information is front-loaded and directly addresses 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?

Despite no output schema, the description does not explain return format or structure of the dasha periods. For a complex domain like Vedic astrology, more completeness is needed to inform agent about output expectations.

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

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

Schema coverage is 100%, with each parameter having a detailed description in the schema. The tool description itself adds no further parameter-specific information. Baseline 3 is appropriate as schema already covers 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?

Title and description clearly state the tool returns all 9 Mahadasha periods (120-year cycle) of Vimshottari Dasha. It distinguishes from sibling tools like 'dasha_current' and 'dasha_sub_mahadasha' by specifying 'complete cycle' and 'all major planetary periods'.

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

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

No guidance on when to use this tool versus alternatives like 'dasha_current' or 'sub_mahadasha'. Does not mention prerequisites (e.g., need exact birth data) or explicitly state that this is for the full cycle, not current or sub-periods.

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 accurately states the output: 9 Antardasha sub-periods within a Mahadasha. However, with no annotations, more detail would be beneficial, such as indicating this is a read-only computation, how the sub-periods are calculated (proportional durations), and what data is required. The current description is adequate but minimal.

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 with no unnecessary words. Every sentence provides essential information: what it returns and the basic concept of proportional sub-periods. Highly efficient.

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

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

Despite having 7 parameters and no output schema, the description only states the output is 9 sub-periods without specifying details like start/end dates, durations, or planet lords. For a tool with this complexity, more guidance on what the response contains is needed. The description is insufficient for an agent to fully understand the result format.

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 detailed explanations for each parameter (e.g., date, time, latitude, longitude, timezone, mahadasha). The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns 9 Antardasha sub-periods within a Mahadasha. The verb 'Returns' combined with the specific resource 'Antardasha sub-periods' and the explanation that each Mahadasha is divided into 9 proportional sub-periods provides precise purpose. The title further clarifies it's for a specific Mahadasha, distinguishing it from sibling tools like dasha_current or dasha_major.

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

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

No explicit guidance on when to use this tool versus alternatives. Given siblings like post_vedic_astrology_dasha_current and post_vedic_astrology_dasha_major, it would be helpful to indicate that this tool is for detailed sub-periods of a specific Mahadasha, while others provide current period or full list of Mahadashas. The description lacks such context.

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 calculation is based on the BPHS Shodasha Varga system and mentions detection of Vargottama planets. This gives insight into the tool's behavior beyond basic functionality. No contradictions noted.

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 purpose, then explains divisions, then mentions system and feature. Every sentence adds value. Could be slightly more structured (e.g., bullet list for divisions) but overall efficient.

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

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

Given no annotations, 100% schema coverage, no output schema, and complexity (7 params, many siblings), the description covers purpose, usage context, underlying system, and a notable feature. It is complete for an agent to understand when and why to use this tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by linking parameters to life areas (e.g., division 9 for marriage) and explaining the importance of time and location for Lagna and house divisions. It doesn't repeat schema but enriches context.

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 any Vedic divisional chart (Varga) from D2 Hora to D60 Shashtiamsa' and lists specific life areas for each division, clearly distinguishing it from siblings like birth chart or navamsa. The verb+resource+scope is specific and complete.

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

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

The description explains that divisional charts reveal insights about specific life areas and maps each division to a domain (e.g., D9 for marriage, D10 for career). While it doesn't explicitly say 'use this when you need X,' the mapping is sufficiently clear for an agent to infer usage context. It does not mention alternatives but given the comprehensive coverage, not needed.

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 burden. It discloses the calculation condition, types, and output (severity and effects). However, it does not state that the tool is read-only or mention any authentication or rate limits, missing some 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 somewhat verbose and includes marketing-like statements (e.g., 'Essential for ... matrimonial compatibility'). It is front-loaded with the core condition but could be more 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?

The description mentions output (severity and effects) but no output schema exists. It lacks prerequisites or hints about when to choose this tool over siblings. For a tool with 5 parameters, completeness is adequate but not excellent.

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 parameter descriptions in the schema are already detailed. The tool description does not add significant new meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool detects Kalsarpa dosha when all 7 planets are hemmed between Rahu and Ketu. It lists 12 specific types (e.g., Ananta, Kulik) and mentions return of severity and effects based on Rahu house position, making the purpose highly specific and distinguishable.

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

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

No explicit guidance is given on when to use this tool versus sibling dosha tools like manglik or sadhesati. The phrase 'Essential for Vedic astrology dosha analysis' is generic and does not help the agent choose this tool over alternatives.

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 full burden. It discloses key behavioral traits: the detection is based on Mars position in inauspicious houses, returns severity levels (Mild/Moderate/Severe) and cancellation factors, and includes exceptions that reduce effects. This gives the agent a good understanding of what to expect, though it doesn't cover error responses or input validation specifics.

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 reasonably concise with four sentences that each add value: first defines what is detected, second states use case, third mentions return values, fourth notes exceptions. It could be slightly shorter (e.g., combining some sentences), but it avoids redundancy and front-loads 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 complexity (astrological dosha calculation) and lack of output schema, the description provides essential details: houses considered, severity levels, cancellation factors, and use case. It is complete enough for an agent to understand what the tool does and when to invoke it, though it omits response structure specifics.

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

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

Schema coverage is 100%, so each parameter already has a description. The tool description does not add new meaning beyond reinforcing the overall purpose. For example, it mentions that date/time/location are needed for calculations, but the schema's parameter descriptions already provide this context. The description is aligned but not additive.

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

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

The description clearly identifies the tool as detecting Manglik dosha based on Mars position in specific houses (1,2,4,7,8,12) from Lagna. It distinguishes from siblings by focusing on a specific dosha type and explicitly names the use case (matrimonial compatibility checks). The verb 'detect' combined with the resource 'Manglik dosha' provides a specific action and object.

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 when to use: for matrimonial compatibility checks and kundli matching. It mentions that the tool returns severity levels and cancellation factors, which implies the output format. However, it does not explicitly differentiate from sibling dosha tools like post_vedic_astrology_dosha_kalsarpa or post_vedic_astrology_dosha_sadhesati, leaving room for confusion about which dosha calculator to use for which situation.

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 should fully disclose behavioral traits. It mentions returning 'Saturn transit dates and effects on life' with phase identification, which is helpful. However, it omits details like computation time, data requirements, or authentication needs. The description adds moderate value but leaves 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 verbose, including redundant phrases like 'Accurate sade sati calculator' and 'Shani sadhesati 7.5 year period tracker.' While it front-loads the main purpose, the extra sentences are somewhat repetitive, making it less 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?

The description lists return elements (dates, phases, effects) but is vague on output structure (e.g., whether multiple periods, exact format). Without an output schema, more detail is needed for completeness. It partially addresses the complexity but leaves 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 parameter descriptions. The tool description adds no additional semantic value beyond the schema—it does not elaborate on how parameters relate to Sadhesati calculation (e.g., the role of Moon position derived from birth data). 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 calculates Sadhesati periods based on Saturn transit relative to natal Moon, including phase identification. It differentiates from sibling dosha tools (e.g., kalsarpa, manglik) and general astrology tools by focusing specifically on this Saturn transit phenomenon.

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 use: 'Essential for Saturn transit analysis, sadhesati remedies timing, and understanding challenging Saturn periods.' It implies use when analyzing Saturn-related effects, though it does not explicitly exclude alternatives like the general transit tool. Slightly lacking in explicit when-not-to-use guidance.

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

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

Describes what a crossing is, ascending/descending, and gives frequency examples (Moon ~2 per month). Also states output fields (date, time, direction, longitude, zodiac sign). With no annotations, the description adequately clarifies behavior but omits details like which planets are 'visible' or any limitations.

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 relatively concise given the technical content. Key information is front-loaded, and each sentence adds value. Could be trimmed slightly, but overall well-structured.

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 3 parameters, the description covers the tool's behavior and output fields. It mentions visible planets and gives frequency hints. However, it could list which planets are included or specify that it excludes the Sun/other bodies. Still, it is sufficiently complete for an agent to determine correct usage.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add significant parameter-specific info beyond the schema; it provides context about the overall output but not new details on 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?

Clearly states the tool finds ecliptic plane crossings for visible planets in a given year. Distinguishes from sibling tools by focusing on a specific astronomical event (ecliptic crossings) that is not covered by other 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?

Explicitly describes the tool's function and the input (year). While it does not contrast with sibling tools, the unique purpose makes it clear when to use this tool. Could benefit from mentioning that it is for planetary nodes.

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 disclose behavioral traits. It mentions support for custom ayanamsa but lacks information on limitations, error handling, or what happens with invalid input. The description is mostly a feature list, not a behavioral account.

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 due to SEO keywords and bullet points. The first sentence effectively states the main purpose, but subsequent sentences could be trimmed. The structure is not optimized for quick comprehension by an AI agent.

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 9 parameters, no output schema, and no annotations, the description should explain output format and usage constraints. It mentions chart components but omits details on the response structure, error scenarios, or parameter interactions. The description is incomplete for a tool of this complexity.

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

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

Schema coverage is 100% and each parameter has a description in the input schema. The description adds some contextual value (e.g., mentioning 'custom ayanamsa') but largely repeats or expands on schema descriptions without significant new meaning. The SEO portion does not aid 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 it generates a complete KP birth chart with specific components like Placidus house cusps, star-lord and sub-lord calculations. The tool name and title further reinforce this, distinguishing it from sibling tools that focus on individual aspects (e.g., kp_cusps, kp_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?

No explicit guidance on when to use this tool versus the many sibling KP tools (e.g., post_vedic_astrology_kp_cusps, post_vedic_astrology_kp_planets). The description lists features but does not provide context on prerequisites or alternative use cases. The SEO content is irrelevant for an AI agent.

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

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

No annotations are provided, so the description carries the full burden. It discloses aynamsa system flexibility and return of all 12 cusps with sub-division details. For a calculation tool, this is adequate transparency about 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 adequately sized but contains SEO padding (e.g., 'SEO: Placidus house cusps API...') that is unnecessary for an AI agent. The core information is front-loaded, but extraneous text reduces 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?

Given no output schema, the description briefly states the return (12 cusps with sub-division details) but lacks structure details. It is complete for basic usage but could benefit from more detail on output format and differentiation from similar tools like kp_chart.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds no new parameter semantics beyond what is already in the schema. It reinforces ayanamsa flexibility but does not provide additional 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 clearly states the tool calculates unequal Placidus house cusps with sub-lord details, and mentions specific use cases (KP horary, cusp sub-lord analysis, birth chart rectification). It distinguishes from siblings like kp_planets and kp_chart by targeting cusp calculation.

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 contexts (KP horary, cusp analysis, rectification) but does not explicitly exclude other tools or provide when-not-to-use guidance. Clear context, but lacks direct comparison to alternatives.

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 provides key behavioral details: it returns all 9 planets with nakshatra, star-lord, sub-lord, and horary numbers. It does not disclose error handling or rate limits, but it adequately conveys the output 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 concise sentences plus a few search tags. It is front-loaded with the core purpose and avoids unnecessary words, making it efficient for quick understanding.

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

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

Given the complexity (8 parameters, no output schema, no annotations), the description explains the output contents (planet list and attributes) fairly well. It could mention potential limitations or data range, but it is largely complete for its intended use.

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 clear parameter descriptions. The main description adds no further parameter meaning beyond listing returned fields, so it meets the baseline without adding significant value.

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

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

The description clearly states it returns KP planetary positions with star-lord and sub-lord calculations, specifying the exact resource (planets) and the KP-specific computations. It distinguishes itself from siblings like kp_cusps or kp_chart by focusing on planetary details.

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

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

The description mentions it is essential for KP astrology software, significator analysis, and event prediction, giving context on when to use it. However, it does not explicitly compare to alternatives like post_vedic_astrology_planetary_positions 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 bears full responsibility for behavioral disclosure. It mentions the return includes longitude, zodiac sign, nakshatra, sublord, sub-sublord, and KP number, but does not disclose potential performance implications, rate limits, or the structure of the output (e.g., array of timestamps). The constraints on range and interval are helpful, but more could be said about the tool's computational load.

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

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

The description is concise, consisting of 4-5 sentences that front-load the main action and output. Every sentence adds value without redundancy or unnecessary detail.

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

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

Given the tool's complexity (8 parameters, 5 required, no output schema), the description explains what the tool returns (list of fields per planet per timestamp) but does not detail the exact JSON structure. For an AI agent, the description is mostly complete but could benefit from an example or explicit note about the return format.

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, so each parameter already has a description. The tool description does not add new details about parameters beyond what the schema provides. It mentions output fields but not parameter semantics, so it meets the baseline of 3.

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

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

The description clearly states the tool calculates positions of all 9 planets at regular time intervals with full KP hierarchy (sign lord, star lord, sublord, sub-sublord). It lists specific output fields and distinguishes itself from sibling tools like single-time KP planets by emphasizing the interval aspect.

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 suggests ideal use cases: tracking planetary motion, finding optimal muhurta windows, analyzing transit patterns, and building KP ephemeris tables. It also specifies the maximum range of 7 days and interval constraints (15 minutes to 24 hours). However, it does not mention when not to use this tool or directly compare with sibling tools like post_vedic_astrology_kp_planets for single time.

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 full burden. It states the tool returns precise timestamps but does not disclose any behavioral details such as authentication, rate limits, or side effects. The description is adequate but lacks depth on operational aspects.

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

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

The description is concise with four sentences, front-loading the primary action and then listing use cases. Every sentence adds value with no redundancy.

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

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

Given the complexity (6 parameters, no output schema), the description adequately explains the tool's purpose and use cases. However, it lacks detail on the output format, which could be useful for an agent invoking the tool.

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

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

Schema coverage is 100%, so all parameters have descriptions in the schema. The tool description provides high-level context but does not add significant meaning beyond what the schema already provides for each parameter.

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

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

The description clearly states the tool tracks when planets enter new zodiac signs with precise ingress timestamps, and lists specific use cases like Sun sankranti dates and Moon sign changes. This distinguishes it from sibling tools such as planetary positions or transit, which do not focus on ingress times.

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 (transit analysis, muhurta selection, panchang) but does not explicitly mention when not to use it or provide alternatives like post_vedic_astrology_planetary_positions or post_vedic_astrology_transit.

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 explains what the tool returns (five ruling planets) and that optional birth data adds significators. It does not mention potential behavioral traits like idempotency or error handling, but it is transparent about its core functionality.

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 just two sentences: the first states the core action, the second explains the optional feature. No wasted words, front-loaded with the main verb 'Calculate'.

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 7 parameters and no output schema, the description adequately covers the primary output and optional significators. It does not detail the response structure, but the main intent is clear. Could be improved by listing returned fields 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?

Schema coverage is 100%, so baseline is 3. The description adds context by explaining the purpose of optional birthDate/birthTime for significators, but does not elaborate on individual parameters beyond the schema's own descriptions.

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

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

The description clearly states the tool calculates the 5 ruling planets using Krishnamurti Paddhati horary astrology, and distinguishes itself from siblings by specifying it returns Day Lord, Moon Sign/Star/Sub Lord, Lagna Sign/Star/Sub Lord with optional significators.

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

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

The description implies when to use the tool: for basic ruling planets or with birth data for significators (essential for KP prediction). It does not explicitly mention when not to use it or list alternatives, but the purpose is clear enough.

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

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

With no annotations, the description carries the full burden. It explains the 4-level KP hierarchy, the return fields (Day Lord, Moon/Lagna lords, ruling planets set, per-planet significations), and that computations are based on each moment's sky chart. Missing potential performance notes for large intervals, but overall 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 a single paragraph of moderate length (7 sentences). It front-loads the main purpose and then details specifics. Each sentence adds value, though it could be more bulleted for clarity. No wasted words.

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

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

Given no output schema, the description adequately explains the return values: Day Lord, Moon Sign/Star/Sub/Sub-Sub Lords, Lagna lords, unique ruling planets, and per-ruling-planet house significations. It also describes the KP hierarchy. Lacks exact JSON structure, but sufficient for understanding.

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 baseline is 3. The description adds context beyond the schema, e.g., recommending intervalMinutes of 1-5 for birth time rectification and explaining ayanamsa systems. However, the schema already provides good descriptions, so the added value is marginal.

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 ruling planets and KP significators at regular intervals, using Krishnamurti Paddhati horary astrology. It specifies the verb 'calculate', the resource 'ruling planets and significators at intervals', and differentiates from sibling tools like the single-moment ruling planets tool.

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

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

The description provides explicit use cases: birth time rectification, muhurta selection, and KP horary number analysis. It implies when to use this tool over alternatives by noting that no birth data is needed, but does not explicitly state when not to use or list alternatives.

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 reveals that returns exact timestamps and supports specified planets. However, it lacks disclosure of potential limitations (e.g., performance for large ranges, handling of retrograde planets, whether it creates side effects). The behavioral profile is partly 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 four sentences, front-loaded with the main action and supported planets. It is efficient but could be slightly tighter by merging the third and fourth sentences. No extraneous 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?

Given the complexity of KP astrology and no output schema, the description explains the core function and return type (exact timestamps) but does not specify output format or structure (e.g., list of transitions with timestamps, sublords). It is adequate but not fully comprehensive.

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

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

Schema coverage is 100%, so baseline is 3. The description reiterates planet support but adds no new meaning beyond the detailed schema descriptions for ayanamsa, nodeType, or timezone. Minimal additional value.

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

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

The description clearly states the tool tracks planet crossings of KP sublord boundaries using specific verb 'Track' and resource 'KP sublord boundaries'. It distinguishes from siblings like kp_rasi_changes or kp_planets by focusing on sublord changes for event timing, not positions or rasis.

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 ('prashna kundali analysis', 'dasha predictions', 'find favorable windows') but does not explicitly exclude when not to use or compare to siblings. The context is sufficient for an expert agent.

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

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

No annotations are provided, so the description carries the full burden. It mentions detecting Vargottama planets and dividing planetary positions into 9 parts, but does not disclose the output format, response structure, or any limitations. The description is promotional rather than transparent about 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 verbose with five sentences containing redundant phrases (e.g., 'Navamsa calculator API reveals planetary strength in married life' and repeated mentions of marriage). It could be trimmed to a single concise sentence without losing meaning. Several sentences add little 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 complexity of astrology and no output schema, the description should clarify what the response contains (e.g., planetary positions, Vargottama status). It mentions a few aspects but lacks specifics. Additionally, it does not explain how this tool differs from sibling tools like compatibility or generic divisional chart, leaving the agent underinformed.

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 already present. The tool description adds no new information about parameters beyond what the schema provides. Baseline score of 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool calculates Navamsa (D9) chart for marriage compatibility, spouse prediction, and spiritual life. It distinguishes the tool from generic divisional charts by focusing on marriage-specific uses, and mentions detection of Vargottama planets. The purpose is specific and clearly communicated.

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 indicates the tool is 'essential for matrimonial matching, relationship prediction, and marital harmony analysis', giving context for use. However, it does not explicitly describe when not to use this tool or compare it to sibling tools like post_vedic_astrology_compatibility or post_vedic_astrology_divisional_chart. Guidance is present but incomplete.

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 must disclose behavioral traits. It explains that the tool calculates four panchang elements and mentions paksha and ruling planet, indicating a read-only computation. However, it does not address error conditions, input validation, or rate limits, but since it's a simple calculator, the disclosure is adequate.

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

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

The description is informative but somewhat verbose, repeating phrases like 'Daily panchang API' and 'Tithi calculator' without adding new information. The main purpose is front-loaded, but sentences could be trimmed without losing clarity. Still efficient for the content provided.

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 input schema is comprehensive, covering all parameters. However, no output schema exists, and the description only partially describes the output by naming the four elements and mentioning ruling planet. It does not detail the full response structure, data types, or additional fields, leaving some ambiguity for the 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?

Schema coverage is 100% with strong descriptions, so baseline is 3. The tool description restates the purpose of the output elements (e.g., 'Tithi calculator') but does not add new parameter syntax or meaning beyond what the schema's parameter descriptions already provide. No additional compensation needed.

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

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

The description clearly states it calculates Panchang elements (Tithi, Nakshatra, Yoga, Karana) for any date, specifying the tool's core function. It distinguishes itself from sibling tools like 'detailed' or 'choghadiya' by mentioning 'basic' and listing these four specific elements, leaving no ambiguity about its 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 provides context on when to use the tool: for determining auspicious timings (muhurta), festival dates, and planetary influences. It implies usage for basic panchang needs but does not explicitly exclude cases when detailed versions are more appropriate or specify prerequisites, though the context of siblings helps guide the agent.

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

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

With no annotations, the description explains the calculation relies on date, location, timezone, and outputs period timings and auspiciousness, adequate for 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?

Description is front-loaded with main action, but ends with SEO keywords 'Choghadiya calculator API' etc., which are unnecessary for an AI agent.

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?

Missing output schema; description does not specify return format (e.g., period start/end times, type). Input is well covered, but output expectations are absent.

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

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

Schema has 100% coverage; description adds value by explaining how parameters affect sunrise/sunset and defaults, e.g., timezone defaults to IST.

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 Choghadiya muhurta timings, divides day/night into 8 periods with planetary rulers, and distinguishes from sibling tools like hora, basic panchang.

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

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

The description specifies it's essential for muhurta selection and daily planning, implying when to use, but does not explicitly contrast with siblings or state when not to 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?

With no annotations provided, the description conveys what the tool returns (limbs, times, periods) and that calculations are based on location. It does not disclose potential side effects or operational details, but overall it provides sufficient transparency for a read-only 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, with two sentences that front-load the key contents and then list use cases. Every sentence adds value with no redundancy.

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

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

Given the tool's complexity and absence of an output schema, the description adequately covers the plethora of output elements. It could be enhanced by mentioning the response structure, but it remains sufficient for agent selection.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the role of latitude/longitude in determining local times, the importance of timezone for accuracy, and language fallback behavior. It also provides examples.

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 provides a complete daily panchang with all five limbs plus additional periods. It distinguishes itself from the sibling 'post_vedic_astrology_panchang_basic' by being 'detailed' and listing specific components like Rahu Kaal, Abhijit Muhurta, and planetary hora.

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 lists relevant use cases like muhurta selection and daily horoscope apps, giving clear context. However, it does not explicitly mention when to use an alternative (e.g., the basic panchang) or when not to use this tool.

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

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

With no annotations, the description carries the transparency burden. It explains the calculation method but does not disclose output structure, error handling, or side effects. The keyword sentence adds little value.

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 mostly concise with 4 substantive sentences. The final keyword sentence is redundant but not overly harmful. Slight room for improvement by removing keywords.

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 should mention return value structure. It does not, leaving agents to guess the response format. The concept is well explained, but completeness is lacking for practical use.

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. The tool description adds no additional parameter-level information beyond the schema, so 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 it calculates all 24 Hora periods for any date and location, with a specific verb (calculate) and resource (Hora periods). It explains the day/night division and planetary lords, distinguishing it from sibling tools like panchang_basic 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 no explicit guidance on when to use this tool vs alternatives (e.g., panchang_choghadiya). It only implies use for planetary hours, lacking exclusions or comparisons.

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

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

No annotations are provided, so the description must disclose behavior. It states that parallels are equivalent to conjunctions and contraparallels to oppositions, and mentions topocentric corrections in the latitude parameter description. However, it does not disclose edge cases (e.g., no parallels found), or whether the operation is read-only. Basic transparency but could be expanded.

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 relatively concise with 4 sentences plus a keyword line, which is unnecessary and detracts from quality. The core information is front-loaded, but the keyword stuffing makes it less polished. Could be improved by removing the keyword line.

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 explains what the tool does and what it returns (declinations and aspects). However, it lacks details on output format, error handling, or examples. Given no output schema, the description should provide more context on the structure of results. It is adequate but not thorough.

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

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

All 6 parameters have descriptions in the input schema (100% coverage). The main description adds minimal extra meaning: it mentions the orb default and that time affects the Moon, but these are already covered or implied in the schema. Baseline 3 is appropriate as the description does not significantly enhance parameter understanding 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?

Title and description clearly state the tool calculates planetary declinations and finds parallels and contraparallels, which are equivalent to conjunctions and oppositions. It distinguishes itself from sibling tools like post_vedic_astrology_aspects which focus on ecliptic longitude 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 implies usage for declination-based aspects but does not explicitly state when to use this tool over alternatives like post_vedic_astrology_aspects or post_vedic_astrology_planetary_positions. No usage exclusions are provided.

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

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

Without annotations, the description compensates by stating the scanning frequency ('Scanned daily at noon UTC') and defining parallels/contraparallels. However, it does not disclose potential output size, error handling, or return format beyond the concept of events.

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 starts with a clear action but includes a redundant final sentence listing synonyms. It is slightly verbose for a simple tool; could be more efficient.

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

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

Given no output schema or annotations, the description explains the tool's purpose and scientific background but omits details about output structure (e.g., list of events vs. ephemeris). It is adequate but leaves gaps for an AI 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?

Schema coverage is 100%, so the baseline is 3. The description does not add significant extra meaning beyond the schema's parameter descriptions; it only reinforces the context of monthly and daily scanning.

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

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

The description clearly states the verb ('Find all') and resource ('declination parallel and contraparallel events between the 7 visible planets for a given month'). It explains the astronomical significance and distinguishes from siblings like 'post_vedic_astrology_parallels' by specifying 'monthly' and '7 visible 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 implies usage for advanced transit analysis and hidden aspect discovery but does not explicitly compare with sibling tools like 'post_vedic_astrology_parallels' or 'post_vedic_astrology_aspects_monthly'. No when-not-to-use guidance is provided.

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

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

No annotations provided, but description discloses behavioral traits: real-time calculator, uses Whole Sign house system, faster response. Adds context beyond schema, such as time criticality for Lagna.

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

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

Front-loaded with core purpose, then expands with features and use cases. Every sentence is informative without verbosity. Excellent structure for agent comprehension.

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 6 parameters and no output schema, description provides sufficient context about what is returned (planets, nakshatra, etc.) and why parameters are critical. Adequate for agent to understand tool's role and data 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 coverage is 100% with descriptions. Description adds value by reinforcing parameter importance in Vedic context (e.g., 'Time is CRITICAL for Lagna calculation'), providing more semantic meaning than schema alone.

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

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

Clearly states it gets simplified planetary positions for all 9 planets plus Lagna, with nakshatra, pada, rashi, house number. Distinguishes from siblings by mentioning 'simplified' and 'faster response without full chart structure'.

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

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

Explicitly says 'Perfect for planetary alignment tracking, daily transit updates, and astrology widgets'. Implying use when basic planetary data is needed without full chart, but does not explicitly name alternatives or state when not to 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?

No annotations are provided, so the description carries full burden. It discloses that calculations are 'at noon UTC' and includes the coordinate system parameter with explanation. However, it omits potential aspects like rate limits, data volume, 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 relatively short: two sentences plus a list of keywords. It front-loads the main function. The keyword list may be extraneous but does not harm conciseness significantly.

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

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

No output schema exists, so the description must explain return values. It lists 'longitude, zodiac sign, degree within sign, and retrograde status for each planet on each day', which is fairly complete. It does not specify the response structure but covers key fields.

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%, baseline at 3. The description adds significant value for the 'coordinateSystem' parameter by explaining the difference between sidereal (Nirayana, Lahiri ayanamsa) and tropical (Sayana). This goes beyond the schema description.

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

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

The description clearly states 'Get daily sidereal ecliptic positions for all 9 Vedic planets (Navagraha) for an entire month', specifying the verb (get), resource (positions), and scope (monthly). The sibling tools include a non-monthly version ('post_vedic_astrology_planetary_positions'), so the monthly distinction is clear.

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 mentions the tool is 'Essential for ephemeris generation, transit tracking, and planetary movement visualization', giving context on when to use it. It does not explicitly exclude scenarios, but the sibling list implies alternatives (e.g., single-day positions, monthly transit).

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 full burden. It describes the tool as calculating and returning data but lacks details on behavior such as handling of invalid inputs, rate limits, or required permissions. For a read operation, it suffices minimally but could be more informative.

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 somewhat verbose and includes apparent keyword stuffing (e.g., 'Shadbala calculator API, planetary strength Vedic astrology, graha bala, Ishta Kashta Phala'). It is front-loaded with the main purpose but could be more 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?

Given the complexity of Shadbala (6 components, 7 planets, plus Ishta/Kashta Phala) and no output schema, the description lists the return components but does not specify the output structure or format. It provides enough information for an agent to select the tool but lacks complete behavioral context.

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

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

Schema coverage is 100% with detailed descriptions for all parameters. The description does not add new information about the parameters beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool calculates complete Shadbala (six-fold planetary strength) and lists all components. It distinguishes from sibling tools by focusing on planetary strength evaluation, which is a distinct concept from birth chart, dasha, yoga, etc.

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

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

The description mentions it is 'essential for evaluating planetary strength in Vedic birth chart analysis, dasha prediction, transit interpretation, and yoga assessment.' This implies usage context but does not explicitly state when to use this tool versus alternatives like aspects or dasha tools, nor does it provide exclusion criteria.

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

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

With no annotations provided, the description carries full burden. It mentions what the tool returns but lacks details on behavioral traits such as authentication needs, rate limits, error handling, or whether it requires a prior birth chart calculation.

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

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

The description is mostly concise with three informative sentences, but the final sentence listing keywords ('Transit analysis API, gochar calculator, vedic transit predictions') adds redundancy without 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?

The description explains what the tool returns (house positions, aspects, key transits) but lacks output format details, prerequisites (e.g., birth chart), and error conditions. Given no output schema, this 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?

Schema coverage is 100% with detailed parameter descriptions (e.g., latitude affects house cusps). The tool description adds no additional parameter meaning beyond what the schema already provides, 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 it analyzes planetary transits over natal chart positions, listing specific outputs (house positions, aspects, slow-moving planet highlights). However, it does not differentiate from the sibling tool post_vedic_astrology_transit_monthly, which may have overlapping 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 states it is 'essential for timing predictions, event forecasting' which implies usage context, but it provides no explicit guidance on when to use this tool versus alternatives like post_vedic_astrology_aspects or 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?

No annotations provided, so description carries full burden. It describes the output: sign changes for each planet and starting positions. It does not mention destructive behavior or edge cases, but it's clear that this is a read-only data retrieval operation.

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 somewhat verbose with repeated phrases like 'monthly planetary transit API, gochar calendar, rashi parivartan dates.' It could be more concise. However, it is well-structured in listing planets and use cases.

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

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

No output schema exists, so description must explain return values. It states that it shows when each planet transitions and includes starting positions. It could be more precise about the format (dates/times), but it gives enough context for basic understanding.

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 baseline is 3. The description does not add significant meaning beyond the schema's parameter descriptions. It repeats 'planetary sign changes' but does not elaborate on parameter usage or constraints.

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

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

Description clearly states it gets all planetary sign changes for a month, listing the 9 Vedic planets and including starting positions. It distinguishes from siblings by specifying 'monthly' and mentioning use cases like transit prediction and muhurta planning.

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 context for usage: 'Essential for transit prediction, monthly horoscope generation, and muhurta planning.' It implies use cases but does not explicitly state when not to use or suggest alternatives. However, the sibling list includes other transit tools, so the agent can infer but lacks direct 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. It describes the derivations (8-part day/night division, Sun longitude-based) and cites BPHS, but lacks disclosure of behavioral traits such as authentication needs, rate limits, or potential side effects. The description is transparent about computation but insufficient for full behavioral 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 description is moderately concise but includes redundant or marketing-like phrasing at the end (e.g., 'Upagraha calculator API, Gulika Mandi position...'). The key information is front-loaded, but the extra keywords detract from conciseness. A streamlined version would improve score.

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

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

Given the lack of output schema, the description reasonably explains what the tool returns: list of 11 upagrahas with their derivation. It covers the main categories and use cases. It does not specify output format (e.g., positions in degrees) but is largely complete for a calculation tool. Could add more detail on the return structure.

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 additional parameter-level meaning beyond the schema; however, it provides high-level context about what the parameters will compute. No param details are missing, but the description could complement the schema by explaining how input values affect output.

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

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

The description explicitly states it calculates all 11 Vedic upagraha positions per Brihat Parashara Hora Shastra, and distinguishes between 6 time-based and 5 Sun-longitude-based upagrahas. It clearly identifies the resource (upagraha positions) and specific verb (calculate), differentiating it from other sibling tools like planetary positions or doshas.

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 indicates this tool is 'essential for complete kundli analysis, dosha assessment, and advanced chart interpretation,' providing clear context for when to use it. However, it does not explicitly state when not to use it or provide comparisons to sibling tools, which would improve the 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?

No annotations are provided, so the description carries the full burden. It explains the output fields (id, name, present, quality, evidence) and mentions the rules used. No destructive behavior or auth needs are mentioned, but it's fairly transparent about what the tool does.

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

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

The description is detailed but front-loaded with the purpose and list of yogas. Every sentence adds value, though it could be slightly more 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?

Given the complexity of detecting 12 yogas with specific rules and no output schema, the description does a good job explaining the output format and sources. It could mention error cases but is fairly 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 baseline is 3. The description does not add meaning beyond what the schema already provides for each parameter. It mentions 'birth data' but does not elaborate on 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 clearly states it detects 12 classical Vedic yogas and lists them. It distinguishes from sibling tools get_vedic_astrology_yoga and get_vedic_astrology_yoga_id by noting they are dictionary lookups while this computes from birth 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 contrasts this 'chart-driven detection' with dictionary lookup tools, implying use when actual yoga detection from birth data is needed. It could be more explicit about when not to use, but the differentiation is strong enough.

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