Asterwise
OfficialServer Quality Checklist
Latest release: v0.1.0
- Disambiguation3/5
The DO NOT CONFUSE WITH sections are exemplary and do heavy lifting, but 103 tools across heavily overlapping clusters (5 crystal tools, 9 tarot tools, 4 Vedic compatibility tools, 3 western transit variants, 4 dasha systems) still create significant selection risk. The pair asterwise_get_gemstone_recommendations and asterwise_get_crystal_recommendations_natal is genuinely hazardous — both derive gem/crystal prescriptions from natal charts using different engines.
Naming Consistency4/5Nearly every tool follows asterwise_get_<resource> in clean snake_case, and within-domain suffixes (varshaphal, varshaphal_saham, varshaphal_harsha_bala) are highly predictable. The deviations — check_sade_sati, check_mobile_number, check_vehicle_number, draw_tarot_cards — are semantically justified but break the dominant get_ pattern, preventing a 5.
Tool Count2/5103 tools is extreme by any standard, quadruple the 25+ threshold from the calibration rubric. Even granting the server's broad multi-domain scope (Vedic astrology, Western astrology, numerology, tarot, crystals, dreams, remedies), the surface is fragmented into overly granular endpoints: three transit-window variants, six individual numerology number calculators that duplicate the existing profile tool, and nine tarot tools.
Completeness4/5Coverage is exhaustive for a read-only computational API: all major dasha systems, transits, multiple compatibility traditions, panchanga/muhurta, remedies, Western returns/progressions/synastry, numerology systems, tarot spreads, crystals, and dream symbols. Minor gaps — no standalone current-planetary-position ephemeris tool, no Vedic moon-sign-only endpoint, no house-system override for Vedic charts — are workable but not fatal.
Average 4.5/5 across 103 of 103 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 33 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 8 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the annotations (readOnly, idempotent, non-destructive) but does not add any extra behavioral context such as side effects, rate limits, or authorization requirements. Since annotations already cover the key traits, this is acceptable but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the essential functionality without unnecessary detail or fluff. It is highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a basic idea of what the tool does but lacks context about the nature of Prashna (horary astrology) or any specifics about the expected output format. It is adequate for a simple task but not comprehensive given the complex nested input and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps the main parameters (date, time, place, keyword) to meaningful roles, but it omits mention of ayanamsa and response_format, which are present in the schema. It provides partial semantic coverage but not full parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (casting a Prashna chart) and the key inputs (date, time, place, keyword) and outputs (houses, Moon diagnostics, verdict, cusps). It is slightly generic but sufficient for a high-level understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling tools (e.g., natal, KP, compatibility). It does not differentiate use cases, leaving the agent to infer from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, which cover the tool's safety profile. The description does not contradict these annotations and adds no behavioral details beyond what annotations provide, so a neutral score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for workflow, input contract, and confusion avoidance. It is a bit verbose but remains organized and easy to follow. The length is justified by the additional clarifying information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits any explanation of the 'response_format' parameter, which is present in the schema. Additionally, the schema description for 'name' is incorrect and does not match the purpose or the INPUT CONTRACT. These gaps hinder an agent from fully understanding the tool's inputs and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the 'name' parameter is completely mismatched: it says 'Person's full name as commonly written; letters are converted to numerology values', which contradicts the tool's purpose of looking up a crystal. Although the description text's INPUT CONTRACT correctly states 'crystal slug or display name', the schema description itself is misleading and would cause an agent to misuse the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up a specific crystal by slug or name and returns full details including planetary assignments, healing properties, and safety cautions. It also explicitly distinguishes itself from sibling tools via the 'DO NOT CONFUSE WITH' section, listing alternative crystal-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives by listing asterwise_get_crystals, asterwise_get_crystal_by_planet, and asterwise_get_gemstone_recommendations as distinct options. It also mentions that this tool can be used standalone or after another tool, giving contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, non-destructive, and openWorld=false. The description adds that it is standalone and that input is validated upstream, providing a small amount of extra context about side effects and error handling. However, the description does not elaborate on output behavior or error responses, so the added transparency is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (description, workflow, input contract, do-not-confuse, link). The main functionality is stated in one concise sentence, and the additional sections are brief and purposeful. It is slightly longer due to the exclusions, but remains efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions the key outputs (planes, missing/repeated digits, per-digit traits) and provides a link to the full output and error contract. However, the output schema is not included in the prompt, and the description does not explain the output structure beyond those annotations, nor does it elaborate on error cases. The link helps but is not directly accessible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema states 'date' is required, but the description says 'Defaults to today when omitted' – a direct contradiction. Additionally, the 'INPUT CONTRACT' line says 'date string only' while the schema includes a second parameter, response_format. This inconsistency and omission undermine the clarity of the two parameters, despite the schema descriptions being otherwise clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: deriving a Lo Shu three-by-three frequency grid from birth-date digits and annotating planes, missing/repeated digits, and per-digit traits. It also explicitly distinguishes itself from two similar siblings (numerology profile and name correction) by contrasting letter-based vs digit-based methods, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'DO NOT CONFUSE WITH' section gives explicit when-not-to-use guidance for two closely related tools (numerology profile and name correction), and the workflow section notes it is standalone. This helps an agent select the correct tool among many siblings, though it does not exhaustively list all alternative cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds that it returns data in UTC but does not elaborate on edge cases, input validation, or output structure beyond the listed elements. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It states the action, key input constraints, and output elements efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the output elements and specifies UTC, which is useful. It does not discuss error scenarios or validation details, but for a simple computation tool, the provided context is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description mentions 'one calendar date' and 'geographic location' mapping to the location object, but adds little beyond the schema's per-field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes Panchanga elements for a single calendar date at a geographical location, listing specific outputs (tithi, vara, nakshatra, yoga, karana, end times). This differentiates it from the sibling asterwise_get_panchanga_calendar, which covers a whole month.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single date but does not explicitly contrast with alternatives like asterwise_get_panchanga_calendar or asterwise_get_tamil_panchanga. No explicit 'when to use vs. 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnly, openWorld, idempotent, and destructive hints, so the description's omission of these details is acceptable. The description mentions defaulting behavior and validation of month range, which adds transparency. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear INPUT CONTRACT and WORKFLOW sections, is not overly verbose, and fronts the purpose. The repetition of 'Defaults' and 'DO NOT CONFUSE WITH' mirrors the schema descriptions but is acceptable. Slightly redundant with the schema but not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a full output schema and sibling context is provided, the description is complete enough. It clearly distinguishes from the single-day sibling and covers validation. The mention of the full output contract link adds completeness, though no detailed output fields are described in the description itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters with clear defaults and examples. The description itself does not add extra meaning beyond the schema, but the schema is already comprehensive. The response_format parameter is well described with enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns lunar phase data for every day in a month as a structured array, distinguishing it from the single-day sibling. The verb 'Returns' is specific, but it does not explicitly mention the output format for the array (e.g., JSON structure) beyond referencing the single-day object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a WORKFLOW section stating standalone and no after steps, and a DO NOT CONFUSE WITH section naming the alternative single-day tool. However, it does not explicitly say when to prefer this over the sibling or mention any prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover read-only, idempotent, and non-destructive behavior, and the description does not contradict them. It adds useful context about time sensitivity and the meaning of the score, but the erroneous 'time required' statement undermines transparency about actual parameter expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into sections (description, workflow, input contract, do-not-confuse) and is concise overall. However, it contains redundant mentions of the score range (e.g., 'Maximum 20 per planet' and 'out of 20') and a parameter-name error that adds noise without benefit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes a link to the full output/error contract, explains the tool's role within the Varshaphal workflow, and clarifies its relationship to sibling tools. The input contract's inaccuracies create some gaps in understanding the exact required parameters, but the availability of a schema and output schema mitigates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides comprehensive descriptions for all parameters, so the description's additional context is marginal. It clarifies that the year is not age and that time affects results, but the naming mismatch ('target_year' vs 'year') introduces confusion rather than adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool computes Harsha Bala for solar return charts, specifies the maximum score per planet (20) and its four components, and differentiates it from related tools. It leaves little ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow recommendations (use asterwise_get_varshaphal first to identify the Year Lord, then apply the output with asterwise_get_varshaphal_saham) and a clear 'DO NOT CONFUSE WITH' section. However, the 'INPUT CONTRACT' misnames the year parameter as 'target_year' instead of 'year' and incorrectly marks 'time' as required when the schema allows omission, which could mislead an agent during invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint, idempotentHint, destructiveHint) already cover the key behavioral aspects, and the description is consistent with them. The description adds some context about the calculation process but does not introduce any contradictions, so it slightly adds value 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for workflow, input contract, and distinctions, but it duplicates some information already present in the schema (e.g., the input contract). It is not overly verbose and provides necessary guidance, 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context about the tool's purpose and its relationship to other numerology tools, but the ambiguity around the required/optional nature of the 'date' parameter could lead to misuse. Given the complexity and many sibling tools, this is a notable gap that reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema covers all three parameters with descriptions, there is an internal inconsistency: the 'date' parameter's description states it 'Defaults to today when omitted' while the required array lists it as required. This ambiguity is not resolved in the main description, creating confusion about whether the date must be supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool calculates the Maturity number, which is the sum of Life Path and Expression numbers, and explains its meaning. It distinguishes itself from similar numerology tools like asterwise_get_numerology_profile and asterwise_get_personal_cycles, providing explicit 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'WORKFLOW' section that recommends running asterwise_get_numerology_profile first to confirm Life Path and Expression numbers, and a 'DO NOT CONFUSE WITH' section that clarifies differences from two other tools. This gives explicit guidance on when and how to use the tool relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's burden is lighter. It adds meaningful behavioral context: computation from sunrise/sunset, sixteen labeled segments, and an optional rahu_kaal overlay. It does not detail error behavior, but the docs link provides the full contract and 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into short labeled sections with the core purpose front-loaded. WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE, and the docs link each earn their place; there is no filler or redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and the description covers purpose, workflow, and alternatives, so much of the context is present. However, the misleading `location` description and lack of clarification about timezone/response_format behavior create a real gap for an agent constructing the required nested object. The docs link mitigates but does not fix the in-schema contradiction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high, but the nested `location` property description is misleading: it says a place name like 'Chennai, India' is an alternative to latitude/longitude/timezone, while the schema requires lat/lon and has no place-name field. The INPUT CONTRACT statement about YYYY-MM-DD and lat/lon ranges helps, but the contradictory parameter description undermines reliable invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Splits a solar day into sixteen Choghadiya segments' and names the output labels (quality, ruler, local clock bounds). The DO NOT CONFUSE section explicitly differentiates it from asterwise_get_hora and asterwise_get_muhurta, so an agent can distinguish it from siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section explicitly states BEFORE: None and AFTER: asterwise_get_rahu_kaal as an optional overlay. The DO NOT CONFUSE section names two alternatives and the distinguishing count/scope. This is explicit 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not add behavioral traits beyond the annotations. The annotations already declare readOnlyHint: true, idempotentHint: true, and destructiveHint: false, and the description is consistent with these. It explains the computational method but that is functional, not behavioral (e.g., side effects, rate limits). Since the annotations already cover safety aspects, the description adds no extra behavioral context, hence a neutral score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and contains useful disambiguation. However, some redundancy exists: the 'DO NOT CONFUSE WITH' section repeats the same contrast twice (e.g., 'uniform arc vs individual motion' and 'real-time sky, not symbolic progression'). Overall it is concise and informative, but slightly repetitive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides rich context: the exact formula (1 ephemeris day = 1 tropical year = 365.2421904 days), the workflow sequence, and clear differentiation from related tools. It also mentions the output content (progressed planets, Ascendant, MC, solar arc). This gives the agent a complete understanding of the tool's purpose and relationship to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of parameters with detailed descriptions (e.g., birth object fields, target_date, response_format). The description text repeats the same information (e.g., 'target_date (optional YYYY-MM-DD) — the date to progress to. Defaults to today.') without adding new semantic detail. Thus it meets the baseline for complete schema coverage but adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Secondary progressed chart using the day-for-a-year method' and explicitly lists what it returns: '10 progressed planet positions, progressed Ascendant and MC, and the solar arc.' This leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool via the 'WORKFLOW' section (BEFORE: asterwise_get_western_natal, AFTER: asterwise_get_western_solar_arc) and the 'DO NOT CONFUSE WITH' section, which distinguishes it from solar arc (uniform motion) and transits (real-time sky). This is excellent usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive, so the description doesn't need to restate that. It adds valuable context by explaining the computational method (date digits summed and reduced to a single digit, then tripled) and offering a link to the full output/error contract, which covers any missing edge-case details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and is front-loaded with the primary purpose. It is slightly lengthy due to the distinctions and workflow notes, but every sentence serves a purpose, and the included docs link consolidates additional details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no required params, read-only), the description is complete: it explains what it does, how it computed, when to use it vs. alternatives, and provides a docs link for errors/output. It doesn't explicitly mention response formats, but the schema already covers that, and the workflow note clarifies its standalone nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the single optional parameter (response_format) with enum and default, achieving 100% coverage. The description adds context that no required parameters exist and that the date is automatically derived, but this relates to operational behavior rather than enhancing parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns today's angel number computed from the current date, with a specific algorithm (sum and reduce digits). It explicitly distinguishes itself from sibling tools via the 'DO NOT CONFUSE WITH' section, naming asterwise_get_angel_number and asterwise_get_angel_number_personal and their 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: the 'WORKFLOW' section states it is standalone and suggests when to use the personal angel number tool afterward. The 'DO NOT CONFUSE WITH' section clarifies when to use alternative tools (specific number lookup vs. personalized from birth date), leaving no ambiguity about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context by stating it 'scores' and 'returns' data, implying no mutation. It also notes 'All scoring is computed upstream from those payloads,' clarifying the input handling. No contradiction with annotations, and the description adds modest 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for workflow and exclusions, and the main purpose is stated in one sentence. It includes a link to the full contract and helpful context without excessive verbosity. The extra sections add value and are not redundant, so it earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for a complex astrological tool: it mentions the expected output (koota breakdown, dosha flags, etc.), gives workflow recommendations, names sibling tools to avoid confusion, and links to the full output/error contract. While the output schema is not inline, the link covers it, and the description is complete enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (person1, person2, response_format) fully described. The description adds minimal parameter-specific info, only mentioning 'Two BirthData objects follow the global contract' and 'unknown midnight time accepted without flag,' which slightly supplements the schema. Since the schema already covers semantics thoroughly, 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: scoring North Indian Ashtakoota (36-point Guna Milan) for two charts and returning a breakdown, dosha flags, classical vetoes, mangal cross-check, and narrative guidance. It distinguishes from similar tools via the 'DO NOT CONFUSE WITH' section naming dashakoot and porutham, so an agent can select it correctly without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when to use this tool: before interpreting scores, a natal chart is recommended; after, papasamyam is an optional overlay. It also explicitly names alternatives (dashakoot, porutham) and explains why they are different, giving clear guidance on 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral details such as case-insensitive lookup, standalone execution, and the dual-tradition output, which go beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for workflow, input contract, and sibling-tool distinction. It stays concise while front-loading the core purpose, and the documentation link avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides workflow context, example inputs, a contrast with the sibling tool, and a link to the full output/error contract. It lacks explicit output field details here, but the documentation link and output-schema indication make it sufficient for this read-only lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema's description for 'name' is semantically wrong, describing a person's full name for numerology instead of a dream symbol slug or display name. The surrounding INPUT CONTRACT and examples partially correct this, and response_format is well described, but one of the two parameters is actively misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Lookup'), a specific resource ('dream symbol'), and a clear scope ('by slug or name, case-insensitive'). It also explicitly distinguishes itself from asterwise_get_dream_symbols, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'DO NOT CONFUSE WITH' note directly tells the agent when to use this tool versus the full listing tool, and the WORKFLOW section states it is standalone with no prerequisites. Example inputs further clarify the expected name values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety and side-effect transparency. The description is consistent with these annotations—'Builds' implies generating calculations without modifying any stored state. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear headers (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and stays focused. It is slightly longer than necessary but every section adds value, especially the disambiguation from siblings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the core purpose and output tags, but it fails to resolve the location parameter conflict and does not clarify how the date/timezone/lat/lon interplay works. The response_format field is referenced only in the schema, not explained. Overall, enough for basic use but gaps remain due to the location ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The location parameter description says 'Place name, e.g. 'Chennai, India'. Alternative to giving latitude, longitude and timezone.' but the schema requires lat, lon, and date as required properties within an object. This directly conflicts—an agent would be confused whether to pass a string or an object. The individual field descriptions are clear, but the top-level parameter semantics are misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Builds', the resource 'twenty-four planetary Horas', the scope 'between successive sunrises for a location date', and the output details (ruler, quality text, current status). It also differentiates from sibling tools like choghadiya and natal chart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section explicitly says it is standalone and points to asterwise_get_choghadiya as an alternative same-day slot system. The DO NOT CONFUSE WITH section clearly distinguishes Horas from choghadiya (16 vs 24 segments) and natal chart, giving agents clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe, non-mutating behavior is known. The description adds that it computes and returns house tables plus planet-tier reverse indexes, providing useful context, but it does not describe output details or potential side effects beyond what the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is direct and free of filler, combining the core purpose, workflow prerequisite, and disambiguation in a compact structure. Each sentence serves a distinct informative purpose, and the optional 'Full output and error contract' link is a reasonable addition rather than unnecessary bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested birth object and three parameters, the description plus full schema coverage provides all necessary operational context. It includes the recommended preceding workflow, clarifies sibling distinctions, summarizes the return content, and references the full output/error contract, making the tool self-sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for every parameter, including nested birth fields, house_number, and response_format. The description itself adds little beyond the schema, merely restating optionality of house_number and the input source, so it does not significantly enhance parameter understanding above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Computes'), a precise resource ('KP significator chains'), and a clear scope ('for all houses or one optional house from BirthData'). It also names the primary sibling tools to avoid confusion with, making the tool's unique purpose immediately identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The workflow section explicitly recommends calling asterwise_get_kp_chart before this tool to establish cusps, giving clear when-to-use direction. The 'DO NOT CONFUSE WITH' section further clarifies how this tool differs from related KP and natal chart tools, so an agent can select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and non-destructive; the description adds that it computes from birth data and points to a full output/error contract. No contradictions with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured with WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE, and a link to the full contract. Purpose is front-loaded; some repetition with the schema exists but it is not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, workflow, key input defaults, sibling distinctions, and directs users to the full output/error contract. Since an output schema exists, detailed return-value explanation is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter already has descriptions, defaults, formats, and enums. The prose input contract mostly restates the schema and omits response_format and ayanamsa, so it adds little beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Returns a personalised daily prediction using Tarabala and Chandrabala', giving a specific verb, resource, and method. It also explicitly names sibling tools not to confuse with, making its scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-not-to-use guidance via 'DO NOT CONFUSE WITH' for nakshatra_details, panchanga, and biorhythm, and adds a workflow note that panchanga should follow for full daily context. This clearly distinguishes it from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description does not need to repeat these. The description adds useful context like 'upstream validates' and 'echoes recommendation stub fields,' which aligns with a non-modifying operation. No contradictions exist between the description and annotations, and the description does not introduce any misleading side-effect claims. However, it does not explicitly describe potential errors or rate limits, but annotations reduce the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized, using clear section headers (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) to separate purpose, prerequisites, and disambiguation. It front-loads the primary purpose in the first sentence and avoids redundant elaboration. The inclusion of a link to the full output/error contract keeps the description concise while providing access to deeper details. It is slightly verbose with multiple sections, but each contributes to usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for an agent to understand the tool's role within the larger context of sibling tools. It provides workflow context (recommended predecessor), clarifies boundaries versus similar tools, and points to a full output/error contract. Since an output schema is indicated (has output schema: true), the description does not need to enumerate return fields; however, the phrase 'echoes recommendation stub fields' is somewhat ambiguous and could benefit from a brief explanation, but the link covers details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters (name, date, response_format), each with detailed descriptions. The description merely restates the schema constraints ('name and date strings only; upstream validates') without adding additional meaning beyond what is already in the input schema. For example, the schema already explains that name letters are converted to numerology values and that date defaults to today. Since coverage is high and the description does not introduce new semantics, 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Scores the current spelling of a personal name against the birth-date Life Path, suggests alternate spellings with harmony metrics, and echoes recommendation stub fields.' This provides a specific verb (scores, suggests, echoes), a specific resource (personal name, birth-date Life Path), and distinguishes it from related tools via the 'DO NOT CONFUSE WITH' section (e.g., business_name_analysis for entities, chaldean_numerology for Chaldean compounds).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance by naming sibling tools and contrasting them: 'DO NOT CONFUSE WITH: asterwise_get_business_name_analysis — entity Expression scan, not personal spelling alternatives; asterwise_get_chaldean_numerology — Chaldean compounds, not harmony-scored spelling list.' It also specifies a recommended preceding workflow: 'BEFORE: RECOMMENDED — asterwise_get_numerology_profile — baseline numbers before renaming advice.' This tells an agent exactly when to use this tool and when to choose alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, and the description reinforces this by saying 'Looks up' and 'server-side'. It does not mention rate limits or auth, but the key non-mutating nature is well covered by both annotations and description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE WITH sections. It is slightly verbose and repeats some information, but the organization aids scanning and no sentence is purely filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema (true), the description does not need to detail return fields. It explains the input contract, the auto-selected year, the output format options, and relationship to related tools, making it sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters with descriptions. The description adds useful semantics: name letters are converted to numerology values, date defaults to today, response_format has markdown/json options, and only month/day are used for the calculation. Minor ambiguity remains about whether the full date year is ignored, but overall extra context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Looks up') and a clear resource ('Personal Year theme'), and explicitly distinguishes itself from sibling tools like asterwise_get_numerology_profile and asterwise_get_varshaphal. The purpose is immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a recommended workflow ('BEFORE: RECOMMENDED — asterwise_get_numerology_profile'), clarifies it uses the current calendar cycle, and notes it is not a Vedic varshaphal. It implies when to use it but does not explicitly state all exclusion cases, though the DO NOT CONFUSE WITH section covers the most likely alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds standalone behavior, output format implications, a documented error contract link, and the archetype context, going beyond what annotations alone provide without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized and front-loaded with the core behavior. The WORKFLOW and DO NOT CONFUSE sections are useful, though the 'Required' label is inaccurate and the BEFORE/None/standalone wording is slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter read tool, it covers scope, workflow, sibling alternatives, output/error contract, and is backed by an output schema. Nothing essential is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the enum and default, so the description needed to add only nuance. Instead, it labels response_format as 'Required', which is misleading because the schema lists zero required parameters and provides a default. This adds confusion rather than meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Returns all 22 Major Arcana cards (The Fool through The World) as a structured array.' It also explicitly distinguishes itself from asterwise_get_tarot_cards and asterwise_get_tarot_suit, making sibling differentiation immediate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section says 'BEFORE: None — standalone' and 'AFTER: asterwise_draw_tarot_cards — draw from this subset by filtering by arcana_type.' The 'DO NOT CONFUSE WITH' section names the sibling tools that cover the full deck and suits, making the correct selection clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/destructive hints, so the bar is lower. The description adds useful context by mentioning the output score range, the workflow, and a link to the full output/error contract, which goes beyond the bare annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and each sentence serves a purpose. It is a bit verbose with all-caps labels but remains well-structured and easy to scan. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, two persons, many sibling tools), the description provides enough context to select and invoke the tool correctly. It includes a link to the full output/error contract, clarifying what to expect, and it differentiates from the most similar alternatives. A full inline output schema would make it perfect, but the URL suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for every parameter, including nested objects, enums, and defaults. The description itself adds no extra semantic information about parameters; it merely repeats 'person1, person2 — WesternBirthData' which is already in the schema. Hence baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States clearly that it computes a compatibility score (0–100) between two natal charts, and lists the specific components (element affinity, synastry aspects, sign comparisons). It explicitly distinguishes itself from two sibling tools (synastry and zodiac compatibility) which is crucial for disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow guidance: optional prior call to western_natal, and a follow-up call to western_synastry when more raw aspect detail is needed. Also explicitly states when NOT to use this tool (for raw aspects or sign-only compatibility) by naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations cover read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral details beyond annotations, including that standard inter-chart orbs are used, house_system is ignored for synastry, and response_format controls output. It does not mention rate limits or error cases, but those are not required given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using short labeled sections for workflow, input contract, and disambiguation. The DO NOT CONFUSE section is especially efficient at preventing misuse. The full output contract link is a reasonable addition rather than unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for agent selection and invocation, including output format, ignored parameters, and relationship to sibling tools. Since the context indicates an output schema exists and a full output/error contract link is provided, the description does not need to enumerate all return fields or error codes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for all parameters. The description adds important semantic details such as 'house_system ignored for synastry payload' and explains that person1 and person2 are WesternBirthData objects, which helps agents understand which nested fields are relevant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes an aspect grid between two natal charts using the tropical zodiac and returns inter-chart aspects. The 'DO NOT CONFUSE WITH' section explicitly distinguishes it from composite charts and numeric compatibility scores, so an agent can select the correct tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context for when to use the tool, such as 'Useful for relationship compatibility analysis', and provides a WORKFLOW section telling agents to fetch individual natal charts first and use composite charts afterward. It also clarifies that it returns raw aspects unlike the numeric compatibility tool, though it does not explicitly state 'use this instead of X when Y'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the call read-only, idempotent, and non-destructive, so the description only needs to clarify what the computation returns. It does so by noting the period-tree location (data.periods.root[]), output date format, and a link to the full output/error contract, with no contradicting side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into focused sections (main computation, workflow, input contract, and do-not-confuse) and all sentences carry useful information. It is slightly longer than necessary but remains scannable and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers the key output shape (two-level tree, data.periods.root[], DD/MM/YYYY strings) and provides a link to the full contract, which is sufficient when combined with the detailed input schema and presence of an output schema. It does not need to enumerate every return field because the full contract is referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself provides complete descriptions for the birth object, coordinates, date/time, ayanamsa, timezone, and response_format, so the description adds little parameter-level guidance. The 'BirthData follows the global contract' note is generic but not misleading; output-related notes do not improve parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence clearly states that this tool computes the eight-Yogini, 36-year Yogini Dasha cycle and describes the two-level period-tree output and DD/MM/YYYY boundary format. It also explicitly distinguishes itself from the Vimshottari and Ashtottari dasha siblings, 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.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete workflow guidance ('BEFORE: recommended asterwise_get_natal_chart', 'AFTER: optional asterwise_get_dasha') and explicitly warns against confusing this tool with asterwise_get_dasha (Vimshottari) and asterwise_get_ashtottari_dasha (108-year system). This tells an agent when to use this tool and which sibling to choose otherwise.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds a linked 'Full output and error contract' and mentions a default behavior for date ('Defaults to today when omitted'), providing additional transparency beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with clear headings (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and a concise link to full docs. Each section is purposeful, though it repeats some schema-level parameter descriptions and includes a long sibling list in context; the description itself is efficient without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides the mapping logic, a recommended prerequisite, explicit disambiguation from nearest siblings, and a link to the full output/error contract. Since an output schema exists (per context), return values need not be explained. The description is complete enough for an agent to decide to call it and to anticipate its behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (per context signals), so baseline is 3. The tool description repeats the date and name parameters with a concrete example for date, but does not add substantially new semantics beyond what the schema already provides. The response_format parameter is not mentioned in the main description, though it is covered in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Computes') and resource ('personal angel number') with a clear method (Pythagorean Life Path). Explicitly distinguishes from siblings in the 'DO NOT CONFUSE WITH' section, naming asterwise_get_angel_number_today and asterwise_get_numerology_profile, so an agent can select it correctly without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a recommended prerequisite workflow ('BEFORE: RECOMMENDED — asterwise_get_numerology_profile — confirm Life Path before calling') and explicit alternatives to avoid confusion, covering when to use and when not to use this tool. This fully addresses the 'when vs alternatives' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive behavior, so the description's job is lighter. It adds value by stating the exact computed outputs, clarifying that raw matrices are exposed here rather than applied to transits, and linking to the full output/error contract. Minor operational details like rate limits or auth are absent but not critical for a read-only compute tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections—WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH—and the core function is front-loaded in the first sentence. It is longer than minimal, but the length is justified by the complexity of the tool and the need to disambiguate among a large sibling list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex Vedic tool with a nested birth object and an output schema, the description provides the essential workflow, input restriction, sibling disambiguation, and a link to the full contract. Return-value details are not duplicated because an output schema exists, so nothing necessary for correct selection and invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter coverage with detailed descriptions for date, lat, lon, time, ayanamsa, timezone, person_name, and response_format, so the baseline is 3. The description adds only the high-level contract 'BirthData only,' which is useful but does not deepen per-parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a precise verb phrase—'Computes full Ashtakavarga bindu matrices, trikona and ekadhipatya reductions, and sarva totals'—clearly identifying both the resource and the computation. The 'DO NOT CONFUSE WITH' sections explicitly distinguish it from asterwise_get_chart_strength and asterwise_get_gochar, so an agent can disambiguate without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section names a recommended predecessor (asterwise_get_natal_chart), a natural successor (asterwise_get_gochar), and why the successor uses this tool's output. It also identifies the tools most likely to be confused with this one and explains the selection difference, making when-to-use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable context about input handling: 'No local validation on name or date' and that non-letters are stripped, which informs the agent about what the tool does with edge-case inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE WITH. Each sentence serves a purpose, avoiding fluff while including necessary disambiguations and a link to the full contract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, 2 required, one enum), the description provides sufficient high-level behavior, workflow, and distinctions from siblings. It references a full contract for deeper details, and the output schema covers structured return data, so no critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter (date, business_name, response_format) having a descriptive description. The tool description does not add extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: reducing a business name to Expression and root digits against a founder birth date, returning suitability lists and a harmony score. It distinguishes itself from sibling tools by specifying 'business' and 'brand', and contrasts with personal name correction and mobile number analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit workflow guidance: standalone with no BEFORE step and an AFTER recommendation to use asterwise_get_name_correction for persons. It also includes a DO NOT CONFUSE WITH section that names alternative tools and their scopes, making it obvious when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate read-only, idempotent, and non-destructive behavior, and the description is consistent with that. The description adds useful context about output format and date formatting but does not disclose additional behavioral side effects or limitations 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for workflow, input contract, and disambiguation. However, the date format distinction is repeated in both the 'INPUT CONTRACT' and 'DO NOT CONFUSE WITH' sections, adding slight redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description summarizes the output content, mentions the output format options, provides workflow context, and references the full output and error contract URL. Combined with the detailed schema, an agent has sufficient information to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with detailed descriptions, so the description adds little beyond what is already in the input schema. The note about data.periods[] using YYYY-MM-DD is output-related rather than an input parameter clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool computes Char Dasha and returns sign lords as period rulers with ISO-dated Maha and Antar sequences plus karaka mappings. It also distinguishes itself from Vimshottari and Yogini dasha tools, so an agent can clearly identify when to choose this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow guidance: natal chart is recommended before, and Vimshottari dasha is noted as an optional cross-check after. It also clarifies the date format difference versus asterwise_get_dasha and warns against confusing it with the Vimshottari and Yogini tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context: sorted alphabetically, full content list, and a link to the error contract. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and front-loads the primary purpose. While slightly verbose, every section adds value and is well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering safety, the description is fully complete. It explains the output contents, workflow, alternatives, and provides a documentation link for errors. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter response_format is fully documented in the schema with enum and description. Schema coverage is 100%, so the baseline is 3. The description does not mention the parameter, but it doesn't need to since the schema covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns all 50 crystals sorted alphabetically, with a detailed list of what each entry includes. It distinguishes itself from siblings via the DO NOT CONFUSE WITH section, naming asterwise_get_crystal, asterwise_get_crystal_by_planet, and asterwise_get_crystal_recommendations with their 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WORKFLOW section states no prerequisites and names the AFTER tool for filtering by Vedic planet. The DO NOT CONFUSE WITH section explicitly lists alternative tools and their distinct purposes, leaving no ambiguity about when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the description does not need to repeat these. It adds detail about local enum enforcement (Pydantic) which is a mild behavioral note. No contradictions with the annotations are present, and the description does not introduce side effects or unexpected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and avoids repetition. While it is somewhat verbose, the structure makes it easy to scan, and every sentence adds useful context. It is concise enough for an API description without being terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes the full output/error contract URL, explains the optional chart_type and the default behavior of returing all 16 charts, and provides workflow context. This is sufficient for an agent to understand the tool's scope, prerequisites, and output format without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all parameters, including birth, chart_type, and response_format, each with detailed descriptions. The description itself adds little semantic value beyond restating the enum enforcement, so it does not elevate the baseline set by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes divisional (varga) chart positions from BirthData, and explicitly distinguishes it from the natal chart and chart strength tools. The verb 'Computes' and the resource 'divisional chart positions' are specific, and the distinction from sibling tools leaves no ambiguity about its 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct instructions: pass chart_type for one varga, omit for all sixteen. It also provides a WORKFLOW note recommending the natal chart as a prerequisite, and a 'DO NOT CONFUSE WITH' section explicitly naming when not to use this tool versus the natal chart or chart strength. This covers both when to use and when to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by explaining that filtering narrows results, that response_format changes output, and that there are no prerequisites. It also points to a full error contract, providing transparency about expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description repeats information about category values and filtering in both the main paragraph and the INPUT CONTRACT section, making it somewhat redundant. While the structure is clear (purpose, workflow, input, confusion avoidance), the repetition detracts from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for a simple read-only list tool, including the distinction from the single-symbol tool and a link to the full output and error contract. It would be slightly more complete if it explicitly stated the return format (e.g., array of symbols), but the existing details are adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters, including default values and allowed values for response_format, and the allowed categories for category. The tool description repeats this information without adding new meaning, so it does not improve parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns dream symbols with dual-tradition interpretation and mentions the scope (500 symbols, 8 categories). It explicitly distinguishes from the sibling tool asterwise_get_dream_symbol by saying 'DO NOT CONFUSE WITH...' which clarifies the specific purpose of returning a list vs a single symbol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance via the WORKFLOW and DO NOT CONFUSE WITH sections. It states that this tool is standalone, and that for a specific symbol detail, one should use asterwise_get_dream_symbol. It also explains the optional category filter and the response_format parameter, giving clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnly, idempotent, and non-destructive annotations and adds context about output contents. It does not contradict annotations, though it relies on them for side-effect transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized with workflow and disambiguation sections and is front-loaded with the core purpose. Minor redundancy exists between the opening paragraph and the later disambiguation note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the detailed input schema, output schema indication, and annotations, the description provides sufficient context for correct invocation and clear differentiation from numerous sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% field-level descriptions with examples and defaults. The prose adds little parameter-specific meaning beyond identifying the Lal Kitab system.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces the Lal Kitab house and planet schema plus Rin flags from BirthData using Lal Kitab placement rules, and explicitly distinguishes it from the natal chart and remedies tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: it is standalone for Lal Kitab queries, lists the recommended follow-up tool, and warns against confusing it with asterwise_get_natal_chart and asterwise_get_lal_kitab_remedies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds useful context about validation failures ('malformed payloads fail upstream') and points to a full error contract via URL, going beyond the annotation baseline 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE), but it is longer than necessary and repeats some schema content (e.g., date format). It earns a 4 for organization and clarity despite minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully situates the tool within a large numerological suite by distinguishing it from similar tools, documents its output components, and provides a link to the complete documentation and error contract. An agent has enough context to select and invoke it correctly without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters with clear meaning (date format, name conversion, response_format enum). The description itself does not add extra parameter-specific details beyond the schema, so it stays at the baseline warranted by full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Builds'), resource ('Pythagorean numerology profile'), inputs ('legal name and birth date'), and outputs ('core numbers, cycles, lucky digits, and summary copy'). Explicitly differentiates from Chaldean numerology and lucky-numbers-only tools in the DO NOT CONFUSE section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow context (BEFORE/AFTER) naming a related tool and when to use it (to fill Personal Year). Lists alternative tools with clear differentiators, giving unambiguous when-to-use versus 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already establish the tool's safety profile. The description adds transparency by stating 'WORKFLOW: BEFORE: None — standalone', indicating no prerequisites or side effects, and consistently says 'Returns' without implying any mutation. The 'standalone' statement goes beyond the annotations, reinforcing idempotent/read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The core description is concise and front-loaded. However, the full description includes lengthy 'INPUT CONTRACT' and 'WORKFLOW' sections that largely duplicate information already present in the input schema. The 'DO NOT CONFUSE WITH' section is useful but could be integrated more tightly. The overall text is longer than necessary, with some redundancy between the written description and the schema, reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the essential context: what the tool returns (three cycle numbers), how they are derived (from birth date and target date), and how to use optional parameters. It also points to a full external contract via the provided link. It does not describe error handling or response structure, but the presence of an output schema (not shown here) and the external docs reference largely compensate. The tool is sufficiently contextualized for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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's 'INPUT CONTRACT' section adds concrete examples (e.g., '1985-11-12', '2026', '5', '1') and clarifies nuanced behavior such as 'Personal Day is only returned when day is provided. Defaults to null (Personal Day omitted).' This goes beyond the schema descriptions by providing usage examples and edge-case behavior, adding practical meaning for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary function: 'Returns the Personal Year, Personal Month, and Personal Day numbers for a given birth date and optional target date.' It identifies the specific output (three cycle numbers) and the input (birth date + optional target date). The 'DO NOT CONFUSE WITH' section explicitly distinguishes it from asterwise_get_personal_year and asterwise_get_numerology_profile, making its unique 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by contrasting with sibling tools: 'asterwise_get_personal_year — returns Personal Year only, no month or day breakdown' and 'asterwise_get_numerology_profile — core name numbers; personal_year field is null there.' This directly tells the agent when to choose this tool over the alternatives. It also explains the optional parameters (year, month, day) and their defaults, clarifying the intended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral context on top: it confirms birth data alone computes everything, mentions the exact classical combinations covered, and links to a full output/error contract. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE WITH sections, making it easy to scan. It includes a documentation URL for full details. It is slightly more verbose than strictly necessary, but every section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisites (none), downstream workflow, sibling disambiguation, and points to a full output/error contract URL. Combined with the rich input schema, annotations, and output schema, the agent has everything needed to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema itself documents all parameters and nested properties. The description only restates the birth contract at a high level and does not add new meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Detects and analyses Pitru Dosha' using all five classical combinations. It also explicitly differentiates itself from asterwise_get_doshas, saying that sibling returns less detail. This makes the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit routing guidance: 'DO NOT CONFUSE WITH asterwise_get_doshas' and 'Use this tool when dedicated Pitru Dosha analysis is needed.' It also provides a workflow context, noting that puja suggestions come after via asterwise_get_puja_suggestions. This is strong, actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful context beyond those: it computes three kaal bands, depends on location and date, and includes a local-time 'active now' check. It could mention more about error behavior, but the docs link and output schema cover some of that gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into distinct, purposeful sections: core behavior, workflow, input contract, exclusions, and documentation link. The central behavior is front-loaded, and no sentence is filler or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nested-location tool with an output schema and strong annotations, the description is nearly complete: it covers workflow, sibling differentiation, validation behavior, and points to the full contract. It loses a point because the ambiguous 'place name' alternative in the location schema is not clarified in the description, and the exact required coordinates/date are only implicitly referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 INPUT CONTRACT adds modest value by noting that LocationInput validates the date pattern and coordinates locally. However, the description does not resolve the schema's confusing 'location' property description that mentions a place-name alternative while the schema actually requires lat, lon, and date.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names three specific outputs (Rahu Kaal, Gulika Kaal, Yamaganda Kaal intervals) plus an active-now status flag, and ties the computation to diurnal length and location. The DO NOT CONFUSE section explicitly distinguishes it from choghadiya and panchanga, so an agent can identify it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
WORKFLOW states this tool is standalone with no prerequisite, and AFTER names choghadiya as the broader alternative. DO NOT CONFUSE further gives two exclusions with reasons, making when-to-use and when-not-to-use explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail by mentioning Rajju veto severity tracking and the expanded breakdown map with tradition metadata, though exact result keys and error cases are only pointed to via the contract URL.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized with WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH, and contract sections. It is slightly verbose and repeats some schema content, but every section serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the annotations cover safety, the description is complete: it provides workflow, disambiguation from relevant siblings, input requirements, output format, and a link to the full error contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions, so the baseline is 3. The description only restates the input contract and does not add significant meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Evaluates'), names the exact resource (twelve Tamil Thirumana poruthams for two charts), and immediately distinguishes it from the ten-porutham and North Indian compatibility tools in the DO NOT CONFUSE section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit workflow guidance (run asterwise_get_porutham first as a quick pass), states the input contract (two BirthData objects), and names the alternatives to avoid. It also indicates output format and points to the full output/error contract.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the API pins to the current day, there is no explicit query date, and the output includes intensity, upcoming cycles, and historical rows. It also references the full output/error contract via link.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by clearly labeled WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE sections. Each section earns its place, and the external documentation link avoids bloating the description with full contract details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the existing output schema, and rich annotations, the description is complete. It states the computation, the date behavior, the output contents, the recommended workflow, sibling distinctions, and points to the full contract. An agent has enough to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 some input-contract context ('No explicit query date — API pins to current day' and 'BirthData global contract applies'), but it does not meaningfully elaborate on the individual birth or response_format parameters beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Evaluates Saturn's seven-and-a-half-year Moon-sign cycle phases against natal data for the current day and returns intensity, upcoming cycles, and historical rows.' It clearly distinguishes itself from asterwise_get_gochar and asterwise_get_transits in the DO NOT CONFUSE section, so an agent can differentiate it from siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section explicitly recommends a before-tool (asterwise_get_natal_chart) and an after-tool (asterwise_get_gochar), while the DO NOT CONFUSE section names two alternatives and explains why they differ. This gives the agent 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide strong safety cues: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds useful behavioral context beyond those: it is a standalone reference with no BEFORE/AFTER workflow dependencies, and it defaults the date to today. It also links to the full output and error contract, which covers any remaining behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured and front-loaded: the core behavior appears in the first sentence, followed by compact WORKFLOW, INPUT CONTRACT, and confusion-avoidance sections. Every section earns its place and the whole thing is easy for an agent to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool with full schema coverage, an output schema, and rich annotations, the description is complete. It covers date format, default behavior, supported systems, sibling alternatives, and points to the full output/error contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both date and response_format fully. The description reiterates the date default but does not add meaningfully beyond the schema. Baseline 3 is appropriate because the schema carries the parameter semantics burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb with a resource: 'Returns ayanamsha values for all four supported systems (Lahiri, Raman, KP, Tropical) for a given date.' It is clearly distinct from sibling tools, and it even names the two most likely confusable alternatives and what they do differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a 'DO NOT CONFUSE WITH' section, naming asterwise_get_natal_chart and asterwise_get_westen_natal and explaining when each should be used instead. This gives concrete routing guidance beyond simply defining the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context beyond the annotations by stating it is 'standalone' and has a specific workflow after it, which is not covered by the readOnly or idempotent hints. However, it does not explicitly mention side effects or permissions, though the annotations already cover these (readOnlyHint true, destructiveHint false). Overall, it adds moderate context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and is not overly long. However, the INPUT CONTRACT section repeats information already present in the schema, introducing slight redundancy. The front-loaded first sentence is effective, and the overall structure is easy to follow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (4 parameters, 1 enum, output schema exists), the description covers the core purpose, usage, and differentiators. It points to a URL for the full output and error contract, which addresses potential omissions. It does not describe the output structure in detail, but the link compensates. Overall, it is sufficiently complete for an agent to decide and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of the parameter descriptions, giving a baseline of 3. The description adds the range constraint for 'days' (1-90) and clarifies the default behavior for 'target_date' ('Defaults to today'), which is not fully specified in the schema. This additional context improves understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool computes physical, emotional, and intellectual biorhythm cycles for a birth date. It also explicitly distinguishes itself from related tools via the 'DO NOT CONFUSE WITH' section, naming asterwise_get_nakshatra_prediction and asterwise_get_panchanga. This provides both a specific verb and resource, and clear 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow guidance: 'BEFORE: None' and 'AFTER: asterwise_get_nakshatra_prediction', indicating where this tool fits in a sequence. It also tells the agent when not to use this tool (i.e., for Vedic daily predictions or panchanga elements), making the selection criteria very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly and idempotent hints, so the description does not need to repeat those. It adds behavioral context by stating the sorting logic and offering a response_format parameter, which clarifies output behavior beyond the schema. The output/error contract link provides additional transparency, though no direct side-effect details are needed given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (workflow, input contract, do-not-confuse, output contract). Though somewhat lengthy, every sentence contributes useful information—no fluff. The main recommendation statement is concise, and the additional sections are organized logically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides sufficient context for correct invocation: required filters, output format options, and a link to the full output/error contract. Although the actual output schema is not embedded, the description's mention of markdown/json and the contract URL mitigate the gap. It also clarifies relationships with sibling tools, making the tool's role well-defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 enhances this by listing allowed chakra values (Root, Sacral, Solar Plexus, etc.) which are not in the schema enum, and providing concrete examples for intention (protection, abundance, love) and zodiac_sign. It also clarifies the limit default/max, aligning with schema but adding context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Recommends' and the resource 'crystals', with specific criteria (zodiac sign, chakra, intention). The 'DO NOT CONFUSE WITH' section explicitly differentiates from sibling tools like asterwise_get_crystal_by_planet and asterwise_get_gemstone_recommendations, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the requirement 'At least one filter is required' and describes the ordering behavior ('matches the most criteria first'). The workflow mentions 'AFTER: asterwise_get_crystal' for subsequent detail retrieval, and the 'DO NOT CONFUSE WITH' lines provide clear when-to-use guidance against alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral detail about the computed output — grid, score, percentage, dosha flags, diagnostics — and points to a full output/error contract URL, extending context beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the tool's core behavior, then organized into compact labeled sections for workflow, input contract, sibling differentiation, and documentation. Every section serves a distinct purpose and none is redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested two-person input and a rich astrology computation, but the description covers workflow, input contract, sibling disambiguation, and full output/error documentation. Combined with complete schema descriptions and the output schema, an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents person1, person2, response_format, including nested fields, defaults, and enums. The description's mention of 'Two BirthData objects per global contract' adds no meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Computes'), a precise resource ('ten-koota Dashakoot grid'), and the derived outputs ('ten-point score with percentage', 'boolean dosha flags', 'supplementary diagnostics'). It also explicitly differentiates from sibling tools asterwise_get_compatibility and asterwise_get_porutham, so an agent can distinguish this tool from similar-sounding alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section states a recommended prerequisite (asterwise_get_natal_chart for each native) and an optional follow-up (asterwise_get_papasamyam). The DO NOT CONFUSE WITH section names the two closest sibling tools and explains why they are not the same, which is exactly the when/not-when guidance needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context by specifying that the tool computes from the natal chart, returns a structured set of categories including contraindications and safety notes, and advises confirming the chart before wearing advice. It does not add details on auth or rate limits, but this is not central for a read-only computation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The main purpose sentence is front-loaded and is followed by compact, labelled sections for workflow, input contract, and exclusions. Each section adds decision-relevant value, and the docs link is a useful escape hatch rather than bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with an output schema, nested birth object, and safety annotations, the description covers the purpose, the output categories, the necessary workflow, and the alternatives to avoid. There is also a link to the full output and error contract, so an agent can resolve any remaining uncertainty. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents birth and response_format. The description only adds 'BirthData follows the global contract', which adds little beyond the schema. Baseline 3 is appropriate because the schema carries the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Computes'), names the exact resource ('Ratna-style gemstone picks and cautions from the natal chart'), and enumerates the outputs (primary stones, role-based stones, secondary options, contraindications, safety note). It clearly separates itself from sibling remedy tools in the DO NOT CONFUSE section, making tool selection 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section explicitly tells the agent to run asterwise_get_natal_chart BEFORE and asterwise_get_remedies AFTER, and the DO NOT CONFUSE section names alternatives and explains what they are not. This is explicit 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotent behavior, and the description adds practical behavioral notes such as defaulting target_date to today and handling of birth time '00:00' without unknown-time detection. However, it does not elaborate on rate limits or runtime characteristics, but the provided context is sufficient given the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and front-loads the core purpose in the first sentence. While it is somewhat lengthy, each section serves a distinct purpose and the formatting aids readability, though it could be slightly more compact without losing essential disambiguation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core functionality, provides workflow context, disambiguates from close sibling tools, and points to a full output/error contract for deeper details. Given the tool's moderate complexity (nested birth object, enums), the description is sufficient for an agent to select and invoke it correctly, though the output format could be slightly more detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all parameters, so baseline is 3. The description adds extra clarity via the global contract note for birth data, specifically addressing the acceptance of '00:00' as a literal time, which supplements the schema's warning about not using it for unknown times. This added nuance justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes Gochar against the natal Moon and Lagna, and enumerates specific outputs (per-planet transit longitudes, houses, AVK scores, vedha flags, roll-up summary). It explicitly distinguishes from sibling tools via the 'DO NOT CONFUSE WITH' section, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance through WORKFLOW and DO NOT CONFUSE WITH sections, recommending natal chart as a prerequisite and dasha transits as a follow-up. It also specifies what this tool is not for (ingress/station tables, dasha-lord correlation), leaving no ambiguity about its appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds transparency about error handling by linking to a full output and error contract, and it explains the computation process (scanning letters, converting to values). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but well-structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH). The example inside INPUT CONTRACT repeats some information from the opening sentence, but the overall organization aids readability and avoids being unnecessarily verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema is reported as present (context signal), the description does not need to explain return values. It does point to a full output and error contract URL for additional details, and the workflow section places the tool in a broader context. This is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover both parameters with 100% coverage, so the baseline is 3. The main description goes further by providing a concrete example ('Arjun Mehta') that illustrates how the name is processed, which adds practical semantic clarity beyond the schema text. The response_format enum is also clearly documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific function: identifies karmic lessons by scanning all letter values in a full name and finding missing digits 1–9. It explicitly distinguishes from sibling tools by noting that balance number uses only first initials and expression number reduces to a single digit, preventing confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use context via the workflow section (standalone, before numerology profile) and a 'DO NOT CONFUSE WITH' section that names specific alternatives and explains the exact differences (initials vs all letters, reduced vs absent digits). This gives clear guidance on selecting this tool over related options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the baseline safety profile is covered. The description adds useful behavioral context beyond annotations: it lists per-planet stressed analysis, priority tiers, specific action row categories (remedy, donation, keep, avoid), and points to the output/error contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then organized into compact WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE WITH sections. Each section earns its place, and there is no redundancy with annotations or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return-value details are already covered. The description supplies workflow context, alternative tool routing, input contract, and a link to the full output/error contract, making it complete for an agent to decide when and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the input schema. The description adds only the input contract 'BirthData only', which is useful but does not provide any additional meaning 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Lists') and a clear resource ('Lal Kitab style totkas per stressed planet'), and specifies the output shape (priority tiers and typed action rows). It also explicitly distinguishes itself from asterwise_get_remedies and asterwise_get_gemstone_recommendations, so an agent can select it correctly without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section gives a concrete before-step ('asterwise_get_lal_kitab_chart') and an explicit AFTER: None, and the DO NOT CONFUSE WITH section names alternatives and their differentiating focus. This makes when-to-use and when-not-to-use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds useful context beyond those annotations by noting the payload is 'condensed', that inputs are forwarded upstream without local checks, and by linking to the full output/error contract. This is meaningful additional transparency, though not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) that each add distinct value. The main purpose is front-loaded in the first sentence, and there is no filler or redundant restating of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool of this complexity: it explains the standalone workflow, the follow-up path, sibling disambiguation, input forwarding behavior, and provides an external contract link. An output schema exists, so return-value details are already covered, and the annotations handle the safety profile. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters with descriptions. The description adds only generic context ('name and birth date') and does not meaningfully enrich the parameter semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Fetches') and clearly defines the resource: condensed lucky-number guidance for a name and birth date. It enumerates the payload contents (primary/secondary picks, power number, interpretation, date_specific flag), and explicitly distinguishes the tool from likely siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section states that this tool is standalone and points to asterwise_get_numerology_profile as the follow-up when deeper context is needed. The DO NOT CONFUSE WITH section names two alternatives and explains exactly why they are not the same, giving 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent), the description discloses important behavioral details: unknown birth times are accepted as '00:00' without error but yield unreliable lagna results, and a sunrise chart is used when time is omitted. It also explains output format options and the API's lack of flagging for unreliable results, adding significant transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear paragraphs for purpose, workflow, input contract, and distinction. It is slightly verbose (e.g., repeating 'BirthData enforces...' when the schema already conveys this), but it front-loads the core purpose and keeps each section relevant. The link to full docs is a good touch, but the length could be trimmed slightly without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential context: what the tool does, how to use it, the unknown-time caveat, and a link to the full output/error contract. It does not enumerate the exact return fields, but that is available via the linked docs and the output schema reference. It is fairly complete for a tool with this complexity, though a bit more detail on common error scenarios would elevate it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides thorough descriptions for all parameters, including formats, enums, defaults, and constraints. The description adds minimal extra semantic value beyond what is in the schema, such as noting the ayanamsa enum is 'local (Pydantic)' and pointing to a documentation link. This aligns with the baseline of 3 given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Computes the full sidereal natal chart from BirthData and returns planet rows, houses, aspects, arudhas, upapada, bhava cusps, and avakhada metadata.' This is a specific verb (computes) with a clear resource (sidereal natal chart) and distinguishes it from the divisional chart sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly contrasts with 'asterwise_get_divisional_chart' by noting 'sixteen vargas only, not the primary radix bundle returned here.' Additionally, it provides workflow context ('BEFORE: None... AFTER: RECOMMENDED — asterwise_get_yogas'), guiding when this tool fits in a sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context by stating it is standalone and provides a link to the full output and error contract, supplementing the annotations with additional behavioral clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and includes a link to full documentation. While it repeats some schema information (e.g., number range, response_format), the repetition is minimal and serves to reinforce key constraints without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema is present, the description does not need to explain return values. It provides sufficient context: the purpose, input constraints, differentiation from siblings, and a reference to the full contract. This is complete enough for an agent to decide when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 value by specifying the exact inclusive range (1-33) and the error condition (INVALID_PARAMS) for the number parameter, and clarifies the meaning of the response_format enum, going beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns dictionary-style numerology copy for a single integer, including interpretation and keywords. It explicitly distinguishes itself from similar sibling tools (asterwise_get_numerology_profile and asterwise_get_lucky_numbers) in the 'DO NOT CONFUSE WITH' section, making its unique 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when not to use this tool by naming the alternatives and their differences. It also outlines the input contract (inclusive range 1-33 and error behavior) and mentions output format options, giving clear instructions for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds meaningful behavioral detail beyond that: it compares two charts, uses three reference points, and produces a threshold-based compatibility label, plus it points to a full output/error contract URL.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then organized into short labeled sections for workflow, input contract, disambiguation, and documentation. Every section earns its place and there is no redundant prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex Vedic compatibility tool, the description covers the core calculation, recommended sequencing, exclusions from two similar tools, the two-person input contract, and a link to the full output and error contract. The rich input schema and output schema reduce the need for inline return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the nested BirthData fields are already fully documented with formats, defaults, and examples. The description only restates 'Two BirthData objects per global contract,' which does not add significant meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific computation—'Measures malefic stress from Lagna, Moon, and Venus references for each partner, compares totals, and labels compatibility level against a threshold'—with a clear verb, resource, and outcome. It also names the sibling tools it must not be confused with, making differentiation immediate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section explicitly recommends asterwise_get_compatibility as a BEFORE step, and the 'DO NOT CONFUSE WITH' section names asterwise_get_doshas and asterwise_get_compatibility with precise scoping reasons. This gives the agent clear when-to-use and when-not-to-use guidance relative to the closest siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the bar for additional disclosure is lower. The description adds meaningful algorithmic transparency by specifying that Y is always a consonant and that master numbers 11, 22, 33 are preserved, which helps the agent anticipate results. It does not detail failure modes, but the output schema and linked docs likely cover those.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate sections for purpose, workflow, input contract, and disambiguation. It is concise overall, but there is minor redundancy: the Y-as-consonant rule appears in both the main description and the input contract. Still, the structure aids readability and no unnecessary fluff is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes all necessary context for correct invocation: the input format, the output format options, a link to the full output/error contract, and clear differentiation from similar tools. Given the tool's relative simplicity and the presence of an output schema (per context signals), the description is sufficiently complete 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptive text, providing a baseline of 3. The tool description adds extra semantic value by clarifying the 'name' parameter as the full legal name at birth and emphasizing the vowel rule, which is not fully captured in the schema description. This pushes the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the tool calculates the Soul Urge number from vowels in the full name, naming the specific resource and verb. It further distinguishes it from sibling tools by explicitly contrasting with expression (all letters) and personality (consonants) numbers, making it clear which tool to select.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance by naming the tools not to confuse with (expression and personality numbers) and clarifies the vowel-only vs. all-letters vs. consonants distinction. It also indicates a follow-up tool (personality number) to complete the name trinity, providing clear when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes that cards are drawn with cryptographic randomness and that the question does not affect card selection, adding transparency beyond the readOnlyHint annotation. It doesn't mention any potential side effects, but the annotations already cover safety, and the extra details are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate sections for workflow, input, and disambiguation. While slightly verbose due to repeating disambiguation details, the information is organized and easy to scan, with no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary aspects for a user to call the tool correctly: what it does, how to use it, and output options. Since an output schema exists, the lack of return-value details is acceptable. The mention of response_format and the question's non-influence on selection round out the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description elaborates on each parameter's meaning (question shapes interpretation, allow_reversed controls reversed cards, response_format controls output type) and even provides an example and a note about the question being echoed. This goes beyond the schema's basic definitions, enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool draws 3 unique cards for a Past/Present/Future spread, assigning each to a named positional slot. It explicitly distinguishes from sibling tools like draw_tarot_cards (free draw) and celtic_cross (deeper analysis), making its specific 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a 'DO NOT CONFUSE WITH' section that contrasts this tool with two directly related siblings, and the 'AFTER' note suggests using the celtic cross for deeper analysis of the same question. This gives clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the annotations by specifying 'standard natal orbs' and the input format (tropical longitude). Since annotations already indicate read-only, idempotent, and non-destructive behavior, the description does not contradict them and provides a useful default behavior detail, though it could mention potential orb variations or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and front-loads the core purpose in the first sentence. While it is slightly verbose due to the embedded workflow and contract text, the structure makes it easy to navigate and not overly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes workflow context, input contract details, links to full documentation, and differentiates from sibling tools. It does not provide an explicit output schema, but the response_format parameter and phrase 'returns every aspect' give sufficient indication of the result. The link to docs fills any remaining gaps, making it complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions, but the description text adds meaningful constraints not present in the schema: positions must contain at least 2 entries, gives an explicit example, and clarifies the coordinate type (tropical longitude). This goes beyond the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates all active aspects from supplied planetary longitudes, with explicit input and output. It also explicitly distinguishes itself from similar tools (asterwise_get_western_natal and asterwise_get_western_synastry) in the 'DO NOT CONFUSE WITH' section, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance via the WORKFLOW section, stating it can be used standalone or after obtaining positions from asterwise_get_western_natal. It also directly names the alternatives to avoid confusion, giving clear when-to-use and when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the return occurs approximately every 27.3 days, the chart is built 'for that moment at the birth location', and a 'complete Western natal chart' is produced. It does not describe error behavior or edge cases, but the external docs link mitigates that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then organized into compact labeled sections: WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH, and docs link. Every section serves a distinct purpose, and there is no filler or repetition that weakens the agent's ability to parse it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, idempotent computation tool with a rich input schema and an output schema present, the description covers the essential context: what it computes, the input contract, the workflow prerequisite, the closest alternative, and a full documentation link. Nothing critical is missing for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the birth object, after_date, and response_format. The description's INPUT CONTRACT mostly restates what the schema already says (after_date defaults to today, birth is WesternBirthData), adding no meaningful parameter semantics 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('finds') and resource ('the next lunar return chart after a given date'), then explains the underlying mechanism: the next moment the Moon returns to its natal tropical longitude. It also explicitly disambiguates from asterwise_get_western_solar_return, so an agent can distinguish it from the closest sibling without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use context ('next return after this date'), a workflow dependency ('BEFORE: asterwise_get_western_natal'), and an explicit exclusion with the alternative tool ('DO NOT CONFUSE WITH: asterwise_get_western_solar_return'). This gives an agent concrete routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, so the safety profile is fully covered. The description adds meaningful behavioral context by explaining the calculation rule and the uniform rate of progression, which helps callers understand what the tool does without needing to infer it from the name alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) with no redundant or filler language. Every sentence contributes either the calculation method, the prerequisite, the input default, or a disambiguation from sibling tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for the tool's complexity: it states the prerequisite chart, the optional target date, the disambiguation from similar tools, and points to a full output/error contract URL. Since an output schema is present, describing return values inline is not necessary, and the provided link covers any additional output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters with detailed descriptions, including nested birth fields, enums, defaults, and formats, so the baseline is met. The description's INPUT CONTRACT adds little beyond restating target_date's default and naming 'WesternBirthData', which does not materially enhance the schema's already thorough semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as computing Solar Arc Directions for a target date and explains the method (progressed Sun minus natal Sun, uniformly applied). It explicitly distinguishes itself from secondary progressions and daily transits among sibling tools, leaving no ambiguity about its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete workflow prerequisite by stating BEFORE: asterwise_get_western_natal and notes AFTER: None. It also gives explicit when-not-to-use guidance by contrasting with secondary progressions and daily transits, and documents the target_date default so callers know when it can be omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful context beyond that: no ephemeris calculation, fast execution, basis in element/modality affinity, and a link to the full output/error contract. It would only reach 5 by describing error cases inline rather than referencing a docs URL.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses clear labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) that make scanning easy. Every section earns its place; no filler or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering safety/idempotency, the description supplies the missing behavioral and routing context: prerequisites, alternatives, underlying logic, and a pointer to the full contract. Nothing an agent needs to select and call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema already documents sign1, sign2, and response_format with examples and defaults. The description's INPUT CONTRACT mostly restates parameter names without adding semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear resource ('sign-to-sign compatibility') and methodology ('element and modality affinity'), and immediately distinguishes it from similar-sounding siblings. It names exactly what this tool is not: asterwise_get_western_compatibility and asterwise_get_western_synastry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WORKFLOW and DO NOT CONFUSE sections tell the agent when to use this tool vs alternatives: no birth data needed, use asterwise_get_western_compatibility when full charts are available, and use synastry for aspect geometry. This is textbook-level routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description does not add extra context about side effects, permissions, or rate limits, but it is consistent with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (purpose, workflow, input contract, do-not-confuse) and is free of unnecessary verbosity. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Includes algorithm, worked examples, output format options, and differentiation from related tools. An agent has everything needed to invoke this tool correctly without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema with types, defaults, and enums. The description adds the algorithm and concrete examples, providing rich semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates the Balance number from first letters of name parts, with explicit examples. It distinguishes itself from expression number and karmic lessons, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'DO NOT CONFUSE WITH' section that explicitly names sibling tools and clarifies when not to use them. It also covers output format options, giving clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context by linking to the full output and error contract and warning about lagna-sensitive timing when birth time is unknown. This goes beyond what the annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE sections, making it easy to scan. Some redundancy exists with the schema's parameter descriptions, but the separation of concerns is helpful and not excessive given the large number of sibling dasha tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers before/after workflows, sibling-tool disambiguation, output date format, level-depth payload implications, and a link to the full output/error contract. For a complex astrological tool, this provides sufficient context for an agent to invoke it correctly, especially alongside the detailed schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters, so the baseline is high. The description adds valuable output-format context ('Response dates in periods[] use DD/MM/YYYY, not ISO') and reiterates important time-related caveats, but much of the parameter-level meaning is already captured in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Computes Vimshottari Dasha'), a clear resource ('from birth data'), and a concrete output ('returns hierarchical period trees plus current Maha/Antar interpretation blocks'). It also distinguishes this tool from sibling tools in the 'DO NOT CONFUSE WITH' section, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the recommended before-tool (asterwise_get_natal_chart), the after-tool (asterwise_get_dasha_transits), and the alternative dasha tools with their key differences. This gives the agent clear guidance on when to use this tool versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior; the description adds that this is an AI-synthesised editorial horoscope, returns structured guidance fields plus model/period metadata, and that response_format only controls rendering between markdown and JSON. It also references a full output/error contract URL, providing meaningful behavior 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal, but every section earns its place: purpose, workflow, input contract, disambiguation, and documentation link. The structure is clear and front-loaded with the core purpose before supporting details, making it efficient despite its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description appropriately focuses on selection, input constraints, disambiguation, and the contract URL for full output/error details. It covers before/after workflow and alternatives, so an agent has everything necessary to invoke the tool correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is already strong, but the description adds genuine value by expanding moon_sign to include Sanskrit and English rashi names, clarifying that period is constrained to the schema enum, and specifying that response_format only selects rendering mode. This helps an agent understand valid inputs beyond the basic schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a clear, specific action: fetches an AI-synthesised Moon-sign horoscope for a chosen horizon, and distinguishes the resource and deliverable from sibling tools. The 'DO NOT CONFUSE WITH' section explicitly contrasts it with asterwise_get_natal_chart and asterwise_get_gochar, so an agent can select it 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance via WORKFLOW and DO NOT CONFUSE sections, naming the exact sibling tools and their purposes. It also notes that a personalized chart should use asterwise_get_natal_chart, giving clear exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description's job is to add what they don't cover. It does: the tool is standalone, activity values are not validated locally with bad slugs surfacing as MCP INTERNAL_ERROR, and from_date/to_date ordering plus span rules are enforced upstream. It also links the full output/error contract, covering the remaining behavioral surface.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, then the rest is organized into terse, clearly labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) plus a single docs link. Every section carries distinct, decision-relevant information with no filler; the only minor wart is the slightly ambiguous 'slugs above' reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 required parameters, a nested location object, and an existing output schema, the description covers the essential decision surface: purpose, standalone workflow, follow-up step, parameter error behavior, and sibling disambiguation. The unenumerated activity slug list and unspecified span rules are the only real gaps, and both are mitigated by the docs link and schema examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, and the description pushes above it by adding error and validation semantics: activity must match a supported English slug and is not validated locally, and date-ordering/span rules are enforced upstream. The main shortfall is that the supported slugs are referenced ('above') rather than enumerated, leaving the agent to infer them from schema examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb ('Searches'), a distinct resource (a date span for top-scoring muhurta windows for a named activity), the astrological inputs (Panchanga, Choghadiya, classical siddhi flags), and a location. The 'DO NOT CONFUSE WITH' block explicitly differentiates it from asterwise_get_choghadiya and asterwise_get_panchanga, so an agent can identify this tool without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section states the tool is standalone (no BEFORE prerequisite) and names asterwise_get_panchanga as the AFTER step for drilling into limb detail, giving explicit sequential guidance. The 'DO NOT CONFUSE WITH' section names both confusable siblings and states the discriminating conditions — single-day enumeration without activity scoring (choghadiya) versus unranked single-day limb detail (panchanga) — which effectively tells the agent when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately conveys a read-only, idempotent retrieval operation and points to an external full output/error contract. The readOnlyHint and idempotentHint annotations are not contradicted; the description adds useful detail about the monthly row-oriented return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loaded with the core purpose. Some redundancy exists between the AFTER workflow note and the DO NOT CONFUSE WITH line, but it is not excessive and reinforces the key distinction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context for correct use: the output shape, the distinction from the single-day tool, input validation, timezone behavior, and a link to the full contract. Given the rich input schema and sibling context, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with ranges and defaults, and the description adds that year/month/lat/lon are validated locally and that timezone handling follows upstream response fields. response_format is not described, but the schema provides its enum and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns one row per civil day for a calendar month at a location, with condensed Panchanga fields. It also explicitly distinguishes itself from asterwise_get_panchanga, the single-day detailed version, so an agent can select the right sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit before/after workflow guidance and a direct 'DO NOT CONFUSE WITH' warning identifying asterwise_get_panchanga as the single-day alternative. This makes it clear when to use this monthly calendar tool versus a more detailed daily lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly/idempotent/non-destructive. Description adds a full output/error contract URL and clarifies it returns tables, which is consistent. No contradictions; the error contract link provides extra 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat verbose with multiple labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE, plus a URL). However, the sections are structured and each adds distinct value; the main purpose is front-loaded. Slightly wordy but acceptable for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested birth object, two parameters, many siblings), the description is complete: it provides workflow context, clarifies input contract, contrasts with similar tools, and points to full output/error documentation. An agent has enough information to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—every field and sub-field has a detailed description with examples. The description adds no new parameter semantics beyond the 'BirthData follows the global contract' note, which simply references a shared structure already fully documented in the schema. Baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States precisely what it does: derives classical remedial prescriptions from planetary weakness and dusthana lordship, returning mantra, lifestyle, charity, and dignity tables. Explicitly contrasts with sibling tools (lal_kitab_remedies and gemstone_recommendations) to avoid confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow guidance: recommends getting natal chart first and optionally following with gemstone recommendations. Also clearly states what this tool is NOT for (household Lal Kitab totkas, gemstone-only), giving clear when-to-use vs. 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to restate those. It adds valuable context such as the exact-slug requirement, the output/error contract link, and the distinction from bulk/random card tools. This is appropriate given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections: summary, workflow, input contract, disambiguation, and docs link. The major arcana list is long but genuinely useful for exact-slug lookup. The workflow section is arguably unnecessary because it just says 'None', but overall the description remains well-organized and purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two parameters, one required, full schema coverage, an output schema, and annotations covering safety/idempotency, the description covers the remaining needs: valid values, disambiguation from siblings, and a reference to the full output/error contract. Nothing important is missing for an agent to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the baseline is already strong. The description adds value beyond the schema by providing an extended list of valid Major Arcana slugs, a clear Minor Arcana pattern, and explicit 'must be exact' guidance. This helps an agent construct valid card_id values without trial and error.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns full structured data for a single card identified by slug ID, which is a specific verb-resource pairing. It also explicitly distinguishes itself from siblings like asterwise_get_tarot_cards and asterwise_draw_tarot_cards, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete use cases (card detail pages, single-card lookups, post-selection display) and explicitly names alternatives not to confuse it with, including when to use those alternatives. This is explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide readOnlyHint=true, idempotentHint=false, and destructiveHint=false, and the description does not contradict these or claim any side effects. The description does not add extra context about safety, auth, or rate limits, but given the annotations already cover the core behavioral aspects, the description is sufficient and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) but contains some redundancy, as the INPUT CONTRACT repeats parameter details already present in the schema. However, it remains concise overall and does not include extraneous information, making it easy for an agent to parse the essential guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose, usage, and distinctiveness from siblings, and the schema provides parameter details and output format options. Although the description does not specify the exact structure of the 'markdown' vs 'json' response, the schema's response_format enum and the mention of 'confidence level' give sufficient context for an agent to understand the expected output. Overall, the tool is well-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description elaborates on both key parameters: allow_reversed is explained in the INPUT CONTRACT with the note that setting it to false ensures strictly yes/no answers without 'maybe' from reversal, and question includes an example ('Should I accept this job offer?'). Combined with 100% schema coverage for all three parameters (including response_format), the semantic meaning of each parameter is fully conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Draws one card and returns a yes, no, or maybe answer with confidence level' and explicitly distinguishes it from siblings in the 'DO NOT CONFUSE WITH' section, noting that the three-card spread is a positional reading (not binary) and draw_tarot_cards is a free draw without answer logic. This fully clarifies the tool's purpose and its unique role among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section clearly indicates this tool is standalone ('BEFORE: None') and recommends following up with asterwise_get_tarot_three_card_spread when the answer is 'maybe' or more context is needed. The 'DO NOT CONFUSE WITH' section additionally tells the agent when not to use this tool, providing clear usage guidance relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that range cap, date order, and validity are enforced upstream, and clarifies it returns a chronological list without side effects. This supplements the annotation with operational constraints, though it does not fully describe error handling or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into clear sections (description, workflow, input contract, do not confuse) and is appropriately detailed given the large sibling list. It avoids fluff, though the DO NOT CONFUSE section is somewhat repetitive with the WORKFLOW. Overall, every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema is available (as indicated by context) and the description explains the returned data as chronological astronomical events, the description is complete. It also explains the input window and birth context. Minor gap: it does not explicitly mention the output format options (markdown/json), though those are in the schema parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with detailed descriptions, including nested birth fields, enums for ayanamsa and response_format, and defaults. The description adds the input contract (YYYY-MM-DD and 24-month cap) that is not fully explicit in the schema for from_date/to_date, enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists sign ingresses and retrograde/direct stations for all planets between two dates, with an explicit 'against the natal context' qualifier. This distinguishes it from generic transit tools and names the specific astronomical events returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a WORKFLOW section explicitly recommending the before-tool (asterwise_get_natal_chart) and after-tool (asterwise_get_gochar). It also provides a DO NOT CONFUSE WITH section that contrasts with two sibling tools (gochar and dasha_transits), giving concrete selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral detail beyond annotations: formatting noise is ignored, only digits contribute, country code digits are included in the reduction, and the output is harmonic scoring plus interpretive copy. It does not mention auth or rate limits, but the annotations cover the main safety concerns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH, and a docs link, and every section earns its place. The core behavior is front-loaded in the first sentence, and the remaining sections are compact and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema, annotations, and 100% schema coverage, the description is complete enough for correct invocation. It covers the workflow, exclusions, input contract, and points to a full output and error contract URL, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 meaningful semantics for mobile_number by clarifying that formatting noise is ignored and country code digits are included in the reduction sum, which is not fully explicit in the schema. It also frames date as the birth date, though the schema already documents the format and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it digit-strips a mobile string, reduces it with the owner's name and birth date, and returns harmonic scoring plus interpretive copy. It also explicitly names sibling tools it is not, such as asterwise_check_vehicle_number and asterwise_get_business_name_analysis, so an agent can distinguish it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section gives an explicit recommended predecessor (asterwise_get_numerology_profile) and states AFTER: None. The DO NOT CONFUSE WITH section explicitly names alternatives and the conditions that separate them, such as 'plate digit rules, not SIM numbering' and 'letter Expression scan, not phone roots.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by specifying that letters and separators are ignored, that reduction uses numeric digits only, and that the response follows the same harmony schema as mobile analysis. It stops short of summarizing actual error modes beyond linking to the external error contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured into WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH, and a documentation link. Each sentence serves a clear purpose, and the most important behavioral details are front-loaded in the opening sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides invocation context, expected input normalization, sibling-tool disambiguation, a recommended predecessor, and a pointer to the full output and error contract. Since the input schema is fully documented and an output schema exists, the description does not need to restate return values and is complete for an agent selecting and calling this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 four parameters. The description adds value by explaining the input contract for the vehicle_number parameter — letters and separators are stripped and only digits participate in reduction — which is not fully explicit in the individual property descriptions. This complements rather than merely repeats the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: it strips non-digits from a vehicle registration token, reduces the numeric run with owner name and birth date, and returns a harmony schema. It clearly differentiates itself from asteroids mobile-number checking and business-name analysis, so an agent can identify this tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section explicitly recommends running asteroid_get_numerology_profile before this tool and states AFTER: None. The DO NOT CONFUSE WITH section names two siblings and explains why they are not appropriate, which gives an agent concrete guidance on when to 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose read-only, idempotent, and non-destructive behavior. The description adds a behavioral note that inputs are forwarded as-is without local validation, which goes beyond the annotations. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with separate sections for workflow, input contract, and do-not-confuse guidance. Every sentence adds value—there is no fluff or redundant information. The structure makes it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations, schema, and the provided URL for the full output/error contract, the description offers sufficient context for an agent to understand what the tool does, what inputs it expects, and how it relates to sibling tools. The output format is partially described (themes and keywords) and response_format parameter covers the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions for name, date, and response_format, including an enum and default. The description reinforces that name and date are used as-is, adding a small semantic nuance beyond the schema. No parameter is left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reduces a name and birth date using the Chaldean system and returns analyses with themes and keywords. It distinguishes itself from similar tools by explicitly naming the Chaldean approach and contrasting with Pythagorean and Lo Shu methods, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance through the 'DO NOT CONFUSE WITH' section, naming alternatives and when not to use them (e.g., Pythagorean profile, Lo Shu grid). The AFTER workflow also suggests comparing with the Pythagorean profile when needed, giving clear direction on when to use this tool versus related ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, idempotent, non-destructive behavior, so the description does not need to repeat that. It adds genuine behavioral context: the tool outputs exactly 20 festivals, covers solar and tithi-based events, is standalone, and links to the full output/error contract. It does not discuss rate limits or error specifics, but those are partially covered by the annotations and the linked contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core behavior and then uses labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) that make the definition easy to scan. Every section carries operational information, and the docs link replaces a long enumeration of error cases. There is no filler or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with one required field and an output schema, the description supplies the input contract, required-or-alternative parameter groups, output scope, workflow, sibling disambiguation, and a link to the full output/error contract. An agent has everything needed to decide when to use this tool and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, which sets the baseline at 3. The description earns additional credit by adding the year range 1900-2100 that the schema omits and by clarifying the mutually exclusive input groups: either location OR latitude + longitude + timezone. These are non-obvious constraints an agent must know to call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource: 'Computes all major Hindu festival dates for a given year and location.' It enumerates exactly what is returned (20 pan-Hindu festivals, including solar sankrantis and tithi-based festivals) and later disambiguates from sibling tools, so an agent can tell it apart from asterwise_get_panchanga_calendar and asterwise_get_muhurta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit WORKFLOW section stating no prerequisites and identifying the natural next call (asterwise_get_panchanga). It also includes a DO NOT CONFUSE WITH section naming two siblings and the exact conditions that select them: full Panchanga per day vs festival-specific, and auspicious activity windows vs festival calendar. This is exceptionally clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations: it clarifies that Moon sign is computed from birth data, that no prior setup is needed, and that the result is a static lookup rather than a daily score. It also links to the full output and error contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE) with the core purpose front-loaded. Each section adds distinct value, and the documentation link is compact. There is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup with a full input schema, an output schema, and safety annotations, the description covers prerequisites, follow-up usage, sibling disambiguation, and points to the full output/error contract. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 meaning beyond the schema by stating that the birth object is the sole input and that Moon sign is derived from it, which is not explicit in the schema. The INPUT CONTRACT also summarizes the relevant birth fields (date, time, lat, lon, timezone).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Returns'), a specific resource ('four Ghatak (inauspicious) timing parameters'), and the basis ('Janma Rasi (natal Moon sign)'). The DO NOT CONFUSE section explicitly separates it from asterwise_get_nakshatra_prediction and asterwise_get_panchanga, so an agent can distinguish it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section explicitly states no prerequisites ('BEFORE: None') and recommends a follow-up tool ('AFTER: asterwise_get_nakshatra_prediction') for daily auspiciousness. DO NOT CONFUSE names two alternatives and explains why they differ, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral details beyond annotations: the lookup is static, exact-name based, and 'nakshatra_name is forwarded raw — no local fuzzy matching or normalisation.' These are useful operational traits not visible in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a one-sentence summary, followed by clearly labeled WORKFLOW, INPUT CONTRACT, and DISAMBIGUATION sections. Every section earns its place and the external docs link handles deep error/output detail without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a static lookup tool: it states scope, input exactness, standalone behavior, sibling exclusions, expected return categories, and points to a full output/error contract. With an output schema and rich annotations present, nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the parameters. The description adds value by clarifying that nakshatra_name must be exact and is forwarded raw without fuzzy matching, which is a real semantic constraint beyond the schema. It does not add detail for response_format, but the schema covers that fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'looks up static metadata for one of twenty-seven nakshatras by exact name' and names the return content. It also explicitly distinguishes itself from sibling tools in the 'DO NOT CONFUSE WITH' block, so an agent can see exactly what this tool is and is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow context ('standalone', BEFORE/AFTER: None) and explicitly names two sibling alternatives with the condition that selects them: asterwise_get_natal_chart computes birth nakshatra, asterwise_get_dasha uses Moon nakshatra for timing. This gives 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds valuable behavioral context: the four strings are passed through without local guards, and a sanity-check workflow is advised, plus a link to the full output/error contract. It stops short of detailing error cases but the external contract covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly organized into first-sentence summary, WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH, and a docs link. Every section earns its place and there is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, annotations covering safety, and a description that includes workflow prerequisites, input caveats, sibling distinctions, and an external contract link, the agent has everything needed to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents formats for the four name/date parameters. The description adds meaning by clarifying that all four strings pass through without local guards and that the Life Paths are derived from names and birth dates. It also signals the response_format enum through the JSON/markdown phrasing in the schema without needing duplication.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states the specific action, 'Compares two people on Pythagorean Life Path numbers' and lists the returned artifacts: score, tier, narrative, strengths, challenges, advice. It clearly difers from siblings by naming what it is not. This exceeds basic clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section explicitly recommends calling asterwise_get_numerology_profile per person before comparing, and the DO NOT CONFUSE WITH section names the two nearest alernatives and their distinguishing conditions. This gives an agent concrete routing guidance beyond mere inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it is a standalone reference tool, follows classical Vedic tradition, and can return either all planets or one planet; it also links to the full output and error contract. It adds value beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into short, labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE) with the core purpose front-loaded in the first sentence. Every section earns its place by aiding tool selection or invocation, and the formatting makes scanning easy despite the large sibling list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only reference tool with two optional parameters and an output schema, the description is complete: it states purpose, input contract, workflow context, sibling disambiguation, and points to the full output/error contract via URL. Nothing an agent needs to select or invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds meaning for the 'planet' parameter by enumerating all nine allowed values and explicitly stating that omitting it returns all planets. The 'response_format' parameter is already well-explained by the schema enum, so the description does not need to repeat it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and resource ('classical graha (planet) properties'), and clearly scopes the operation to 'all nine planets or a single planet'. The 'DO NOT CONFUSE WITH' section explicitly distinguishes it from puja suggestions and rudraksha recommendations, making sibling differentiation strong.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section states there is no prerequisite ('BEFORE: None') and names the natural follow-up tool ('AFTER: asterwise_get_puja_suggestions'). The 'DO NOT CONFUSE WITH' block explicitly names alternatives and why they are different, giving clear when-to-use versus 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read. The description adds value by specifying what the output contains: pass count out of ten, Rajju/Vedha condition booleans, and per-porutham evidence objects. It also links to a full output and error contract. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well structured with clear labeled sections: WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE WITH. The key scoping sentence is front-loaded, and every section earns its place. The documentation URL is practical and not filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a high-complexity tool with two nested BirthData objects, an output schema, and multiple sibling tools, the description covers purpose, workflow, input contract, sibling differentiation, and links to the full output/error contract. The output schema is present, so return values need not be fully explained in the description. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter. The description adds the input contract reference 'Two BirthData objects per global contract' and points to the documented error contract. Baseline 3 applies for high coverage, and the description earns a 4 by explicitly framing the two-person requirement above what the schema literally states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Runs the Tamil ten-porutham checklist for two charts, counts passes out of ten, surfaces Rajju/Vedha classical condition booleans, and returns per-porutham evidence objects.' It clearly distinguishes this tool from siblings by naming the alternative twelve-porutham tool and the dashakoot tool in the DO NOT CONFUSE WITH section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section explicitly says BEFORE: RECOMMENDED asterwise_get_natal_chart per native, and AFTER: asterwise_get_thirumana_porutham if an extended twelve-koota read is needed. It also names alternatives and the conditions that select them: twelve poruthams including Nadi and Varna versus ten, and dashakoot float scoring versus Tamil pass grid. This is explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior, and the description adds useful behavioral context such as omitting planet returns all nine ggrahas and positioning pujas as complementary to rudraksha. The link to the full output/error contract handles the remaining behavioral disclosure without cluttering the text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a crisp purpose sentence and uses labeled short sections such as WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE, so an agent can scan quickly. Every section carries distinct information and there is no filler or repetition of schema/annotation values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema and safety annotations, the description covers workflow context, parameter semantics, sibling disambiguation, and points to the full contract. An agent choosing between this and any of the many siblings has enough context to route correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 still adds a complete enumeration of the nine allowed planet values plus the omit-for-all behavior, which the schema only hints at with examples. The response_format parameter is already fully described in the schema, so no further prose is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb and resource: 'returns puja (ritual worship) recommendations for planetary propitiation per ggraha'. The 'DO NOT CONFUSE' section explicitly separates it from asterwise_get_remedies and asterwise_get_rudraksha, making the purpose unambiguous even among many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
WORKFLOW provides explicit before/after tool relationships: natal chart first, rudraksha after, and the DO NOT CONFUSE section names the closest alternatives. The INPUT CONTRACT also tells the agent when to omit planet versus supply a specific ggraha.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description need not repeat those. It adds context by specifying the workflow dependency, the behavior when planet is omitted ('Omit to get all nine planets'), and points to a full output/error contract. This exceeds the annotation baseline without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured and front-loaded with a one-sentence purpose. The WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE WITH sections are scannable and each adds distinct value. There is no filler or redundant restating of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the read-only idempotent annotations, optional parameters, and available output schema, the description is complete enough for an agent to invoke the tool correctly. It covers prerequisites, parameter values, sibling disambiguation, and points to the full output/error contract. No critical contextual gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 goes further by enumerating the exact allowed planet values (Sun, Moon, Mars, Mercury, Jupiter, Venus, Saturn, Rahu, Ketu) and explaining the omission behavior, which the schema does not fully specify. This adds meaningful guidance beyond the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Returns Rudraksha bead recommendations per planet.' It clearly scopes the tool to per-planet bead recommendations and explicitly contrasts it with gemstone and puja tools in the 'DO NOT CONFUSE WITH' section, making sibling differentiation strong.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section explicitly names the prerequisite tool (asterwise_get_natal_chart) and explains why it should be called first: to identify planets needing support. It also names two similar-sounding tools and clarifies why they are not appropriate, giving the agent explicit selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish readOnly, idempotent, and non-destructive behavior, but the description adds major behavioral context: it calls upstream endpoints sequentially, merges payloads, and returns a top-level wrapper with nested data fields rather than a flat root. WARNING about nested .data fields and a link to the full output/error contract go well beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into labeled WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE sections, and every sentence carries unique information. The key facts are scoped the composite call and output shape, are presented immediately, and the sibling disambiguation is efficient without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's composite nature, the readOnly/idempotent annotations, and the presence of an output schema, the description covers all important invocation concerns: prerequisite call, post-tool behavior, nested output shape, and to full contract documentation. The agent has everything needed to call the tool correctly and parse its response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully documents birth fields, response_format, defaults, constraints, enums, and formats. The description only refers to 'one BirthData' and does not add per-parameter meaning beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately identifies this as a composite tool that calls the atmakaraka and ishta-devata endpoints and merges their payloads into top-level atmakaraka and ishta_devata objects for one BirthData. It explicitly contrasts it with asterwise_get_natal_chart and asterwise_get_char_dasha, which separates it from a large sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a WORKFLOW section naming asterwise_get_natal_chart as a recommended prerequisite and states that there is no AFTER step, giving an agent an explicit sequence. The DO NOT CONFUSE section names two alternatives and explains why each is not appropriate, satisfying both the 'when to use' and 'when-not-to-use' requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description never contradicts those. The description adds useful behavioral context: the exact output categories returned, the input constraint that either location or coordinates+timezone must be provided, and a link to the full output/error contract. It does not cover error/auth/rate-limit behavior, but with annotations carrying the safety profile, the description adds appropriate extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence carries the core purpose and output content, and the rest is organized into tight labeled blocks: WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH, and a docs link. Each section earns its place and no sentence is redundant with the schema. The structure makes it easy for an agent to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the six-parameter schema, the existing output schema, and annotations that establish the read-only/idempotent profile, the description covers the key decisions: what the tool returns, how to supply the date and location/coordinates, and which sibling tools to avoid. Residual details such as exact error formats and full output fields are delegated to the linked docs and output schema, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 a non-obvious grouping constraint not stated in the schema: 'Either location (city name) OR latitude + longitude + timezone must be provided.' It also reafirms the date format. This is meaningful extra meaning beyond what the property descriptions alone supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Returns Tamil-specific Panchanga for a date and location', then enumerates the distinct contents: four inauspicious periods, Nalla Neram, and the Tamil solar month. It also names similar siblings in the DO NOT CONFUSE WITH block, so the agent can differentiate it from asterwise_get_rahu_kaal and asterwise_get_panchanga without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section explicitly states this is standalone and that asterwise_get_panchanga should be used after for the full Vedic five-limb panchanga. The DO NOT CONFUSE WITH block gives clear when-not-to-use guidance and names the exact alternatives with one-line distinctions. This is explicit alternatives/routing guidance, not merely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety behavior. The description adds transparency by describing it as a standalone catalogue endpoint and linking to the full output and error contract. It does not contradict the annotations, and the additional context is sufficient without being redundant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and a link to documentation. It is slightly verbose because it repeats response_format information from the schema and lists many output fields, but every sentence adds value and the organization makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that returns a large deck with many fields and has only one parameter, the description covers everything needed: the output content, the parameter semantics, the use context, and how it differs from siblings. The link to the full output and error contract further ensures completeness. No output schema is provided, but the description explicitly lists the output fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter response_format is fully described in the input schema with an enum of markdown/json, a default, and a clear explanation of what each format returns. The description also repeats this in the INPUT CONTRACT section, ensuring complete semantic clarity. Schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the complete 78-card Rider-Waite-Smith deck with full metadata, listing the specific fields (id, name, arcana_type, etc.). It also names sibling tools it should not be confused with, making its unique purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool versus alternatives via the 'DO NOT CONFUSE WITH' section, noting that major_arcana returns only 22 cards, suit returns only 14 cards, and draw returns a random draw. It also provides workflow guidance (BEFORE/AFTER) indicating it is a standalone catalogue endpoint to be used as a base for display layers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail beyond those: case-insensitive suit matching, local rejection of invalid values with MCP INVALID_PARAMS, and the structured array return shape. It does not mention auth or rate limits, but the existing annotations lower the burden and the description provides valuable validation context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded purpose, followed by workflow, input contract, sibling disambiguation, and documentation link. Every section earns its place and there is no filler or tautological repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema, full schema coverage, and thorough annotations, the description is complete. It covers validation behavior, output shape, sibling differentiation, and points to a full docs URL for output and error contracts, leaving no critical gap for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 for the suit parameter by enumerating the exact allowed values ('wands', 'cups', 'swords', 'pentacles'), specifying case-insensitivity, and clarifying the local rejection behavior — all beyond what the schema field description provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Returns all 14 cards in a given Minor Arcana suit as a structured array.' It clearly scopes the tool to Minor Arcana suits and disambiguates it from the Major Arcana and full-catalogue siblings, so an agent can identify the tool's purpose precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'DO NOT CONFUSE WITH' section explicitly names asterwise_get_tarot_major_arcana and asterwise_get_tarot_cards and gives the distinguishing criteria (22 Major Arcana vs suit-based; 78-card catalogue). The WORKFLOW section states the tool is standalone, leaving no ambiguity about prerequisites or follow-up calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the description doesn't need to repeat them. It adds a reference to the full output and error contract, which gives users a path to understand error behavior. No contradiction exists between description and annotations, but it doesn't go much beyond the annotations for behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections like WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE WITH. It is informative without being verbose, and the link to the full contract avoids embedding unnecessary details. The formatting enhances readability and scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (nested birth object, multiple output fields), the description covers the essential context: what it computes, recommended prerequisites, key output concepts, and a link to the full contract. The presence of an output schema means return values are handled separately, and the description sufficiently bridges the tool's purpose and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions for all parameters, so the baseline is 3. The description adds extra clarity by emphasizing that 'year' is the true Gregorian return year and not an age, and it provides workflow context. This modest additional guidance raises the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool computes the annual Tajika-style solar return and lists the specific outputs (Muntha, Pancha Adhikari, Tajika aspects, varshaphal positions). It also distinguishes itself from sibling tools like dasha and transits in the 'DO NOT CONFUSE WITH' section, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly specifies when to use this tool by recommending a prerequisite (asterwise_get_natal_chart), and clarifies the input contract (supply the true Gregorian return year, not age). It also explicitly warns against confusion with dasha and transit tools, providing clear alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that house_system is ignored and that the response contains composite planets with dignities and aspects, going beyond the annotations. However, it does not detail error behavior, though it links to a full output and error contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE, and contract link sections. Every sentence provides useful information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested parameter objects and output schema, the description is complete enough for an agent to invoke the tool correctly. It specifies prerequisites, differentiates from closely related tools, notes ignored parameters, and points to the full output and error contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with detailed descriptions for person1, person2, and response_format. The description adds valuable caveats such as 'house_system ignored' and clarifies that each person uses WesternBirthData, supplementing the schema meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning a midpoint composite chart for two people, with composite planets, dignities, and aspects. It explicitly differentiates this from synastry and numeric compatibility tools in the DO NOT CONFUSE section, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section gives explicit guidance to examine inter-chart aspects via asterwise_get_western_synastry before the composite. The INPUT CONTRACT and DO NOT CONFUSE sections clarify when this tool is appropriate versus synastry or compatibility tools, providing strong usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints, and the description adds behavioral context beyond those: it specifies the computation engine, clarifies that this is the tropical system rather than Vedic, and enumerates the exact returned values. The docs link additionally references the output and error contract, although the description itself could have said a little more about error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a concise summary, then organized into labeled sections for workflow, input contract, sibling differentiation, and full documentation. Every section serves a distinct purpose with no filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations, output schema, input schema, and sibling list, the description is complete: it covers what the tool returns, how to call it, what to call instead, what to call next, and where to find the full contract. Nothing an agent needs to invoke this safely is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, and the description adds a concrete example value ('2026-05-01') and reinforces that the date is optional and defaults to today. The response_format parameter is not echoed in the prose, but the schema describes it fully with an enum and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Calculates'), a clear resource ('tropical lunar phase'), a date scope ('for any date'), and the return fields. It also explicitly distinguishes itself from its closest siblings in the 'DO NOT CONFUSE WITH' section, so an agent can identify this tool without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states standalone usage ('BEFORE: None — standalone'), suggests the natural next step for full-month data, and explicitly warns against confusing this tool with the calendar and Vedic panchanga tools. This gives 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the operation as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context: the calculation uses natal tropical longitude, occurs at the birth location, and the after_date parameter defaults to today, which goes beyond what the annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: a clear one-sentence summary is followed by labeled WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE sections. Every section serves a purpose, and the external docs link covers deeper contracts without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a complex tool: it specifies prerequisites, follow-up, parameter expectations, sibling disambiguation, and points to the full output/error contract. Since an output schema is present, not detailing return values in the description is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 enumerating all valid planet values (Sun through Pluto), listing the required birth input contract, and clarifying that after_date defaults to today—details that reinforce and extend the schema without being redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's precise function: finding the next exact moment a specified planet returns to its natal tropical longitude and building a complete Western natal chart for that moment. It also names the two closest sibling tools and explicitly states what this tool is not, making differentiation easy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow instructions: BEFORE this tool use asterwise_get_western_natal, AFTER None. It also explicitly warns not to confuse this tool with the Sun-only and Moon-only return shortcuts, giving an agent clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful operational detail, such as ignoring house_system and using return computation defaults, while not contradicting the annotations. It does not discuss side effects, but none are expected given the read-only hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings and front-loaded purpose. It is slightly repetitive in restating the input contract in prose, but remains efficient and scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema is available and the description provides workflow, parameter semantics, and sibling distinctions, the context is complete. The external link to full output/error contract also covers any remaining details without bloating the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters with descriptions. The description adds critical semantics beyond the schema, notably that house_system is ignored for solar return computations and that year is the calendar year, not age, which prevents misuse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a solar return chart for a given year by finding the exact moment the Sun returns to its natal tropical longitude. It explicitly differentiates itself from lunar return and Vedic Varshaphal tools, so an agent can distinguish it from relevant siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit WORKFLOW instruction to understand the natal chart before reading the return. It also names alternatives to avoid confusion (lunar return and Varshaphal), giving 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that house_system is ignored for this endpoint, that start_date defaults to today, and defines the transit orbs used (major 3°, sextile 2°, minor 1°). This adds behavioral context beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured with short sentences, explicit sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH), and zero fluff. Every sentence earns its place: it defines the output, states the orbs, gives defaults, sequences dependencies, and links the full contract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema, nested objects, and full schema coverage, the description covers the essential operational context: prerequisites (natal chart first), input contract, defaults, exclusion of house_system, and links to full docs. Nothing an agent needs to correctly select and invoke the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds meaning by explaining the birth object is WesternBirthData, noting which nested field is ignored for this endpoint (house_system), and clarifying start_date optionality and default behavior. It doesn't restate every schema field but adds workflow-relevant semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Current sky positions vs natal chart for a single day'), names the exact output (all 10 planets with tropical longitudes and active aspects), and differentiates itself from two siblings by day count. An agent can tell it apart from weekly/monthly variants without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section explicitly says BEFORE calling get_western_natal to establish the natal chart first and AFTER calling weekly for a week view. The 'DO NOT CONFUSE WITH' section lists the two sibling tools and the distinguishing duration (7 days vs 1 day, 30-day window vs single day). This is explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, and the description does not contradict them. While the description adds context about response formats (markdown vs json) and defaults, it does not elaborate on side effects or system impact beyond what annotations imply. Given the annotation coverage, the description is consistent and adequate, though not overly detailed on behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (DESCRIPTION, WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and avoids redundant prose. However, it repeats some default information that already appears in the schema (e.g., start_date defaults to today), making it slightly verbose. Overall, it remains compact and scannable for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary context: what the tool computes, default behavior, workflow prerequisites, related tools to avoid confusion, and a link to full documentation. Since the tool has an output schema (as indicated by 'Has output schema: true'), the description does not need to explain return values, and it provides enough information for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter (including nested birth fields) having descriptive text. The description adds extra semantic value by explaining the purpose of start_date (setting month start) and noting that house_system is ignored, which is not immediately obvious from the schema alone. This enriches parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '30-day transit window vs natal chart' and returns 'day-by-day transit snapshots plus peak aspects.' It also specifies the default behavior ('defaults to today') and differentiates from daily and weekly variants via the 'DO NOT CONFUSE WITH' section, making its scope 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage instructions, including how to set the month start via 'Use start_date to set the month start; defaults to today.' It also lists the correct workflow prerequisite ('BEFORE: asterwise_get_western_natal') and explicitly warns against confusion with the daily and weekly counterparts, giving clear guidance on when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds transparency by noting that the house_system parameter is ignored for this tool, and that start_date defaults to today when omitted, giving users realistic expectations about parameter handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into concise sections (purpose, workflow, input contract, warnings, external reference), making it easy to scan. It avoids unnecessary verbosity while covering all essential aspects in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the tool's purpose, workflow integration, parameter clarifications, and a link to the full output/error contract. This is sufficient for an agent to correctly invoke the tool without needing additional context, especially given the high schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides thorough descriptions for all parameters (birth, start_date, response_format), achieving 100% coverage. The description adds one extra semantic note: house_system is ignored, which clarifies a potential confusion given the schema includes it. This slight addition warrants a score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a 7-day transit window against a natal chart, returning daily snapshots and peak aspects. It also distinguishes it from daily and monthly transit tools, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells users to use this tool for a week-long transit view, and directs them to daily or monthly variants for other time spans. It also lists the recommended preceding call (natal chart) and following call (monthly transits), providing clear guidance on when to use this tool in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the '00:00' time edge case and the warning that yoga house logic may be wrong if true birth time is unknown. It also links to the full output/error contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear labeled sections: purpose, workflow, input contract, disambiguation, and documentation link. Every section earns its place, and the core purpose is front-loaded in the first sentence. It is detailed but not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the presence of an output schema, and rich annotations, the description is complete. It covers the core behavior, workflow context, input contract caveats, sibling disambiguation, and points to the full contract. Nothing an agent needs to decide whether to call this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 meaningful parameter-level guidance by clarifying the global BirthData contract and explicitly warning about the '00:00' time value, which is not fully explained in the schema. This extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Evaluates'), a specific resource ('natal chart'), and a clear scope ('named classical yogas'), and lists the exact output fields per hit. The DO NOT CONFUSE WITH section explicitly distinguishes it from asterwise_get_natal_chart and asterwise_get_panchanga, so an agent can separate it from siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section gives explicit before/after recommendations: run asterwise_get_natal_chart first and asterwise_get_doshas after. The DO NOT CONFUSE WITH section names alternatives and explains why they are not this tool. This is unusually complete usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral details: the output location (data.periods.root[]), date formatting (DD/MM/YYYY), depth semantics, and local validation of levels. It also links to the full output and error contract. The readOnly and idempotent annotations align with the described compute-and-return behavior, with 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into workflow, input contract, and disambiguation sections, making it easy to parse. It is slightly repetitive (e.g., mentioning data.periods.root and DD/MM/YYYY twice), but the structure and clarity justify the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of nested objects and an output schema, the description is complete: it specifies input constraints, output shape, date formats, related tools, and a link to the full contract. An agent has enough context to invoke the tool correctly and understand expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides thorough descriptions for all parameters, including defaults, formats, and allowed values. The description adds useful context about level validation and the relationship to sibling tools, though it does not dramatically expand on the schema's already high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states that the tool computes the 108-year Ashtottari Dasha tree with configurable depth and returns periods under data.periods.root. It also explicitly distinguishes this tool from asterwise_get_dasha (Vimshottari) and asterwise_get_yogini_dasha, leaving no ambiguity about its 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow guidance, recommending asterwise_get_natal_chart before use and asterwise_get_dasha for optional Vimshottari comparison. It also includes explicit 'DO NOT CONFUSE WITH' notes, which effectively tells an agent when to use this tool versus closely related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the baseline is low. The description adds context about the workflow (recommended order) and clarifies that it reads 'from BirthData', which implies a read-only operation. However, it does not explicitly mention side effects or lack thereof beyond the annotations, so a small gap remains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Despite being long, the description is highly structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and front-loads the purpose. No wasted words; each sentence carries distinct value, and the flow guides the reader efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is self-contained and thorough: it states what the tool returns, how it fits in a larger workflow, differentiates it from similar tools, and even points to a full documentation URL. Given the complexity (multiple bala types, vargas, karaka maps), this is more than sufficient for an agent to decide when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – every parameter and subfield is described. The description goes beyond the schema, e.g., explaining that omitting time uses a sunrise chart and not to pass '00:00' for unknown, and giving default Ayanamsa as 'lahiri' with a recommendation. This adds practical meaning that helps invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states what the tool does: 'Aggregates Shadbala, Bhavbala, Vimshopaka...' and is clearly distinguished from sibling tools like asterwise_get_yogas and asterwise_get_ashtakavarga. The verb 'Aggregates' plus the specific resource (BirthData) and the list of outputs make 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The workflow section gives explicit before/after recommendations: 'BEFORE: RECOMMENDED — asterwise_get_natal_chart' and 'AFTER: asterwise_get_yogas — optional'. The 'DO NOT CONFUSE WITH' section explicitly names alternatives and what they are, so when-to-use and when-not-to-use are crystal clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful runtime behavior, such as the sunrise-chart fallback when time is omitted and the 'never pass 00:00' warning. It does not discuss rate limits or auth, but the annotations cover the core behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings and each section serves a distinct purpose: purpose, workflow, input contract, and disambiguation. Despite being detailed, it avoids redundant prose and stays focused on actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context for an agent to decide when to use this tool, what inputs to provide, what defaults apply, and how it differs from closely related crystal and gemstone tools. It also includes a link to the full output/error contract and implies key output fields like match_score and match_reasons.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All schema parameters are described, including nested birth fields like lat/lon with ranges, time with format and special unknown-value semantics, ayanamsa enum meanings, timezone default, and response_format. The description adds practical examples and clarifies edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: recommends crystals from a Vedic natal chart using house lordship rules. It also explicitly distinguishes this from zodiac/chakra-based matching, 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.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear workflow with BEFORE/AFTER steps, input contract details, defaults, and a dedicated 'DO NOT CONFUSE WITH' section that differentiates it from several sibling tools. It also links to the full output and error contract.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description adds behavioral details: it performs today's transit correlation, returns scored correlations, and requires only birth data. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is a clear purpose statement and the uppercase sections help scannability, but the description is longer than necessary with some redundancy (AFTER vs DO NOT CONFUSE WITH and the final URL).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for use: it covers output content, workflow, today's fixed date, alternatives, and points to the full output/error contract. Since an output schema exists, not detailing return values is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; description adds meaningful context by clarifying that there is no date parameter and that birth data follows a global contract, while the schema already documents each field with examples and constraints. The wording around unknown birth time is slightly opaque, preventing a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: combines active Vimshottari lords with today's transits, returning scored correlations plus transit longitudes and houses. The title and sibling list make it distinct from asterwise_get_gochar, asterwise_get_transits, and asterwise_get_dasha.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow guidance: natal chart is recommended before, gochar is optional after, and DO NOT CONFUSE WITH statements differentiate the three closest sibling tools. It also states that no date field is needed because 'today' is fixed by the API.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately reflects the read-only, idempotent, non-destructive annotations and adds useful behavioral details such as returning a deduplicated list and being time-dependent on the server clock. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, but the all-caps formatting and repetitive emphasis on 'no birth data' and 'no date parameter' add some redundancy. Overall it remains concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes the key output fields, the input contract, the absence of a date parameter, and a follow-up workflow recommendation when natal confirmation is needed. It gives enough context for an agent to invoke the tool correctly without requiring additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for lat, lon, and response_format, so the baseline is 3. The description reinforces that only lat and lon are needed and explicitly states there is no date parameter, which adds useful semantic clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes KP ruling planets for the current instant at a given lat/lon with no birth data, and lists the specific outputs (day lord, Moon/Ascendant lord chains, deduplicated ruling_planets list). It also explicitly distinguishes this from the KP chart and prashna chart tools, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says there is no birth data and that 'now' is implicit on the server clock, which is crucial for correct use. It also names when to use this tool versus alternatives (KP chart needs BirthData, prashna chart is for horary keywords) and provides a workflow hint to follow up with asterwise_get_kp_chart if natal confirmation is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent hints, the description explains the SHA-256 seeding, deterministic behavior across callers, and the distinction from individual readings. This adds meaningful context about side effects (none) and output consistency, exceeding what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH, link to documentation) and front-loaded purpose. It is somewhat verbose, repeating schema info in prose, but the redundancy is not excessive and each section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, workflow, alternatives, and points to a full output/error contract via URL. Given the tool's low complexity (3 simple params) and presence of an output schema, nothing is left ambiguous for a typical caller.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters (date, allow_reversed, response_format) with 100% coverage. The description adds extra determinism detail for allow_reversed (seeded by date+'_rev') but omits any mention of response_format, missing an opportunity to clarify the JSON output. Still, it adds some value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a deterministic daily tarot card seeded by a date hash, and explicitly differentiates it from random draw and three-card spreads. It also clarifies the collective, non-individual nature of the reading, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit BEFORE/AFTER workflow context and a 'DO NOT CONFUSE WITH' section naming alternative tools (random draw and three-card spread). It also notes the date defaults to today, giving concrete guidance on when to use this tool and when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the read-only nature is covered. The description adds behavioral warnings about 'silently produces the wrong return' when year is actually age, and that accurate birth time is required for reliable Saham interpretation—useful context 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with distinct sections (COMPUTES, BEFORE, AFTER, INPUT CONTRACT, DO NOT CONFUSE WITH, full docs link). Each section earns its place, and the repetition of warnings (e.g., year vs age) is purposeful reinforcement rather than fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a domain-specific Vedic astrology tool, the description provides sufficient workflow context (base chart needed first, Harsha Bala afterward) and points to a full output/error contract. It correctly assumes domain knowledge about Sahams while making the call flow clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the prose enriches every key parameter: target_year is clarified as 'not age', birth.time explains the sunrise-chart fallback and explicitly warns never to pass '00:00' for unknown. These are critical semantic clarifications that go well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'computes all 10 Tajika Saham (sensitive points) for a Varshaphal solar return chart', which is a specific verb on a specific resource. The DO NOT CONFUSE WITH section clearly distinguishes it from the base Varshaphal chart and Harsha Bala scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The BEFORE/AFTER instructions tell the agent to first retrieve the base Varshaphal chart and later check Harsha Bala, while the DO NOT CONFUSE WITH section names three sibling tools and explains when not to use them. This gives explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description reveals that content is AI-synthesised, that response_format only changes rendering, and that results include model/period metadata. It also points to a full output and error contract URL, so the tool's behavioral and error profile is well disclosed with 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal but earns its length: core function is front-loaded and the WORKFLOW/INPUT CONTRACT/DO NOT CONFUSE sections are scannable. Some redundancy exists ('chosen horizon' vs. the period parameter), but nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter, well-annotated tool with an output schema, the description covers workflow, input constraints, output highlights, sibling confusion, and directs to a full error/output contract. An agent has everything needed to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is a 3. The description adds useful constraints beyond the schema: sun_sign must be English zodiac names only, no Sanskrit aliases, and response_format affects rendering only. This clarifies ambiguity without compensating for missing schema docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names the exact resource ('Western sun-sign horoscope'), the action ('Fetches'), and the output shape (structured guidance fields plus metadata). It also calls out the Western/tropical distinction, so it is clearly separable from the many sibling astrology tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section states the tool is standalone and names asterwise_get_western_natal as the AFTER option when a personalised chart is needed. DO NOT CONFUSE WITH explicitly contrasts asterwise_get_horoscope (Vedic Moon-sign) and asterwise_get_western_natal, giving an agent clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower; the description still adds substantial behavioral context by warning that an incorrect timezone shifts the Ascendant, noting that house_system is accepted here but silently ignored by other endpoints, and clarifying that ayanamsa is always tropical even if a value is supplied. This goes well beyond the structured annotations and helps an agent anticipate surprising behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections (WORKFLOW, INPUT CONTRACT, IMPORTANT, NOTE, DO NOT CONFUSE WITH) and front-loads the core purpose in the first sentence. Every section earns its place given the nested parameter object, timezone pitfall, and confusing sibling landscape; a few typographical artifacts and duplicated schema examples keep it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested inputs, multiple house systems, timezone sensitivity, and over 100 sibling tools, the description covers the full workflow, input contract with examples, failure-relevant pitfalls, and disambiguation. Since an output schema exists, the description need not enumerate return fields, and the docs link covers the full output/error contract. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 meaning beyond the schema by explaining why timezone matters (house cusps/Ascendant), by noting the house_system quirk across sibling endpoints, and by explicitly documenting the absent ayanamsa field. Some content repeats schema examples, but the additional contextual guidance pushes it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-qualifier pair — 'Calculate a complete Western natal chart using the tropical zodiac and Swiss Ephemeris' — and lists concrete outputs (10 planets, house placements, dignities, aspects, balance statistics). It explicitly disambiguates from asterwise_get_natal_chart (Vedic/sidereal) and asterwise_get_western_aspects (raw longitudes), so an agent can distinguish this tool from close siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance with a 'DO NOT CONFUSE WITH' section naming two alternatives and the exact conditions that select them (Vedic vs tropical; full chart vs already-known positions). It also includes a WORKFLOW section saying this tool is standalone and lists downstream AFTER tools (transits, synastry, solar return), giving sequencing context that is rare and valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them. It adds significant context beyond annotations: cryptographic randomness via Python secrets.SystemRandom, per-call independence with no session state, local rejection of out-of-range counts with MCP INVALID_PARAMS, and a 50% per-card reversal chance that is explicitly 'not seeded.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core behavior in the first sentence, then organized into labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) that make it scannable. There is no filler; examples, validation notes, and the docs link all earn their place, and the length is proportionate to the three near-sibling tools it must disambiguate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Between the annotations (safe read operation), the output schema, and the docs link for the full output/error contract, nothing an agent needs to invoke this tool correctly is missing. The reminder to interpret drawn cards via active_meaning and active_keywords fields also closes the loop on how results should be consumed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all three parameters; the description adds strong value with concrete examples (1 daily pull, 3 simple reading, 10 Celtic Cross, 78 full deck), the 1–78 boundary with local validation behavior, and probability mechanics for allow_reversed (50% per card, independent, not seeded). Minor gap: response_format is absent from the INPUT CONTRACT section, though its schema description is thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'Draws N unique random cards from the 78-card deck' — and adds scope-defining traits (unique, cryptographic randomness, no session state). The 'DO NOT CONFUSE WITH' block names the three closest tarot siblings and their distinguishing behavior, so an agent can select this tool without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool is standalone with no prerequisites or follow-up ('BEFORE: None', 'AFTER: None'). The 'DO NOT CONFUSE WITH' section names asterwise_get_tarot_card_of_the_day, asterwise_get_tarot_three_card_spread, and asterwise_get_tarot_celtic_cross with the precise differences (deterministic vs positional vs random), leaving no ambiguity about when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description ('Returns') is consistent. No contradiction exists. The description adds context about filtering and sorting, which is harmless and does not mislead about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses clear section headers (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and every sentence provides distinct, necessary information (scope, sorting, exclusions, related tools). No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though an output schema exists (so return values need not be explained), the description fully covers what the tool does, its filtering, and its relationship to other tools. This is enough for an agent to decide when to call it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described). The description adds extra value by listing all valid planet values in the INPUT CONTRACT (Sun, Moon, Mars, Mercury, Jupiter, Venus, Saturn, Rahu, Ketu), which is more precise than the schema's example 'Venus' or 'Saturn'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Returns all crystals associated with a specific Vedic planet.' It further distinguishes itself by clarifying the sorting (Navaratna first, Uparatna substitutes) and exclusions (no Vedic correspondence), which clearly separates it from sibling crystal tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit workflow is provided: BEFORE (use natal chart to identify planet) and AFTER (use gemstone recommendations for prescription). The DO NOT CONFUSE WITH section names alternatives and explains when each should be used (e.g., gemstone recommendations for actual prescription, not just listing), giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details not covered by annotations, such as 'Unknown birth time at midnight is accepted silently,' and clarifies output types like 'presence flags, typed detail objects, optional summaries, and remedy lines.' These enrich the readOnlyHint and idempotentHint already present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH), each serving a distinct purpose. It is concise yet comprehensive, avoiding redundancy while covering essential operational aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes the input contract, workflow context, differentiation from siblings, and a link to the full output/error contract. Given the tool's moderate complexity, this provides sufficient context for correct usage without needing to restate every schema detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema already provides detailed descriptions for parameters, the description adds valuable semantics by noting that omitting birth time uses a sunrise chart and sets birth_time_provided=false, clarifying the behavior for the 'time' field. This goes beyond the schema's basic default description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Scores twelve fixed dosha buckets from birth data and returns presence flags, typed detail objects, optional summaries, and remedy lines per dosha.' It also explicitly differentiates from similar tools like asterwise_get_chart_strength and asterwise_get_compatibility, making its unique purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance with 'WORKFLOW: BEFORE: RECOMMENDED — asterwise_get_natal_chart' and 'AFTER: asterwise_get_remedies.' It also includes a 'DO NOT CONFUSE WITH' section that names alternatives and explains why they should not be chosen instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds meaningful beyond the annotations: it discloses the Goodwin/Balliett per-part method, explains why master numbers are preserved, and clarifies that name parts are reduced separately before summing. It also points to the output/error contract URL, adding behavioral context beyond what annotations and schema convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Organized with clear labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and front-loads the core calculation method in the first sentence. Every section earns its place and the length is appropriate for a tool that needs to distinguish itself among many sibling numerology tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to explain return values. It covers the calculation method, input requirements, workflow position, sibling distinctions, and error/out contract via a link. There is no missing information that would prevent an agent from selecting and invoking this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 genuine value for the name parameter: full legal name as used at birth, space-separated parts, any case allowed, and a minimum one alphabaetic character constraint. It does not diacuss response_format, but the schema already fully documents that enum and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States the specific operation: calculates the Expression/Destiny number from a full name using Pythagorean letter values, with concrete method details (per-part reduction, master number preservation). It also explicitly differentiates itself from sibling numerology tools, so an agent can immediately identify what this tool uniquely does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit WORKFLOW section stating it is standalone and names the natural after-step (soul_urge_number). Also has a dedicated DO NOT CONFUSE WITH section listing four sibling tools and the exact condition that makes them alternatives, which is ideal guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnly, idempotent, non-destructive, and the description adds non-obvious caveats: ayanamsa choice is not enforced locally and mismatched settings still post upstream, and time='00:00' is accepted without warning. This goes beyond structured fields and warns about edge cases that could corrupt interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then organized into short labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH). Every section adds distinct value and no sentence is redundant with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, rich input schema, and safety annotations, the description supplies the remaining context: workflow position, sibling distinctions, input edge cases, and a link to the full output/error contract. An agent has enough information to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 useful parameter-level caveats beyond the schema, such as that time='00:00' is accepted without warning and ayanamsa mismatches are not locally validated; it also connects BirthData to the output without restating schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: builds a KP natal chart with sub-lords on grahas and twelve cusps from BirthData. It also explicitly disambiguates from asterwise_get_natal_chart ('classical bundle without KP sub-lords') and asterwise_get_kp_ruling_planets ('live moment rulers, not natal cusps'), making the tool's identity clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit routing guidance: a DO NOT CONFUSE WITH section names sibling tools and states the contrast, and the WORKFLOW section says this tool precedes asterwise_get_kp_significators for house-level significator chains. It also gives a BEFORE recommendation to cross-check birth records, which helps agents decide when results are trustworthy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds meaningful behavioral detail beyond annotations: which letters count, Y always treated as a consonant, per-name-part reduction, and preservation of master numbers 11, 22, and 33. This is precisely the kind of algorithm-level context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: calculation overview, WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH, and a docs link. It is front-loaded with the essential calculation rule and contains no filler; the only small redundancy is restating the Y rule, but it remains useful as an input contract reminder.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description does not need to explain return values. It covers the input contract, examples, master-number behavior, workflow placement, sibling disambiguation, and includes a URL to the full output/error contract. Nothing essential is missing for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is adequate. The description enriches the name parameter with a fuller contract ('Full legal name as used at birth'), concrete examples, and the Y-is-always-a-consonant rule. However, this slightly conflicts with the schema's 'as commonly written' wording, creating minor ambiguity about which name form is authoritative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Calculates the Personality number from consonants in the full name.' It further differentiates from the most similar siblings by naming the Expression number (all letters) and Soul Urge number (vowels only). This makes 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.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section explicitly says the tool is standalone BEFORE and points to asterwise_get_numerology_profile AFTER for seeing all five core numbers together. The 'DO NOT CONFUSE WITH' section names the exact alternatives and what distinguishes them, giving an agent 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses key behavioral traits: unique non-repeating cards, cryptographic randomness, and the independent 50% reversal chance when allowed. This explains the non-idempotent nature and adds context the annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and organized with clear labels (WORKFLOW, BEFORE, AFTER, INPUT CONTRACT). Every section adds decision-relevant information and avoids filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tarot tool with an output schema and contract link, the description covers the spread layout, card uniqueness, randomness, reversal behavior, input constraints, and relation to sibling tools. No critical calling information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters, but the description adds meaningful detail: 'allow_reversed' has an explicit 50% reversal rule, 'question' has a 500-character limit and an example, and the output/error contract is linked. 'response_format' is less described in prose but is fully covered by the schema enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific tool ('Ten-card Celtic Cross spread') and states exactly what it does: draws 10 unique cards using cryptographic randomness and assigns them to the 10 classical positions. It also names sibling tools it should not be confused with, so an agent can select it 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WORKFLOW section explicitly says when to use this tool standalone and when to follow the three-card spread, and the 'DO NOT CONFUSE WITH' section lists three alternatives with their distinguishing use cases. This gives an agent explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes 'WORKFLOW: BEFORE: None — standalone. AFTER: None.' which clarifies no side effects, complementing the annotations (readOnlyHint, idempotentHint, destructiveHint). It also states the output format parameter, so the agent knows it produces markdown or JSON.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, supported, workflow, input contract, disambiguation) and each section serves a necessary role. It is detailed but not redundant, and the formatting makes it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of sibling tools, the description provides complete context: purpose, supported inputs, disambiguation from relevant alternatives, workflow, input contract, and a link to full output/error docs. It also indicates the output options via the response_format parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema: 'number' as the angel number sequence with examples, and 'response_format' with enum and default. The description's 'INPUT CONTRACT' section reinforces the meaning with examples, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lookup the meaning of a specific angel number by its sequence.' It also specifies supported sequences and explicitly names sibling tools to avoid confusion (asterwise_get_angel_number_today, asterwise_get_angel_number_personal, asterwise_get_number_meaning).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance through the 'DO NOT CONFUSE WITH' section, listing specific alternatives and explaining the difference (e.g., today's daily number, personal number from birth date, Pythagorean numerology). This tells the agent exactly when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
shields.io Endpoint
For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/asterwise/asterwise-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server