Western Astrology MCP Server by RoxyAPI

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

Beyond the readOnlyHint=true annotation, the description discloses meaningful behavioral traits: the forecast is generated from real-time planetary transits using whole-sign house positions, content is unique per sign, it is fixed for a given date and rolls over at midnight (default UTC), and the date/timezone parameters alter the 'current' period. It also enumerates the output categories (love, career, health, finance, etc.). This adds substantial context that the annotation alone does not provide, making behavior predictable.

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 first two sentences are information-dense and front-loaded, but the final sentence 'Daily horoscope API, zodiac forecast, sun sign horoscope, astrology prediction.' is pure keyword stuffing that adds zero value for an AI agent and wastes tokens. This violates the 'every sentence earns its place' principle. If the keyword string were removed, this would be a 5; as written, it is needlessly padded.

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?

There is no output schema, so the description carries the burden of explaining return values. It does this well, listing love, career, health, finance, overview, active transits, Moon sign/phase, energy rating, lucky number/color, and compatible signs. It also covers date/timezone rollover behavior. It lacks explicit error-handling or limitation details, but for a simple daily-horoscope read operation, the description is sufficiently complete for an agent to understand what it will get 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?

The schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds extra meaning for two parameters: it explains that 'date' is for editorial scheduling and that 'timezone' controls rollover on a local clock, which directly clarifies their purpose beyond the schema. The other params (sign, lang, compact) rely on the schema's already thorough descriptions, so this is a moderate increment over baseline.

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

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

The description opens with 'Get the daily horoscope for any zodiac sign' – a specific verb ('get') and resource ('daily horoscope by zodiac sign'). It clearly distinguishes from siblings by specifying 'daily' (vs weekly/monthly) and adds a differentiator: forecasts are transit-based using whole-sign house positions, so each sign gets unique content. This is unambiguous and surfaces the tool's distinct purpose among the sibling astrology tools.

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

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

The description provides clear context: it is for daily horoscopes, and gives usage guidance on date and timezone parameters ('Pass date for editorial scheduling, or timezone to roll over on a local clock'). It does not explicitly mention when to use this over the weekly/monthly siblings, but the word 'daily' and the sibling naming make the intended scope obvious. Since there are no explicit exclusions or alternative recommendations, it stops short of a 5.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral details beyond annotations: sign-specific house activations, coverage of love/career/health/finance, actual ephemeris-based key dates (New Moon, Full Moon, retrogrades), and timezone rollover behavior. This gives the agent a clear model of what the tool returns and how it behaves.

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 purpose and then provides useful detail. The first three sentences are information-dense and valuable. However, the final keyword string ('Monthly horoscope API, zodiac monthly forecast, astrology monthly prediction') is redundant filler that adds no new information. Slightly less concise than ideal, but not bloated.

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

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

Given no output schema, the description compensates well by explaining what data is included (week-by-week breakdown, key dates, life areas) and edge-case behavior (date inside month, timezone fallback). It does not specify the exact response structure, but for a read-only horoscope tool with a compact parameter, the description is sufficiently complete 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 description coverage is 100% — every parameter (date, lang, sign, compact, timezone) is already well-documented in the schema. The description reinforces the date and timezone semantics but adds nothing beyond what the schema provides, resulting in a baseline score of 3.

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 exactly what the tool does: 'Get monthly horoscope for any zodiac sign' and differentiates from siblings by specifying 'week-by-week breakdown and real lunar phase key dates.' This clearly separates it from daily and weekly horoscope tools. It is a specific verb+resource definition.

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 clear usage context: 'Pass any date inside a month to retrieve that month, or timezone to roll over on a local clock.' It explains how to select the month and timezone behavior, but does not explicitly mention alternatives or state when not to use the tool. Nevertheless, the monthly scope is self-evident versus the daily/weekly siblings.

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

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

Annotations already declare readOnlyHint and destructiveHint. The description adds useful behavioral context: the forecast is transit-based, house-specific, covers multiple life areas, and includes lucky days/numbers/compatible signs. It also explains week-boundary behavior via date or timezone. 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 first three sentences are informative and front-loaded. However, the trailing keyword list ('Weekly horoscope API, zodiac weekly forecast, astrology weekly prediction.') is redundant SEO-style filler that adds no agent value, making the description less concise than it could be.

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 a rich schema and read-only annotations, the description adequately conveys the tool's scope and expected content. It names the forecast period, content areas, and date/timezone selection. The absence of an output schema is partially mitigated by listing key response themes (love, career, health, etc.). Minor gaps like error behavior are not critical for this read-only tool.

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

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

Schema coverage is 100% with detailed parameter descriptions (e.g., date format, timezone semantics, compact output, language fallback). The description only lightly restates the date/timezone behavior, adding no new info beyond the schema. Baseline 3 applies.

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 'Get weekly horoscope for any zodiac sign,' which clearly states the verb and resource. It specifies the Monday-to-Sunday forecast period and content categories, distinguishing it from sibling daily/monthly horoscope 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?

It provides clear usage guidance: 'Pass any date inside a week to retrieve that week, or timezone to roll over on a local clock.' This implies the weekly scope and the optional date/timezone behavior. It doesn't explicitly exclude daily or monthly alternatives, but the weekly focus is unambiguous.

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, so the lower burden applies. The description adds behavioral detail beyond the schema by specifying what the tool returns ('moon phase and illumination for every day') and the time scope ('specific month'). There is no contradiction with annotations.

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

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

The description is concise: two sentences with no redundant phrasing. The first sentence states the core function, and the second lists concrete use cases. Every word 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?

For a simple read-only calendar tool with a fully documented schema, the description is sufficient. It indicates the output content at a high level ('showing moon phase and illumination') but does not detail the return structure; this is acceptable since no output schema exists and the tool's use case is straightforward.

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 provides 100% coverage, documenting all four parameters with descriptions, defaults, and ranges. The description adds no additional parameter-level meaning, so a 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 clear verb+resource ('Get complete lunar calendar') and specifies the scope ('for every day of a specific month'). This clearly differentiates it from sibling tools like get_astrology_moon_phase_current and get_astrology_moon_phase_upcoming, which cover current or upcoming phases rather than a full monthly calendar.

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 clear use-case context: 'Perfect for creating moon phase calendars, lunar planners, and astrology event schedules.' However, it does not explicitly state when not to use it or contrast with alternative moon phase tools, so it lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context beyond listing output fields, such as pagination, precision caveats, or timezone resolution. It's adequately transparent for a simple read operation, but not enriched.

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

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

Two sentences: the first enumerates the return data (illumination, lunar age, zodiac sign, distance, phase name), the second lists use cases. No filler or redundancy; every clause adds 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?

