Western Astrology MCP Server by RoxyAPI

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

Even with readOnlyHint=true and destructiveHint=false already in the annotations, the description adds substantial behavioral guarantees: no language model is involved, the same sign and date always return the same text, scheduled content is stable, rollover defaults to UTC, and unsupported language codes fall back to English. This goes well beyond the safety profile the annotations already provide.

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

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

The description is well front-loaded with the core purpose and behavioral guarantees, and most sentences carry operational weight. The trailing keyword string 'Daily horoscope API, zodiac forecast, sun sign horoscope, astrology prediction.' is non-operational filler, and the language list partially duplicates schema 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?

With a full output schema present, the description does not need to enumerate return values, and it covers everything an agent needs to call the tool correctly: date handling, timezone behavior, language fallback, determinism, and the fact that transit events are included for fact-checking. The only minor caveat is the 8-vs-10 language mismatch, which is a parameter-level nuance rather than a completeness gap.

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 and the description does not need to compensate. It adds useful framing for `date` and `timezone` ('editorial scheduling' / 'local clock'), but the language claim ('Composed in 8 languages... any other lang code returns English') slightly conflicts with the schema's 10-language enum and per-field fallback wording, so it doesn't add clean value over the schema.

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

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

The description states a specific deliverable: a publish-ready daily horoscope column generated from dated transits for any zodiac sign, returned with its underlying events for fact-checking. It also makes the tool's distinctiveness clear — 'every sign gets different content rather than one blurb reused twelve times' and the rollover-at-midnight detail reinforce the daily scope that separates it from weekly/monthly/yearly siblings.

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

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

The description gives clear operational context: pass a date for editorial scheduling, pass a timezone to roll over on a local clock, and expect English fallback for unsupported languages. It does not explicitly route to the weekly/monthly/yearly siblings, so the when-to-use guidance is strong but not fully explicit about alternatives.

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

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

Annotations already mark the tool as read-only and non-destructive, and the description goes well beyond that by disclosing exact event instants, verifiability against NASA/USNO, language fallback to English, timezone-relative rollover, and the section structure. This is rich behavioral context with no contradiction.

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

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

The opening is front-loaded with the core scope, but the description is padded with redundant quality claims and ends in keyword-stuffed phrases like 'Monthly horoscope API, zodiac monthly forecast, astrology monthly prediction.' It is structured enough to be usable, but not every sentence earns its place.

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

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

Given the output schema and 100% schema coverage, the description does not need to explain return shapes. It covers content sections, key dates, language fallback, date/timezone semantics, and the read-only nature, so an agent has everything needed to select and call this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds little beyond what the schema already states for date/timezone behavior. The claim of '8 languages' is inconsistent with the schema's 10-language enum, so I do not give it credit for improving parameter understanding.

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

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

The description clearly states the resource: a month-long column for any zodiac sign with weekly breakdown and dated key dates. 'Month-long' explicitly differentiates it from the daily/weekly/yearly sibling tools, and the mention of key dates adds a distinguishing attribute.

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 invocation context: any date inside a month retrieves that month, and timezone controls rollover when date is omitted. It does not explicitly name sibling alternatives or exclusion conditions, but the month-scoped content makes the appropriate use obvious.

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 discloses behaviors not available in the annotations: deterministic output ('No language model is involved, so the same sign and week always returns the same text'), language fallback ('any other lang code returns English'), timezone-sensitive week rollover, and uniqueness of content per sign. This adds substantial context beyond the readOnlyHint/destructiveHint annotations. No contradiction 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 organized and front-loads the core purpose, but it is longer than necessary and ends with a keyword-stuffed sentence ('Weekly horoscope API, zodiac weekly forecast, astrology weekly prediction') that adds no agent value. Several behavioral details are repeated in the schema, so not every sentence earns its place.

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

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

Given that an output schema exists, the description correctly avoids restating return formats. It covers what the column contains (overview, love, career, health, finance, advice, lucky days, numbers, compatible signs), determinism, date/timezone behavior, and language fallback. The only minor gap is not explicitly distinguishing when to prefer this over the daily/monthly siblings, though the Monday-to-Sunday framing makes it inferable.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces parameter semantics (e.g., 'Pass any date inside a week to retrieve that week' for date, 'timezone to roll over on a local clock' for timezone, and language fallback), but it doesn't introduce meaning beyond what the schema already documents. This is adequate but not additive.

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 resource: a Monday-to-Sunday horoscope column for any zodiac sign, naming transits and the days they fall on. The 'Monday to Sunday' framing sharply distinguishes it from daily and monthly sibling tools. The verb 'retrieve' appears in the date-handling sentence, making the action explicit.

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

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

The description gives clear operational context: pass any date inside a week to select that week, omit date to use the current period, and pass a timezone to control the local rollover. It doesn't explicitly say 'use this instead of the daily/monthly tools,' but the weekly scope and content list make the intended use obvious. No exclusions or alternative routing are 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?

Annotations already mark this as read-only and non-destructive. The description adds substantial behavioral detail beyond that: it returns editorial copy plus structured dated events, includes every eclipse and retrograde station by house, and explains compact-mode and timezone-related behavior. There is no contradiction with the annotations.

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

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

The first three sentences are dense but informative, covering output structure, verification use case, and year/timezone usage. However, the trailing keyword phrase ('Yearly horoscope API, year ahead astrology...') is filler that adds no agent value, and the first sentence packs a very long list that could be more readable.

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

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

For a 5-parameter GET with an output schema and read-only annotations, the description covers the returned content, current vs. historical year selection, timezone behavior, compact token savings, and editor verification. Nothing essential for selecting or invoking the tool 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?

All five parameters have full schema descriptions with enums, defaults, examples, and range constraints, so the baseline is 3. The description reinforces the year semantics ('Omit the year for the one in progress') and compact output, but it does not materially add 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 states a specific action ('Get the year ahead') and a clear resource (yearly horoscope by zodiac sign), then enumerates the concrete contents: themes, 12-house key periods, best months, eclipses, and retrogrades. This distinguishes it strongly from the daily, weekly, and monthly sibling tools by its yearly 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 gives clear usage context: omit the year for the current one, pass 1900–2100 for archives or early forecasts, and rely on the timezone parameter to define the current year. It does not explicitly name daily/weekly/monthly as alternatives or state when not to use this tool, but the year-ahead framing makes the intended use fairly unambiguous.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered structurally. The description adds that the result is 'complete' month coverage with illumination values, which is mild scoping context, but says nothing about rate limits, coverage gaps, or return shape. Adequate given annotations, not rich.

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, both front-loaded with the core capability first and the use cases second. The second sentence leans promotional but does carry some routing value; no wasted preamble.

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

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

