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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by specifying that letters and separators are ignored, that reduction uses numeric digits only, and that the response follows the same harmony schema as mobile analysis. It stops short of summarizing actual error modes beyond linking to the external error contract.

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

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

The description is well structured into WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH, and a documentation link. Each sentence serves a clear purpose, and the most important behavioral details are front-loaded in the opening sentence.

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

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

The description provides invocation context, expected input normalization, sibling-tool disambiguation, a recommended predecessor, and a pointer to the full output and error contract. Since the input schema is fully documented and an output schema exists, the description does not need to restate return values and is complete for an agent selecting and calling this tool.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds value by explaining the input contract for the vehicle_number parameter — letters and separators are stripped and only digits participate in reduction — which is not fully explicit in the individual property descriptions. This complements rather than merely repeats the schema.

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

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

The description uses a specific verb and resource: it strips non-digits from a vehicle registration token, reduces the numeric run with owner name and birth date, and returns a harmony schema. It clearly differentiates itself from asteroids mobile-number checking and business-name analysis, so an agent can identify this tool without opening the schema.

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

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

The WORKFLOW section explicitly recommends running asteroid_get_numerology_profile before this tool and states AFTER: None. The DO NOT CONFUSE WITH section names two siblings and explains why they are not appropriate, which gives an agent concrete guidance on when to choose this tool over alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them. It adds significant context beyond annotations: cryptographic randomness via Python secrets.SystemRandom, per-call independence with no session state, local rejection of out-of-range counts with MCP INVALID_PARAMS, and a 50% per-card reversal chance that is explicitly 'not seeded.'

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

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

The description is front-loaded with the core behavior in the first sentence, then organized into labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) that make it scannable. There is no filler; examples, validation notes, and the docs link all earn their place, and the length is proportionate to the three near-sibling tools it must disambiguate.

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

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

Between the annotations (safe read operation), the output schema, and the docs link for the full output/error contract, nothing an agent needs to invoke this tool correctly is missing. The reminder to interpret drawn cards via active_meaning and active_keywords fields also closes the loop on how results should be consumed.

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

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

With 100% schema description coverage, the schema already documents all three parameters; the description adds strong value with concrete examples (1 daily pull, 3 simple reading, 10 Celtic Cross, 78 full deck), the 1–78 boundary with local validation behavior, and probability mechanics for allow_reversed (50% per card, independent, not seeded). Minor gap: response_format is absent from the INPUT CONTRACT section, though its schema description is thorough.

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

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 — 'Draws N unique random cards from the 78-card deck' — and adds scope-defining traits (unique, cryptographic randomness, no session state). The 'DO NOT CONFUSE WITH' block names the three closest tarot siblings and their distinguishing behavior, so an agent can select this tool without opening their schemas.

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

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

Explicitly states the tool is standalone with no prerequisites or follow-up ('BEFORE: None', 'AFTER: None'). The 'DO NOT CONFUSE WITH' section names asterwise_get_tarot_card_of_the_day, asterwise_get_tarot_three_card_spread, and asterwise_get_tarot_celtic_cross with the precise differences (deterministic vs positional vs random), leaving no ambiguity about when this tool is the right choice.

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

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

The description includes 'WORKFLOW: BEFORE: None — standalone. AFTER: None.' which clarifies no side effects, complementing the annotations (readOnlyHint, idempotentHint, destructiveHint). It also states the output format parameter, so the agent knows it produces markdown or JSON.

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

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

The description is well-structured with clear sections (purpose, supported, workflow, input contract, disambiguation) and each section serves a necessary role. It is detailed but not redundant, and the formatting makes it easy to parse.

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

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

Given the large number of sibling tools, the description provides complete context: purpose, supported inputs, disambiguation from relevant alternatives, workflow, input contract, and a link to full output/error docs. It also indicates the output options via the response_format parameter.

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

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

Both parameters are fully described in the schema: 'number' as the angel number sequence with examples, and 'response_format' with enum and default. The description's 'INPUT CONTRACT' section reinforces the meaning with examples, going beyond the schema.

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

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

The description clearly states the tool's purpose: 'Lookup the meaning of a specific angel number by its sequence.' It also specifies supported sequences and explicitly names sibling tools to avoid confusion (asterwise_get_angel_number_today, asterwise_get_angel_number_personal, asterwise_get_number_meaning).

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

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

