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 the safety profile is covered. The description adds the useful detail that every day's phase and illumination are included, but it does not disclose additional operational constraints such as rate limits, timezone handling, or response behavior. This is adequate but not exceptional.

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

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

The description is two sentences with the core specification front-loaded. The second sentence provides legitimate use cases, though 'Perfect for' is slightly promotional. Overall it is concise and well structured without unnecessary detail.

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

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

Given the output schema exists and annotations already cover read-only behavior, the description plus schema fully define invocation: required year/month, optional lang and compact, and month-long phase/illumination output. No critical gap prevents an agent from selecting or calling this tool correctly.

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

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

Schema description coverage is 100%: every parameter (lang, year, month, compact) has a clear description, defaults, and valid ranges. The description itself adds no parameter-level meaning beyond what the schema already provides, 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?

The description uses a specific verb and resource: 'Get complete lunar calendar showing moon phase and illumination for every day of a specific month.' It clearly distinguishes this from the sibling current/upcoming moon phase tools by emphasizing month-long, day-by-day coverage.

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 communicates clear context: this is for full-month lunar calendar data, useful for planners and astrology schedules. It stops short of explicitly naming alternatives like get_astrology_moon_phase_current or get_astrology_moon_phase_upcoming, but the 'every day of a specific month' phrasing makes the usage context clear.

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

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

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, covering the safety profile. The description adds that it returns dates and phase names for each lunar quarter and is scoped to upcoming weeks/months, but does not disclose details like timezone handling or boundary conditions. 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?

Two sentences with no waste: the first front-loads the action and return value, the second gives concrete use cases. Nothing repeats the schema or annotations.

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

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

For a simple, parameter-optional query tool, the description combined with full schema coverage, annotations, and an output schema is sufficient to invoke correctly. The only gap is not explicitly routing the agent away from sibling moon-phase 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%, with lang, count, compact, and startDate all documented with defaults, constraints, and examples. The description adds no parameter-specific semantics, 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: 'Get upcoming moon phase transitions' and names all four phases. 'Upcoming' and 'next weeks/months' clearly separate it from sibling tools like get_astrology_moon_phase_current and get_astrology_moon_phase_calendar_year_month.

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

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

Provides clear context with use cases: 'Perfect for lunar event calendars, moon phase widgets, and astrology planning tools.' It does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.

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

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

Annotations already declare 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 establish the safety profile (readOnlyHint=true, destructiveHint=false); the description adds genuine behavioral context beyond that: the day/night formula is applied automatically from chart sect, positions are tropical, and the tool returns an interpretation per lot. Nothing contradicts the annotations, so the score reflects real added value.

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, roughly 90 words, with the main verb front-loaded in the first sentence. Each sentence carries distinct information: scope, lot list, method and output, target use case. Minor redundancy exists between sentences 1 and 2, but overall it is efficient 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 a full output schema and 100% parameter schema coverage, the description need not explain return values or parameters. It covers purpose, method, output items, and target audience, which is sufficient for an agent to invoke this calculator correctly. There is no critical invocation detail 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 per the rubric the baseline is 3. The description touches lightly on parameters ('birth moment' maps to date/time; 'chart sect' relates to houseSystem) but does not need to compensate since the schema already gives rich per-parameter explanations, including an extensive nodeType and houseSystem write-up.

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

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

The description opens with a specific verb and resource ('Calculate the seven Hermetic lots (Arabic parts) for any birth moment') and enumerates all seven lots by name. It also describes the computational method (arc from the Ascendant, day/night formula from sect), which clearly differentiates it from the many sibling astrology tools such as 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?

Usage context is implied: 'for any birth moment' and 'for Hellenistic and traditional astrology apps' suggest when an agent would select this tool. However, it names no alternative tool and gives no explicit when-not-to-use or exclusion conditions, leaving the agent to infer the boundary against 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 valuable behavioral context beyond that: it discloses the disambiguation logic (Grand Cross suppresses contained T-Squares, Kite suppresses underlying Grand Trine), the tightness score range (0-100), the dissociate flag, and the one-line interpretation. This is meaningful behavioral disclosure that helps an agent understand what the tool will and won't return.

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

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

The description is a single dense paragraph that front-loads the core purpose and pattern list, then adds the disambiguation behavior and use cases. It is somewhat long but every sentence carries information: the pattern enumeration, the score/flag/interpretation details, the suppression logic, and the use cases. The structure could be improved with line breaks, but the content is efficient.

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

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

The tool has 10 parameters, a rich output schema, and full schema coverage, so the description doesn't need to explain parameters or return values. The description covers the pattern types, the disambiguation behavior, the score/flag/interpretation fields, and the intended use cases. The only minor gap is that it doesn't mention the 'include' parameter's effect on pattern detection (e.g., whether Chiron participates in patterns), but the schema covers the parameter itself.

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 10 parameters thoroughly. The description adds no parameter-specific semantics beyond what the schema provides, which is acceptable given the baseline of 3 for high coverage. The description's mention of 'tightness score' and 'dissociate flag' relates to output rather than input parameters.

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

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

The description names a specific verb ('Identify') and a precise resource ('classical Western astrology multi-planet configurations in a birth chart'), then enumerates the exact pattern types returned. It clearly distinguishes this from sibling tools like post_astrology_aspects (which handles two-planet aspects) and post_astrology_natal_chart (which returns the full chart).

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

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