With an output schema present and annotations covering the safety profile, the description need not explain return values. Year/month scope, illumination inclusion and a language-capable schema cover what an agent needs; only the when-vs-sibling guidance is thin.

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% – year range, month 1-12, lang enum and compact mode are all documented in the schema itself. The description adds no parameter-level detail beyond what the schema already carries, so the 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?

States a specific verb ('Get') and resource ('complete lunar calendar showing moon phase and illumination') and pins the scope to 'every day of a specific month'. That scope clause is what separates it from the sibling single-point tools get_astrology_moon_phase_current and get_astrology_moon_phase_upcoming without opening either 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 second sentence gives use cases ('moon phase calendars, lunar planners, astrology event schedules'), which implies when the tool is appropriate, but it never states when to prefer it over get_astrology_moon_phase_current/upcoming or names any alternative. Usage is implied rather than prescribed.

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 read-only and non-destructive nature is already encoded in annotations, so the description only needs to add context, and it does: it enumerates the returned data and phase-name vocabulary. It also surfaces the behavioral nuance that time matters because the Moon moves ~13 degrees per day, affecting phase precision. This aligns with annotations rather than contradicting them.

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

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

At three sentences, the description is appropriately sized and opens with the core function before adding use-case context. The phase-name enumeration is somewhat verbose if the output schema already defines those values, but it remains useful for an agent to anticipate response values. There is no 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?

With zero required parameters, 100% schema coverage, read-only annotations, and an output schema, the description does not need to explain return structure or safety. The description adds the user-facing intent and enough behavioral context (time sensitivity, returned values) for an agent to call it correctly. The main omission, sibling differentiation, is a usage-guideline issue rather than a callability gap.

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?

Every parameter has a full schema description with formats, defaults, enums, and examples, so schema coverage is 100%. The tool description mostly describes outputs rather than parameters; the one parameter-level insight (time affects precision) is already present in the time parameter's schema. Little additional parameter meaning is contributed by the description.

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

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

The opening sentence states a clear verb and resource ('Get current moon phase') and lists exact return fields, including phase name, illumination, lunar age, zodiac sign, and distance. It is unambiguous about what the tool computes. It does not contrast itself with sibling moon-phase tools such as get_astrology_moon_phase_calendar_year_month or get_astrology_moon_phase_upcoming, so differentiation is left to the name/title.

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 real consumer contexts ('moon tracking apps, lunar calendars, astrology widgets, gardening by moon phase tools'), which hints at applicable use cases. It does not say when to prefer this tool over the calendar/upcoming moon-phase siblings or provide any exclusions. Selection guidance is absent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that results are phase names plus dates over a span of weeks/months, but says nothing about ordering, timezone/UTC handling of dates, or how the span relates to count — useful gaps remain.

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 short sentences, front-loaded with what is returned and its scope, followed by use cases. Nothing is redundant or padded; only the marketing-flavored 'Perfect for' sentence is marginal.

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?

An output schema exists, so return-format detail is not required, and all four optional parameters are well documented with defaults. Combined with read-only annotations, an agent has enough to call it correctly; only the date/timezone semantics of the returned transitions are unaddressed.

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 lang, count, compact, and startDate are all fully documented in the schema itself, including ranges, defaults, and the compact columnar format. The description adds no parameter-level meaning beyond that, so the 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?

States a specific verb (get) and resource (upcoming moon phase transitions), enumerating the four phase types and the scope ('next weeks/months'). It reads clearly against siblings like get_astrology_moon_phase_current and get_astrology_moon_phase_calendar_year_month, but it never names those alternatives to sharpen the 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 offers use-case framing ('lunar event calendars, moon phase widgets, astrology planning tools'), which implies usage. It does not say when to prefer this over the current-phase or month-calendar siblings, nor state any exclusions, so guidance is only 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 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 the safety profile is covered. The description adds useful context about the returned content fields and identifier flexibility, but it does not disclose additional behavioral traits such as error behavior, rate limits, or data source caveats.

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 action and the required id semantics, then enumerates the response fields and use cases. It is somewhat dense but every sentence contributes useful information, with no significant filler.

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

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

Given the annotations, full schema documentation, and presence of an output schema, the description provides all necessary orientation: what the tool does, what inputs are expected, what data is returned, and common use cases. Nothing essential 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%, with detailed descriptions for id, lang, and compact already present. The description mostly restates the id flexibility (lowercase vs case-insensitive names) and does not add substantial meaning beyond the schema.

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

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

The description clearly states a specific action ('Retrieve comprehensive planet interpretation') and a specific resource ('any astrological planet'), and it explains the required identifier style. It is easy to distinguish from the sibling list tool because it describes a per-planet ID lookup by name and ID.

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

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

The description gives explicit use cases such as birth chart readings, natal chart interpretation, transit meanings, and planet meaning lookups, which clearly indicate when this tool is appropriate. It does not explicitly name an alternative or exclusion case, but the context is strong enough to guide selection.

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

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

Annotations already provide 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, covering the safety profile. The description adds meaningful behavioral context: input flexibility (lowercase ID or case-insensitive name) and the comprehensive nature of the response. It does not contradict annotations and provides extra detail about what the call returns without relying solely on the schema.

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, long, run-on sentence that packs a massive enumeration of returned fields ('...personality traits (positive, negative, keywords), zodiac sign descriptions, famous people with this sign, key strengths and qualities, sign motto, greatest gifts, challenges, and secret weapon.'). It is not front-loaded with the most critical differentiators and would be easier to scan if split into short sentences or bullets. This length reduces usability.

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

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

The tool has an output schema, so return-value explanation is unnecessary. The description covers input formats, language options via schema, and the breadth of returned data. It does not mention error handling or edge cases (e.g., unknown sign IDs), but for a simple read-by-ID tool with read-only annotations, the description is sufficiently complete 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 coverage is 100% — every parameter (id, lang, compact) has a description in the input schema. The tool description essentially repeats the id input behavior (lowercase or case-insensitive) that the schema already documents, adding no new semantic value. It does not elaborate on lang or compact beyond what the schema states. Since schema carries the full burden, 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 specific verb ('Retrieve') and a clear resource ('comprehensive zodiac sign information'), then enumerates the exact fields returned (element, modality, ruling planet, personality traits, etc.). It is unambiguous about what the tool does and is not a tautology. However, it does not explicitly contrast with the sibling get_astrology_signs (likely a list-all tool), so it slightly misses sibling differentiation, but the purpose itself is crystal clear.

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

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