The description explicitly provides usage guidance through the 'DO NOT CONFUSE WITH' section, listing specific alternatives and explaining the difference (e.g., today's daily number, personal number from birth date, Pythagorean numerology). This tells the agent exactly when to use this tool vs alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds a linked 'Full output and error contract' and mentions a default behavior for date ('Defaults to today when omitted'), providing additional transparency beyond the annotations without contradicting them.

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

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

Structured with clear headings (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and a concise link to full docs. Each section is purposeful, though it repeats some schema-level parameter descriptions and includes a long sibling list in context; the description itself is efficient without fluff.

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

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

Provides the mapping logic, a recommended prerequisite, explicit disambiguation from nearest siblings, and a link to the full output/error contract. Since an output schema exists (per context), return values need not be explained. The description is complete enough for an agent to decide to call it and to anticipate its behavior.

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

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

Schema description coverage is 100% (per context signals), so baseline is 3. The tool description repeats the date and name parameters with a concrete example for date, but does not add substantially new semantics beyond what the schema already provides. The response_format parameter is not mentioned in the main description, though it is covered in the schema.

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

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

States a specific verb ('Computes') and resource ('personal angel number') with a clear method (Pythagorean Life Path). Explicitly distinguishes from siblings in the 'DO NOT CONFUSE WITH' section, naming asterwise_get_angel_number_today and asterwise_get_numerology_profile, so an agent can select it correctly without opening their schemas.

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

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

Provides a recommended prerequisite workflow ('BEFORE: RECOMMENDED — asterwise_get_numerology_profile — confirm Life Path before calling') and explicit alternatives to avoid confusion, covering when to use and when not to use this tool. This fully addresses the 'when vs alternatives' guidance.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the description doesn't need to restate that. It adds valuable context by explaining the computational method (date digits summed and reduced to a single digit, then tripled) and offering a link to the full output/error contract, which covers any missing edge-case details.

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

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

The description is well-structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and is front-loaded with the primary purpose. It is slightly lengthy due to the distinctions and workflow notes, but every sentence serves a purpose, and the included docs link consolidates additional details.

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

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

Given the tool's simplicity (no required params, read-only), the description is complete: it explains what it does, how it computed, when to use it vs. alternatives, and provides a docs link for errors/output. It doesn't explicitly mention response formats, but the schema already covers that, and the workflow note clarifies its standalone nature.

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

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

The schema description covers the single optional parameter (response_format) with enum and default, achieving 100% coverage. The description adds context that no required parameters exist and that the date is automatically derived, but this relates to operational behavior rather than enhancing parameter understanding beyond the schema.

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

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

The description clearly states that the tool returns today's angel number computed from the current date, with a specific algorithm (sum and reduce digits). It explicitly distinguishes itself from sibling tools via the 'DO NOT CONFUSE WITH' section, naming asterwise_get_angel_number and asterwise_get_angel_number_personal and their purposes.

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

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

Usage guidance is explicit: the 'WORKFLOW' section states it is standalone and suggests when to use the personal angel number tool afterward. The 'DO NOT CONFUSE WITH' section clarifies when to use alternative tools (specific number lookup vs. personalized from birth date), leaving no ambiguity about selection.

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

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

Annotations already provide strong safety cues: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds useful behavioral context beyond those: it is a standalone reference with no BEFORE/AFTER workflow dependencies, and it defaults the date to today. It also links to the full output and error contract, which covers any remaining behavioral details.

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

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

The description is well structured and front-loaded: the core behavior appears in the first sentence, followed by compact WORKFLOW, INPUT CONTRACT, and confusion-avoidance sections. Every section earns its place and the whole thing is easy for an agent to scan.

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

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

For a simple two-parameter read-only tool with full schema coverage, an output schema, and rich annotations, the description is complete. It covers date format, default behavior, supported systems, sibling alternatives, and points to the full output/error contract.

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

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

Schema description coverage is 100%, so the input schema already documents both date and response_format fully. The description reiterates the date default but does not add meaningfully beyond the schema. Baseline 3 is appropriate because the schema carries the parameter semantics burden.

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

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

The description states a specific verb with a resource: 'Returns ayanamsha values for all four supported systems (Lahiri, Raman, KP, Tropical) for a given date.' It is clearly distinct from sibling tools, and it even names the two most likely confusable alternatives and what they do differently.

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

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

The description explicitly provides a 'DO NOT CONFUSE WITH' section, naming asterwise_get_natal_chart and asterwise_get_westen_natal and explaining when each should be used instead. This gives concrete routing guidance beyond simply defining the tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description does not add extra context about side effects, permissions, or rate limits, but it is consistent with the annotations.

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

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

The description is well-organized with clear sections (purpose, workflow, input contract, do-not-confuse) and is free of unnecessary verbosity. Every sentence adds value.

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

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

Includes algorithm, worked examples, output format options, and differentiation from related tools. An agent has everything needed to invoke this tool correctly without further clarification.

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

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

Both parameters are fully described in the schema with types, defaults, and enums. The description adds the algorithm and concrete examples, providing rich semantic detail beyond the schema.

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

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, with explicit examples. It distinguishes itself from expression number and karmic lessons, making its purpose unmistakable.

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

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 that explicitly names sibling tools and clarifies when not to use them. It also covers output format options, giving clear usage direction.

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

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

The description adds some behavioral context beyond the annotations by stating it is 'standalone' and has a specific workflow after it, which is not covered by the readOnly or idempotent hints. However, it does not explicitly mention side effects or permissions, though the annotations already cover these (readOnlyHint true, destructiveHint false). Overall, it adds moderate context without contradicting the annotations.

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

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

The description is structured into clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and is not overly long. However, the INPUT CONTRACT section repeats information already present in the schema, introducing slight redundancy. The front-loaded first sentence is effective, and the overall structure is easy to follow.

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

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

Given the moderate complexity (4 parameters, 1 enum, output schema exists), the description covers the core purpose, usage, and differentiators. It points to a URL for the full output and error contract, which addresses potential omissions. It does not describe the output structure in detail, but the link compensates. Overall, it is sufficiently complete for an agent to decide and invoke the tool correctly.

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

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

The schema already covers 100% of the parameter descriptions, giving a baseline of 3. The description adds the range constraint for 'days' (1-90) and clarifies the default behavior for 'target_date' ('Defaults to today'), which is not fully specified in the schema. This additional context improves understanding beyond the schema alone.

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

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

The description clearly states that the tool computes physical, emotional, and intellectual biorhythm cycles for a birth date. It also explicitly distinguishes itself from related tools via the 'DO NOT CONFUSE WITH' section, naming asterwise_get_nakshatra_prediction and asterwise_get_panchanga. This provides both a specific verb and resource, and clear differentiation.

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

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

The description provides explicit workflow guidance: 'BEFORE: None' and 'AFTER: asterwise_get_nakshatra_prediction', indicating where this tool fits in a sequence. It also tells the agent when not to use this tool (i.e., for Vedic daily predictions or panchanga elements), making the selection criteria very clear.

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

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

Annotations already disclose read-only, idempotent, and non-destructive behavior. The description adds a behavioral note that inputs are forwarded as-is without local validation, which goes beyond the annotations. It does not contradict any annotations.

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

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

The description is concise and well-structured, with separate sections for workflow, input contract, and do-not-confuse guidance. Every sentence adds value—there is no fluff or redundant information. The structure makes it easy to scan and understand.

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

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

Given the annotations, schema, and the provided URL for the full output/error contract, the description offers sufficient context for an agent to understand what the tool does, what inputs it expects, and how it relates to sibling tools. The output format is partially described (themes and keywords) and response_format parameter covers the rest.

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

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

The schema covers 100% of parameters with descriptions for name, date, and response_format, including an enum and default. The description reinforces that name and date are used as-is, adding a small semantic nuance beyond the schema. No parameter is left unexplained.

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

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 using the Chaldean system and returns analyses with themes and keywords. It distinguishes itself from similar tools by explicitly naming the Chaldean approach and contrasting with Pythagorean and Lo Shu methods, making the purpose unambiguous.

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

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

The description provides explicit usage guidance through the 'DO NOT CONFUSE WITH' section, naming alternatives and when not to use them (e.g., Pythagorean profile, Lo Shu grid). The AFTER workflow also suggests comparing with the Pythagorean profile when needed, giving clear direction on when to use this tool versus related ones.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, which cover the tool's safety profile. The description does not contradict these annotations and adds no behavioral details beyond what annotations provide, so a neutral score is appropriate.

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

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

The description is well-structured with clear sections for workflow, input contract, and confusion avoidance. It is a bit verbose but remains organized and easy to follow. The length is justified by the additional clarifying information.

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

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

The description omits any explanation of the 'response_format' parameter, which is present in the schema. Additionally, the schema description for 'name' is incorrect and does not match the purpose or the INPUT CONTRACT. These gaps hinder an agent from fully understanding the tool's inputs and usage context.

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

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

The schema description for the 'name' parameter is completely mismatched: it says 'Person's full name as commonly written; letters are converted to numerology values', which contradicts the tool's purpose of looking up a crystal. Although the description text's INPUT CONTRACT correctly states 'crystal slug or display name', the schema description itself is misleading and would cause an agent to misuse the parameter.

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

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

The description clearly states the tool looks up a specific crystal by slug or name and returns full details including planetary assignments, healing properties, and safety cautions. It also explicitly distinguishes itself from sibling tools via the 'DO NOT CONFUSE WITH' section, listing alternative crystal-related tools.

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

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 by listing asterwise_get_crystals, asterwise_get_crystal_by_planet, and asterwise_get_gemstone_recommendations as distinct options. It also mentions that this tool can be used standalone or after another tool, giving contextual usage direction.

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

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

Annotations already cover readOnly and idempotent hints, so the description does not need to repeat those. It adds behavioral context by stating the sorting logic and offering a response_format parameter, which clarifies output behavior beyond the schema. The output/error contract link provides additional transparency, though no direct side-effect details are needed given the annotations.

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

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

The description is well-structured with clear sections (workflow, input contract, do-not-confuse, output contract). Though somewhat lengthy, every sentence contributes useful information—no fluff. The main recommendation statement is concise, and the additional sections are organized logically.

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

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

Provides sufficient context for correct invocation: required filters, output format options, and a link to the full output/error contract. Although the actual output schema is not embedded, the description's mention of markdown/json and the contract URL mitigate the gap. It also clarifies relationships with sibling tools, making the tool's role well-defined.

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

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

Schema description coverage is 100%, so baseline is 3. The description enhances this by listing allowed chakra values (Root, Sacral, Solar Plexus, etc.) which are not in the schema enum, and providing concrete examples for intention (protection, abundance, love) and zodiac_sign. It also clarifies the limit default/max, aligning with schema but adding context.

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

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

Clearly states the verb 'Recommends' and the resource 'crystals', with specific criteria (zodiac sign, chakra, intention). The 'DO NOT CONFUSE WITH' section explicitly differentiates from sibling tools like asterwise_get_crystal_by_planet and asterwise_get_gemstone_recommendations, making its purpose unambiguous.

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

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

Explicitly states the requirement 'At least one filter is required' and describes the ordering behavior ('matches the most criteria first'). The workflow mentions 'AFTER: asterwise_get_crystal' for subsequent detail retrieval, and the 'DO NOT CONFUSE WITH' lines provide clear when-to-use guidance against alternatives.

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

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

The annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful runtime behavior, such as the sunrise-chart fallback when time is omitted and the 'never pass 00:00' warning. It does not discuss rate limits or auth, but the annotations cover the core behavioral traits.

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

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

The description is well-structured with clear headings and each section serves a distinct purpose: purpose, workflow, input contract, and disambiguation. Despite being detailed, it avoids redundant prose and stays focused on actionable guidance.

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

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

The description provides enough context for an agent to decide when to use this tool, what inputs to provide, what defaults apply, and how it differs from closely related crystal and gemstone tools. It also includes a link to the full output/error contract and implies key output fields like match_score and match_reasons.

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

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

All schema parameters are described, including nested birth fields like lat/lon with ranges, time with format and special unknown-value semantics, ayanamsa enum meanings, timezone default, and response_format. The description adds practical examples and clarifies edge cases.

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

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

The description states a specific action: recommends crystals from a Vedic natal chart using house lordship rules. It also explicitly distinguishes this from zodiac/chakra-based matching, making the tool's purpose unambiguous.

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

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

The description provides a clear workflow with BEFORE/AFTER steps, input contract details, defaults, and a dedicated 'DO NOT CONFUSE WITH' section that differentiates it from several sibling tools. It also links to the full output and error contract.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context: sorted alphabetically, full content list, and a link to the error contract. No contradiction with annotations.

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

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

The description is structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and front-loads the primary purpose. While slightly verbose, every section adds value and is well-organized.

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

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

With an output schema present and annotations covering safety, the description is fully complete. It explains the output contents, workflow, alternatives, and provides a documentation link for errors. Nothing an agent needs to call it correctly is missing.

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

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

The only parameter response_format is fully documented in the schema with enum and description. Schema coverage is 100%, so the baseline is 3. The description does not mention the parameter, but it doesn't need to since the schema covers it.

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

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

The description clearly states the tool returns all 50 crystals sorted alphabetically, with a detailed list of what each entry includes. It distinguishes itself from siblings via the DO NOT CONFUSE WITH section, naming asterwise_get_crystal, asterwise_get_crystal_by_planet, and asterwise_get_crystal_recommendations with their purposes.

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

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

Explicit WORKFLOW section states no prerequisites and names the AFTER tool for filtering by Vedic planet. The DO NOT CONFUSE WITH section explicitly lists alternative tools and their distinct purposes, leaving no ambiguity about when to use this tool versus others.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral details such as case-insensitive lookup, standalone execution, and the dual-tradition output, which go beyond the annotations without contradicting them.

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

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

The description is well-structured with clear sections for workflow, input contract, and sibling-tool distinction. It stays concise while front-loading the core purpose, and the documentation link avoids unnecessary verbosity.

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

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

The description provides workflow context, example inputs, a contrast with the sibling tool, and a link to the full output/error contract. It lacks explicit output field details here, but the documentation link and output-schema indication make it sufficient for this read-only lookup.

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

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

The input schema's description for 'name' is semantically wrong, describing a person's full name for numerology instead of a dream symbol slug or display name. The surrounding INPUT CONTRACT and examples partially correct this, and response_format is well described, but one of the two parameters is actively misleading.

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

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

The description opens with a specific verb ('Lookup'), a specific resource ('dream symbol'), and a clear scope ('by slug or name, case-insensitive'). It also explicitly distinguishes itself from asterwise_get_dream_symbols, making its purpose unambiguous.

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

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

The 'DO NOT CONFUSE WITH' note directly tells the agent when to use this tool versus the full listing tool, and the WORKFLOW section states it is standalone with no prerequisites. Example inputs further clarify the expected name values.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds meaningful beyond the annotations: it discloses the Goodwin/Balliett per-part method, explains why master numbers are preserved, and clarifies that name parts are reduced separately before summing. It also points to the output/error contract URL, adding behavioral context beyond what annotations and schema convey.

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

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

Organized with clear labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and front-loads the core calculation method in the first sentence. Every section earns its place and the length is appropriate for a tool that needs to distinguish itself among many sibling numerology tools.

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

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

Given the output schema exists, the description does not need to explain return values. It covers the calculation method, input requirements, workflow position, sibling distinctions, and error/out contract via a link. There is no missing information that would prevent an agent from selecting and invoking this tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds genuine value for the name parameter: full legal name as used at birth, space-separated parts, any case allowed, and a minimum one alphabaetic character constraint. It does not diacuss response_format, but the schema already fully documents that enum and default.

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

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

States the specific operation: calculates the Expression/Destiny number from a full name using Pythagorean letter values, with concrete method details (per-part reduction, master number preservation). It also explicitly differentiates itself from sibling numerology tools, so an agent can immediately identify what this tool uniquely does.

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

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

Provides an explicit WORKFLOW section stating it is standalone and names the natural after-step (soul_urge_number). Also has a dedicated DO NOT CONFUSE WITH section listing four sibling tools and the exact condition that makes them alternatives, which is ideal guidance for tool selection.

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

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

The annotations already establish read-only, idempotent, non-destructive behavior, so the description does not need to repeat that. It adds genuine behavioral context: the tool outputs exactly 20 festivals, covers solar and tithi-based events, is standalone, and links to the full output/error contract. It does not discuss rate limits or error specifics, but those are partially covered by the annotations and the linked contract.

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

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

Front-loads the core behavior and then uses labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) that make the definition easy to scan. Every section carries operational information, and the docs link replaces a long enumeration of error cases. There is no filler or tautology.

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

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

For a 6-parameter tool with one required field and an output schema, the description supplies the input contract, required-or-alternative parameter groups, output scope, workflow, sibling disambiguation, and a link to the full output/error contract. An agent has everything needed to decide when to use this tool and how to invoke it correctly.

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

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

Schema coverage is 100%, which sets the baseline at 3. The description earns additional credit by adding the year range 1900-2100 that the schema omits and by clarifying the mutually exclusive input groups: either location OR latitude + longitude + timezone. These are non-obvious constraints an agent must know to call the tool correctly.

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

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

Opens with a specific verb and resource: 'Computes all major Hindu festival dates for a given year and location.' It enumerates exactly what is returned (20 pan-Hindu festivals, including solar sankrantis and tithi-based festivals) and later disambiguates from sibling tools, so an agent can tell it apart from asterwise_get_panchanga_calendar and asterwise_get_muhurta.

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

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

Provides an explicit WORKFLOW section stating no prerequisites and identifying the natural next call (asterwise_get_panchanga). It also includes a DO NOT CONFUSE WITH section naming two siblings and the exact conditions that select them: full Panchanga per day vs festival-specific, and auspicious activity windows vs festival calendar. This is exceptionally clear usage guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context by specifying that the tool computes from the natal chart, returns a structured set of categories including contraindications and safety notes, and advises confirming the chart before wearing advice. It does not add details on auth or rate limits, but this is not central for a read-only computation tool.

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

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

The main purpose sentence is front-loaded and is followed by compact, labelled sections for workflow, input contract, and exclusions. Each section adds decision-relevant value, and the docs link is a useful escape hatch rather than bloat.

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

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

For a complex tool with an output schema, nested birth object, and safety annotations, the description covers the purpose, the output categories, the necessary workflow, and the alternatives to avoid. There is also a link to the full output and error contract, so an agent can resolve any remaining uncertainty. Nothing critical is missing.

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

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 birth and response_format. The description only adds 'BirthData follows the global contract', which adds little beyond the schema. Baseline 3 is appropriate because the schema carries the heavy lifting.

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

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

The description uses a specific verb ('Computes'), names the exact resource ('Ratna-style gemstone picks and cautions from the natal chart'), and enumerates the outputs (primary stones, role-based stones, secondary options, contraindications, safety note). It clearly separates itself from sibling remedy tools in the DO NOT CONFUSE section, making tool selection unambiguous.

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

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

The WORKFLOW section explicitly tells the agent to run asterwise_get_natal_chart BEFORE and asterwise_get_remedies AFTER, and the DO NOT CONFUSE section names alternatives and explains what they are not. This is explicit when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations: it clarifies that Moon sign is computed from birth data, that no prior setup is needed, and that the result is a static lookup rather than a daily score. It also links to the full output and error contract.

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

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

The description is organized into labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE) with the core purpose front-loaded. Each section adds distinct value, and the documentation link is compact. There is no filler or repetition of schema details.

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

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

