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

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

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

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

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

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

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

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

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

Schema description coverage is 100%, so every one of the six parameters is already documented in the schema, including the format enum and the select/fields/precision semantics. The description restates the format option rather than adding new meaning, so the baseline 3 for full schema coverage applies.

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

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

The description states a specific verb and resource: returning agent tool definitions generated from the live OpenAPI document, in either OpenAI or Anthropic shape. That is clear enough to differentiate it from report/chart tools in the namespace, but it never names the closest sibling (astroway_mcp_tools_list) or explains the distinction, so it falls short of a 5.

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

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

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

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

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

Annotations already declare 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 a safe read-only, idempotent, non-destructive, closed-world call, so the safety profile is covered. The description adds genuinely new behavioral context the annotations cannot carry: it is a metered call at 10 credits (Tier 1), and it is an alias rather than a distinct operation. It does not discuss response shape, but an 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?

Front-loaded single-line purpose followed by compact bracketed metadata (group, cost, alias). Every line carries information and there is no filler; the alias parenthetical is slightly meta but saves an agent from double-invoking the canonical 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?

Because an output schema exists, the description need not describe return values, and the annotations cover safety. What is still missing for a specialized 15-parameter Hellenistic calculation is any indication of what the nine categories contain or what input precision the technique expects, leaving the agent reliant on the schema and outside knowledge.

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 contributes nothing about any parameter — no mention of date/time format, coordinates, timezone handling, ayanamsa, house system, or the `fields`/`precision` compact-mode options. The four required parameters are largely self-explanatory from their names and patterns, but the description does not compensate for the documented 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?

Names a specific technique (planetary bonification/maltreatment conditions per Valens) and states its scope (9 categories), and the alias line ties it explicitly to the canonical `astroway_hellenistic_brennan_bonifications_maltreatments` sibling. It is distinguishable from the surrounding Hellenistic/Brennan tools, though 'planet conditions' remains somewhat jargon-dependent for an agent unfamiliar with the doctrine.

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

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

No explicit when-to-use or when-not-to-use guidance versus alternatives such as dignities, joys of planets, or the other Brennan-tradition tools. The '[Group: Hellenistic: Brennan tradition]' tag implies context, and the alias note tells the agent this tool is interchangeable with its canonical sibling, which is a partial routing signal rather than real usage guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds two facts not present in structured data – the 10-credit Tier 1 cost and the tradition grouping – plus the depth hint 'full classical condition'. It says nothing about targeting a specific profection year or how the result is shaped, so with annotations carrying the safety burden a 3 is fair.

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 substantive line is front-loaded and short, with metadata tags on separate lines that do not interrupt reading. The cost and alias notes are compact and earn their place as routing aids. No filler 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 an output schema present, the description is not obliged to explain return values, and it identifies the calculation performed. However, it never connects targetAge to the profection year being computed – the key input for this tool – and gives no hint about the scope of 'full classical condition' output. Adequate but with a clear gap for an agent to invoke it 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 100%, so the nested birth-data block, fields and precision params are already documented in the schema, including the timezone/offset and houseSystem caveats. The description adds no parameter-level meaning of its own, which is the expected baseline 3 when the schema does the heavy lifting. Notably targetAge, the one field that distinguishes this from a generic natal chart, is left to the schema.

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

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

Names a specific resource – the annual profection year-lord with its full classical condition – which is a concrete astrological deliverable rather than a restatement of the title. It also discloses that it is an alias of astroway_hellenistic_brennan_profections_detail, helping the agent recognize the duplicate. It stops short of distinguishing this from sibling profection tools such as astroway_prognostics_profections, so differentiation is only partial.

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 versus the canonical astroway_hellenistic_brennan_profections_detail or the other profection/prefection tools. The group tag '[Hellenistic: Brennan tradition]' hints at the school but gives no selection criteria. The alias note implies interchangeability but never says to prefer one over the other.

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 adds the tradition grouping and the 10-credit/Tier 1 cost, which is real behavioral context an agent can act on for budget decisions, but it discloses nothing about the computed output, determinism of results, or data requirements.

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

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

Two short bracketed metadata lines plus a one-line purpose — tightly sized and front-loaded with no filler. It is terse rather than verbose, though the metadata lines consume most of the available space where substantive content could have gone.

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 low schema description coverage, the description is far too thin: no input guidance, no when-to-use, no note on how the day/night/common variant is chosen (presumably from chart sect). An output schema exists, so return values need not be explained, but the rest of the burden is unmet.

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 the only place left to explain inputs — and it says nothing about any of them. The four required fields (date, time, latitude, longitude) and the many optional chart modifiers (zodiacType, houseSystem, ayanamsa, fields, precision) are left entirely to the partial schema, which does not 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?

The line 'Dorothean triplicity rulers (day/night/common)' names a specific Hellenistic technique and its three sect variants, so an astrologically literate agent can tell it apart from siblings like hand_bounds or decanic_rulers. However, it is essentially a restatement of the title with no verb — it never says what the tool computes or returns (e.g. the triplicity lord per planet/sign), leaving purpose inferred from jargon 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 statement of when to use this technique versus alternatives (e.g. almuten, bounds, sect strength) and no prerequisites. The only routing help is the parenthetical noting it is an alias of `astroway_hellenistic_brennan_triplicity_rulers`, which is useful for de-duplication but is not usage guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description adds genuinely useful context beyond that — the 10-credit cost tier and the Brennan-tradition grouping — but discloses nothing about the returned period structure or how the 80-year default horizon affects output.

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 short, front-loaded lines with no filler; the technique and interpretive domain come first. Slightly under-specified rather than verbose, but nothing wastes 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?

