Astraluno

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

Annotations already declare a safe read-only, idempotent profile, but the description adds valuable context beyond them: no birth data storage or logging (including request bodies, logs, stats, errors), language fallback behavior for unsupported codes, and the concrete behavior change when the time is unknown (no Ascendant/houses, multiple Moon signs).

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 is front-loaded in the opening clause, and the dense paragraph packs trigger phrases, constraints, edge-case behavior, and privacy into a few sentences. It is long and clause-heavy, but nearly every clause adds operational value rather than repetition.

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 an 11-parameter tool with an output schema, the description supplies the missing behavioral context an agent needs: input fallback rules, unknown-time handling, window semantics, and a privacy guarantee. Return-value details are correctly omitted since the output schema covers them.

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 only 9%, so the description carries real weight, and it does explain the trickiest parameters: the ±15/30/60/120 window, fold/ambiguity choice, historic offset override, and the unknown-precision semantics. It leaves lang, timezone, latitude/longitude, place_id, birth_date, and birth_time format unaddressed, so coverage is strong but incomplete.

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 complete natal chart') and enumerates the outputs (planets, Ascendant, Whole Sign houses, major aspects, uncertainty). It also lists multilingual trigger phrases and clearly occupies the comprehensive-chart slot, distinguishing it from narrower siblings like get_big_three or get_planet_positions.

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

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

Gives explicit operational guidance: ask for missing birth time and birthplace rather than guessing, and use time_precision=unknown when the time is unknown with defined consequences. It does not, however, explicitly route between this tool and the other chart-related siblings, so the when-not-this-tool 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 readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses result uncertainty, the degraded-output mode for unknown birth times, and a privacy guarantee covering request bodies, queries, access logs, stats and errors. This is operational context an agent cannot get from 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?

Front-loads purpose, then usage, then edge cases and privacy. The multilingual keyword list is a little listy but earns its place for matching user phrasing; otherwise the sentences are dense and purposeful.

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

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

An output schema exists, so return values need not be explained, and the description notes uncertainty, one-line meanings and links anyway. The main shortfall is undocumented geographic/time parameters against a 9% coverage schema, which an agent must infer.

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 only 9% with 11 parameters, so the description must carry the load. It covers lang fallback, time_precision='unknown' behavior and missing birth_time, but says nothing about latitude/longitude vs place_id, timezone, ambiguity, approx_window_minutes, or utc_offset_override_sec. Partial compensation, significant remaining gaps.

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 Sun sign, Moon sign and rising sign together') and immediately routes the user's phrasing to it. Clear distinction from siblings like get_sun_sign and calculate_birth_chart, which cover narrower or broader scopes.

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?

Explicitly names trigger utterances in two languages and, crucially, gives a decision rule for incomplete input: ask for missing birth time/birthplace instead of guessing, and fall back to 'unknown' semantics (no Ascendant/houses, both Moon signs) when time is unavailable. That is when-to-use plus edge-case handling.

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 readOnly/idempotent/non-destructive and closed-world, but the description adds real value beyond them: the [from,to) UTC range semantics, the 400-day maximum, the fact that output is in local times with signs and uncertainty, and an explicit no-store/no-log privacy guarantee.

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

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

Front-loaded with purpose and examples, then operational constraints, then privacy. The multilingual example strings add some bulk but usefully signal non-English intent; overall dense but each sentence serves a purpose.

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-value explanation is unnecessary, and the description focuses on the operational constraints (range, timezone, max span) that the schema does not express. Coverage is strong; the notable omission is explicit guidance on the optional lang parameter's fallback behavior beyond its schema note.

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?

With only 25% schema description coverage, the description carries meaningful load: it names from_date, to_date and an IANA timezone, and adds constraints the schema lacks (inclusive/exclusive range semantics, 400-day cap, UTC boundary interpretation). Only 'lang' semantics go undocumented in the description, relying on its schema note.

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

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

States a specific verb ('Calculate') and resource (new/first quarter/full/last quarter Moon), and backs it with concrete example queries. An agent can distinguish this from all astrology siblings (birth charts, transits, signs) without opening the schema.

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

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