The description lists broad use cases ('Perfect for horoscope readings, zodiac compatibility checks...') but gives no guidance on when to choose this tool over alternatives. It does not mention get_astrology_signs (which likely returns all signs) or any condition that would make this tool inappropriate. The implication that it handles a single sign is present but not explicit, and there is no when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context: the lots are arc-projected from the Ascendant, and the day/night formula is selected automatically from chart sect. It also discloses the return contents per lot, though nothing about auth or limits.

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

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

Front-loads the core action and the lot list, then the mechanism and returns. The closing 'Built on accurate tropical chart positions, no astronomy expertise needed' is mildly promotional, but the rest is dense and waste-free.

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?

An output schema exists, so return values need not be detailed, yet the description still summarizes them. Annotations cover safety and all params are schema-documented, leaving only the sibling-routing gap. Adequate for a read-only calculator.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters thoroughly. The description adds only an indirect note tying chart sect to the applied formula, without clarifying individual parameters beyond the schema 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?

States a specific verb ('Calculate') and resource ('the seven Hermetic lots (Arabic parts)'), then enumerates all seven lots by name. It is immediately distinguishable from siblings like post_astrology_natal_chart or post_astrology_houses.

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 audience context ('for Hellenistic and traditional astrology apps') and scope ('for any birth moment'), which implies when it applies. However, it never names an alternative or states when NOT to use it versus the broader natal chart tool that likely also surfaces lots.

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 only cover safety (readOnly, non-destructive); the description adds genuinely useful behavioral detail beyond that: what each pattern object carries (tightness score 0-100, dissociate flag, one-line interpretation) and the built-in suppression rule where a Grand Cross suppresses contained T-Squares and a Kite suppresses its underlying Grand Trine. It doesn't discuss orbs/tolerance behavior or failure modes, but the disclosure is well above the annotation baseline.

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

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

Front-loaded with the core purpose, followed by return contents and the suppression rule, all of which earn their place. The trailing audience list ('useful for ... and editorial chart-pattern callouts') is the one soft sentence, but the rest is dense and well-ordered.

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

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

With an output schema present, the description need not explain return values, yet it usefully summarizes them; 5 required and 10 total parameters are fully documented in the schema, and the pattern vocabulary is complete. The only real gap is sibling-level routing guidance, which the description leaves implicit.

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 parameters (including strictOrbs orb-narrowing behavior, include tokens, nodeType, compact) are already fully documented in the schema. The description mentions no parameter at all, adding no semantic value beyond what structured fields provide; 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?

States a specific verb (identify/detect) and resource (classical Western multi-planet configurations in a birth chart), then enumerates the exact pattern types returned (Grand Trine, Kite, T-Square, Grand Cross, Yod, Mystic Rectangle, Stellium). This clearly separates it from the pairwise-modifier sibling post_astrology_aspects without the agent needing to open either 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 closing sentence lists audiences ('personalized natal report engines, astrology chatbots, AI agents that interpret chart geometry'), which implies usage context but is audience-oriented rather than decision-oriented. It never states when to prefer this over post_astrology_aspects, post_astrology_natal_chart, or post_astrology_transit_aspects, nor any prerequisites. Usage is inferable from the pattern list but not explicitly guided.

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 safety profile, so the bar is lower; the description still adds real behavioral context: standard Western astrology orbs, returned fields (aspect type, exact angle, orb, applying/separating, strength 0-100), and default coverage of all planets/aspect types.

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

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

Front-loaded with the core action, then return fields, then filtering, then use cases. Dense but every sentence carries information; the final 'Perfect for...' sentence is the weakest and partly redundant.

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 annotations, a fully documented schema, and an output schema present, the description needn't explain return values in depth. It still adds orb conventions and default scoping, leaving little an agent needs beyond the structured 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%, so the schema already documents every parameter including defaults (all 14 bodies, all 9 aspects). The description's 'filter by specific planets or aspect types' adds no syntax or format detail beyond what the schema provides, so 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?

States a specific verb and resource: calculates major and minor aspects between planets for a date/time, and enumerates the aspect types returned. It is clearly a natal-moment aspect calculator, though it never names the closely related siblings (post_astrology_transit_aspects, post_astrology_aspect_patterns) to draw the boundary.

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 only implied via 'Perfect for aspect tables, transit analysis, and aspect pattern detection,' which actually points toward sibling tools rather than distinguishing this one. No explicit when-to-use/when-not or alternative routing is 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: calculation on tropical longitudes, per-aspect traditional orbs, closest-approach timestamps converted to the caller's timezone, and the rationale for excluding the Moon. It stops short of disclosing response size, rate limits, or pagination.

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 content is front-loaded and well organized, but the closing lines ('Monthly aspect calendar API, exact aspect times, planetary aspect ephemeris, transit timing. Verified against NASA JPL Horizons.') are SEO keyword padding that adds no invocation value. Some redundancy exists between the title and the opening clause.

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?

An output schema exists, so return values need no explanation, and the description covers scope, exclusions, defaults, calculation basis, and timezone handling adequately for a 6-parameter, zero-required tool. Minor gaps remain around response volume for a full month and the compact/nodeType knobs, but nothing critical 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 coverage is 100%, so baseline is 3, but the description adds meaning: omitting year and month yields the month in progress (useful for a published calendar), and it clarifies that event times are rendered in the supplied timezone. It says nothing about lang, compact, or nodeType, which remain schema-only.

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

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

States a specific verb (get), resource (planetary aspects), and precise scope (every aspect perfecting in a given month across 13 non-lunar Western bodies). It enumerates the nine aspect types and explicitly carves out the Moon, so an agent can tell it apart from daily/transit aspect siblings without opening a 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?

Gives clear context for when it applies (monthly forecast copy, transit calendars, electional timing, newsletter automation) and states the no-argument default behavior. It contrasts scope against a 'daily view' but never names the alternative sibling tool (e.g. post_astrology_aspects or post_astrology_transit_aspects), leaving the routing decision partly to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: it enumerates what each asteroid returns (sign, degree, house, daily speed, retrograde status, interpretation) and clarifies the deliberate scope exclusion of Chiron. It does not discuss rate limits or computation cost, but the added scope and output detail is substantive.

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

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

Three sentences, front-loaded with the core purpose and scope, followed by output detail and the Chiron routing note. Every sentence carries information; the middle sentence is slightly list-heavy but earns its place by preempting questions about what comes back.

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

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

With an output schema present and 100% parameter coverage, the description need not explain return shapes or field syntax, and it correctly focuses on scope and routing. It is complete for selection purposes; only minor gaps remain around polar-latitude fallback behavior and precision limits, which the schema partially covers.

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% across all 9 parameters, with detailed per-field docs for date, time, timezone, houseSystem, nodeType, lang, and compact. The description adds no parameter-level guidance of its own, so the baseline 3 is appropriate — the schema carries the full parameter burden.

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

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