No output schema exists, so the description compensates by listing the returned fields and the exact phase names. For a straightforward read-only lunar phase lookup, this is sufficient context; a minor gap is not describing the output shape or whether the result is an object vs. array, but the field list makes it usable.

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% with well-documented parameters (date, lang, time, compact, timezone) including defaults, formats, and examples. The description itself adds no parameter-level meaning, so the schema carries the full burden; baseline 3 applies.

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?

Clear verb ('Get') + specific resource ('current moon phase') with detailed output fields. The word 'current' in name/title helps distinguish from sibling tools like upcoming and calendar, but the description doesn't explicitly contrast with them.

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?

No explicit instructions for when to use this tool versus alternatives like get_astrology_moon_phase_upcoming or get_astrology_moon_phase_calendar_year_month. The description implies a general purpose (moon tracking, calendars) but doesn't state exclusions or when the other tools would be more appropriate.

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 useful behavior beyond annotations by specifying the return payload ('dates and phase names for each lunar quarter') and the list of phases, which partially compensates for the absence of an output schema. It does not disclose pagination or response shape details, but these are less critical for a read-only tool already marked readOnlyHint=true.

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?

Three concise sentences front-load the core function, then give return details and use cases. Every sentence earns its place: the first states the action, the second describes the output, and the third gives typical applications. No redundancy or filler.

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 read-only annotations and fully self-describing schema, the description fills the main remaining gaps: it clarifies that the tool returns a list of future lunar transitions and their dates. It could be more explicit about differentiation from sibling tools, but the name and description make the intended context clear.

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%, and the description does not add parameter-specific information. All four parameters (lang, count, compact, startDate) are fully documented in the schema, so the description's lack of parameter detail is acceptable. 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 uses the verb 'Get' with a specific resource 'upcoming moon phase transitions' and enumerates the four lunar phases (New Moon, First Quarter, Full Moon, Last Quarter). It clearly scopes the temporal range ('next weeks/months') and is distinct from sibling tools like 'current' and 'calendar_year_month' through the 'upcoming' qualifier.

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 clear usage context: 'Perfect for lunar event calendars, moon phase widgets, and astrology planning tools' and states the temporal scope. However, it does not explicitly mention alternatives such as get_astrology_moon_phase_current or get_astrology_moon_phase_calendar_year_month, nor does it state when not to use this tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context about the exact scope (all 14 bodies) and the data shape (fields included), which goes beyond the annotations. It does not mention return format or pagination, but for a simple list endpoint this is adequate.

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?

Three sentences: first states purpose and payload, second lists use cases, third points to the detailed alternative. No fluff, front-loaded, every sentence 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?

With only 2 optional parameters and no output schema, the description fully covers what the agent needs: what is returned, the field list, typical use cases, and the path to more detailed data. It is complete for a list endpoint with good sibling coverage.

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% for both parameters (lang and compact) with detailed descriptions. The tool description does not add parameter-level meaning, but the schema does the heavy lifting, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool 'Returns all 14 astrological bodies' with specific fields (name, symbol, tagline, category, ruling sign, short descriptions). It distinguishes itself from the sibling get_astrology_planet_meanings_id by explicitly pointing to that endpoint for complete profiles.

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?

Includes explicit use cases ('Perfect for astrology reference apps, planet meaning widgets...') and a direct alternative: 'Use GET /planet-meanings/{id} for complete profiles.' This tells the agent when to choose this list version vs. the detailed version.

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 operation as read-only and non-destructive, lowering the bar. The description adds valuable behavioral details: input flexibility (case-insensitive names), the 'complete astrology meaning' return shape, and the specific fields included. 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 front-loaded with the core purpose and then efficiently lists input forms and return fields. The use-case enumeration ('Perfect for birth chart readings, ...') is slightly repetitive and could be trimmed, but the paragraph remains focused and information-dense.

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 no output schema, the description correctly compensates by enumerating the major return fields and clarifying input aliases. The tool is a simple read-only lookup, and the description together with the rich schema and annotations provides enough information for an agent to select and invoke it confidently.

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 provides thorough descriptions for all three parameters (id, lang, compact) with examples, defaults, and behavioral notes like 'Languages without translations yet return English'. Since schema coverage is 100%, the description does not need to repeat this; it adds only minimal reinforcement of id semantics.

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 'Retrieve comprehensive planet interpretation for any astrological planet using lowercase ID or case-insensitive name', establishing a specific verb+resource+scope. It enumerates the exact data fields returned, and the singular 'planet' lookup differentiates it from sibling list tools like get_astrology_planet_meanings.

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 clear context for when to use the tool: for a single planet lookup via ID/name, and it lists concrete use cases like 'birth chart readings' and 'planet meaning lookups'. It does not explicitly exclude alternatives or name sibling tools, but the singular-lookup focus makes the intended usage unambiguous.

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, covering safety. The description adds behavioral context by specifying the fixed set of 12 signs and the exact content returned, such as date ranges and short descriptions. No additional side effects or hidden behavior are relevant.

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 purpose and the full list of signs, then gives use cases and an alternative. The use-case enumeration is slightly verbose but each part serves to clarify applicability and differentiation. Overall it is efficient and well-structured.

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 list tool with zero required parameters, rich schema annotations, and no output schema, the description is complete: it names the returned fields, lists every sign, and points to the detailed variation. No pagination, return format, or error details are necessary for this use case.

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 fully describes both 'lang' and 'compact' with defaults, enums, and examples, achieving 100% schema description coverage. The tool description does not add parameter-specific meaning, but the schema carries the full burden, so the 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 'Returns all 12 tropical zodiac signs' with a complete enumeration (Aries through Pisces) and specifies the exact fields: name, symbol, element, date ranges, and short descriptions. It clearly differentiates from the sibling 'signs/{id}' tool by noting that the id version provides detailed profiles, making the 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 provides explicit use cases ('Perfect for zodiac sign lists, horoscope widgets, birth chart calculators...') and an explicit alternative: 'Use GET /signs/{id} for complete zodiac sign profiles.' This tells the agent exactly when to choose this tool over the detailed sibling.

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, lowering the burden. The description adds valuable behavioral context beyond this: input flexibility (case-insensitive names), the exhaustive list of returned data elements, and the compact option's token reduction. 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 front-loaded with the core purpose and then provides a structured list of return fields and use cases. It is longer than strictly necessary but every sentence contributes useful information; the use-case sentence is somewhat generic but not padding. Overall well-organized and appropriately sized.

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 no output schema, the description carries the responsibility of explaining return values, and it does this thoroughly (element, modality, ruling planet, traits, famous people, etc.). It also covers input format, language fallback is handled by schema, and the compact behavior is mentioned. For a simple read-only tool, this is complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does add a brief example and notes case-insensitivity, but this largely mirrors the schema's own parameter descriptions. It does not provide additional semantic depth for the lang or compact parameters, so no higher score is warranted.

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 ('Retrieve') and names the resource ('zodiac sign information') with clear scope ('for any astrological sign'), and distinguishes it from siblings like get_astrology_signs by focusing on a single sign's comprehensive profile. It also details the exact output fields, making the 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 provides clear context for when to use this tool (single-sign detailed lookups) and lists numerous relevant use cases ('horoscope readings, zodiac compatibility checks, birth chart interpretations'). However, it does not explicitly name sibling alternatives (e.g., get_astrology_signs for listing all signs) or give exclusion criteria, so it falls short of a 5.

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, so the safety profile is covered. The description adds valuable behavioral context: the day/night formula is applied automatically from chart sect, and it details exactly what is returned (sign, degree, longitude, arc, interpretation). It also notes the use of tropical positions. 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 three sentences and reasonably concise. The first sentence front-loads the main purpose and lists all seven lots. The final sentence ('Built on accurate tropical chart positions, no astronomy expertise needed.') is slightly promotional but still provides useful reassurances for the user. No wasted words 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?

