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 are readOnly, openWorld, idempotent, non-destructive. Description adds behavioral context: no date parameter (API pins to current day), input contract (BirthData global), output contract with all fields, error contracts (INVALID_PARAMS, INTERNAL_ERROR), compute class (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?

Description is long but well-organized into sections with clear headings. It is front-loaded with key purpose and usage. Some redundancy exists in output contract, but structure aids readability. Could be slightly more concise, but not overly verbose.

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 (nested objects, output schema present), description is very complete: covers purpose, workflow, input/output contracts, error handling, compute class, and differentiation from siblings. Output schema is provided, so description adds 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?

Schema coverage is 50% but birth object has detailed descriptions for each field. Description adds meaning beyond schema: explains response_format options (json for programmatic, markdown for human-readable) and notes that English sign names are used. Some parameter details are already in schema, but description provides additional context.

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

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

Description clearly states that the tool evaluates Saturn's 7.5-year Moon-sign cycle phases (Sade Sati) against natal data for the current day, returning intensity, upcoming cycles, and historical rows. It explicitly distinguishes from siblings like asterwise_get_gochar and asterwise_get_transits, ensuring no confusion.

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: BEFORE recommending asterwise_get_natal_chart for context and AFTER suggesting asterwise_get_gochar for broader transit. It also states what the tool covers and what it does not (not general Gochar or dasha overlay), giving clear 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 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?

The description adds significant behavioral context beyond annotations: it discloses the use of cryptographic randomness (Python secrets.SystemRandom), independence of calls (no session state), uniqueness guarantee within a draw, and pre-computation of active_meaning. Annotations already indicate readOnlyHint=true, which is consistent, and the description adds no contradictions.

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

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

The description is long but well-structured with clear section headings (SECTION: WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.), making it easy to navigate. While concise overall, a few sentences could be trimmed, but the structure justifies the 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?

The description is extremely thorough for a tool with 3 parameters and an output schema. It covers input constraints, output contract (with field descriptions), response format options, compute class, error contract, and disambiguation from three sibling tools. No gaps are evident.

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 'INPUT CONTRACT' section fully compensates by explaining each parameter in detail, including valid ranges, defaults, examples, and error handling. For instance, count is described with examples like '1 (daily pull), 3...', and allow_reversed is explained with its probabilistic behavior. This adds substantial 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 explicitly states 'Draws N unique random cards from the 78-card deck using cryptographic randomness', providing a clear verb, resource, and distinguishing characteristic. The 'WHAT THIS TOOL COVERS' section further clarifies use cases, and the disambiguation section explicitly differentiates from sibling tools.

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

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

The description includes a 'WORKFLOW' section stating 'BEFORE: None — standalone' and 'AFTER: None — interpret drawn cards', and a dedicated 'DO NOT CONFUSE WITH' section listing three sibling tools with clear explanations of when to use each alternative instead. This provides explicit when-to-use and when-not-to-use guidance.

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

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 declare readOnlyHint=true and destructiveHint=false. Description adds compute class, error contracts, and edge cases (Rahu/Ketu not classical contributors), but no contradictions.

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

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

Well-structured with clear sections, but somewhat lengthy. Each section adds value; could be slightly more concise.

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

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

Given the complexity, the description covers workflow, error handling, output structure, and edge cases comprehensively. Output schema exists but description still adds 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 50% due to nested 'birth' object. Description states 'BirthData only' but doesn't add details beyond schema. However, output contract is well-documented.

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 full Ashtakavarga bindu matrices, reductions, and totals from BirthData for transit support analysis. It distinguishes from sibling tools like asterwise_get_chart_strength and asterwise_get_gochar.

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?

Explicit workflow section recommends asterwise_get_natal_chart before and asterwise_get_gochar after. Also includes 'DO NOT CONFUSE WITH' section listing 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?

The description goes well beyond the annotations (readOnlyHint, idempotentHint, etc.) by detailing compute class (MEDIUM_COMPUTE), error contracts (INVALID_PARAMS, INTERNAL_ERROR), edge cases (no classical applicability check), and output format (DD/MM/YYYY dates, nested sub periods). 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 (WORKFLOW, INPUT CONTRACT, OUTPUT CONTRACT, etc.) and starts with a concise summary. However, it is lengthy due to the comprehensive coverage. While every section serves a purpose, verbosity could be slightly reduced without losing 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?

For a complex tool with multiple parameters, output schema, and sibling comparisons, the description covers all necessary aspects: what the tool computes, output structure, workflow, error handling, compute class, and distinctions from similar tools. The presence of an output schema means return values need not be detailed, and the description still provides key structural info.

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 only 33%, requiring the description to compensate. The description adds context about the 'levels' parameter (range 1-5) and the date format, but does not elaborate on other parameters beyond what the schema already provides. It provides moderate additional value but does not fully compensate for the low 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 that the tool computes the 108-year Ashtottari Dasha tree with configurable depth and returns periods under data.periods.root. It explicitly distinguishes itself from Vimshottari, Yogini, and Char dasha, and contrasts with sibling tools like asterwise_get_dasha.

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

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

The description includes a dedicated WORKFLOW section recommending a prerequisite (asterwise_get_natal_chart) and optional follow-up (asterwise_get_dasha for comparison). The 'DO NOT CONFUSE WITH' section explicitly warns against using this tool for other dasha types, providing clear when-to-use and when-not-to-use guidance.

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

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 a safe, read-only, idempotent operation. The description adds valuable details: compute class (FAST_LOOKUP), error contracts, and the specific behavior of only using first letters. No contradictions.

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

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

The description is well-structured with clear section headers and front-loaded with the core purpose. While lengthy, each section adds necessary context for correct usage. Could be slightly more concise but not wasteful.

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 niche numerological purpose and absence of an output schema, the description covers all necessary aspects: purpose, input format with examples, output structure (data.number and data.is_master_number), response format options, compute class, error contract, and differentiation from related tools.

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 no parameter descriptions (0% coverage). The description fully compensates with detailed explanations for both parameters: 'name' is defined as full birth name with space-splitting rules and examples, and 'response_format' is explained with its two values and effect.

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

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

The description clearly states it calculates the Balance number from first letters of name parts using Pythagorean values. It explicitly distinguishes itself from siblings like asterwise_get_expression_number and asterwise_get_karmic_lessons, 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 ('consulted specifically in times of stress') and what it does not cover (everyday personality). It also directly contrasts with sibling tools 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?

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 (readOnlyHint=true, destructiveHint=false) already declare the tool safe and idempotent. The description adds behavioral context: computation class (MEDIUM_COMPUTE), response format modes (json vs markdown), error contracts with edge cases like tie-breaking, and date format differences. All consistent with annotations with no contradictions.

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

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

The description is well-structured with clear sections and front-loaded summary, but it is verbose—spanning multiple sections with repeated admonitions. Some sentences (e.g., repeated edge-case handling) could be condensed without losing meaning.

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 an output schema (not shown but mentioned) and annotations, the description covers input contract, output contract, workflow, error contracts, and differentiation from siblings. It provides a complete picture for an agent to invoke the tool correctly.

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

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

With 50% schema coverage, the description adds value by noting the 'BirthData global contract' for the birth parameter and clarifying the date format difference (ISO vs DD/MM/YYYY) from a sibling tool. It also explains the response_format parameter's effect. This 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 the tool computes Char Dasha from birth data, specifying outputs like sign lords, ISO-dated sequences, and karaka mappings. It explicitly distinguishes from siblings such as asterwise_get_dasha and asterwise_get_yogini_dasha, so an agent can precisely identify its purpose.

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

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

The description provides a dedicated 'WORKFLOW' section recommending asterwise_get_natal_chart before and asterwise_get_dasha after, plus a 'DO NOT CONFUSE WITH' section that names alternative tools. This gives explicit when-to-use and when-not-to-use guidance.

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

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

The description adds significant behavioral context beyond annotations: compute class (~800ms), error contract, edge cases (large payload), and response format options. It does not contradict the annotations (readOnlyHint, idempotentHint).

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-loads the main purpose, but it is verbose, spanning multiple sections with detailed sub-headings. While the length is justified by the tool's complexity, 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?

For a complex tool with numerous outputs, the description is remarkably complete: it covers workflow, error handling, detailed output contract with field names and types, response format options, and edge cases. No important context is missing.

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

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

The input schema already provides descriptions for both parameters (birth, response_format). The description adds value by clarifying the input contract ('BirthData only; no extra toggles') and the purpose of response_format. Given high schema coverage, the description's additional context is useful but not extensive.

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

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

The description clearly states what the tool does: aggregates Shadbala, Bhavbala, Vimshopaka, and other chart strength computations from BirthData. It also includes a dedicated 'DO NOT CONFUSE WITH' section that explicitly distinguishes it from sibling tools like asterwise_get_yogas and asterwise_get_ashtakavarga.

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 with recommended prior and subsequent tool calls ('BEFORE: asterwise_get_natal_chart', 'AFTER: asterwise_get_yogas'), and lists alternatives 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 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, idempotentHint, destructiveHint. The description adds valuable context: compute class MEDIUM_COMPUTE, upstream computation, edge case advice (e.g., 'Rajju and Vedha conditions may be present alongside high scores'), and error contracts. No contradiction.

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

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

The description is well-structured into labeled sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.) and front-loaded with the core purpose. While lengthy, each section provides necessary information 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 the tool's complexity, the description covers all aspects: purpose, workflow, input/output contracts (including detailed output schema), error handling, compute class, and sibling distinctions. It even addresses edge cases, making it fully complete.

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

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