With an output schema, complete annotation coverage, and fully-described parameters, the structured fields carry most of the burden. The remaining gap is routing guidance among the many close Hellenistic ZR siblings, which the description does not address.

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%; the nested birth-data object, `fields`, and `precision` are all thoroughly documented in the schema itself. The description adds no parameter semantics, 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?

Names a specific technique verb+resource: 'Zodiacal Releasing from Lot of Fortune' with the interpretive domain ('body/livelihood periods'). This distinguishes it reasonably from the sibling ZR-from-Spirit tools, though the distinction is implicit in 'Fortune' rather than stated. The alias note clarifies its relationship to the canonical tool name.

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

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

No when-to-use guidance is given. It does not tell the agent when to pick this over `..._zodiacal_releasing_spirit`, `..._zr_loosing_of_bond`, or `..._zr_peak_periods`, nor what question the Lot of Fortune periods answer versus the Spirit lot. The alias line explains naming, not 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 declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds genuinely useful operational context — the 10-credit Tier 1 cost and the canonical-vs-alias relationship — but says nothing about computation basis, period depth, or what the 'years' horizon affects.

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 front-loaded lines with no filler: what it computes first, then grouping, cost, and alias identity. The bracketed tag format is dense and scannable; 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?

An output schema exists and annotations fully cover safety, and the input schema is richly self-documenting, so the description need not explain returns. What is missing is the disambiguation an agent needs among the clustered ZR siblings, which is the main residual gap.

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

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

Schema description coverage is 100% and the nested birth-data object documents formats, timezone handling, rejected short forms and houseSystem letters in detail. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific technique and resource ('Zodiacal Releasing from Lot of Spirit') plus the interpretive domain ('career/action periods'), and identifies itself as an alias for astroway_hellenistic_brennan_zodiacal_releasing_spirit. It does not, however, distinguish itself from the close sibling astroway_helb_zodiacal_releasing_fortune, leaving the Spirit-vs-Fortune choice implicit.

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

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

'career/action periods' implies the topical context in which to reach for this tool, but there is no explicit when-to-use, when-not, or named alternative even though two near-identical siblings (zodiacal_releasing_fortune, zr_peak_periods) exist. Usage is inferable rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds useful operational context — the credit cost and tier — plus group/tradition provenance and the alias mapping, which helps routing. It does not describe what the detection output means, but that is largely covered by the output schema.

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

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

Four short bracketed fragments, front-loaded with the purpose first followed by metadata. Minimal waste, though the bracketed tags read more like internal metadata than agent-facing guidance.

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

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

With an output schema present and 100% parameter coverage, the description need not explain returns or inputs. It supplies cost, tradition group, and alias mapping, which is enough context to invoke correctly, though the astrological meaning of 'loosing of bond' is left 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 100% and the nested birth-data schema is thoroughly documented, so the schema carries the full parameter burden. The description adds no parameter-level meaning beyond that; 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 resource and action: detecting the 'Loosing of Bond' within a ZR (Zodiacal Releasing) sequence. However, it doesn't distinguish itself from close siblings like astroway_hellenistic_brennan_zr_peak_periods or the ZR releasing tools beyond noting it is a renamed alias, and 'Loosing of Bond' is jargon an agent may not interpret.

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

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

No when-to-use guidance, no exclusions, no routing to alternatives. The agent learns it concerns ZR sequences but nothing about when this tool should be selected over the sibling ZR peak-periods or zodiacal-releasing 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?

With readOnlyHint/idempotentHint/destructiveHint already covering the safety profile, the description's useful addition is the cost disclosure (10 credits, Tier 1) and the group membership. It says nothing about what the computation actually produces or any input constraints beyond the schema, so it adds modest 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?

Very compact and front-loaded: the core statement comes first, followed by clearly delimited bracket metadata tags. The alias parenthetical is worth its space for disambiguation. Nothing extraneous.

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

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

An output schema exists, so return values need not be explained. Still, for a 15-parameter specialist tool with heavy sibling overlap and 33% schema coverage, the description does not give enough to guarantee correct invocation — chiefly which antiscia variant to pick and how the required inputs should be formed.

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 four required inputs (date, time, latitude, longitude) have no descriptions anywhere. The description supplies no parameter meaning at all, so 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 resource ('antiscia') qualified by 'solstitial' and 'Hellenistic conventions', which is more than a tautology of the title. It does not, however, distinguish itself from the neighboring astroway_aspects_antiscia or astroway_helg_contra_antiscia tools, so an agent still has to guess which antiscia variant applies.

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 note ('Cursor-friendly alias for ...') is genuine routing guidance — it tells the agent which of two equivalent tools to prefer in a Cursor context. But there is no when-to-use/when-not guidance against the other antiscia siblings (aspects_antiscia, contra_antiscia), so usage remains implicit.

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 two genuinely useful behavioral facts not in annotations: the tradition group (Hellenistic: Greenbaum) and the cost (10 credits, Tier 1). It adds nothing about computation inputs, failure modes, or rate limits, but with annotations carrying the safety burden a 3 is warranted.

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 and front-loaded, and the bracketed metadata lines are easy to scan. However, the brevity is under-specification rather than disciplined conciseness: there is no sentence that explains purpose, usage, or behavior, so the size reflects missing content rather than efficient 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-value explanation is not required, and annotations cover safety. But for a 15-parameter chart computation with 33% schema coverage and multiple near-identical sibling tools (antiscia, contra-antiscia, aspects_antiscia), the description leaves the agent unable to tell what distinguishes this computation or how to supply the undocumented inputs.

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 carries an obligation to compensate for the undocumented parameters, and it supplies none. The schema does document a few key params (fields, ayanamsa, timezone, precision, timezoneOffset), but the required date/time/latitude/longitude and several others remain unexplained, and the description adds no syntax or format guidance.

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 title 'Contra-Antiscia' with an 'Equinoctial' qualifier. It names the astrological resource but gives no verb (compute/derive) and never explains what contra-antiscia are or what the tool returns, so it is near-tautological against the name/title. The alias note identifies equivalence with the long-named sibling but does not distinguish this tool from astroway_aspects_antiscia or astroway_helg_antiscia_hellenistic.

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 at all. The only routing information is that this is a 'cursor-friendly alias' for astroway_hellenistic_greenbaum_contra_antiscia, which implies interchangeability but does not tell the agent when to prefer this over that sibling or over the antiscia variants. No prerequisites or exclusions are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new context—Hellenistic Greenbaum tradition grouping and cost (10 credits, Tier 1)—which is useful for budgeting, but says nothing about prerequisites or output structure.

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 brief and front-loaded with the core statement, followed by compact bracketed metadata. It is efficient, though the alias line and tags consume space without aiding invocation.

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 a 15-parameter chart tool with 33% schema coverage and no usage guidance is under-described. Nothing tells the agent how the many optional parameters interact or what makes this result meaningful versus sibling Hellenistic 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?

