Asterwise

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

Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable context beyond this: it explains that formatting noise is ignored, only digits contribute, country code digits are included, and it's classified as FAST_LOOKUP. However, it doesn't detail rate limits or authentication needs, which would elevate it to a 5.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.), front-loading key information. Every sentence adds value—no fluff or repetition—making it efficient and easy to parse.

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

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

Given the tool's complexity (numerology analysis with multiple inputs), the description is highly complete. It covers purpose, usage, input handling, output structure (detailed in OUTPUT CONTRACT), error handling, and sibling differentiation. With annotations and an output schema present, the description provides all necessary context without redundancy.

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

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

With 0% schema description coverage, the description must compensate. It explains that mobile_number accepts various formats (bare ten digits, plus-country-code with spaces/hyphens), name and date are used for owner numerology comparison, and response_format controls output serialization. This adds meaningful semantics, though it doesn't specify date format or name handling details.

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

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

The description clearly states the tool's purpose: it digit-strips a mobile number, reduces it with owner's name and birth date, and returns harmonic scoring plus interpretive copy. It specifically distinguishes from sibling tools like asterwise_check_vehicle_number and asterwise_get_business_name_analysis, making the scope explicit.

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

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

The description provides explicit guidance on when to use this tool versus alternatives (e.g., 'Not for vehicle plates' and references to specific sibling tools). It also recommends a prerequisite tool (asterwise_get_numerology_profile) and clarifies there's no follow-up tool, offering comprehensive usage context.

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

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

Annotations provide readOnlyHint=true, destructiveHint=false, etc., covering safety. The description adds valuable context beyond annotations: it specifies that 'Today' is implicit with no date parameter, signs are in English not Sanskrit, and includes compute class (MEDIUM_COMPUTE) and error contracts. It doesn't contradict annotations, but could mention rate limits or caching behavior for a more complete 5.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, etc.), front-loading key information. Every sentence adds value—no redundancy or fluff. It efficiently covers purpose, usage, parameters, output, and distinctions in a compact format.

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

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

Given the tool's complexity (astrological calculations), rich output schema, and annotations, the description is complete. It explains the tool's scope, workflow, input/output contracts, compute class, errors, and sibling distinctions. The output schema exists, so the description doesn't need to detail return values, and it adequately supplements the structured data.

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

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

Schema description coverage is 50% (birth object has descriptions, response_format lacks description). The description compensates by detailing the 'BirthData global contract' and specifying that 'response_format=json serialises... response_format=markdown renders...' This adds meaning beyond the schema, especially for response_format. However, it doesn't fully explain all parameter nuances (e.g., ayanamsa defaults), keeping it from a 5.

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

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

The description explicitly states the tool '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.' This is a specific verb ('evaluates') with clear resources (Saturn's cycle phases, natal data) and outputs. It distinguishes from siblings by naming 'asterwise_get_gochar' and 'asterwise_get_dasha_transits' as different tools.

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

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

The description provides explicit guidance on when to use this tool vs. alternatives: 'It is not general Gochar (asterwise_get_gochar) or dasha overlay (asterwise_get_dasha_transits).' It also recommends workflow steps: 'BEFORE: RECOMMENDED — asterwise_get_natal_chart — confirm Moon sign context. AFTER: asterwise_get_gochar — broader transit canvas if needed.' This clearly defines context and exclusions.

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

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

The description adds valuable behavioral context beyond annotations. Annotations indicate read-only, open-world, idempotent, and non-destructive operations, but the description details specific processing rules (e.g., 'Letters and separators are ignored; reduction uses numeric digits only'), error handling (e.g., 'INVALID_PARAMS (local — caught before upstream call): None'), and performance class ('FAST_LOOKUP'). It does not contradict annotations, which already cover safety aspects.

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

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

The description is structured with clear sections (e.g., 'WHAT THIS TOOL COVERS', 'WORKFLOW'), which aids readability, but it is verbose with redundant details. For example, the 'OUTPUT CONTRACT' and 'RESPONSE FORMAT' sections could be more concise, and some information (like 'Edge cases') repeats earlier points. It is front-loaded with core functionality but includes excessive elaboration.

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

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

Given the tool's complexity (numerology analysis with multiple inputs and outputs), the description is highly complete. It covers purpose, usage guidelines, input processing rules, detailed output fields, response formats, error handling, performance, and sibling differentiation. With an output schema present, it appropriately focuses on behavioral context rather than repeating return values, making it sufficient for effective tool use.

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

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

With 0% schema description coverage, the description compensates by explaining parameter semantics. It clarifies that 'vehicle_number' handles 'Indian pattern plates (e.g. MH01AB1234) and international variants' and that 'name' and 'date' are used with the vehicle number for 'reduction'. It also details 'response_format' options ('json' vs 'markdown') and their effects, adding meaning not in the schema.

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

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

The description clearly states the tool's purpose: 'Strips non-digits from a vehicle registration token, reduces the numeric run with owner name and birth date, and returns the same harmony schema as mobile analysis.' It specifies the verb (strips, reduces, returns), resource (vehicle registration), and distinguishes it from sibling tools like 'asterwise_check_mobile_number' and 'asterwise_get_business_name_analysis' 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.

Does 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. It states 'Does not analyse phone numbers (asterwise_check_mobile_number) or business names' and includes a 'DO NOT CONFUSE WITH' section listing specific sibling tools. It also recommends a 'BEFORE' tool (asterwise_get_numerology_profile) for owner baseline, offering clear workflow context.

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

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

Adds significant behavioral context beyond annotations: explains cryptographic randomness, fresh draws per call, and reversal probability. No contradiction with readOnlyHint annotation.

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

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

Well-structured with clear sections, concise sentences each adding value. No wasted words.

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

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

Complete for a draw tool: covers input parameters, output structure, and random behavior. Output schema is described in detail.

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

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

Description adds meaning for 'count' and 'allow_reversed' (ranges, defaults, behavior) beyond schema. Does not mention 'response_format' parameter, but schema covers it. Good compensation for 0% schema coverage.

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

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

Clearly states 'Draw N random unique cards' from a specific deck using cryptographic randomness, distinguishing it from sibling tools like get_tarot_card or get_tarot_cards.

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

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

Provides detailed input contract but no explicit guidance on when or when not to use this tool compared to other tarot-based siblings. Implicit context is present but not explicit.

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

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

Description adds significant behavioral detail beyond annotations: specifies return fields (theme, message, guidance, areas), error handling, input format requirements, and even notes the numerological tradition. Annotations already indicate readOnly, idempotent, non-destructive, and description aligns and complements.

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

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

Description is well-structured into labeled sections and front-loaded with purpose. Some sections (e.g., COMPUTE CLASS, WORKFLOW) are minimally useful, adding slight verbosity, but overall efficient for the information content.

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

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

Tool has 2 parameters, rich output schema, and annotations; description covers everything needed: supported numbers, output structure, error contracts, and disambiguation. Agent can fully understand when and how to invoke.

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

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

Schema has 0% description coverage, so description compensates fully: explains 'number' parameter with examples and case-sensitivity, and explains 'response_format' enum values with clarity on output differences.

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

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

Description clearly states the tool looks up meaning of a specific angel number by sequence, lists supported numbers (e.g., 111, 444), and distinguishes from sibling tools in a dedicated section.

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

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

Description includes a 'DO NOT CONFUSE WITH' section that explicitly contrasts three sibling tools, explaining when to use each. Workflow sections indicate standalone operation, but lacks explicit 'when not to use' guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds useful behavioral context: it is a FAST_LOOKUP (pure digit math, no ephemeris), provides error contracts (INVALID_PARAMS, INTERNAL_ERROR), and details output fields. No contradictions with annotations.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, OUTPUT CONTRACT, etc.). It is somewhat lengthy but each section serves a purpose. Could be slightly more concise, but it is well-organized.

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

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

Given the tool's complexity, the description covers all necessary aspects: purpose, workflow, input/output contracts with field details, error handling, compute class, and differentiation from siblings. The output schema is described in detail, so no gaps remain.

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

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

Schema coverage is 0%, so the description carries the full burden. It explains the 'date' parameter format with an example, the optional 'name' for personalization, and the 'response_format' enum with descriptions of both options. This adds substantial meaning beyond the schema.

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

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

The description clearly states the tool computes a personal angel number from a birth date using Pythagorean Life Path. It identifies the specific resource (birth date) and method (digit-fusing Life Path), and explicitly distinguishes from sibling tools like asterwise_get_angel_number_today and asterwise_get_numerology_profile.

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

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

The description provides explicit guidance: it recommends calling asterwise_get_numerology_profile before, and includes a 'DO NOT CONFUSE WITH' section listing alternative tools with clear differentiation. This helps the agent decide when to use this tool versus siblings.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds value by detailing the pure math computation, FAAP_LOOKUP compute class, and that no external data is needed, which goes beyond the annotations.

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

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

The description is well-structured with clear sections and front-loaded with purpose. However, it is somewhat lengthy with sections like 'COMPUTE CLASS' and 'ERROR CONTRACT', which are useful but could be more concise.

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

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

The description covers all necessary aspects: input contract (no parameters required beyond response_format), output contract with field names and types, error contract, workflow, and compute class. It is fully self-contained and complete.

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

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

The only parameter (response_format) has an enum, and the description explains the difference between markdown and json, including that both return identical data and json is indented. Since schema coverage is 0%, the description fully compensates.

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

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

The description clearly states the tool returns today's angel number computed from the current date, explains the computation method, and distinguishes from siblings asterwise_get_angel_number and asterwise_get_angel_number_personal.

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

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