For a read-only lookup with a full input schema, an output schema, and safety annotations, the description covers prerequisites, follow-up usage, sibling disambiguation, and points to the full output/error contract. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by stating that the birth object is the sole input and that Moon sign is derived from it, which is not explicit in the schema. The INPUT CONTRACT also summarizes the relevant birth fields (date, time, lat, lon, timezone).

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

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

States a specific verb ('Returns'), a specific resource ('four Ghatak (inauspicious) timing parameters'), and the basis ('Janma Rasi (natal Moon sign)'). The DO NOT CONFUSE section explicitly separates it from asterwise_get_nakshatra_prediction and asterwise_get_panchanga, so an agent can distinguish it from siblings.

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

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

The WORKFLOW section explicitly states no prerequisites ('BEFORE: None') and recommends a follow-up tool ('AFTER: asterwise_get_nakshatra_prediction') for daily auspiciousness. DO NOT CONFUSE names two alternatives and explains why they differ, giving clear when-to-use guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety and side-effect transparency. The description is consistent with these annotations—'Builds' implies generating calculations without modifying any stored state. No contradiction.

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

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

The description is well-organized with clear headers (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) and stays focused. It is slightly longer than necessary but every section adds value, especially the disambiguation from siblings.

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

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

The description explains the core purpose and output tags, but it fails to resolve the location parameter conflict and does not clarify how the date/timezone/lat/lon interplay works. The response_format field is referenced only in the schema, not explained. Overall, enough for basic use but gaps remain due to the location ambiguity.

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

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