With 15 parameters and only 33% schema description coverage, the description should compensate but contributes nothing about any parameter. Required date/time/latitude/longitude, sidereal options (ayanamsa, zodiacType), and houseSystem choices are left entirely to the schema, and many are undocumented even there.

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" identifies the resource (the Daimon/Tyche axis, i.e. Spirit-Fortune) and implies a computation, but there is no verb and "as primary chart spine" is domain jargon an agent may not parse. It loosely matches the title/sibling name without clarifying what it computes or returns.

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 given. The only routing-style content is the note that it is a cursor-friendly alias for `astroway_hellenistic_greenbaum_daimon_tyche_axis`, which tells the agent it is a duplicate rather than when to prefer 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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful operational context not in the annotations: the tradition group and the 10-credit Tier 1 cost, which affects call budgeting. However, it never describes what "conditions analysis" computes or what the response 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 prose is a single front-loaded sentence, and the group/cost/alias lines are structured metadata that scan quickly. It is not padded, though the extreme brevity borders on under-specification rather than true conciseness.

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 computationally complex tool with 15 parameters (4 required), three enums, and low schema coverage, the description is far too thin. It omits parameter usage, output shape, and any indication of what "conditions analysis" yields; the presence of an output schema excuses return-value detail but not the missing usage and parameter context.

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

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

Schema description coverage is only 33% across 15 parameters, so the description must compensate and does not. It provides no explanation of the required date/time/latitude/longitude, nor of how the sidereal/ayanamsa or house-system options affect the Eros result, so it adds nothing beyond the schema.

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

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

"Eros calculation with conditions analysis" names a resource (the Lot of Eros) and adds a scope hint (conditions analysis), but it largely restates the title "Lot of Eros Detail." It does not say what a "Lot of Eros" is or how it differs from sibling Hellenistic lots such as daimon_tyche_axis or lots_of_seven, leaving the agent to infer.

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 alternatives, no prerequisites beyond the required inputs, and no exclusions. The only routing help is the note that it is an alias for the longer-named Greenbaum tool, which tells the agent about the name relationship but not the use case.

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

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

Annotations already declare this read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds nothing behavioral: no note on determinism, whether the same moment always yields the same reading, what the output contains, or what 'quality of time' actually returns. For a computation tool of this type that gap is significant.

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 but wastes its few tokens on cost tier and group taxonomy while omitting the actual purpose. It is front-loaded with a vague phrase and then spends its budget on metadata rather than task-relevant content.

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

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

With an output schema present, return values need not be explained, but the description should still convey what this Greenbaum technique computes and when it applies. It provides only a tag line plus billing/group info, leaving an agent unable to distinguish this from the many other Hellenistic quality/timing tools without opening schemas.

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?

Four required parameters (date, time, latitude, longitude) are self-evident from names and schema constraints, and the schema documents timezone, ayanamsa, and precision in depth. However, 33% schema coverage means roughly two-thirds of the 15 params, including houseSystem, zodiacType, and cosmogram, carry no description anywhere; the description does nothing to compensate.

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

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

The one-line purpose, 'Synchronistic quality of a moment', is cryptic jargon that doesn't state what computation occurs or what the agent gets back. It restates the title rather than describing a verb+resource. The only concrete information is administrative (group/cost) and the alias relationship, which is structural metadata, not purpose.

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 canonical astroway_hellenistic_greenbaum_quality_of_time, nor versus siblings like the daimon/tyche, sect, or planetary-hours tools. The alias note tells the agent the tool exists but not when to prefer it, and no conditions, prerequisites, or exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description's one genuine addition is operational: 'Cost: 10 credits (Tier 1)', which is not in any structured field and matters for budgeting calls. It says nothing about output content, precision defaults, or why an ayanamsa/houseSystem would matter here.

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?

It is short with no filler, and the metadata lines (group, cost, alias) are scannable. But the brevity is largely under-specification rather than efficiency: the lead line is a noun fragment and no sentence actually describes a callable operation.

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 description coverage, the definition omits what the result contains (beyond the existing output schema), how the required moment inputs should be supplied, and how this technique relates to its many Hellenistic siblings. Group, cost, and the alias are present, but the core question of what calling this produces is left unanswered.

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

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