The description opens with a specific verb+resource ('Calculate the natal positions of the four classical asteroid goddesses, Ceres, Pallas, Juno, and Vesta'), names the exact bodies covered, and explicitly distinguishes itself from the natal chart endpoint by stating Chiron is handled there. An agent can separate this from post_astrology_natal_chart or post_astrology_lilith without inspecting schemas.

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

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

It states the use context ('for natal reports and relationship astrology') and routes Chiron work to the natal chart endpoint, giving a clear when-to-use signal and one explicit alternative. It stops short of naming when this tool should NOT be used versus other asteroid-adjacent endpoints (e.g. Lilith, Arabic lots), so it is clear but not exhaustive.

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 is a safe read-only operation, so the bar is lower; the description adds useful context by disclosing the computation ('where a planet turns angular across the world') and what is shipped (right ascension, declination, meridian longitudes, sampled rising/setting curves, per-line interpretation). It says nothing about cost, rate limits, or caching, so it is not a 5.

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

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

Three sentences, front-loaded with the deliverable, then the meaning of the lines, then the return contents. Sizing is appropriate for the complexity, though the middle sentence is mildly decorative ('the core of relocation astrology') rather than actionable.

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 annotations covering the safety profile and a full output schema and 100% parameter coverage, the description only needs to establish purpose and output character, which it does. It could still say more about how the map is scoped (global coverage) and how optional flags like include/compact affect the result.

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 nine parameters (including enum-rich nodeType, lang, include, compact) are thoroughly documented in the schema itself. The description adds no parameter guidance beyond that, so the baseline of 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?

States a specific verb and resource: generate an astrocartography map of MC/IC/Ascendant/Descendant planetary lines for a birth moment, and explains what each line means. It is clearly distinct in output from relocation_chart or local_space, but it never names or contrasts those siblings explicitly.

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 conveys what the artifact is for ('the core of relocation astrology and astro mapping') and that it takes any birth moment, which implies when it is wanted, but it gives no explicit when-to-use, prerequisites, or alternatives versus the relocation and local-space siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that this is a scored, interpretive analysis (0-100 score, category breakdowns, narratives), which is useful, but it discloses no operational traits such as cost, rate limits, or what happens with missing/unknown birth times beyond the schema's own note.

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

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

The purpose is front-loaded in the first clause, but the bulk of the text is an enumeration of return contents that the output schema already defines (categories, narratives, element balance, archetype, aspects). That enumeration is largely redundant against the existing output schema and could be trimmed without losing agent-relevant signal.

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?

An output schema exists, so return values need not be explained, and the definition is otherwise thorough about the tool's scope. The one real gap is the absence of any routing contrast against sibling tools that consume the same birth-chart inputs.

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 nested person1/person2 objects are fully documented in the schema itself, so the description carries no additional parameter burden. The description adds nothing beyond what the schema already states, warranting 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 states a specific verb and resource: 'Calculate a detailed compatibility score between two birth charts using Western synastry.' It is unambiguous what the tool produces. It stops short of naming the sibling it competes with (post_astrology_synastry, post_astrology_composite_chart), so an agent must infer the boundary between a scored relationship analysis and raw inter-chart 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?

There is no when-to-use or when-not-to-use guidance. With three sibling relationship-analysis tools (synastry, composite_chart, compatibility_score), the definition never says when the scored/interpreted view is preferable to the raw aspect output. The agent is left to infer routing purely from the name.

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 genuine behavioral context beyond that: the exact midpoint methodology ('planets, angles and house cusps are each the midpoint of the two natal values'), the invariant that the Ascendant always sits on the first cusp, and the returned artifacts. No auth or rate-limit context, but the calculation semantics are well disclosed.

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 and method are front-loaded well, but the closing keyword list ('Composite chart API, midpoint chart calculator, relationship astrology, couple chart analysis') is SEO padding that adds no actionable information, and 'core identity, emotional bond, communication style, and growth direction' is marketing-flavored 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?

With an output schema present, the description need not enumerate return values, and it still summarizes them. For a 5-parameter, nested-object tool with full schema coverage, the only real gap is the absence of when-to-use guidance relative to the synastry/compatibility siblings.

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

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

Schema description coverage is 100%, with person1/person2 sub-fields, lang, compact, and houseSystem all documented in the schema itself. The description adds no parameter-level meaning (e.g., it never mentions houseSystem or the lang/compact options), so the baseline 3 for fully-covered schemas 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?

