Server Quality Checklist

Tool Scores

• get_janam_kundaliA
  4.4/5.0
  Behavior4/5

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

  Description adds behavioural context beyond annotations: mentions deterministic computation, Swiss Ephemeris, rate limits, and accuracy dependency on birth-time precision. Annotations already declare readOnlyHint=true and destructiveHint=false, so the description reinforces and adds specifics without contradiction.

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

  Conciseness4/5

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

  Description is front-loaded with the main purpose and then details. It is comprehensive but not overly verbose; each sentence adds value. Could be slightly more concise, but structure is good.

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

  Completeness5/5

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

  Despite no output schema, the description thoroughly explains the output contents (lagna, grahas, dasha, yogas) and notes omissions for present-moment charts. Also covers accuracy dependencies, making the tool's behavior well-understood.

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

  Parameters3/5

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

  Schema coverage is 100% with each parameter having a good description. The tool description does not add significant additional meaning beyond what is in 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.

  Purpose5/5

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

  Description clearly states the tool returns a full Vedic birth-chart summary for one person, listing specific elements (lagna, grahas, dasha, yogas). It also distinguishes from sibling tools by naming alternatives for narrower queries.

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

  Usage Guidelines5/5

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

  Explicitly says 'Use this when the user wants their whole chart read' and lists four alternative sibling tools with specific narrow scopes, providing clear when-to-use and when-not-to-use guidance.

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

• get_kundli_matchA
  4.5/5.0
  Behavior5/5

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

  Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds significant value beyond annotations: it states 'Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools.' This discloses rate limits, computational method, and authentication requirements. There is no contradiction with annotations.

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

  Conciseness4/5

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

  The description is well-structured and front-loaded with the core purpose, followed by usage guidance, behavioral details, and rate limits. However, it is somewhat verbose and could be more concise. For example, the mention of 'no writes, no auth' is repeated in rate limit context. Overall, every sentence serves a purpose, but some redundancy exists.

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

  Completeness4/5

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

  Given the complexity of the tool (nested objects, no output schema), the description provides a comprehensive overview of the output: eight koots with points, total, dosha, cancellation, and verdict. It also addresses the distinction from check_manglik and specifies rate limits. However, it does not describe the exact structure of the output, which could be helpful for an agent to parse the response. The absence of an output schema makes this a minor gap, but overall it is sufficient for understanding what the tool does.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The tool description does not add significant new information beyond what is in the schema; it mostly reiterates that birth time is required and that place can be replaced with coordinates. This provides minimal additional value, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states it returns classical Ashtakoot marriage compatibility, listing components like eight koots, total out of 36, dosha, cancellation, and verdict. It distinguishes itself from sibling tool get_love_compatibility, calling it 'name-numerology entertainment' and explicitly says it is not a substitute. It also clarifies that nadi/bhakoot dosha reported is chart-pair compatibility, not individual Mars dosha, directing to check_manglik for that purpose.

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

  Usage Guidelines5/5

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

  The description explicitly says 'Use this whenever real marriage matching is asked for.' It tells when not to use it: get_love_compatibility is not a substitute. It provides clear guidelines on when to use check_manglik instead for individual Mars dosha. It also specifies that both people need an exact birth time and place.

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

• get_love_compatibilityA
  4.5/5.0
  Behavior5/5

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

  Descriptions adds details beyond annotations: deterministic arithmetic, no ephemeris or birth details, no writes, no auth, and rate limit of 30 req/min/IP. All consistent with readOnlyHint, idempotentHint, and destructiveHint annotations.

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

  Conciseness4/5

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

  Description is moderately sized and well-structured, starting with main purpose then caveats, comparison, and technical details. Slightly verbose but each sentence adds value.

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

  Completeness4/5

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

  Despite no output schema, the description explains the return includes a 0-100 score, short reading, and band. It covers input validation, behavior, and limitations adequately for a simple tool. Minor gap: exact JSON structure not specified.

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

  Parameters3/5

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

  Schema covers 100% of parameters with descriptions. The description mentions name reduction and digit mapping but doesn't add significant meaning beyond the schema. Baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool computes a name-compatibility score using Pythagorean numerology. It specifies the verb ('Returns'), the resource ('name-compatibility score'), and the method, distinguishing it from sibling tools like get_kundli_match.

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

  Usage Guidelines5/5

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

  Explicitly advises use only for entertainment and warns against using it for real relationship decisions, directing users to get_kundli_match for genuine matching. This provides clear when-to-use and when-not-to-use guidance.

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