The description states the tool is 'Useful for personalized natal report engines, astrology chatbots, AI agents that interpret chart geometry, and editorial chart-pattern callouts,' which gives clear context for when to invoke it. It does not explicitly name sibling alternatives or state when not to use it, but the pattern-specific scope is strongly implied by the detailed pattern list.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it states that the tool returns applying/separating status and a 0-100 strength, supports filtering, and uses 'standard Western astrology orbs.' This helps set expectations about output richness and orb conventions without contradicting the annotations.

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

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

The description is compact and front-loaded: it opens with the core action, then defines aspect types, output fields, filtering, use cases, and orb conventions. Every sentence contributes information, and there is no filler or tautological restatement of the tool name. The use-case list is brief but adds useful context.

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 detailed input schema (100% coverage), an output schema, and read-only annotations, the description is largely sufficient for an agent to select and invoke the tool. It covers the single date/time scope, output highlights, filtering, and orb conventions. The main missing piece is explicit sibling differentiation, but that is already accounted for in usage guidelines.

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

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

Schema description coverage is 100%, so the schema already fully documents date, time, timezone, lang, compact, planets, and aspectTypes. The description only reinforces that planets and aspectTypes can filter results and that minor aspects are included by default, adding little beyond the schema. This matches the baseline of 3 for high schema coverage.

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

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

The description uses a specific verb and resource: 'Calculate all major and minor aspects between planets for any date and time,' and it enumerates the output fields (aspect type, angle, orb, applying/separating status, strength). This clearly states what the tool does. It does not explicitly contrast the tool with nearby siblings like post_astrology_aspects_monthly or post_astrology_transit_aspects, so sibling differentiation is only implicit.

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 aspect tables, transit analysis, and aspect pattern detection,' which gives use cases but no decision rule for choosing this tool over alternatives. With sibling tools such as post_astrology_aspects_monthly, post_astrology_transit_aspects, and post_astrology_aspect_patterns present, explicit guidance about when to use this tool versus those would help. No exclusions or alternative routing are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond that: exact date/time of closest approach in the user's timezone, tropical longitude calculation, and verification against NASA JPL Horizons. No contradiction with annotations.

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

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

The description is front-loaded with the core function and then adds scope, exclusions, and use cases in a logical order. The trailing keyword cluster ('Monthly aspect calendar API, exact aspect times, planetary aspect ephemeris, transit timing') is somewhat redundant, but nearly every other sentence earns its place.

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

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

For a tool with 6 parameters, an output schema, and read-only annotations, the description is remarkably complete: it covers body scope, aspect list, calculation basis, timezone behavior, default month handling, and verification. The output schema handles return-structure details, so nothing critical is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some parameter-level insight, such as timezone affecting returned times and 'Omit year and month to get the month in progress,' but it does not delve into lang, compact, or nodeType beyond what the schema already documents.

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

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

The description states a specific verb and resource: 'Get every planetary aspect that perfects during a given month' across the 13 non-lunar Western bodies. It enumerates which bodies and which aspects are covered, and the monthly scope clearly distinguishes it from siblings like post_astrology_aspects and post_astrology_transits_monthly.

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

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

The description gives clear usage context: 'Essential for monthly forecast copy, transit calendars, electional timing, and newsletter automation,' and explains the behavior when year/month are omitted. It does not explicitly name sibling alternatives or state when-not-to-use this tool, but the Moon-exclusion rationale and monthly framing make the intended use unmistakable.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds behavioral detail about the output (zodiac sign, degree, house, speed, retrograde status, interpretation) and the scope (four asteroids only). No contradictions exist. It doesn't mention edge cases like polar circle house fallback, but that's already in 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?

Two sentences, zero fluff. The first sentence front-loads the core purpose, and the second adds a scoping distinction. Every word earns its place.

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

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

The tool has 9 parameters (5 required) and an output schema, which the description leverages. It explains the returned data and differentiates from Chiron, covering the main usage context. It doesn't mention house system or node options, but those are thoroughly described in the schema. For a complex astrology tool, this is adequately 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% with detailed explanations for all 9 parameters. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline 3 applies. It doesn't compensate for any schema gaps, but none exist.

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

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

The description explicitly states the tool calculates natal positions of the four classical asteroid goddesses (Ceres, Pallas, Juno, Vesta), with a specific verb and resource. It also differentiates from sibling tools by noting Chiron is available via the natal chart endpoint, ensuring no ambiguity about 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 context: 'for natal reports and relationship astrology' and explicitly mentions that Chiron is handled elsewhere. While it doesn't name a specific alternative tool, the Chiron reference effectively guides when not to use this endpoint. It could be more explicit about when to prefer other post_astrology_* tools, but the context is sufficient.

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 tool read-only and non-destructive, so the description does not need to cover safety. It adds behavioral context by describing exactly what the map returns (right ascension, declination, meridian longitudes, sampled curves, interpretation), which goes beyond the raw readOnlyHint. This helps the agent anticipate output shape and purpose without contradicting the annotations.

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

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

The description is three sentences with no filler: the first sentence states the core action, the second gives context/meaning, and the third lists the return contents. Each sentence earns its place, and the primary verb is front-loaded. It is informative without being verbose.

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

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