The location parameter description says 'Place name, e.g. 'Chennai, India'. Alternative to giving latitude, longitude and timezone.' but the schema requires lat, lon, and date as required properties within an object. This directly conflicts—an agent would be confused whether to pass a string or an object. The individual field descriptions are clear, but the top-level parameter semantics are misleading.

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

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

The description clearly states the specific verb 'Builds', the resource 'twenty-four planetary Horas', the scope 'between successive sunrises for a location date', and the output details (ruler, quality text, current status). It also differentiates from sibling tools like choghadiya and natal chart.

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

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

The WORKFLOW section explicitly says it is standalone and points to asterwise_get_choghadiya as an alternative same-day slot system. The DO NOT CONFUSE WITH section clearly distinguishes Horas from choghadiya (16 vs 24 segments) and natal chart, giving agents clear selection criteria.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior; the description adds that this is an AI-synthesised editorial horoscope, returns structured guidance fields plus model/period metadata, and that response_format only controls rendering between markdown and JSON. It also references a full output/error contract URL, providing meaningful behavior beyond the annotations.

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

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

The description is longer than minimal, but every section earns its place: purpose, workflow, input contract, disambiguation, and documentation link. The structure is clear and front-loaded with the core purpose before supporting details, making it efficient despite its length.

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

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

