AstroWay Hellenistic and traditional

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds genuine behavioral context beyond them: executors are kept out of the vendor objects because an unexpected key causes a 400 on the vendor side, and cost is flagged as not in the public credit manifest. That is real operational 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?

Roughly three sentences, front-loaded with the purpose before the format and executor caveats. It is dense but each sentence carries information, though the format explanation partially duplicates the schema's own enum description.

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

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

With an output schema present and full annotation coverage, the description need not explain return values, and it appropriately focuses on the vendor-shape contract and the executors/400 gotcha. It is nearly complete, with the only gap being sibling disambiguation rather than missing operational detail.

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

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

Schema description coverage is 100%, so the schema already documents every parameter in depth (limit ceiling rationale, select values, precision semantics). The description only restates format and its default, adding no parameter meaning the schema lacks. Baseline 3 is correct.

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

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

The description clearly states what the tool returns: tool definitions for an agent framework, generated from the live OpenAPI document. It is specific about the resource and the vendor-shape variants (openai vs anthropic objects). However, it never distinguishes this from the near-identical sibling astroway_mcp_tools_list, which an agent would plausibly 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?

There is no explicit when-to-use, when-not-to-use, or alternative-naming guidance. The mention that openai objects 'spread straight into a chat completion' implies a use case, but the agent is left to infer when this endpoint is preferable to astroway_mcp_tools_list or the MCP tool-call streaming siblings.

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

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

Annotations already declare 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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description usefully adds the cost (10 credits, Tier 1) and the endpoint, but says nothing about the nature of the nine categories or any rate/usage constraints beyond 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?

Front-loads the one-line purpose and then packs group, endpoint, required params, cost, and alias into tight bracketed lines. Efficient; the redundancy of restating the four required params is the only minor 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?

An output schema exists, so return values need no explanation, and the alias/endpoint/cost framing is complete for an alias tool. However, with 15 params at 33% schema coverage and a domain term ('9 categories') left unexplained, the description is only marginally adequate 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 33% across 15 parameters, so the description carries the burden of compensating — but it merely repeats the four required params (date, time, latitude, longitude) already listed in the schema and says nothing about the ayanamsa, timezone, houseSystem, fields, precision, or zodiacType 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?

States the resource and scope ('Planet conditions per Valens: 9 categories') and explicitly identifies itself as a Cursor-friendly alias for the canonical `astroway_hellenistic_brennan_bonifications_maltreatments`, which helps distinguish it from the many HB siblings. The intent is somewhat jargon-dependent ('bonifications/maltreatments'), but an agent can place it in the Hellenistic/Brennan family.

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 required inputs, endpoint, and credit cost are given, and the alias relationship implies when it is interchangeable with the canonical tool. There is no explicit when-to-use-vs-alternatives guidance against the other Brennan/Hellenistic tools (e.g. joys_of_planets, lots_15).

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds only metadata (group, endpoint, cost) but nothing about behavioral traits such as what the response contains, pagination, or error conditions. For a read/compute tool with annotations in place, this is thin but not contradictory.

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 short and front-loaded with the key concept. The bracketed metadata block (group, endpoint, cost) adds operational utility without bloat. It's efficient, though the core sentence could be more action-oriented.

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

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

The tool has an output schema, so return-value explanation isn't required. The description covers group, endpoint, cost, and alias relationship, but omits what the tool actually computes and when to use it relative to the many profection/time-lord siblings. Adequate but with notable 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?

Schema description coverage is 100%, so the schema fully documents parameters including timezoneOffset, houseSystem, targetAge, and fields/precision. The description adds no parameter meaning beyond the schema, so the baseline 3 is appropriate.

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

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

The description reads 'Annual profection year-lord with full classical condition,' which tells the agent what the output is but not what the tool does as an action. It's close to a restatement of the title/name rather than a verb+resource statement. It does not distinguish itself from siblings like astroway_prognostics_profections or astroway_hellenistic_brennan_time_lord_stack.

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

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

The description provides no when-to-use guidance, no alternatives, and no exclusions. The only routing hint is the note that it is a 'Cursor-friendly alias' for astroway_hellenistic_brennan_profections_detail, which is about naming, not usage selection.

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

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

Annotations already declare the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the description is not the main carrier here. It does add genuinely useful operational context in the cost (10 credits, Tier 1) and the required-parameter list, but says nothing about output shape or computation 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 purpose is front-loaded in one line, followed by compact bracketed metadata (group, endpoint, required, cost) and a short alias note. Nothing is padded, though the bracketed blocks are metadata 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?

An output schema exists, so return values need not be described, and the endpoint/cost/required blocks cover the minimum needed to invoke the call. However, for a 15-parameter tool with low schema description coverage, the description does not do enough to round out the missing parameter meaning.

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% and 15 parameters exist, so the description is expected to compensate but does not. It lists the four required parameters (date, time, latitude, longitude), which merely repeats the schema's required array, and leaves the remaining eleven parameters undocumented.

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 the specific technique (Dorothean triplicity rulers) and its scope variants (day/night/common), which is a concrete astrological resource rather than a tautology. It also explicitly identifies itself as an alias of a named sibling, aiding disambiguation, though it does not explain how it differs from other Hellenistic triplicity-family 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 or when-not-to-use guidance and no selection criteria against alternatives. The alias note tells the agent this is interchangeable with one sibling, but nothing indicates the context in which a caller should reach for this technique.

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 non-schema facts — the 10-credit cost tier, the POST endpoint, and the Brennan-tradition grouping. It does not describe what a "body/livelihood period" output looks like (decade/peak structure), but with full annotations and an output schema that gap is tolerable.

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 technique and its meaning in the first line, followed by tightly packed metadata blocks. Every element is short, though the alias/endpoint/cost boilerplate is administrative rather than task-guiding.

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 plus a 100%-covered input schema carry the parameter and safety burden. The description supplies the remaining context an agent needs (cost, endpoint, tradition, alias mapping), leaving little missing 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 description coverage is 100%, and the rich nested birth-data schema documents date/time/latitude/longitude, timezone handling and the fields/precision compact-mode params in detail. The description adds no parameter meaning, so the baseline of 3 applies.

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

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