The example queries ('when is the next full Moon', Italian equivalents) clearly frame the intended use case. It does not, however, explicitly name when to prefer it over a sibling or state exclusions, 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 read-only/idempotent/non-destructive/closed-world, yet the description adds material the annotations cannot convey: the interpretation is symbolic and not a scientific prediction, and no birth data is stored or logged including request bodies, queries, access logs, stats and errors. The language fallback behavior completes the picture.

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

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

Front-loaded with the core verb and illustrative examples, then constraints, then the privacy note. Dense and largely waste-free, though the example list and trailing privacy sentence make it a long single block rather than cleanly segmented guidance.

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

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

An output schema exists, so return values need no explanation; the description instead covers the items an agent genuinely needs — input id conventions, one-sign-or-one-house constraint, symbolic framing, and data-handling posture. Only the mutual-exclusion behavior when both sign and house are supplied is left unspecified.

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?

With only 25% schema description coverage the description must carry weight, and it does: it specifies that body_or_angle and sign require canonical English ids (so callers must not pass 'Venus' or 'Venere'), and it adds the sign-vs-house exclusivity rule that the schema itself does not express. It does not explain the house/body interaction in the no-sign case beyond a phrase.

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

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

States a specific verb+resource ('Read the free corpus meaning of a placement') and backs it with six concrete input examples spanning both languages and all three lookup shapes. The role is clearly distinguishable from sibling calculation tools like calculate_birth_chart or get_planet_positions, which return astronomical data rather than interpretation.

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

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

Gives concrete operating context: 'One sign or one house per call; no sign/house returns the body meaning,' which tells the agent how to shape the call and what the degenerate case does. It does not name alternatives or say when a caller should prefer this over a computation sibling, so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description earns credit for adding the return payload (tropical geocentric positions, retrograde flags, Moon phase/illumination) and defaults (now, UTC). The no-logging/no-storage statement adds a privacy guarantee, though it is slightly odd since the tool accepts no birth data at all.

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

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

Front-loaded with the core purpose, then returns, then defaults, then the privacy note — a logical order with little waste. The multilingual example list is somewhat bulky for the value it adds.

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

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

With an output schema present, return fields need not be enumerated, and annotations cover safety. The description additionally supplies defaults and a data-handling guarantee, leaving only edge cases (invalid datetime, large-range behavior) unaddressed.

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

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

Schema coverage is only 33% (only lang is documented), so the description must compensate. "Defaults to now and UTC" does cover the datetime and timezone defaults, but it adds nothing about accepted ISO-8601 format nuances, timezone identifiers, or why lang matters, leaving two of three parameters thinly specified.

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 (compute) and resource (current sky / planet positions at an ISO instant), plus concrete example queries in two languages. However, it never distinguishes itself from the overlapping sibling get_moon_phases, which it partly duplicates by returning Moon phase/illumination.

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?

"Compute the current sky or a specified ISO instant" plus the natural-language examples ("where is Venus today", "cielo di oggi") make the intended context clear and imply it defaults to now. No exclusions or named alternatives (e.g. "for a full natal chart use calculate_birth_chart") are given.

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

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

Annotations already declare it as a safe, read-only, idempotent operation. The description adds valuable domain context: that station estimates aren't exact-to-the-second, and that it includes shadows and uncertainty windows. It also mentions privacy/data-handling, which is extra. It doesn't contradict annotations.

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

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

The description mixes useful scoping with a privacy notice and a caveat about precision. The privacy sentence feels tangential and could be omitted or moved. Front-loaded with the core purpose but somewhat cluttered.

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 output schema exists, the description doesn't need to explain return values. It covers scope, limitations (station accuracy), and includes examples. Missing explicit guidance on the 'lang' parameter, but overall complete for a simple lookup 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 only 33%; the description names 'planet' and 'year' and gives a range for planets, but doesn't explain the 'lang' parameter or its fallback behavior (though the schema does describe lang). Baseline 3 is appropriate as schema handles some but not all, and description adds marginal detail on planet scope.

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

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

