AstroWay Core astrology

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds that it returns a 'plain-text human-readable summary' and clarifies the budget-checking purpose, providing useful context 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?

Three efficient sentences: purpose, usage guidance, and return format. Front-loaded with key information, no wasted words.

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

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

Despite lacking an output schema, the description specifies the return format (plain-text human-readable summary). For a simple status check tool, this is complete and sufficient.

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?

Tool has zero parameters, so schema coverage is 100%. Description does not need to explain parameters, and it adds value by hinting at the output format.

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

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

Description clearly states the verb 'Check' and the resource 'API key status' with specific attributes (tier, credit balance, rate limits, monthly cycle reset). It distinguishes itself from the many sibling astrology calculation 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?

Explicitly instructs to run this tool BEFORE invoking expensive endpoints, providing credit thresholds (Tier 4+ at 100+ credits, Tier 6/7 at 500-5000 credits) to confirm budget.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds the useful guarantee that the emitted schema is the schema the endpoint validates and that the objects carry no vendor-specific fields, but says nothing about cost, rate limits, or response size behavior beyond what the schema states.

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 visible portion is front-loaded on what is returned and the two format shapes, with no filler. It is somewhat terse for a tool with six parameters and a listed default/select semantics, but every visible sentence carries information.

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

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

With an output schema present, the description need not explain return values, and annotations cover the read-only/idempotent profile. The remaining gap is routing: nothing tells the agent when to choose this over astroway_mcp_tools_list or similar listing tools.

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

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

Schema description coverage is 100%, so every one of the six parameters is already documented in the schema, including the format enum and the select/fields/precision semantics. The description restates the format option rather than adding new meaning, so the baseline 3 for full schema coverage 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 states a specific verb and resource: returning agent tool definitions generated from the live OpenAPI document, in either OpenAI or Anthropic shape. That is clear enough to differentiate it from report/chart tools in the namespace, but it never names the closest sibling (astroway_mcp_tools_list) or explains the distinction, so it falls 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?

There is no explicit when-to-use guidance and no stated alternative. The mention of `format=openai` as the default is parameter behavior, not a usage rule, and the agent is left to infer whether this is for building an agent, curated retrieval, or an MCP tool listing.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds the cost signal (20 credits, Tier 2), which is genuine behavioral context an agent would not get from the schema. However it discloses nothing about computational behavior, resolution, or precision beyond that.

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

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

Two compact sentences with the core concept front-loaded, followed by brief group and cost tags. Nothing is wasted, though the parenthetical definition and metadata lines make it slightly more list-like than prose would be.

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 annotations carry the safety profile. What is missing is usage context and any clarification of the 11 under-documented parameters for a tool that takes 15, leaving an agent able to understand the operation but not confident about invocation choices.

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 33% and the description adds no parameter meaning at all, so it does not compensate for the gap. Several parameters (cosmogram, zodiacType, houseSystem, ayanamsaId, name, city) are left undocumented in both places, and the reader must infer their roles from enum values alone.

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 a well-defined resource (antiscia and contra-antiscia), and even parenthetically glosses the concept as mirror points along the Cancer/Capricorn axis, plus their aspects to natal planets. This distinguishes it in substance from siblings like midpoints or arabic_parts, though it never names an alternative, so it falls 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?

The description offers no when-to-use, no when-not-to-use, and no alternatives among the many sibling aspect tools. The [Group] and [Cost] tags are metadata, not guidance about selecting this tool over midpoints, parallel_aspects, or fixed_stars.

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 behavior, so the safety profile is fully covered. The description adds the credit cost (20, Tier 2) and that a built-in lot set is used when none is supplied, which is useful but modest additional context; it says nothing about formula syntax or error behavior for invalid custom formulas.

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 front-loaded sentences plus compact group/cost metadata; nothing is padded. The metadata lines are useful but arguably belong in structured fields rather than the description body.

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 and annotations cover the safety profile, so the description need not explain return values. Stating what is returned (standard lots plus any custom formula) and the credit tier is sufficient for an agent to invoke this 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% and the schema itself richly documents body, timezone, houseSystem, fields and precision, so the schema carries parameter meaning. The description only implies that custom lots are optional via 'any custom formula', adding little beyond the schema's own 'built-in set is used when omitted' 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 and resource ('Calculate Arabic parts (Lots) from a natal chart') and lists outputs (Fortune, Spirit, custom formulas). It is clear on its own, but never distinguishes itself from the many sibling points/aspects tools such as astroway_aspects_midpoints or astroway_aspects_antiscia.

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 guidance on when to choose this over sibling tools or what prerequisites exist beyond the generic '[Group: Aspects & Points]' tag and cost line. The agent must infer usage purely from the name and one sentence.

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 as read-only, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds genuinely useful context (bars show orb duration with exact dates; cost of 10 credits, Tier 1), but omits return format and any parameter-level 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?

Three focused sentences with the output shape front-loaded, followed by compact group/cost metadata. No padding, though the cost/group tags add bookkeeping rather than task-relevant content.

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

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

The output schema exists so return values need not be explained, and the description does convey the produced artifact. But with 10 parameters at 20% coverage and a near-twin sibling, the description leaves meaningful gaps an agent needs to call it correctly.

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

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

Schema description coverage is only 20% (only 'fields' and 'precision' are documented), across 10 parameters including maxOrb, stepDays, planet1Ids/planet2Ids, aspectAngles, and visiblePlanetIds. The description explains none of these, so it does not compensate 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 gives a specific verb+resource+output: it 'transforms aspect timelines into Gantt-style bars grouped by transit planet,' so the agent knows exactly what is produced. However, it does not distinguish this from the obvious sibling astroway_aspects_aspect_timeline, which the phrase 'aspect timelines' nearly collides with.

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?

'Useful for visual transit calendars' implies a usage context but gives no explicit when-to-use, when-not, or alternative. With a near-duplicate sibling (astroway_aspects_aspect_timeline) available, the description should route the agent but does not.

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, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds that results include enter/exact/leave dates, which is useful behavioral context, but says nothing about precision loss, orb defaults, sampling step behavior, or the 100-credit cost implications beyond the tier label.

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?

One tight sentence with the core computation front-loaded, followed by the required group and cost metadata. Nothing is wasted, though the single sentence is arguably too sparse for a 9-parameter 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 complex 9-parameter tool with low schema coverage, the description is too thin: it omits how maxOrb, stepDays, aspectAngles and precision shape the returned timeline. The output schema covers return values, but the input side leaves an agent guessing at numeric ranges and defaults.

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 22% across 9 parameters, so the description carries much of the burden and fails to. maxOrb, stepDays, aspectAngles, precision and planet1Ids/planet2Ids are undocumented in both places; the description only vaguely references 'two specific planets' and a 'date range' without parameters actually named startDate/endDate.

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: calculating when two planets form an exact aspect over a date range. It is clear what the tool produces, but it does not differentiate itself from similarly named siblings such as astroway_calendar_aspects or astroway_aspects_aspect_bar, so an agent still has to infer which to pick.

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

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