Schema description coverage is 67% (person1/person2 have descriptions; response_format lacks one). The description compensates by detailing the input contract ('Two BirthData objects follow the global contract') and explaining response_format options (json vs markdown with use cases). This adds 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 explicitly states the tool 'Scores North Indian Ashtakoota (36-point Guna Milan) for two charts' and lists what it returns (koota breakdown, dosha flags, etc.). It distinguishes from siblings by naming alternatives like asterwise_get_dashakoot in a dedicated '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 includes a 'WORKFLOW' section recommending to use asterwise_get_natal_chart before and asterwise_get_papasamyam after. It also clarifies it is not Dashakoot, Tamil Porutham, or Thirumana, providing explicit when-to-use and when-to-avoid 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 and idempotentHint. The description adds critical behavioral details such as the caution field containing safety warnings for specific crystals (e.g., toxicity of Malachite) and error contract descriptions. 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 into labeled sections (BEFORE, INPUT, OUTPUT, ERROR, etc.) and each adds value. It is somewhat verbose but appropriate for a tool with multiple facets; minor conciseness improvements could be made.

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 syntax, output shape, error cases, safety warnings, and integration points. With an output schema present, the description adequately references it ('same shape as each crystal in asterwise_get_crystals'). Complete for a lookup tool.

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

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