Given the tool's complexity (9 parameters, output schema present), the description efficiently covers the core behavior, the output format, and the interpretive component ('short interpretation per line'). It does not elaborate on edge cases or alternatives, but the schema and annotations already carry that weight. The missing differentiation from close siblings is a minor gap in an otherwise complete picture.

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 (date, time, latitude, longitude, timezone, include, nodeType, lang, compact) already has detailed semantic descriptions. The tool description adds no parameter-level meaning beyond the general 'birth moment' phrase. With full schema coverage, the baseline of 3 is appropriate.

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

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

The description opens with a precise verb ('Generate') and a specific resource ('astrocartography map of Midheaven, Imum Coeli, Ascendant, and Descendant planetary lines'). It further explains what the lines represent ('where a planet turns angular'), which separates it from generic relocation charts or other astrology maps. The level of detail makes the tool's purpose unmistakable without needing to open the schema.

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

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

The explanation that this is 'the core of relocation astrology and astro mapping' implies when it should be used, but no alternatives are named and no exclusion criteria are given. Sibling tools like post_astrology_relocation_chart or post_astrology_local_space are not mentioned, so the agent must infer relative fit from the description alone. That meets the 'implied usage' bar, not explicit 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is already known. The description adds useful context about the return categories (romantic, emotional, etc.) and specific planetary pairs, but does not disclose any additional behavior such as error handling, rate limits, or edge cases. Since output schema exists, return format details are not required here. The description adds moderate value beyond annotations.

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

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

The description is one focused paragraph that front-loads the core purpose ('Calculate a detailed compatibility score...') and then enumerates the breakdowns. It is detailed but not bloated, with each sentence contributing useful information about output composition. Slightly longer than necessary but well-structured.

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

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

For a read-only tool with a rich input schema and an output schema (indicated), the description covers the key aspects: what it returns (score, categories, narratives, elements, archetypes, aspects). It does not mention when to choose this over the sibling post_astrology_synastry, which is a notable gap given the tool list. Otherwise, it is complete for the given complexity.

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

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

Schema description coverage is 100%, with detailed descriptions for person1, person2, lang, and compact. The tool description itself adds no parameter-specific information beyond what the schema already provides, so it does not elevate the semantics. 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?

Clearly states it calculates a detailed compatibility score between two birth charts using Western synastry, with specific verb and resource. It lists return contents, but does not explicitly distinguish itself from the sibling post_astrology_synastry, which also likely deals with inter-chart aspects. Thus it is clear but lacks explicit sibling differentiation.

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

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

Provides no guidance on when to use this tool versus alternatives like post_astrology_synastry or post_astrology_composite_chart. It does not state when not to use it or mention any prerequisites beyond the required input. The agent must infer its applicability from the name and description alone.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: it explains the midpoint calculation, the invariant that the Ascendant sits on the first cusp, and exactly what the response contains. No contradiction with annotations.

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

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

The main action and method are front-loaded in the first sentence, and the body is reasonably tight. However, the trailing keyword string — 'Composite chart API, midpoint chart calculator, relationship astrology, couple chart analysis' — is redundant SEO 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?

For a read-only calculation with a full output schema, 100% parameter coverage, and helpful annotations, the description covers what the tool does, how it calculates, and what it returns. The only notable gap is the missing guidance on when to choose this over synastry, but that is a usage-guidance concern already scored separately.

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 thoroughly documents all five parameters including person1/person2, lang, compact, and houseSystem. The description adds no parameter-level detail beyond referring to 'two natal charts,' which maps directly to person1/person2. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Generate a composite chart by calculating midpoints between two natal charts.' It explains what the chart represents and the method used, which distinguishes it conceptually from relationship-comparison tools like synastry, though it does not explicitly name any sibling tool.

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

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

The description implies the tool is for relationship/couple analysis through phrases like 'relationship as a single entity' and 'couple chart analysis,' but it gives no explicit when-to-use guidance, no exclusions, and does not mention alternatives such as post_astrology_synastry. The usage context is clear only by 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 mark the tool as readOnly and non-destructive, and the description adds rich behavioral context: it defines ascending vs. descending node passages, clarifies that these are exact-on-plane moments rather than near-plane, specifies the return shape (date/time, tropical longitude, sign), and notes the NASA JPL Horizons verification. This goes well beyond what annotations convey and gives the agent a solid mental model of the tool's 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 description is front-loaded with the core purpose and keeps essential semantics early. Most sentences earn their place, but the final line 'Ecliptic crossing API, planetary node passage, ascending and descending nodes.' is keyword-style repetition that adds no agent value. Minor fluff aside, the structure is clear and logically 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?

The description covers included bodies, excluded bodies, node definitions, return contents, timezone handling, use cases, and data verification. Combined with a fully documented input schema and an output schema, an agent has everything needed to invoke the tool correctly. There is no material missing context for a read-only calculation tool.

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

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

Schema description coverage is 100%, so the baseline is 3 and the description need not compensate. The description does reinforce semantic meaning for 'year' ('during a given year') and 'timezone' ('in your timezone'), but these are already fully documented in the schema. It adds no new parameter-level insight beyond what the schema provides, which is appropriate given the high coverage.

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

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