The description explains what the tool computes but gives no when-to-use guidance, no exclusions, and does not name any alternative tool. The date-range and two-planet framing weakly implies usage but provides no routing information relative to the many other aspect 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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds the credit cost (Tier 2, 20 credits) and notes the response includes star details and aspect type, but says nothing about the missing orb control it advertises, nor about output volume or limits.

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

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

Two tight sentences with the core operation front-loaded, plus compact group and cost metadata. No filler, though the cost/group lines are boilerplate rather than definitional content.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. But with 15 inputs at 33% schema description coverage and no mention of the required birth-data parameters or sidereal/house options, an agent must reconstruct the calling contract almost entirely from 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 coverage is only 33% across 15 parameters, so the description carries more burden than it does. It mentions 'specified orb' even though no orb parameter exists in the schema, and it never explains the required date/time/latitude/longitude quartet, zodiacType, houseSystem, or the ayanamsa options.

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?

Specific verb+resource: 'Calculate conjunctions between natal planets and fixed stars within a specified orb,' which an agent can distinguish from the sibling astroway_aspects_fixed_stars_catalog (a star listing) without opening either schema. However, no sibling is named explicitly, so differentiation relies on inference.

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 when-to-use guidance, no prerequisites, and no alternatives named. 'Within a specified orb' hints at a narrowing input, but the description never says when this tool should be preferred over other aspect tools such as astroway_aspects_parallel_aspects or the fixed-star catalog.

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, idempotentHint and openWorldHint=false, so safety and determinism are covered. The description adds useful context (static, no chart, 36-star default flagged, magnitude trimming) but doesn't cover pagination or response shape, which the output schema carries.

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 compact sentences plus a group/cost tag; front-loaded with the key noun. The bracketed metadata lines are boilerplate but consistent with the tool family and mildly useful.

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 static reference lookup with an output schema, the description covers provenance, contents, the default flag, and a trimming filter. Nothing essential is missing; only the return-format note is left to the output 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 coverage is 100% and both parameters (fields, precision) are fully documented in the schema. The description mentions maxMagnitude, a query-string option, adding a little signal, but the structured fields do the heavy lifting. 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 resource (fixed star catalogue) and its exact provenance (Swiss Ephemeris fixstars.cat), naming the fields returned. It is clearly distinguishable from the related astroway_aspects_fixed_stars, which computes star contacts rather than listing names.

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?

"Static lookup, no chart needed" gives clear context for when to reach for it, and the maxMagnitude trimming note scopes a common use case. It does not explicitly route the agent to a sibling for the computed-star case, 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 readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds the credit cost (20 credits, Tier 2) and tool group, which is useful operational context, but says nothing about output shape, caching, or input sensitivity beyond that.

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

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

One sentence of substance, front-loaded with the verb and resource, followed by clearly separated group/cost metadata. No filler, though the very brevity is also the source of the missing guidance.

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

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

For a computation tool with 15 parameters and an output schema (so return values need not be explained), the description covers purpose and cost but omits input expectations and what distinguishes a 'power zone'. Adequate minimum but thin for the parameter surface.

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%, so the description would need to compensate, but it adds nothing about the 15 parameters. It never mentions that date/time/latitude/longitude are required, nor how ayanamsa/zodiacType or timezone affect Gauquelin sector results — a real gap since sector positions depend on exact time and location.

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 ('Gauquelin sector positions (1–36) for all planets'), and adds the interpretive output ('whether each planet is in a power zone'). No close sibling overlaps (no other Gauquelin tool in the list), so differentiation is moot, but the description does not explicitly say how it differs from general aspects/point 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?

There is no when-to-use guidance, no mention of when a Gauquelin-sector analysis is preferable to other aspect/point tools, and no note of prerequisites such as needing a birth time. The agent is left to infer context entirely.

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 full safety profile (readOnlyHint, idempotentHint, destructiveHint false, openWorldHint false), so the bar is lower. The description adds the cost/group metadata ('20 credits, Tier 2'), which is genuine behavioral context beyond the annotations, but says nothing about the response shape or limits.

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

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

Two short sentences front-load the core action, followed by compact group and cost tags. Nothing is padded or redundant, though the optional-aspects clause is doing little work.

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 15-parameter tool with only 33% schema coverage, the description omits any guidance on inputs or configuration even though an output schema covers return values. An agent has no help navigating the many optional parameters or distinguishing this from the midpoint_trees sibling.

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% across 15 parameters, so the description is expected to compensate and does not. It never mentions the required date/time/latitude/longitude inputs or the many configuration knobs (ayanamsa, houseSystem, zodiacType, precision), leaving half the schema undocumented anywhere.

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

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

The description states a specific verb and resource: 'Calculate all planetary midpoints and their zodiac positions,' plus an optional mode ('midpoint aspects to natal points'). It is clear on its own but never distinguishes itself from the near-identical sibling astroway_aspects_midpoint_trees, so an agent cannot tell which one to reach for from the text alone.

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 only usage signal is 'Optionally include midpoint aspects to natal points,' which describes an internal option rather than when to choose this tool over astroway_aspects_midpoint_trees or other aspects tools. No preconditions, exclusions, or alternative routing are given.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description usefully adds billing behavior (20 credits, Tier 2), which is real context not present in structured fields, but says nothing about output shape, computational cost, or failure modes beyond that.

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

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

A single tight sentence with the key noun phrase front-loaded, followed by two short metadata tags. Nothing is redundant, though the bracket tags are boilerplate shared across the tool family rather than tool-specific 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?

An output schema exists, so return values need no explanation, and the nested birth-data schema is exhaustively documented. What remains missing is the routing information an agent needs to pick this tool over the near-identical midpoint sibling, leaving the definition only minimally sufficient.

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 only 3 parameters, so the schema already carries the burden. The description mentions the orb and the focal-planet dimension, which maps loosely to the schema, but adds no format, default, or range detail beyond what is already documented.

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?

Names a specific verb (calculate) and a specific resource (Uranian midpoint trees / planetary pictures with symmetries), plus the scoping unit ('for each focal planet within a given orb'). It does not, however, distinguish itself from the sibling astroway_aspects_midpoints, which an agent could easily confuse it with.

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 when-to-use guidance, no prerequisites, and no reference to alternatives such as astroway_aspects_midpoints or astroway_aspects_antiscia. The only selection signal is the credit tier, which tells the agent about cost but not about appropriateness.

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, so safety is covered. The description adds only the credit cost (20 credits, Tier 2) and the orb-scoped planet scope; it says nothing about response shape, errors, or limits beyond that.

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

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

