Western Astrology MCP Server by RoxyAPI

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

Besides the readOnlyHint annotation, the description adds substantial behavioral detail: output is deterministic because no language model is involved, content rolls over at midnight by default UTC, and the same text is guaranteed for a given sign and date. It also discloses the fact-checking event list and language coverage, going far 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 core sentences are information-dense and front-loaded, covering purpose, output, determinism, and scheduling behavior. The definition loses a point by trailing off into redundant SEO-style keywords such as Daily horoscope API, zodiac forecast, sun sign horoscope, and astrology prediction, which add no agent 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?

Despite having no output schema, the description thoroughly enumerates returned content: overview, love, career, health, finance, advice, active transits, Moon sign and phase, energy rating, lucky number and color, and compatible signs. It also explains timezone handling, deterministic scheduling for future dates, and language behavior, giving an agent enough context to invoke and interpret the result 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 documents all five parameters with full descriptions, so the baseline is 3. The description reinforces the date and timezone semantics with editorial scheduling and local-clock rollover language, but it does not add meaningfully new parameter-level information beyond what the schema already provides.

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

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

The description opens with a concrete deliverable: a publish-ready column for any zodiac sign built from dated transits and returned with the underlying events for fact-checking. It clearly distinguishes the tool from weekly, monthly, and yearly sibling tools through the title, the daily rollover behavior, and its transit-based editorial approach.

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 operational guidance for when to customize invocation, such as passing a date for editorial scheduling or a timezone to roll over on a local clock. It does not explicitly name alternative sibling tools or state when not to use this tool, so it falls short of full exclusion-based 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 no contradiction exists. The description adds valuable behavioral guarantees beyond annotations: key dates are the exact New Moon, Full Moon, and retrograde instants ('never approximations'), and events can be verified against NASA JPL Horizons or USNO. It also discloses that the column includes all named aspects, ingresss, lunations, and stations read into whole-sign houses.

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 paragraphs are dense and informative, front-loading the main purpose and key data guarantees. However, the final sentence 'Monthly horoscope API, zodiac monthly forecast, astrology monthly prediction.' is redundant SEO-style keyword-stuffing that provides no agent-usable guidance. The description could be tighten with out losing 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?

With no output schema, the description carries the burden of explaining return content: prose, week-by-week breakdown, dated key dates with exact instants, and companion overview/love/career/heath/finance/advice sections. It also covers month selection, timezone semantics, and language availability. A explicit note on the JSON response shape would make it fully complete, but it is already strong and 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?

Schema description coverage is 100%, so the baseline of 3 applies. The description adds a useful note that any date inside a month retrieves that month and that timezone affects the 'current' period, but the schema already fully documents all five parameters including formats, defaults, and examples. The description does not need to repeat 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 states a specific service: a month-long horoscope column for any zodiac sign, including a week-by-week breakdown and dated key dates. The 'month-long' framing and final 'Monthly horoscope API' clearly distinguish it from the daily, weekly, and yearly sibling tools. The instruction 'Pass any date inside a month to retrieve that month' gives the agent a concrete retrieval pattern.

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?

Clear context is provided that this is the month-grade horoscope offering and how to select the target month with a date or timezone. It does not explicitly name the daily/weekly/yearly siblings or state when to prefer them, so it stops short of full alternative routing. The description still gives an agent enough context to pick this tool 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 and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond that: 'No language model is involved, so the same sign and week always returns the same text,' plus the editorial-check framing, per-sign uniqueness, and language availability.

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 content is front-loaded and informative, but it loses conciseness with the trailing keyword phrase 'Weekly horoscope API, zodiac weekly forecast, astrology weekly prediction,' which adds no agent value. Tightening the description by removing that final sentence would improve structure.

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

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

Because there is no output schema, the description carries the burden of describing return content, and it does enumerate overview, love, career, health, finance, advice, lucky days, lucky numbers, and compatible signs. It also covers date, timezone, and language behavior, leaving only minor gaps around response structure and the slight inconsistency between 'eight languages' and the ten enum values.

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

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

Schema coverage is 100%, so the baseline is 3. The description reinforces the date and timezone semantics ('Pass any date inside a week', 'timezone to roll over on a local clock'), but adds little meaning beyond what the schema already provides.

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

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

The description opens with 'A Monday to Sunday column for any zodiac sign,' which clearly identifies the resource and its weekly scope. It explains the return content (transits, dated events, sections) but does not explicitly contrast with the daily/monthly/yearly sibling tools, so differentiation relies on the title and the Monday-to-Sunday phrasing.

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 operational guidance: pass any date inside a week to retrieve that week, or use timezone to roll over on a local clock. However, it does not state when to choose this tool over get_astrology_horoscope_sign_daily, monthly, or yearly, nor does it mention 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 carry readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the output is a combination of prose and structured arrays, dated events are returned alongside the copy specifically so an editor can verify the piece, and coverage spans the whole year with house placements for eclipses and retrogrades.

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 opening sentence is dense but efficient, packing the entire output inventory into one list. The middle sentence on editor verification earns its place, and the year guidance is useful. However, the final sentence is pure SEO keyword filler ('Yearly horoscope API, year ahead astrology...') that adds no functional value for an AI agent and should be removed.

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 tool with no output schema, the description is highly complete: it names all major output components, explains the copy-versus-data relationship, gives the valid year range, documents default behavior, and covers language fallback in the schema. An agent can accurately predict both the call semantics and the shape of the response without needing additional documentation.

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 adds only a mild extra: it explains the purpose of the year parameter ('build an archive or a forecast ahead of time') and repeats the default-current-year behavior already in the schema. This is marginal added value, 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 opens with a specific verb and resource: 'Get the year ahead for any zodiac sign,' and then enumerates exactly what is returned—long-form column, structured arrays, themes, key periods, best months, eclipses, retrogrades. This clearly distinguishes it from the daily, weekly, and monthly sibling horoscope tools, and the term 'year ahead' / 'annual' reinforces the temporal scope.

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 frames when to use this tool—for yearly forecasts, archives, and ahead-of-time building—and explains the year parameter behavior ('Omit the year for the one in progress, or pass any year from 1900 to 2100'). However, it does not explicitly name daily/weekly/monthly alternatives or state when not to use it, relying instead on the tool name and siblings for exclusion.

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 output context about day-by-day phase and illumination data, but does not describe pagination, timezones, or response fidelity beyond that.

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

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

The description is short and front-loaded: a clear actioning first sentence and a pragmatic use-case second sentence. It is efficient, though the second sentence is phrased more like marketing than operational guidance, so a 5 is slightly too high.

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 nature and the fully self-documenting param schema, the description is almost sufficient. It tells the agent the response content (phase/illumination for each day), even with no output schema, but it does't specify per-day field names or common alternatives such as timezones or date formatting.

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 explanations, defaults, ranges, examples, and enum values. The description doesn't need to repeat parameter details, so it earns the baseline 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 clearly states a specific resource ('complete lunar calendar'), the scope ('every day of a specific month'), and what it contains ('moon phase and illumination'). This month-scoped behavior distinguishes it from the current/upcoming moon-phase sibling tools.

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

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

The description gives clear use context: 'creating moon phase calendars, lunar planners, and astrology event schedules.' It does not explicitly name alternative sibling tools or provide when-not-to-use guidance, so it falls just 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 established. The description adds useful context about what values the tool computes and returns (phase name, illumination, lunar age, zodiac sign, distance), but it does not disclose potential edge cases, timezone effects, or how the optional parameters affect the result beyond what the schema already describes.

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

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