States a specific verb and resource ('Generate a composite chart by calculating midpoints between two natal charts') and explains the underlying method in detail, so the agent knows exactly what computation is performed. However, it never names its closest sibling (post_astrology_synastry), leaving the composite-vs-synastry distinction to be inferred from the description of the composite as 'a single entity'.

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 explains what a composite chart represents but gives no explicit when-to-use guidance, no conditions, and no alternatives. An agent choosing between this and post_astrology_synastry or post_astrology_compatibility_score gets no routing help beyond the implicit 'relationship' framing.

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 a safe read-only profile, and the description adds genuine behavioral context: the exact set of included/excluded bodies, the direction convention (south-to-north = ascending), the returned fields (date/time in the caller's timezone with tropical longitude and sign), and a data-provenance note (verified against NASA JPL Horizons). It stops short of describing pagination, volume of results, or any rate limits.

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 explanation is front-loaded and accurate, but the tail contains padding: a marketing sentence ("Essential for eclipse-season work...") and a keyword-stuffed fragment ("Ecliptic crossing API, planetary node passage, ascending and descending nodes.") that repeats the topic rather than informing. Some sentences could be trimmed without losing meaning.

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

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

With an output schema present, the description need not enumerate return values, and it covers the crucial domain semantics: which bodies are included/excluded and why, the ascending/descending convention, and the eclipse relevance. An agent has enough to call the tool correctly; only result volume/shape nuance is left unaddressed.

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 year, lang, compact, and timezone in detail. The description reinforces only the timezone behavior ("the exact date and time in your timezone") and the year scoping, adding little beyond what the schema provides. 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?

States a specific verb (get) and resource (moments a body crosses the plane of the ecliptic) with precise scope: a given year, 11 named bodies, and the explicit exclusion of the Sun and lunar nodes. It clearly distinguishes itself from sibling transit/aspect tools by centering on node passages rather than general positions.

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?

Gives clear usage context ("Essential for eclipse-season work, node timing, and astronomical calendars") and explains the astronomical condition that makes a crossing meaningful. However, it never names an alternative sibling tool or states when NOT to use this one (e.g., versus post_astrology_transits_monthly).

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

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

Annotations already declare the read-only, non-destructive profile. The description adds real behavioral context beyond that: every returned star carries precessed longitude, sign, magnitude and planetary nature, and each conjunction inside 'the chosen orb' receives a plain-language interpretation. That tells the agent what is computed and how the orb affects output, though it doesn't discuss volume or edge cases.

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 tight sentences: purpose, coverage/detection, return content, and audience. Front-loaded with the core action, no repetition of the title, and every sentence earns its place.

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

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

With an output schema present, the description correctly avoids enumerating return fields in exhaustive detail while still summarizing its shape and the orb-driven interpretation. Safety is covered by annotations and inputs by the schema, so the description is complete enough; only the absence of any guidance about large conjunctions lists or performance keeps it from a 5.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters thoroughly (orb, nodeType, timezone, compact, etc.). The description only alludes to 'the chosen orb' and 'the chart' without adding syntax or format detail beyond the schema, so 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?

States a specific verb and resource ('Calculate the tropical zodiac positions of the major named fixed stars') plus exact scope (four Royal stars, fifteen Behenian stars, conjunctions to planets/Ascendant/Midheaven). This clearly separates it from siblings like post_astrology_natal_chart, post_astrology_planets, or post_astrology_asteroids without the agent needing to open any schema.

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

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

The closing sentence gives context ('a focused tool for natal reports that weigh Regulus, Spica, Aldebaran, Antares, and Algol'), implying when it is useful. However, it never states when to prefer this over the plain natal chart or planet tools, nor any exclusions or prerequisites, leaving usage to inference.

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

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

Annotations already declare this is a safe read-only, non-destructive operation, so the burden is lightened. The description adds the return scope (12 cusps, signs, degrees, Ascendant, Midheaven) and notes accurate Asc/MC calculations, but the substantive caveat about latitude distortion lives in the schema, not the 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?

Front-loaded with the verb and resource, and the 'all' parameter guidance comes before the promotional tail. The closing 'Perfect for astrology charts...' sentence is marketing padding that does not earn its place, mildly diluting an otherwise tight 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 an output schema covering return values and full schema coverage on inputs, the description only needs to convey purpose, routing, and scope, which it does. It could still help by noting latitude limitations or how it relates to the natal chart sibling, but nothing essential to 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 all eight parameters are already documented in the schema, including the houseSystem enum and the 'all' option. The description only restates the house-system choices at a high level, adding no syntax or format detail beyond structured data.

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

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

States a specific verb and resource ('Calculate astrological house cusps') and enumerates the supported house systems, which distinguishes it from sibling chart tools like post_astrology_natal_chart that also produce houses. An agent can select it without opening the schema.

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

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

Gives clear usage context: default single-system calculation, plus the explicit 'all' parameter route for side-by-side comparison, and names target use cases (charts, cusp tables, educational tools). It does not, however, say when a sibling tool such as the natal chart would be preferable, so no exclusions are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the mean-vs-true distinction and notes that the true apogee can shift sign and turn retrograde, but says nothing about permissions, rate limits, or precision caveats beyond that. Adequate but not rich.

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

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

Three sentences, front-loaded with the core action and resource, then the variant distinction, then the return fields and audience. Dense but every sentence carries information; only the audience sentence is borderline expendable.

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

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

With an output schema present, the description needn't enumerate return values, and the parameter documentation is fully covered by the schema. For a complex calculation tool this is nearly complete; the only gap is any guidance on choosing this over a broader natal-chart tool.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters in depth; baseline 3 applies. The description's explanation of the mean/true variants loosely maps to nodeType, but adds no syntax or format detail the schema lacks.

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

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

The description names a specific verb and resource ('Calculate Black Moon Lilith for any birth chart') and precisely scopes it to both the mean and true lunar apogee. It clearly identifies the tool's domain, though it never explicitly contrasts itself with overlapping siblings like post_astrology_natal_chart or post_astrology_asteroids, which may also surface points.

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 implied ('for any birth chart') and the audience is named ('natal astrology apps and AI agents'), but there is no explicit when-to-use/when-not guidance or routing to alternatives. An agent can infer the context but gets no exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered. The description adds the domain behavior (horizon rotation makes birth time essential) but discloses nothing about permissions, rate limits, or cost, and since an output schema exists the return-value enumeration is largely redundant.

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, both earning their place: the first front-loads what the tool computes and returns, the second gives use cases. The opening sentence is dense but well-structured; nothing is filler or restated name/title boilerplate.

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

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

With an output schema present, the description need not explain return values, and it adequately covers the computational contract and the five required inputs. The one remaining gap is sibling disambiguation against relocation/astrocartography tools, which matters given 39 overlapping astrology 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?

Schema description coverage is 100% and every parameter (date, time, latitude, longitude, timezone, include, compact, lang) is documented in the schema itself, so the baseline of 3 applies. The description only hints that latitude/longitude are the 'birthplace' origin, adding no meaning beyond the schema.

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

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

States a specific verb and resource ('Generate a local space astrology map') and immediately specifies the mechanism (projecting natal planets onto the local horizon as compass directions and great-circle lines). It enumerates the concrete outputs (azimuth, altitude, 16-point compass direction, above-horizon flag, lat/long waypoints), so an agent knows exactly what this produces versus the broader family of chart 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?

Gives clear use contexts ('Ideal for relocation planning, directional astrology, and travel-direction maps'), which is more than implied guidance. It does not, however, name or exclude the closely related siblings post_astrology_relocation_chart and post_astrology_astrocartography, so an agent has no explicit routing rule when several overlap.

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 is a safe read (readOnlyHint=true, destructiveHint=false), so the safety profile is covered. The description adds the underlying astronomy (~27.3-day sidereal orbit) and the fact that output is a full tropical chart, but says nothing about authentication, rate limits, or accuracy caveats around the approximate returnDate.

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 sentences are informative and front-loaded, leading with the verb and the precise astronomical condition. However, the trailing keyword list ('Lunar return chart API, monthly horoscope forecast, Moon cycle chart, emotional astrology prediction') is SEO padding that adds no actionable content and dilutes the definition.

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

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

With an output schema present, the description need not detail return values, yet it still summarizes the chart components and the interpretive themes, which is helpful. Combined with 100% schema coverage and annotations, an agent has enough to call the tool correctly; only explicit sibling differentiation 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% and an output schema exists, so the schema already documents all nine parameters including latitude/longitude effects, timezone resolution, and returnDate tolerance. The description adds no parameter-level meaning beyond what the schema states, so the 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?

States a specific verb and resource ('Generate a lunar return chart') and pins down the technical trigger precisely: the moment the transiting Moon returns to its natal ecliptic longitude. It is clearly a natal-chart-based return calculation, but it never names the most confusable sibling, post_astrology_solar_return, so the agent must infer the lunar-vs-solar distinction from domain knowledge.

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

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

The phrase 'primary technique for monthly astrological forecasting' implies when this tool is appropriate, but there are no explicit when-to-use/when-not-to-use rules and no routing to alternatives such as post_astrology_solar_return (yearly) or post_astrology_horoscope_sign_monthly. Usage context is present but left to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the calculation uses the tropical zodiac and is 'Verified against NASA JPL Horizons,' which is a useful accuracy signal, but it does not disclose rate limits, authentication needs, or other operational behavior; much of the remaining text restates return contents that the output schema covers.

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 front-loaded with the core purpose and return contents, and the final accuracy claim is useful. The middle marketing sentence ('Perfect for...') does not help an agent invoke the tool and could be removed, but overall the description is appropriately sized.

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

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

For a 9-parameter, read-only calculation tool with full schema coverage, an output schema, and safety annotations, the description provides enough context about scope and outputs. It does not need to explain return values because an output schema exists, though it could better route agents among the many sibling chart 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?

Schema description coverage is 100%, so all nine parameters—including the house system enum and node type—are already fully documented in the input schema. The description mentions customizable house systems but adds no syntax, defaults, or constraints beyond what the schema provides.

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

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

States a specific verb ('Calculate') and resource ('Western astrology natal chart'), and enumerates the returned bodies, houses, aspects, Ascendant, Midheaven, and dominants. This distinguishes it from narrower sibling tools like post_astrology_planets or post_astrology_houses, which each return a subset.

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 says it is 'Perfect for astrology apps, birth chart generators, horoscope websites, and astrological consultation tools,' which implies usage context but never states when to choose this complete-chart tool over siblings like post_astrology_planets or post_astrology_aspects. No exclusions or prerequisites 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description still adds real value beyond that: the geocentric frame matching ephemerides, the deliberate exclusion of the Moon and its rationale, and the fact that returned times are localized to the caller's timezone with exact closest-approach instants.

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 content is front-loaded and each explanatory sentence (Moon exclusion, geocentric frame, return contents) earns its place. However, the trailing SEO keyword string ('Monthly parallel calendar API, declination aspects, contraparallel ephemeris. Verified against NASA JPL Horizons.') is filler that dilutes an otherwise tight definition.

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

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

With an output schema present and all seven parameters fully described, the description needn't explain return shapes, and it still covers the interpretive context (parallel≈conjunction, contraparallel≈opposition), the excluded body, and the reference frame. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, and the schema already documents orb, lang, year, month, compact, nodeType, and timezone in detail, so the baseline is 3. The description adds little parameter-specific syntax beyond reinforcing that year/month are optional and timezone drives reported event times.

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

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

States a specific verb ('Get every parallel and contraparallel of declination'), a precise resource (declination contacts for a month), and enumerates the exact body set (13 non-lunar Western bodies, Moon excluded). This cleanly separates it from the aspect-oriented siblings like post_astrology_aspects_monthly, since it explicitly notes these contacts are not zodiacal-distance based.

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?

Gives concrete usage contexts ('declination work, out-of-bounds tracking, monthly forecast copy, electional timing') and explains when defaults apply ('Omit year and month to get the month in progress'). It also implies contrast with aspect tables ('surface connections an aspect table cannot show') but never names a specific sibling tool to use instead, so routing is inferred 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds what the chart contains (planetary positions, house cusps, aspects), but says nothing about authentication, rate limits, or how a retrograde multi-crossing return is disambiguated at the description level.

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 two sentences are well front-loaded and informative, but the trailing 'Planetary return chart API, Saturn return calculator, Jupiter return chart, Mars return forecast' is keyword-stuffed filler that repeats the title, and the Saturn-return milestone claim duplicates the schema text.

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

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

With an output schema present, return values need no explanation, and the description adequately conveys purpose and planetary scope for a 10-parameter, 7-required tool. Only the absence of explicit sibling routing keeps it from being fully complete.

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

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

Schema description coverage is 100%, so every parameter, including the retrograde/approximateDate nuance, is already documented in the schema. The description only restates the planet options and cycle lengths, adding no syntax or format detail beyond structured fields, so the 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?

States a specific verb (Generate) plus the resource (planetary return chart) and enumerates the exact supported planets, which cleanly separates it from post_astrology_solar_return and post_astrology_lunar_return without opening either 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 explains what a planetary return is and how long each cycle lasts, which implies when the tool is relevant, but it never states when to prefer it over the solar/lunar return siblings or any prerequisites. Usage is inferable 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the returned fields and an accuracy claim ('Verified against NASA JPL Horizons'), giving useful context, but says nothing about rate limits, precision caveats, or how the coordinate/timezone inputs affect output 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, front-loaded with the core verb+resource and body list, and no repetition of the name. Slightly diluted by marketing phrasing ('Perfect for...', 'Verified against NASA JPL Horizons'), but still tight and well ordered.

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

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

With an output schema, full parameter coverage, and read-only annotations, the description only needs to frame scope and inputs, which it does. The remaining gap is the lack of sibling routing, but nothing essential 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% and each field already carries rich prose (timezone formats, node conventions, compact shape). The description adds no parameter-level detail beyond the schema, so the 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?

States a specific verb (calculate) and resource (tropical zodiac positions) and enumerates the exact 14 bodies covered, which is a concrete scope statement. Combined with 'for any date, time, and location', it clearly separates this arbitrary-date ephemeris tool from siblings like post_astrology_planets_monthly, post_astrology_lilith, and post_astrology_asteroids.

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?

Lists use-cases ('transit tracking, ephemeris tables, astrology apps, planetary position widgets') which implies context, but never names a condition that selects this tool over the many overlapping siblings (planets_monthly, transits, transit_aspects). No when-not-use or explicit alternative routing is provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description adds genuinely useful behavior: calculation is at noon UTC, the year/month omission yields the current month, and the data is verified against NASA JPL Horizons. It does not mention rate limits or output shape, but the output schema covers the latter.

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 front-loaded and information-dense, but the closing 'Monthly ephemeris API, tropical position table, daily planet transit positions, ecliptic longitude calculator' is keyword stuffing that restates the same concept four ways and dilutes the definition.

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

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

With an output schema present, the description need not explain return values, and it does cover the bodies, the time basis, and the default-date behavior. All parameters are optional and their defaults are documented, so an agent has enough to call it correctly; only the lang and compact options go unmentioned 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?

Schema description coverage is 100%, so the baseline is 3; the schema already documents ranges, defaults, and the lang enum. The description adds only the motivation for the year/month default ('so a published ephemeris page stays current without a redeploy') and says nothing about lang or compact, so it does not meaningfully exceed the schema.

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

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

States a specific verb and resource ('Get daily tropical ecliptic positions for all 14 Western bodies ... for an entire month') and enumerates exactly which bodies are covered, so scope is unambiguous. It differentiates itself from single-day siblings through the explicit monthly scope, though it never names the closest alternatives (e.g. post_astrology_planets, post_astrology_transits_monthly) to sharpen the 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?

Offers use cases ('ephemeris tables, transit tracking, retrograde calendars, planetary movement charts') and one concrete operational hint ('Omit year and month to get the month in progress'), which implies when the tool fits. However, it gives no guidance on when to prefer this over the daily/single-planet or transit-monthly siblings, and no exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by spelling out what the calculation produces (age, profected house/sign, lord of the year with natal sign and house, plain-language interpretation) and the technique that drives it, though it says nothing about auth, rate limits, or edge cases (e.g. targetDate before birth, which the schema handles).

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

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

Three sentences, front-loaded with the core action and output, with no filler. It is slightly longer than strictly necessary given the schema and output schema carry the detail, but every sentence conveys real 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?

With an output schema present, annotations covering the read-only profile, and full parameter documentation in the schema, the description only needs to establish purpose, mechanism, and output gist — all of which it does. An agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all ten parameters in detail. The description adds only conceptual framing (birth chart + target date) and no parameter-specific syntax or format detail beyond what the schema provides, so the baseline of 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?

States a specific verb+resource ('Calculate the annual profection and lord of the year for any birth chart and target date') and names the distinctive Hellenistic time-lord technique, which cleanly separates it from siblings like progressions, solar return, or transits. The one-line mechanism (each completed year advances the rising sign by one whole-sign house) makes the tool's scope unambiguous.

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

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

The description explains the technique well but never states when to choose this tool over alternatives such as post_astrology_progressions, post_astrology_solar_return, or post_astrology_planetary_returns, and gives no exclusions or prerequisites. Usage is only implied by the technique's definition.

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

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

Annotations already establish the safe read-only profile. The description adds the calculation method and the returned contents (bodies with sign, degree, whole-sign house, motion, retrograde state, plus Ascendant/Midheaven via the Naibod arc), which is useful, but it says nothing about limits, accuracy caveats, or behavior when the birth time is unknown.

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 is well front-loaded and technically informative, but the trailing sentence ('Secondary progressions API, progressed chart calculator, progressed Sun and Moon, progressed Ascendant and Midheaven') is pure keyword stuffing that repeats earlier content and dilutes the definition.

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

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

With an output schema present, the description need not enumerate return fields, yet it usefully summarizes them, and annotations cover safety. For a 9-parameter tool it is largely complete; only the missing routing guidance against sibling techniques keeps it from a 5.

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

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

Schema coverage is 100% and the schema already explains every parameter, including the day-for-a-year semantics of targetDate. The description restates that mechanism at a high level but adds no format, default, or edge-case detail beyond the schema, so the baseline of 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?

States a specific verb (generate) and resource (secondary progressed chart) and explains the defining technique, the day-for-a-year key, which implicitly separates it from solar arc and profections. However, it never names a sibling tool, so the differentiation is inferential rather than explicit.

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

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

The description explains what progressions are and that the progressed Sun/Moon are timing markers, but gives no when-to-use guidance, no conditions for choosing this over transits, profections, or solar arc, and no prerequisites or 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 mark the tool as readOnlyHint=true and destructiveHint=false, so no contradiction exists. The description adds useful behavioral nuances beyond annotations: the birth moment stays unchanged, planets keep natal signs and degrees, only angles and house cusps are recomputed, and results are 'Verified against NASA JPL Horizons.' This gives the agent confidence about the computation's scope and reliability.

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 information-dense, with every sentence earning its place: the core behavior, the computation details, the returned contents, and the target use cases. It is front-loaded with the main action and avoids redundant restatement of the tool name or title.

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 complete schema documentation and an output schema present, the description covers everything an agent needs to select and invoke it correctly: what it computes, what it returns, how it behaves relative to natal positions, and for which use cases it is intended. No critical gaps remain.

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

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

Schema description coverage is 100%, and each parameter already has detailed descriptions, examples, formats, and constraints. The tool description adds a helpful conceptual framing (birth moment fixed, angles recomputed) but does not substantially enrich individual parameter meaning 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 states a precise verb and resource: 'Calculate a relocation chart (relocated birth chart)' for a new place on Earth, with an exact definition of what is recomputed and what stays fixed. It clearly distinguishes the tool from siblings like natal charts, astrocartography, and local space by emphasizing that planetary positions remain natal while only angles and house cusps shift.

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

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

The description provides clear context for when to use the tool: 'Built for relocation astrology readings, astrocartography style move planning, and travel charts.' It does not explicitly name alternative sibling tools or state when not to use it, but the use cases are specific enough to guide an agent's selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful non-obvious detail: the exact arc computation, that every natal point including Ascendant and Midheaven is advanced, and what the response contains. It omits any note on rate limits, precision limits, or timezone edge cases, which keeps it short of a 5.

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

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

Front-loaded with the core action and the arc definition before the return payload, which is the right ordering. It is somewhat padded with promotional clauses ('Built on accurate tropical chart positions, no astronomy expertise needed') that do not help invocation.

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

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

With an output schema present, return values need not be explained, and the required-parameter set is fully covered by the schema. The description supplies the conceptual model needed to call the tool correctly; only the missing sibling differentiation keeps it from being fully complete.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema, including targetDate's semantics. The description reinforces the targetDate concept ('about one degree for each year of life') but adds no syntax or format meaning beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Calculate a solar arc directed chart') and defines the mechanism precisely: secondary-progressed Sun minus natal Sun, applied to every natal point. This clearly separates it from sibling predictive techniques such as post_astrology_progressions, post_astrology_profections, and post_astrology_transits.

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

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