One front-loaded sentence stating the operation plus two compact metadata tags; no filler, no redundancy.

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 described, and the required birth data plus orb are covered by the schema. What remains thin is usage guidance, but nothing an agent needs to call the tool 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 the nested birth-data and orb fields fully documented, so the baseline is 3. The phrase 'within orb' loosely ties to body.orb but adds no format or default detail 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?

Names a specific verb (Calculate) and a precise resource (parallel and contra-parallel aspects by declination), and defines both terms, so an agent can distinguish it from ecliptic-aspect siblings like aspect_bar or midpoints. It does not explicitly name an alternative sibling, keeping it 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?

The scope (all planets, within orb) implies when the tool applies, but there is no explicit when-to-use/when-not guidance or routing to sibling aspect tools. Usage must be inferred from the astronomical term 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 readOnly, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds two useful operational facts beyond the annotations: the cost tier (10 credits, Tier 1) and that one symbol is produced per longitude. It says nothing about output content or limits, hence a middle score.

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?

One compact sentence front-loads the purpose, followed by short group and cost tags. Nothing is padded, though the bracketed metadata is boilerplate rather than explanatory content.

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

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

With an output schema present, return values need not be explained, and annotations cover the safety profile. For a simple per-longitude lookup the description plus structured fields give an agent enough to call it correctly; only usage context is thin.

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

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

Schema coverage is 67%; the required `longitudes` array has no schema description. The description compensates by specifying these are ecliptic longitudes and that a symbol is returned per element, which is the essential semantic for the undocumented parameter. It still omits units/range detail.

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: returns the Sabian symbol (Dane Rudhyar) for each supplied ecliptic longitude. The resource is unique enough among the astroway_aspects_* siblings that an agent can identify it, but no sibling is named or contrasted, so it falls 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives (e.g. other symbol/point lookups). The phrase 'for each given ecliptic longitude' only hints at the input shape, which is already visible in the schema.

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, idempotentHint, openWorldHint and destructiveHint, so the safety profile is fully covered by structured data. The description adds one genuinely useful behavioral fact beyond the annotations - the 10-credit (Tier 1) cost - but says nothing about return format, precision behavior, or limits.

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

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

The core sentence is front-loaded and wastes no words, and the bracketed group/cost metadata is compact. It is appropriately sized for a single-purpose lookup tool, though the metadata lines are formatting rather than prose.

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 annotations cover the safety profile. The remaining gaps are the undocumented 'longitude' parameter and the absence of any disambiguation from the very similar sibling tool, which matters given the crowded Calendar & Cycles namespace.

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 40%: 'fields' and 'precision' are documented in the schema, while 'startDate' and 'endDate' have no descriptions and 'longitude' is entirely opaque. The phrase 'within a date range' partially compensates for the two date parameters, but 'longitude' remains unexplained in both the schema and 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 description states a specific verb ('Find'), resource ('minimum brightness moment of Algol (Beta Persei), the eclipsing variable star') and scope ('within a date range'), so the operation is unambiguous. However, it does not distinguish itself from the near-identical sibling 'astroway_calendar_algol_minimum_nearest', which an agent could easily confuse with this tool.

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

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

The description gives no when-to-use guidance, no prerequisites, and no exclusions. Critically, it never routes the agent between this tool and the 'astroway_calendar_algol_minimum_nearest' sibling, leaving the choice entirely to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description usefully adds the 'single nearest ... before or after' semantics, but omits tie-breaking (if the date sits equidistant between two minima) and any auth/cost behavior beyond the credit tag.

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?

A single front-loaded sentence stating the core behavior, followed by compact Group and Cost tags. No padding or redundancy, though the metadata lines slightly dilute the one-line payload.

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 core lookup is stated. But for a 4-parameter tool with an unexplained 'longitude' input and no clarity on how 'nearest' resolves ties, the definition is only minimally 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?

With only 50% schema description coverage, the description carries real burden it does not meet: the 'longitude' parameter is entirely undocumented anywhere, and 'date' has only a pattern, not a stated meaning or timezone/format convention. The description adds nothing to clarify these 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 gives a specific verb (find) and a precise resource (the single nearest Algol brightness minimum relative to a date), which is clear on its own. It does not, however, differentiate itself from the sibling astroway_calendar_algol_minimum, so an agent must infer which of the two Algol tools to pick.

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

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

There is no explicit when-to-use guidance or mention of alternatives. The phrase 'before or after a given date' implies a proximity lookup, but nothing tells the agent when to prefer this over the plain Algol minimum tool or what input conditions apply.

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, so the bar is low, and the description still adds real behavioral context: the orb model used (per-pair astro.com matrix) and the cost (10 credits, Tier 1). It omits any auth or rate-limit notes, but the orb provenance is meaningful 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?

Two tightly written sentences that front-load the core purpose and then the differentiator, with group/cost metadata kept to bracketed tags. Nothing is padded, though the cost line is boilerplate rather than tool-specific 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 not be explained, and the description does cover what the tool produces. The gap is on the input side: for a 15-parameter tool with 33% schema coverage, the description leaves most parameter meaning and several sidereal/house-system choices undocumented.

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 15 parameters and only 33% schema description coverage, the description must compensate for the undocumented inputs, yet it names none of them (date, time, latitude, longitude, ayanamsa, houseSystem, zodiacType). The only field list it gives (type/exactAngle/orb/isApplying) describes the output, not the 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?

States a specific verb and resource (aspect calculation) and enumerates the returned aspect fields (type, exactAngle, orb, isApplying). It clearly distinguishes itself from the full chart endpoint, but does not differentiate itself from sibling aspect tools like astroway_aspects_aspect_bar or astroway_aspects_parallel_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?

The clause 'same calcAspects() as /chart but without planet positions / houses / midpoints overhead' implies you should use it when you only need aspects, which is a usable hint. However there is no explicit when-to-use vs when-not-to-use statement and no mention of the many sibling aspect tools an agent could pick instead.

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 full safety profile (read-only, idempotent, non-destructive, closed-world), so the description adds the cost tier (100 credits, Tier 4) and group, which is useful operational context. It does not disclose the computation basis for the outer planet pairs or any rate/side-effect nuance. Adequate but not rich.

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

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

A single front-loaded sentence stating the computation, its formula, and its purpose, followed by compact group/cost tags. No wasted prose, though the bracketed metadata adds little beyond what tooling may already expose.

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

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

The tool is a computation/analysis endpoint with an output schema and full annotations, both of which relieve the description of return-value and safety burden. However, the undocumented 'pairs' parameter and the missing contrast with sibling cycle tools leave meaningful gaps for correct invocation.

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

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