The description is concise and front-loaded with the tool's core purpose and outputs. The phase-name enumeration is slightly verbose but useful because it disambiguates phase naming conventions. The final use-case sentence adds context but is arguably promotional rather than operational.

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 responsibility of explaining the return content; it does so by listing the computed fields and exact phase names. Given the simple read-only nature and the rich parameter schema, the description is sufficient for an agent to understand the tool's primary use, although it does not mention units for distance or detailed lunar-position naming.

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 every parameter already has a descriptive explanation with defaults and examples. The description adds no parameter-specific guidance beyond naming the core result fields, so it does not meaningfully compensate beyond the schema, which makes the baseline of 3 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 identifies a specific verb ('Get'), a precise resource ('current moon phase'), and enumerates the returned data (illumination percentage, lunar age, zodiac sign, distance, phase name). The word 'current' distinguishes it from sibling tools that target future phases or yearly/monthly calendars, so an agent can clearly tell what this tool provides.

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 through phrasing like 'Get current moon phase' and 'Perfect for moon tracking apps, lunar calendars, astrology widgets, and gardening by moon phase tools.' However, it does not explicitly contrast this tool with its siblings, such as get_astrology_moon_phase_upcoming 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 that it returns dates and phase names and scopes to upcoming transitions, which is useful but minimal; it doesn't disclose behavior beyond that (e.g., how far out the phases are computed). The description does not contradict 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 tight: it opens with the action and scope, briefly states the return content, and ends with a short use-case clause. No redundant phrasing or schema repetition. It could drop the somewhat generic 'Perfect for...' clause and still be complete, but it does not harm.

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 simple read-only list tool with no required parameters, all four parameters fully documented in the schema, and read-only annotations provided. The description covers the return content (dates and phase names), which offsets the missing output schema. It is complete for straightforward invocation, though it could note the relative time horizon of the results.

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 lang, count, compact, and startDate in detail, including defaults, bounds, and format. The description adds nothing about parameters, which is acceptable given the schema carries the full burden; baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Get upcoming moon phase transitions' with the enumerated phase types (New Moon, First Quarter, Full Moon, Last Quarter). The temporal scope 'next weeks/months' and the title 'Next new moon, full moon, quarters' effectively distinguish this from the sibling tools get_astrology_moon_phase_current and get_astrology_moon_phase_calendar_year_month, so an agent can tell them apart.

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 use-case context ('Perfect for lunar event calendars, moon phase widgets, and astrology planning tools'), which gives a sense of when it is appropriate. However, it never names any sibling alternative nor states when NOT to use it, so the agent must infer the boundary against the calendar/current phase tools on its own.

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 this a read-only, non-destructive operation, and the description does not contradiction them. It adds behavioral scope: the tool deliberately returns the full set of 14 bodies and defines exactly what 'meaning' contains (symbol, tagine, category, ruling sign), so an agent can predict response shape and cardinality.

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 is dense and front-loads the main value. However, the sentence 'Perfect for astrology reference apps, planet meaning widgets, ...' is a largely redundant use-case list that does not help an agent call the tool more precisely. One useful sentence plus a partial-purpose sentence; compact but with minor 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?

For a no-required-parameter, read-only list operation, the description and schema together cover invocation, output scope, language switches, compact mode, and where to go for deeper data. No output schema is needed because the description already marks the fields expected. Nothing important is missing.

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

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

Schema coverage is 100%, with both parameters thoroughly explained in the schema: lang includes a full list of codes, a default, and a translation-fallback behavior, and compact describes the columnar output shape. The description contributes no parameter-level information, but the schema handles that responsibility, which supports the baseline 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 opens with a precise verb ('Returns') and a specific resource ('all 14 astrological bodies') and enumerates its exact contents (Sun through Pluto, lunar nodes, Chiron, Black Moon Lilith) plus the fields returned. It is clearly distinct from the sibling that fetches a single planet profile, so purpose ambiguity is low.

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 states the use cases for the list tool and explicitly names the alternative endpoint for more detailed data: 'Use GET /planet-meanings/{id} for complete profiles with detailed interpretations, keywords, temperature, and dignities'. This gives an agent a clear selection rule between the list and the detail endpoint.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so a safe read is understood. The description adds meaningful behavioral context by spelling out exactly what data is returned: symbol, tagline, category, dignity, keywords, etc. It does not mention rate limits or auth, but for a read-only lookup tool the transparency level is strong.

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 opens with the core action and resource, then gives a useful field list, and ends with usage examples. The use-case enumeration is slightly long and somewhat redundant, but it remains front-loaded and readable. It is appropriately sized for a tool that returns rich astrology data.

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 must convey return semantics, and it does well by listing many of the expected fields and value types. It also clarifies how id and name inputs work. Minor gaps, such as explicit language fallback behavior and a stronger separation from sibling endpoints, are slightly missing, but the overall picture is complete enough for an agent.

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

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

The input schema has 100% coverage with detailed descriptions for all three parameters, including BCP47 language support and compact-shape semantics. The description repeats only a fragment of the id parameter's behavior and adds no new information beyond the schema. Since the schema already carries the parameter semantics, 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 specific verb ('Retrieve'), a clear resource ('comprehensive planet interpretation'), and a distinct input contract (lowercase ID or case-insensitive name). It also lists the exact data fields returned, making the tool's purpose immediately recognizable and distinguishable from a generic list or sign-related 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 gives practical use cases like 'birth chart readings', 'planet meaning lookups', and 'transit meanings', making it clear when to use this tool. However, it does not explicitly distinguish itself from the sibling 'get_astrology_planet_meanings' or state when the plural variant should be used instead, so it stops short of full 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 provide readOnlyHint=true and destructiveHint=false, covering side-effect safety. The description adds useful context about scope ('tropical zodiac signs') and what data is included, but it does not disclose other behavioral traits like possible language fallback behavior or latency concerns. Given the safety profile is covered, this is adequate but not beyond what annotations already imply.

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 action ('Returns all 12 tropical zodiac signs'), follows with concise parameter-relevant info and use cases, and ends with the sibling alternative. The full list of suns is verbose but useful for agent recognition, and every sentence earns its place. 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 no output schema, so the description does a good job stating it returns the requested fields. It covers scope, signing list complete. The `lang` and `compact` behavior are only captured in the schema, but the description doesn't need to repeat schema-covered biases. It also clearly points to the detail endpoint for complete profiles. Missing only minor financial usage constraints, but those are well covered by annotations and 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?

The schema description coverage is 100%: both `lang` and `compact` have thorough descriptions in the schema, so the tool description adds no new parameter insight. It does not mention that `lang` or `compact` exist, but the schema fully covers their semantics, 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 an exact action and resource: 'Returns all 12 tropical zodiac signs' and lists every one of them. It names the exact fields returned (name, symbol, element, date ranges, short descriptions), and explicitly distinguishes it from the sibling 'GET /signs/{id}' endpoint for detailed profiles. This leaves no ambiguity about the tool's role.

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 a range of concrete use cases ('zodiac sign lists, horoscope widgets, birth chart calculators, astrology app...') and explicitly says to use GET /signs/{id} when full profiles with personality traits are needed. This is a clear when to use/alternatives guidance, leaving no doubt about when this listing is preferred.

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 that lang parameter can return English fallback per field with no translation, and that compact returns lossless token savings — both are behavioral details beyond the schema that help an agent predict behavior. It does not it does not mention the possibility of invalid sign output, but that's a minor gap.

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

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