The schema covers only 33% of 15 parameters, and the description adds zero parameter meaning. Undocumented fields such as `name`, `city`, and `cosmogram` remain ambiguous, and the description does not clarify that date/time/latitude/longitude are mandatory birth-moment inputs or how zodiacType/ayanamsa interact with a sidereal constellation technique. With low coverage, the description is expected to compensate and does not.

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

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

The fragment 'Constellations beyond the zodiac' conveys the domain (extra-zodiacal constellations in the Greenbaum Sphaera Barbarica tradition) but names no verb, no output, and no computation, so an agent cannot tell what it actually returns. It does explicitly identify itself as an alias of `astroway_hellenistic_greenbaum_sphaera_barbarica`, which resolves duplication against that one sibling, but nothing distinguishes it from the other Hellenistic Greenbaum tools aside from the group tag.

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 comparison to related Hellenistic tools (zodiacal_decans, temple_doctrine, dodekatemoria). The only routing hint is the alias note, which tells the agent it is interchangeable with the canonical Greenbaum endpoint rather than when this technique is the right one.

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 a closed-world operation, so the safety profile is fully covered. The description adds genuinely new context in the pricing line (10 credits, Tier 1) and the group tag, but says nothing about computation prerequisites or what 'assignments' produce.

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, and every element (substance line, group, cost, alias) is a distinct fact with no filler. It is efficient, though the efficiency partly reflects that little substantive information was included.

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 astrological computation tool, the description omits what the doctrine output contains, how the required time/place inputs drive the result, and when the tool applies. An output schema does exist, which excuses not restating return values, but the input and selection guidance remain too thin.

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

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

The schema has 15 parameters with only 33% description coverage, yet the description mentions no parameter at all. The required date/time/latitude/longitude contract and the sidereal options (ayanamsa, zodiacType) go undiscussed, leaving the description unable 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?

The description names a specific resource (temple-house assignments) and attributes it to the Greenbaum tradition, which helps distinguish it from the Brennan/Schmidt/Hand Hellenistic siblings. However, 'temple-house assignments' is never explained, so an agent that lacks domain knowledge cannot tell what is actually computed or returned. It is a labeled purpose rather than a described one.

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

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

There is no statement of when to use this tool versus alternatives. The only routing information is the note that it is an alias for astroway_hellenistic_greenbaum_temple_doctrine, which tells the agent the two are equivalent but not which one to pick or in what situation the doctrine 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful non-annotation context – the 10-credit Tier 1 cost and the tradition grouping – but says nothing about what is computed or how the result is scoped.

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, with no filler prose; the bracket metadata and alias note are compact. It errs on the side of under-specification rather than verbosity, but structurally it is clean.

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 chart tool with an output schema and strong annotations, the description is far too thin: it omits what the decans/attributions actually are and gives no parameter guidance. The output schema excuses it from explaining return values, but the input-side complexity is 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% across 15 parameters, so the description must compensate for undocumented fields (city, name, cosmogram, zodiacType, houseSystem, ayanamsaId, date, time, lat/long). It adds no parameter meaning whatsoever, leaving half the surface unexplained.

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 "Zodiacal decans with attributions" largely restates the tool name and title, though "with attributions" hints at returned content and the [Group: Hellenistic: Greenbaum tradition] tag situates it. It never states the operation (is it computing, listing, or looking up decans?) or distinguishes itself from the many sibling decan/hellenistic tools. Adequate but vague.

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

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

No when-to-use guidance is given: no conditions for choosing this tool, no exclusions, and no reference to alternatives. The only pointer is the note that it is a cursor-friendly alias for astroway_hellenistic_greenbaum_zodiacal_decans, which clarifies naming rather than 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only the credit cost and the count of output categories, disclosing nothing about what the 9 categories contain, how conditions are judged, or what triggers a bonification versus a maltreatment.

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 and front-loads the substantive clause before the bracketed metadata. But the brevity is under-specification rather than economy: for a 15-parameter tool it omits information an agent genuinely needs.

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 with 15 parameters, 33% schema coverage, no usage guidance, and no behavioral detail, the definition is far too thin for a tool of this complexity, especially with a same-named sibling in another prefix group.

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 — yet it explains none of them. It does not clarify required birth data, the compact 'fields' mode, ayanamsa/zodiac selection, or the timezone vs timezoneOffset interaction, leaving roughly ten parameters undocumented 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 domain output ('Planet conditions per Valens: 9 categories'), which tells an agent this is a Hellenistic bonification/maltreatment analysis rather than a chart or aspect tool. However, it lacks a clear verb and never distinguishes itself from the near-identical sibling astroway_helb_bonifications_maltreatments, so an agent must rely on the name alone to choose between them.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of when to prefer this over the parallel helb_* or greenbaum variants. The '[Group: Hellenistic: Brennan tradition]' tag gives faint tradition context but stops short of routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-annotation context — the 10-credit Tier 1 cost and the tradition grouping — but says nothing about what the computation returns or any constraints on the input chart.

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

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

Two short, front-loaded lines with structured bracketed metadata; nothing is padded. It is efficient, though the brevity edges toward under-specification rather than optimal density.

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

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

An output schema exists, so return values need not be described, and annotations cover safety. However, for a 15-parameter chart-computing tool the description should at minimum clarify that it consumes birth data and what distinguishes its output from the sibling Brennan/Hellenistic tools — that gap is unfilled.

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 contributes zero parameter information. The four required inputs and the numerous optional chart/formatting flags (zodiacType, houseSystem, cosmogram, name, city) are left entirely to the schema, which documents only a handful 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 names a specific concept ('Classical planetary joys') and gives a concrete example mapping ('Sun-Leo-9th'), but it never states what the tool actually does — return a static reference table or compute the joys for the supplied birth data. The required chart parameters (date, time, latitude, longitude) sit in tension with the table-like example, leaving the action ambiguous. It also does not distinguish itself from the many sibling hellenistic_brennan tools.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternative. The '[Group: Hellenistic: Brennan tradition]' tag hints at a family of related tools but gives no condition for choosing this one over, say, triplicity_rulers or 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, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds the credit cost (10 credits, Tier 1), which is genuinely useful behavioral context an agent cannot get from annotations, but it says nothing about what the 15 lots contain or how results are shaped.

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

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