Schema coverage is 0%, so description fully compensates. It explains the 'name' parameter can be slug or display name with examples (e.g., 'blue-sapphire'), and details 'response_format' options (json vs markdown) with different response styles. Adds 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 'Lookup a specific crystal by slug or name' and specifies the returned data includes full detail. It distinguishes from siblings like asterwise_get_crystals (full catalogue) and asterwise_get_crystal_by_planet (by planet), preventing confusion.

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 'BEFORE/AFTER' workflow context and a 'DO NOT CONFUSE WITH' section listing sibling tools with their purposes, providing clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. Description adds valuable context beyond annotations: sorting order (Navaratna first), filtering criteria (only navaratna/uparatna), and response format behavior (identical data, different formatting). No contradictions.

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

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

Well-structured with clear sections, but somewhat verbose (repetition in 'What This Tool Covers' section largely restates main description). Still, it is front-loaded with purpose and remains readable.

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 2 parameters with simple types, the description covers all necessary context: valid inputs, output structure (data.total, data.crystals), sorting, filtering, error conditions, and workflow integration. Output schema exists but description still adds value by explaining shape and sort order.

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% (no descriptions in JSON schema), so description bears full burden. It thoroughly explains the 'planet' parameter listing valid values and 'response_format' enum options with behavior details (identical data). This fully compensates 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 it returns all crystals associated with a specific Vedic planet (verb+resource). It distinguishes from siblings like asterwise_get_crystals (all 50 crystals) and asterwise_get_gemstone_recommendations (chart-specific recommendations). The scope is precise and unambiguous.

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

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

Provides explicit guidance on when to use (Jyotish practitioners recommending remedial gems) and when not to (crystals with no Vedic correspondence). The 'DO NOT CONFUSE WITH' section and workflow BEFORE/AFTER suggestions offer clear context and differentiation from alternative 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 indicate readOnly and non-destructive. The description adds detailed behavioral traits: scoring method (zodiac 3, chakra 2, intention 1), ranking, matching logic (partial match on keywords), valid values, error contracts, and compute class. No contradictions.

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

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

The description is well-structured with clear sections (scoring, workflow, input/output contracts, error contract, differentiation). The first sentence front-loads the core purpose. Every 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 the tool's complexity (5 parameters, scoring, multiple siblings), the description covers all needed information: how to use, output contract, error handling, differentiation, and workflow. Output schema exists, so return values are appropriately not detailed. Nothing missing.

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 description fully explains all five parameters: limit (default 5, max 20), chakra (valid list), intention (keyword, partial match), zodiac_sign (English zodiac names), response_format (enum, not detailed but schema covers it). Also states at least one filter is 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?

The description clearly states the tool recommends crystals based on zodiac sign, chakra, or intention keyword, with at least one filter required. It differentiates from siblings like asterwise_get_crystal_by_planet and asterwise_get_gemstone_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?