• check_manglikA
  4.6/5.0
  Behavior5/5

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

  Annotations already indicate readOnlyHint and idempotentHint. The description adds 'Read-only deterministic computation', 'no writes, no auth', specific rate limits (30/min/IP per instance, 60/min/IP shared engine budget), and clarifies that remedies are 'reported as data not advice'. This extends well beyond the annotations.

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

  Conciseness4/5

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

  The description is fairly concise but covers all necessary aspects. It is front-loaded with the primary purpose, then includes usage guidance, sibling distinctions, and behavioral details. A few sentences could be trimmed, but overall it is well-organized and efficient.

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

  Completeness5/5

  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 thoroughly explains what is returned (yes/no, severity levels, reference points, cancellations, remedies). It also covers input constraints (required fields, place vs. coordinates), rate limits, and engine budgets. It provides complete context for an agent to understand and use the tool.

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

  Parameters3/5

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

  Schema coverage is 100% with detailed descriptions for all 6 parameters. The tool description does not add new meaning beyond what the schema already provides; it only reiterates usage context. Baseline score of 3 is appropriate as the schema carries the full burden.

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

  Purpose5/5

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

  The description clearly states the verb 'returns' and the specific resource 'Manglik verdict for ONE person's birth chart', listing all output components (yes/no, severity, reference points, cancellations, remedies). It distinguishes from sibling tools like get_kundli_match and check_kaal_sarp, 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.

  Usage Guidelines5/5

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

  Explicitly tells when to use ('am I manglik' questions, before marriage discussion) and when not to (use get_kundli_match for two-chart compatibility, check_kaal_sarp for Rahu-Ketu dosha). Also provides rate limits and auth/engine constraints, giving clear guidance on appropriate use.

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

• get_dasha_periodsA
  4.6/5.0
  Behavior5/5

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

  Annotations already indicate readOnlyHint, idempotentHint, and non-destructive. The description adds significant context: computation source (Swiss Ephemeris, Lahiri ayanamsa), no auth, rate limits (30 req/min/IP endpoint, 60 shared), and that dates shift with birth-time accuracy. 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.

  Conciseness4/5

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

  The description is thorough and well-structured, with every sentence contributing value. It covers return types, edge cases, usage, limitations, and technical details. While not overly verbose, it could be slightly tighter; however, it is very effective.

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

  Completeness5/5

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

  Given the complexity of the tool (no output schema, 6 parameters), the description is highly complete: it explains return structure, edge cases, usage examples, limitations, rate limits, and even suggests another tool. It provides all necessary context for an agent to use it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100% with detailed descriptions for all 6 parameters. The description does not add new meaning to parameters beyond what the schema provides, though it mentions an edge case (present moment) relevant to usage but not to parameter values. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states it returns the Vimshottari dasha timetable, listing specific components (current periods with end dates, birth mahadasha with balance, full lifetime timeline) and distinguishes from siblings by noting that for planet placements one should call get_janam_kundali.

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

  Usage Guidelines5/5

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

  It explicitly tells when to use the tool ('which dasha am I in', 'when does my Saturn mahadasha start') and when not to use it (for interpretation or planet placements), and provides an alternative tool (get_janam_kundali). It also clarifies the is_birth_fallback edge case.

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