The description names a specific Hellenistic technique (Zodiacal Releasing from the Lot of Fortune) and its subject matter (body/livelihood periods), which is enough to separate it from the sibling ZR-from-Spirit tool. It stops short of explicitly contrasting itself with that sibling, 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 and no mention of the sibling astroway_helb_zodiacal_releasing_spirit or astroway_hellenistic_brennan_zodiacal_releasing_fortune. An agent has to infer from the name alone which releasing technique to pick and when Fortune rather than Spirit 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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds useful non-annotation context: cost (10 credits, Tier 1) and the exact endpoint. It says nothing about the response shape or computation depth, but with an output schema present that omission is minor.

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

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

Front-loaded with purpose, then tightly bracketed metadata for group, endpoint, and cost, ending with the alias note. Every element earns its place, though the bracketed lines are more structural boilerplate 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?

With a rich output schema, the description need not explain return values; it complements the schema with cost and endpoint. The only real gap is the absence of any routing guidance against the Fortune/Loosing-of-Bond siblings in this crowded Hellenistic family.

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 is thoroughly documented (date/time formats, timezone behavior, house system letters). The description adds no parameter meaning beyond this, so the baseline 3 is appropriate.

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

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

States a specific technique and object ('Zodiacal Releasing from Lot of Spirit') plus the interpretive domain ('career/action periods'). It implicitly distinguishes from the sibling 'zodiacal_releasing_fortune' by naming the Lot of Spirit, but it never explicitly contrasts the two, leaving that inference to the agent.

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

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

Usage is only implied by 'career/action periods'; there is no explicit when-to-use, when-not, or pointer to the Fortune counterpart. The alias note helpfully clarifies it is a duplicate of the canonical brennan tool, which is a genuine usage signal, but no comparative guidance is given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's genuine additions are cost (10 credits, Tier 1) and the canonical endpoint, which an agent can use for budgeting and auditing. It still says nothing about response behavior, pagination or the years window's effect.

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 purpose line followed by short bracketed metadata tags; nothing is padded or repeated. The tags earn their place as cost/group/alias signals.

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

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

With a rich output schema, full parameter documentation and safety annotations, the definition is serviceable for invocation. The remaining gap is that an agent cannot tell from this text what the technique means or when it should be preferred over the sibling ZR tools.

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

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

Schema description coverage is 100% and the nested body schema is unusually well documented (formats, timezone handling, houseSystem casing). 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?

The description names a specific technique and scope ('Loosing of Bond detection within ZR sequence') and pins it to the Hellenistic: Brennan tradition, which lets an agent place it in the right family. It falls short of 5 because the jargon is never unpacked and it doesn't distinguish itself from near siblings such as zr_peak_periods or zodiacal_releasing_fortune/spirit. The alias note does usefully resolve it against astroway_hellenistic_brennan_zr_loosing_of_bond.

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 use this tool versus the other ZR or zodiacal-releasing siblings, and no prerequisites or exclusions. The only routing information is endpoint, group and cost metadata.

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 credit cost (10, Tier 1) and the underlying endpoint, but says nothing about what the computation returns or any limits beyond the 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?

A single front-loaded sentence followed by compact bracketed metadata; no sentence is wasted. The bracket-block style is terse and machine-oriented rather than prose, but it is easy to scan.

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. Still, for a 15-parameter, 10-credit calculation tool the description leaves optional-parameter behavior and result content entirely to 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 must compensate; it merely repeats the four required fields already marked as required in the schema. The many optional parameters (city, name, cosmogram, zodiacType, houseSystem, ayanamsaId) get no elucidation from 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?

States a specific technique (solstitial antiscia) with a named tradition (Hellenistic conventions), which separates it from the general astroway_aspects_antiscia and from astroway_helg_contra_antiscia. The alias note also identifies the Greenbaum-lineage sibling it duplicates, aiding disambiguation.

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 alias line tells the agent this is interchangeable with astroway_hellenistic_greenbaum_antiscia_hellenistic, which is a useful routing hint. However there is no stated condition for choosing antiscia over contra-antiscia or the aspects variant, so usage is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-schema information: the credit cost (10 credits, Tier 1) and the fact that this is a duplicate alias of another endpoint, which helps an agent avoid double-billing for the same computation.

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 domain term followed by bracketed structured metadata (group, endpoint, required, cost, alias). No filler sentences, though the body is arguably too terse to be self-sufficient.

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 for a 15-parameter astrological computation with only 33% schema description coverage, the description leaves the caller without an explanation of the technique, the effect of ayanamsa/houseSystem/zodiacType, or how results are shaped.

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%, with 15 parameters including enums for ayanamsa, zodiacType and houseSystem. The description merely restates the four required fields already declared in the schema's required list and adds no syntax, defaults, or meaning for the undocumented parameters, so it neither compensates for the gap nor adds value.

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 deliverable ('equinoctial contra-antiscia') and, via the alias note, distinguishes itself from the canonical sibling astroway_hellenistic_greenbaum_contra_antiscia. However, it never states what the tool actually computes or returns (positions? aspect pairs?) – it is a bare domain noun phrase with no verb, opaque to anyone not already versed in Greenbaum Hellenistic technique.

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 guidance. The alias note ('Cursor-friendly alias for ...') implicitly tells the agent either name works, which is marginally useful, but nothing explains when contra-antiscia analysis is the right choice versus siblings like astroway_helg_antiscia_hellenistic or astroway_hellenistic_greenbaum_dodekatemoria.

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 genuinely new operational context - the 10-credit Tier 1 cost and the required parameter set - but says nothing about authentication needs, rate limits, or what the response actually contains.

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 short, bracket-structured, and front-loads the key facts (group, endpoint, required params, cost). The opening phrase 'as primary chart spine' is interpretive filler, but the remainder is dense and earns its space.

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

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