The description includes a 'DO NOT CONFUSE WITH' section explicitly naming alternatives and their differences, plus a workflow section stating it is standalone and suggesting asterwise_get_angel_number_personal for a personalized query.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable context beyond annotations: it discloses computational complexity (MEDIUM_COMPUTE), explains that Rahu/Ketu are not classical contributors per tradition, and provides threshold lore (28+ bindus supports transits, below 25 implies friction). No contradictions with annotations.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.), but could be more concise. Some sections like OUTPUT CONTRACT and RESPONSE FORMAT contain detailed technical specifications that might be better in schema documentation. However, the information is well-organized and front-loaded with core purpose.

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

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

Given the tool's complexity, rich annotations, and detailed output schema (implied by OUTPUT CONTRACT section), the description provides excellent contextual completeness. It covers purpose, workflow, input/output contracts, compute class, error handling, edge cases, and sibling tool differentiation. The output schema existence means the description doesn't need to explain return values in detail.

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

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

Schema description coverage is 50% (birth parameter has detailed descriptions, response_format lacks description). The description adds minimal parameter semantics beyond schema - it states 'BirthData only' and mentions response_format options but doesn't explain parameter meanings or usage. With moderate schema coverage, baseline 3 is appropriate as the description doesn't significantly compensate for gaps.

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

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

The description clearly states the tool computes Ashtakavarga bindu matrices, trikona and ekadhipatya reductions, and sarva totals from BirthData for transit support analysis. It specifies the exact astrological calculations performed and distinguishes from siblings like asterwise_get_chart_strength and asterwise_get_gochar by explaining what each sibling focuses on.

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

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

The description provides explicit workflow guidance: BEFORE recommends asterwise_get_natal_chart to confirm chart, AFTER mentions asterwise_get_gochar uses AVK scores. It also clearly distinguishes when NOT to use this tool versus asterwise_get_chart_strength and asterwise_get_gochar in the 'DO NOT CONFUSE WITH' section.

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

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

The description adds valuable behavioral context beyond what annotations provide. While annotations indicate read-only, open-world, idempotent, and non-destructive operations, the description adds that 'this tool always returns a full timeline with no niyama_met flag,' mentions 'MEDIUM_COMPUTE' timing, and details error contracts including 'INVALID_PARAMS' for levels out of range and 'INTERNAL_ERROR' for upstream failures. No contradictions with annotations exist.

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

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

The description is structured with clear sections but is verbose with repetitive details. Sentences like 'Dates in periods are DD/MM/YYYY' and similar formatting notes appear multiple times. While well-organized, it could be more concise by eliminating redundancy while maintaining clarity.

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

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

Given the tool's complexity, rich annotations, and detailed output schema, the description is highly complete. It covers purpose, usage guidelines, behavioral traits, input/output contracts, error handling, and sibling distinctions. The output schema exists, so the description appropriately focuses on contextual rather than structural details.

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

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

With schema description coverage at 33%, the description adds some parameter context but doesn't fully compensate. It explains that 'levels' has 'same semantics as asterwise_get_dasha (1-5)' and that 'Periods use data.periods.root[], not data.periods[]', but doesn't elaborate on 'birth' or 'response_format' parameters beyond what the schema provides. The baseline is appropriate given partial coverage.

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

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

The description clearly states the tool 'Computes the 108-year Ashtottari Dasha tree' with specific details about configurable depth (levels 1-5) and output structure. It explicitly distinguishes this from sibling tools like 'asterwise_get_dasha' (Vimshottari), 'asterwise_get_yogini_dasha', and 'asterwise_get_char_dasha' by stating 'It is not Vimshottari, Yogini, or Char Dasha.'

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

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

The description provides explicit guidance on when to use this tool versus alternatives. It states 'Classical texts restrict use when Rahu is in Kendra/Trikona from Lagna lord (not in Lagna)' and recommends 'apply rules externally.' It also includes a 'BEFORE' section recommending 'asterwise_get_natal_chart' for context and an 'AFTER' section suggesting 'asterwise_get_dasha' for comparison.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds context: compute class (FAST_LOOKUP), error contract (INTERNAL_ERROR), and output format details. No contradictions with annotations.

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

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

The description is well-structured with clear sections, front-loads the purpose, and avoids unnecessary repetition. It is slightly verbose but each section adds relevant information.

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

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

The description covers purpose, usage, output structure (including DMS format), error handling, and will not confuse with similar tools. The missing parameter semantics for 'response_format' is a minor gap, but overall the tool is well-documented.

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

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

Schema description coverage is 0%, meaning the description adds little to parameter understanding. It only mentions the 'date' parameter with format and default, but omits 'response_format' entirely. The schema has an enum for 'response_format' but the description does not explain it.

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

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

The first sentence clearly states the tool returns ayanamsha values for four specific systems for a given date. The 'DO NOT CONFUSE WITH' section explicitly differentiates it from sibling tools that apply ayanamsha automatically, making purpose distinct.

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

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

The description provides a 'DO NOT CONFUSE WITH' section naming two specific sibling alternatives and explaining their difference. The 'WORKFLOW' section states it is a standalone reference with no before/after steps, clarifying when to use it.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool 'indicates how a person handles stress and unresolved issues,' which is a minor interpretive context but does not significantly expand on behavioral traits beyond the annotations.

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

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

The description is concise with two sentences plus a short output contract note. It avoids unnecessary details and is front-loaded with the core purpose, though the output contract section could be integrated more smoothly.

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

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

For a simple tool with two parameters and an output schema (implied by 'OUTPUT CONTRACT'), the description covers the basic purpose and output fields but lacks parameter details, usage context, and error scenarios. It is minimally complete.

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

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

Schema description coverage is 0%, meaning the schema has no parameter descriptions. The tool description does not add any meaning about the 'name' parameter (e.g., full name format, which parts) or 'response_format' beyond the enum values in the schema, failing to compensate for the lack of schema details.

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

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

The description clearly states the tool calculates the Balance number from the first letter of each name part, indicating how a person handles stress and unresolved issues. This specific verb and resource distinguishes it from numerous sibling tools that calculate other numerology numbers.

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

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

The description does not provide guidance on when to use this tool versus alternatives like other numerology tools. No explicit context or exclusions are mentioned, leaving the agent to infer usage based on the function's name alone.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds extensive behavioral context: formula, critical day explanation, output structure (single and multi-day), error contracts, and compute class. No contradictions with annotations.

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

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

The description is well-structured with clear sections and headings, making it easy to parse. However, it is relatively verbose; some redundancy exists (e.g., repeating cycle details in multiple sections). Still, every section adds value.

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

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

Given the tool's complexity (multiple cycles, date ranges, output structure, error handling, sibling differentiation), the description is remarkably complete. It covers all essential aspects despite the output schema existing, and even includes compute class and error contracts.

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

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

Schema description coverage is 0%, so the description must fully explain parameters. It covers birth_date (format), target_date (default), and days (range/default) in the 'INPUT CONTRACT' section. However, the response_format parameter (enum: markdown/json) is not mentioned in the description, leaving a gap in parameter understanding.

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

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

The description clearly states it computes three biorhythm cycles (physical, emotional, intellectual) for a birth date. It uses specific verbs and resources, and includes a 'DO NOT CONFUSE WITH' section that explicitly distinguishes it from sibling tools like asterwise_get_nakshatra_prediction and asterwise_get_panchanga.

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

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

Provides explicit BEFORE/AFTER workflow guidance and a dedicated 'DO NOT CONFUSE WITH' section naming two sibling tools with their purposes. This makes it clear when to use this tool versus alternatives, such as for Western biorhythm vs. Vedic Tarabala.

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

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

The description adds valuable behavioral context beyond what annotations provide. While annotations indicate read-only, open-world, idempotent, and non-destructive operations, the description details computational characteristics (FAST_LOOKUP class), input handling (strips non-letters per upstream rules, accepts special characters/digits), error contracts (upstream validation, INTERNAL_ERROR for API failures), and edge cases (emojis/digits flow through stripping). It doesn't contradict the annotations, which already cover safety aspects.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.), making it easy to navigate. While comprehensive, it could be slightly more concise—some sections like OUTPUT CONTRACT list all fields in detail, which might be redundant given the output schema exists. However, every section adds value, and the information is front-loaded with the core purpose first.

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

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

Given the tool's complexity (numerology analysis with multiple outputs) and the presence of annotations and an output schema, the description is exceptionally complete. It covers purpose, usage guidelines, behavioral details, parameter semantics, output structure, error handling, and sibling differentiation. The output schema likely documents return values, so the description appropriately focuses on explaining the analysis logic and context rather than repeating schema information.

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

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

With 0% schema description coverage, the description fully compensates by explaining all three parameters' semantics. It clarifies that 'business_name' accepts numerals/punctuation with non-letters stripped, 'date' is a founder birth date, and 'response_format' controls output presentation (json for programmatic parsing, markdown for human-readable reports). The OUTPUT CONTRACT section further details what each parameter influences in the results.

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

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

The description clearly states the tool's purpose: 'Reduces a business name to Expression and root digits against a founder birth date and returns thematic suitability lists plus a harmony score.' It specifies the exact operation (reduction against a date), distinguishes it from sibling tools (asterwise_get_name_correction for personal spelling, asterwise_check_mobile_number for numeric analysis), and identifies the specific resource (business name).

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

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

The description provides explicit guidance on when to use this tool versus alternatives. The 'DO NOT CONFUSE WITH' section names specific sibling tools and explains their different purposes (personal spelling vs. corporate Expression scoring, numeric line analysis vs. brand letters). It also includes workflow sections indicating this is standalone and when to use asterwise_get_name_correction afterward for personal entities.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable behavioral context: it specifies the compute class (MEDIUM_COMPUTE), explains that validation is upstream with no local validation, details error handling (INVALID_PARAMS, INTERNAL_ERROR), and warns about edge cases (Chaldean/Pythagorean disagreement). This goes significantly 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.

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, etc.), but it's quite lengthy with some redundancy (e.g., OUTPUT CONTRACT and RESPONSE FORMAT overlap). While informative, it could be more concise by combining related sections or trimming repetitive details.

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

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