The description opens with a precise verb and resource: 'Get every moment a body crosses the plane of the ecliptic during a given year,' and then enumerates exactly which bodies are included (Moon through Pluto, Chiron, Black Moon Lilith). It explicitly states what the tool is not (Sun and lunar nodes are excluded), which differentiates it clearly from any sibling astrology tool. The purpose is unambiguous and immediately actionable.

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

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

The description names concrete use cases—'eclipse-season work, node timing, and astronomical calendars'—and explains the significance of crossings in eclipse prediction, which informs when an agent should choose this tool. It does not explicitly point to a sibling alternative or state when not to use it, but the tool is unique enough among siblings that this is a minor omission. Clear context is provided without formal 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 read-only safety profile is covered. The description adds context about what the tool computes (precessed longitudes, conjunctions, plain language interpretations) but does not go into side effects, rate limits, or auth requirements. This is acceptable given the annotation coverage.

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

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

Four sentences, each with a distinct purpose: action, scope, output details, and use case. No fluff or redundancy. The core purpose is front-loaded, and the description earns its length.

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

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

Given the output schema exists and the annotations cover safety, the description is complete for a well-scoped tool: it explains the star coverage, the conjunction detection, and the use case. It could explicitly name sibling tools for other calculations, but the title and sibling list make the boundary clear enough.

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% (all 9 parameters are documented), so the baseline is 3. The tool description mentions the 'chosen orb' but does not add meaningful parameter semantics beyond what the schema already explains, such as orb's min/max/default or timezone resolution rules. 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 names a specific verb and resource ('Calculate the tropical zodiac positions of the major named fixed stars') and delineates scope ('four Royal stars and the fifteen Behenian stars', conjunctions to planets, Ascendant, Midheaven). It clearly distinguishes itself from siblings like post_astrology_planets or post_astrology_asteroids by focusing on fixed stars and their conjunctions.

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: 'A focused tool for natal reports that weigh Regulus, Spica, Aldebaran, Antares, and Algol against the chart.' This implies when to use it (natal star analysis) but does not explicitly mention alternative tools or state when not to use it. Still, the use case is concrete and distinguishes it from other chart tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the capability to compare all four house systems and claims accurate Ascendant/MC calculations, but these are largely redundant with the output schema and parameter descriptions. No additional behavioral traits like rate limits or prerequisites are 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 description is front-loaded with the core purpose, but it contains redundancy: 'Returns all 12 house cusps with zodiac signs, degrees, Ascendant, and Midheaven' is followed by 'Includes accurate Ascendant and MC calculations,' repeating the same information. The 'Perfect for' sentence is somewhat promotional and does not add technical value, 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?

For a read-only calculation tool with a rich output schema and fully described parameters, the description covers the essential context: what it computes, which systems are supported, and when comparison mode is useful. It does not address edge cases like high-latitude distortion or DST handling, but those are already documented in the schema descriptions, so the overall package is complete enough for an agent to call the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions the 'all' parameter and house system options, but these are already described in the schema's houseSystem property. It does not add significant new meaning for individual parameters beyond what the schema already provides.

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

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

The description opens with a specific verb and resource: 'Calculate astrological house cusps' and enumerates the supported systems (Placidus, Whole Sign, Equal, Koch). It clearly distinguishes this tool from siblings like post_astrology_aspects or post_astrology_natal_chart by focusing solely on house cusps and listing the specific output (cusps, Ascendant, Midheaven).

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

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

The description provides clear use cases ('Perfect for astrology charts, house cusp tables, and educational tools showing house system differences') and highlights the 'all' parameter for side-by-side comparison. However, it does not explicitly state when not to use it or name alternative tools, stopping short of full usage guidance.

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

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

The description adds value beyond annotations: it explains that true Lilith can shift sign and turn retrograde, and discusses the mean/true difference in a way not covered by annotations. It also mentions the return includes interpretation, which is useful. The annotations already declare read-only and non-destructive, and the description aligns with that, so no contradiction.

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

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

The description is two sentences, with the first sentence covering core functionality and variants, and the second describing outputs and audience. It is front-loaded with the core action and returns, but the second sentence adds slightly fluffy language ('wild, suppressed, and reclaimed self') that is not strictly necessary. Overall, it's efficient but not perfectly lean.

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

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

Given the tool's moderate complexity with 9 parameters and an output schema, the description adequately covers inputs, outputs, and use cases. It discusses the mean/true distinction, return fields, and audience. The only minor gap is not explicitly contrasting with very similar sibling tools, but the output schema and detailed param descriptions cover most needs.

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?

Though schema coverage is 100%, the description enhances several parameters: it explains nodeType in depth (mean vs true, sign agreement, cusp proximity), and clarifies timezone resolution for IANA vs numeric offsets. It also implicitly ties latitude/longitude to birth location, though less explicitly for those. This goes beyond the schema's basic field descriptions.

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

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

The description clearly states the tool calculates Black Moon Lilith, specifically both mean and true lunar apogee, for a birth chart. It distinguishes itself from siblings like post_astrology_planets or post_astrology_natal_chart by focusing on this specific point and its variants, making the purpose unambiguous.

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

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

The description implies use for natal astrology apps and agents exploring Lilith's themes, and the distinction between mean and true is explained. However, it doesn't explicitly state when to prefer this over siblings like post_astrology_planets or post_astrology_natal_chart, nor does it mention when not to use it. This is a moderate gap given the large sibling set.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral detail: it projects natal planets onto the local horizon, computes azimuth in degrees clockwise from true north, altitude, 16-point compass direction, horizon status, and directional-line waypoints. This goes well beyond the safety annotations and gives the agent a precise mental model of the calculation.

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, each doing distinct work: define the computation, list the returned data, and state the use cases. The core scope is front-loaded and there is no filler or repetition of schema details.

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

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