With no output schema, the description compensates by listing the return fields (zodiac sign, degree, exact longitude, arc, interpretation). It covers the core behavior, the input context (birth moment), and the target audience. It could mention edge cases like unknown birth time, but the schema already notes a default for time. Overall, it is complete for a read-only calculation 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 baseline is 3. The description does not add much parameter-specific meaning beyond what the schema already provides; it references 'chart sect' which relates to houseSystem, but this is not a new semantic detail. The description's value is more at the tool level than parameter level.

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 with a specific verb ('Calculate') and resource ('the seven Hermetic lots'), and lists all seven lots by name. It distinguishes itself from sibling tools by focusing exclusively on Arabic parts, a unique domain among the 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 description provides clear context: it is for any birth moment and for Hellenistic and traditional astrology apps. It implicitly tells the agent to use this tool when Arabic parts are needed, but it does not explicitly state when not to use it or compare it to alternatives like the natal chart 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?

The description adds substantial behavioral context beyond the readOnlyHint/destructiveHint annotations: it specifies output attributes (tightness score 0-100, dissociate flag, one-line interpretation) and describes built-in disambiguation (Grand Cross suppresses T-Squares, Kite suppresses Grand Trine). This transparency helps the agent predict side effects and output 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?

Four sentences with zero filler. It front-loads the core purpose, then methodically lists pattern types, output attributes, disambiguation logic, and use cases. Every sentence earns its place; no redundant restatement of the title or schema.

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

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

Given 10 parameters, no output schema, and no nested objects, the description provides a solid overview of what is returned and for whom. It names all pattern types and key output fields, and even covers disambiguation behavior. It does not address error handling or timezone edge cases, but these are not essential for tool selection.

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

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

Schema description coverage is 100%, so the schema already fully documents all 10 parameters. The description adds no parameter-specific semantics, sticking to outputs and use cases. Baseline 3 is appropriate because the schema carries the parameter documentation 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 opens with a specific verb ('Identify') and a precise resource ('classical Western astrology multi-planet configurations in a birth chart'), then enumerates every pattern type returned. This clearly distinguishes it from sibling tools like post_astrology_aspects, which handle two-planet aspects rather than multi-planet configurations.

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 states suitable applications: 'personalized natal report engines, astrology chatbots, AI agents that interpret chart geometry, and editorial chart-pattern callouts.' This gives clear context for when to use the tool, though it does not explicitly name alternative tools or state when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral detail by stating the return data (aspect type, exact angle, orb, applying/separating status, strength 0-100) and noting 'standard Western astrology orbs', which goes beyond what annotations provide. No contradictions found.

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 a tightly written four-sentence paragraph that front-loads the core function and then adds return details, filters, and use cases. No filler words or redundant repetition; every sentence contributes meaningful 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?

For a read-only calculation tool with no output schema, the description adequately covers inputs, filters, and outputs. It explains return fields and mentions standard orbs. It could be slightly more specific about the 'minor aspects' and the exact default set of bodies, but the schema fills those gaps.

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

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

Input schema coverage is 100%, with all seven parameters already described in detail. The description reinforces the ability to filter by planets and aspect types but does not add meaning beyond the schema, so the 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 action ('Calculate'), the resource ('planetary aspects'), and the scope ('for any date and time'). It also lists return fields and filters, distinguishing it from ambiguous astrology tools and implying contrast with the monthly and transit-aspect 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 description gives clear context ('Perfect for aspect tables, transit analysis, and aspect pattern detection') but does not explicitly name alternatives or exclusion criteria. The mention of 'aspect pattern detection' could mislead since a dedicated aspect_patterns sibling tool exists, so guidance on when to use this tool vs. alternatives is only implicit.

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?

With readOnlyHint=true already in annotations, the description adds substantial behavioral context: it returns 'exact date and time of closest approach in your timezone', uses 'tropical longitudes', deliberately excludes the Moon, defaults to month in progress when year/month omitted, and is 'Verified against NASA JPL Horizons.' This goes well beyond the annotation safety profile.

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 purpose and then adds necessary context (bodies, aspects, orbs, timezone, exclusion rationale). It includes a small SEO keyword tail ('Monthly aspect calendar API, exact aspect times, planetary aspect ephemeris, transit timing') which is somewhat unnecessary but not bloated. Every substantive sentence earns its place, though it is longer than a minimal two-sentence description.

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 tool has no output schema, but the description explains return values ('exact date and time of closest approach in your timezone along with the nature of the aspect'), default behavior, exclusions, and even verification. It covers the full decision context for an agent, accounting for all six optional parameters and the monthly scope, making it highly complete.

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

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

Schema description coverage is 100% for all 6 parameters, so the baseline is 3. The description adds value by explaining the functional result of omitting year/month ('Omit year and month to get the month in progress') and ties the timezone to readability ('which is what makes a published calendar read correctly for its audience'). This practical usage tip enriches the param understanding, hence 4.

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: 'Get every planetary aspect that perfects during a given month' and then details the exact 13 non-lunar Western bodies, nine aspects, and output (exact date/time and nature of aspect). This clearly distinguishes it from sibling tools like post_astrology_aspects or post_astrology_transits_monthly by emphasizing monthly scope and non-lunar exclusion.

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 states explicit use cases: 'Essential for monthly forecast copy, transit calendars, electional timing, and newsletter automation.' It also gives a clear when-not rationale: 'The Moon is excluded because it forms hundreds of aspects a month and belongs in a daily view rather than a monthly one.' This implies a daily-view alternative without naming a sibling, so it falls short of full explicit alternative naming but is still strong.

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, so the safe read operation is known. The description adds behavioral detail beyond this by listing exactly what each asteroid returns (tropical zodiac sign, degree, house placement, daily speed, retrograde status, and interpretation) and explicitly excludes Chiron. This is useful context that goes beyond the annotations.

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

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

The description is two sentences long and front-loaded with the core purpose. The first sentence states what the tool does, and the second covers output details plus an important alternative (Chiron via natal chart endpoint). Every sentence earns its place with no 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?