Explicitly states when to use (for crystal recommendations based on zodiac/chakra/intention) and when not (not for Jyotish prescription, for chart-based gem use asterwise_get_gemstone_recommendations). Also provides workflow: standalone for consumer apps, then optionally asterwise_get_crystal for full details.

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 indicate safe read operation. Description adds extensive behavioral details: inclusion/exclusion rules, scoring algorithm, dangerous combinations, that non-classical crystals are never returned, edge cases (empty results, caution fields), error contracts, and output structure. 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 section headers, but quite lengthy. Some redundancy (e.g., rules restated). Front-loaded with purpose and key rules. Could be shortened slightly without losing clarity, but structure makes navigation easy.

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 extremely thorough: covers all input/output contracts, error handling, edge cases, workflow, sibling differentiation, and detailed rules. Output schema exists (described in OUTPUT CONTRACT) so return values are fully 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 50% schema coverage, description adds huge value: explains time sensitivity for birth parameter, defaults for ayanamsa and timezone, constraints on date range, and clarifies that response_format=json vs markdown return identical data but different presentations.

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 house lordship rules. It explicitly distinguishes from three sibling tools (asterwise_get_gemstone_recommendations, asterwise_get_crystal_recommendations, asterwise_get_crystal_by_planet) by engine, input type, and output detail.

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 'WORKFLOW' section listing BEFORE (none) and AFTER links to other tools. Includes a 'DO NOT CONFUSE WITH' section naming siblings and their differences. Explains when to use this tool (classical Vedic prescription) vs 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 indicate readOnlyHint, idempotentHint, and nondestructive behavior. The description adds context about the static database ('FAST_LOOKUP — static database, no ephemeris') and the dual-tradition content. 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-loaded with key information. It is somewhat verbose due to exhaustive detail (e.g., ERROR CONTRACT, OUTPUT CONTRACT), but each section serves a purpose for clarity. Could be slightly trimmed but still 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?

Given the tool's complexity (50 crystals, dual-tradition fields), the simple schema, and the presence of an output schema, the description is highly complete. It covers the vedic_correspondence logic, workflow, error behavior, and output structure thoroughly.

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 single parameter response_format is described in the 'RESPONSE FORMAT' section: 'response_format=json — full 50-crystal array. response_format=markdown — formatted catalogue. Both return identical data.' This adds meaning beyond the schema's enum values, especially since schema coverage is 0%.

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

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

The description clearly states 'Returns all 50 crystals in the database sorted alphabetically', providing a specific verb and resource. It distinguishes from sibling tools like asterwise_get_crystal, asterwise_get_crystal_by_planet, etc., 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 includes a WORKFLOW section stating 'BEFORE: None — standalone catalogue.' and 'AFTER: asterwise_get_crystal_by_planet — filter by Vedic planet for remedial use.' It also lists alternatives in 'DO NOT CONFUSE WITH', making when-to-use and when-not-to-use explicit.

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

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

Annotations already provide readOnlyHint, idempotentHint, etc. Description adds compute class timing (~100-1500ms), complete error contract (INVALID_PARAMS, INTERNAL_ERROR, edge cases), and output structure 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?

Very long but well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.). Each section earns its place. Slightly verbose but appropriate for the complexity; could be more concise while retaining all essential info.

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 parameters, nested objects, output schema exists), the description covers everything: input contract, output contract, error handling, edge cases, and integration with sibling tools. No gaps identified.

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 only 33% schema description coverage, the description comprehensively explains all parameters: levels depth and payload impact, birth data contract with special note about time='00:00', and response_format options. Adds meaning well 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 it computes Vimshottari Dasha from birth data, returns hierarchical period trees and interpretation blocks. It explicitly lists what it does not cover (Char, Yogini, Ashtottari) and distinguishes from many sibling dasha 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?

Provides explicit workflow: BEFORE use asterwise_get_natal_chart, AFTER use asterwise_get_dasha_transits. Also includes a 'DO NOT CONFUSE WITH' section naming alternative tools for different dasha systems, 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 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 mark the tool as read-only, idempotent, and non-destructive. The description adds behavioral details such as D30 omitting Sun and Moon, compute class MEDIUM_COMPUTE, and detailed error contracts, going 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-organized with clear sections, but it is verbose. The first sentence is effective, though some sections could be condensed without losing 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?

The description covers output format details, error contracts, workflow order, and response format options. With an output schema indicated, the description compensates fully for any 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?

Despite schema coverage at 33%, the description thoroughly explains the chart_type parameter behavior (single vs all), the response_format modes, and the birth data structure. The enum values for chart_type are listed in the description.

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

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