The description is one substantial paragraph with high information density. It front-loads the core action, then the output fields, and the use cases at the end. Nothing is duplicative of the schema; every sentence adds something. It is somewhat lengthy, but comprehensively informative.

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

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

The description is complete for a read-only retrieval tool: it lists all returned content categories, parameter handling, language behavior, fallback translation, compact mode, and typical use cases. Combined with the annotations (readOnlyHint) and the absence of an output schema, there's nothing important missing. Edge cases like invalid sign are not documented, but the description's rich detail exceeds the minimum.

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 elaborates on the id parameter by giving examples ('aries', 'Aries', 'ARIES') and explains response content per language. The description also explains what compact does more clearly than the schema (lossless, 40-52% token savings). It therefore adds value on top of a fully self-documenting schema, so above baseline 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 clearly states the tool retrieves comprehensive zodiac sign information for any astrological sign using lowercase ID or case-insensitive name. It enumerates the specific fields returned (element, modality, ruling planet, etc.), which distinguishes it from the sibling get_astrology_signs (likely a list) and the horoscope/moon-phase tools. The verb 'retrieve' signals a read operation.

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

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

The description does not explicitly name alternatives or exclusions, but it does say what the tool is for, listing use cases like horoscope readings, compatibility checks, and birth chart interpretations. Given the sibling list, any tool whose name contains 'sign_id' is clearly the singular-profile variant, while the others are daily/weekly/monthly horoscopes or power calculations. It could be stronger by explicitly saying 'not for daily horoscopes' but the context signals are enough.

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

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

The annotations already cover readOnlyHint and destructiveHint. The description adds behavioral detail beyond that: the arc-from-Ascendant method, automatic day/night formula based on chart sect, the tropical position basis, and the exact return fields (sign, degree, longitude, arc, interpretation). No contradiction with annotations.

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

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

Three—sentence description starts with purpose, then method, then returns. Almost every clause carries useful information, though the closing 'Built on accurate tropical positions, no astronomy expertise needed' is slightly redundant and could compress.

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 spelling out the return fields (sign, degree, exact longitude, arc, interpretation) and the calculation mechanism. It doesn't describe the exact JSON response shape, but a high-level parameter description and behavior are enough for a well-typed API.

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

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

Schema coverage is 100%, so the baseline of 3 applies. The description doesn't add parameter-specific detail beyond the schema, but the schema itself already documents each field thoroughly, so agent needs are met.

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 states a specific verb 'Calculate' and identifies a precise resource: the seven Hermetic lots (Arabic parts), listing every one of them (Part of Fortune, Part of Spirit, Eros, Necessity, Courage, Victory, Nemesis). This creates a clear, easily distinguishable purpose among the many sibling astrology tools.

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

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

Provides clear usage context: 'any birth moment' and 'for Hellenistic and traditional astrology apps'. However, it doesn't name alternatives or give explicit when-not-to-use conditions, so it falls just short of the highest tier.

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?