• get_panchangA
  4.6/5.0
  Behavior5/5

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

  Annotations declare readOnlyHint, idempotentHint, etc. Description adds deterministic computation via Swiss Ephemeris, Lahiri ayanamsa, no writes, no auth, rate limits (30 req/min/IP + shared budget), and that window times are based on actual sunrise/sunset. This provides rich behavioral context beyond annotations.

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

  Conciseness4/5

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

  5 sentences, front-loaded with main output, minimal waste. Every sentence adds value, though slightly long for a concise definition. Still well-structured and efficient.

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

  Completeness5/5

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

  Given no output schema and a complex tool with many output components, the description enumerates all major outputs and adds rate limit and auth details. It is comprehensive enough for an agent to understand what the tool provides and how to use it.

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

  Parameters4/5

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

  Schema already describes all 5 parameters (100% coverage). Description adds that date can be omitted for today, place is geocoded server-side, timezone must be IANA (not offset), and lat/lon required when place omitted. This adds meaningful usage context.

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

  Purpose5/5

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

  Description clearly states it returns the Hindu panchang for one date at one place, enumerating the five angas, lunar month, sunrise/sunset, muhurta, choghadiya, and inauspicious periods. It also distinguishes from siblings like get_muhurta_timings and get_birth_details, making the purpose precise.

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

  Usage Guidelines4/5

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

  Explicitly says to use for 'what is today's panchang / tithi / nakshatra' questions and contrasts with get_muhurta_timings for full timing surface and get_birth_details for birth star. Could be more exhaustive about when not to use, but provides solid guidance.

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

• get_sade_satiA
  4.6/5.0
  Behavior5/5

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

  Annotations already mark readOnly, openWorld, idempotent, non-destructive. The description adds rate limits (30/min/IP per instance, 60/min/IP shared), computation source (Swiss Ephemeris, Lahiri ayanamsa), and clarifies that dates are computed, not predicted, and no interpretation is returned. 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.

  Conciseness4/5

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

  The description is slightly long but well-organized with front-loaded return details, followed by usage, then behavioral notes. Each sentence adds value; could be trimmed slightly but still efficient.

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

  Completeness5/5

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

  Despite no output schema, the description fully explains the return values, the tool's scope, rate limits, and computational nature. It covers all necessary context for an agent to understand what to expect and how to use the tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so baseline 3 applies. The description does not repeat parameter details but does not need to; the schema's parameter descriptions are already thorough.

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

  Purpose5/5

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

  The description clearly states the tool returns Sade Sati status and lists specific outputs (phase, dates, etc.). It distinguishes from the sibling tool get_transits by specifying this is Saturn-only, which helps the agent choose correctly.

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

  Usage Guidelines5/5

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

  Explicitly provides usage scenarios: 'when does my sade sati start/end' and 'am I in shani sade sadi'. Also gives a clear alternative: for all grahas, use get_transits.

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

• check_kaal_sarpA
  4.8/5.0
  Behavior5/5

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

  Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false), the description adds that it is a deterministic computation using Swiss Ephemeris and Lahiri ayanamsa, mentions no writes or auth, and specifies rate limits (30 requests/min/IP per server instance, plus shared engine budget of 60/min/IP). This adds significant 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.

  Conciseness4/5

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

  The description is a single paragraph of dense but well-organized information. It is front-loaded with the main verdict and types, and covers usage, behavior, and constraints. A bit more structure (e.g., separate sentences for different aspects) could improve readability, but it is effective and concise.

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

  Completeness5/5

  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 what the tool returns (yes/no, type, hemming, houses, explanation). It covers computational details, rate limits, and the need for exact birth time. For a tool with 6 parameters and no output schema, this is complete and provides all necessary context.

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

  Parameters4/5

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

  Schema coverage is 100% so the description doesn't need to add much, but it provides extra context: it notes that partial hemming can flip with time errors, and clarifies the coordinate/timezone alternative for the place parameter. This adds value beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool returns a yes/no Kaal Sarp dosha verdict for one birth chart, plus the specific type, hemming status, houses involved, and a plain explanation. It distinguishes itself from sibling tools like check_manglik and get_kundli_match by explicitly naming them as different doshas.

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

  Usage Guidelines5/5

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

  The description explicitly says 'Use this for do I have kaal sarp dosh questions' and provides clear guidance on when not to use it (for manglik or kundli match, use separate tools). It also warns that partial hemming can flip with a few minutes' error, emphasizing the need for exact birth time.

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