Given the tool's complexity (numerology calculation with multiple outputs) and rich annotations/output schema, the description is exceptionally complete. It covers purpose, differentiation, workflow, input/output contracts, response formats, compute class, error handling, and edge cases. With an output schema present, it appropriately focuses on behavioral aspects rather than re-describing return values.

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

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

With 0% schema description coverage, the description must compensate. It explains that 'name and date forwarded as-is; no local validation' and details the 'response_format' parameter's effect (json vs markdown output modes). While it doesn't specify exact formats for name/date, it provides meaningful context about parameter handling that the schema lacks.

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

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

The description clearly states the tool 'reduces a name and birth date through the Chaldean letter-value system' and 'returns name, birth, and combined compound analyses with themes and keywords.' It specifically distinguishes from sibling tools like 'asterwise_get_numerology_profile' (Pythagorean) and 'asterwise_get_lo_shu_grid' (digit placement), 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.

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

The 'DO NOT CONFUSE WITH' section explicitly names alternatives (asterwise_get_numerology_profile, asterwise_get_lo_shu_grid) and clarifies when not to use this tool. The 'WORKFLOW' section provides before/after context, stating it's standalone and can be followed by asterwise_get_numerology_profile for comparison.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable context beyond this: it specifies compute class (MEDIUM_COMPUTE), error contracts (INVALID_PARAMS, INTERNAL_ERROR), edge cases (tie-break rules), and output format options (json vs markdown), enhancing behavioral understanding without contradicting annotations.

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

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

The description is well-structured with clear sections (e.g., WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT), making it easy to navigate. While comprehensive, some sections (like OUTPUT CONTRACT listing all fields) are detailed but necessary for clarity, keeping it front-loaded and efficient without wasted sentences.

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

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

Given the tool's complexity (astrological calculations with nested outputs), the description is highly complete. It covers purpose, usage guidelines, behavioral details (compute class, errors), input/output contracts, and sibling distinctions. With annotations providing safety info and an output schema implied by the OUTPUT CONTRACT section, no significant gaps remain for effective agent use.

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

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

Schema description coverage is 50%, with detailed descriptions for birth parameters but none for response_format. The description compensates by explaining the response_format parameter's effect in the 'RESPONSE FORMAT' section, clarifying that it controls serialization without altering data. However, it doesn't add semantics for birth parameters beyond the schema, keeping the score from reaching 5.

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

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

The description starts with a specific verb ('Computes') and resource ('Jaimini Char Dasha from birth data'), clearly stating what the tool does. It explicitly distinguishes from siblings like asterwise_get_dasha (Vimshottari) and asterwise_get_yogini_dasha, making the purpose distinct and well-defined.

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

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

The description includes explicit guidance on when to use this tool vs alternatives in the 'DO NOT CONFUSE WITH' section, naming specific sibling tools and their differences. It also provides workflow recommendations ('BEFORE' and 'AFTER' sections) and clarifies input/output contracts, offering comprehensive usage context.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, etc., but the description adds valuable context: it discloses compute class ('MEDIUM_COMPUTE (~800ms)'), error handling details (INVALID_PARAMS vs INTERNAL_ERROR), and edge cases ('Large payload due to embedded vargas and Ashtakavarga duplicates'). This goes beyond annotations without contradicting them.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, etc.), making it easy to scan. Every sentence adds value—no redundant information. It's appropriately sized for a complex tool, with front-loaded purpose and detailed sections for depth.

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

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

Given the tool's complexity, rich output schema (detailed in description), and annotations, the description is highly complete. It covers purpose, usage, behavior, output structure, errors, and sibling distinctions. The output schema is fully described in the description, so no additional return value explanation is needed.

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

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

Schema description coverage is 50%, but the description adds minimal parameter semantics beyond the schema. It states 'BirthData only; no extra toggles' and mentions the response_format parameter's effect on output serialization. However, it doesn't explain the birth parameter's components or provide additional context for the two parameters, so it only partially compensates for the schema coverage gap.

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

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

The description explicitly states the tool 'aggregates' multiple strength metrics from BirthData, listing specific components like Shadbala, Bhavbala, Vimshopaka, etc. It clearly distinguishes from siblings by specifying what it does NOT cover (yogas or doshas), making the purpose specific and differentiated.

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

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

The description includes explicit workflow guidance: 'BEFORE: RECOMMENDED — asterwise_get_natal_chart' and 'AFTER: asterwise_get_yogas — optional configuration pass after strength review.' It also clearly distinguishes from alternatives like asterwise_get_yogas and asterwise_get_ashtakavarga, providing 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.

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

The description adds valuable behavioral context beyond the annotations. While annotations indicate read-only, open-world, idempotent, and non-destructive operations, the description adds that boundaries follow actual sunrise/sunset with DST implicit, slots track sunrise/sunset not fixed civil slices, and it's classified as FAST_LOOKUP. It also details error contracts (INVALID_PARAMS, INTERNAL_ERROR) and edge cases, providing comprehensive behavioral transparency.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.), making it easy to navigate. While comprehensive, some sections like OUTPUT CONTRACT and RESPONSE FORMAT are detailed but necessary for clarity. It avoids redundancy and is front-loaded with the core purpose, though it could be slightly more concise in the output details given the presence of an output schema.

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

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

Given the tool's complexity, rich annotations, and output schema, the description is highly complete. It covers purpose, usage guidelines, behavioral traits, input/output contracts, error handling, and sibling distinctions. The output schema exists, so the description doesn't need to explain return values in detail, but it still provides useful context on data structure and response formats, ensuring the agent has all necessary information.

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

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

With 100% schema description coverage, the baseline is 3. The description mentions that LocationInput enforces YYYY-MM-DD date and lat/lon ranges locally, and all parameters are defined in the tool schema. It adds minimal semantic context beyond the schema, such as noting DST is implicit due to timezone handling, but doesn't elaborate on parameter usage or constraints beyond what's already documented in the schema.

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

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

The description clearly states the tool's purpose: it splits a solar day into sixteen Choghadiya segments from sunrise/sunset at a location and labels each slot's quality, ruler, and local clock bounds. It specifically distinguishes this tool from sibling tools like asterwise_get_muhurta (multi-day windows for named activities) and asterwise_get_panchanga (full Panchanga limbs), providing clear differentiation.

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

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

The description provides explicit guidance on when to use this tool versus alternatives. It states that this tool is standalone (no prerequisites) and mentions asterwise_get_rahu_kaal as an optional follow-up. It also clearly distinguishes it from asterwise_get_hora (planetary horas) and asterwise_get_muhurta (scored windows for activities), giving clear alternatives and exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable context beyond this: it specifies the compute class (MEDIUM_COMPUTE), explains that unknown midnight time is accepted, describes the two output formats (json/markdown), and details error handling including edge cases about vetoes. No contradiction with annotations exists.

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

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

The description is well-structured with clear sections but is quite lengthy. While each section serves a purpose, some redundancy exists (e.g., output details appear in both 'OUTPUT CONTRACT' and 'RESPONSE FORMAT'). The front-loaded purpose statement is excellent, but subsequent sections could be more concise while maintaining clarity.

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

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

Given the tool's complexity (astrological compatibility scoring with multiple components), rich output schema, and comprehensive annotations, the description provides exceptional completeness. It covers purpose, differentiation, workflow, input/output contracts, response formats, compute class, error handling, and specific warnings. With an output schema present, it appropriately doesn't need to explain return values in detail.

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

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

With 67% schema description coverage (2 of 3 parameters well-documented in schema), the description adds meaningful context. The 'INPUT CONTRACT' section explains that two BirthData objects follow a global contract and that unknown midnight time is accepted. While it doesn't detail individual parameter semantics beyond what the schema provides, it clarifies the overall input structure and constraints.

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

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

The description immediately states the specific verb ('Scores') and resource ('North Indian Ashtakoota (36-point Guna Milan) for two charts') with clear output details. It explicitly distinguishes from three named sibling tools (asterwise_get_dashakoot, asterwise_get_porutham, asterwise_get_thirumana_porutham) in the 'WHAT THIS TOOL COVERS' section, providing precise differentiation.

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

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

The 'WORKFLOW' section provides explicit before/after recommendations (asterwise_get_natal_chart before, asterwise_get_papasamyam after). The 'DO NOT CONFUSE WITH' section names three specific alternatives with explanations of why they're different. The 'Edge cases' note warns about vetoes invalidating high scores.

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

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

Annotations declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive. The description adds critical behavioral details: the caution field carries safety warnings for specific crystals, and the error contract documents 404 for unknown names, which goes 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.

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

The description is well-structured with clear sections and front-loaded purpose. While it is somewhat lengthy, all content is relevant and aids understanding. Minor deduction for including seemingly extraneous metadata like 'COMPUTE CLASS: FAST_LOOKUP'.

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

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

Given the tool's simplicity (2 params) and rich annotations, the description covers everything: input contract, output contract, error contract, workflow, and differentiation from siblings. It is fully sufficient for correct invocation.

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

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

Input schema has 0% description coverage, but the description fully explains both parameters: 'name' with slug/display name examples and 'response_format' with markdown/json options. This compensates completely for the lack of schema descriptions.

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

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

The description clearly states the tool looks up a specific crystal by slug or name, returning full details including planetary assignments, healing properties, and cautions. It explicitly distinguishes from sibling tools like asterwise_get_crystals and asterwise_get_crystal_by_planet.

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

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

The description provides a 'DO NOT CONFUSE WITH' section listing alternatives, a workflow section stating it can be standalone or after gemstone recommendations, and explicit before/after context.

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

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

Annotations already declare readOnlyHint, idempotentHint true. The description adds details on sorting, filtering criteria, exclusion of none_classical crystals, error contracts, compute class (FAST_LOOKUP), and response format behavior. No contradiction with annotations.

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

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

Well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, etc.), front-loaded with core purpose. Slightly verbose but each section adds value. No superfluous content.

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

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