An output schema exists, so return-value documentation is not required. However, for a 15-parameter sidereal-capable calculation in a family with many near-identical Hellenistic siblings, the description omits what distinguishes this axis output from related Greenbaum tools and how the timezone/zodiac options affect the result.

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

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

With 15 parameters and only 33% schema description coverage, the description is expected to compensate, and it does not. It merely repeats the four already-required fields (date, time, latitude, longitude) that the schema marks as required, leaving timezone vs timezoneOffset, ayanamsa/ayanamsaId, zodiacType, and houseSystem semantics entirely unexplained in 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 names the resource (Spirit-Fortune / Daimon-Tyche axis) but never states what the tool actually does with it - no verb like 'computes' or 'returns'. It does provide sibling differentiation by explicitly identifying itself as the Cursor-friendly alias of `astroway_hellenistic_greenbaum_daimon_tyche_axis`, which is genuinely useful among hundreds of siblings.

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

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

There is no when-to-use guidance: nothing says when a practitioner should request the Daimon-Tyche axis versus zodiacal releasing, lots, or any other Hellenistic technique. The only routing cue is the alias note, which tells the agent this is interchangeable with the canonical name rather than when to choose it.

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. The description usefully adds the credit cost (10 credits, Tier 1) and discloses that it is a cursor-friendly alias of the canonical tool, but it omits auth prerequisites, rate limits, and any other operational caveats.

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

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

Five short lines with the purpose front-loaded and metadata in scannable bracket tags. The alias note is mildly redundant with the tool-name suffix, but there is no wasted 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?

For a 15-parameter specialized Hellenistic tool that does have an output schema, the description supplies tradition, endpoint, cost, and required inputs, which covers the basics. However, it leaves the 11 non-required parameters and all usage context unaddressed, so an agent can invoke it but has little help choosing or configuring it.

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 only restates the four required fields (date, time, latitude, longitude) that the schema's required array already declares. It says nothing about fields, ayanamsa, timezone, precision, timezoneOffset, or the other optional parameters, so it fails to compensate for the low coverage.

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

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

States a calculation of the Lot of Eros plus 'conditions analysis', and the group tag frames it as the Greenbaum Hellenistic tradition. It is clearer than a bare name restatement, but it never clarifies what 'conditions analysis' comprises and does not distinguish this alias from the canonical `astroway_hellenistic_greenbaum_lot_of_eros_detail` other than noting they are the same.

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 named alternatives, and no exclusions. The bracket block only lists required inputs and credit cost, so an agent gets no signal on when this detail variant is preferable to the broader lots or Hellenistic 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 the safe read-only, idempotent, non-destructive profile, so the bar is low. The description adds genuinely useful context: the 10-credit Tier 1 cost and the note that it is a cursor-friendly alias of astroway_hellenistic_greenbaum_quality_of_time, which signals duplication. No auth or rate-limit details.

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 and front-loaded: one purpose line followed by compact bracketed tags for group, endpoint, required inputs, and cost. Little waste, though the opening line carries almost no functional information.

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

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

For a 15-parameter tool with 33% schema coverage, the description omits guidance on the optional configuration params that distinguish Hellenistic variants. An output schema exists, so return values are excused, but the input-side complexity is largely unaddressed.

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

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

Schema description coverage is only 33% (15 params), so the description must compensate, but it merely repeats the four required params already marked required in the schema. Nothing is added about the eleven optional params (houseSystem, zodiacType, ayanamsa, fields, precision, timezone), which materially affect a Hellenistic calculation.

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

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

"Synchronistic quality of a moment" is close to a restatement of the name/title and does not say what the tool actually computes. However, the bracketed metadata names the tradition (Hellenistic: Greenbaum) and endpoint, which does differentiate it from the Brennan/Schmidt/Hand siblings in the same family.

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, and no named alternatives (e.g., vs. astroway_hellenistic_brennan_quality_of_time or other timing tools). The cost tag is the only decision-relevant hint provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld=false, so the safety profile is covered. The description adds genuinely useful context beyond the annotations — the cost (10 credits, Tier 1) and the endpoint — but it says nothing about what computation is performed or what the caller should expect, so the value is moderate.

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 definition is tight and front-loads the one descriptive phrase before bracketed metadata, with no filler sentences. The bracketed block is machine-oriented rather than prose, but it is compact and easy to parse.

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

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

An output schema exists, so return-value documentation is not required. But for a 15-parameter calculation tool the description omits the conceptual result, any usage context, and all optional-parameter meaning, leaving the agent without enough to invoke it purposefully beyond the four required fields.

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

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

Schema description coverage is only 33% across 15 parameters, and the description's '[Required: date, time, latitude, longitude]' merely restates the schema's required array. The optional parameters (ayanamsa, timezone, houseSystem, fields, precision, cosmogram) get no explanation in the description, 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 names a specific technique ('Constellations beyond the zodiac', Hellenistic Greenbaum tradition) and disambiguates itself as a cursor-friendly alias of astroway_hellenistic_greenbaum_sphaera_barbarica. However, it never states what the tool actually does or returns — no verb like 'compute' or 'derive the Sphaera Barbarica placements for a chart' — so the agent knows the topic but not the operation.

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 and no alternatives named. The bracketed metadata lists required inputs and cost but says nothing about the conditions under which this technique is appropriate, nor how it differs in use from related Hellenistic siblings (decans, dodekatemoria, temple doctrine).

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, destructiveHint=false, so safety is covered. The description usefully adds non-annotation context: cost (10 credits, Tier 1) and the POST endpoint. However it says nothing about response shape, latency, or failure modes beyond what annotations give, so it sits at the baseline-plus level.

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

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