goes well beyond the readOnly/destructive annotations: it discloses the pattern payload (tightness score 0-100, dissociassociate flag, one-line interpretation) and, more valuably, the built-in suppression algorithm — a Grande Cross suppresses its contained T-squares and a Kite suppresses its underlying Grande Trine. An agent otherwise could not predict that some patterns are intentionally omitted from the output. Remaining undisceclosed: behavior when no patterns exist and output ordering.

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 payload and disambiguation information is information-conceptually dense and frontLoaded — the verb+resource is first. However, the enumptions of pattern names duplicates the title, and the closing list of 'useful for' use-cases reinforces the usage guideline at the cost of a little redundancy, making it slightly longer than necessary.

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 10-parameter tool with no output schema, the description lists the data each pattern carries but never specifies the response shape — whether the result is a top-level array, an object keyed by pattern type, or how an empty chord (no patterns found) is represented. Required parameters are birth-data only and are fully schema-described, so the call can be made correctly; the ambiguity is in the return contract and edge cases.

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 has a detailed description, defaults, enums, and a concrete example (the schema's nodeType explanation about true vs. mean is exceptionally complete). The description itself adds nothing about parameters, so the baseline 3 applies: the schema carries the full 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 first sentence states a specific verb ('Identify') and a specific scope ('multi-plant configurations in a birth chart'), then enumerates all seven pattern types it handles. This clearly separates it from sibling tools like post_astrology_aspects (pairwise?) and post_astrology_natal_chart, which the tool list shows as separate resources — an agent can pick this tool without opening the schema.

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

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

The final sentence names concrete use cases ('personalized atal report engines' 'astrology chatbots' chart pattern callouts'), giving clear when-to-use context. However, it does not explicitly name sibling alternatives it competes with (e.g., post_astrology_aspects for pairwise aspects, post_astrology_natal_chart for the full chart) or 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?

The description goes beyond the read-only annotations by revealing the output shape: aspect type, exact angle, orb, applying/separating status, and strength (0-100). It also discloses the calculation basis ('standard Western astrology orbs'). This gives an agent a clear behavioral model without hidden surprises.

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 most discriminating detail—'any date and time'—is front-loaded, and every following sentence contributes either an example aspect, output fields, filter capability, or use cases. It could be tightened slightly by cutting the partially redundant 'Finds conjunctions...' sentence, but it is still well shaped.

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 no output schema, the description covers primary returned fields and the orb standard, and the schema carries the parameter constraints. The main missing precision is the full list of minor aspects and an explicit routing note that differentiates e.g., aspects_monthly or transit_aspect from this call, so it is solid but not maximally 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?

Since the schema covers 100% of the parameters with detailed examples and typical descriptions (date format, decimal timezone, language enum, compact shape), the description largely does not need to add parameter-level meaning. It only glosses the filters and does not introduce new 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 says 'Calculate all major and minor aspects between planets for any date and time,' naming a precise action, resource, and temporal scope. The list of aspect degrees makes the tool immediately recognizable and differentiates it from the monthly aspect and pattern detection 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?

It provides clear context by anchoring the tool to a user-supplied date/time and names typical use cases such as aspect tables and transit analysis. It does not explicitly say 'use X instead when…', so it falls just short of the explicit exclusion bar.

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 this is a read-only, non-destructive operation, so the bar is lower. The description then adds meaningful behavioral detail: exact times for closest approach in the selected timezone, tropical longitudes, traditional orbs, exclusion of the Moon, and the fact that omitting year/month serves the current month so pasted calendars stay fresh. The catalog appears to be verified against JPL Horizons. Nothing about the behavior is hidden or contradicts 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 main behavior is front-loaded in the first sentence, followed by a logical order: scope, aspects, method, coordinate system, exclusions, default behavior, use cases. It is dense but not bloated. The trailing line 'Monthly aspect calendar API, exact aspect times, planetary aspect ephemeris, transit timing' reads like keyword stuffing and does not earn its place; that keeps it from a 5.

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 stating that the response includes exact date and time, the timezone, and the nature of each aspect. It also covers defaults, limits, exclusions, bodies, and coordinate system. It does not provide an example output shape or total response structure, which would make it fully complete, but for a compute-only, read-only monthly calendar API the description leaves an agent well-equipped.

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 explains lang, year, month, compact, nodeType, and timezone. The description primarily reinforces two of those (current month defaults and local timezone) without adding new parameter-level insight. It does not compensate beyond the schema, so the baseline 3 is appropriate.

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

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

The description states a clear action and resource: 'Get every planetary aspect that perfects during a given month', and then enumerates the covered bodies, aspect types, and calculation basis. It is far more specific than the tool name alone and implicitly distinguishes itself from single-date or broader astrology endpoints. An agent can form an accurate expectation without opening the schema.

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

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

The description names concrete use cases: monthly forecast copy, transit calendars, electional timing, and newsletter automation. It also explains the Moon's exclusions by saying it 'belongs in a daily view rather than a monthly one', which is an implicit when-not-to-use signal. It does not explicitly point to alternative sibling tools, so it stops short of a full routing guideline.

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 state read-only safety, so the bar is lower. The description adds real behavioral detail by enumerating the returned fields for each asteroid: zodiacsign, degree, house, speed, retrogade status, and interpretation. It also discloses that Chiron is intentionally absent, shaping expectations before the user calls the tool.

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

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

The description is two informative sentences, front-loading the purpose and then adding output composition and endpoint distinction. Every sentence contributes distinct value, and there is no filler or redundant restating of the tool name.

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?

Since there is no output schema, the description compensates by naming the returned per-asteroid fields. It also gives a clear scope boundary (four asteroid goddesses, Chiron excluded) and typical use case. It doesn't explain every context, but the rich input schema covers remaining detail.

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

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

Schema description coverage is 100%, so structured schemas already fully define every parameter. The description does not add paramter-level meaning beyond what schemas fields provide. Thus the appropriate baseline is 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 uses a specific verb 'Calculate' and names the exact resource: natal positions of Ceres, Pallas, Juno, and Vesta. It even lists the returned fields, making the tool's purpose unmistakable. It also explicitly distinguishes itself from the natal chart endpoint by noting Chiron is available there, which differentates it from a likely sibling.

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: 'for natal reports and relationship astrology' and directs users needing Chiron to the natal chart endpoint. It names one concrete alternative and tells when this endpoint is the better fit. It does not exhaustively compare against other natal chart tools, hence not 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so no safety contradiction exists. The description adds useful behavioral context by specifying exact return contents, such as right ascension, declination, two meridian line longitudes, sampled rising/setting curves, and per-line interpretation, which is beyond the annotation coverage.

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

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

The description is only three sentences, each earning its place: the first gives the primary action, the second defines map meaning and context, and the third enumerates the output payload. It front-loads the main purpose and avoids redundant detail.

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 9-parameter tool with no output schema, the description appropriately notes what the returned data will contain, which partially fills the absent output schema gap. It does not mention optional parameters such as include, compact, or lang, but those are already well-explained in the input schema, so the description is adequate though not exhaustive.

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 documents all 9 parameters with detailed descriptions, giving 100% schema_description_coverage, so per rubric the baseline is 3. The description's prose does not directly document parameters, but it adds thematic clarity around what the map represents, which is helpful context without compensating for parameter specifics.

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

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

The description states a specific verb ('generate'), a specific resource (astrocartography map), and the concrete angle types (Midheaven, Imum Coeli, Ascendant, Descendant). It distinguishes the tool from sibling chart tools by clarifying the astrocartography domain and the birth-moment input requirement.

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 'for any birth moment' implies this tool is for relocation/astro mapping calculations at birth, and the definition of planetary lines provides context. However, it gives no explicit guidance about when to use this tool versus siblings like post_astrology_local_space or post_astrology_relocation_chart, leaving an agent to infer usage boundaries.

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 no safety caveats are needed. The description adds useful behavioral context beyond that: the computational basis (Western synastry/inter-chart aspects), the score range, the five category breakdowns, and the inclusion of narratives, element balance, archetype classification, and significant aspects.

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

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

The description is a single dense paragraph that front-loads the core purpose and result, then lists the included analyses. It is longer than minimal but every clause adds a distinct output or methodology detail, making the length justified for a report-style astrology endpoint.

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 burden of explaining return contents, and it does so thoroughly: overall score, category breakdowns, specific planetary-pair logic, narratives, element balance, archetype, and key aspects. The input schema covers all parameter semantics, and annotations cover the safety profile, so nothing needed for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents person1, person2, lang, and compact thoroughly. The description reinforces the 'two birth charts' concept and explains which planetary pairs matter, but it does not add parameter-format or usage details beyond what the schema provides, matching the baseline for full 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 names a specific verb ('Calculate'), a precise resource ('compatibility score between two birth charts'), and a clear method ('Western synastry'). It does not explicitly name and differentiate from sibling post_astrology_synastry, but the focus on a 0-100 score with category breakdowns makes the tool's purpose distinct.

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

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

The usage context is implied: use this when an overall compatibility score plus breakdowns is needed. However, the description never explicitly says when to prefer this over sibling post_astrology_synastry or other chart-comparison tools, and it gives no exclusions or routing 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 convey read-only, non-destructive behavior, so the description only needed to add behavioral context. It does so by specifying that all chart points are computed as midpoints and by stating the invariant that the Ascendant sits on the first cusp, which usefully signals the exact calculation approach.

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 several sentences earn their place by explaining the method, result, and return contents. However, the final sentence is a loose keyword list ('Composite chart API, midpoint relationship calculator, relationship astrology, couple chart analysis') that adds no functional guidance for an agent and slightly dilutes an otherwise clear 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 description lists the principal returned components: planetary positions, house cusps, Ascendant, Midheaven, aspects, and relationship interpretation. Since no output schema exists, this return summary is valuable. Combined with the rich parameter schema and read-only annotations, an agent has sufficient context to select and invoke the 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%, and every parameter already has a rich description including defaults, formats, and examples. The tool description adds little parameter-level detail beyond referring generally to two natal charts and the midpoint method, so it does not significantly exceed what the schema already provides.

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

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

The description clearly states a specific action ('Generate') on a specific resource ('composite chart') and gives the midpoint method. It also distinguishes this tool from synastry/compatibility siblings by emphasizing that the composite chart represents the relationship as a single entity rather than comparing two charts.

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: whenever a midpoint-based relationship chart is needed. It does not explicitly name alternatives or say 'use this instead of synastry', so it falls short of full routing guidance, but the semantic distinction between relationship-as-a-single-entity and other relationship chart types is effectively implied.

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

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

Annotations indicate read-only/non-destructive behavior, and the description adds meaningful behavior: the Sun and lunar nodes are excluded, crossings are exact positions rather than near approaches, and data is validated against NASA JPL Horizons. It also explains the eclipse-relevant consequence of lunar node coincidences.

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 body opening smoothly states the scope and use-case, followed by important clarifications. The final keyword phrase, 'Ecliptic crossing API, planetary node passage, ascending and descending nodes,' is largely redundant SEO filler repeating the topic and the body scope, preventing 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 specifies what will be returned—exact date/time, timezone, tropical longitude, and sign—and explains the body set. Combined with the full input schema and use-case guidance, this is 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 covers 100% of parameters with descriptions, examples, ranges, defaults, and enum values. The description only reiterates general timezone and return-value ideas without adding semantic nuance; the schema already carries parameter documentation.

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

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

The description states the exact operation: it captures every moment a body crosses the ecliptic during a year, names the bodies involved, and defines ascending vs. descending node passages. This clearly differentiates the tool from all astrology siblings, especially node-related queries.

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 gives explicit usage context: 'essential for eclipse-season work, node-based timing, and astronomical calendars.' It does not explicitly list exclusions or alternatives, and there are no close sibling-tools for this specific calculation, so the guidance is clear enough.

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 give exactly read/destructive hints, and the description goes well beyond them by disclosing each star's output and that each conjunction comes with a plain-language interpretation in the selected orb. This gives the agent a concrete model of the tool's behavior and return shape.

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

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

Three sentences that front-load the main operational purpose, then list return details, and close with the use case. It is tidy, but there is slight redundancy between the groups of stars and the additional relisting of the five star names, so it isn't perfect.

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 schema that already covers all parameters and a description that covers output details and orb sensitivity, an agent can select and invoke the tool confidently. No output schema is needed because the return semantics are fully described in prose.

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 offers 100% description coverage of all 9 parameters, so the baseline is 3. The description adds little to the parameter disambiguation; its only related note is 'chosen orb', which is indirectly redundant with the orb parameter's well-documented definition.

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

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

The description begins with a specific action and resource: 'Calculate the tropical zodiac positions of the major named fixed stars' and then states the exact use, detection of conjunctions to planets, Ascendant, and Midheaven. The list of star and the phrase 'focused tool for natal reports' distinguishes it from the many other astrological siblings without needing to open the schema.

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

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

The description makes the intended context clear: 'a focused tool for natal reports' that weighs Regulus, Spica, Aldebaran, Antares, and Algol against the chart. It does not explicitly name alternatives or when not to use it (e.g., not for planetary positions alone), so it stops short of a full usage guideline.

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 established. The description adds value by stating the return shape (12 cusps, signs, degrees, Ascendant, MC) and the 'all' comparison mode, which goes beyond structured annotations. It does not, however, disclose potential failure modes or precision caveats in the description itself, keeping it in line with the baseline for annotation-backed tools.

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 sentences, with the core behavior and return values stated upfront. The 'Perfect for...' sentence is somewhat promotional but does convey target use cases. Overall it is compact, well-organized, and front-loaded, with no redundant restatement of the tool name.

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 8 parameters, high schema coverage, and no output schema, the description compensates by clearly describing the output: all 12 house cusps, signs, degrees, Ascendant, and Midheaven. It also explains the 'all' comparison mode, which is a key behavior. With annotations covering safety, an agent has enough context to invoke the tool correctly, though a note on error behavior would round it out.

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 already individually documented. The description reinforces the meaning of the 'all' parameter ('compare all 4 house systems side-by-side for educational purposes'), but this is also covered in the houseSystem parameter description. The description adds little beyond the schema, so the baseline of 3 is appropriate.

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

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

The description gives a clear verb and resource: 'Calculate astrological house cusps' using specific systems, and lists the returned data (12 house cusps, Ascendant, Midheaven). This makes the tool's function unambiguous. However, it does not explicitly differentiate itself from overlapping siblings like post_astrology_natal_chart, so it stops short of full sibling distinction.

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 through 'Perfect for astrology charts, house cusp tables, and educational tools showing house system differences,' which gives a sense of context. But it never states when NOT to use this tool or names alternatives (e.g., 'for a full chart use post_astrology_natal_chart'). Usage guidance remains implicit 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 already say readOnly=true and destructive=false; the description adds behavior (true apogee can shift sign and turn retro, mean is steady) and mentions the output fields. This goes beyond the structured hints and helps the agent understand calm, although rate limits and exact limitations are not covered.

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 with the primary result front-loaded; no redundant parameter repetition. The second-half 'wild, suppressed, and reclaimed self' flavor adds context but is slightly decorative rather than operational.

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?

Because there is no output schema, it is valuable—and unusual—that the description names the returned values: sign, degree, house, longitude, latitude, speed, retro flag, and interpretation. Combined with dense input-schema docs, the agent has most of what it needs; the missing piece is a clear mapping between description and nodeType.

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

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

Schema description coverage is 100%, so the input schema already does the heavy lifting for all 9 parameters. The description's mean/true discussion supports nodeType conceptually but does not clarify how nodeType maps to the Lilith/apogee variants, and the schema's own nodeType text mentions North/South Nodes, which is slightly confusing.

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 precise verb and resource: calculate Black Moon Lilith for a birth chart. It also distinguishes the mean vs true lunar apogee and enumerates returned fields (sign, degree, house, speed, retro flag, interpretation). This makes the tool unmistakable among the large sibling set.

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

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

The phrasing 'for any birth chart' and 'Built for natal apps and AI...' gives a clear invocation copn text and target audience. It does not explicitly compare with alternatives like post_astrology_natal_chart, so 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?

The description adds meaningful behavioral details beyond the readOnlyHint/destructiveHint annotations, such as returned azimuth, altitude, 16-point compass sector, and waypoint output. It clearly describes the computational outcome 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 compact yet complete, with each sentence adding a distinct purpose: what the tool generates, what it returns, and when to use it. The key output vocabulary ('longitude', 'altitude', 'waypoints') is front-loaded, allowing an agent to grasp behavior quickly.

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 no output schema, the description does a fair job of disclosing return field meanings and directionality. It also covers main use cases and indicates which bodies are used via the schema. Slightly unequipped for error cases or optional body behavior, but these are minor given other structured metadata at 100% 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 description coverage is 100%, so the input schema already documents every parameter. The MCP description adds conceptual framing like 'lag and longitude waypoints' and 'geocentric lines radiating from birthplace,' but it does not enrich individual parameter meanings, keeping this at 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 a specific verb and resource—'Generate a local space astrology map'—and goes into concrete detail about what is produced: azimuth, altitude, compass direction, horizon status, and line waypoints. The tool name, title, and description all reinforce the same distinct purpose, separating it from siblings like astrocartography by emphasizing 'local horizon' and 'radiating from the birthplace'.

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 closing sentence clearly states the intended use cases: 'Ideal for relocation planning, directional astrology, and travel-direction maps.' This provides contextual guidance for when to use the tool, though it does not explicitly contrast it against the sibling astrocartography or relocation tools, nor does it say when this tool should not be used.

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

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

The annotations already establish readOnlyHint=true and destructiveHint=false, so the tool's safety profile is covered structurally. The description adds meaningful behavioral context beyond that: it explains the exact lunar return moment, the ~27.3 day cycle, and exactly what the chart contains (planetary positions, house cusps, aspects, Ascendant, Midheaven). This helps an agent predict what will happen when the tool runs.

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

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

The purpose is front-loaded and the main clauses are informative. However, the final sentence is a keyword-stuffed tail: 'Lunar return chart API, monthly horoscope forecast, Moon cycle chart, emotional astrology prediction.' It repeats the title and earlier content and does not earn its place, making the description somewhat longer than needed.

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 fairly complex astrological tool with no output schema, the description does enough to set expectations by listing not only the chart type but the specific chart contents returned. It explains the time-position basis for choosing the returnDate and the emotional/domestic focus. It does not describe any error conditions, but parameter schema already documents the constraints and required fields.

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

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

Schema description coverage is 100% and the parameter descriptions are already rich, including constraints, defaults, formats, and examples for all nine parameters. The description adds astrological context about the lunar cycle but not meaningfully new parameter semantics. Baseline 3 is appropriate because the schema bears the burden of explaining 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?

Opens with specific verb and resource: 'Generate a lunar return chart for any month, cast for the exact moment the transiting Moon returns to its natal ecliptic longitude.' It clearly differentiates itself from solar, planetary, and natal chart siblings by naming the return type and the exact calculation premise. The additional description of chart contents—planetary positions, house cusps, aspects, Ascendant, and Midheaven—further removes what the tool does.

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

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

Clear context is provided: this is 'the primary technique for monthly astrological forecasting' and the chart reveals themes 'for the coming month.' That tells an agent when lunar-return is appropriate. It does not explicitly name alternatives like solar-return for annual forecasts or natal chart for birth interpretation, so it does not fully satisfy the explicit when-to-use-vs-alternatives standard.

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 confirm readOnly and not destructive, so the safety profile is covered. The description adds relevant method disclosures: it uses the tropical zodiac, supports customizable house systems, and is validated against NASA JPL Horizons. No contradiction with annotations exists.

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

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

The description is compact and front-loads the core purpose: 'Calculate complete Western astrology natal chart'. The following clauses list output items in a structured, readable way. The 'Perfect for...' sentence is borderline marketing, but it does not repeat schema or waste much space.

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?

Since there is no output schema, the description carries the burden of informing the agent what data to expect, and it does that by listing celestial bodies, house cusps, aspects, Ascendant, Midheaven, and dominants. Input requirements are fully covered by the schema. It omits possible error behavior or response structure details, but that is minor for a read-only computation API.

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 across all 9 parameters, so the description does not need to duplicate parameter details. It adds context by naming the house-system choices, but it does not add meaning beyond what the schema already offers. 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?

Uses a specific verb ('Calculate') and resource ('complete Western astrology natal chart'), and enumerates concrete output components: 14 celestial bodies, 12 house cusps, aspects, Ascendant, Midheaven, and dominants. This clearly distinguishes it from sibling tools like post_astrology_planets or post_astrology_aspects, which cover only subsets.

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 this is the comprehensive natal-chart endpoint by saying 'complete' and listing full chart elements, but it never explicitly states when to use this tool versus specialized siblings like post_astrology_planets or post_astrology_houses. There is context, but no exclusions or alternative routing.

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

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

Beyond the readOnlyHint and destructiveHint annotations, it discloses meaningful behavior: geocentric declinations, exclusion of the Moon, the use of month-in-progress defaults when year and month are omitted, timezone-dependent reporting, and the verified source. This is substantial additional context.

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

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

The core function and scope are front-loaded, and most details earn their place. The description loses a little polish near the end with tag-like phrases such as 'Monthly parallel calendar API, declination aspects, contraparallel ephemeris' and the verification claim, which are not necessary for tool selection.

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 still explains what will be returned: exact date and time of closest approach, both declinations, in the requested timezone. It also clarifies the full body set and why the Moon is excluded, giving an agent enough context to invoke it correctly and interpret results.

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

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

Schema description coverage is 100%, so the input schema already documents all seven optional parameters thoroughly. The prose adds only contextual behaviors, such as timezone-aware output and month defaults, rather than materially deepening any individual parameter meaning. The baseline 3 is therefore 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: 'Get every parallel and contraparallel of declination that perfects during a given month', then enumerates the exact 13 bodies it covers. It also distinguishes itself from aspect tools by explaining that these contacts surface connections an aspect table cannot show.

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 gives clear decision contexts: use this for declination contacts, out-of-bounds tracking, monthly forecast copy, electional timing, and reading these contacts alongside zodiacal aspects. It does not explicitly name sibling tools or state a 'when-not-to-use' condition, but the context is clear enough for an agent to select 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 say readOnlyHint=true, and destructive=false, and the description aligns: it generates and returns a chart. It also discloses important behavior not covered by the annotations: the result is a full tropical zodiac chart with 'planetary positions, house cusps, and aspects.' This gives an agent a realistic phrase of what the call returns, and there is no contradictory claim.

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 opening sentence is front-loaded and actionable, and the first few sentences define the tool's purpose and use cases. However, the final clause—'Planetary return chart API, Saturn return calculator, Jupiter return chart, Mars return forecast'—is redundant keyword style that repeats what has already been said. It does not earn its place in an otherwise direct 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 10 parameters, 7 required, no output schema, and many sibling chart/divination tools, a description needs to cover both the choice and the returned result. This one does: it specifies the chart, the planets, the output's content (planets, houses, aspects), and the astronomical event logic. The schema covers the remaining parameter details, and the description is enough for an agent to select and invoke it correctly with a small gap around no explicit mention that solar/lunar returns are handled by separate sibling tools.

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

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

The input schema covers all 10 parameters with detailed descriptions, so the baseline is 3. The description does add some interpretive color for parameter choices, such as 'Jupiter return (~12 years) signals growth, Mars return (~2 years) resets energy and drive,' but this is a modest addition rather than a substantial one. Since the schema already documents the valid enumerations and allowed ranges, an agent can call the tool correctly without the description's parameters scenes.

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 leads with a specific verb and resource: 'Generate a planetary return chart for Mercury, Venus, Mars, Jupiter, or Saturn.' It explicitly names the planets covered, which distinguishes this from solar and lunar return siblings without needing the schema. The opening gives an agent immediate, unambiguous knowledge of what the tool does.

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

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

The description provides clear context on when each planetary return is relevant: Saturn return is a major life milestone, Jupiter signals expansion and growth, Mars resets energy and drive. It does not explicitly say 'solar or lunar returns should use other tools,' but the planet list and periods make the intended use fairly evident. Thus the tool has clear context but lacks an explicit exclusion of sibling alternatives.

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

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

Annotations already cover the read-only, non-destructive profile. The description contributes real behavioral context beyond that: tropical zodiac convention, the complete body list, concrete computed fields, and validation against NASA JPL Horizons. It stops short of describing exact response shape, but the listed return values help.

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 tight sentences with the core capability and scope front-loaded, followed by output fields and use cases. Minor fluffy words like 'perfect' and 'accurate' are acceptable and do not obscure meaning.

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

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

For a tool with 8 parameters, no output schema, and many siblings, the description does enough to orient an agent: what is computed, for which bodies, what is returned, and why one would call it. Lacking only an explicit distinction from sibling tools like post_astrology_planets_monthly.

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 explanations for all 8 parameters and covers 100% of them. The description does not need to repeat parameter semantics, and it does not materially add beyond the schema, so 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 names a concrete action and target: 'Calculate accurate tropical zodiac positions for all 14 celestial bodies' and enumerates exactly which bodies. It clearly reads as the broad ephemeris tool rather than a narrow sibling like moon-phase 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?

Use cases are explicitly listed: transit tracking, ephemeris tables, astrology apps, and planetary position widgets. It does not explicitly explain when to prefer a sibling tool such as post_astrology_aspects, but the context is clear enough for selection.

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

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

Goes well beyond the readOnlyHint annotation by disclosing the calculation moment ('at noon UTC'), the accuracy provenance ('Verified against NASA JPL Horizons'), and the dynamic default behavior that keeps a published page current without redeployment. These are real behavioral traits an agent needs to decide when results are time-anchored and how inputs affect the response.

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 carry dense, valuable information with front-loaded facts. The closing keyword-style sequence ('Monthly ephemeris API, tropical position table, daily planet transit positions, ecliptic longitude calculator') is largely redundant repetition of earlier content, though it also holds the useful JPL verification fact. It would average 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?

For a zero-required-parameter tool with 100% schema coverage, the description fully conveys the body list, date range, temporal reference, return fields, and default-current behavior. The annotation already covers the safety profile, and the description covers the epistemic context; what an agent needs to invoke and interpret the call is present.

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 already documents all 4 parameters at 100% coverage, so the baseline is 3. The description adds practical value by explaining why omitting year and month yields the month-in-progress (a 'stay current without a redeploy' strategy), giving the agent a semantic reason to prefer defaults. That context is genuinely additive rather than a restatement.

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 the verb 'Get' and a precise resource: daily tropical ecliptic positions for an exact enumeration of 14 Western bodies across a full month. It names the specific outputs (longitude, zodiac sign, degree within sign, retrograde status), which separates it from sibling tools like post_astrology_transits_monthly (aspect-oriented) and post_astrology_planets (non-monthly position data).

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?

Use cases are explicit: 'Essential for ephemeris tables, transit tracking, retrograde calendars, and planetary movement charts.' It also gives actionable input guidance ('Omit year and month to get the month in progress, so a published ephemeris page stays current without a redeploy'). However, it stops short of naming sibling alternatives or stating 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?

The annotations already establish the read-only, non-destructive safety profile. The description adds useful behavioral context about how the calculation advances the rising sign by one whole sign per completed year and what the response will contain, which goes beyond the schema without overstating side effects.

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

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

The description is two information-dense sentences with no filler. The core action is front-loaded, the rule is clearly explained, and every clause contributes either to selecting the tool or understanding its output.

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

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

Given that this is a stateless calculation tool, the description is complete: it names the inputs conceptually, the calculation rule, and the full set of output fields. The schema additionally covers all parameters with formats, ranges, enums, and a complete example, even though no output schema is present.

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 10 parameters already have detailed descriptions in the schema, including formats, ranges, defaults, and enum meanings, so the schema is doing the heavy lifting. The description only adds a high-level relationship between birth chart and target date and correctly does not repeat all the parameter documentation.

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

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

The description is immediately specific: it names the exact action, the resource, and the method — calculating annual profection and lord of the year for a birth chart and target date using the Hellenistic time lord technique. It also identifies the distinctive output (age, profected house/sign, lord of the year, interpretation), making the tool easy to distinguish from sibling progression, return, and transit calculators.

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

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

Usage is implicit: the description explains that this computes a profection year for a birth chart and target date, so an agent can infer when to choose it. However, it does not explicitly say when not to use it or point to alternatives such as progressions, solar returns, or planetary returns, which is important given the large sibling tool list.

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

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

Beyond the read-only/destructive annotations, the description discloses the returned fields (sign, degree, whole-sign house, motion, retrograde state) and the Naibod arc method for progressed angles. It complements the annotations without contradicting them, and it gives an agent a concrete behavioral model. It does not cover edge conditions, but the annotations still supply the 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 essential info is front loaded: the 44 definition, the output shape, and the timing-marker purpose. The closing SEO-keyword sentence adds little for the agent because it restates already given facts, but the list is short and remains manageable.

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 provides adequate context by enumerating what is returned and the calculations typical. The tool has 9 parameters and 6 required, but the schema fully covers those, and the description covers the behavioral return side. It is not perfect, but is complete enough for correct invocation.

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

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

Input schema coverage is 100%, so the schema already documents all parameter formats and defaults. The description reinforces the targetDate calendar and the day-for-a-year mechanism, but that is largely described again in the schema's targetDate property. Therefore, 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 opens with a precise verb and resource — 'Generate the secondary progressed chart' — and explains the distinguishing day-for-a-year method. It is clearly differentiated from the sibling solar arc, transit, and return tools, so an agent knows exactly what this endpoint computes.

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 makes the intended use context explicit: compute a secondary progressed chart for any date using the day-per-year key. It doesn't explicitly say when not to use it or prefer post_astrology_solar_arc / transits, so it earns a 4 rather than 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, and the description is consistent with that safety profile — it only calculates and returns, never mutates. Beyond the annotations, the description adds valuable behavioral context: what is preserved (planets in natal signs/degrees), what changes (angles, houses), and a concrete list of return entities (houses, angular planets, distance, compass direction). The 'Verified against NASA JPL Horizons' claim adds a trust anchoring for accuracy.

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, each earning its place: what the schema does, the underlying rule, the return contract, and the intended use cases. The sentence is front-loaded with the primary verb and resource. Mild redundancy ('relocation chart (relocated birth chart)') is negligible. No fluff; well within an appropriate size for a tool with 10 parameters.

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 though there is no output schema, the description enumerates the key return entitites (relocated houses, angles, planets meandering, angular planets, distance, compass bearing), which is enough for an agent to use the result in conversational flows. The input contract is fully covered by the 100% schema coverage, and purpose and use-context are clear. Slight gap: no specification of the exact response shape or possible fallback behavior, but the answer is already strong given the secure-project properties.

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 each parameter is already documented with ranges, examples, and role (e.g., 'birthplace latitude… used for the original natal angles the relocated chart is compared against'). The plain description adds some conceptual bridge — that birth coordinates fix planets and relocation coordinates alter angles — but does not add per-parameter meaning beyond what the schema already carries. With full coverage, 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 opens with a specific verb and resource: 'Calculate a relocation chart (relocated birth chart) for a new place on Earth.' It then clarifies the exact mechanic — planets keep their natal signs and degrees while Ascendant, Midheaven, Vertex, and house cusps are recomputed for the new coordinates. This scope is unambiguous and naturally distinguishes the tool from siblings like natal_chart or astrocartography.

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 intended contexts: 'relocation astrology readings, astrocartography style move planning, and travel charts.' This tells an agent when the tool is appropriate. It does not, however, explicitly name the sibling tool to prefer when the user wants a full astrocartography map of many locations or a plain natal chart without relocation, so the alternative-routing is implied but not stated.

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

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

The annotations (readOnlyHint=true, destructiveHint=false) already declare that this is a safe, non-mutating operation, and there is no contradiction. The description adds 'Built on accurate tropical chart positions' and a plain-language interpretation, which is context but not disclosure of meaningful behavioral traits such as edge cases around missing times or the fidelity of the interpretation layer. Since the safety profile is implied, the extra value is moderate — a solid 3.

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 single, well-structured paragraph with a reasonable length for a 9-parameter, output-rich tool. The key concept (solar arc arithmetic) is front-loaded, followed by return contents and use case. The closing phrase 'no astronomy expertise needed' is marginal filler, but the rest of each sentence carries information, so it remains efficient overall.

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

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

This tool has no output schema, so the description does the entire job of explaining return values; it enumerates the solar arc, each directed point's natal/derived longitudes, sign, degree, and interpretation — adequate for an agent to understand the result shape. Combined with 100% schema-backed parameters and read-only annotations, the definition is functionally complete. The prior mention of explicit sibling disambiguation is the only notable omission within a complete tool description.

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 prose, however, adds conceptual semantics that reinforce parameter meaning: the solar arc is defined as secondary-progressed Sun minus natal Sun, and the effect on targetDate ('every natal point... advanced by that same arc') is clearly expressed. This enrichment helps an agent understand how targetDate, date, and the returned positions relate, pushing the score to 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: 'Calculate a solar arc directed chart for any birth moment and target date.' It then explains the technique (forwarding all natal points by the solar arc of ~1 degree per year), which leaves no ambiguity about what the tool produces. It does not explicitly name a sibling tool it is not, so it stops short of a 5, but the distinctive mechanism makes it easy to distinguish from transits, progressions, and solar 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 description gives a concrete use context: 'for predictive astrology apps timing major life events.' That tells an agent when solar arc is relevant, but it does not explicitly compare against alternatives, state when NOT to use this tool (e.g., when secondary progressions or transits would be more appropriate), or name a competing sibling like post_astrology_progressions. The guidance is implied rather than stated, warranting a 3.

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 already present, the description adds valuable behavior beyond the annotations: it discloses the full chart contents (planetary positions, house cusps, aspects, Ascendant, Midheaven) and calls out how relocating to a different city changes houses and Ascendant. There is no contradiction between annotation and description.

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

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

The opening sentence is informative and the most useful part is front-loaded, but the tail is keyword-stuffing: 'Solar return chart API, annual horoscope forecast, birthday chart calculator, yearly astrology prediction, relocated solar return' adds no new information and repeats several prior points. The description would be better with that sentence removed.

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 does a good job of telling the agent what the chart contains and what the key influencing parameter is, location. Combined with the detailed input schema and annotations, an agent has enough context to invoke it properly.

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 100% of the parameters with detailed examples, so the description does not need to repeat them. The description adds a bit of extra context around location-sensitivity, but that is already stated in the latitude schema description. This matches the baseline for fully covered schemas.

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 names a specific operation, generating a solar return chart, and explains the core astronomical basis: the moment the transiting Sun returns to its natal longitude. It is clear that this is an annual forecasting chart rather than a general birth chart, but it does not explicitly differentiate itself from nearby siblings like lunar_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 description explicitly states the intended use case, 'annual astrological forecasting' and 'for any year', and explains that the chart is location-sensitive so the agent knows to treat latitude/longitude as meaningful inputs. It does not name alternatives or state when NOT to choose this tool, 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 agent knows this is a safe, non-mutating operation. The description adds meaningful behavioral context beyond the annotations by disclosing the output contents: compatibility score (0-100), inter-aspect listings with strength ratings, harmonious vs. challenging counts, and relationship dynamics analysis. This is especially valuable because no output schema is provided, so the description is the only source of return semantics.

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 appropriately sized for a complex astrology tool, with the core purpose and key output benefits appearing in the first two sentences. The promotional closing sentences ('Perfect for dating apps...' and 'Based on professional astrological techniques') are somewhat optional but not misleading or bloated. Overall it is well-structured and front-loaded with the most decision-relevant information.

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

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

Given the tool's complexity, nested input objects, and lack of an output schema, the description does a good job of covering the essential context: what is calculated, how, and what the response contains. The remaining gap is that it does not explicitly disambiguate from the closely related sibling post_astrology_compatibility_score or describe the exact output shape with field names, which could have improved completion for an agent. Still, it is sufficient for a strong first pass.

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 explain individual parameter formats or expectations; it relies on the input schema to carry that load. The schema itself is rich, providing deep descriptions for person1/person2, lang, compact, and houseSystem. Since schema description coverage is around 60% and the description only adds context-level meaning ('between two natal charts') without parameter-specific help, it is not better than the baseline.

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

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

The description clearly states the tool calculates 'complete synastry (relationship compatibility) between two natal charts' using 'Western tropical astrology,' which is a specific verb, resource, and method. It also distinguishes itself from sibling tools like post_astrology_natal_chart (single chart) and post_astrology_compatibility_score (score-focused) by emphasizing detailed inter-chart aspect analysis and relationship dynamics. The title and description align tightly with the tool name.

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

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

The description provides clear use-case context, explicitly mentioning dating apps, matrimonial sites, relationship counseling tools, and astrology compatibility features. This tells an agent when this tool is relevant. However, it does not explicitly name sibling alternatives (e.g., post_astrology_compatibility_score for a simpler score, or post_astrology_composite for a merged chart) or state when not to use this tool, so it falls short of full explicit routing.

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

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

Annotations already mark the tool as read-only and non-destructive. The description adds meaningful behavioral detail by enumerating what each returned aspect includes (type, orb, applying/separating status, narrative interpretation, impact rating, practical guidance) and noting that both current and future dates are supported. It does not discuss caveats or rate limits, but for a safe read operation this is good transparency beyond structured fields.

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 immediately define the core behavior and return content. The final keyword-style sentence ('Transit aspects API, transit-to-natal analysis, predictive astrology...') adds little for an agent and could be removed without loss, but it does not obscure the core meaning or appear early. Slightly overstated length for the edge value, but mostly 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?

There is no output schema, so the description productively enumerates return fields and mentions that supports filtering and default/future dates. With 9 parameters, nested natal chart objects, and rich sibling alternatives, the description does not cover every possible open question, but it gives enough to correctly select and call this endpoint for detailed transit interpretations.

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 every parameter has its own description, so the schema carries the semantics. The tool description adds no parameter-specific detail beyond confirming that planets and aspectTypes can be filtered. This is exactly the baseline 3 case: the schema already covers the parametric meaning, so the description is not required to compensate but also doesn't enrich it.

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

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

The description opens with a concrete verb and resource: 'Calculate all transit-to-natal aspects' and immediately clarifies the exact inputs (transiting positions vs. natal chart). It distinguishes the tool from the sibling /transits endpoint by highlighting added interpretation fields, strength ratings, and timing guidance, which resolves ambiguity among the large post_astrology_* 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 sets clear usage context: it is for detailed transit-to-natal aspect analysis with narrative interpretations and filtering. It explicitly positions itself as 'more detailed than the /transits endpoint,' which helps an agent choose among this, post_astrology_transits, and post_astrology_transits_monthly. It stops short of stating when to pick an alternative or when not to use this endpoint, so no exclusions are given.

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

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

Beyond annotations that already say this is read-only and non-destructive, the description adds substantial behavioral detail: output includes all 14 bodies, signs, degrees, speeds, and optionally transit-to-natal aspects with orbs and applying/separating status. No contradiction exists between the description and 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 and efficient: it states the operation, the exact output shape, the optional behavior, and the main use cases in a few sentences. There is no redundant or filler 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?

With no output schema present, the description carries the return-value burden and fulfills it well by specifying the base body list and the natal comparison additions. Combined with complete schema descriptions and read-only annotations, there is enough context for the agent to call the tool safely.

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 schema already documents every parameter with defaults, examples, and edge cases. The description adds only high-level context about natal chart comparison, but it does not need to compensate because the schema covers parameter meaning thoroughly.

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 clear verb-plus-resource: it calculates current or future planetary transits and lists concrete outputs (14 celestial bodies with signs, degrees, speeds, plus optional natal transit arspects). It does not explicitly distinguish itself from sibling tools like post_astrology_transits_monthly or post_astrology_transit_aspects, so it stop just short of full differentiation.

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

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

The description names concrete use cases: daily transit forecasts, aspect alerts, and personalized transit reports, which gives an agent practical guidance on when to select it. It does not state exclusions or route to alternatives, so it earns 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?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses result contents (starting signs plus ingresses with exact date/time), timezone sensitivity, default-to-current-month behavior, and accuracy reassurance against NASA JPL Horizons. This provides meaningful context an agent would not get from the annotations alone.

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 opens with the core action and output, then practical usage guidance. The trailing keyword list ('Monthly transit API, planetary ingress calendar, sign change dates, tropical transit table') reads like SEO filler and adds little, keeping it from a 5, but most sentences are targeted and not duplicated.

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 outlines what the tool returns, for what period, for which highlights, at what timezone, and how to keep a calendar current. With all six parameters already fully described in the schema and no required inputs, the base description supplies complete operational context for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the burden on the description is low. It adds some useful semantic context for the year and month parameters, e.g. 'Omit year and month to get the month in progress, so a published transit calendar stays current.' For other parameters like lang, compact, and nodeType, the description does not attempt to add anything beyond the already-thorough schema.

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

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

The description states a specific verb and resource: 'Get every tropical sign change for a given month, for all 14 Western bodies.' It also precisely enumerates the scope (Sun through Pluto, lunar nodes, Chiron, Black Moon Lilith) and distinguishes itself naturally from sibling tools like post_astrology_transits, post_astrology_transit_aspects, and get_astrology_moon_phase_calendar_year_month.

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: 'transit calendars, monthly forecast copy, retrograde and ingress tracking, and newsletter automation.' It also explains the option of omitting year and month to get the month in progress. It stops short of explicitly telling an agent when not to use this tool versus alternatives such as post_astrology_transits or post_astrology_aspects_monthly.

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