There is no output schema, so the description carries the burden of explaining return values. It lists the per-asteroid data fields (sign, degree, house, speed, retrograde, interpretation), which is sufficient for an agent to understand the response. It also covers scope and the Chiron alternative. It doesn't mention house system defaults or node type options, but those are documented in the schema, so the description is reasonably complete for tool 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?

The input schema has 100% coverage with detailed descriptions for all 9 parameters, so the baseline is 3. The description doesn't add parameter-specific meaning beyond what the schema already provides; it only mentions 'natal positions' and 'tropical zodiac sign,' which are output concepts rather than parameter semantics.

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

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

The description specifies the exact resource: 'Calculate the natal positions of the four classical asteroid goddesses, Ceres, Pallas, Juno, and Vesta.' It also distinguishes this tool from siblings by explicitly noting 'Chiron is available through the natal chart endpoint,' clarifying that this endpoint is for the four asteroid goddesses only.

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 clear guidance: it states the endpoint is 'for natal reports and relationship astrology' and explicitly names an alternative for Chiron ('Chiron is available through the natal chart endpoint'). This tells the agent when to use this tool and when to use a sibling tool, satisfying the criteria for explicit when/when-not guidance.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds meaningful behavioral details: it lists exact outputs ('right ascension, declination, the two meridian line longitudes, and sampled rising and setting curves ready to plot') and notes an interpretation per line. This goes beyond what annotations provide, giving the agent an expectation of the response 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 three sentences, front-loaded with the main action and purpose. No fluff or redundancy; every sentence adds value (what it does, what it returns, and the context). The structure is clean and scannable.

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

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

Given the tool has 9 parameters and no output schema, the description does a solid job of explaining the output format ('returns right ascension, declination... ready to plot') and the domain context. It doesn't detail the exact geographical representation or error cases, but for an AI agent the essentials are covered. Slightly more detail about how 'ready to plot' translates to data structures would improve it.

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 does not add parameter-specific details beyond what the schema already contains, but it does explain the overall purpose (computing planetary lines) that ties the date, time, and location parameters together. It neither clarifies nor conflicts with the schema, so a 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 uses a specific verb and resource: 'Generate an astrocartography map of Midheaven, Imum Coeli, Ascendant, and Descendant planetary lines for any birth moment.' It clearly distinguishes this from sibling tools by naming the exact astrological technique and what it returns. The phrase 'core of relocation astrology and astro mapping' further situates it among the sibling set.

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 implies usage for relocation astrology and astro mapping, and states 'for any birth moment,' giving some context. However, it does not explicitly compare to sibling tools like post_astrology_relocation_chart or post_astrology_local_space, nor say when not to use this tool. There is no clear 'use this instead of X' 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's 'Calculate... Returns' is consistent with a read-only operation. The description adds detail about output content but no side-effect or behavioral caveats; with annotations covering the safety profile, this is adequate but not exceptional.

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 clear purpose and then enumerates output details in three dense sentences. It is detailed but not bloated; every clause adds selection-relevant information, though it is slightly long for a tool description.

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 no output schema present, the description thoroughly explains return values: the 0-100 score, five category breakdowns, specific planetary pairs, narratives, element balance, archetype classification, and significant aspects. This is more than sufficient for an agent 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 all parameters are fully documented in the schema. The description only refers to 'two birth charts' and adds no parameter-specific meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool does a compatibility score between two birth charts using Western synastry, with specific output breakdowns. However, it does not explicitly differentiate it from closely related siblings like post_astrology_synastry, so it misses the sibling-distinction criterion.

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?

No when-to-use guidance or alternatives are mentioned. The description implies this tool is for obtaining a quantified compatibility score, but it never states when to prefer it over post_astrology_synastry or post_astrology_composite_chart, leaving the agent without exclusionary 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, so the agent knows it is a safe read operation. The description adds value by disclosing the midpoint calculation method and the invariant that 'the Ascendant always sits on the first cusp,' plus a concrete list of returned data. No side effects or permissions are relevant, so the description covers the key behavioral traits beyond annotations.

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

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

The first two sentences are efficient and front-loaded, explaining purpose and method. The final sentence—'Composite chart API, midpoint chart calculator, relationship astrology, couple chart analysis'—is keyword stuffing that adds little for an AI agent, diluting conciseness. Overall, it is well-structured but not every sentence 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?

There is no output schema, so the description's explicit list of return values ('composite planetary positions, house cusps, Ascendant, Midheaven, aspects, and relationship interpretation') is necessary and present. The schema covers all parameters, including nested person objects and house system. Edge cases (e.g., missing time, nodeType selection) are left to the schema, which is acceptable for moderate complexity.

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 each parameter (lang, compact, person1, person2, houseSystem) is already documented with detailed descriptions. The description's mention of 'planets, angles and house cusps are each the midpoint' is conceptual and doesn't add input-specific 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 opens with a specific verb and resource: 'Generate a composite chart by calculating midpoints between two natal charts.' This clearly distinguishes the tool from synastry (comparing two charts) and natal chart (single person) by centering on the midpoint method and 'relationship as a single entity.' The return list (planetary positions, house cusps, Ascendant, Midheaven, aspects, interpretation) further nails the purpose.

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

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

The description gives context that helps infer when to use the tool: 'represents the relationship as a single entity' and describes the output content. However, it never explicitly names alternatives (e.g., synastry, compatibility score) or states when not to use this tool, so usage guidance is implied rather than 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 declare readOnlyHint=true and destructiveHint=false, and the description adds valuable behavioral context: it explains what constitutes a crossing, the distinction between ascending and descending nodes, and mentions verification against NASA JPL Horizons. 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 substantive but relatively concise, covering purpose, scope, exclusions, and usage context in a few sentences. It could be slightly trimmed by removing the final comma-separated keyword list (which duplicates earlier explanations) but overall is efficient.

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

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

Given the tool's moderate complexity (4 params, no output schema), the description covers the input requirements, return content, and use cases adequately. It could mention pagination or result limits if the year scan produces a large dataset, but overall provides sufficient context for an agent to invoke 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 description does not need to add much. However, it supplements by explaining the computed fields (date, time, tropical longitude, sign) that the output will contain, and mentions timezone handling, which adds context beyond basic schema information.

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

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

The description clearly states the tool retrieves every moment a body crosses the ecliptic plane during a year, specifies the 11 bodies included, and differentiates the tool from sibling astrology tools (e.g., eclipse-season work, node timing) by focusing on exact node passages rather than general transits or aspects.

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 states when to use the tool (eclipse-season work, node timing, astronomical calendars) and explains exclusions (Sun and lunar nodes are omitted). It does not directly compare with sibling tools, but the specific use case (crossings vs. general aspects or transits) provides implicit 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, so the safety profile is known. The description adds substantial behavioral context: it precesses star positions, returns visual magnitude and traditional planetary nature, and provides plain-language interpretations for conjunctions. This goes beyond the annotations without contradicting them.

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

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