• get_pancha_pakshiA
  4.8/5.0
  Behavior5/5

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

  Beyond annotations (readOnlyHint, idempotentHint, etc.), the description details computational specifics (Swiss Ephemeris, Lahiri ayanamsa), rate limits (30 req/min/IP, shared 60/min/IP), place-specificity due to sunrise/sunset, and confirms no writes or auth. This adds significant 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.

  Conciseness4/5

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

  The description is relatively long but every sentence is informative. It could be slightly more concise, but it is well-structured with clear sections and front-loads key information.

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

  Completeness5/5

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

  Given 7 parameters, no output schema, and complex functionality, the description is highly complete. It explains the output structure (yaamas, acting birds, sub-periods, strength ratings, relations) and operational details, making it self-contained.

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

  Parameters4/5

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

  Schema covers 100% of parameters, so baseline is 3. The description adds value by explaining the roles (e.g., 'birth fields identify the person; date picks the day') and providing geocoding details for place. It enhances understanding beyond schema alone.

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

  Purpose5/5

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

  The description uses a specific verb 'Returns' and clearly identifies the resource as a 'PERSONAL timing schedule under Tamil Pancha Pakshi Shastra'. It distinguishes the tool from siblings get_muhurta_timings and get_panchang by explaining this tool is personalized.

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

  Usage Guidelines5/5

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

  Explicitly states 'Use this when the user wants timings tuned to THEM' and contrasts with sibling tools that give generic windows. Also mentions the two systems can disagree, providing clear guidance on when to use.

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

• get_transitsA
  4.8/5.0
  Behavior5/5

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

  Beyond annotations, the description adds: read-only deterministic computation, Swiss Ephemeris, Lahiri ayanamsa, no writes/auth, and that a call with 'natal' costs two requests. 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.

  Conciseness4/5

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

  Well-structured and front-loaded, but somewhat long. Every sentence is informative, so still earns a high score.

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

  Completeness5/5

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

  Given no output schema, the description details what is returned (positions, houses, nakshatra, etc.), explains the frame, and notes rate limits. Complete for a complex tool.

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

  Parameters4/5

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

  Schema coverage is 100% with detailed param descriptions. The description adds context for defaults and the effect of the 'natal' parameter on output, but the schema already does heavy lifting.

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

  Purpose5/5

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

  The description clearly states the tool returns planetary positions in a transit chart, with specific details like sign, degree, nakshatra, and house. It distinguishes from siblings like get_janam_kundali and get_sade_sati.

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

  Usage Guidelines5/5

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

  Explicitly says 'Use this for' and 'do not scan it across many dates to find them', and names alternative tools for birth chart and dated Saturn phases.

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

• get_birth_detailsA
  4.9/5.0
  Behavior5/5

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

  Adds significant context beyond annotations: deterministic computation using Swiss Ephemeris, Lahiri ayanamsa, whole-sign houses; no writes, no auth; rate limits per server instance. Annotations already declare readOnly and idempotent, but description enriches understanding.

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

  Conciseness5/5

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

  Single well-structured paragraph, front-loaded with returns, then usage, then limitations, then behavioral notes. Every sentence earns its place, no redundancy.

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

  Completeness5/5

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

  Thorough explanation of all 6 parameters, despite no output schema. Covers parameter dependencies (place vs lat/lng/timezone), purpose, limitations, rate limits, and sibling tool comparisons. Complete for a read-only deterministic tool.

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

  Parameters4/5

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

  Schema coverage is 100%, baseline 3. Description adds extra meaning: explains place format, clarifies that birth_time is local clock not UTC, explains alternative for latitude/longitude/timezone use, and validates dates. Adds moderate value beyond schema.

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

  Purpose5/5

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

  Description explicitly states it returns identity fields of Vedic birth chart (nakshatra, rashi, lagna, navamsa lagna) and contrasts with sibling tools like get_janam_kundali which include planet tables. Clear verb+resource with sibling differentiation.

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

  Usage Guidelines5/5

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

  Explicitly states when to use: 'common single questions' and 'to fetch values that get_muhurta_timings accepts'. Also states when NOT to use: for planet table, yogas, dashas, and names alternatives (get_janam_kundali, get_dasha_periods).

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