Given the output schema exists, the description appropriately focuses on selection, input constraints, disambiguation, and the contract URL for full output/error details. It covers before/after workflow and alternatives, so an agent has everything necessary to invoke the tool correctly in context.

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

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

Schema coverage is 100%, so the baseline is already strong, but the description adds genuine value by expanding moon_sign to include Sanskrit and English rashi names, clarifying that period is constrained to the schema enum, and specifying that response_format only selects rendering mode. This helps an agent understand valid inputs beyond the basic schema descriptions.

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

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

States a clear, specific action: fetches an AI-synthesised Moon-sign horoscope for a chosen horizon, and distinguishes the resource and deliverable from sibling tools. The 'DO NOT CONFUSE WITH' section explicitly contrasts it with asterwise_get_natal_chart and asterwise_get_gochar, so an agent can select it correctly.

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

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

Provides explicit when-to-use guidance via WORKFLOW and DO NOT CONFUSE sections, naming the exact sibling tools and their purposes. It also notes that a personalized chart should use asterwise_get_natal_chart, giving clear exclusion criteria.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds transparency about error handling by linking to a full output and error contract, and it explains the computation process (scanning letters, converting to values). No contradictions with annotations.

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

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

The description is longer than average but well-structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH). The example inside INPUT CONTRACT repeats some information from the opening sentence, but the overall organization aids readability and avoids being unnecessarily verbose.

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

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

Given that an output schema is reported as present (context signal), the description does not need to explain return values. It does point to a full output and error contract URL for additional details, and the workflow section places the tool in a broader context. This is sufficient for an agent to invoke it correctly.

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

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

Schema descriptions cover both parameters with 100% coverage, so the baseline is 3. The main description goes further by providing a concrete example ('Arjun Mehta') that illustrates how the name is processed, which adds practical semantic clarity beyond the schema text. The response_format enum is also clearly documented.

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

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

The description clearly states the tool's specific function: identifies karmic lessons by scanning all letter values in a full name and finding missing digits 1–9. It explicitly distinguishes from sibling tools by noting that balance number uses only first initials and expression number reduces to a single digit, preventing confusion.

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

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

The description provides explicit when-to-use context via the workflow section (standalone, before numerology profile) and a 'DO NOT CONFUSE WITH' section that names specific alternatives and explains the exact differences (initials vs all letters, reduced vs absent digits). This gives clear guidance on selecting this tool over related options.

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

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

The annotations already declare readOnly, idempotent, non-destructive, and openWorld=false. The description adds that it is standalone and that input is validated upstream, providing a small amount of extra context about side effects and error handling. However, the description does not elaborate on output behavior or error responses, so the added transparency is modest.

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

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

The description is well-structured with clear sections (description, workflow, input contract, do-not-confuse, link). The main functionality is stated in one concise sentence, and the additional sections are brief and purposeful. It is slightly longer due to the exclusions, but remains efficient overall.

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

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

The description mentions the key outputs (planes, missing/repeated digits, per-digit traits) and provides a link to the full output and error contract. However, the output schema is not included in the prompt, and the description does not explain the output structure beyond those annotations, nor does it elaborate on error cases. The link helps but is not directly accessible.

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

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

The schema states 'date' is required, but the description says 'Defaults to today when omitted' – a direct contradiction. Additionally, the 'INPUT CONTRACT' line says 'date string only' while the schema includes a second parameter, response_format. This inconsistency and omission undermine the clarity of the two parameters, despite the schema descriptions being otherwise clear.

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

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

The description clearly states the tool's function: deriving a Lo Shu three-by-three frequency grid from birth-date digits and annotating planes, missing/repeated digits, and per-digit traits. It also explicitly distinguishes itself from two similar siblings (numerology profile and name correction) by contrasting letter-based vs digit-based methods, making its purpose unmistakable.

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

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

The 'DO NOT CONFUSE WITH' section gives explicit when-not-to-use guidance for two closely related tools (numerology profile and name correction), and the workflow section notes it is standalone. This helps an agent select the correct tool among many siblings, though it does not exhaustively list all alternative cases.

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

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

Annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds useful context beyond those annotations by noting the payload is 'condensed', that inputs are forwarded upstream without local checks, and by linking to the full output/error contract. This is meaningful additional transparency, though not exhaustive.

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

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

The description is well-structured with labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) that each add distinct value. The main purpose is front-loaded in the first sentence, and there is no filler or redundant restating of schema details.

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

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

The description is complete for a tool of this complexity: it explains the standalone workflow, the follow-up path, sibling disambiguation, input forwarding behavior, and provides an external contract link. An output schema exists, so return-value details are already covered, and the annotations handle the safety profile. Nothing essential is missing.

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

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

Schema coverage is 100%, so the schema already documents all three parameters with descriptions. The description adds only generic context ('name and birth date') and does not meaningfully enrich the parameter semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description opens with a specific verb ('Fetches') and clearly defines the resource: condensed lucky-number guidance for a name and birth date. It enumerates the payload contents (primary/secondary picks, power number, interpretation, date_specific flag), and explicitly distinguishes the tool from likely siblings.

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

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

The WORKFLOW section states that this tool is standalone and points to asterwise_get_numerology_profile as the follow-up when deeper context is needed. The DO NOT CONFUSE WITH section names two alternatives and explains exactly why they are not the same, giving clear when-to-use and when-not-to-use guidance.

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

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

The annotations (readOnlyHint, idempotentHint, destructiveHint) already cover the key behavioral aspects, and the description is consistent with them. The description adds some context about the calculation process but does not introduce any contradictions, so it slightly adds value beyond the annotations.

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

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

The description is well-structured with clear sections for workflow, input contract, and distinctions, but it duplicates some information already present in the schema (e.g., the input contract). It is not overly verbose and provides necessary guidance, though it could be slightly more concise.

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

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

The description provides sufficient context about the tool's purpose and its relationship to other numerology tools, but the ambiguity around the required/optional nature of the 'date' parameter could lead to misuse. Given the complexity and many sibling tools, this is a notable gap that reduces completeness.

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

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

Although the schema covers all three parameters with descriptions, there is an internal inconsistency: the 'date' parameter's description states it 'Defaults to today when omitted' while the required array lists it as required. This ambiguity is not resolved in the main description, creating confusion about whether the date must be supplied.

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

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