Three sentences, logically arranged from computation to output to use-case, with no filler. Every sentence earns its place: the first explains what is calculated, the second what is returned, and the third the intended use case.

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 9 parameters and no output schema, the description does a good job explaining the core outputs: precessed ecliptic longitude, zodiac sign, visual magnitude, planetary nature, and interpretations. It does not mention edge cases like zero conjunctions or compact-mode output shape, but the schema covers the compact parameter, and the description gives enough for an agent to form a mental model.

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 100% of parameters with detailed descriptions, including defaults, ranges, formats, and examples. The description only indirectly references the orb parameter ('chosen orb') and does not add new parameter semantics that the schema does not already provide, so the baseline of 3 is appropriate.

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

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

The description uses specific verbs 'calculate' and 'detect' with a well-defined resource: tropical zodiac positions of fixed stars and conjunctions to natal planets, Ascendant, and Midheaven. It names the specific star groups (four Royal stars, fifteen Behenian stars, Regulus, Spica, Algol), cleanly distinguishing it from sibling tools like post_astrology_planets or post_astrology_aspects.

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 states 'for any birth moment' and 'A focused tool for natal reports', providing clear context that this is for natal fixed-star analysis rather than transits, synastry, or predictive work. It implies this usage through the natal focus but does not explicitly name alternatives or exclusions, leaving only a slight gap in 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. The description adds valuable context about the return format (all 12 house cusps with signs, degrees, Ascendant, and MC) and the ability to compare systems via the 'all' parameter. 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 compact at five sentences, front-loading the purpose. Minor redundancy exists between 'Returns all 12 house cusps...' and 'Includes accurate Ascendant and MC calculations,' but overall it is efficient and well-structured.

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 calculator with 8 fully documented parameters, the description adequately explains purpose, return values, and use cases. It does not mention edge cases like polar latitudes or error handling, but this is not critical given the schema coverage and annotations.

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 only repeats the 'all' parameter functionality already present in the schema for houseSystem, adding no new semantic meaning beyond what the schema property descriptions provide.

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

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

The description clearly states the tool calculates astrological house cusps using four named house systems. It explicitly lists return values (12 house cusps, Ascendant, Midheaven) and differentiates from sibling astrology tools by focusing on house cusps specifically.

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 clearly states this is for astrology charts, house cusp tables, and educational tools comparing house systems. However, it does not explicitly mention alternatives or when not to use it, though the narrow scope implies its specific use case.

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, so the safety profile is covered. The description adds useful behavioral detail about the true apogee shifting sign and turning retrograde, and mentions the retrograde flag in the output, going 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 two well-structured sentences, front-loaded with the core action and immediately distinguishing variants. Every word earns its place, with no fluff or repetition of schema content.

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

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

Despite complex parameters and no output schema, the description adequately explains what the tool returns (sign, degree, house, speed, etc.), clarifies the mean vs true difference, and states its intended use. Combined with full schema coverage and safe annotations, this is highly complete for a calculator 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 baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides; it focuses on output and purpose rather than parameter details.

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

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

The description clearly states the tool calculates Black Moon Lilith for any birth chart, explicitly distinguishing between mean and true apogee. It also lists the specific return values, making its purpose unambiguous and differentiating it from sibling astrology tools.

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

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

The description mentions it is 'built for natal astrology apps and AI agents' and focuses on Lilith, but it does not explicitly name alternative tools or state when not to use it. Context is clear, but exclusions are absent.

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?

With readOnlyHint=true and destructiveHint=false already provided, the description adds meaningful behavioral context: it explains that the map projects natal planets onto the local horizon and returns azimuths, altitudes, compass direction, above-horizon status, and waypoints. This goes beyond the annotations by describing the computation and output structure. It lacks mention of potential edge cases or limitations, hence a 4.

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 two sentences, front-loaded with the core function and output, then gives use cases. Every sentence earns its place with specific details; no 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?

The tool has 8 parameters and no output schema, but the description covers the core concept, output fields, and use cases. The schema fills in parameter details. It could arguably mention the 'include' extra bodies or language fallback, but these are in the schema. For an astrological computation tool, it is sufficiently complete.

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

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

The input schema covers 100% of parameters with detailed descriptions, including why 'time' is essential. The description does not need to enumerate parameters; it provides the conceptual frame. Baseline of 3 is appropriate since the schema does the heavy lifting.

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

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

The description uses the specific verb 'Generate' with the resource 'local space astrology map' and details the projections onto the local horizon. It clearly differentiates from sibling tools like post_astrology_astrocartography by focusing on compass directions and great-circle lines from the birthplace, and lists concrete outputs (azimuth, altitude, compass direction).

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 states 'Ideal for relocation planning, directional astrology, and travel-direction maps,' providing clear use cases. It does not explicitly name alternative tools or exclusions, so it falls below 5, but the context is 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?

Given readOnlyHint=true and destructiveHint=false in annotations, the safety profile is already clear. The description adds meaningful behavioral context: the exact return moment is computed, the chart includes specific elements, and the interpretation focuses on emotional and domestic themes. This goes beyond the annotation flags 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 front-loaded with a strong functional sentence and includes useful conceptual background about the lunar cycle. However, the final sentence 'Lunar return chart API, monthly horoscope forecast, Moon cycle chart, emotional astrology prediction' is repetitive keyword stuffing that adds no new information, costing a point.

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?

Despite lacking an output schema, the description explicitly names the chart's components (planetary positions, house cusps, aspects, Ascendant, Midheaven) and overall interpretative use. Combined with a highly detailed input schema, this is sufficient for an agent to understand what to expect and how to invoke the tool. Minor gaps like house system behavior are already covered in the schema.

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

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

Schema description coverage is 100%, so parameters like birthDate, returnDate, latitude, and longitude are already well documented. The description adds no new parameter-level details, but it does reinforce that the chart is cast for the lunar return location and uses natal Moon longitude. Baseline 3 is appropriate since schema carries the load.

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 'Generate a lunar return chart for any month' — a specific verb paired with an unambiguous resource. It clearly defines the astrological basis (exact moment transiting Moon returns to natal ecliptic longitude) and lists distinct deliverables (planetary positions, house cusps, aspects, Ascendant, Midheaven), setting it apart from sibling chart tools like solar_return or planetary_returns.

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 phrase 'primary technique for monthly astrological forecasting' provides clear usage context, implying this is for monthly emotional forecasts. However, it doesn't explicitly name alternatives or when-not-to-use scenarios, such as when a solar return or transits tool would be more appropriate. Still, the guidance is sufficient for an agent to select this for monthly forecasts.

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, covering the safety profile. The description adds useful output context (what celestial bodies, house systems, and aspects are returned) and the accuracy note ('Verified against NASA JPL Horizons'), but it does not disclose behavioral traits like rate limits, auth requirements, or side effects beyond what annotations cover. This is a solid 3 per the calibration example.

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 four concise sentences that are front-loaded with the primary purpose, followed by output details, use cases, and a credibility statement. Every sentence earns its place with no fluff or redundancy. It is appropriately sized for the tool's 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?