The description specifies the tool computes divisional (varga) chart positions from BirthData, with clear differentiation between single chart and all sixteen vargas. It also distinguishes itself from siblings like asterwise_get_natal_chart and asterwise_get_chart_strength.

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 recommending to call asterwise_get_natal_chart first and a 'DO NOT CONFUSE WITH' section that explicitly names alternative tools for different use cases.

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, including compute class (MEDIUM_COMPUTE), error contracts for INVALID_PARAMS and INTERNAL_ERROR, edge cases about cancellation lists, and details on output format differences between json and markdown. No contradiction with readOnlyHint=true or other 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-organized with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, OUTPUT CONTRACT, etc.), making it easy to parse. While it is lengthy, each section serves a purpose and front-loads the main action. Minor redundancy in listing doshas twice could be trimmed, but overall efficient.

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

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

Given the complexity of twelve doshas with detailed output, the description covers input contract, output contract with field types, error contracts, workflow suggestions, and sibling tool distinctions. It is complete enough for an AI agent to understand when and how to use the tool 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 coverage for the birth object is high, and the description adds that unknown birth time at midnight is accepted silently. It explains the effect of response_format options (json vs markdown), which adds value beyond the schema enum descriptions. However, some parameters like timezone default are mentioned in schema, but description does not add new constraints beyond what 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 explicitly states it scores twelve fixed dosha buckets from birth data and lists each dosha name. It also distinguishes from sibling tools asterwise_get_chart_strength and asterwise_get_compatibility, making the purpose very specific and clear.

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

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

The description includes a dedicated 'SECTION: DO NOT CONFUSE WITH' that names two alternative tools, a 'SECTION: WORKFLOW' that recommends prerequisite tools (asterwise_get_natal_chart) and follow-up tools (asterwise_get_remedies), and explicit statements about what the tool does not replace.

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 indicate readOnly, non-destructive, idempotent, open world. Description adds context: tradition conflicts (snake, elephant, crow, wedding), themes field for synthesis, response formats, and error contracts (invalid params → 404, internal error). No contradictions.

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

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

The description is well-structured with sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.). It front-loads core purpose. Slightly verbose but each section adds value; could be more concise but still 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?

Given the tool's complexity (dual-tradition, context variants, related symbols) and the presence of an output schema (mentioned in context signals), the description covers input, output format, error handling, workflow, and provides examples of tradition conflicts. It is complete and leaves no major gaps.

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

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

Schema coverage is 0% (no descriptions in schema). Description provides examples for 'name' ('snake', 'eagle', etc.), notes case-insensitivity, and explains 'response_format' enum values (json vs markdown return identical data). Adds significant meaning beyond 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 looks up a specific dream symbol by slug or name (case-insensitive) and returns full dual-tradition interpretation. It identifies the resource (dream symbol) and the action (lookup). It also distinguishes from sibling tool asterwise_get_dream_symbols by noting it is for a single symbol vs full database listing.

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

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

Explicitly states use cases: dream journaling, AI-powered interpretation, cross-tradition comparison. Includes a 'DO NOT CONFUSE WITH' section naming the alternative sibling tool. Mentions stand-alone workflow with no prerequisites, and provides error handling 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 indicate readOnly, openWorld, idempotent, and non-destructive hints. The description adds beyond that by detailing the 500 symbols, 8 categories, and the 'traditions_agree' field highlighting East-West conflicts. The 'COMPUTE CLASS: FAST_LOOKUP' section also clarifies performance. 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 (e.g., 'WHAT THIS TOOL COVERS', 'WORKFLOW', 'INPUT CONTRACT'). However, it is verbose and could be more concise; several sentences repeat information already implied by the structure.

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

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

Given the tool's complexity (500 symbols, dual traditions, optional filters), the description covers all necessary aspects: input, output format, error contracts, compute class, and sibling differentiation. The output schema exists (as per context) and the description details the output structure, so completeness is high.

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 description must compensate. The 'INPUT CONTRACT' section lists the optional category parameter with valid values ('animals, nature, people, places, objects, actions, body, abstract'). The 'RESPONSE FORMAT' section explains the response_format parameter's values ('json' for symbol array, 'markdown' for formatted catalogue), adding meaning beyond the schema enum.

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 (Jungian and Vedic). It explicitly distinguishes from the sibling tool 'asterwise_get_dream_symbol' which returns a single symbol detail, satisfying the purpose clarity criteria.

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 'WHAT THIS TOOL COVERS' section explaining the scope, a 'WORKFLOW' section showing before/after dependencies, and a 'DO NOT CONFUSE WITH' section that explicitly warns against using it for single symbol retrieval. This provides clear guidance on when to use this tool vs alternatives.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. The description adds master number preservation (11, 22, 33), per-part reduction method, output fields including karmic debt, and compute class (FAST_LOOKUP). 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 but is quite lengthy. However, each section adds necessary detail without redundancy, earning a high score but not perfect due to 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?