Covers all aspects: input constraints, output shape (data.total, data.crystals), sorting order, error handling, workflow integration, and differentiation from siblings. Output schema exists so return format details are adequate.

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

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

Schema description coverage is 0%, but the 'INPUT CONTRACT' section fully explains the planet parameter (valid values) and response_format (effects on output). This compensates completely for the missing schema descriptions.

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

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

The description clearly states it returns crystals associated with a specific Vedic planet, with explicit sorting and filtering. It distinguishes itself from siblings like asterwise_get_crystals and asterwise_get_gemstone_recommendations.

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

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

Provides explicit usage context ('Useful for Jyotish practitioners'), workflow recommendations (before/after tools), and a dedicated 'DO NOT CONFUSE WITH' section naming alternative tools and their purposes.

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

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

Adds scoring logic, limit defaults, exact valid values, partial match behavior, error contracts, and compute class. All annotations (readOnlyHint, etc.) are consistent and description enriches beyond them.

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

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

Well-organized into sections; all content is useful but slightly lengthy. However, each sentence earns its place given the complexity.

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

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

Covers purpose, filters, scoring, output format, errors, workflow, and differentiation. No missing information for agent to use correctly.

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

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

Despite 0% schema description coverage, the description fully explains each parameter with values, constraints, and inter-dependencies (e.g., at least one filter required).

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

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

Clearly states 'Recommends crystals based on zodiac sign, chakra, or intention keyword.' and explicitly distinguishes from siblings like asterwise_get_crystal_by_planet and asterwise_get_gemstone_recommendations.

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

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

States requirement of at least one filter, provides workflow with before/after tools, and includes 'DO NOT CONFUSE WITH' section that explicitly tells when to use alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds extensive behavioral context: classical inclusion/exclusion rules, scoring, dangerous combinations, output contract details, error contract with edge cases (e.g., empty crystals[], critical cautions for Blue Sapphire and Hessonite), and compute class. No contradiction with annotations.

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

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

The description is well-structured with clear sections and headings, but is very lengthy and includes detailed classical rules (e.g., inclusion/exclusion, scoring) that may be more than necessary for tool selection. While thorough, it is not concise, as many sentences could be trimmed without losing essential guidance.

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

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

Given the complexity of Vedic astrology, the description is exceptionally complete. It covers input contract, output contract (including all fields), error contract with edge cases, workflow before/after, and differentiation from siblings. The output schema is present, so return values are covered. All critical aspects for correct usage are addressed.

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

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

The description adds meaning beyond the input schema: it states 'Standard BirthData (date, time, lat, lon, timezone, ayanamsa). Defaults to Lahiri ayanamsa' and emphasizes that 'time (required): Ascendant (Lagna) is time-sensitive'. It also explains response_format options. Although schema descriptions cover 50%, the description compensates with context about time sensitivity and defaults.

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

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

The description clearly states it recommends crystals from a Vedic natal chart using classical Ratna Shastra rules per BPHS and Mani Mala. It explicitly distinguishes itself from siblings: 'not from zodiac sign or chakra preference' and includes a 'DO NOT CONFUSE WITH' section that names alternative tools and their differences.

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

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

The description provides a dedicated 'WORKFLOW' section explaining BEFORE and AFTER steps, and a 'DO NOT CONFUSE WITH' section that explicitly tells when to use this tool vs alternatives (e.g., asterwise_get_gemstone_recommendations returns gem names not crystal database entries). It also includes guidance on when not to use (e.g., inaccurate birth time changes results).

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

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

Description exceeds annotation coverage with details like 'FAST_LOOKUP — static database, no ephemeris', 'INTERNAL_ERROR' error contract, and explicit output contract. Annotations already provide readOnlyHint/idempotentHint/destructiveHint, and the description adds meaningful behavioral context without contradiction.

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

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

While the description is lengthy, it is well-structured with clear section headers (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, OUTPUT CONTRACT, etc.). Some redundancy exists (e.g., repeating the 50-crystal count multiple times), but every section adds unique value.

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

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

Given the presence of an output schema, the description remains complete by covering input, output, error handling, compute class, and sibling differentiation. It does not rely on the output schema to explain return values but still provides comprehensive context for accurate tool selection and usage.

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

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

The sole parameter 'response_format' is fully explained: 'response_format=json — full 50-crystal array. response_format=markdown — formatted catalogue. Both return identical data.' This adds semantic meaning beyond the schema's enum listing, compensating for the 0% schema description coverage.

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

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

Description clearly states it returns all 50 crystals sorted alphabetically with detailed fields. Explicitly distinguishes from sibling tools like asterwise_get_crystal, asterwise_get_crystal_by_planet, and asterwise_get_crystal_recommendations 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.

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

Provides explicit workflow guidance with BEFORE (none) and AFTER (asterwise_get_crystal_by_planet) sections. Includes a dedicated 'DO NOT CONFUSE WITH' section listing alternatives and their purposes, making it clear 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.

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

The description adds significant behavioral context beyond what annotations provide. While annotations indicate readOnly, non-destructive, idempotent operations, the description adds: compute class ('MEDIUM_COMPUTE (~100ms at levels=1, ~1500ms at levels=5)'), error contract details, date format specifics ('DD/MM/YYYY, not ISO'), and edge case handling. It doesn't contradict annotations and provides rich operational context.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.) that make information easy to locate. Every sentence serves a specific purpose—no wasted words. The information is front-loaded with the core purpose, followed by detailed sections for those needing deeper understanding.

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

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

Given the tool's complexity (astrological calculations with hierarchical outputs), the description provides comprehensive context. It covers purpose, workflow integration, input semantics, output structure (though an output schema exists), performance characteristics, error handling, and differentiation from similar tools. The combination of detailed description and existing output schema makes this complete for agent understanding.

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

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

With only 33% schema description coverage, the description compensates substantially. It explains the 'levels' parameter in detail (depth meaning, default, max, payload implications), clarifies BirthData field semantics (date/time formats, '00:00' handling, lagna-sensitive timing implications), and explains the 'response_format' parameter's effect on output presentation. This adds crucial meaning beyond the minimal schema descriptions.

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

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

The description explicitly states 'Computes Vimshottari Dasha from birth data and returns hierarchical period trees plus current Maha/Antar interpretation blocks.' This provides a specific verb ('computes'), resource ('Vimshottari Dasha'), and output details. It clearly distinguishes from sibling tools like asterwise_get_char_dasha, asterwise_get_yogini_dasha, and asterwise_get_ashtottari_dasha by specifying what it does NOT compute.

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

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

The description includes explicit workflow guidance: 'BEFORE: RECOMMENDED — asterwise_get_natal_chart — establishes chart and Moon context before interpreting Dasha lords' and 'AFTER: asterwise_get_dasha_transits — correlates active Dasha lords with transits for the same birth data.' It also clearly states when NOT to use this tool in the 'WHAT THIS TOOL COVERS' section, naming specific alternative tools for other Dasha systems.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable context beyond annotations: it specifies the 'COMPUTE CLASS' as 'MEDIUM_COMPUTE' (indicating resource intensity), details error contracts (INVALID_PARAMS, INTERNAL_ERROR), and advises to 'Read rajju/vedha supplementary objects before trusting the headline score' for edge cases. No contradiction with annotations.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, OUTPUT CONTRACT, etc.), making it easy to scan. It is appropriately sized for a complex tool, though some sections (like OUTPUT CONTRACT) are detailed but necessary. Every sentence adds value, with no redundant information.

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

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

Given the tool's complexity (computational astrology matching), rich output schema detailed in 'OUTPUT CONTRACT', and annotations covering safety, the description is highly complete. It explains regional style, scoring methodology, workflow recommendations, error handling, compute class, and distinctions from siblings. The output schema eliminates need to describe return values in the description, and the description adds all necessary contextual information.

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

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

Schema description coverage is 67%, with detailed descriptions for person1/person2 fields (lat, lon, date, time, ayanamsa, timezone, person_name) but no description for response_format. The description compensates by explaining in 'RESPONSE FORMAT' that 'response_format=json serialises... response_format=markdown renders...', adding semantic meaning not in the schema. However, it doesn't fully document all parameters beyond what the schema provides.

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

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

The description clearly states the tool computes a 'ten-koota Dashakoot grid for two charts' and converts it to a 'ten-point score with percentage', distinguishing it from sibling tools like 'asterwise_get_compatibility' (North Indian 36-point) and 'asterwise_get_porutham' (Tamil pass grid). It specifies the regional style (South Indian Kannada/Telugu) and scoring method (0.0 or 1.0 per koota).

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

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

The description provides explicit guidance in the 'WORKFLOW' section: 'BEFORE: RECOMMENDED — asterwise_get_natal_chart for each native' and 'AFTER: asterwise_get_papasamyam — optional malefic differential.' It also includes a 'DO NOT CONFUSE WITH' section naming specific sibling tools and explaining their differences, giving clear alternatives and exclusions.

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

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

The description adds valuable behavioral context beyond the annotations. While annotations indicate read-only, open-world, idempotent, and non-destructive operations, the description clarifies that the tool uses a fixed 'today' date (no date parameter), mentions compute class (MEDIUM_COMPUTE), and details error handling (INVALID_PARAMS, INTERNAL_ERROR). It also explains the response format options (json vs markdown) and edge cases like past/future analysis not being supported. No contradictions with annotations exist.

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

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

The description is well-structured with clear sections (e.g., WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT), making it easy to scan. Each sentence adds value without redundancy. It efficiently covers purpose, usage, parameters, output, format, compute class, errors, and sibling distinctions in a compact yet comprehensive manner.

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

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

Given the tool's complexity (astrological calculations with multiple outputs), rich annotations, and detailed output schema, the description is highly complete. It explains the tool's scope, workflow, input constraints (fixed date), output structure (with examples), response formats, compute class, error handling, and explicit sibling distinctions. The output schema is detailed, so the description doesn't need to re-explain return values, focusing instead on contextual guidance.

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

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