• get_eclipsesA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds deterministic computation (Swiss Ephemeris, Lahiri ayanamsa), caching behavior with possible 30s recompute, rate limits, year range constraints, and city snapping. 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.

  Conciseness4/5

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

  Description is comprehensive but slightly lengthy. However, it is well-structured with front-loaded return information and clear sections. A minor trim could improve conciseness.

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

  Completeness5/5

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

  Given no output schema, the description sufficiently details return fields (eclipse type, date, times, magnitude, locally_visible flag). Also covers behavioral aspects like caching and rate limits. Complete enough for an agent.

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

  Parameters5/5

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

  Schema has 100% coverage for both parameters. Description adds meaningful extra context: default city (Delhi), snapping to 50 supported cities, year range limit (current year ±2).

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

  Purpose5/5

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

  Description clearly states it returns solar and lunar eclipses for a year with local visibility for a city. It distinguishes from siblings by explicitly naming get_year_events and get_panchang for other purposes.

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

  Usage Guidelines5/5

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

  Provides explicit guidance: use for eclipses and visibility questions and sutak timing; mentions alternatives for festivals (get_year_events) and daily almanac (get_panchang).

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

• get_mobile_numerologyA
  4.9/5.0
  Behavior5/5

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

  Description adds value beyond annotations: 'read-only deterministic arithmetic over a fixed number table -- no ephemeris, no network lookup, no writes, no auth, at least 30 requests/min/IP per server instance.' Annotations already declare readOnlyHint, idempotentHint, destructiveHint; description provides concrete details.

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

  Conciseness5/5

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

  Two sentences, no waste. First sentence lists outputs, second gives usage guidance and behavioral details. Front-loaded with key purpose.

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

  Completeness5/5

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

  Even without output schema, description lists all return values (digit string, total, etc.). Also covers rate limit, authentication, and distinguishes from sibling. Complete for a deterministic read-only tool.

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

  Parameters4/5

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

  Input schema has one parameter with 100% description coverage. Description adds context: accepts various formats like +91 98765-43210, strips non-digits, must contain at least one non-zero digit. This exceeds schema description.

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

  Purpose5/5

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

  Description clearly states it returns numerological reading of a phone number, listing specific outputs (digit string, total, reduced number, vibe, meaning). Distinct from sibling get_numerology by specifying it's for phone numbers only, not birth dates.

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

  Usage Guidelines5/5

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

  Explicitly says to use for 'is my phone number lucky' style questions or when choosing candidate numbers. Also states when not to use: for birth date queries, use get_numerology.

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

• get_muhurta_timingsA
  4.9/5.0
  Behavior5/5

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

  Adds details beyond annotations: read-only deterministic computation, no auth, rate limits, handling of unknown windows by including them as 'unknown' rather than omitting. No contradiction with annotations.

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

  Conciseness4/5

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

  Front-loaded with main purpose, but then includes a long list of all windows which is informative but slightly verbose. Still efficient given the detail needed.

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

  Completeness5/5

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

  Covers all aspects: what is returned, usage, behavioral traits, rate limits, computation details, missing data handling, and sibling comparisons. No output schema, so description compensates adequately.

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

  Parameters5/5

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

  Schema coverage 100% but description adds value: explains optionality behavior (omit date for today, omit janma_rashi/nakshatra removes those blocks), trade-off between place and lat/lon/timezone, and provides examples.

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

  Purpose5/5

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

  Description clearly states it returns all auspicious/inauspicious windows for one date/place. Lists specific windows. Distinguishes from siblings get_panchang and get_pancha_pakshi with explicit when-to-use guidance.

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

  Usage Guidelines5/5

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

  Explicitly says use to CHOOSE a moment, and points to alternatives for simpler panchang or personalized timing. Also clarifies it operates on one date and one place.

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