Schema coverage is only 40% and the description compensates minimally, implying only the startYear/endYear date range. The 'pairs' parameter has no description anywhere, and 'fields'/'precision' compact-mode behavior is left entirely to the schema. For 5 parameters, the description does not fill the documentation 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 gives a specific verb+resource: it computes the André Barbault Cyclic Index, defines it ("sum of all outer planet separations"), and scopes it to a date range. This is distinguishable from most siblings, though it does not explicitly contrast with close cousins like astroway_calendar_planetary_cycles or planetary_phases.

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

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

The phrase "to indicate global crisis periods" implies the analytical purpose and gives some context for use, but there is no explicit when-to-use/when-not guidance and no named alternative among the many calendar tools. Usage must be inferred.

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, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuine extra context — that results carry type, date, and geographic visibility data, and that the call costs 100 credits (Tier 4) — but says nothing about result volume, pagination, or whether the year/range inputs interact.

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 tight sentences with the capability stated first and the return contents second; the bracketed group/cost metadata is compact and skimmable. No filler, though the cost/group lines are boilerplate rather than description prose.

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-shape explanation is not strictly required, and the description does gesture at it. However, for a tool with a required-but-nullable year, an undocumented range cap, and two nearby eclipse siblings, the description leaves the agent short of what it needs to choose and call confidently.

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 50%: 'fields' and 'precision' are documented in the schema, while 'year' (nullable but required) and 'yearsRange' (max 20) are not. The description's 'year or multi-year range' hint loosely maps to those two params, but does not explain the required-but-nullable year, the 20-year cap, or how the two interact — so it only partly compensates for the 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?

Specific verb ('Find') plus a precise resource ('solar and lunar eclipses') and scope ('within a given year or multi-year range'). It clearly distinguishes itself from generic calendar tools, but never acknowledges the close siblings astroway_geo_eclipse_analysis or astroway_render_eclipse_path, which an agent would reasonably confuse with this one.

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

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

The phrase 'within a given year or multi-year range' implies when the tool applies, but there is no explicit when-to-use guidance, no exclusion of overlapping siblings, and no statement of prerequisites. Usage must be inferred from the purpose sentence 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 establish read-only/idempotent safety, and the description adds real behavioral context beyond them: automatic fallback warning when |lat| > 66.5° for quadrant systems, plus the list of supported house systems. It does not mention cost implications or fallback target system, but the polar-latitude caveat is valuable and non-obvious.

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?

Dense but front-loaded: the first clause states what is computed, the second names systems, the third flags the edge case. No padding, and the group/cost tags are structured metadata rather than prose. Slightly compressed to the point of terseness but no wasted 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-format explanation is not required, and the description usefully enumerates the returned points anyway. However, for a 15-parameter tool at 33% schema coverage with no output-schema reliance for params, the description leaves several inputs (cosmogram, name/city, date/time handling) undocumented.

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% across 15 parameters. The description names the house-system families (Placidus, Koch, Regiomontanus, etc.), which maps names onto the opaque enum codes, and its latitude caveat relates to the latitude parameter. But date/time/longitude, cosmogram, name and city go unaddressed in prose.

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 ('Standalone house calculation') and enumerates exactly what is returned: 12 cusps, ascendant, MC, ARMC, vertex, co-asc, polar-asc. The word 'Standalone' signals it is distinct from the full-chart sibling (astroway_western_chart), though no sibling is named outright.

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?

Implied usage only: 'Standalone' suggests reach for this when only houses are needed rather than a full chart, but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent must infer the routing decision itself.

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, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: retrograde re-entries are included in the result set, and the call costs 100 credits (Tier 4), which is operationally relevant for an agent budgeting calls.

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?

One tight sentence front-loads the core behavior, followed by short structured group/cost tags. Nothing is wasted, though the bracketed metadata is boilerplate rather than informative prose.

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. For a 5-parameter tool the description covers the essential inputs, the retrograde nuance, and cost, but omits any routing guidance among the many calendar siblings and says nothing about the compact-mode options, leaving a modest 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 only 40%: planetId, startDate, and endDate have no schema descriptions, and the description compensates by naming the planet and date range as the operative inputs. It says nothing about the two optional compact-mode parameters (fields, precision), though those are already documented in the schema, so the net compensation is adequate but not deep.

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

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

The description gives a specific verb and resource ('Find all sign ingresses for a planet within a date range') and adds a scope qualifier ('including retrograde re-entries') that clarifies the semantics of 'ingress'. It does not, however, distinguish itself from close siblings such as astroway_calendar_retrograde_periods or astroway_calendar_planetary_cycles, so an agent must infer the boundary.

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

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

There is no when-to-use or when-not-to-use guidance and no named alternative. The agent is left to infer from the date-range/planet framing that this is a time-window scan, with nothing steering it away from overlapping tools like retrograde_periods or planetary_cycles.

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=true, idempotent=true, destructive=false, openWorld=false, so safety is covered. The description adds genuinely useful non-annotation context: the 100-credit Tier 4 cost, which lets an agent weigh whether the call is worth it. Return-format detail is light but the output schema exists, so this is the right area to add 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?

A single front-loaded sentence with zero filler, followed by compact bracketed metadata for group and cost. Every element 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, two-required-param aggregation tool with an output schema, the definition covers purpose, contents, and cost adequately. The only real gap is the absence of any usage/routing guidance, which is minor given the tool's simplicity.

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%: the non-obvious params (fields, precision) are documented in the schema, while year/month are self-explanatory from their names. The description adds nothing beyond "given month" — no format hints, ranges, or defaults — so it neither compensates nor detracts.

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

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

States a specific verb ("Calculate") and resource ("a lunar calendar for a given month"), then enumerates the outputs (Moon sign per day, lunar phases, VOC windows, perigee/apogee). The enumeration implicitly distinguishes it from the single-purpose siblings astroway_calendar_moon_phase and astroway_calendar_moon_voc, though 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 only says "for a given month" — there is no when-to-use vs. when-not guidance and no routing to alternatives like the individual moon-phase or VOC tools. An agent must infer the aggregation-vs-single-purpose distinction entirely on its own.

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

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety burden is off the description. The description adds that both applying and separating aspects are returned and discloses a 100-credit (Tier 4) cost, which is genuinely useful pre-call information, but says nothing about result volume, pagination, or lat/long input needs for this kind of 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?