For a read-only compute tool with a full input schema and an output schema present, the description covers what the tool does, what it returns, and when it is useful. Nothing essential for selecting or invoking it correctly is missing.

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

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

Schema description coverage is 100%, with each of the 8 parameters already documented clearly, including formats, units, defaults, and allowed values. The tool description adds no new parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description opens with a specific action and resource: 'Generate a local space astrology map' that 'projects the natal planets onto the local horizon as compass directions and great-circle lines.' It then enumerates the exact outputs, making the tool's scope unmistakable. The 'local horizon' and 'compass directions' framing clearly separates it from global/relocation chart siblings like astrocartography without requiring the agent to open 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?

The description gives concrete use cases: 'relocation planning, directional astrology, and travel-direction maps.' This is clear positive context for when to invoke it. However, it never names sibling tools or states when not to use it, so it stops short of full when-not/alternatives guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral context by specifying the exact return condition and the chart contents: planetary positions, house cusps, aspects, Ascendant, and Midheaven. It also explains the interpretive scope ('emotional patterns, domestic focus, intuitive themes') without contradicting the annotations.

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

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

The first three sentences are efficient and front-loaded with the core definition, cycle, and output contents. The final keyword sentence ('Lunar return chart API, monthly horoscope forecast, Moon cycle chart, emotional astrology prediction.') is redundant SEO-style phrasing that repeats the title and adds no operational value.

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

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

Given 9 parameters, 100% schema coverage, an output schema, and read-only annotations, the description provides adequate context: it explains the astronomical trigger, the output chart contents, and the forecast use case. It does not need to describe return values because the output schema exists; the main missing piece, routing against sibling tools, is already accounted for under usage guidelines.

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 even though the description adds no parameter-level details. The prose reinforces the exact-moment calculation and the monthly return concept, but it does not add syntax, formats, or semantics beyond what the schema already provides.

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

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

The description opens with a specific verb+resource: 'Generate a lunar return chart for any month,' and precisely defines the trigger as the moment the transiting Moon returns to its natal ecliptic longitude. It clearly distinguishes this from sibling monthly transit/aspect tools by naming the exact astronomical technique and listing the returned chart components.

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

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

The description states that the lunar return is 'the primary technique for monthly astrological forecasting' and explains the ~27.3-day cycle, giving the agent a clear context for selecting this tool. It does not explicitly name sibling alternatives such as post_astrology_solar_return or post_astrology_planetary_returns, so it stops short of a full when-not-to-use statement.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context: mentions 'Verified against NASA JPL Horizons' for accuracy, lists output scope (14 bodies, 12 houses, aspects), and clarifies return items like Ascendant and dominants. This adds value beyond annotations.

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

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

The description is rich but efficient, with key output and use-case information front-loaded. It doesn't waste words, though it's longer than strictly necessary. Still, it's well-structured for an agent to quickly grasp scope.

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

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

Given the tool's complexity (9 params, output schema), the description covers scope well but could add more on output structure or edge cases (e.g., what happens with invalid dates). However, the output schema is present, so return details are likely covered. Doesn't mention error handling or prerequisites beyond timezone.

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 parameters are well-documented. The description doesn't add much on top for most params, but it does hint at house systems and body lists. However, it lacks details on optional params like lang and compact. Given high coverage, this is above baseline but not perfect.

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 'Calculate complete Western astrology natal chart (birth chart) with tropical zodiac' and lists specific outputs like celestial bodies, house cusps, and aspects. It distinguishes itself from sibling tools like individual planet or house tools by mentioning the full chart calculation.

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

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

The description implies when to use: for full birth chart needs. It doesn't explicitly mention when not to use or point to alternatives, but given the sibling list, it's clear this is the comprehensive chart tool while others are focused (e.g., post_astrology_houses for houses only).

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial non-obvious behavior: the Moon is deliberately excluded, declinations are geocentric, exact date/time of closest approach is returned in the requested timezone, and omitting year/month returns the current month so calendars stay current. There is no contradiction between the description and 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 key scope is front-loaded and the first sentence is excellent, but the description is long and includes astrological background and a closing keyword string ('Monthly parallel calendar API, declination aspects, contraparallel ephemeris') that add little for an agent selecting or invoking the tool. Most sentences earn their place, but a few could be trimmed.

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 7-parameter tool with no required parameters and an output schema, the description covers the body set, the meaning of parallels and contraparallels, timezone behavior, the current-month shortcut, and why the Moon is excluded. The output schema handles return-shape details, so nothing critical is missing for correct selection and invocation.

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

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

Input schema coverage is 100%, so parameters like orb, lang, year, month, compact, nodeType, and timezone are already well documented. The description adds only small contextual notes, such as timezone-aware return times and the omit-year/month behavior, which is appropriate but does not need to restate 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 opens with a specific verb and resource: 'Get every parallel and contraparallel of declination that perfects during a given month,' and enumerates exactly which 13 bodies are included. It also distinguishes the tool from sibling aspect tools by explaining that declination contacts are independent of zodiacal distance and surface connections aspect tables cannot show.

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

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