The bracket-tag layout is front-loaded and scannable, with the technique name first and metadata after. No prose padding, though the alias line is the only content that isn't derivable from structured fields or the endpoint path.

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 15 parameters, 33% schema coverage, and no parameter explanation in the description, the definition is thin for the tool's complexity. The output schema handles return values and annotations handle safety, but the large block of undocumented parameters leaves the agent guessing about inputs like ayanamsa, house system, and compact mode.

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 carries a heavier burden. It merely restates the four required params (date, time, latitude, longitude) already flagged as required in the schema, and adds nothing about the undocumented params (city, name, cosmogram, zodiacType, houseSystem, ayanamsaId). 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 named technique (temple-house assignments) and attributes it to the Greenbaum tradition, which distinguishes it from the Brennan/Hand/Schmidt Hellenistic siblings. The parenthetical alias note clarifies its relationship to `astroway_hellenistic_greenbaum_temple_doctrine`, preventing duplicate calls. It stops short of saying what the output actually contains, but the purpose is identifiable.

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 reach for this technique versus other Hellenistic tools (dodekatemoria, zodiacal decans, quality of time). The alias note implies 'either this or the canonical name', but that is routing hygiene, not usage guidance. An agent gets no condition that selects this tool over its many siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description contributes the credit cost (10 credits, Tier 1) and the fact that this is a cursor-friendly alias of astroway_hellenistic_greenbaum_zodiacal_decans, which is genuinely useful, but the remaining bracket lines (endpoint, required fields) are operational metadata rather than tool-specific behavior.

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

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

The definition is short and front-loads the subject before the bracketed metadata, with no padding sentences. The structure is scannable, though the opening line carries very little information relative to the space the bracket block occupies.

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 endpoint with 33% schema coverage, the description supplies no explanation of what 'attributions' means, no usage context, and no disambiguation from the many adjacent Hellenistic decan/zodiacal tools, leaving real gaps an agent would face.

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%, with 15 parameters and no explanation of city, name, cosmogram, zodiacType, ayanamsaId, or houseSystem beyond bare enums/defaults. The description's only parameter content is '[Required: date, time, latitude, longitude],' which merely repeats what the schema's required array already states, 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 names the resource (zodiacal decans) and adds 'with attributions,' but it has no verb and largely restates the title 'Zodiacal Decans.' It does nothing to distinguish this Greenbaum decans endpoint from close siblings such as astroway_hellenistic_hand_decanic_rulers or astroway_hellenistic_greenbaum_dodekatemoria.

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 call this tool versus alternatives, and no named sibling for disambiguation. The '[Required: ...]' and '[Cost: ...]' brackets convey invocation mechanics, not usage guidance, so an agent gets no help deciding whether this or a neighboring Hellenistic technique fits.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description usefully adds operational context the annotations do not carry — the 10-credit cost and the required input set — but says nothing about authentication, output shape, or what the "9 categories" actually contain. With annotations doing the heavy lifting, this is an adequate 3.

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 statement is front-loaded and free of filler, and the bracketed metadata is compact. However, the terse phrasing tips into under-specification: the description is short because it omits information, not because it is economical.

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, but for a 15-parameter tool with weak schema coverage the description should do far more. It gives no usage context, no disambiguation from the sibling helb_bonifications_maltreatments, and no explanation of the nine categories, leaving an agent under-informed for a non-trivial chart calculation.

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 carries real burden — but it merely restates the four required parameters, which are already listed in the schema's required array, and adds no semantic meaning. Undocumented parameters such as cosmogram, zodiacType, and ayanamsaId receive no clarification here, so the coverage gap is left unfilled.

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 bare statement of what is computed ("Planet conditions per Valens: 9 categories"), which is enough to recognize the Hellenistic bonification/maltreatment concept but not a specific verb+resource framing. It does not distinguish itself from near-identical siblings such as astroway_helb_bonifications_maltreatments or astroway_dignities_essential_dignities, leaving the agent to guess which variant 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 when-to-use, when-not-to-use, or alternative-tool guidance anywhere in the description. The only routing-like content is a group tag and endpoint path, which tell the agent where the tool lives but not when to choose it over the highly similar helb_ and hand_ Hellenistic tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, closed-world and non-destructive behavior, so the safety profile is covered. The description adds two genuinely useful facts beyond annotations — the credit cost (10, Tier 1) and the required parameter set. It does not disclose how timezone/ayanamsa defaults affect results, which matters for a chart tool.

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

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

Compact and front-loaded: the meaning sentence comes first, followed by terse bracketed metadata. No meandering prose. The bracket fields are dense but each carries operational value, so little 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?

With an output schema present, return values need not be explained, and annotations cover the safety profile; required inputs and cost are given. However, for a 15-parameter chart tool the absence of any guidance on zodiac/house/ayanamsa options leaves the definition only 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 only 33%, so the description must compensate, but it only restates the four required parameters already marked required in the schema. It says nothing about behavior-affecting optional params (zodiacType, houseSystem, ayanamsa, timezone vs timezoneOffset) that materially change the output, leaving those enums unexplained in both places.

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 astrological resource ('Classical planetary joys') and anchors it with a concrete example ('Sun-Leo-9th'), so an agent can tell what domain it computes. The '[Group: Hellenistic: Brennan tradition]' tag distinguishes it from the many other Hellenistic sibling tools. It lacks an explicit verb (e.g. 'returns/computes'), keeping it just 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 statement of when to use this tool versus alternatives, no prerequisite context (it needs a full birth moment), and no routing to related tools such as lots_15 or bonifications_maltreatments. The only usage signal is the machine-readable bracket metadata listing required params and cost.

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 closed-world, so the safety profile is covered. The description adds genuinely new operational context the annotations do not carry: the credit cost and tier (10 credits, Tier 1) and the exact required input set, which is comparable to disclosing rate/cost constraints.

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 purpose, then terse bracketed metadata with no filler sentences. The endpoint URL is the only arguably redundant element, and the whole definition is short enough to scan instantly.

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 required inputs plus cost are stated. However, for a 15-parameter tool at 33% schema coverage sitting in a dense cluster of near-identical Hellenistic lot tools, the definition does not explain the optional parameters or justify choosing it over its siblings, leaving real 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?