One sentence of substance plus two bracketed metadata tags; the purpose leads and nothing is padded. Only minor drag from the metadata blocks, which are arguably infrastructural rather than descriptive.

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 structure need not be described, and the core operation is stated. Still, in a namespace with dozens of calendar and aspect tools, the description does not supply the disambiguating detail (Moon-to-planet only? all aspect types? transit vs. natal?) that would let an agent pick this tool confidently over its near neighbors.

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%: only fields and precision are documented, while the required year and month have no schema descriptions. The description's "within a date range" is the only hint about their meaning, and it is actually misleading since no day or time parameter exists in the schema, so the framing of a date range is never reconciled with the year+month inputs.

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), a specific resource (aspects the Moon makes), and a scope (within a date range, including applying and separating). This is clearly narrower than the generic astroway_calendar_aspects, though it never names that sibling to make the distinction 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?

"Useful for electional and horary work" gives a domain context, which implies when an agent would reach for it. However, there is no statement of when to prefer this over astroway_calendar_aspects, astroway_calendar_moon_voc, or astroway_aspects_aspect_timeline, all of which sit in the same decision space.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the algorithmic basis (Meeus Ch.48, geocentric) and the 10-credit consumption cost. It still says nothing about geographic sensitivity, caching, or rate limits, so it adds moderate rather than rich behavioral context.

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

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

Two tight sentences with the computed outputs front-loaded, followed by a compact methodology note and bracketed metadata. No filler or redundancy, though the group/cost tags are appended rather than integrated.

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 correctly focuses on what is computed. However, with 15 parameters at 33% schema coverage and no usage guidance, the definition is incomplete for an agent trying to assemble a correct call — particularly around whether location is truly needed for a phase value.

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% across 15 parameters, so the description must carry more of the burden and does not. It never mentions the four required inputs (date, time, latitude, longitude), the timezone vs timezoneOffset interaction, ayanamsa/zodiacType choices, or the compact-mode fields/precision options.

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 the specific resource and enumerates exactly what is computed: illumination %, age in days, elongation, waxing/waning, and sun/moon zodiac signs, plus the method (Meeus Ch.48 geocentric Sun-Moon elongation). An agent knows precisely what this produces. It does not, however, distinguish itself from closely named siblings such as astroway_render_moon_phase or astroway_calendar_lunar_calendar.

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

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

There is no when-to-use guidance, no statement of prerequisites (e.g. that latitude/longitude and a local date/time are mandatory), and no routing to alternatives like the moon-phase renderer or the lunar calendar. The bracketed group/cost tags are metadata, not 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?

Annotations already declare this a safe, read-only, idempotent, non-destructive operation, so safety behavior is covered. The description adds the VOC definition and a credit cost tier, but says nothing about output shape, rate limits, or how periods are bounded/returned when none occur.

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 tight sentences with the concept definition front-loaded, plus compact bracketed metadata for group and cost. No filler, though the group/cost tags are somewhat boilerplate.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. Still missing are sibling differentiation and any explanation of the three undescribed parameters, leaving the agent with questions before 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?

Schema description coverage is only 57% — 'date', 'time', and 'rangeDays' have no schema descriptions at all. The description mentions only 'within a date range', which hints at rangeDays but does not explain the date/time format, the meaning of rangeDays, or how date+time+rangeDays combine. It fails to compensate 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?

States a specific verb+resource ('Find Moon void-of-course periods') and even defines the domain concept (last aspect until next sign ingress). However, it does not differentiate this from closely related siblings such as astroway_calendar_moon_phase, astroway_calendar_lunar_calendar, or astroway_calendar_moon_aspects, which an agent could easily confuse it with.

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 when-to-use / when-not-to-use guidance and no mention of any alternative tool. The sibling set contains at least three other Moon-calendar tools, so the absence of routing information is a real gap; usage must be inferred from the name 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful non-schema behavior: the cost (100 credits, Tier 4), which lets an agent budget. It says nothing about result volume, date-range limits, or pagination.

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

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

Two tight sentences with the core action front-loaded, followed by structured group and cost tags. Nothing is padded, though the bracket metadata is arguably presentation rather than description.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. The remaining gaps are the planet ID domain and any range/limit constraints, which are modest for a read-only query tool but still real.

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%, and the two documented parameters (fields, precision) are the optional ones. The description compensates for the undocumented required parameters by conveying their meaning (two planets plus a date range), but it never explains what a planet ID actually is or its valid domain, which is the key ambiguity for the caller.

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: 'Find all conjunctions between two planets within a date range,' which tells an agent exactly what is computed. It adds the domain framing ('start of a new synodic cycle'), but it never distinguishes itself from close siblings such as astroway_calendar_aspects or astroway_aspects_aspect_timeline, so the agent must infer the boundary.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternative among the many calendar/aspect siblings. The phrase 'defining the start of a new synodic cycle' hints at the analytical intent but does not tell the agent when this tool is preferable to a generic aspect search.

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, so the safety load is largely carried. The description adds real behavioral context beyond that: the cacheable-result rationale for why isCurrent is omitted rather than false, and the note that hours are rarely 60 minutes long. It does not mention auth, rate limits, or credit cost.

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, followed by the structural detail and the parameter behavior. Sentences are dense but each carries information; the truncated trailing clause suggests the entry is tight rather than padded.

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 annotations cover the safety profile. What remains — the purpose, the hour structure, and the isCurrent/atLocalHour contract — is all present, so an agent has what it needs 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 coverage is 63%, and the schema itself already documents atLocalHour, timezone, timezoneOffset, fields, and precision in detail. The description's atLocalHour explanation largely duplicates the schema, and startHour/endHour it references are outputs, not inputs, so net added parameter meaning is marginal.

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

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

The description gives a precise verb+resource: 'Chaldean planetary hours for a date and place,' and even explains the 12+12 unequal-hour structure, so an agent immediately knows this is the planetary-hours calculator rather than a general calendar tool. It stops short of naming any sibling (e.g. moon_phase, hours vs. sun_times) to disambiguate within the dense calendar group.

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

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

There is no when-to-use or when-not-to-use guidance and no routing to alternatives among the many calendar siblings. The only conditional logic explained is the internal atLocalHour toggle, which is about output shape, not about selecting this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact not in the annotations — the 20-credit (Tier 2) cost — but says nothing about rate limits, whether results depend on the observer's location, or how the phase set is computed. With annotations carrying the safety burden, this is adequate but thin.

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?

A single front-loaded sentence that names the operation, the scope ('each planet relative to the Sun'), and the full phase vocabulary, followed by compact group/cost metadata. Nothing is wasted, though the enumerated phase list could be trimmed since the output schema presumably carries the values.

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 annotations cover safety. However, for a 15-parameter tool with only 33% schema coverage, the description omits why latitude/longitude are required for a planetary-phase calculation and how ayanamsa/zodiacType affect the result. Minimum viable, with clear gaps.

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

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

The description mentions no parameters at all, and schema description coverage is only 33% across 15 parameters. Several undocumented parameters (cosmogram, zodiacType, houseSystem) plausibly alter the computed phases, yet the description does not explain any of them. With coverage below 50%, the description was expected to compensate and does not.

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

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