Two short lines with zero filler; the substantive claim is front-loaded. It is arguably under-specified rather than verbose, but nothing in the text 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 tool with only 33% schema coverage, the description should at minimum say what input it needs (birth date/time/place) and what the 15 lots represent. With an output schema present it need not describe return values, but the input and conceptual gaps leave an agent under-equipped.

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 contributes nothing about parameters. Fields like city, name, cosmogram, zodiacType, houseSystem and ayanamsaId have neither schema descriptions nor description-level explanation, so the description 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?

The description names a specific deliverable — 'All 15 Hermetic Lots per Brennan §11' — and the group tag situates it in the Brennan tradition, distinguishing it at the family level from the Greenbaum/Hand lot variants in the sibling list. It lacks a verb (compute/derive) and never directly names a competing sibling, but the resource is unambiguous.

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

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

There is no when-to-use guidance, no prerequisites, and no routing to alternatives such as astroway_hellenistic_hand_lots_of_seven or astroway_aspects_arabic_parts. The only auxiliary text is credit cost and group membership, which do not help an agent choose this tool over a sibling.

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 by structured data. The description contributes non-annotation operational context in the form of the credit cost ('10 credits, Tier 1'), but says nothing about the targetAge semantics, computation behaviour, or what 'full classical condition' entails.

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 plus two bracketed metadata tags — no filler, nothing repeated from the schema. It is efficient, though arguably at the cost of the guidance an agent needs.

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 input schema is exhaustively documented, which lowers the bar. What remains missing is the routing context (which profection tool to use when) and any note on what targetAge drives, which for a niche Hellenistic technique would meaningfully help an agent call it correctly.

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

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

Schema description coverage is 100% with a very detailed body schema (formats, rejected short forms, timezone handling, house-system letters), so the schema carries the burden. The description adds no parameter meaning of its own; 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 one-line description names a specific technique and output ('Annual profection year-lord with full classical condition'), which is clearer than a bare tautology. It does not, however, distinguish itself from near-identical siblings such as astroway_helb_profections_detail, astroway_prognostics_profections or astroway_hellenistic_hand_perfections, so an agent cannot tell which profection variant to pick from 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 when-to-use, when-not-to-use, or alternative-tool guidance. The [Group: Hellenistic: Brennan tradition] tag is a taxonomy label, not a routing instruction, and it is the only thing helping the agent choose among the several sibling profection 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 and destructiveHint=false, so the safety profile is covered. The description adds the credit cost (10, Tier 1) and tradition grouping, but says nothing about what 'combined' means operationally — whether the three systems are aligned into one timeline or returned separately, or whether targetAge drives the stack.

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

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

Two short lines with the core purpose front-loaded and no filler; the bracket tags are compact metadata. It is arguably under-specified rather than padded, but every sentence present earns its place.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Still, for a niche technique-stacking tool the description never explains what the stack contains or how the three lord systems combine, leaving an agent to guess at the value of the combined call.

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 nested birth-data object, date/time/lat/lon requirements, ayanamsa, timezone handling, and the fields/precision compact-mode switches are all already documented in the schema. The description adds no parameter-level meaning beyond that, 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?

Names a specific composite resource — a combined time-lord stack of profection, ZR and decennials for a date — which is more specific than most siblings such as astroway_prognostics_profections or astroway_hellenistic_hand_decennials. It does not, however, clarify how this differs from calling those individual tools, and 'ZR' is left unexpanded for non-specialists.

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 combined stack versus the standalone profection, zodiacal-releasing or decennial siblings in the same family. The only scoping hint is the '[Group: Hellenistic: Brennan tradition]' tag, which is categorization rather than usage guidance.

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

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds a small factual note that three rule sets (day/night/common) are produced, but discloses nothing about how sect is determined, what body/chart is used, or output shape. With annotations doing the heavy lifting, this is a modest 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?

Extremely short and front-loaded: the technique is stated in the first phrase and metadata is bracketed separately. It earns its place without padding, though brevity here costs it elsewhere.

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 natal-chart computation with an output schema, the description is far too thin. It omits inputs, sect logic, and output contents. The output schema relieves it of explaining return values, but the usage-relevant context for a chart-based tool is essentially absent.

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

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

Schema description coverage is only 33% across 15 parameters, so the description is expected to compensate and does not. It says nothing about date, time, latitude, longitude, timezone, houseSystem, or the compact-mode fields/precision parameters. The one substantive behavioral element it could clarify (day vs night derived from the timestamp/location) is left entirely implicit.

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 astrological technique (Dorothean triplicity rulers) with day/night/common variants, so the resource is identifiable. But it never says what the tool does with birth data (compute rulers for a chart), and it does not distinguish itself from close siblings like astroway_helb_triplicity_rulers or the Hellenistic dignity/rulership tools. The name carries most of the 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?

No when-to-use guidance at all. It doesn't say this returns the triplicity sect rulers for a natal chart, nor when to prefer it over astroway_dignities_essential_dignities or the Schmidt/Hand Hellenistic siblings. The only other text is group/cost metadata, which is not usage guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds the billing tier (10 credits) and tradition grouping, which is genuinely useful, but says nothing about how the periods are computed or what the `years` window governs.

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 terse lines with the technique and scope front-loaded; no filler. The brevity is efficient rather than padded, though it leans on metadata brackets for the rest.

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?