With schema description coverage at 50% (only 'birth' object has descriptions, 'response_format' lacks one), the description compensates well. The 'INPUT CONTRACT' section clarifies that 'today' is fixed by the API and all parameters are defined in the schema, and it provides context for BirthData (e.g., 'unknown birth time: time='00:00' accepted without detection'). While it doesn't detail individual parameters beyond the schema, it adds meaningful usage context that aids understanding.

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

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

The description clearly states the tool's purpose: 'Combines active Vimshottari lords with today's transits and returns scored correlations plus transit longitudes and houses from Moon and Lagna.' It specifies the exact verb ('combines'), resources ('active Vimshottari lords', 'today's transits'), and output ('scored correlations', 'transit longitudes and houses'). It explicitly distinguishes from siblings like asterwise_get_dasha, asterwise_get_transits, and asterwise_get_gochar 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.

Does 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. The 'WHAT THIS TOOL COVERS' section states what it does and what it doesn't do (e.g., 'no date parameter', 'does not return full Dasha trees'). The 'WORKFLOW' section recommends using asterwise_get_natal_chart before this tool and asterwise_get_gochar after. The 'DO NOT CONFUSE WITH' section explicitly names alternative tools and their different purposes.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable behavioral context beyond annotations: it explains that D30 omits Sun and Moon per convention, mentions that wrong ayanamsa may be rejected upstream, clarifies that all sixteen charts appear even when only one chart_type is requested, and provides error contract details. No contradiction with annotations.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.) and every sentence adds value. It's appropriately sized for a complex tool with many behavioral nuances, with no redundant or wasted content.

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

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

Given the tool's complexity (computes 16 charts), rich annotations, and presence of an output schema, the description provides excellent completeness. It covers purpose, workflow, input/output contracts, error handling, sibling differentiation, and behavioral nuances. The output schema exists, so the description appropriately focuses on explaining the structure and usage rather than repeating return value details.

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

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

With only 33% schema description coverage (birth parameter has rich descriptions but chart_type and response_format lack descriptions), the description compensates well. It explains chart_type 'selects the analytical focus' and that response_format offers json for programmatic parsing or markdown for human-readable reports. While it doesn't detail every parameter, it adds meaningful context beyond the sparse schema.

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

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

The description clearly states the tool 'computes all sixteen divisional charts from BirthData' with specific output details (D1-D60 blocks keyed by planet). It explicitly distinguishes from siblings like asterwise_get_natal_chart (radix chart only) and asterwise_get_chart_strength (strength metrics), providing clear differentiation.

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

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

The description provides explicit workflow guidance: 'BEFORE: RECOMMENDED — asterwise_get_natal_chart — anchor D1 before reading higher vargas' and 'AFTER: None.' It also includes a 'DO NOT CONFUSE WITH' section naming specific alternatives with their purposes, 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.

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

Annotations provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond this: it specifies the tool covers 'MEDIUM_COMPUTE' class, details error contracts (e.g., date range limits, cancellation arrays), and explains that 'Unknown birth time at midnight is accepted silently.' This enriches behavioral understanding without contradicting annotations.

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

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

The description is well-structured with clear sections (e.g., WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT), each containing focused, necessary information. Every sentence serves a purpose, such as clarifying scope, guiding usage, or detailing output, with no redundant or verbose content, making it highly efficient and front-loaded.

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

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

Given the tool's complexity, rich annotations, and the presence of an output schema, the description is highly complete. It covers purpose, usage guidelines, behavioral details (compute class, errors), input/output contracts, and distinctions from siblings. The output schema existence means the description doesn't need to explain return values in depth, and it effectively supplements structured data with necessary context.

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

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

Schema description coverage is 50%, with detailed descriptions for birth parameters but none for response_format. The description adds minimal parameter semantics beyond the schema: it mentions 'BirthData follows the global contract' and that response_format affects output serialization. However, it doesn't fully compensate for the lack of schema description for response_format, keeping it at baseline level given partial schema coverage.

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

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

The description explicitly states the tool 'Scores twelve fixed dosha buckets from birth data and returns presence flags, typed detail objects, optional summaries, and remedy lines per dosha.' It lists all twelve specific dosha names and clearly distinguishes this tool from sibling tools like asterwise_get_compatibility and asterwise_get_chart_strength, making the purpose highly specific and differentiated.

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

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

The description includes explicit 'SECTION: WORKFLOW' with 'BEFORE' and 'AFTER' recommendations (asterwise_get_natal_chart and asterwise_get_remedies), and 'SECTION: DO NOT CONFUSE WITH' that names specific sibling tools and explains when not to use this tool (e.g., for compatibility or Shadbala metrics). This provides clear, actionable 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.

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds extensive behavioral context: error contract (INVALID_PARAMS leads to 404, MCP INTERNAL_ERROR), compute class FAST_LOOKUP, output format details, and that it returns full dual-tradition interpretation. No contradiction with annotations.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, etc.). It is front-loaded with the core purpose. Some sections like WORKFLOW are minimal but not wasteful. A bit verbose but still efficient.

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

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

Given the complexity (dual-tradition, error handling, output shape), the description covers all necessary aspects: input contract, output contract, response format, workflow, error contract, and differentiation. Output schema exists, so return values need not be detailed. Complete.

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

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

Schema coverage is 0%, so the description fully compensates. It explains 'name' as symbol slug or display name with examples, and describes 'response_format' enumeration and its implications in the 'RESPONSE FORMAT' section. Adds meaning beyond schema.

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

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

The description clearly states the tool does a lookup of a specific dream symbol by slug or name, returning full dual-tradition interpretation. It distinguishes from sibling 'asterwise_get_dream_symbols' which lists all symbols.

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

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

The description includes a 'DO NOT CONFUSE WITH' section explicitly naming the alternative tool, and a 'WHAT THIS TOOL COVERS' section listing use cases. However, it does not explicitly state when to avoid using this tool beyond the sibling differentiation.

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

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

The description adds significant behavioral context beyond the annotations: it reveals that the tool performs a FAST_LOOKUP on a static database, details error contracts (INVALID_PARAMS, INTERNAL_ERROR), and explains the response format options (JSON vs markdown). No contradiction with annotations.

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

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

The description is well-structured with sections and front-loaded with purpose. While thorough and clear, it is slightly longer than necessary; however, every sentence adds value, and the structure aids readability. The slight verbosity prevents a perfect score.

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

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

The description covers all aspects: purpose, parameters, output contract with field details, error contracts, workflow, response format, and distinction from sibling. Given the presence of an output schema and the tool's complexity, the description is fully complete.

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

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

Despite 0% schema description coverage, the description fully explains both parameters: the category parameter lists all valid values (animals, nature, people, places, objects, actions, body, abstract) and notes it is optional, and the response_format parameter is described as choosing between JSON and markdown.

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

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

The description clearly states it returns dream symbols with dual-tradition interpretation, specifies 500 symbols across 8 categories, and distinguishes from the sibling tool asterwise_get_dream_symbol for single symbol details. The verb is specific and resource clearly defined.

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

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

The description includes a 'WORKFLOW' section stating it is standalone and recommends using asterwise_get_dream_symbol afterward for detail, and a 'DO NOT CONFUSE WITH' section explicitly differentiating from the sibling. It also explains optional filtering by category, providing 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.

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

Annotations show readOnlyHint and idempotentHint. Description adds method details, master number handling, and output contract, enhancing transparency 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.

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

Structured with sections (OUTPUT CONTRACT, DO NOT CONFUSE WITH), but could be more concise. Each section adds value without redundancy.

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

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

Given output schema, description provides output contract. Covers method and master numbers. Adequate for a focused calculation tool; no missing critical context.

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

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

Schema coverage is 0%, requiring description to explain parameters. Description only mentions 'full name' but does not specify format for 'name' or explain 'response_format' options.

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

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

Description clearly states verb 'Calculates' and resource 'Expression number', specifies the method (Goodwin method) and distinguishes from sibling with '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.

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

Provides a sibling differentiation section but lacks explicit 'when to use' guidance. Adequate but minimal contextual advice.

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

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

Describes complex calculation methodology (Swiss Ephemeris, sunrise-based tithi determination) and edge cases (tithi skipping, almanac differences). Annotations already indicate read-only, idempotent, non-destructive, and open-world. The description adds significant behavioral context beyond annotations.

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

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

Well-structured with clear sections (WHAT, WORKFLOW, INPUT, OUTPUT, etc.). While somewhat lengthy, each section adds necessary information. Could be slightly more concise (e.g., tithi calculation formula might be simplified), but overall effective.

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

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

Covers all relevant aspects: input validation, output contract with fields, error scenarios, compute class, and relationships to sibling tools. Output contract details compensate for the absence of explicit output schema text. Completely adequate for a complex tool with 6 parameters and no schema descriptions.

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

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

Despite 0% schema description coverage, the description details input contract: year range (1900-2100), requirement for location or lat+lon+timezone, and explanation of response_format options (json vs markdown). This fully compensates for missing schema descriptions.

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

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

The description clearly states it computes major Hindu festival dates for a given year and location, listing specific festivals and distinguishing between solar and tithi-based types. The 'DO NOT CONFUSE WITH' section explicitly names sibling tools (asterwise_get_panchanga_calendar and asterwise_get_muhurta) and their different purposes.

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

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

Provides explicit workflow with 'BEFORE: None — standalone' and 'AFTER: asterwise_get_panchanga' for further detail. The 'DO NOT CONFUSE WITH' section gives clear alternatives and when to use them. Error contract and compute class (SLOW_COMPUTE) also guide usage expectations.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable behavioral context beyond annotations: it explains that gemstone may be empty in primary due to dual lordship, warns about intentional gemstone duplication across secondary and contraindicated, and specifies the compute class as MEDIUM_COMPUTE. No contradiction with annotations.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, etc.), but it's verbose with redundant details like full output contract and error specifications that could be in structured fields. Some sentences (e.g., Edge cases about duplication) are necessary, but overall it could be more concise.

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

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