Clear verb+resource+scope: 'Find retrograde periods by planet and year', with concrete example queries and the planet/date range (Mercury through Pluto, 1900–2099). This is distinguishable from sibling tools like get_planet_positions or get_sign_ingresses.

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 natural-language example queries that imply when to use it, and the scope (planet, year, 1900–2099) clarifies coverage. However, it doesn't explicitly state when to use siblings instead (e.g., get_planet_positions for daily positions), so it stops short of full alternative routing.

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

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds real value on top: it discloses that retrograde re-entries and uncertainty windows appear in results, that the interval is UTC half-open with a 400-day cap, and that no birth data is stored or logged. It lacks detail on output shape, but the output schema covers that.

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

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

Front-loaded with purpose and query examples, then constraints, then the privacy statement. The multi-language examples are slightly repetitive but earn their place by illustrating natural-language query patterns; no filler sentences.

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

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

With an output schema present, return values need not be explained, and the description covers the key behavioral facts (retrograde re-entries, uncertainty windows, date bounds, privacy). Missing only guidance on planet selection breadth relative to sibling tools, 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 description coverage is only 25%, so the description must compensate. It adds meaning for the date parameters ('[from,to) UTC, max 400 days') but says nothing about planet enum values or the lang fallback that the schema only partially documents. Partial compensation warrants a mid score.

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

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

States a specific verb (find) and resource (when a planet enters a zodiac sign), reinforced by three concrete example queries across languages. The event-based framing ('when does Venus enter Leo') clearly separates it from sibling planetary-position and retrograde-period tools.

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

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

Usage context is implied through examples and the 'max 400 days' date-window constraint, plus a note that retrograde re-entries are included. However, it never states when to prefer this over get_retrograde_periods or get_planet_positions, leaving alternative selection to inference.

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

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds substantive traits beyond them: cusp handling with ingress plus uncertainty, a no-guessing guarantee, the fallback of considering all local-day conversions when no timezone is given, and an explicit privacy statement that no birth data is stored or logged.

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

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

Front-loaded with purpose, then edge-case and privacy notes in tight clauses with no filler. The quoted multilingual trigger phrases add length but earn their place for matching user utterances.

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

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

An output schema exists so return values need no explanation, and the description covers the domain-specific risks (cusp ambiguity, timezone absence, privacy) that an agent would otherwise have to guess at.

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?

With only 25% schema description coverage the description must carry weight, and it does explain the trickiest parameter (timezone optionality and its all-local-day fallback) and how birth_time changes behavior. It says nothing about the lang fallback parameter, leaving one 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?

States a specific verb (find) and resource (Sun zodiac sign) plus the exact input that drives it (birth date), and lists natural-language triggers in EN/IT. An agent can distinguish this single-sign lookup from siblings like get_big_three or calculate_birth_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?

Gives clear usage conditions: use for 'what is my zodiac sign' style queries, cusp dates are resolved with ingress/uncertainty rather than guessed, and when a time is supplied the caller should ask for a timezone. It does not explicitly name a competing sibling to route away from, so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds valuable privacy context (no birth data stored or logged, including request bodies, queries, access logs, stats and errors) which is not captured by annotations. It doesn't explain output structure, but an output schema exists to carry that.

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

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

Three sentences, front-loaded with the core purpose, then disambiguation rule, then privacy note. Efficient overall, though the privacy clause is long and slightly dense for a single sentence.

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 needn't be detailed. The description covers purpose, disambiguation behavior, and privacy guarantees; it's complete enough for an agent to invoke correctly, though it could say more about what happens on no-match or the lang fallback note.

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 50%: lang is documented in the schema (with fallback behavior), but query has no description. The description doesn't add syntax or format details for query beyond the example phrases, so baseline 3 applies—the schema does most of the work.

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 (Find) and resource (disambiguated birthplace candidates and GeoNames ids), plus example queries in multiple languages. It's clearly distinguishable from sibling tools like get_big_three or calculate_birth_chart, which deal with chart/astrological data rather than place lookup.

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?

Explicit when-to-use guidance: 'Ask the user to choose when more than one plausible match exists; never guess.' This directly tells the agent how to behave on ambiguous results, which is the key decision point for this tool.

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