The description clearly states that the tool calculates the Maturity number, which is the sum of Life Path and Expression numbers, and explains its meaning. It distinguishes itself from similar numerology tools like asterwise_get_numerology_profile and asterwise_get_personal_cycles, providing explicit differentiation.

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

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

The description includes a 'WORKFLOW' section that recommends running asterwise_get_numerology_profile first to confirm Life Path and Expression numbers, and a 'DO NOT CONFUSE WITH' section that clarifies differences from two other tools. This gives explicit guidance on when and how to use the tool relative to alternatives.

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

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

Annotations already declare the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description's job is to add what they don't cover. It does: the tool is standalone, activity values are not validated locally with bad slugs surfacing as MCP INTERNAL_ERROR, and from_date/to_date ordering plus span rules are enforced upstream. It also links the full output/error contract, covering the remaining behavioral surface.

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

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

The purpose is front-loaded in the first sentence, then the rest is organized into terse, clearly labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) plus a single docs link. Every section carries distinct, decision-relevant information with no filler; the only minor wart is the slightly ambiguous 'slugs above' reference.

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

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

For a tool with 4 required parameters, a nested location object, and an existing output schema, the description covers the essential decision surface: purpose, standalone workflow, follow-up step, parameter error behavior, and sibling disambiguation. The unenumerated activity slug list and unspecified span rules are the only real gaps, and both are mitigated by the docs link and schema examples.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description pushes above it by adding error and validation semantics: activity must match a supported English slug and is not validated locally, and date-ordering/span rules are enforced upstream. The main shortfall is that the supported slugs are referenced ('above') rather than enumerated, leaving the agent to infer them from schema examples.

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

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

The opening sentence names a specific verb ('Searches'), a distinct resource (a date span for top-scoring muhurta windows for a named activity), the astrological inputs (Panchanga, Choghadiya, classical siddhi flags), and a location. The 'DO NOT CONFUSE WITH' block explicitly differentiates it from asterwise_get_choghadiya and asterwise_get_panchanga, so an agent can identify this tool without opening any schema.

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

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

The WORKFLOW section states the tool is standalone (no BEFORE prerequisite) and names asterwise_get_panchanga as the AFTER step for drilling into limb detail, giving explicit sequential guidance. The 'DO NOT CONFUSE WITH' section names both confusable siblings and states the discriminating conditions — single-day enumeration without activity scoring (choghadiya) versus unranked single-day limb detail (panchanga) — which effectively tells the agent when this tool is the right choice.

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

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

Annotations already mark it read-only and non-destructive; the description adds that it computes from birth data and points to a full output/error contract. No contradictions with the annotations.

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

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

The description is well structured with WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE, and a link to the full contract. Purpose is front-loaded; some repetition with the schema exists but it is not excessive.

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

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

The description covers purpose, workflow, key input defaults, sibling distinctions, and directs users to the full output/error contract. Since an output schema exists, detailed return-value explanation is not required.

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

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

Schema coverage is 100% and every parameter already has descriptions, defaults, formats, and enums. The prose input contract mostly restates the schema and omits response_format and ayanamsa, so it adds little beyond what the schema provides.

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

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

Description opens with 'Returns a personalised daily prediction using Tarabala and Chandrabala', giving a specific verb, resource, and method. It also explicitly names sibling tools not to confuse with, making its scope unmistakable.

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

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

The description provides explicit when-not-to-use guidance via 'DO NOT CONFUSE WITH' for nakshatra_details, panchanga, and biorhythm, and adds a workflow note that panchanga should follow for full daily context. This clearly distinguishes it from alternatives.

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

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

Annotations already disclose readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description does not need to repeat these. The description adds useful context like 'upstream validates' and 'echoes recommendation stub fields,' which aligns with a non-modifying operation. No contradictions exist between the description and annotations, and the description does not introduce any misleading side-effect claims. However, it does not explicitly describe potential errors or rate limits, but annotations reduce the burden.

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

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

The description is compact and well-organized, using clear section headers (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) to separate purpose, prerequisites, and disambiguation. It front-loads the primary purpose in the first sentence and avoids redundant elaboration. The inclusion of a link to the full output/error contract keeps the description concise while providing access to deeper details. It is slightly verbose with multiple sections, but each contributes to usability.

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

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

The description is complete for an agent to understand the tool's role within the larger context of sibling tools. It provides workflow context (recommended predecessor), clarifies boundaries versus similar tools, and points to a full output/error contract. Since an output schema is indicated (has output schema: true), the description does not need to enumerate return fields; however, the phrase 'echoes recommendation stub fields' is somewhat ambiguous and could benefit from a brief explanation, but the link covers details.

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

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

Schema description coverage is 100% for all three parameters (name, date, response_format), each with detailed descriptions. The description merely restates the schema constraints ('name and date strings only; upstream validates') without adding additional meaning beyond what is already in the input schema. For example, the schema already explains that name letters are converted to numerology values and that date defaults to today. Since coverage is high and the description does not introduce new semantics, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Scores the current spelling of a personal name against the birth-date Life Path, suggests alternate spellings with harmony metrics, and echoes recommendation stub fields.' This provides a specific verb (scores, suggests, echoes), a specific resource (personal name, birth-date Life Path), and distinguishes it from related tools via the 'DO NOT CONFUSE WITH' section (e.g., business_name_analysis for entities, chaldean_numerology for Chaldean compounds).

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

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

The description gives explicit when-to-use guidance by naming sibling tools and contrasting them: 'DO NOT CONFUSE WITH: asterwise_get_business_name_analysis — entity Expression scan, not personal spelling alternatives; asterwise_get_chaldean_numerology — Chaldean compounds, not harmony-scored spelling list.' It also specifies a recommended preceding workflow: 'BEFORE: RECOMMENDED — asterwise_get_numerology_profile — baseline numbers before renaming advice.' This tells an agent exactly when to use this tool and when to choose alternatives.

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

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

Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds valuable behavioral context: the four strings are passed through without local guards, and a sanity-check workflow is advised, plus a link to the full output/error contract. It stops short of detailing error cases but the external contract covers that.

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

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

The description is tightly organized into first-sentence summary, WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH, and a docs link. Every section earns its place and there is no filler or repetition of schema details.

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

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

With output schema present, annotations covering safety, and a description that includes workflow prerequisites, input caveats, sibling distinctions, and an external contract link, the agent has everything needed to select and invoke this tool correctly.

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

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

Schema coverage is 100%, so the schema already documents formats for the four name/date parameters. The description adds meaning by clarifying that all four strings pass through without local guards and that the Life Paths are derived from names and birth dates. It also signals the response_format enum through the JSON/markdown phrasing in the schema without needing duplication.

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

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