The description gives concrete use cases ('declination work, out-of-bounds tracking, monthly forecast copy, and electional timing') and positions the tool relative to aspect reading ('read them alongside aspects'). It does not explicitly name an alternative sibling or state when not to use this tool, so it stops short of full routing guidance.

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

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

Annotations already mark this as read-only and non-destructive, so the description's burden is lower. It adds useful behavioral context by clarifying that the result is a full tropical zodiac chart with all planetary positions, house cusps, and aspects. There is no contradiction with annotations.

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

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

The main body is reasonably ordered: definition, context, output scope. However, the final sentence 'Planetary return chart API, Saturn return calculator, Jupiter return chart, Mars return forecast.' is keyword stuffing with no informational value for an agent, 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?

For a 10-parameter tool with a rich schema and an output schema, the description provides the essential conceptual framing: what a planetary return is, which planets are supported, and what the resulting chart contains. Combined with the schema, an agent has enough context to invoke it correctly, though the description itself adds little operational detail.

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

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

Schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly. The description repeats the planet cycle lengths that already appear in the planet parameter's description but contributes no new parameter semantics, such as how approximateDate or timezone affect the calculation.

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

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

The description opens with a specific verb and resource: 'Generate a planetary return chart' for the five named planets, and explains the astronomical definition ('transiting planet conjuncts its natal longitude'). This clearly distinguishes it from lunar/solar return siblings. It also states the output scope (planetary positions, house cusps, aspects), so an agent can tell what the tool does at a glance.

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 supported planets and gives contextual details about Saturn/Jupiter/Mars return significance, so an agent can infer when this tool is appropriate. However, it never explicitly states when not to use it or points to alternatives like post_astrology_lunar_return or post_astrology_solar_return. Usage guidance remains implied rather than 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the return fields (longitude, latitude, zodiac sign, degree within sign, daily motion speed, retrograde status) and the 'tropical' zodiac convention, plus a verification claim against NASA JPL Horizons that helps the agent trust accuracy.

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

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

Four sentences, each earning its place: the core calculation, the body list, the return fields, and the use cases/verification. The most important information is front-loaded, with no redundant phrasing.

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

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

Given the tool's moderate complexity (8 parameters, output schema present) and the rich annotations, the description is complete: it covers what is calculated, for which bodies, what is returned, intended use cases, and accuracy verification. Nothing an agent needs to decide whether to invoke it is missing.

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

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

Schema description coverage is 100%, so the schema fully documents every parameter. The description adds no parameter-level meaning beyond what the schema already provides, which matches the baseline of 3 for high-coverage schemas.

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

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

The description uses a specific verb ('Calculate') and resource ('tropical zodiac positions for all 14 celestial bodies'), enumerating exactly which bodies are included. This clearly distinguishes it from sibling tools like aspects, houses, or monthly planetary positions. An agent can immediately tell what this tool does and what it does not do.

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

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

The description states clear use cases ('transit tracking, ephemeris tables, astrology apps, and planetary position widgets') and implies general applicability to any date/time/location. However, it does not explicitly mention when not to use it or contrast it with sibling tools like post_astrology_planets_monthly, so it doesn't earn a 5.

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

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

Annotations already mark it read-only and non-destructive; the description adds meaningful behavioral context beyond that: calculations are 'at noon UTC', omitting year/month returns the current month so a published page stays current without redeploy, and data is 'Verified against NASA JPL Horizons.' No contradiction with annotations.

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

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

The first two sentences front-load the core operation and return fields, with defaults and use cases following. The trailing keyword list ('Monthly ephemeris API, tropical position table...') is somewhat redundant with the opening sentence, 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?

For a read-only endpoint with zero required parameters, rich schema descriptions, and an output schema, the description covers body set, coordinate system, time zone, defaults, output fields, and use cases. Nothing essential for selecting or invoking it is missing.

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

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

Schema description coverage is 100%, so the schema carries most parameter meaning. The description adds a useful semantic by framing omitted year/month as an intentional way to get the month in progress, which goes slightly beyond the schema's simple default statements.

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 action ('Get'), a precise resource ('daily tropical ecliptic positions for all 14 Western bodies'), and a clear scope ('an entire month'). It is easily distinguishable from aspect, transit, and moon-phase siblings by content, but it never explicitly names an alternative or says what it is not, so it stops short of a 5.

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

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