Annotations, a rich input schema, and an output schema cover most of the burden, so the description needn't explain return values. Still, for a specialist Hellenistic timing technique it offers no interpretation context, no period semantics, and no sibling routing, leaving the agent with minimal grounding.

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 object carries extensive documentation (date/time formats, timezone handling, rejected short forms, house-system letters). The description adds nothing parameter-specific, 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 (Zodiacal Releasing from the Lot of Fortune) and its domain (body/livelihood periods), which semantically distinguishes it from the sibling astroway_hellenistic_brennan_zodiacal_releasing_spirit. It stops short of explicitly contrasting the two, but an agent can tell what this computes.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternative. With a Spirit-variant sibling and ZR peak-period/loosing-of-bond siblings in the same family, the agent is left to infer routing from the tool name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful non-schema context - the cost (10 credits, Tier 1) and the Brennan-tradition grouping - but says nothing about what the computation consumes or produces beyond what the schema and output schema carry.

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

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

Three short, front-loaded lines with no filler; the purpose leads and the tradition/cost tags are compact metadata. Slightly terse in a way that leaves gaps, 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?

With an output schema and full annotation coverage, the description need not explain return values, and it correctly signals technique and cost. However, for a technical Hellenistic calculation it omits any indication of when the technique is appropriate or how it relates to the Fortune-based sibling, leaving a real gap.

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

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

Schema description coverage is 100%, so body/fields/precision are already fully documented in the schema, including the detailed birth-data and compact-mode notes. The description adds no parameter-level meaning, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific technique (Zodiacal Releasing from the Lot of Spirit) and the domain it addresses (career/action periods), which meaningfully distinguishes it from the sibling zodiacal_releasing_fortune variant. It stops short of explicitly naming that sibling or stating the Spirit-vs-Fortune contrast outright.

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

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

No when-to-use guidance, no prerequisites, and no alternatives are named despite several closely related siblings (zodiacal_releasing_fortune, zr_peak_periods, zr_loosing_of_bond). The agent is left to infer selection purely from the technique 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only the tradition grouping and a credit cost (10 credits, Tier 1), which is genuinely useful non-schema information, but says nothing about the shape or scope of the detection result. With annotations carrying the behavioral burden, a 3 is appropriate.

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 one-line purpose is front-loaded before the metadata tags, and there is no filler. It is arguably too terse rather than too long, but nothing present 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?

An output schema exists, so return values need not be described, and the input schema is exhaustive. The remaining gap is conceptual and scoping: the description never explains what a 'loosing of bond' is or whether the result covers the Fortune, the Spirit, or both ZR sequences, which is the one thing an agent cannot recover from the structured 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 100%, and the body schema already documents date/time/coordinates formats, timezone handling, ayanamsa and houseSystem letters in detail. The description adds nothing about the parameters, so the baseline 3 for schema-does-the-work 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 technical operation ('Loosing of Bond detection') on a specific resource ('ZR sequence'), which is more than a tautology, but 'ZR' is never expanded and the concept is opaque to an agent that does not already know Hellenistic zodiacal releasing. It also does not distinguish this from the closely named siblings astroway_hellenistic_brennan_zodiacal_releasing_fortune/spirit or astroway_hellenistic_brennan_zr_peak_periods.

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 versus the other ZR tools, no prerequisites, and no exclusions. The phrase 'within ZR sequence' only implies that a ZR context exists; it does not tell the agent which sibling produces that context or whether this tool should be called first.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds only taxonomy ('Hellenistic: Brennan tradition') and cost (10 credits, Tier 1); it says nothing about how the periods are computed, the default 80-year span, or what the caller receives beyond the schema.

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

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

Two short lines, front-loaded with the single substantive sentence, and the bracketed tags carry routing and billing information rather than filler. It is efficient, though the sparseness reflects missing content rather than tight editing.

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

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

The output schema handles return values and the annotations handle safety, so the description is not obligated to cover those. What remains missing is domain orientation: an agent cannot tell from this text how peak periods differ from the other ZR/zodiacal-releasing siblings or when to prefer 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?

Schema description coverage is 100% and the nested birth-data schema is unusually well documented (timezone/offset rules, houseSystem letters, ayanamsa), plus an output schema exists. The description contributes nothing about body/fields/precision, so the baseline 3 for schema-carried semantics 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 names a specific output (peak periods) and a domain (ZR, glossed as 'angular signs from Lot'), which is more than a restatement of the title. However, 'ZR' is never expanded to Zodiacal Releasing, so an agent must infer the link to siblings like zodiacal_releasing_fortune/spirit, and it does not say what a 'peak period' actually contains. Purpose is implied rather than stated clearly.

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

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

There is no when-to-use guidance, no exclusions, and no routing to the many related Hellenistic/Brennan tools (zr_loosing_of_bond, zodiacal_releasing_fortune, zodiacal_releasing_spirit, time_lord_stack). The only metadata is a group tag and a cost tag, neither of which tells the agent when this tool is the right choice.

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 genuinely useful non-schema context — a 10-credit Tier 1 cost and the Greenbaum tradition grouping — which annotations do not carry. It still says nothing about determinism of the calculation, caching, or what the antiscia are computed relative to.

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 definition is front-loaded in the first line, and the bracketed group/cost metadata is compact and easy to scan. Every element present earns its place, though the overall length is arguably too thin for a 15-parameter calculation 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?