States a specific verb and resource: 'Calculate the synodic phase of each planet relative to the Sun,' and enumerates the eight phase names so the agent knows exactly what output to expect. It is distinguishable from astroway_calendar_moon_phase by the phrase 'each planet,' but the description never names that sibling or otherwise explicitly differentiates itself from the surrounding calendar 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?

There is no when-to-use guidance, no exclusions, and no named alternative. The only routing signal is the bracketed '[Group: Calendar & Cycles]' label, which is category metadata rather than usage guidance. An agent must infer from the tool name alone when this beats astroway_calendar_moon_phase or astroway_calendar_planetary_cycles.

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, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds genuinely new context: the 50-credit Tier 3 cost and the Calendar & Cycles grouping, both useful for selection. It says nothing about output shape or the meaning of 'stations' beyond the three states, but the output schema covers returns.

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 single sentence followed by compact metadata lines for group and cost; nothing is bloated. It is efficient, though slightly terse given the parameter set it must cover.

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 and annotations cover return values and safety, so the burden is reduced. What is missing is how to specify planetIds (opaque integer IDs with no description or enum) and no guidance for the date range, leaving an agent unsure how to construct a valid call for anything but default planets.

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 40%; planetIds and the two date params carry no schema descriptions. The description partially compensates by naming the planet concept and the date-range bound, mapping loosely to planetIds/startDate/endDate. It adds nothing about precision or fields, and gives no hint on planet ID enumeration.

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: finding retrograde stations (direct/retrograde/stationary) for a planet over a date range. The scope is clear enough to distinguish from most siblings, but it never differentiates itself from near-neighbors like astroway_calendar_planetary_cycles or astroway_calendar_ingresses, which also return timed station/transition events.

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 when-to-use guidance, no mention of alternatives, no prerequisites. The description implies you supply a planet and a date range but never says when this tool is preferable to the other calendar tools that surface retrograde-adjacent events.

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, so safety is covered. The description adds genuinely new behavioral facts: a concrete credit formula, a 3000-char ceiling, and glossary pinning as a translation behavior. No contradictions 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?

Two tight sentences with the capability, default, and limits front-loaded, followed by bracketed metadata. Minor redundancy between 'Credits: 15 + ceil(chars/40)' and '[Cost: 16 credits (Tier 1)]', but overall 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?

An output schema exists, so return values need no explanation, and annotations carry the safety profile. Cost, limits, and the source default round out the picture; only the unexplained 'domain' parameter and the language-count mismatch keep it from being fully complete.

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

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

Schema coverage is only 33%, so the description must compensate; it clarifies the source_lang default and the text length cap, which helps. However, the 'domain' parameter is never mentioned anywhere, and the stated '21 languages' does not match the 20-value enums for source_lang/target_lang, leaving ambiguity.

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 ('Translate one text') and adds domain-scoping ('astrology-domain glossary pinning'), which is more than a restatement of the title. 'One text' implicitly separates it from astroway_content_localization_translate_batch, though 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?

Gives a useful default rule ('Source defaults to English; pass source_lang to override'), but never says when to choose this over translate_batch (multiple texts) or translate_glossary_lang (glossary management). Usage is implied by 'one text' 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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: per-string and per-batch size limits plus an explicit cost formula (15 + ceil(total_chars/40)), which is exactly the kind of cost/rate information annotations cannot carry.

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 constraints and cost in a single tight sentence; the group and cost tags are compact metadata lines. Every element earns its place with 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?

An output schema exists, so return values need not be explained. Still, for a 6-parameter tool the description omits source_lang entirely and gives no sibling routing, leaving notable gaps; it is adequate but not 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 coverage is low (33%), so the description must compensate. It does add real meaning: items are bounded (≤25, ≤2000 chars, ≤20000 total) and must share one target language + domain. However, source_lang is never mentioned, and the compact-mode fields/precision parameters (only explained in the schema) sit oddly against a translation tool with no description-level context.

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 ('Translate up to 25 strings') and adds precise scope limits (2000 chars each, 20000 total, one shared target language + domain). It is clear and self-contained, but never distinguishes itself from the sibling translate_astro / translate_glossary_lang / translate_languages tools, which an agent selecting among them would want.

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

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

There is no when-to-use guidance. The batch/shared-domain framing implies bulk use, but nothing tells the agent when to pick this over the astro or glossary translation siblings, or what the single-string alternative is. The constraints imply a use case but leave 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 declare readOnlyHint, idempotentHint and destructiveHint=false, so the safe read profile is covered. The description adds cost behavior, but then contradicts itself: 'Free (0 credits)' followed by '[Cost: see your plan — endpoint not in the public credit manifest]', which leaves the agent unable to know whether this costs credits.

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 purpose in one sentence, then the query defaults and cost. The group/cost metadata lines are boilerplate but short; nothing egregious.

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

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

With an output schema present and full parameter coverage, return values need not be explained. However, the self-contradictory cost line and the absent guidance on how this glossary relates to the translate_* siblings leave gaps for a localization-family 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 lang, fields and precision are already well documented and baseline 3 applies. The description instead describes query parameters that do not exist in the schema (?source, ?domain), which adds marginal, mildly confusing context rather than clarifying the actual inputs.

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: 'Download the astrology glossary for a target language' — an agent can tell this retrieves glossary content rather than translating astro text (translate_astro) or listing locales (translate_languages). It does not explicitly name the closest siblings, but the noun 'glossary' separates it adequately.

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 statement of when to use this versus the sibling translation/localization tools. It supplies default values for query options (source=en, domain=generic) and a cost note, but nothing about prerequisites or selection conditions.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's only added behavioral claim is cost ('Free (0 credits)'), but it is immediately followed by '[Cost: see your plan — endpoint not in the public credit manifest]', an internally inconsistent billing signal that an agent cannot resolve.

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

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

The core sentence is short and front-loaded, but the two bracketed metadata footers are boilerplate that duplicate billing intent and contradict the 'Free (0 credits)' claim, adding noise rather than 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?

For a zero-required-parameter lister with an output schema (so return values need not be explained), stating the count and payload shape plus the compact-mode availability is close to sufficient. Only the missing guidance on how this feeds the translate_* tools leaves a 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 100% and both parameters (fields, precision) are generic compact-mode response shapers documented in the schema itself. The description adds nothing about them, 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 ('List the 21 supported language codes + names') with a concrete count, so an agent knows exactly what comes back. It is distinguishable from the translate_* siblings by being a pure listing, though it never names those siblings to confirm the distinction.

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

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

