Stellara

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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description still adds non-obvious behavioral facts: 'No predictions, nothing stored', that birth time/place are optional, and that the celebrity path returns a score and share text.

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

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

Three tight sentences, front-loaded with what the tool produces before covering the optional-input caveats and the celebrity mode. Dense but no filler; the mode-switching detail is worth its space.

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

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

For a nested two-person input with no output schema, the description covers both invocation modes, optionality of birth time/place, and roughly what comes back (aspects, orbs, summary, score/share text). Minor gap: it does not describe response shape for the non-celebrity path in 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 every field, its format and the latitude/longitude vs birth_place trade-off. The description only adds the person_b-vs-celebrity substitution rule, which is a modest increment over the schema's own wording.

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 ('Compares two birth charts (synastry)') and immediately names the concrete output: closest aspects between A's and B's planets with orbs and a summary. It is clearly distinguishable from siblings like get_birth_chart (single chart) and get_transits.

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

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

Explains the two operating modes and the condition that selects each: pass person_b normally, or use `celebrity` instead for a playful match, with a pointer to list_celebrities. It also flags which inputs are optional, but does not explicitly state when to prefer this over get_birth_chart for a single person.

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

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

With readOnlyHint, openWorldHint=false and idempotentHint already declared, the description adds genuinely useful context: the card is written in the third person, framed as character not prediction, and no personal data is stored. That last claim corroborates the readOnly/idempotent profile. It stops short of describing output structure or any rate/size constraints, but with output schema present that is minor.

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

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

Front-loads the verb and resource, then packs content, tone and privacy into two short follow-up sentences. Slightly dense and the tone phrasing repeats the 'third person' idea, but 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?

Output schema exists, so return values need not be described, and annotations carry the safety profile. The description supplies the remaining information an agent needs: what the card contains, its tone, and that no data is persisted.

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

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

Schema coverage is 100%, so the schema already documents birth_date, recipient_name and language, including format and enum. The description reinforces the name-handling semantics (third person, by name or neutrally without one) but adds no syntax or format detail beyond the schema, so the baseline 3 applies. It says nothing about the language parameter, leaving that entirely to the schema.

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

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

States a specific verb and resource ('Creates a festive Christmas card') and enumerates the content it produces (text plus SVG image, sun sign, life path number). However, it never differentiates from astrology siblings like get_sun_sign_reading or get_birth_chart, so an agent must infer that this is the card-generation variant rather than a reading endpoint.

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

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

The description implies the use case (producing a festive card from a birth date) but offers no explicit when-to-use, when-not-to-use, or named alternative among the siblings. An agent can infer intent from the name and content summary, but routing 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 read-only, idempotent, non-open-world behavior, and the description adds real substance on top: 'No predictions, nothing stored', the approximation caveat for a missing birth time, and the conditional inclusion of houses/angles. These are exactly the behavioral facts an agent cannot infer from annotations or 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?

Four dense sentences, front-loaded with what is computed and what is returned, followed by the conditional rules and the safety caveat. No filler sentences and nothing repeated from the schema.

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

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

With no output schema, the description correctly carries the burden of describing the return contents (planets, aspects, interpretation, optional angles/houses) and the accuracy caveat. It is nearly complete, but says nothing about behavior when a birth_place cannot be resolved or matched ambiguously, which matters for a tool whose fallback path is latitude/longitude/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 the baseline is 3; the description earns above baseline by documenting the parameter interaction that governs output — birth_time plus birth_place are jointly required for Ascendant, Midheaven and houses, and time alone leaves the Moon approximate. It does not add format/syntax detail beyond the schema's examples, so it stops short of 5.

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 ('Computes a real birth chart from astronomical positions (tropical zodiac)') and enumerates the actual deliverables (Sun–Pluto with sign/degree/retrograde, major aspects with orbs, short interpretation). This clearly separates it from siblings like get_sun_sign_reading (single-sign reading) and get_transits (time-based transits) without opening either schema.

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

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