For a complex tool with 9 parameters, no output schema, and rich sibling context, the description is quite complete. It enumerates the key output elements (14 bodies, houses, aspects, angles), mentions customizable house systems, and provides verification context. It does not describe the exact response shape or error behavior, but the extensive parameter schema compensates for this, making this tool above average but slightly short of a 5.

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 has 100% description coverage, so the baseline is 3. The tool description adds no parameter-specific meaning beyond what the schema already provides (e.g., house systems are already described in the houseSystem parameter). The description's mention of house systems and celestial bodies is more about output than parameter semantics.

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: 'Calculate complete Western astrology natal chart (birth chart) with tropical zodiac.' It uses a specific verb ('calculate') and resource ('natal chart'), and differentiates from sibling tools by enumerating the full output scope (14 celestial bodies, 12 houses, aspects, etc.), making it distinct from tools like aspects-only or compatibility.

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 clear use-case context: 'Perfect for astrology apps, birth chart generators, horoscope websites, and astrological consultation tools.' This implies when to use the tool, but it does not explicitly exclude alternatives or name sibling tools for other purposes. Thus it has clear context without explicit exclusions, warranting a 4 rather than a 5.

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. The description adds valuable behavioral context: returns exact date/time of closest approach in timezone with both declinations, geocentric, verified against NASA JPL Horizons, and details about excluded bodies and node types. 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 fairly long (13 sentences) but each sentence adds value—defining concepts, explaining exclusions, default behavior, and use cases. It is front-loaded with the core purpose and structured logically. Minor room for trimming, but overall concise for the information conveyed.

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

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

Given no output schema, the description adequately covers return values (date/time of closest approach, both declinations). It explains the set of 13 bodies, geocentric basis, and verification. The sibling tool list (many astrology endpoints) and the description's clear differentiation (parallels vs. aspects, productivity uses) make the tool's niche very clear.

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 parameters. The description adds meaning by explaining the 'omit year and month' shortcut for current month in progress, which is not fully captured in the schema defaults. It also provides context for nodeType choice (mean vs. true).

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 'Get every parallel and contraparallel of declination that perfects during a given month,' specifying the verb and resource. It differentiates from siblings by explaining that parallels do not depend on zodiacal distance, distinguishing this from aspect-based tools like post_astrology_aspects_monthly.

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 use cases: 'Essential for declination work, out-of-bounds tracking, monthly forecast copy, and electional timing.' It also explains default behavior ('Omit year and month to get the month in progress') and why the Moon is excluded, though it does not explicitly name alternative tools for other scenarios.

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. The description adds behavioral context by stating the output includes a full tropical zodiac chart with planetary positions, house cusps, and aspects, which is relevant for invoking and using the tool. No contradictions with annotations were found.

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 body is front-loaded with the purpose and useful context, but the trailing sentence 'Planetary return chart API, Saturn return calculator, Jupiter return chart, Mars return forecast.' is redundant SEO-style keyword stuffing that adds no value. This padding reduces 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?

With no output schema, the description adequately summarizes return values by mentioning the full tropical zodiac chart with planetary positions, house cusps, and aspects. It also explains the astronomical phenomenon behind planetary returns. While it doesn't enumerate all output fields, the level of detail is sufficient for a tool of this complexity given the thorough schema.

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

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

Schema description coverage is 100%, so baseline is 3. The description's mention of cycle durations for planets is already present in the schema's planet parameter description, and no additional parameter-specific semantics are added beyond what the schema provides. Therefore, it neither harms nor significantly enhances parameter understanding.

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

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

The description clearly states the tool generates a planetary return chart for specific planets (Mercury, Venus, Mars, Jupiter, Saturn), which uniquely distinguishes it from sibling tools like solar_return and lunar_return. The explicit listing of supported planets and the emphasis on Saturn return provide precise scope and a clear action verb.

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 useful context by explaining each planet's return cycle and highlighting Saturn return as a major life milestone, implying when this tool is valuable. However, it does not explicitly compare to alternative tools (e.g., solar/lunar returns) or state when not to use it, so it falls short of full 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 this as read-only (readOnlyHint=true), and the description reinforces a non-destructive calculation. It adds meaningful detail about return data (longitude, latitude, zodiac sign, degree, daily motion, retrograde status), the tropical zodiac system, and a verification claim ('Verified against NASA JPL Horizons'), exceeding the annotation bar.

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 three sentences, front-loaded with the core calculation, then return data, use cases, and a credibility signal. Every sentence earns its place; no redundancy or boilerplate.

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 no output schema, the description takes on the task of describing what the caller will receive, and it lists return fields explicitly (longitude, latitude, zodiac sign, degree within sign, daily motion speed, retrograde status). It also clarifies the body set, date/location flexibility, and accuracy, making the tool's behavior fully understandable for a read-only calculator.

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 each parameter is thoroughly documented in the schema. The description's references to 'date, time, and location' are generic and add no additional parameter meaning beyond what the schema already provides, warranting the baseline score.

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 'Calculate accurate tropical zodiac positions for all 14 celestial bodies' – a specific verb, clear resource, and explicit scope that distinguishes it from sibling tools like post_astrology_asteroids or post_astrology_planets_monthly. The listing of the exact bodies (Sun through Pluto, lunar nodes, Chiron, Black Moon Lilith) leaves no ambiguity.

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

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

States it is 'Perfect for transit tracking, ephemeris tables, astrology apps, and planetary position widgets,' giving clear use-case context. It does not explicitly name alternative tools or exclusion criteria, but the use cases effectively imply when this general all-body ephemeris tool is appropriate.

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 as read-only and non-destructive; the description adds substantial behavioral context: positions are calculated at noon UTC, 'Omit year and month to get the month in progress', exact return fields (longitude, zodiac sign, degree, retrograde), and verification against NASA JPL Horizons. 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 front-loaded with the main action and scope, followed by return details, defaults, use cases, and verification. The keyword phrase 'Monthly ephemeris API, tropical position table...' is somewhat redundant with the opening, adding a small amount of wordiness that prevents a perfect score.

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

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

Even without an output schema, the description fully explains what the agent can expect: longitude, zodiac sign, degree within sign, retrograde status, calculated at noon UTC. It also covers default behavior, use cases, and verification source, making the tool fully actionable.

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

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