No when-to-use or when-not-to-use guidance is given, and the obvious alternative use cases in the same Content Localization group (translate_astro, translate_batch, translate_glossary_lang) are never mentioned. The only usage-adjacent signal is 'Free (0 credits)', which is about billing, not 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 declare readOnly/idempotent/non-destructive/closed-world, so the safety bar is low; the description still adds real value by clarifying that endpoints are NOT invoked and that results are cached with a 5-minute TTL. It also discloses the return shape (total + per-endpoint breakdown with tier annotations), which is meaningful since no output schema 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?

Three tight sentences, front-loaded with the core capability and the non-invocation guarantee, followed by workflow guidance and the cache note. Nothing is wasted.

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

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

Despite having no output schema, the description explains the return value, and the invocation-free and cache behaviors are covered. For a one-parameter, read-only estimator this is fully sufficient.

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

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

Schema description coverage is 100% and the single 'endpoints' parameter is fully documented with examples and the leading-slash rule in the schema. The description only restates 'one or more endpoints' without adding format or constraint detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('Estimate the credit cost of one or more endpoints') and immediately pins the scope with 'WITHOUT invoking them', which no sibling tool does. An agent can distinguish this from the many invocation/report siblings 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?

Gives explicit workflow guidance: 'estimate first, ask user confirmation, then invoke' for multi-step planning. This is clear when-to-use context, though it names no alternative tool or when-not-to-use condition.

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, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered structurally. The description adds the non-obvious cost context (20 credits, Tier 2), which is genuinely useful for planning, but says nothing about computation dependencies or output shape.

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

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

One front-loaded sentence defining the computation plus two compact metadata tags. No filler, no repetition of schema content.

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

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

An output schema exists and the input schema is fully documented, so return values and inputs need no restatement. For a deterministic read-only computation this is close to sufficient; only the missing sibling differentiation keeps it from a 5.

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

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

Schema description coverage is 100%, including a rich description of the nested birth-data object, so the schema carries the parameter burden. The tool description adds no parameter meaning of its own, which is the baseline expectation here.

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?

Names a specific verb ('Calculate') and resource ('Almuten Figuris') and defines the concept precisely as the planet with the highest essential dignity score across key chart positions. However, it does not distinguish itself from close siblings like astroway_dignities_essential_dignities or astroway_dignities_hyleg, which operate on overlapping dignity concepts.

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 no indication of when to choose this tool over its dignity siblings (essential_dignities, receptions, disposition_chains, hyleg), nor any prerequisites such as needing a full natal chart with houses. Only the group tag hints at domain.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the cost tier ('20 credits (Tier 2)') and group, which is genuine value beyond structured fields, but says nothing about what the chain output looks like or any limits.

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

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

One front-loaded sentence plus two compact metadata tags; nothing is wasted. It is arguably under-specified rather than over-long, but structurally 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?

An output schema exists, so return values need not be explained, and the core computation is stated. However, for a tool nested inside the dignities family with a layout variant sibling, the absence of routing guidance leaves the definition minimally adequate.

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

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

Schema description coverage is 100% and the schema itself richly documents body, mode/rulerMode, fields and precision. The description adds no parameter meaning of its own, 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 ('Calculate planetary disposition chains') and defines the concept ('the recursive sequence of sign rulers leading to the final dispositor'), which lets an agent distinguish it from siblings like almuten or essential_dignities. It stops short of naming or contrasting any sibling directly, so it is clear but not fully differentiated.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as astroway_dignities_disposition_chains_layout, which sounds like the closest sibling. The group tag hints at domain but gives no selection criteria.

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, closed-world, non-destructive behavior, so the safety profile is covered. The description adds a genuine behavioral fact beyond the schema: the 20-credit Tier 2 cost, which lets an agent budget calls. Output content (layout coordinates) is also noted, though the return shape itself is left to the 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?

A single front-loaded sentence captures purpose and differentiator, followed by compact group and cost tags. Every line earns its place with no redundancy.

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 explaining the return shape is not required, and the rich input schema covers the natal/mode parameters. What remains slightly thin is the relationship to the rendering tools and the non-layout sibling, but for a layout-variant tool this is largely 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 the body, fields, and precision parameters thoroughly documented in the schema itself. The description adds nothing about parameters, so the baseline 3 for a fully-covered schema 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 (Return) and resource (disposition chains) plus the distinguishing feature: computed x/y layout coordinates for graph visualization. This implicitly separates it from the sibling astroway_dignities_disposition_chains, though it never names that sibling explicitly, so an agent must infer the contrast.

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

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

The phrase 'for graph visualization' hints at the use case, but there is no explicit when-to-use, when-not-to-use, or routing to the non-layout sibling. The agent has no guidance on why it would pick this variant over astroway_dignities_disposition_chains.

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 disclose that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful cost context (20 credits, Tier 2) but does not describe return behavior, authentication needs, or rate limits, and output schema covers results.

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 front-loaded sentence naming the calculation, followed by compact group and cost metadata. Every element earns its place, with no redundancy or waste.

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 and the presence of an output schema, the description provides enough to understand the tool's output scope. The main missing element is usage guidance relative to other dignity tools, but the group label and precise calculation statement make it largely 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 the input schema already documents the body, fields, and precision parameters thoroughly. The description adds no parameter-specific meaning beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states a specific verb ('Calculate'), resource ('essential dignities'), and the exact five Ptolemaic categories plus debilities. This clearly distinguishes it from sibling dignity tools such as almuten, disposition chains, hyleg, and receptions.

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 no explicit when-to-use guidance, prerequisites, or comparison to alternative dignity tools. The [Group: Dignities & Receptions] label categorizes it but does not explain when an agent should choose this tool over 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 cover read-only, idempotent, non-destructive and closed-world behavior. The description adds genuinely useful non-schema context: the method tradition and the 20-credit Tier 2 cost, which lets an agent budget calls. It says nothing about dependencies on the body chart data or what the computation requires, so it is additive but not rich.

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

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

One tight sentence carries the verb, resource and method, with the group and cost tags appended compactly. Front-loaded and waste-free, though the metadata lines add little beyond classification.

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

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

With an output schema present the return values need no explanation, and the input schema is fully documented, so an agent can technically call it. The remaining gap is routing: nothing explains when hyleg/alcocoden analysis is the right dignity tool versus its 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 schema already documents body, fields and precision in detail (including timezone handling and compact mode). The description adds no parameter meaning beyond that, which is the expected baseline 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?

States a specific verb (Calculate) and the exact resources (Hyleg/apheta, giver of life; Alcocoden, indicator of lifespan) plus the method (traditional Hellenistic). It is precise about what it computes, but never distinguishes itself from sibling dignity tools like astroway_dignities_almuten or astroway_dignities_essential_dignities.

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 when-to-use guidance, no prerequisites, and no alternatives are named. The [Group: Dignities & Receptions] and cost tags are metadata, not usage guidance. An agent has no signal for choosing this over almuten or disposition_chains.

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, idempotentHint, destructiveHint false, and openWorldHint false, so the safety profile is covered. The description adds the credit cost and tier, which is genuinely useful operational context absent from annotations, but says nothing about computation scope, planet set, or output shape.

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

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