The first sentence states the specific action, 'Compares two people on Pythagorean Life Path numbers' and lists the returned artifacts: score, tier, narrative, strengths, challenges, advice. It clearly difers from siblings by naming what it is not. This exceeds basic clarity.

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

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

The WORKFLOW section explicitly recommends calling asterwise_get_numerology_profile per person before comparing, and the DO NOT CONFUSE WITH section names the two nearest alernatives and their distinguishing conditions. This gives an agent concrete routing guidance beyond mere inference.

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

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds useful context about validation failures ('malformed payloads fail upstream') and points to a full error contract via URL, going beyond the annotation baseline without contradiction.

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

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

The description is well-structured with clear sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE), but it is longer than necessary and repeats some schema content (e.g., date format). It earns a 4 for organization and clarity despite minor redundancy.

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

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

Fully situates the tool within a large numerological suite by distinguishing it from similar tools, documents its output components, and provides a link to the complete documentation and error contract. An agent has enough context to select and invoke it correctly without ambiguity.

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

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

Schema descriptions cover 100% of parameters with clear meaning (date format, name conversion, response_format enum). The description itself does not add extra parameter-specific details beyond the schema, so it stays at the baseline warranted by full schema coverage.

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

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

States a specific verb ('Builds'), resource ('Pythagorean numerology profile'), inputs ('legal name and birth date'), and outputs ('core numbers, cycles, lucky digits, and summary copy'). Explicitly differentiates from Chaldean numerology and lucky-numbers-only tools in the DO NOT CONFUSE section.

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

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

Provides explicit workflow context (BEFORE/AFTER) naming a related tool and when to use it (to fill Personal Year). Lists alternative tools with clear differentiators, giving unambiguous when-to-use versus when-not-to-use guidance.

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

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

The description accurately conveys a read-only, idempotent retrieval operation and points to an external full output/error contract. The readOnlyHint and idempotentHint annotations are not contradicted; the description adds useful detail about the monthly row-oriented return shape.

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

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

The description is reasonably concise and front-loaded with the core purpose. Some redundancy exists between the AFTER workflow note and the DO NOT CONFUSE WITH line, but it is not excessive and reinforces the key distinction.

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

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

The description provides enough context for correct use: the output shape, the distinction from the single-day tool, input validation, timezone behavior, and a link to the full contract. Given the rich input schema and sibling context, nothing essential is missing.

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

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

The input schema covers all parameters with ranges and defaults, and the description adds that year/month/lat/lon are validated locally and that timezone handling follows upstream response fields. response_format is not described, but the schema provides its enum and default.

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

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

The description clearly states the tool returns one row per civil day for a calendar month at a location, with condensed Panchanga fields. It also explicitly distinguishes itself from asterwise_get_panchanga, the single-day detailed version, so an agent can select the right sibling tool.

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

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

The description provides explicit before/after workflow guidance and a direct 'DO NOT CONFUSE WITH' warning identifying asterwise_get_panchanga as the single-day alternative. This makes it clear when to use this monthly calendar tool versus a more detailed daily lookup.

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

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

The annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already establish the tool's safety profile. The description adds transparency by stating 'WORKFLOW: BEFORE: None — standalone', indicating no prerequisites or side effects, and consistently says 'Returns' without implying any mutation. The 'standalone' statement goes beyond the annotations, reinforcing idempotent/read-only behavior.

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

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

The core description is concise and front-loaded. However, the full description includes lengthy 'INPUT CONTRACT' and 'WORKFLOW' sections that largely duplicate information already present in the input schema. The 'DO NOT CONFUSE WITH' section is useful but could be integrated more tightly. The overall text is longer than necessary, with some redundancy between the written description and the schema, reducing conciseness.

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

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

The description provides the essential context: what the tool returns (three cycle numbers), how they are derived (from birth date and target date), and how to use optional parameters. It also points to a full external contract via the provided link. It does not describe error handling or response structure, but the presence of an output schema (not shown here) and the external docs reference largely compensate. The tool is sufficiently contextualized for basic use.

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

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

Schema coverage is 100%, so the baseline is 3. The description's 'INPUT CONTRACT' section adds concrete examples (e.g., '1985-11-12', '2026', '5', '1') and clarifies nuanced behavior such as 'Personal Day is only returned when day is provided. Defaults to null (Personal Day omitted).' This goes beyond the schema descriptions by providing usage examples and edge-case behavior, adding practical meaning for the agent.

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

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

The description clearly states the tool's primary function: 'Returns the Personal Year, Personal Month, and Personal Day numbers for a given birth date and optional target date.' It identifies the specific output (three cycle numbers) and the input (birth date + optional target date). The 'DO NOT CONFUSE WITH' section explicitly distinguishes it from asterwise_get_personal_year and asterwise_get_numerology_profile, making its unique purpose unambiguous.

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

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

The description provides explicit usage guidance by contrasting with sibling tools: 'asterwise_get_personal_year — returns Personal Year only, no month or day breakdown' and 'asterwise_get_numerology_profile — core name numbers; personal_year field is null there.' This directly tells the agent when to choose this tool over the alternatives. It also explains the optional parameters (year, month, day) and their defaults, clarifying the intended use cases.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds meaningful behavioral detail beyond annotations: which letters count, Y always treated as a consonant, per-name-part reduction, and preservation of master numbers 11, 22, and 33. This is precisely the kind of algorithm-level context an agent needs.

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

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

The description is well-structured with clear sections: calculation overview, WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH, and a docs link. It is front-loaded with the essential calculation rule and contains no filler; the only small redundancy is restating the Y rule, but it remains useful as an input contract reminder.

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

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

Given an output schema exists, the description does not need to explain return values. It covers the input contract, examples, master-number behavior, workflow placement, sibling disambiguation, and includes a URL to the full output/error contract. Nothing essential is missing for correct selection and invocation.

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

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

Schema coverage is 100%, so the baseline is adequate. The description enriches the name parameter with a fuller contract ('Full legal name as used at birth'), concrete examples, and the Y-is-always-a-consonant rule. However, this slightly conflicts with the schema's 'as commonly written' wording, creating minor ambiguity about which name form is authoritative.

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

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: 'Calculates the Personality number from consonants in the full name.' It further differentiates from the most similar siblings by naming the Expression number (all letters) and Soul Urge number (vowels only). This makes the tool's purpose unambiguous.

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

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

The WORKFLOW section explicitly says the tool is standalone BEFORE and points to asterwise_get_numerology_profile AFTER for seeing all five core numbers together. The 'DO NOT CONFUSE WITH' section names the exact alternatives and what distinguishes them, giving an agent clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral context on top: it confirms birth data alone computes everything, mentions the exact classical combinations covered, and links to a full output/error contract. It does not contradict annotations.

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

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