Schema description coverage is only 33% across 15 parameters, so the description carries the burden of compensating — and it does not. It repeats the four required fields already listed in the schema's 'required' array and says nothing about the meaningful optional inputs (fields compact mode, ayanamsa/sidereal school, timezone vs timezoneOffset, zodiacType, houseSystem, 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 names a specific resource ('All 15 Hermetic Lots per Brennan §11') and scopes it to a named author/tradition, which separates it from the Greenbaum, Hand and Schmidt lot tools in the sibling list. It never states an explicit verb (compute/derive), and the differentiation from other lot endpoints is carried by the '[Group: Hellenistic: Brennan tradition]' tag rather than prose.

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

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

Usage is only implied: the agent must infer that this is the tool for the 15-lot Brennan set specifically. There is no statement of when to prefer this over astroway_hellenistic_hand_lots_of_seven or the Greenbaum lot endpoints, and no prerequisites beyond the required-field list.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that – a cost of 10 credits (Tier 1) and the POST endpoint – which an agent budgeting calls needs, but says nothing about result shape or cost-sensitive behavior beyond the flat price.

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

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

Four short lines with the purpose front-loaded and only machine-relevant metadata (group, endpoint, cost) following. No sentence is padded; the only mild inefficiency is that the bracket metadata is structured like tags 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?

With a rich input schema, an output schema, and full annotations, the description's omission of return-value detail is acceptable. The remaining gap is routing: in a namespace containing astroway_prognostics_profections and astroway_helb_profections_detail it never says what 'detail' adds or when this Brennan variant is the right choice.

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 embedded birth-data object is documented in exhaustive detail, so the baseline of 3 applies. The description contributes nothing about parameters, notably not explaining targetAge, the single required key that actually distinguishes this call from a plain natal chart.

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 phrase 'Annual profection year-lord with full classical condition' names a specific astrological computation and its scope ('full classical condition'), and the [Hellenistic: Brennan tradition] group tag separates it from greenbaum/schmidt/helb profection siblings. It is however a noun phrase with no verb, and it does not explicitly contrast with astroway_prognostics_profections or astroway_helb_profections_detail.

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 statement of when to prefer this over the other profection tools in the namespace. The 'annual' phrasing implies a yearly time-lord context but nothing tells the agent which sibling to pick for a non-Brennan or non-detail request.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely useful business context the annotations do not carry: the endpoint and a per-call cost of 10 credits (Tier 1). It says nothing about pagination, response shape, or how the combined output interleaves the three systems, but against annotations it is adequate.

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

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

One front-loaded sentence plus bracketed metadata; nothing is padded. It is arguably too terse, but every element present earns its place and the core purpose leads.

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

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

An output schema exists, so return values need not be described. But for a combined time-lord synthesis tool, the description leaves open what the stack actually reports and how targetAge interacts with the birth date, which is exactly the context an agent needs to call it instead of the three single-technique 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% and the nested birth-data schema is unusually detailed (timezone vs timezoneOffset rules, houseSystem letters, rejected short forms). The description adds nothing about parameters and does not explain the relationship between date and targetAge. Baseline 3 is correct when the schema does all the work.

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

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

It names the three techniques it merges (profection, ZR, decennials) and the input it works from (a date), so the general function is inferable. However, 'ZR' is an unexpanded abbreviation and the description never distinguishes this aggregate from the sibling tools that each deliver one of these techniques individually (profections_detail, zodiacal_releasing_*, hand_decennials). It states a purpose but does not let an agent cleanly separate it from its neighbours.

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 the individual profection/ZR/decennial tools as alternatives. An agent receiving this has to guess whether the combined stack or the single-technique sibling is the right call.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds two genuinely useful behavioral facts not in the annotations: the credit cost (10 credits, Tier 1) and the exact set of required inputs. It says nothing about output shape or determinism beyond what annotations imply.

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

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

The description is terse and front-loaded: the substantive sentence comes first and the bracketed metadata follows in scannable lines. Every line carries information (cost, endpoint, required inputs), though the body sentence is arguably under-specified rather than merely concise.

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 cost/required inputs are covered. However, for a 15-parameter calculation endpoint with only 33% schema coverage, the description leaves key optional parameters and the distinction from the near-identical helb sibling 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 description coverage is only 33% across 15 parameters, so the description is expected to compensate, but it merely re-lists the four required parameters (date, time, latitude, longitude) that the schema already marks required. It adds no meaning for the 11 optional parameters such as houseSystem, zodiacType, ayanamsa, or the compact-mode fields.

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 (triplicity rulers) with its tradition flavor (Dorothean) and the three rulership categories it returns (day/night/common), which is more informative than a bare name restatement. It does not, however, distinguish itself from the very similar sibling astroway_helb_triplicity_rulers, leaving the agent to infer the difference from the name 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 description contains no when-to-use guidance, no prerequisites, and no mention of alternatives such as astroway_helb_triplicity_rulers or astroway_dignities_almuten. Only the template metadata (required params, cost) hints at anything operational.

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. The description adds genuinely useful operational context absent from annotations: the cost tier (10 credits) and the endpoint/group membership. It does not explain computation behavior or how the periods are derived, but the annotation bar is met.

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

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