One sentence that defines the deliverable up front, followed by bracketed metadata for group and cost. Nothing is redundant and the operative definition 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?

An output schema exists, so return values need not be explained, and annotations cover safety. The gap is the missing link between the tool and its required input: the agent is not told that a natal chart (date, time, latitude, longitude) must be supplied, nor how receptions rank against essential dignities output, which a sibling-heavy toolset makes non-obvious.

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

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

Schema description coverage is 100%, including detailed natal-chart fields and compact-mode fields/precision, so the schema carries parameter meaning. The description adds no parameter information at all; 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 (find mutual receptions between planets) and then defines the concept operationally: pairs where each planet is in a sign ruled, exalted, or in the dignity of the other. An agent can tell what a result means. It does not, however, distinguish itself from nearby siblings such as astroway_dignities_essential_dignities or astroway_dignities_disposition_chains.

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

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

There is no statement of when to choose this tool over the other dignity tools, no prerequisites, and no exclusions. The only routing signal is the [Group: Dignities & Receptions] tag, which is a category label rather than 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 readOnly, idempotent, openWorld=false, and non-destructive, so the safety profile is covered. The description adds real value with the cost disclosure (50 credits, Tier 3), which matters for a metered tool, but says nothing about output shape or latency.

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 front-loaded sentences plus structured group/cost metadata; nothing is wasted. It is tight, though the brevity is partly what leaves the parameter story untold.

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 described, but a 15-parameter astrological calculation with 33% coverage and no guidance on sidereal vs tropical, ayanamsa selection, or date/timezone handling is under-specified for correct invocation.

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

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

Fifteen parameters with only 33% schema description coverage, and the description mentions none of them. Critical choices such as zodiacType, ayanamsa, timezone vs timezoneOffset, and the compact-mode fields/precision have no guidance beyond terse schema text, and four required birth inputs are never explained.

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*C*G lines) and defines the concept (geodetic map lines where each planet was angular at birth). It is clearly the base ACG computation, but it never distinguishes itself from the many geo_acg_* siblings such as line_report, by_category, or best_places.

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

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

There is no when-to-use or when-not-to-use guidance. With eight astroway_geo_acg_* siblings plus geo_geodetic, geo_relocation, and geo_local_space in the same family, an agent gets no help deciding when this raw calculation is preferable to the report/category/zone variants.

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 behavior. The description adds useful algorithmic context by explaining that distance is computed exactly from hour angle and altitude rather than a discretised polyline, and that it ranks supportive versus challenging influences.

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

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

The purpose is front-loaded in the first sentence, but the description then spends significant space on a technical formula and ends with a truncated phrase ('Supportive and challengin…'). It is not wasteful, but not tightly structured either.

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, rich annotations, and full schema descriptions, the main missing piece is usage guidance relative to sibling tools. For a specialized ranking tool, the description is adequate but leaves routing decisions to inference.

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

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

Schema description coverage is 100%, so every parameter already has documentation. The description mentions the 19 life categories and supportive/challenging ranking, but adds no syntax or format details beyond what the schema provides.

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

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

The description states a specific verb and resource: 'Rank cities against the astrocartography lines of a chart for one of the 19 life categories.' That is clear and actionable, but it does not explicitly differentiate this tool from close siblings such as astroway_geo_acg_by_category or astroway_geo_acg.

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 no when-to-use, when-not-to-use, or alternative-tool guidance. An agent must infer from the name and sibling list whether this or another ACG endpoint is appropriate.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the ranking logic, the curated-interpretation return, and the [Cost: 50 credits (Tier 3)] disclosure. It loses credit because it claims '11 languages' while the schema's language enum exposes 21, an internal inconsistency that could mislead an agent about 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?

Two tight sentences carry the core behavior, with the ranking rule front-loaded, followed by structured [Group] and [Cost] metadata lines that are easy to scan. Nothing is wasted, though the '11 languages' clause is inaccurate rather than merely brief.

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 and the input schema is fully documented, so return-value explanation is unnecessary. For a read-only geo tool sitting in a family of six similar astroway_geo_acg* tools, the description is adequate on behavior but incomplete on routing, which is the main thing an agent needs here.

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

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

Schema description coverage is 100% and the nested body schema already documents date/time/latitude/longitude, timezone handling, category, polarity, radiusDeg, and language in detail. The description's only parameter-adjacent contribution is the optional 'point' behavior for proximity ranking, so baseline 3 applies.

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

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

The description names a specific resource and scope: A*C*G lines filtered to one life category, with a stated ranking rule (astrological weight, then proximity when a point is supplied). It does not, however, differentiate itself from close siblings such as astroway_geo_acg, astroway_geo_acg_categories, or astroway_geo_acg_line_report, so an agent cannot tell from the text alone which of the six geo_acg tools to pick.

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 only usage signal is the conditional clause 'when a point is supplied, by proximity to it,' which hints that a location is optional but never states when to choose this tool over astroway_geo_acg or astroway_geo_acg_categories. There is no when-to-use, when-not-to-use, or prerequisite guidance, and the sibling list is crowded with near-duplicates.

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 openWorldHint=false, so the safety profile is covered. The description usefully adds that this call is free and cacheable and that it is a read-only reference rather than a computation, which is genuine value beyond the structured 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?

Front-loaded with the substance (taxonomy, 19 areas, planet-and-angle lines), tail metadata kept short. Efficient, though the dangling "two endpoints below" reference and mixed bracketed tags add slight 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?

An output schema exists so return values need not be explained, and the tool has no required parameters. However, the description leaves the "two endpoints below" unreferenced and says nothing about how the taxonomy integrates with the category-based siblings, leaving an agent to bridge that 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 100% and the schema fully documents both the fields projection syntax and the precision rounding, so baseline 3 is appropriate. The description adds nothing about fields or precision.

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 resource: a reference taxonomy of 19 life areas mapping planet-and-angle lines with weight and polarity. This clearly differentiates it as the static lookup table behind the ACG endpoints, distinct from computation tools like astroway_geo_acg or astroway_geo_acg_by_category. It falls short of a 5 only because it never names those endpoints explicitly ("the two endpoints below").

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?

"Drives the two endpoints below" implies it is a lookup source rather than a computation, and "Free, cacheable" hints it is a cheap reference call, but no explicit when-to-use or when-not-to-use versus the ~15 astroway_geo_* siblings is given. Usage must be inferred.