The output schema exists, so return values need not be explained, but for a complex 15-parameter astronomical calculation with 33% parameter coverage the description is far too sparse. It omits what is being computed, for which chart, how it relates to sibling antiscia tools, and any use context.

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%, well below the 50% threshold, so the description is expected to compensate and does not. With 15 parameters (date, time, latitude, longitude, city, name, cosmogram, zodiacType, houseSystem, ayanamsaId, etc.) and no parameter guidance whatsoever, half-documented fields like zodiacType and houseSystem remain opaque from both schema and 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 a specific resource ('Solstitial antiscia') qualified by a tradition ('Hellenistic conventions'), which is more than a tautology. However, it names no verb (compute/return) and offers no differentiation from the many antiscia siblings present, such as astroway_aspects_antiscia, astroway_helg_antiscia_hellenistic, and astroway_hellenistic_greenbaum_contra_antiscia. An agent cannot tell from the text alone how this differs from the near-identical helg variant.

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, when to prefer an alternative, or what prerequisites exist. The 'Greenbaum tradition' group tag hints at a school but does not translate into a selection rule. An agent is left to infer usage entirely from the 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context at all — no output shape, no computation notes — beyond the billing line 'Cost: 10 credits (Tier 1)', which is the only non-structural information present.

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?

It is short and front-loaded, but the brevity is under-specification rather than efficiency: the single content sentence conveys no operational information and the remaining lines are metadata tags. Nothing here earns credit as a useful, compact description.

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

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

An output schema exists so return values need not be described, but for a 15-parameter chart computation the description omits what is being computed, what the sidereal/house-system options mean for this technique, and how it differs from the many sibling antiscia tools. It is not sufficient for correct invocation in a dense tool namespace.

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

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

With 15 parameters and only 33% schema description coverage, the description needed to compensate and instead contributes zero parameter information. Several parameters (city, name, cosmogram, zodiacType, houseSystem) are undocumented in both places, so an agent must infer required inputs (date, time, latitude, longitude) purely from the schema.

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

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

The description is essentially a restatement of the tool title: 'Equinoctial contra-antiscia' names the technique but supplies no verb or output statement, so an agent cannot tell what is produced (contacts? a table of reflections? per-planet pairings?). It does not distinguish itself from close siblings like astroway_helg_contra_antiscia, astroway_hellenistic_greenbaum_antiscia_hellenistic, or astroway_aspects_antiscia.

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

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

There is no when-to-use guidance and no named alternative, even though several near-duplicate contra-antiscia/antiscia tools exist in the sibling list. The '[Group: Hellenistic: Greenbaum tradition]' tag gives weak tradition context but nothing actionable for 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description's genuine contribution is the non-annotated billing context ('10 credits, Tier 1'), which is real added value, but it omits what inputs are mandatory and what the response 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?

It is short and front-loaded with no filler, so nothing is wasted. However the brevity is under-specification rather than efficiency, since two lines cannot carry the burden of a 15-parameter chart calculation.

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, 4-required-parameter chart tool with an output schema and a near-identical sibling, this definition leaves the agent without the information needed to invoke it correctly. Credit cost is disclosed, but input expectations and sibling selection are absent.

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

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

The schema has 15 parameters with only ~33% description coverage, so the description carries a heavy burden to compensate. It says nothing about the required date/time/latitude/longitude inputs, the timezone vs timezoneOffset precedence, the 'fields'/'precision' compact mode, or any enum meaning. Zero parameter value is added.

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 artifact produced (the Spirit-Fortune / Daimon-Tyche axis) and frames it as a 'primary chart spine', which is more concrete than the bare title. But there is no verb (compute/return) and no differentiation from the near-duplicate sibling astroway_helg_daimon_tyche_axis, which appears to be the same technique in a sibling group. An agent can guess the topic but not the action or how it beats the sibling.

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

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

There is no statement of when to use this tool, what conditions select it, or which alternatives exist. Given the presence of an almost identical helg_ sibling, guidance on when to prefer this variant would be especially valuable, and none is offered.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description does add genuinely useful behavioral context the annotations cannot convey: the tradition grouping (Hellenistic: Greenbaum) and the cost (10 credits, Tier 1). It says nothing about what the computation requires or returns, but an 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?

The entry is short and front-loads the technique name, and the group/cost tags carry real routing value. However, the brevity is under-specification rather than efficiency for a 15-parameter tool, leaving the definition 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?

For a fairly complex chart-computation tool, the description omits what dodekatemoria are, what input chart is expected, how it relates to the duodecima/decans siblings, and any cost or latency expectations beyond the credit tag. An agent cannot confidently select it over the many neighboring Hellenistic 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?

With 15 parameters and only 33% schema description coverage, several fields (city, name, cosmogram, zodiacType, houseSystem, ayanamsaId, latitude, longitude) are undocumented anywhere. The description adds no parameter meaning whatsoever, so 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?

The text 'Dodecatemoria sub-divisions of zodiac' essentially restates the title with a thin gloss and never states what the tool does (compute and return dodekatemoria placements for a chart). It also fails to differentiate from the near-duplicate sibling astroway_hellenistic_greenbaum_duodecima, which names the same 12th-part 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 guidance, no prerequisite statement (e.g. that a birth date/time/place drives the computation), and no pointer to alternatives such as the duodecima or zodiacal_decans tools. The agent must infer everything from the 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, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely useful non-schema context: the billing cost (10 credits, Tier 1) and the tradition group, but says nothing about return shape or any computational caveats.

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

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

The text is short, front-loaded with the defining phrase, and the bracketed metadata lines are easy to scan. It is arguably too sparse for a 15-parameter tool, but as raw conciseness and structure it is efficient with 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?