Offers a target use case ('predictive astrology apps timing major life events') but never states when to choose this over the closely related progression/profection/transit siblings, and gives no exclusions or prerequisites. Usage is implied rather than directed.

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 safety is covered. The description adds useful behavioral context (location sensitivity, the moment of casting) but, with an output schema present, its listing of returned fields is largely redundant and it omits rate limits or precision caveats.

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 content is front-loaded and readable, but the closing string of SEO keywords ('Solar return chart API, annual horoscope forecast, birthday chart calculator, yearly astrology prediction, relocated solar return') is filler that adds no invocation value and dilutes the entry.

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

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

With an output schema present, return values need not be spelled out, and the description nonetheless covers inputs, casting basis, and location sensitivity. It is nearly complete for an agent to call correctly, missing only explicit alternative-tool routing.

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 every parameter is already documented in the schema. The description's only added semantics is reinforcing that location inputs change houses/Ascendant, which the schema also states. 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?

States a specific verb (Generate) and resource (solar return chart) and precisely defines the technique: the chart cast for the moment the transiting Sun returns to its natal ecliptic longitude. This clearly distinguishes it from natal_chart, lunar_return, and planetary_returns 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 conveys the applicable scope ('for any year') and a key usage nuance ('Location-sensitive: relocating... changes the houses and Ascendant'), but never names when to choose this over siblings like post_astrology_lunar_return or post_astrology_planetary_returns, nor any prerequisites. Usage is implied rather than explicitly routed.

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 a compatibility score and inter-aspect details, but since an output schema exists, this return-value summary is mostly redundant and it does not disclose auth, rate limits, or error behavior.

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

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