The input schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds meaningful nuance beyond the schema by explaining the omission pattern for year/month and the fixed noon-UTC calculation, which deepens the semantics of those optional parameters.

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 'Get daily tropical ecliptic positions for all 14 Western bodies... for an entire month', clearly stating the verb, resource, and scope. It distinguishes itself from sibling tools like post_astrology_planets (likely single-date positions) and monthly aspect/transit tools by emphasizing the month-long ephemeris table and the exact set of bodies.

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 clear contexts: 'Essential for ephemeris tables, transit tracking, retrograde calendars, and planetary movement charts' and explains the omit-year/month behavior for keeping a published ephemeris current. It does not explicitly name alternatives or when-not-to-use, but the use cases and default behavior make selection straightforward.

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. The description adds valuable behavioral context beyond that: it explains how the profection advances (completed years move the rising sign by one whole sign house) and enumerates the exact return values (age, profected house/sign, lord of the year with natal placement, plain language interpretation). It does not mention limitations like birth-time sensitivity or edge cases, so not a 5.

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

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

The description is three sentences that are front-loaded with the primary purpose, followed by the mechanism and output summary. Every sentence contributes meaning with no redundant or filler content, and wording is efficient.

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

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

With 10 parameters and no output schema, the description compensates by clearly stating the return values (age, house, sign, lord of the year, interpretation) and the calculation logic. It does not address optional parameters or edge cases, but those are covered in the schema's rich parameter descriptions. It is sufficiently complete for an agent to invoke 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% with each parameter having its own detailed description. The tool description itself adds little parameter-level meaning beyond the general mention of 'birth chart and target date' and the core calculation. Per the rubrics, baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states 'Calculate the annual profection and lord of the year' with a specific verb and resource, and differentiates from sibling tools by naming the Hellenistic time lord technique and defining distinct outputs (age, profected house/sign, lord of the year with natal placement, interpretation). This clearly distinguishes it from other post_astrology_* tools like progressions or transits.

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 clearly implies when to use this tool: when a user needs annual profections or the year's time lord for a birth chart and target date. It provides context via the calculation mechanics but does not explicitly name alternatives or state 'use X instead of Y'. With clear context and no exclusions, this earns a 4.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond annotations: it details the calculation method (day-for-a-year key), the exact output fields (sign, degree, whole-sign house, motion, retrograde state, progressed Ascendant/Midheaven), and the Naibod arc. This is transparent about what the tool computes and returns, exceeding the annotation baseline.

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 first three sentences are informative and front-loaded with the purpose. However, the final sentence is keyword stuffing ('Secondary progressions API, progressed chart calculator, ...') that repeats already-stated information without adding value for an AI agent. This redundancy prevents a higher score.

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

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

With no output schema, the description adequately explains what is returned (every progressed body, progressed Ascendant/Midheaven). It also provides astrological context for the progressed Sun/Moon. It is comprehensive enough for a read-only astrology calculation tool, though it does not cover edge cases like invalid dates or timezone handling (which the schema partially addresses).

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 each parameter is already documented. The description reinforces the core concept of targetDate via the day-for-a-year key but does not add new parameter-level meaning. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the tool generates a secondary progressed chart using the day-for-a-year key, which is a specific verb+resource+method. It also distinguishes from sibling tools by naming the unique output (progressed bodies, Ascendant, Midheaven) and the method (Naibod arc).

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 implies usage for progressed chart calculations (e.g., 'progressed Sun and Moon are the headline timing markers for inner growth and emotional chapters'), but it does not explicitly state when to prefer this over alternatives like transits, solar arc, or returns. No exclusions or direct comparisons to siblings are provided.

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. The description adds substantial behavioral detail: the birth moment stays the same, so planets keep their natal signs/degrees, while the Ascendant, Midheaven, Vertex, and all house cusps are recomputed for the new location. It also lists the specific outputs and includes a verification claim against NASA JPL Horizons.

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 five sentences, each earning its place: definition, mechanics, outputs, use cases, and verification. It is front-loaded with the primary purpose and avoids filler or repetition of structured fields.

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

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

For a tool with 10 parameters, 7 required, and no output schema, this description is very complete. It explains the calculation logic, lists all returned data (relocated houses/angles, planets that change house, angular planets, distance/direction), and provides use-case context. No critical information 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 10 parameters with detailed descriptions, including semantics like 'relocated Midheaven shifts roughly one degree per degree of longitude moved.' The description itself does not add new parameter-level meaning beyond what the schema already provides, so it earns the baseline score for 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?

The description opens with 'Calculate a relocation chart (relocated birth chart) for a new place on Earth,' which names the specific verb and resource. It further distinguishes the tool from siblings by explaining that only angles and houses are recomputed while planet positions remain fixed, making it clear this is not a natal chart or astrocartography 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 states it is 'Built for relocation astrology readings, astrocartography style move planning, and travel charts,' providing clear use cases. It does not explicitly list when not to use it or name an alternative tool, but the context is strong enough to guide an agent.

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

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

The description goes beyond the readOnlyHint annotation by explaining the calculation method (secondary-progressed Sun minus natal Sun), how every point is advanced, and what the output contains. It also notes it is based on accurate tropical positions. This adds meaningful behavioral 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 three sentences, front-loading the action and then explaining the concept and output. It is slightly verbose but every sentence adds necessary context for a specialized astrological tool. It is concise without sacrificing important explanatory 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?

Without an output schema, the description satisfactorily summarizes the return value (solar arc, directed points with longitudes, signs, degrees, interpretations). It explains the purpose, calculation, and use case, while the schema covers parameters. It lacks edge-case handling, but the schema includes defaults for unknown birth time, making the description reasonably complete.

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

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

All 9 parameters have descriptions in the schema, reaching 100% coverage, so the baseline is 3. The description adds conceptual understanding of the solar arc but does not detail individual parameters beyond what the schema already provides. Since the schema is thorough, this is adequate.

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 ('Calculate') and resource ('solar arc directed chart'), clearly distinguishing this from sibling tools like solar return or progressions. It also explains the core concept (one degree per year) and states the intended use case ('timing major life events'), making the 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 provides clear context for when to use this tool ('for predictive astrology apps timing major life events'), but it does not explicitly mention alternatives or when not to use it. Given the many sibling tools, explicit alternative guidance would be beneficial, but the context is sufficient for most 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?

With annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds meaningful behavioral context: the chart is cast for the exact moment of the Sun's return to its natal longitude, and it is location-sensitive, changing houses and Ascendant when relocated. It also states the output elements. This enriches the agent's understanding beyond what annotations provide.

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

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

The core purpose is front-loaded in the first sentence, which is good. However, the final sentence is a keyword list ('Solar return chart API, annual horoscope forecast, birthday chart calculator, yearly astrology prediction, relocated solar return.') that largely repeats already-stated information and does not earn its place. The description is slightly verbose but still structured and readable.

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

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

The description is quite complete for a complex tool with 9 parameters and no output schema. It explains what the chart returns (full tropical zodiac with positions, houses, aspects, Ascendant, Midheaven), how the calculation works, and the location-sensitive behavior. It lacks explicit exclusions or error conditions, but overall it gives an agent the essential context needed to invoke the tool correctly.

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

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