An output schema exists, so return values need not be explained, but with 15 parameters, three enums, and only 33% schema description coverage, the definition leaves the agent without enough context to invoke it confidently or to tell it apart from its dodekatemoria sibling.

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

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

Schema description coverage is only 33% across 15 parameters, so the schema does not carry the load and the description offers no parameter meaning at all. Nothing is said about how date/time/latitude/longitude interact, nor about the ayanamsa/zodiacType/houseSystem options that materially change output, leaving a significant compensation 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 identifies the technique ('2.5° micro-sign per planet') and its tradition group, which gives a rough sense of what the tool computes. However it uses a cryptic technical label with no verb/resource framing (e.g. 'computes the duodecima placements for a chart'), and it does not distinguish itself from the near-identical sibling astroway_hellenistic_greenbaum_dodekatemoria, which uses the same 2.5° twelfth-part division.

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, what prerequisites it has, or how it relates to alternative Hellenistic division tools. The 'Group' and 'Cost' tags are metadata, not usage direction, so an agent must infer the trigger condition from the name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description does add genuinely useful behavior not in annotations - the 10-credit Tier 1 cost - but says nothing about what the 'conditions analysis' returns or any computation 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?

Two short lines with the purpose front-loaded and no filler prose. The bracketed group/cost tags are structural boilerplate, but the cost tag carries real information, so the brevity is defensible even though it is brevity by omission rather than precision.

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 chart computation, the description omits the required date/time/latitude/longitude inputs, offers no hint of the conditions-analysis output, and fails to disambiguate from its helg-prefixed twin. An existing output schema covers return-value explanation, but the remaining gaps are too large for a tool of this complexity.

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

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

Schema description coverage is only 33% across 15 parameters, so the schema leaves most inputs undocumented (e.g. city, name, cosmogram, zodiacType, houseSystem have no descriptions). The description adds nothing about any parameter, failing 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?

The description says the tool computes the Lot of Eros plus a 'conditions analysis,' which is more than the bare title but still vague about what those conditions are and what the output represents. It gives no differentiation from the near-identical sibling astroway_helg_lot_of_eros_detail, so an agent cannot confidently choose between the two 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 guidance, no prerequisites, and no named alternative, despite a duplicate 'lot_of_eros_detail' tool existing under the helg prefix. The only context offered is a tradition group tag, which does not tell the agent when this tool is the right pick.

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 fully covered elsewhere. The description adds nothing beyond that: no explanation of what the synchronistic judgment contains, no auth or credit-consumption caveats beyond the tier tag, and no note about determinism given the time/location inputs.

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?

It is short and front-loaded with a single opening sentence plus metadata tags, so there is no padding. However the brevity here reflects under-specification rather than efficiency for a 15-parameter technique-specific 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?

An output schema exists, so return values need not be described, but the description still omits what the Hellenistic Greenbaum 'quality of time' judgment actually produces and how it differs from the helg variant. For a domain-specific, credit-costing tool with low parameter coverage, this is not complete enough for reliable selection.

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 at only 33% schema description coverage, the description carries a real burden to explain inputs, and it supplies none. Required date/time/latitude/longitude and the many optional toggles (houseSystem, zodiacType, cosmogram, ayanamsaId) are left entirely to the schema, and the ayanamsa/ayanamsaId duplication is unaddressed.

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 'Synchronistic quality of a moment' essentially restates the title 'Quality of Time' without adding a verb or naming what is actually computed (planetary condition, sect, Moon phase, etc.). It also fails to distinguish the tool from the near-identical sibling astroway_helg_quality_of_time, which is presumably the same technique under a different tradition 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?

There is no statement of when to use this tool, no prerequisites, and no comparison to the helg_quality_of_time sibling. The only contextual signal is the bracketed group/cost metadata, which hints at tradition and invocation cost but gives no actionable 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, non-destructive and closed-world, so the safety profile is covered. The description adds only the credit cost (10 credits, Tier 1) and tradition grouping, which is mildly useful but says nothing about what the calculation produces or any 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?

It is short, but that brevity reflects under-specification rather than economy: two fragments of metadata and no front-loaded statement of purpose. No sentence explains the tool's operation.

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 chart calculation with four required inputs, the description leaves the agent with no idea what is computed, what the output contains (an output schema exists but its meaning is never framed), or when to reach for this tool rather than its many Hellenistic 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 coverage is only 33% across 15 parameters, and the description contributes zero parameter meaning – it never mentions date, time, location, ayanamsa, house system, or the compact-mode fields. With low coverage, the description is expected to compensate and does not.

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

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

The description is a noun fragment, 'Constellations beyond the zodiac,' with no verb and no indication of what the tool actually computes or returns. It restates the domain of the title rather than stating an action, so an agent cannot distinguish it from siblings like astroway_helg_sphaera_barbarica or astroway_aspects_fixed_stars_catalog.

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 any alternative tool. The only additional text is group/cost metadata, which does not help select this tool over the near-identical astroway_helg_sphaera_barbarica sibling.

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 structurally. The description adds only cost/group metadata (10 credits, Tier 1) and nothing about what the computation requires or how results should be read. With annotations carrying the safety burden, this is a thin contribution.

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 two lines are tightly worded and the group/cost metadata is genuinely useful front-loaded context, so there is no padding. However, 'appropriately sized' fails badly for a 15-parameter tool in an obscure domain — the brevity reflects under-specification rather than discipline.

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 given a 15-parameter, four-required tool in a specialized Hellenistic technique, the description leaves the purpose opaque and the inputs unexplained, so an agent cannot confidently select or invoke it.