The description is structured with WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE WITH sections, making it easy to scan. It includes a documentation URL for full details. It is slightly more verbose than strictly necessary, but every section earns its place.

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

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

The description covers prerequisites (none), downstream workflow, sibling disambiguation, and points to a full output/error contract URL. Combined with the rich input schema, annotations, and output schema, the agent has everything needed to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema itself documents all parameters and nested properties. The description only restates the birth contract at a high level and does not add new meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific action and resource: 'Detects and analyses Pitru Dosha' using all five classical combinations. It also explicitly differentiates itself from asterwise_get_doshas, saying that sibling returns less detail. This makes the tool's purpose unmistakable.

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

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

The description gives explicit routing guidance: 'DO NOT CONFUSE WITH asterwise_get_doshas' and 'Use this tool when dedicated Pitru Dosha analysis is needed.' It also provides a workflow context, noting that puja suggestions come after via asterwise_get_puja_suggestions. This is strong, actionable usage guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it is a standalone reference tool, follows classical Vedic tradition, and can return either all planets or one planet; it also links to the full output and error contract. It adds value beyond the annotations without contradicting them.

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

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

The description is organized into short, labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE) with the core purpose front-loaded in the first sentence. Every section earns its place by aiding tool selection or invocation, and the formatting makes scanning easy despite the large sibling list.

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

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

For a simple, read-only reference tool with two optional parameters and an output schema, the description is complete: it states purpose, input contract, workflow context, sibling disambiguation, and points to the full output/error contract via URL. Nothing an agent needs to select or invoke this tool correctly is missing.

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

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

Schema description coverage is 100%, but the description adds meaning for the 'planet' parameter by enumerating all nine allowed values and explicitly stating that omitting it returns all planets. The 'response_format' parameter is already well-explained by the schema enum, so the description does not need to repeat it.

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

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

The description uses a specific verb ('Returns') and resource ('classical graha (planet) properties'), and clearly scopes the operation to 'all nine planets or a single planet'. The 'DO NOT CONFUSE WITH' section explicitly distinguishes it from puja suggestions and rudraksha recommendations, making sibling differentiation strong.

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

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

The WORKFLOW section states there is no prerequisite ('BEFORE: None') and names the natural follow-up tool ('AFTER: asterwise_get_puja_suggestions'). The 'DO NOT CONFUSE WITH' block explicitly names alternatives and why they are different, giving clear when-to-use versus when-not-to-use guidance.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior, and the description adds useful behavioral context such as omitting planet returns all nine ggrahas and positioning pujas as complementary to rudraksha. The link to the full output/error contract handles the remaining behavioral disclosure without cluttering the text.

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

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

The description is front-loaded with a crisp purpose sentence and uses labeled short sections such as WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE, so an agent can scan quickly. Every section carries distinct information and there is no filler or repetition of schema/annotation values.

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

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

For a tool with an output schema and safety annotations, the description covers workflow context, parameter semantics, sibling disambiguation, and points to the full contract. An agent choosing between this and any of the many siblings has enough context to route correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds a complete enumeration of the nine allowed planet values plus the omit-for-all behavior, which the schema only hints at with examples. The response_format parameter is already fully described in the schema, so no further prose is needed.

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

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

The first sentence states a specific verb and resource: 'returns puja (ritual worship) recommendations for planetary propitiation per ggraha'. The 'DO NOT CONFUSE' section explicitly separates it from asterwise_get_remedies and asterwise_get_rudraksha, making the purpose unambiguous even among many siblings.

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

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

WORKFLOW provides explicit before/after tool relationships: natal chart first, rudraksha after, and the DO NOT CONFUSE section names the closest alternatives. The INPUT CONTRACT also tells the agent when to omit planet versus supply a specific ggraha.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful context beyond those: it computes three kaal bands, depends on location and date, and includes a local-time 'active now' check. It could mention more about error behavior, but the docs link and output schema cover some of that gap.

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

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

The description is organized into distinct, purposeful sections: core behavior, workflow, input contract, exclusions, and documentation link. The central behavior is front-loaded, and no sentence is filler or tautology.

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

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

For a nested-location tool with an output schema and strong annotations, the description is nearly complete: it covers workflow, sibling differentiation, validation behavior, and points to the full contract. It loses a point because the ambiguous 'place name' alternative in the location schema is not clarified in the description, and the exact required coordinates/date are only implicitly referenced.

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

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

Schema description coverage is 100%, so the baseline is 3. The INPUT CONTRACT adds modest value by noting that LocationInput validates the date pattern and coordinates locally. However, the description does not resolve the schema's confusing 'location' property description that mentions a place-name alternative while the schema actually requires lat, lon, and date.

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

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

The first sentence names three specific outputs (Rahu Kaal, Gulika Kaal, Yamaganda Kaal intervals) plus an active-now status flag, and ties the computation to diurnal length and location. The DO NOT CONFUSE section explicitly distinguishes it from choghadiya and panchanga, so an agent can identify it without opening the schema.

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

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

WORKFLOW states this tool is standalone with no prerequisite, and AFTER names choghadiya as the broader alternative. DO NOT CONFUSE further gives two exclusions with reasons, making when-to-use and when-not-to-use explicit.

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

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

Annotations already indicate readOnly/idempotent/non-destructive. Description adds a full output/error contract URL and clarifies it returns tables, which is consistent. No contradictions; the error contract link provides extra context beyond annotations.

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

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

Description is somewhat verbose with multiple labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE, plus a URL). However, the sections are structured and each adds distinct value; the main purpose is front-loaded. Slightly wordy but acceptable for the complexity.

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

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

Given the tool's complexity (nested birth object, two parameters, many siblings), the description is complete: it provides workflow context, clarifies input contract, contrasts with similar tools, and points to full output/error documentation. An agent has enough information to use this tool correctly.

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

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

Schema description coverage is 100%—every field and sub-field has a detailed description with examples. The description adds no new parameter semantics beyond the 'BirthData follows the global contract' note, which simply references a shared structure already fully documented in the schema. Baseline 3 applies due to high schema coverage.

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

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

States precisely what it does: derives classical remedial prescriptions from planetary weakness and dusthana lordship, returning mantra, lifestyle, charity, and dignity tables. Explicitly contrasts with sibling tools (lal_kitab_remedies and gemstone_recommendations) to avoid confusion.

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

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

Provides explicit workflow guidance: recommends getting natal chart first and optionally following with gemstone recommendations. Also clearly states what this tool is NOT for (household Lal Kitab totkas, gemstone-only), giving clear when-to-use vs. when-not-to-use guidance.

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