Purpose is front-loaded in a single clause, followed by bracketed metadata (group, endpoint, cost) that is compact and scannable. Nothing is wasted, though the body is arguably too thin to be ideal for a tool in such a crowded namespace.

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 input schema is comprehensive. The gaps are around disambiguation from the many ZR siblings and any sense of what the result is used for, which leaves the definition merely adequate for a specialized computation 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% and the birth-data schema is extremely well documented (formats, tz handling, houseSystem letters, rejection of short forms). The description adds no parameter-level information, so the baseline 3 for fully-covered schemas is correct.

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 technique (Zodiacal Releasing) and its source point (Lot of Fortune), and adds the derived subject matter ('body/livelihood periods'), which is enough to distinguish it conceptually from the Spirit-based sibling. However, it never names the near-duplicate siblings (e.g. astroway_helb_zodiacal_releasing_fortune, astroway_hellenistic_brennan_zodiacal_releasing_spirit), so an agent cannot separate the Brennan variant from the helb variant on the description 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?

There is no statement of when to use this tool versus the Spirit variant, the peak-periods sibling, or the helb duplicate. The description gives no context on what question the output answers or what prerequisites apply. Only the technique name implies usage.

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 readOnly/idempotent/non-destructive safety, so the bar is lower; the description adds genuinely useful behavioral facts not in any structured field — the credit cost (10 credits, Tier 1), the group/tradition, and the exact endpoint. It still says nothing about how long the computation spans or how ageing periods are resolved, so it stops short of a 5.

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

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

The technique and its domain are front-loaded in the first line, with metadata confined to bracketed lines. There is no filler prose, though the three metadata lines are boilerplate shared across the whole tool family rather than content specific to this 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?

With an output schema present and full schema coverage, return values and parameters need no further explanation. However, for a specialised time-lord technique with several near-identical ZR siblings, an agent is given no cue for choosing this one over the fortune/peak-period variants — the one gap that matters here is left unaddressed.

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

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

Schema description coverage is 100%, and the description adds no parameter meaning whatsoever — nothing about the required birth data, the optional 'years' horizon (default 80), or the compact-mode 'fields'/'precision' controls. Baseline 3 is the correct score when the schema carries the entire parameter burden.

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

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

The description names the exact Hellenistic technique ('Zodiacal Releasing from Lot of Spirit') and the domain it covers ('career/action periods'), which is a specific resource, not a tautology. The 'Spirit' qualifier implicitly separates it from the sibling zodiacal_releasing_fortune and zr_peak_periods tools, but the description never makes that contrast explicit.

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

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

The phrase 'career/action periods' implies the use case (career timing questions) but there is no explicit when-to-use/when-not guidance and no mention of the alternative ZR tools (fortune, loosing of bond, peak periods) that share nearly identical input signatures. Usage is left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered without the description. The description does add real value beyond the annotations by disclosing the cost (10 credits, Tier 1) and the transport endpoint, which the structured fields do not carry. It says nothing, however, about prerequisites (e.g. that a natal chart with a ZR sequence is required) or any rate/size constraints.

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 text is short, front-loaded with the core action, and contains no filler or repetition. The three bracketed metadata lines are compact and each carries distinct information, so nothing meaningful is wasted for the size given.

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?

This is an obscure Hellenistic technique paired with a bare one-line label; without any definition of Loosing of Bond or of the ZR (Zodiacal Releasing) sequence, an agent cannot know what the result signifies or when it is the right tool. An output schema does exist, so return values need not be explained, but the conceptual gap and the inability to separate it from the 'helb' twin remain serious omissions.

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 and houseSystem in unusual depth. The description adds nothing about the parameters (including the meaning of the 'years' field for ZR span), so the baseline 3 for fully documented 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?

The description names an action and resource ('Loosing of Bond detection within ZR sequence'), which is more specific than a tautology, but 'ZR' and 'Loosing of Bond' are unexplained jargon and the phrasing is close to restating the title. Critically, it makes no attempt to distinguish itself from near-identical siblings such as astroway_helb_zr_loosing_of_bond or astroway_hellenistic_brennan_zr_peak_periods, so an agent cannot route between them 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?

There is no when-to-use, when-not-to-use, or alternative-tool guidance anywhere in the description. The bracketed Group/Endpoint/Cost lines are operational metadata, not usage guidance. An agent must infer selection purely from the tool name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context — a 10-credit Tier 1 cost and the POST endpoint — but says nothing about what is computed, the technique's assumptions, or rate/limit behavior. No contradiction with annotations.

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

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

Very short and front-loaded: the resource line comes first, followed by structured metadata tags. Nothing is padded, though the metadata lines contribute more routing/tooling value than descriptive value, and the core sentence is doing minimal 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?

An output schema exists, so return values need not be described. However, for a specialized Hellenistic timing technique the description leaves the core question unanswered — what a peak period is, what the Lot-based angular-sign calculation yields, and how it relates to the ZR fortune/spirit/loosing-of-bond siblings. Input richness cannot compensate for an opaque purpose.

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 is unusually rich (timezone, timezoneOffset, houseSystem letters, field names are all documented inline), so the schema carries the parameter burden. The description adds nothing about parameters — notably it never mentions the `years` span (20-120, default 80) that shapes peak-period output. 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 ("Peak periods") and glosses the abbreviation ZR as "angular signs from Lot", which is slightly more than the bare title. But it never states a verb (compute/return/derive) and never explains what a "peak period" actually is in this technique, so an agent cannot tell what it produces. It also fails to distinguish itself from the many ZR-adjacent siblings (zodiacal_releasing_fortune, zodiacal_releasing_spirit, zr_loosing_of_bond).

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 statement, no prerequisites, and no mention of alternatives among the ZR siblings. The only routing-adjacent information is the [Group: Hellenistic: Brennan tradition] tag and the endpoint/cost metadata, which give context but not selection guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world behavior, so the safety profile is covered. The description adds genuinely useful non-annotation facts: the exact endpoint and a 10-credit cost. It does not disclose the response shape, but an output schema exists so that burden is reduced.

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-line summary followed by dense, front-loaded bracket metadata; nothing is wasted. The format is terse and scannable, though the summary line itself is quite thin.

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

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