• get_numerologyA
  4.9/5.0
  Behavior5/5

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

  Annotations declare readOnly, idempotent, non-destructive. Description adds deterministic arithmetic, no ephemeris, no writes, no auth, rate limit 30/min/IP, and that Source line reflects this. No contradiction.

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

  Conciseness5/5

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

  Well-structured, front-loaded with outputs, then usage, then exclusions, then behavioral details. No wasted words; each sentence serves a purpose.

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

  Completeness5/5

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

  Despite no output schema, description thoroughly explains return values (mulank, bhagyank, lucky attributions, optional naam-ank). Covers constraints, rate limits, and auth. Complete for a tool with 2 params.

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

  Parameters4/5

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

  Schema has 100% coverage with good descriptions. Description adds context: name is optional for Chaldean number, birth_date must be real calendar date, time/place not used. Adds extra meaning beyond schema.

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

  Purpose5/5

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

  The description clearly states it returns Vedic numerology from date of birth, listing specific outputs (mulank, bhagyank, lucky attributions) and distinguishes it from astrology and chart tools. It differentiates from sibling tools like get_janam_kundali and get_birth_details.

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

  Usage Guidelines5/5

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

  Explicitly tells when to use: 'when the user asks about their number, life path or lucky colour/day/stone.' Provides alternatives for birth chart and birth star. Also clarifies that birth time/place are not needed.

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

• get_upapada_arudhaA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context: deterministic computation using Swiss Ephemeris, Lahiri ayanamsa, no writes or auth, rate limits (30/min/IP per endpoint, 60/min/IP shared engine budget), and handling of partial results ('partial: true' on engine failure). 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.

  Conciseness4/5

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

  The description is well-structured with clear sentences separated by period, but somewhat lengthy. It front-loads the returned items and then adds usage and parameter details. Every sentence adds value, though a minor trim (e.g., removing 'at least' and 'plus' in rate limit sentence) could improve conciseness. Still, no wasted words.

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

  Completeness5/5

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

  Given the tool's complexity (6 parameters, no output schema), the description covers all important aspects: what is returned (UL, A1-A12, charakarakas, karakamsha, classical texts), usage context (Jaimini vs Parashari), behavior (deterministic, read-only, rate limits), and error handling (partial results). It is fully informative for an AI agent to select and invoke correctly.

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

  Parameters5/5

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

  Schema coverage is 100% (all 6 parameters described in schema). The description adds meaningful context beyond schema: explains the preferred input (place as free text), alternative lat/lon/timezone with requirements, timezone format (IANA, not offset), date format (Gregorian YYYY-MM-DD, range 1200-2400), time format (HH:MM local, required), and rationale for requiring time ('the ascendant moves about one degree every four minutes').

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

  Purpose5/5

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

  The description clearly states the tool returns the Jaimini layer including upapada lagna, arudha padas, charakarakas, and karakamsha lagna. It distinguishes from sibling tools like get_janam_kundali (Parashari layer) and get_kundli_match (scoring two charts). The verb 'Returns' with specific resources makes the purpose explicit.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use: 'Use this only when Jaimini terms are asked for by name -- upapada, arudha, charakaraka, karakamsha -- or for marriage questions read the Jaimini way.' It also tells when not to use by directing to sibling tools for Parashari (get_janam_kundali) and chart matching (get_kundli_match).

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

• get_year_eventsA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds computational details (Swiss Ephemeris, cache, ~30s cold recompute), rate limits (30/min/IP per instance, 60/min/IP shared), and safety (no writes, no auth). No contradiction.

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

  Conciseness4/5

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

  Single paragraph but well-organized: purpose, categories, usage guidance, sibling alternatives, behavioral notes. Every sentence adds value; minor opportunity for bullet points.

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

  Completeness5/5

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

  Covers constraints (year range, city snapping, row cap), output structure (date, name, significance), and explains why city matters (longitude differences). No output schema, so description compensates well.

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

  Parameters5/5

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

  All 4 parameters have schema descriptions (100% coverage). Description adds context: year constraints, city snapping to nearest of 50, month for pagination, and category enum meanings with examples.

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

  Purpose5/5

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

  Description clearly states it returns dated Hindu calendar events for a year at a city, lists examples (Holi, Diwali, ekadashi), and distinguishes from siblings like get_panchang and get_eclipses.

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

  Usage Guidelines5/5

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

  Explicitly says when to use ('when is X this year', 'list all ekadashi dates') and when not (single day detail → get_panchang, eclipses → get_eclipses). Also mentions constraints like year range and pagination.

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