Schema coverage is 100%, so a baseline of 3 applies. The description adds value by reinforcing the significance of latitude/longitude (location-sensitive) and explicitly linking birthDate/birthTime to the natal Sun longitude used in the calculation. This helps the agent understand the role of key parameters without needing to infer it from 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 opens with 'Generate a solar return chart for any year', using a specific verb and resource. It clearly distinguishes this tool from siblings by explaining the exact calculation method (transiting Sun returns to natal ecliptic longitude) and listing the chart contents (planetary positions, house cusps, aspects, Ascendant, Midheaven). This makes it unambiguous as an annual forecasting 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 clear context: it is 'the foundational technique for annual astrological forecasting' and is used for birthday charts, annual horoscopes, and yearly predictions. It also notes location sensitivity, which informs when relocation matters. It does not explicitly name alternatives like lunar_return or state when not to use it, so it falls short of a 5 but is well above vague 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, so the safety profile is known. The description adds behavioral detail beyond annotations by explaining it 'Analyzes inter-chart aspects between all planets' and specifies the output includes a compatibility score, inter-aspects, counts, and dynamics. This provides useful context about what the tool does, with no contradiction.

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

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

The description is front-loaded with the core function and return summary, but includes some non-essential marketing language ('Perfect for dating apps...', 'Based on professional astrological techniques') that could be trimmed. Overall it is compact and well-structured, roughly 80 words covering purpose, outputs, and use cases.

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 person1/person2 objects, multiple parameters) and lack of an output schema, the description adequately explains the return values (compatibility score, inter-aspects, counts, dynamics) and the astrological basis. It does not discuss error conditions or limitations, but the schema covers required parameters, making the description sufficiently complete for a read-only 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?

The description does not add parameter-level explanations; it only mentions 'two natal charts' which maps to person1/person2. Schema description coverage is 60%, and the schema already contains detailed descriptions for all parameters, including nested objects. The tool description provides minimal added value beyond the schema, so 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 calculates 'complete synastry (relationship compatibility) between two natal charts' with a specific verb ('Calculate') and resource. It distinguishes itself from siblings like post_astrology_compatibility_score by emphasizing full inter-chart aspect analysis and relationship dynamics, not just a score.

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 clear usage context: 'Perfect for dating apps, matrimonial sites, relationship counseling tools, and astrology compatibility features.' It implies when to use this tool, but does not explicitly name alternatives or provide exclusion criteria compared to similar tools like post_astrology_compatibility_score.

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. The description adds meaningful behavioral context: it compares transit positions to the natal chart, returns aspect type, orb, applying/separating status, narrative interpretation, impact rating, and practical guidance. It does not discuss rate limits or auth, but the safety profile is covered by annotations and the output expectations are well communicated.

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 first two sentences are strong and information-dense, but the final string of keywords ('Transit aspects API, transit-to-natal analysis, predictive astrology, personalized transit forecast') is SEO filler that adds no decision value. The description would be stronger if it ended after the /transits comparison.

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?

This is a complex tool with 9 parameters, a nested natalChart object, and no output schema. The description compensates by listing the main return fields (aspect type, orb, applying/separating status, interpretation, impact rating, guidance) and differentiating the depth from /transits. It does not describe output shape or edge cases, but the parameter documentation is thorough.

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

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

Schema description coverage is 100%, with each parameter having a detailed description. The tool description adds high-level context about filtering (planets, aspect types), strength ratings, and timing, but does not add detail beyond what the schema already 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 'Calculate all transit-to-natal aspects with detailed interpretations' — a specific verb and resource. It clearly distinguishes this tool from siblings by highlighting detailed interpretations, strength ratings, timing guidance, and AI-friendly fields, and contrasts it with the /transits endpoint.

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?

It provides clear context: 'current (or future) planetary positions against your natal chart' and explicitly says 'More detailed than the /transits endpoint — includes AI-friendly interpretation fields.' This gives a direct alternative comparison, though it stops short of spelling out exhaustive when-to-use/when-not-to-use scenarios.

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, covering the safety profile. The description adds valuable behavioral context: returns all 14 bodies with signs, degrees, speeds, and when natal chart is provided, transit aspects with orbs and applying/separating status. 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?

Three sentences, front-loaded with the main purpose, followed by return details and use cases. Every sentence earns its place, and there is no repetition of schema or annotation information.

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

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

Given the tool's complexity (7 params, nested natalChart, 2 enums) and rich schema/annotations, the description adequately covers primary behavior, return content, and use cases. It does not explain everything (e.g., exact response shape without output schema), but that is not necessary given the depth of the schema.

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

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

Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds only a general 'When natal chart provided' mention, which is already implied by the schema's optional nested object. It does not provide additional parameter semantics beyond what the schema already offers.

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 'Calculate current or future planetary transits', a specific verb and resource, and immediately clarifies 'positions of all bodies now'. It distinguishes from siblings by highlighting optional natal-chart comparison and the specific output of 14 celestial bodies, which separates it from transits_monthly, transit_aspects, and planets.

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 clear use cases: 'Perfect for daily transit forecasts, aspect alerts, and personalized transit reports' and implies single-date or future-date scope. However, it does not explicitly name sibling alternatives or state when not to use it, so it falls short of full 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 read-only/non-destructive. The description adds meaningful behavior: the exact return shape (starting sign + ingresses), timezone-dependent output, default-to-current-month behavior, and verification against NASA JPL Horizons with equinox/solstice cross-checks. No contradictions.

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

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

The first sentence gets straight to the point, followed by return details, defaults, use cases, and verification. The keyword list at the end ('Monthly transit API...') is mildly redundant but not harmful. At ~160 words, it remains structured and front-loaded.

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

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

For a tool with no output schema, the description summarizes the return structure and default behavior. It covers use cases, accuracy guarantees, and timezone handling. Given six parameters and many sibling tools, this is sufficient for an agent to select and invoke it correctly.

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

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

All six parameters are described in the schema (100% coverage), including defaults and enum meanings (e.g., nodeType distinguishes mean vs true node). The description complements this by explaining why timezone matters ('what makes a published calendar read correctly for its audience') and how defaulting year/month works, but the schema already 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 opens with 'Get every tropical sign change for a given month, for all 14 Western bodies'—a specific verb, resource, and scope. It details the output (starting sign, each ingress with exact date/time) and names concrete use cases, distinguishing it from sibling transit tools like post_astrology_transits or post_astrology_aspects_monthly.

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 says 'Essential for transit calendars, monthly forecast copy, retrograde and ingress tracking, and newsletter automation,' providing clear when-to-use context. It also explains the omit-year-and-month default behavior for keeping published calendars current, though it doesn't name specific alternative tools to avoid.

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