With an output schema present and annotations covering safety, the description need not explain return values, and it does note cost and endpoint. Still, for a 15-parameter calculation tool with three enums and low schema coverage, it leaves the optional parameters and the distinction from sibling antiscia tools unexplained.

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 needs to compensate. Instead it merely repeats the four required parameters already declared in the schema and adds nothing about the eleven optional ones (houseSystem, zodiacType, fields, precision, ayanamsa, etc.). It adds no semantic value beyond structured data.

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

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

The description names a specific astrological technique (solstitial antiscia) within a named tradition (Hellenistic/Greenbaum), which is more specific than a tautology. However, it supplies no verb describing what is computed or returned, and it does not distinguish itself from near-identical siblings such as astroway_helg_antiscia_hellenistic or astroway_aspects_antiscia. Purpose is identifiable but underspecified.

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 use this tool versus the many antiscia-related siblings (astroway_aspects_antiscia, astroway_helg_antiscia_hellenistic, astroway_hellenistic_greenbaum_contra_antiscia). The bracket metadata gives operational facts (required params, cost, endpoint) but nothing about 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 readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so safety is covered. The description does add genuinely useful operational context the annotations lack: an explicit 10-credit Tier 1 cost and the POST endpoint. It says nothing about precision of results or what the computation covers, though.

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 bracketed metadata format is compact and front-loads the tool term, and the cost line is worth its space. However, the '[Required: ...]' line is pure duplication of the schema and the block contains no explanatory prose at all, so brevity here is achieved by omission rather than by tight writing.

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 in the description. Even accounting for that, a 15-parameter astrological computation tool with no statement of what it computes, no differentiation from near-identical siblings, and undocumented optional parameters is not complete enough for reliable selection or 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?

Only the four required parameters are listed, which merely repeats the schema's 'required' array. With 15 parameters and 33% schema description coverage, the description needed to explain the optional parameters such as cosmogram, zodiacType, houseSystem and the compact-mode fields, and it explains none of them.

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 is essentially a restatement of the name and title: 'Equinoctial contra-antiscia' names no verb, no output, and no scope of computation. The one distinguishing word, 'equinoctial', is left unexplained, so an agent cannot tell what is actually being calculated.

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 and no reference to alternatives, despite siblings like astroway_helg_contra_antiscia, astroway_helg_antiscia_hellenistic, and astroway_aspects_antiscia that an agent must choose between. The '[Group: Hellenistic: Greenbaum tradition]' tag gives weak routing context but 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's genuinely additive facts are the credit cost (10 credits, Tier 1) and the HTTP endpoint, which help an agent judge expense. It says nothing about sect handling, computational prerequisites, or whether ayanamsa/zodiacType materially change the result.

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 definition is short, front-loaded with the purpose line, and the bracketed metadata lines are scannable rather than prose padding. Slightly over-reliant on a structured block instead of explanatory sentences, but 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?

For a 15-parameter computation with an output schema present (so return values need no explanation), the description is still too thin: it never explains what the Daimon/Tyche axis is used for astrologically, how it relates to the duplicative sibling, or which of the many optional parameters actually matter. An agent has the mechanics but not the judgment needed to invoke it well.

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 carries real burden — yet it only restates the four required fields already declared in the schema's required array. The eleven optional parameters (city, name, cosmogram, zodiacType, houseSystem, ayanamsaId, etc.) receive no clarification, and the sidereal/tropical distinction is especially relevant for a Hellenistic tool and goes unmentioned.

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?

"Spirit-Fortune axis as primary chart spine" names a recognizable astrological construct, so the resource is identifiable, but there is no verb describing what is produced (compute? list? interpret?) and no indication of what the axis output means for the agent. It also fails to distinguish itself from the near-identical sibling astroway_helg_daimon_tyche_axis, which carries the same title-ish concept under a different prefix.

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 bracketed block states required inputs and cost but gives no when-to-use guidance, no prerequisites, and no routing advice relative to the many other Hellenistic lot/spine tools in the sibling list. An agent cannot tell from this text why it would pick this over astroway_helg_daimon_tyche_axis or the Greenbaum lots 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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds genuinely useful context beyond that — the POST endpoint, the four required inputs, and the 10-credit (Tier 1) cost — but says nothing about what the calculation produces or any preconditions.

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?

Very short and cleanly front-loaded, with the bracket block giving a scannable structure and no filler sentences. However, the brevity crosses into under-specification rather than tight writing, so it is efficient without being informative.

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 Hellenistic calculation with sidereal/house-system options and an output schema, an agent needs to know what is being computed and under which frame; the description supplies none of that. The existence of an output schema excuses it from describing return values, but it is still too thin for the tool's complexity.

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

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

Schema coverage is only 33% across 15 parameters, so the description should compensate, but all it offers is '[Required: date, time, latitude, longitude]', which merely restates the schema's own required array. It adds no meaning for the eleven optional parameters (zodiacType, houseSystem, ayanamsa/ayanamsaId, precision, cosmogram, etc.).

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 text 'Dodecatemoria sub-divisions of zodiac' essentially restates the tool name/title with a dictionary gloss; it contains no verb and never says what the tool actually computes or returns (e.g. dodekatemoria placements for a chart). It also does nothing to distinguish this from near-neighbor siblings like astroway_hellenistic_greenbaum_duodecima or astroway_helg_zodiacal_decans.

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 statement and no named alternative or exclusion. The only context is the bracket metadata (group/endpoint/required/cost), which is operational plumbing rather than guidance about when this tool is the right choice over its several Hellenistic subdivisions siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new operational facts — cost of 10 credits (Tier 1) and the endpoint — but says nothing about return shape, edge cases, or what a call produces beyond the concept label. Modest added value over annotations.

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

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