Given the tool's complexity, rich annotations, and detailed output schema, the description is highly complete. It covers purpose, usage guidelines, behavioral nuances, input/output contracts, error handling, and sibling distinctions. The output schema exists, so the description appropriately focuses on contextual information rather than repeating return values.

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

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

Schema description coverage is 50%, with detailed descriptions for birth parameters but none for response_format. The description adds minimal parameter semantics beyond the schema, mainly referencing the global contract for BirthData and explaining the two response_format options. It doesn't fully compensate for the schema gap, but the baseline is appropriate given the schema does substantial documentation.

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

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

The description clearly states the tool computes Ratna-style gemstone recommendations from a natal chart and specifies the exact output structure (primary, role-based stones, secondary options, contraindications, safety note). It distinguishes from siblings by explicitly naming asterwise_get_remedies and asterwise_get_lal_kitab_remedies as different tools.

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

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

The description provides explicit workflow guidance: BEFORE recommends asterwise_get_natal_chart to confirm the chart, and AFTER suggests asterwise_get_remedies for broader remedial programs. It also clearly states what the tool does NOT cover (mantra, fasting, Lal Kitab totkas), distinguishing it from alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds compute class, input/output contracts, error contract, and classical sources, which provide additional 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.

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

The description is well-structured with clear sections (WHAT, WORKFLOW, INPUT/OUTPUT CONTRACT, etc.). It is somewhat verbose but each section adds value, justifying its length.

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

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

For a complex tool with nested input and output, the description covers input contract, output contract (including fields), error contract, compute class, workflow, and sources. It is thorough and leaves no gaps.

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

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

Schema description coverage is high (most fields have descriptions). The description's input contract section restates the BirthData structure but adds little new meaning beyond the schema.

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

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

The description clearly states the tool returns four Ghatak timing parameters based on Janma Rasi, and distinguishes it from sibling tools like asterwise_get_nakshatra_prediction and asterwise_get_panchanga 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.

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

The description provides explicit guidance on when to use (avoiding new ventures when Ghatak parameters align), workflow (before nothing, after nakshatra prediction), and explicitly names siblings to avoid confusion.

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

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

Annotations cover read-only, open-world, idempotent, and non-destructive hints, so the bar is lower. The description adds valuable context beyond annotations: it specifies compute class ('MEDIUM_COMPUTE'), details error contracts (e.g., 'INVALID_PARAMS', 'INTERNAL_ERROR'), and mentions edge cases (e.g., 'ashtakavarga_score is null for Rahu and Ketu'). However, it doesn't explicitly address rate limits or authentication needs, though annotations imply safety.

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

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

The description is well-structured with clear sections (e.g., 'WHAT THIS TOOL COVERS', 'WORKFLOW'), each sentence adds value without redundancy. It is front-loaded with the core purpose, and the structured format enhances readability and efficiency for an AI agent.

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

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

Given the tool's complexity, rich output schema, and annotations, the description is highly complete. It covers purpose, usage guidelines, input/output contracts, error handling, and sibling differentiation. The output schema exists, so the description doesn't need to explain return values in detail, and it provides all necessary contextual information for effective tool use.

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

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

Schema description coverage is low at 33%, but the description compensates well. 'SECTION: INPUT CONTRACT' explains the optional target_date parameter with format and default behavior, and clarifies BirthData follows a global contract. While it doesn't detail all schema properties like ayanamsa or timezone, it adds meaningful context for key inputs, raising it above the baseline.

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

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

The description starts with a clear verb ('Computes') and specifies the exact resource ('Gochar against the natal Moon and Lagna'), then lists the comprehensive return data. It explicitly distinguishes from siblings like asterwise_get_transits and asterwise_get_dasha_transits, making the purpose specific and differentiated.

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

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

The 'SECTION: WHAT THIS TOOL COVERS' explicitly states what it does not do (e.g., 'does not list ingress events over a range'), and 'SECTION: DO NOT CONFUSE WITH' names alternatives. 'SECTION: WORKFLOW' provides clear before/after recommendations (e.g., 'BEFORE: RECOMMENDED — asterwise_get_natal_chart'), giving explicit guidance on 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.

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

Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable behavioral context beyond annotations: it explains the hora sequence logic ('sequence restarts from the weekday lord, spans day and night until next sunrise'), mentions edge cases ('Horas bridge midnight until the next sunrise reference'), and specifies the compute class ('FAST_LOOKUP'). No contradiction with annotations exists.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.) that make it easy to scan. While comprehensive, every section serves a purpose - distinguishing from siblings, explaining workflow, documenting contracts, and preventing confusion. Some sections could be more concise, but overall it's efficiently organized.

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

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

Given the tool has comprehensive annotations, 100% schema coverage, and an output schema (implied by the detailed OUTPUT CONTRACT section), the description is complete. It covers purpose, differentiation from siblings, behavioral context, input/output contracts, error handling, and edge cases. The existence of an output schema means the description doesn't need to explain return values in detail.

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

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

Schema description coverage is 100%, so the schema already fully documents all parameters. The description adds minimal parameter semantics beyond the schema - it mentions 'LocationInput date/coordinate rules apply locally (YYYY-MM-DD, bounded lat/lon)' which restates what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool 'Builds the twenty-four planetary Horas between successive sunrises for a location date and tags each hour with ruler, quality text, and whether it is current.' This is a specific verb ('Builds') + resource ('twenty-four planetary Horas') with precise scope. It explicitly distinguishes from siblings like asterwise_get_choghadiya and asterwise_get_natal_chart 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.

Does 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. The 'SECTION: WHAT THIS TOOL COVERS' states it's 'not Choghadiya (asterwise_get_choghadiya), and not full Panchanga (asterwise_get_panchanga).' The 'SECTION: DO NOT CONFUSE WITH' section explicitly names two sibling tools and explains the differences. The 'SECTION: WORKFLOW' clarifies it's standalone with no prerequisites.

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

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

The description adds substantial behavioral context beyond the annotations. While annotations indicate read-only, open-world, idempotent, and non-destructive operations, the description provides critical details: it's a 'FAST_LOOKUP' compute class, explains the upstream service call, describes error handling (INVALID_PARAMS and INTERNAL_ERROR scenarios), clarifies that it only provides 'sign-level content' not birth-chart analysis, and details the response format options (JSON vs markdown) and their identical underlying data.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.) that make information easy to find. While comprehensive, it's appropriately sized for a tool with complex behavior and 0% schema coverage. Some sections could be slightly more concise, but every sentence adds value beyond structured fields.

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

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

Given the tool's complexity (3 parameters with 0% schema coverage, multiple sibling tools, and rich output), the description is exceptionally complete. It covers purpose, usage guidelines, input semantics, output structure, response formats, compute class, error handling, and sibling differentiation. With an output schema present, it appropriately focuses on explaining the meaning and use of output fields rather than just listing them.

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

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

With 0% schema description coverage, the description fully compensates by providing comprehensive parameter semantics. 'SECTION: INPUT CONTRACT' details: period is constrained to the enum values, moon_sign accepts both Sanskrit and English names with normalization to lowercase English, and response_format selects JSON vs markdown rendering. It also explains resolution is upstream and what each format provides, adding crucial context not in the bare schema.

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

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

The description clearly states the tool 'fetches an AI-synthesised Moon-sign horoscope' with specific details about what it returns (structured guidance fields plus metadata). It explicitly distinguishes this from sibling tools like 'asterwise_get_natal_chart' and 'asterwise_get_gochar' by explaining this provides 'sign-level transit-flavoured copy' rather than personalized charts or planetary transit snapshots.

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

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

The description provides explicit guidance in multiple sections: 'SECTION: WHAT THIS TOOL COVERS' explains what it does and doesn't do (no natal chart, divisional charts, or dasha), 'SECTION: WORKFLOW' specifies when to use this tool (standalone) and when to use 'asterwise_get_natal_chart' instead, and 'SECTION: DO NOT CONFUSE WITH' clearly differentiates from two specific sibling tools with their purposes.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by explaining the algorithmic logic (missing digits) and providing an output contract. No contradictions with annotations.

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

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

The description is concise, front-loading the purpose in the first sentence, and uses a clear output contract section. No unnecessary information.

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

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

The description covers the tool's logic and output structure thoroughly, enabling an AI to understand expected inputs and outputs. Lacks details on error handling or edge cases, but this is adequate given the tool's simplicity.

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

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

The description does not explicitly describe the 'name' or 'response_format' parameters. With 0% schema description coverage, the description only indirectly clarifies usage via the output contract. It adds minimal value beyond the schema.

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

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

The description clearly states the tool identifies karmic lessons by finding absent digits 1-9 from name's letter values, specifying the exact resource and action. It distinguishes itself from sibling tools like get_expression_number or get_soul_urge_number.

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

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

There is no explicit instruction on when to use this tool versus other asterwise tools, such as when to prefer other numerology tools. However, the purpose is clear enough for an AI to infer usage context.

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

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

The description adds valuable behavioral context beyond the annotations: it explains that accurate birth time matters for reliable sub-lords, describes how midnight placeholders affect results, mentions that mismatched ayanamsa settings are forwarded upstream without local enforcement, and notes that sub-lord chains degrade with unknown birth times. While annotations cover safety (readOnly, non-destructive), the description provides practical implementation details without contradicting them.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.) that make it easy to scan. While comprehensive, every section adds value: distinguishing from siblings, providing workflow guidance, clarifying input/output behavior, and warning about edge cases. Some redundancy exists (output details appear in both OUTPUT CONTRACT and RESPONSE FORMAT), but overall it's efficiently organized.

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

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

Given the tool's complexity (astrological calculations with specific KP methodology), rich annotations, and detailed output schema, the description provides excellent contextual completeness. It covers the tool's purpose, when to use it, input considerations, output structure, error handling, sibling differentiation, and practical warnings. The presence of an output schema means the description doesn't need to explain return values in detail, allowing it to focus on higher-level context.

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

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