The first three sentences are informative and front-loaded with the core calculation and return contents. However, the final two sentences ('Perfect for dating apps...' and 'Based on professional astrological techniques.') are promotional filler that does not help an agent select or invoke the tool.

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

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

The tool is complex, with nested objects, five top-level parameters, and an output schema. The description covers the computation and output at a high level, but it omits usage guidance relative to siblings and adds no parameter semantics, so it is only minimally complete for correct selection.

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

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

Schema description coverage is 60%, and the description mentions no parameters at all. It does not explain the required person1/person2 objects, the optional lang/compact controls, or the houseSystem/nodeType choices beyond what the schema already provides, leaving a compensation gap for the uncovered parameter surface.

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: 'Calculate complete synastry (relationship compatibility) between two natal charts using Western tropical astrology.' It is clear what the tool computes, but it does not distinguish itself from sibling tools like post_astrology_compatibility_score or post_astrology_composite_chart, which likely overlap in relationship-compatibility 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 gives marketing-oriented use cases ('Perfect for dating apps, matrimonial sites...') but no operational guidance about when an agent should call this tool versus sibling compatibility or chart tools. There are no exclusions, prerequisites, or named 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 establish that this is a safe, read-only operation, so the bar is lower; the description still adds real context by enumerating the per-aspect outputs (aspect type, orb, applying/separating status, narrative interpretation, impact rating, practical guidance) and the summary rollups. It does not mention auth, rate limits, or cost despite being a POST compute-heavy endpoint, which keeps it short of a 5.

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

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