The concept is front-loaded in the first line and the bracketed metadata block is scannable with zero filler. It is tight, though arguably too terse for a 15-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 15-parameter tool with three enum sets and a close sibling, the description is far too thin: no usage context, no differentiation, no parameter explanation. An output schema exists so return values need not be described, but the input-side and selection-side gaps remain substantial.

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 carries a heavy burden and does not meet it. It merely restates the four required fields already listed in the schema, and explains none of ayanamsa, zodiacType, houseSystem, timezone, 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 fragment 'Duodecima: 2.5° micro-sign per planet' names the technique and its output granularity but contains no verb describing the operation and relies on specialized jargon. It fails to distinguish itself from the sibling astroway_hellenistic_greenbaum_dodekatemoria, which the agent will likely confuse with it. Purpose is implied rather than stated.

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 guidance on when to use this tool versus the very similar dodekatemoria sibling, nor any prerequisite or context statement. The bracket summary supplies required fields and cost but nothing about 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 and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-schema context: the endpoint, the required inputs, and a 10-credit Tier 1 cost. It still says nothing about what 'conditions analysis' computes or any auth/rate constraints.

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 sentence is front-loaded and the bracketed metadata block is compact and scannable, with no redundant prose. It is efficiently sized for the information it actually conveys.

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 for a 15-parameter Hellenistic calculation with 33% schema coverage, no explanation of the parameters, no differentiation from the Greenbaum/HELG twins, and an undefined 'conditions analysis' scope, the definition is not complete enough to invoke 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 description coverage is only 33% across 15 parameters, so the description should compensate; instead it merely restates the four required fields, which the schema's required array already declares. Undocumented options like ayanamsa, houseSystem, zodiacType and fields get no explanation.

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?

It names a resource (Eros lot) and a computation, so the agent knows it produces an Eros-related chart output. However, "conditions analysis" is undefined jargon, and nothing distinguishes it from near-duplicate siblings such as astroway_helg_lot_of_eros_detail or astroway_hellenistic_hand_lots_of_seven.

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 routing among the many Hellenistic lot tools. The presence of a near-identical astroway_helg_lot_of_eros_detail sibling makes the absence of differentiation especially costly.

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/no-open-world, so the safety profile is covered. The description adds genuinely useful behavior context — cost (10 credits, Tier 1) and the coarse endpoint — but says nothing about what the response contains or any limits. Nothing contradicts the annotations.

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

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

The description is short and the bracketed metadata is easy to scan, but the one prose sentence carries almost no information while the blocks relay facts (group, endpoint, cost) that mostly duplicate the tool name and schema. It is compact without being informative.

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 a full output schema, the description omits the two things that matter most: what 'quality of time' actually returns and how it differs from astroway_helg_quality_of_time. An output schema exists so return values needn't be described, but purpose and sibling disambiguation are 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 only 33% across 15 parameters, so the description should compensate — instead it merely repeats the four required parameters (date, time, latitude, longitude) already marked required in the schema and adds nothing about the 11 optional ones (ayanamsa, timezone, houseSystem, zodiacType, fields, precision). With low coverage, this leaves a large semantic 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 says only 'Synchronistic quality of a moment,' which essentially restates the name/title ('Quality of Time') without stating what the tool computes or returns. The Greenbaum group label and endpoint give some framing, but an agent cannot tell what output it would get, and it is indistinguishable from the near-identical sibling astroway_helg_quality_of_time.

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, or alternative guidance is provided. With siblings like astroway_helg_quality_of_time and the electional/muhurta tools in the catalog, the agent has no instruction on which 'quality of time' variant to select or when this one applies.

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 behavioral facts the annotations lack: a cost of 10 credits (Tier 1) and the POST endpoint. However it says nothing about what the operation evaluates or how expensive/large the result is; the cost line is the only substantive addition. The POST endpoint alongside readOnlyHint=true is unusual but not a contradiction, since POST is a transport detail rather than a side-effect claim.

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?

Very short and scannable, with the bracketed metadata lines front-loading group, endpoint, required params, and cost in a consistent format. The trade-off is that the brevity reflects under-specification rather than efficient compression: the opening line carries almost no information and no sentence explains the tool's actual behavior.

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 is far too thin. An output schema exists, so return values need not be explained, but the description never clarifies which branch parameters (zodiacType tropical vs sidereal, ayanamsa, houseSystem) matter for this Hellenistic technique, nor how it differs from the sibling helg_sphaera_barbarica duplicate.

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 two-thirds of the 15 parameters (zodiacType, houseSystem, cosmogram, name, city, and others) are undocumented in both schema and description. The description's only parameter content is '[Required: date, time, latitude, longitude]', which merely restates the schema's required array and adds no syntax, format, or default guidance. 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 is a four-word gloss of the Latin name ('Constellations beyond the zodiac') with no verb and no statement of what computation or output the tool produces. An agent cannot tell from this whether the tool returns paranatellonta/extra-zodiacal star risings, a text passage, or a rendering. It also does nothing to distinguish itself from the near-identical sibling astroway_helg_sphaera_barbarica.

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, or alternative-tool guidance appears anywhere. The only routing signal is the bracketed '[Group: Hellenistic: Greenbaum tradition]' label, which hints at the tradition family but does not say why an agent would pick this over the Brennan, Schmidt, Hand, or helg variants, nor over the duplicate helg_sphaera_barbarica.

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