With only 50% schema description coverage (birth object has detailed descriptions but response_format lacks description), the description compensates well. It explains the purpose of the ayanamsa parameter ('kp' recommended for coherent physics), clarifies that time='00:00' is accepted without warning, and provides context about birth data requirements. The 'INPUT CONTRACT' section adds semantic understanding beyond the basic schema.

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

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

The description clearly states the tool 'Builds a KP natal chart with sub-lords on grahas and twelve cusps from BirthData using the KP ayanamsa', specifying the exact astrological system (Krishnamurti Paddhati), what it calculates (sub-lords for planets and cusps), and the required input (BirthData). It explicitly distinguishes from siblings asterwise_get_natal_chart and asterwise_get_prashna_chart 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.

Does 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: it recommends using this for KP charting (not BPHS radix or prashna), suggests cross-checking birth records before trusting sub-lords, and mentions asterwise_get_kp_significators as a follow-up tool. It also warns about time='00:00' yielding unreliable sub-lords and recommends ayanamsa='kp' for coherent physics.

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

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

Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond this: it specifies the tool uses server clock for 'now', notes coordinate validation is upstream, describes edge cases (instantaneous vs. natal), and details error handling (e.g., INTERNAL_ERROR for upstream failures). This enriches behavioral understanding without contradicting annotations.

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

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

The description is well-structured with clear sections (e.g., WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT), making it easy to scan. Each sentence adds value, such as distinguishing from siblings or explaining output fields, with no redundant information. The front-loaded summary immediately states the core purpose.

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

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

Given the tool's complexity (astrological computations), the description is highly complete. It covers purpose, usage, input semantics, output structure (detailed in OUTPUT CONTRACT), error handling, and sibling differentiation. With annotations covering safety and an output schema likely detailing return values, the description fills all necessary contextual gaps without over-explaining structured data.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'lat and lon only; no date parameter — "now" is implicit on the server clock', clarifying the temporal aspect. For 'response_format', it details the differences between 'json' and 'markdown' modes. However, it doesn't specify expected formats or ranges for lat/lon beyond noting they're 'not range-checked locally', leaving some ambiguity.

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

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

The description starts with a clear verb ('Computes') and resource ('KP ruling planets'), specifying it's for an instantaneous chart with lat/lon and no birth data. It explicitly distinguishes from siblings like 'asterwise_get_kp_chart' (needs birth data) and 'asterwise_get_kp_significators' (house significators), making the purpose specific and well-differentiated.

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

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

The 'WHAT THIS TOOL COVERS' section details what it does and does not cover, while 'DO NOT CONFUSE WITH' explicitly lists alternative tools and when to use them (e.g., 'asterwise_get_kp_chart — needs BirthData'). The 'WORKFLOW' section provides clear before/after guidance, making usage context explicit.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable context beyond this: it specifies that 'Out-of-range house integers are not validated locally — upstream handles errors as MCP INTERNAL_ERROR' and 'Filtering to one house still returns planet_significators{} for context.' It also mentions 'MEDIUM_COMPUTE' class and error handling details, which are not covered by annotations.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.), making it easy to scan. Each sentence adds value, such as explaining output structure, error handling, and sibling tool distinctions, with no redundant information.

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

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

Given the tool's complexity, the description is highly complete. It covers purpose, usage guidelines, input/output contracts, error handling, and sibling distinctions. With annotations providing safety and idempotency hints, and an output schema detailing the return structure, the description fills in necessary contextual gaps effectively.

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

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

Schema description coverage is 33%, which is low. The description adds some parameter context: 'house_number optional int; omit for all twelve. Values outside 1..12 are validated upstream only' and mentions 'Requires same birth tuple as asterwise_get_kp_chart for coherent analysis.' However, it doesn't fully compensate for the low schema coverage, as it doesn't explain the 'birth' object details or 'response_format' beyond what's in the schema.

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

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

The description clearly states the tool 'computes KP significator chains for all houses or one optional house from BirthData' and 'returns house tables plus planet-tier reverse indexes.' It distinguishes from siblings by explicitly naming 'asterwise_get_kp_chart' and 'asterwise_get_natal_chart' and explaining how they differ in function.

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

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

The description provides explicit guidance: 'BEFORE: RECOMMENDED — asterwise_get_kp_chart — establish cusps before significators' and 'DO NOT CONFUSE WITH' sections that clarify when to use this tool versus alternatives. It also specifies that it 'Requires same birth tuple as asterwise_get_kp_chart for coherent analysis.'

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

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

The description adds valuable behavioral context beyond the annotations. While annotations (readOnlyHint=true, destructiveHint=false) indicate a safe read operation, the description provides additional details: it specifies the compute class (MEDIUM_COMPUTE), describes the output format options (json vs markdown), explains error handling (INVALID_PARAMS, INTERNAL_ERROR), and warns about edge cases ('Lal Kitab houses are not interchangeable with BPHS cusps'). No contradiction with annotations exists.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.), making it easy to scan. Every sentence serves a specific purpose—explaining scope, distinguishing from siblings, describing workflow, or clarifying contracts—with no redundant information. The information is front-loaded with the core purpose in the first sentence.

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

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

Given the tool's complexity (astrological calculations with multiple output components), the description provides comprehensive context. It details the exact output structure, specifies compute requirements, explains error handling, and distinguishes from related tools. With annotations covering safety aspects and an output schema presumably detailing the response structure, the description fills all necessary gaps without duplicating structured data.

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

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

With only 2 parameters (birth and response_format) and 50% schema description coverage, the description adds meaningful context. It states 'BirthData global contract; mixing interpretive systems in prose is a caller concern, not validated here', clarifying that parameter validation follows a standard pattern. While it doesn't detail individual parameter fields, it provides high-level guidance about the input contract that complements the schema.

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

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

The description clearly states the tool 'Produces the Lal Kitab house and planet schema plus Rin (debt) flags from BirthData', specifying the exact verb ('produces'), resource ('Lal Kitab house and planet schema'), and output components. It explicitly distinguishes this from sibling tools like 'asterwise_get_natal_chart' (Parashari BPHS) and 'asterwise_get_lal_kitab_remedies' (remedy list only), providing clear differentiation.

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

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

The description includes explicit guidance on when to use this tool versus alternatives. It states 'Do not merge these houses with asterwise_get_natal_chart Bhava Chalit without explicit user intent — frameworks differ' and distinguishes it from 'asterwise_get_lal_kitab_remedies'. It also specifies 'BEFORE: None — standalone for Lal Kitab queries' and 'AFTER: asterwise_get_lal_kitab_remedies', providing clear workflow context.

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

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

Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context beyond this: it specifies the compute class (MEDIUM_COMPUTE), details error contracts (INVALID_PARAMS, INTERNAL_ERROR), and explains edge cases like empty remedies[] arrays. It does not contradict the annotations, which indicate a safe, non-destructive read operation.

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

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

The description is well-structured with clear sections (e.g., WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT), making it easy to scan. Each sentence adds value, such as distinguishing from siblings or explaining output formats, with no redundant information. It is appropriately sized for the tool's complexity, providing necessary details without verbosity.

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

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

Given the tool's complexity (with nested output structures) and the presence of annotations and an output schema, the description is highly complete. It covers purpose, usage guidelines, behavioral context (compute class, errors), parameter details, and output structure. The output schema is referenced in the 'OUTPUT CONTRACT' section, so the description need not explain return values in depth, focusing instead on interpretation and workflow.

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

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

Schema description coverage is 50%, with the 'birth' object well-documented but 'response_format' lacking description. The description compensates by detailing the 'response_format' parameter in the 'RESPONSE FORMAT' section, explaining that 'json' serializes for programmatic use and 'markdown' renders human-readable reports, with both returning identical data. This adds meaningful semantics beyond the schema's enum definition.

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

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

The description clearly states the tool 'Lists Lal Kitab style totkas per stressed planet from BirthData with priority tiers and typed action rows.' It specifies the exact resource (Lal Kitab totkas), the input source (BirthData), and the output structure. It explicitly distinguishes from sibling tools like 'asterwise_get_remedies' and 'asterwise_get_gemstone_recommendations' by noting they cover different remedy systems.

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

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

The description provides explicit guidance on when to use this tool versus alternatives. It states 'Distinct from Parashari mantra/gem rows (asterwise_get_remedies)' and 'Best interpreted alongside asterwise_get_lal_kitab_chart for house context.' It also includes a 'WORKFLOW' section recommending to use 'asterwise_get_lal_kitab_chart' before applying totkas and a 'DO NOT CONFUSE WITH' section listing specific sibling tools to avoid confusion.

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

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

Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond this: it specifies the tool ignores zero digits, details the compute class (MEDIUM_COMPUTE), and outlines error handling (upstream validation, INTERNAL_ERROR cases). However, it doesn't describe rate limits or auth needs, keeping it from a perfect score.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, etc.), each sentence adds value, and it's front-loaded with the core purpose. There's no redundant information, and the structured format enhances readability without unnecessary verbosity.

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

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

Given the tool's complexity, rich output schema detailed in the description, and comprehensive annotations, the description is complete. It fully explains the output structure (grid, planes, number analysis), error handling, compute class, and distinctions from siblings. The presence of an output schema means return values are adequately documented.

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

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

With 0% schema description coverage, the description compensates well. It explains 'date string only; validated upstream' and details the response_format options (json vs markdown) and their implications. While it doesn't specify date format examples, it clarifies that validation occurs upstream and both formats return identical data.

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

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

The description explicitly states the tool 'Derives a Lo Shu three-by-three frequency grid from birth-date digits' and provides detailed coverage of what it analyzes (digit frequencies, plane analysis, number traits). It clearly distinguishes from sibling tools like 'asterwise_get_numerology_profile' and 'asterwise_get_name_correction' by specifying what it does NOT compute.

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

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