Given the complexity and many sibling tools, the description covers purpose, usage, parameters, output contract, error contract, compute class, and response format options. Output schema exists, so return values need not be elaborated.

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 description fully compensates. The INPUT CONTRACT details the 'name' parameter (full legal name, case-insensitive, alphabetic constraint) and 'response_format' enum with usage explanation.

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 Expression (Destiny) number using Pythagorean letter values with the Goodwin/Balliett per-part method. It distinguishes from siblings like Soul Urge, Personality, and Chaldean numerology.

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?

Explicit workflow guidance is provided, including that the tool is standalone and can be followed by asterwise_get_soul_urge_number. A 'DO NOT CONFUSE WITH' section lists alternatives with clear differentiators.

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, and destructiveHint=false. The description adds behavioral context beyond annotations: compute class (MEDIUM_COMPUTE), error contracts (INVALID_PARAMS, INTERNAL_ERROR), and an explanation that parameters are fixed per Janma Rasi, independent of transits. No contradiction.

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

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

The description is long but well-structured with clear labeled sections (SECTION: WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, OUTPUT CONTRACT, etc.). It is front-loaded with purpose and sibling differentiation. Could be slightly more concise, but the structure aids readability.

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 (nested output, multiple parameters, and specific astrological domain), the description is comprehensive. It covers input, output, compute intensity, error handling, and usage context. The output contract compensates for not describing return values in prose, as the output schema exists.

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

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

Schema description coverage is 50% – the 'birth' object parameter is fully described in the schema, but 'response_format' lacks a schema description. The description provides an 'INPUT CONTRACT' section summarizing 'birth' but does not elaborate on 'response_format' or its role. This partially compensates but leaves the missing parameter unexplained.

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

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

The description clearly states the tool returns the four Ghatak (inauspicious) timing parameters based on Janma Rasi (natal Moon sign). It uses a specific verb-resource combination and explicitly distinguishes from siblings 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 includes a 'DO NOT CONFUSE WITH' section naming two sibling tools and explaining their differences, plus a 'WORKFLOW' section with BEFORE (none) and AFTER (suggesting asterwise_get_nakshatra_prediction). This provides clear when-to-use and when-not-to-use guidance.

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

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?

Adds compute class (FAST_LOOKUP), input/output contracts, and error handling details beyond annotations. Annotations (readOnlyHint, idempotentHint) are consistent.

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 but long; some repetition of output schema info, but no waste.

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 input, output, error handling, workflow, and distinctions from siblings. Complete for a lookup tool with output schema.

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

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

Despite 0% schema coverage, description provides detailed example for 'name' and explains response_format options, fully compensating.

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 scanning letter values and finding absent digits. It distinguishes from siblings like asterwise_get_balance_number and asterwise_get_expression_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?

Provides explicit DO NOT CONFUSE WITH section and WORKFLOW with BEFORE/AFTER, including direct sibling references.

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 annotations: it states that sub-lord chains degrade with unknown birth time, that midnight placeholder yields unreliable results, that ayanamsa choice is not forced locally but mismatched settings post upstream, and that time='00:00' is accepted without warning. These details are not in the annotations and enhance transparency. No contradiction.

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

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.) and front-loads the main purpose. While it is lengthy, the sections are justified by the tool's complexity. It could be slightly more concise, but it earns a 4 for good organization and no 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 (KP chart with sub-lords, multiple parameters, output schema exists), the description is comprehensive. It covers purpose, usage guidelines, behavioral traits, parameter nuances, error contracts, output structure (referencing schema), and sibling differentiation. The presence of an output schema means return values are already documented, and the description complements it well.

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

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

The input schema already provides descriptions for all parameters, including nested fields in 'birth'. The description adds value by explaining that ayanamsa choice is not locally enforced and that time='00:00' is accepted without warning, which are nuances beyond the schema. However, it does not extensively elaborate on all parameters, so a score of 4 is appropriate.

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

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