Provides clear intended use: 'Essential for ephemeris tables, transit tracking, retrograde calendars, and planetary movement charts.' It does not, however, contrast with near-neighbor tools like post_astrology_aspects_monthly or post_astrology_planets, nor give when-not-to-use guidance, so it is not a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description rightly avoids repeating that. It adds useful behavioral context: it explains the whole-sign progression logic, what the output includes (age, profected house/sign, lord's natal placement, interpretation), and that it is a read-only calculation. It does not mention edge cases or output shape, but with annotations covering safety, this is adequate.

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

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

Two sentences, zero fluff. The first sentence states the purpose and technique; the second explains the mechanism and outputs. It is front-loaded and every clause earns its place. This is an exemplary concise structure.

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

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

Given the complexity (10 params, 6 required), the schema fully documents all inputs, and the output schema exists, the description is complete for calling the tool correctly. It explains the core algorithm and the return elements. It could mention that the result is a read-only calculation, but annotations cover that. No critical information for 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?

Schema description coverage is 100%, so each of the 10 parameters is already thoroughly documented in the schema (e.g., timezone IANA handling, nodeType distinction, houseSystem nuance). The description itself does not add parameter-specific meaning beyond referring to 'birth chart and target date'. Per the baseline, a 3 is appropriate when the schema carries the full semantic load.

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

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

The description opens with a specific verb and resource: 'Calculate the annual profection and lord of the year for any birth chart and target date using the Hellenistic time lord technique.' It clearly distinguishes this from siblings like progressions or transits by naming the technique and the output (profected house, sign, lord of the year). The mechanism (advancing rising sign per completed year) is also explained, leaving no ambiguity about what the tool does.

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

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

The description does not explicitly state when to use this tool versus the many sibling tools (e.g., post_astrology_progressions, post_astrology_solar_return). It implies its niche by describing annual profections, but offers no 'use this when...' or 'for other techniques use...' guidance. An agent must infer the use case from the name and description alone.

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

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

Annotations already mark the operation as read-only and non-destructive. The description adds useful behavioral context: it explains the day-for-a-year calculation, the returned fields (sign, degree, whole-sign house, motion, retrograde state), and the Naibod arc for progressed angles. No contradiction with annotations.

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

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

Four substantive sentences plus a trailing keyword list. The body is front-loaded and clear, but the final comma-separated keywords ('Secondary progressions API, progressed chart calculator...') are redundant with the title and add noise.

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 rich input schema (all 9 params documented), output schema, and safety annotations, the description is largely complete for invocation. It explains the calculation method and return contents, though it could be stronger on when to select this tool among 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%, so the baseline applies. The description does not add new parameter-level meaning; it restates the day-for-a-year concept already present in the targetDate schema. No parameter is left undocumented, but the description contributes little 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 opens with a specific verb ('Generate'), names the exact resource ('secondary progressed chart'), and explains the calculation key ('day-for-a-year'). It distinguishes itself from sibling astrology chart tools by focusing on secondary progressions and listing distinctive outputs such as progressed Ascendant/Midheaven via the Naibod arc.

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

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

No explicit guidance is given about when to choose secondary progressions over sibling tools such as transits, solar arc, or returns. The intended use is only implied by the tool name and first sentence; no exclusions or alternative conditions 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 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. The description adds valuable behavioral context: the computation method (solar arc formula), the tropical coordinate basis, and the promise of a plain-language interpretation. It also clarifies the level of user expertise required ('no astronomy expertise needed'). These go beyond the structured metadata.

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 with no filler. The first sentence immediately states the action and inputs; the second explains the methodology concisely; the third states the outputs and use case. Every sentence earns its place, and the most critical information (what the tool does) is front-loaded.

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

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

Given the tool's complexity (9 parameters, output schema present, annotations cover safety), the description is nearly complete. It explains the purpose, method, outputs, and intended use case. An output schema exists, so detailed return-value documentation is unnecessary. Minor gaps like house system or handling of unknown birth time are already addressed in the schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema; it only refers to 'birth moment' and 'target date' generically. The schema already fully documents each parameter including formats, defaults, and enumerations, so the description does not need to compensate.

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 for any birth moment and target date.' It clearly distinguishes the tool from siblings by explicitly naming the solar arc technique and explaining its formula (secondary-progressed Sun minus natal Sun). The scope (directed chart with Ascendant and Midheaven) is unambiguous.

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

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

Provides clear usage context: 'for predictive astrology apps timing major life events.' It conveys the intended application without explicitly naming alternatives. Since the schema and title already differentiate it from progressions, transits, and other chart tools, the lack of explicit exclusions is acceptable.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the chart is cast for the exact Sun-return moment, returns a full chart, and relocating changes houses and Ascendant. It does not mention rate limits or errors, but these are less critical for a read-only computation with an output 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 first two sentences are informative and front-loaded, but the final keyword list ('Solar return chart API, annual horoscope forecast, birthday chart calculator, yearly astrology prediction, relocated solar return') is redundant SEO-style filler that repeats the title rather than adding new guidance. Trimming that list would make the description tighter without losing information.

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

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

For a 9-parameter tool with a full output schema and read-only annotations, the description covers the essential context: what the chart is, when it is cast, what it returns, and its location sensitivity. Less obvious fields like lang, compact, and houseSystem are adequately handled by the input schema, so nothing required to invoke it correctly is missing.

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

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

The input schema documents all 9 parameters with 100% coverage, so the baseline is 3. The prose adds meaning beyond the field descriptions by explaining the natal-Sun-return calculation, which ties birthDate, birthTime, and returnYear together, and by emphasizing that latitude/longitude determine the Ascendant and houses. This gives an agent a mental model for choosing location parameters.

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

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

The first sentence names a specific verb and resource ('Generate a solar return chart for any year') and the description enumerates the returned content (planetary positions, house cusps, aspects, Ascendant, Midheaven). This clearly distinguishes it from natal, transit, and lunar return tools, even without naming a sibling.

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

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

The description implies usage for annual forecasting ('foundational technique for annual astrological forecasting') and notes location sensitivity, but it never explicitly states when to prefer this over lunar_return, planetary_returns, or transits, nor when not to use it. With 40+ sibling astrology tools, explicit routing would materially help 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, covering the safety profile. The description adds the output shape (compatibility score, inter-aspects with strength ratings, aspect counts, dynamics analysis) and the astrological tradition (Western tropical). It does not disclose edge-case behaviors like fallback for unknown birth times, but the schema addresses that. No contradiction with annotations.

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

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

The description is four sentences and front-loads the core purpose and method. The use-case sentence earns its place as context, but the closing claim "Based on professional astrological techniques" is filler and adds no functional value.

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

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

Given the output schema, annotations, and detailed nested parameter descriptions, the definition is functional. The main gap is the lack of guidance for choosing between this and the closely related compatibility/composite tools, which matters in a large sibling set of astrology endpoints.

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?

Top-level person1 and person2 lack schema descriptions, resulting in 60% coverage; the description's phrase "between two natal charts" helps map those two undocumented parameters to the required inputs. The other parameters (lang, compact, houseSystem) and all nested fields already have detailed schema descriptions, so the description only partially compensates for the coverage gap.

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 ("Calculate"), a concrete resource ("synastry between two natal charts"), and a precise scope ("inter-chart aspects between all planets"). It clearly describes what the tool does, but it does not explicitly distinguish itself from the close sibling post_astrology_compatibility_score, which also handles relationship compatibility.

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

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

The description provides implied usage context via concrete use cases ("dating apps, matrimonial sites, relationship counseling tools, and astrology compatibility features"). However, it never names alternatives or states when to prefer this over sibling tools like post_astrology_compatibility_score or post_astrology_composite_chart, so an agent has limited routing guidance.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false. The description adds useful operational context: it compares current or future positions against the natal chart, returns timing/applying-separating status, and supports filtering. There is no contradiction with the annotations, and no side-effect warning is needed for a read-only tool.

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

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

The first three sentences are dense and informative, and the comparison to /transits earns its place. The final comma-separated keyword list ('Transit aspects API, transit-to-natal analysis, predictive astrology, personalized transit forecast') is redundant and adds noise, preventing a 5.

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

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

For a 9-parameter tool with a nested object, full schema coverage, an output schema, and safety annotations, the description provides the strategic context an agent needs: detailed interpretations, strength ratings, filtering, and how it differs from /transits. It does not mention defaulting behavior, but the schema already covers that.

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

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

Schema coverage is 100%, and every parameter has a detailed description. The tool description adds only the high-level note that planet and aspect-type filtering are supported, which is helpful but does not extend the schema's per-parameter meaning. A baseline of 3 is appropriate when the schema carries the parameter documentation burden.

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

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

The description opens with a specific verb ('Calculate') and resource ('all transit-to-natal aspects') and enumerates concrete outputs: aspect type, orb, applying/separating status, narrative interpretation, impact rating, and practical guidance. It also explicitly contrasts itself with the /transits endpoint, so an agent can distinguish it from its nearest sibling without inspecting the schema.

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

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

The description names /transits as the less detailed alternative and gives the reason to prefer this tool: 'adding AI-friendly interpretation fields.' It does not spell out exclusions for sibling tools like post_astrology_transits_monthly or post_astrology_aspects, but the comparative wording provides clear context for the main routing decision.

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 readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context: it returns all 14 celestial bodies with signs, degrees, and speeds, and when a natal chart is supplied it includes aspect orbs and applying/separating status. This goes beyond the annotations without contradicting them.

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

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

Four sentences front-load the verb and scope, then move from output details to the optional mode to use cases. There is no filler, no repetition of schema content, 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?

The tool has a rich output schema and a fully documented parameter schema, and the description adds the missing high-level output summary and use-case context. All 7 parameters and both enum options are documented in the schema, so the only minor gap is explicit sibling 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?

The input schema covers 100% of parameters with detailed descriptions, so the baseline is 3. The description reinforces the optional natalChart use case and 'future transits' semantics but does not add syntax-level detail 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 uses a specific verb ('Calculate'), names the resource ('current or future planetary transits'), and clarifies the optional natal-chart comparison. This distinguishes it from transit-related sibling tools like post_astrology_transits_monthly and post_astrology_transit_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?

It clearly states the intended use cases ('daily transit forecasts, aspect alerts, and personalized transit reports') and when natal data should be provided. It does not explicitly name sibling alternatives or exclusion conditions, so it falls just short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds substantial behavioral detail: it specifies the output (starting sign on first of month, each ingress with exact date/time in the user's timezone), the default window behavior when year/month are omitted, and verification against NASA JPL Horizons with cross-checks. This goes well beyond what annotations provide.

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

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

The description is moderately long but well-structured: it front-loads the core purpose, then details the return format and default behavior, then use cases, and ends with verification. The only redundancy is the trailing keyword-like phrase ('Monthly transit API, planetary ingress calendar, sign change dates, tropical transit table.') which adds little value. Overall, it earns its length.

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

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

The tool has 6 optional parameters and an output schema, so the description doesn't need to explain return values. It covers what the tool returns, defaults, timezone handling, and accuracy. It doesn't mention edge cases like DST or timezone resolution details, but those are covered in the schema. For a read-only data-retrieval tool, this is nearly 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 each parameter already has a detailed description. The tool description adds marginal value by noting the 'omit year and month' behavior, but this is already implied by the schema defaults. It does not introduce syntax or formatting details beyond what the schema documents, 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.