The 'SECTION: DO NOT CONFUSE WITH' explicitly names alternative tools and explains when NOT to use this tool (e.g., for Pythagorean Life Path or Chaldean compounds). The 'SECTION: WHAT THIS TOOL COVERS' further clarifies scope, and 'SECTION: WORKFLOW' indicates it's standalone with no prerequisites.

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

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

The description adds valuable behavioral context beyond what annotations provide. While annotations declare readOnlyHint=true, idempotentHint=true, etc., the description specifies that this is a 'FAST_LOOKUP' compute class, that all validation is upstream, that upstream failures surface as MCP INTERNAL_ERROR, and that the tool mirrors lucky_numbers[] from the full profile. This provides practical implementation details that help the agent understand performance characteristics and error handling.

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

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

The description is exceptionally well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, OUTPUT CONTRACT, etc.). Each sentence earns its place by providing specific, actionable information. The information is front-loaded with the core purpose, followed by detailed sections that can be referenced as needed. No wasted words or redundancy.

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

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

Given the tool's complexity and the presence of an output schema, the description provides comprehensive context. It explains what the tool does, when to use it, input behavior, output structure (even though an output schema exists), compute characteristics, error handling, and differentiation from siblings. The description successfully bridges the gap between structured fields and practical usage, making it complete for agent decision-making.

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

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

With 0% schema description coverage, the description carries the full burden of explaining parameters. It clearly states that 'name and date forwarded upstream without local checks' and provides detailed information about the response_format parameter, explaining that both 'json' and 'markdown' options return identical data but in different formats for different use cases. This adds meaningful context beyond the bare schema.

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

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

The description clearly states the tool 'fetches condensed lucky-number guidance for a name and birth date' with specific details about what's included (primary/secondary picks, power number, interpretation, date_specific flag). It explicitly distinguishes this from sibling tools asterwise_get_numerology_profile and asterwise_get_lo_shu_grid, making the purpose specific and differentiated.

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

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

The description provides explicit guidance on when to use this tool ('Use when payload size matters') and when not to use it ('It is not the full profile... nor Lo Shu counts'). It names specific alternatives (asterwise_get_numerology_profile for deeper context, asterwise_get_number_meaning for dictionary entries) and includes a 'DO NOT CONFUSE WITH' section that clearly delineates boundaries with sibling tools.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds value by stating the calculation combines Life Path and Expression numbers, and that the Maturity number represents a desire around age 35. It also lists the output contract, helping the agent understand return fields. No contradictions with annotations.

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

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

The description is concise with two sentences plus an output contract. It is front-loaded with the action and purpose, and the output contract is clearly separated. No unnecessary information.

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

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

Given the complexity (3 params, output schema, many siblings), the description covers purpose, output, and prerequisites adequately. However, it lacks details on parameter formats, edge cases, or example usage. The annotations compensate partially, but the description could be more complete in guiding an agent.

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

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

Schema description coverage is 0%, placing the burden on the description to explain parameters. The description only notes that name and birth date are required, which is already in the schema. It does not clarify name format, date format, or the meaning of response_format enum values, so it adds little beyond the schema.

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

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

The description clearly states the tool calculates the Maturity number from Life Path and Expression numbers, and explains its significance as a wish/desire surfacing around age 35. This is specific and distinguishes it from sibling tools like get_expression_number or get_soul_urge_number.

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

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

The description mentions prerequisites (name and birth date) but does not provide explicit guidance on when to use this tool versus alternatives, nor does it specify when not to use it. The context of age 35 is provided, which implicitly suggests its relevance, but no direct comparisons to sibling tools are made.

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

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

The description adds substantial behavioral context beyond annotations. While annotations indicate read-only, non-destructive, idempotent operations, the description details compute class ('MEDIUM_COMPUTE'), error contracts (INVALID_PARAMS, INTERNAL_ERROR), edge cases (yoga name clarification), and specific rejection rules for unsupported activities. This provides crucial operational context not covered by annotations.

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

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

The description is exceptionally well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.), each containing only essential information. Every sentence serves a specific purpose with zero redundancy, making it easy to scan and understand despite the complexity of the tool.

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

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

Given the tool's complexity and the presence of an output schema, the description provides complete context: it explains what the tool does, when to use it, input requirements, output structure, error handling, compute characteristics, and sibling distinctions. The output schema existence means the description doesn't need to explain return values, and it focuses appropriately on behavioral and usage aspects.

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

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

With only 25% schema description coverage, the description compensates well by explaining parameter semantics: it specifies that 'activity must be one of the supported English slugs' and lists them, clarifies that 'from_date/to_date ordering and span rules are enforced upstream', and explains location validation. However, it doesn't detail all four parameters' formats beyond what the schema minimally provides.

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

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

The description explicitly states the tool 'Searches a date span for top-scoring muhurta windows for a named activity using Panchanga, Choghadiya, and classical siddhi flags at a location.' This is a specific verb ('searches') with clear resources ('date span', 'muhurta windows', 'activity') and distinguishes from siblings by naming what it does not return ('full month calendar' or 'only Choghadiya rows').

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

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

The description provides explicit guidance on when to use this tool versus alternatives: 'BEFORE: None — this tool is standalone. AFTER: asterwise_get_panchanga — drill into Panchanga limbs for a chosen winning date.' It also clearly distinguishes from sibling tools like 'asterwise_get_choghadiya' and 'asterwise_get_panchanga' with specific 'DO NOT CONFUSE WITH' section.

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

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

The description adds substantial behavioral context beyond what annotations provide. While annotations indicate read-only, open-world, idempotent, and non-destructive operations, the description adds important constraints: 'Names are case-sensitive exact matches,' 'no local fuzzy matching or normalisation,' 'FAST_LOOKUP' compute class, and detailed error handling for invalid parameters and edge cases. This provides crucial operational guidance not captured in annotations.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.), making it easy to navigate. While comprehensive, some sections could be more concise (e.g., OUTPUT CONTRACT lists all fields but could summarize categories). Every sentence adds value, but the overall length is substantial for a lookup tool.

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

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

Given the tool's complexity (static metadata lookup with detailed output) and the presence of an output schema, the description is exceptionally complete. It covers purpose, usage guidelines, behavioral constraints, parameter semantics, output format options, compute class, error handling, and sibling differentiation. The OUTPUT CONTRACT section provides a comprehensive field list, though the output schema would handle this structurally.

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

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

With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains that 'nakshatra_name is forwarded raw — no local fuzzy matching or normalisation' and 'Names are case-sensitive exact matches (Ashwini … Revati list).' For response_format, it explains the difference between json and markdown modes and that both return identical underlying data. This adds essential meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Looks up static metadata for one of twenty-seven nakshatras by exact name and returns interpretive, professional, activity, and body-map reference data.' It specifies the exact resource (nakshatras), action (looks up), and distinguishes from siblings by explicitly stating it's for static metadata lookup rather than computation.

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

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

The description provides explicit guidance on when to use this tool versus alternatives. It states: 'Vedanga/classical reference only — no chart computation' and 'It does not compute birth nakshatra from BirthData (use asterwise_get_natal_chart).' The 'DO NOT CONFUSE WITH' section explicitly names two sibling tools and explains their different purposes.

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

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

Description details the computation steps (Tarabala, Chandrabala, transit nakshatra quality), output fields, and compute class (MEDIUM_COMPUTE). Annotations (readOnlyHint=true) are consistent; no contradictions. The error contract is also specified.

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

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

The description is long but well-structured with labeled sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.). It is front-loaded with purpose and then breaks down details. Could be slightly more concise but remains clear.

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

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

Given the tool's complexity (Vedic astrology prediction), the description covers input, output, workflow, exclusions, error handling, and compute class. An output schema exists but the description still fully explains the return structure. Very thorough.

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

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

The input schema has only 33% description coverage, but the description compensates with a detailed 'INPUT CONTRACT' explaining birth (BirthData), target_date format/default, and response_format enum. It adds meaning beyond the schema's minimal descriptions.

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

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

The description clearly states it returns a personalised daily prediction using Tarabala and Chandrabala from the Muhurta Chintamani tradition. It explicitly distinguishes from siblings like asterwise_get_nakshatra_details, asterwise_get_panchanga, and asterwise_get_biorhythm.

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

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

The description includes a 'SECTION: DO NOT CONFUSE WITH' naming specific alternatives and a 'WORKFLOW' section stating no prior tool needed and suggesting asterwise_get_panchanga afterwards. It provides 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.

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

The description adds valuable behavioral context beyond what annotations provide. While annotations indicate read-only, open-world, idempotent, and non-destructive operations, the description explains that empty alternatives[] is valid (success case), clarifies compute class as MEDIUM_COMPUTE, details error handling (upstream validation, INTERNAL_ERROR cases), and specifies that recommendation is currently a null stub. No contradiction with annotations exists.

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

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

The description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.), making it easy to navigate. While comprehensive, some sections like 'RESPONSE FORMAT' could be more concise. Overall, each section adds value without unnecessary repetition.

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

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

Given the tool's complexity (numerology analysis with multiple metrics), the description provides complete context. It details output structure (including current_name metrics and alternatives array), explains edge cases (empty alternatives), distinguishes from siblings, and covers workflow recommendations. With annotations and output schema available, the description fills all necessary gaps.

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

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

With 0% schema description coverage, the description compensates well by explaining parameter semantics in the 'INPUT CONTRACT' section. It clarifies that 'name and date strings only; upstream validates' and details the response_format parameter's effect on output presentation (json vs markdown). However, it doesn't specify exact date format or name formatting requirements.

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

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

The description clearly states the tool's purpose with specific verbs ('scores', 'suggests', 'echoes') and resources ('personal name', 'birth-date Life Path', 'alternate spellings'). It explicitly distinguishes from sibling tools like asterwise_get_business_name_analysis and asterwise_get_chaldean_numerology, making the scope unambiguous.