The description clearly states it builds a KP natal chart with sub-lords, using the KP ayanamsa. It explicitly distinguishes from sibling tools like asterwise_get_natal_chart (classical without sub-lords) and asterwise_get_prashna_chart, satisfying the specific verb+resource requirement and sibling 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: recommends cross-checking birth record before use, suggests following up with asterwise_get_kp_significators, and warns not to confuse with radix or prashna chart tools. It also mentions limitations like unreliable sub-lords with unknown birth time, offering clear when-to-use and when-not-to-use context.

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

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 mark the tool as read-only, idempotent, and non-destructive. The description adds value by detailing: error handling (out-of-range house numbers → MCP INTERNAL_ERROR upstream), compute class (MEDIUM_COMPUTE), and edge cases (filtered output still includes planet_significators for context). This context is 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 long but well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.). The first sentence immediately conveys the core purpose. Every section earns its place given the tool's complexity, though brevity could be slightly improved.

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

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

Given no output schema, the description provides a detailed 'OUTPUT CONTRACT' covering every field and their types. It also includes an 'ERROR CONTRACT' listing possible errors and edge cases. The description fully addresses the tool's purpose, inputs, outputs, workflow, and differentiation, leaving no ambiguity.

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

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

Schema description coverage is low (33%), but the description compensates thoroughly. The 'INPUT CONTRACT' section explains house_number behavior (omit for all, upstream validation for out-of-range), and the 'RESPONSE FORMAT' section elaborates on the two values of response_format. The birth object is already documented in the schema, so no repetition needed.

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

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

The description opens with a specific verb and resource: 'Computes KP significator chains for all houses or one optional house from BirthData.' It clearly distinguishes from sibling tools like asterwise_get_kp_chart and asterwise_get_natal_chart in the 'DO NOT CONFUSE WITH' section, plus notes a recommended workflow dependency on asterwise_get_kp_chart.

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

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

Explicit guidance includes a 'WORKFLOW' section stating (BEFORE: RECOMMENDED — asterwise_get_kp_chart), and a 'DO NOT CONFUSE WITH' section naming alternative tools and their different purposes. The description also clarifies when to omit the optional house_number parameter and mentions upstream validation behavior.

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=true, idempotentHint=true, destructiveHint=false. The description adds substantial behavioral context: compute class MEDIUM_COMPUTE, error contracts (INVALID_PARAMS, INTERNAL_ERROR), edge cases, and notes that Lal Kitab houses differ from cusps. This 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 labeled sections (e.g., 'WHAT THIS TOOL COVERS', 'WORKFLOW', 'OUTPUT CONTRACT'). It is front-loaded with the main purpose. However, it is lengthy and includes extensive output details that could be shortened.

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 (nested objects, output schema present), the description covers workflow, error handling, output format options, and distinctions from similar tools. The output schema is present, so return values are fully documented. 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 description coverage is 50% but the schema itself provides detailed descriptions for most fields inside the 'birth' object. The description does not add additional semantic meaning beyond what the schema already provides, such as clarifying the 'response_format' enum. With high schema coverage, a baseline of 3 is appropriate.

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

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

The description begins with a clear verb and resource: 'Produces the Lal Kitab house and planet schema plus Rin (debt) flags from BirthData using Lal Kitab placement rules.' It distinguishes from siblings like asterwise_get_natal_chart and asterwise_get_lal_kitab_remedies 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 includes a 'WORKFLOW' section stating 'BEFORE: None — standalone for Lal Kitab queries. AFTER: asterwise_get_lal_kitab_remedies.' It also lists similar tools to avoid confusion. However, it does not explicitly state when not to use this tool, which would strengthen 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?

Beyond annotations (readOnlyHint=true, idempotentHint=true, etc.), the description adds extensive behavioral details: it specifies input contract (BirthData only), output contract with field names and types, response format modes (json/markdown with identical data), compute class (MEDIUM_COMPUTE), and a detailed error contract including edge cases (empty remedies). 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.), front-loading the main purpose. Every section adds value, but the length could be slightly reduced without losing clarity. Overall, it is efficient and 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 (nested input, output schema with arrays, response formats, error handling, sibling tools), the description covers all relevant aspects: workflow, output fields, error contracts, and differentiation from similar tools. The output contract is detailed enough for programmatic use, and the presence of an output schema further supports completeness.

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

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

Schema description coverage is 50% (only 'birth' has a top-level description). The description merely states 'BirthData only' in the INPUT CONTRACT, which does not add meaningful detail beyond what the schema already provides for nested parameters. While the schema describes each nested field well, the description does not compensate for the missing top-level description of 'response_format' or provide parameter usage tips.

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-resource pairing: 'Lists Lal Kitab style totkas per stressed planet from BirthData with priority tiers and typed action rows.' It explicitly distinguishes from siblings like asterwise_get_remedies and asterwise_get_gemstone_recommendations in both the 'WHAT THIS TOOL COVERS' section and the 'DO NOT CONFUSE WITH' section, making the tool's specific scope unmistakable.

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

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