The first three sentences are information-dense and front-loaded, but the closing string "Transit aspects API, transit-to-natal analysis, predictive astrology, personalized transit forecast" is keyword stuffing that adds no selection signal. The middle sentence partly duplicates the return-value sentence immediately before it (summary, timing, impact, guidance listed twice).

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 100% schema coverage, an output schema, and read-only annotations, the description needs only to establish purpose and the distinguishing feature set, which it does. The remaining gap is routing: nothing tells the agent why to choose this over post_astrology_transits or post_astrology_transits_monthly, which is a real risk given how many near-identical siblings exist.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters in depth, establishing a baseline of 3. The description only restates that planet, aspect-type, and minStrength filtering exist; it adds no format or syntax detail beyond what the schema provides, so it neither compensates nor detracts.

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 ("Calculate all transit-to-natal aspects") and then scopes it precisely: it explains that it compares current or future planetary positions against a natal chart, and that it adds planet/aspect-type/minStrength filtering plus summary.strongest and byType rollups on top of the base transits behavior. That contrast is enough to separate it from post_astrology_transits and post_astrology_aspects without opening a 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?

Usage is only implied through the "Like /astrology/transits with a natalChart... Adds filtering" framing and the parenthetical "(or future)" positions. There is no explicit when-to-use or when-not-to-use statement picking between this tool, post_astrology_transits, and post_astrology_transits_monthly, so the agent must infer the choice from feature differences.

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 safety is covered by structured data. The description adds conditional behavior ('when natal chart provided, includes transit aspects with orbs and applying/separating status') and the body set returned, but since an output schema exists these return details are partly redundant and no auth/rate-limit context is given.

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, front-loaded with the core verb+resource, then output contents, then the conditional natal-chart behavior, then use cases. Mostly earns its place, though the enumeration of the 14 celestial bodies is slightly verbose given the output schema already lists them.

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 read-only annotations plus a full output schema and 100% schema coverage, the description is complete enough to invoke correctly: it clarifies scope (all bodies), the optional natal comparison, and the aspect output. Only the sibling differentiation 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% (date, time, timezone, lang, nodeType, compact, natalChart all documented in-schema), so the baseline is 3. The description adds no further parameter meaning, wording, or format details 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?

States a specific verb+resource ('Calculate current or future planetary transits') and names the optional natal-chart comparison, so the agent knows exactly what the tool produces. However, it does not distinguish itself from close siblings like post_astrology_transit_aspects (aspect-only) or post_astrology_transits_monthly (date-range variant), which is the main ambiguity it leaves.

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 offers scenario hints ('Perfect for daily transit forecasts, aspect alerts, and personalized transit reports'), which imply when the tool is useful, but gives no explicit when-to-use vs alternatives guidance and no exclusions against the many transit/aspect siblings. Usage is implied rather than directed.

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

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

Annotations already establish a safe read (readOnlyHint=true, destructiveHint=false), and the description adds real behavior beyond that: timezone offset is resolved once at window start and applied to every returned time, omission of year/month yields the live month, and results are verified against NASA JPL Horizons with cardinal ingresses cross-checked. It does not cover response size, pagination, or failure modes, keeping it short of a 5.

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

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

The opening sentence is front-loaded and efficient, but the trailing line 'Monthly transit API, planetary ingress calendar, sign change dates, tropical transit table' is keyword padding that conveys no operational meaning, and the JPL verification sentence is trust marketing rather than call guidance.

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

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

For a no-required-parameter tool with an output schema already present, the description covers everything an agent needs: scope of bodies, ingress payload, current-month default behavior, timezone handling, and data provenance. Return values are explained even though the output schema would have sufficed.

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%, including an unusually detailed nodeType explanation and the compact shape, so the schema already carries parameter semantics. The description only restates a few of these (timezone, omitted year/month), adding little beyond structured data; the baseline 3 applies.

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