Gives explicit conditional context: Ascendant/Midheaven/Whole Sign houses appear only 'when birth time and place are both given', and without a time 'the Moon is flagged as approximate'. That is strong when-to-expect guidance, but it never names an alternative sibling (e.g. compare_charts for two people) or states when not to use this tool.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description's added value is the 'free', 'no predictions', and 'no personal data stored' disclosure plus the deterministic date-table method. That meaningfully extends beyond the annotations, though it does not spell out caching or output delivery 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?

Two tightly packed sentences with zero filler; the scope and content of the return are front-loaded, and the privacy/scope limits follow immediately.

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

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

An output schema exists, so return values need no explanation, and the description adequately scopes inputs and limits for this simple read tool. Only the routing versus sibling tools remains unaddressed, which is a minor 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 both parameters (birth_date, language) are already fully documented including format and default. The description only restates that a birth date is the sole input and that time/place are unnecessary, which is already in the schema text, so it adds little beyond the baseline.

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

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

States a specific verb (Returns) and resource (short, free reading), and enumerates exactly what it contains: sun sign from a date table plus a Pythagorean life path number with character text. The 'based only on a birth date' framing implicitly separates it from the heavier get_birth_chart sibling, but no sibling is named explicitly.

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

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

The description makes the use case inferable (a lightweight, no-birth-time reading) and rules out prediction use, but it never says when to pick this over get_birth_chart, compare_charts, or get_transits. Usage is implied rather than directed.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false, idempotentHint=false), so the bar is lower. The description still adds real context the annotations do not: 'nothing stored' discloses persistence behavior and 'no predictions' scopes the interpretive output as reflective rather than predictive, which sets an agent's expectation for the returned text.

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

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

Two sentences with no filler: the first front-loads what is computed and over what timeframe, the second front-loads the output character and side-effect guarantees. Nothing is repeated, and the densest information (positions, transits, orbs, dates) leads.

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

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

For a 9-parameter tool with no output schema, the description does describe the returned content (planet positions, transits with orbs and exact dates, short interpretation) and the two side-effect facts an agent most needs. It leaves the birth-location/timezone input paths entirely to the schema, but since coverage is 100% that is a minor gap rather than a missing piece.

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

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

Schema description coverage is 100% and every parameter (including latitude/longitude/timezone alternatives, birth_time, language) is already documented in the schema. The description only restates the date and period semantics, adding no syntax or precedence detail beyond the structured fields. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description names a specific verb-and-resource pair (shows planetary positions and the transits they make to a birth chart) plus the output content (orbs, exact dates) and the timeframe (one day or a 7-day week). It is clearly distinct from sibling tools like get_birth_chart (natal-only) and compare_charts (two charts) without needing to name them.

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

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

Usage context is explicit: 'now (or on a given UTC date)' and 'for one day or a 7-day week', which maps directly onto the date/period parameters. However, it never names an alternative tool or states when not to use this one (e.g. versus get_birth_chart for natal-only data), 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 cover the safety profile (readOnly, idempotent, closed-world), so the description's added value is the data provenance (most-followed people on X, birth dates from Wikidata cross-checked with Grokipedia), the 25-item cap, the most-followed-first ordering, and the date-only caveat. These are genuinely non-obvious traits that would otherwise surprise a caller.

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?

Purpose and integration point come first, then the parameter behavior and return characteristics. The trailing fragment 'Most are date-only.' is terse and slightly ambiguous, but overall the text is dense with information and nearly waste-free.

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

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

With no output schema, the description carries the burden of describing results and does so: count cap, ordering, and the date-precision caveat. Provenance and the compare_charts link round it out; only the exact returned fields are left implicit.

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

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

Schema coverage is 100% and the query param is already documented with an example. The description still adds meaning by enumerating accepted input kinds — name, handle, or description such as 'singer' — which the schema does not spell out, so it edges above 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?

States a specific verb and resource ('Lists the famous people') and immediately ties it to its consumer, compare_charts, which no sibling tool claims. An agent can distinguish it from get_birth_chart or compare_charts without opening a schema.

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

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

It establishes clear context — this is the lookup step feeding compare_charts — and explains the optional query. It does not state when not to use it or name an alternative discovery path, so it stops short of a full routing rule.

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