The WORKFLOW section explicitly recommends using asterwise_get_lal_kitab_chart before this tool, providing clear context on when to use it. The DO NOT CONFUSE WITH section lists two alternatives with explanations of what they cover (mantra/gem vs. totkas, classical Ratna focus vs. household remedies), giving explicit guidance on when not to use this tool.

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

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 indicate readOnly and idempotent behavior. Description adds context: compute class (FAST_LOOKUP), the fixed nature of the number, timing (becomes dominant after age 35), and error contracts. 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?

Description is well-structured with clear sections (WHAT THIS TOOL COVERS, WORKFLOW, INPUT CONTRACT, etc.) and front-loaded with the core operation. While somewhat lengthy, each section serves a purpose and provides necessary context 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 the presence of annotations and an output schema, the description covers all necessary aspects: purpose, usage, parameter semantics, behavioral notes, error handling, and differentiation from siblings. It is fully adequate for an agent to use the tool correctly.

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

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

Schema has 0% description coverage, but the description's 'INPUT CONTRACT' section provides clear definitions and examples for each parameter (name, date, response_format), compensating fully 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?

Description starts with a clear verb and resource: 'Calculates the Maturity number...' and explicitly differentiates from siblings in 'DO NOT CONFUSE WITH' section, listing asterwise_get_numerology_profile and asterwise_get_personal_cycles.

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 and AFTER recommendations, and a 'DO NOT CONFUSE WITH' section that names specific alternative tools. This gives clear guidance on when to use this tool and when not to.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds important behavioral details: exact match required, no fuzzy matching, error contracts for unknown names (MCP INTERNAL_ERROR), and the compute class (FAST_LOOKUP). There is no contradiction.

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

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

The description is structured into clear sections (e.g., 'SECTION: WHAT THIS TOOL COVERS', 'SECTION: WORKFLOW') and is front-loaded with the purpose. Every section earns its place by providing specific, actionable information 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 the presence of a detailed output schema and annotations, the description covers all necessary context: input constraints, error handling, compute class, and distinctions from sibling tools. It is complete for a complex tool with 27 possible inputs and a rich output structure.

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

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

Although schema coverage is 0%, the description provides extensive semantic meaning for both parameters: nakshatra_name requires exact case-sensitive spelling, and response_format options (json/markdown) are explained with their impact on output structure. This far exceeds the limited schema information.

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+resource: 'Looks up static metadata for one of twenty-seven nakshatras by exact name and returns interpretive, professional, activity, and body-map reference data.' It clearly distinguishes from siblings like asterwise_get_natal_chart and asterwise_get_dasha 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 includes explicit workflow sections ('BEFORE: None', 'AFTER: None') and a 'DO NOT CONFUSE WITH' that lists alternative tools and when to use them instead. It also states that the tool does not compute birth nakshatra from BirthData, which guides the agent to use asterwise_get_natal_chart instead.

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 extensively discloses behavioral details beyond the annotations. It explains the computation logic (Tarabala counting, Chandrabala house analysis, transit nakshatra quality), indicates it is a read-only computation ('MEDIUM_COMPUTE'), and provides no side effects. This complements the readOnlyHint annotation with rich 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 and front-loads the main purpose. However, it is verbose, including details like exact computation steps and output fields that could be inferred from the output schema. This may reduce efficiency for an AI agent looking for quick scanning.

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

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

For a tool with a complex input and output, the description is thorough. It covers input parameters, output structure, compute class, error contracts, and workflow suggestions. The presence of an output schema does not diminish the need for the detailed output contract provided, as it adds descriptions to the fields.

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

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

The input schema has 33% description coverage, but the description's 'INPUT CONTRACT' section adds meaning: it explains that 'birth' is a BirthData object, 'target_date' is optional YYYY-MM-DD defaulting to today, and lists subfields. However, 'response_format' is not mentioned in the input contract, and the description does not elaborate on all parameter details, leaving some burden on 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 'a personalised daily prediction using Tarabala and Chandrabala.' It details the computation components (Tarabala, Chandrabala, transit nakshatra quality) and explicitly distinguishes from three sibling tools 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 includes a 'WORKFLOW' section noting it can be used after 'asterwise_get_panchanga' for full context, and the 'DO NOT CONFUSE WITH' section clearly specifies when to use 'asterwise_get_nakshatra_details', 'asterwise_get_panchanga', or 'asterwise_get_biorhythm' instead.

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.

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