AstroWay Divination and esoterica

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds that it returns a 'plain-text human-readable summary' and clarifies the budget-checking purpose, providing useful context beyond annotations.

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

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

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

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

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

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

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

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

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

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

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

Description clearly states the verb 'Check' and the resource 'API key status' with specific attributes (tier, credit balance, rate limits, monthly cycle reset). It distinguishes itself from the many sibling astrology calculation tools.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety bar is low; the description still adds real value by clarifying that endpoints are NOT invoked and that results are cached with a 5-minute TTL. It also discloses the return shape (total + per-endpoint breakdown with tier annotations), which is meaningful since no output schema exists.

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

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

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

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

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

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

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

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

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

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

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

States a specific verb and resource ('Estimate the credit cost of one or more endpoints') and immediately pins the scope with 'WITHOUT invoking them', which no sibling tool does. An agent can distinguish this from the many invocation/report siblings at a glance.

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

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

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

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds two genuinely useful operational facts — the GET endpoint and the 5-credit (Tier ½) cost — but says nothing about result size, pagination or how heavy a full catalogue response is, which matters for a browse-all endpoint.

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 states the purpose, followed by compact bracketed metadata (group, endpoint, cost). Nothing is wasted or buried, though the metadata tags are structured fields that arguably belong outside the 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 no required parameters and an output schema present, the description need not explain return values; it still states what the catalogue contains (patterns, short/full meanings, themes). It is sufficient for correct invocation, with sibling disambiguation the only real omission.

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 both parameters (fields, precision) are already documented in the schema, and neither is required. The description adds nothing about compact mode or precision, so the baseline 3 applies — the schema does all the work.

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

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

The description names a specific resource (the full angel number catalogue) and enumerates its scope: singles, masters, repeating, mirror and sequential patterns, plus short/full meanings and themes. 'Full catalogue' usefully contrasts with the single-number siblings (astroway_esoteric_angel_numbers_number, _decode, _today, _by_life_path_n), though it never names one of them explicitly.

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

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

There is no explicit when-to-use or when-not-to-use statement. Usage is only implied by the word 'catalogue' — an agent can infer this is the browse-everything variant versus the per-number lookups, but the description never routes between the four angel-number siblings, which is the main selection risk here.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond them: the GET endpoint path and a cost disclosure ("see your plan — endpoint not in the public credit manifest"), which warns the agent that billing cannot be pre-computed 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?

Purpose and range are front-loaded in the first sentence, with the metadata block (group, endpoint, required param, cost) cleanly separated. Slight redundancy in repeating the 1-9/11/22/33 range already present in the schema 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?

For a single-required-param read tool with an output schema, annotations and full schema coverage, the description supplies what structured data does not: the endpoint, the cost caveat, and the interpretive intent. Nothing essential for a correct call is missing.

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

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

Schema description coverage is 100%: the schema already defines `n` (including master numbers), `fields` (compact mode with example) and `precision`. The description only restates the range, so it adds no meaning beyond the structured fields. 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+resource: angel numbers aligned to a given life-path number, with the accepted range (1-9, 11, 22, 33) spelled out. It is distinguishable from the other angel-number siblings by the life-path scoping, though it never names those siblings (e.g. astroway_esoteric_angel_numbers_number) to disambiguate explicitly.

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

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

"Useful to identify recurring numerical signatures aligned with one's soul path" implies when the tool is appropriate, but there is no explicit when-not guidance and no routing to alternatives among the many angel-number siblings. Usage is inferable but not 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, and destructiveHint=false, so safety is covered. The description adds the credit cost (10 credits, Tier 1) and the shape of the analysis, but does not disclose limits on sequence (max 8 digits), failure behavior, or any rate/auth constraints 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?

Front-loaded with the core action in one sentence, with endpoint, required-parameter, and cost metadata bracketed separately and easy to scan. Every element earns its place; only the lack of any sibling-routing sentence leaves a small structural gap.

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 the return values need not be spelled out, and annotations cover the safety profile. The description adequately covers the two undocumented params and the required field, though the sibling-routing context within the angel-numbers family remains 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 coverage is 50%: 'fields' and 'precision' are documented in-schema, while 'context' and 'sequence' are not. The description partially compensates by implying 'numeric sequence' and 'optional life context', but adds no format, range, or semantics beyond the parameter names themselves.

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

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

States a specific verb+resource ('Decode a numeric sequence') and names the returned artifacts (pattern classification, exact match, reduced single-digit meaning). It does not differentiate itself from the close sibling astroway_esoteric_angel_numbers_number, leaving ambiguity about sequence vs single number.

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

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

The phrase 'in optional life context' hints at when the context parameter matters, but there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as angel_numbers_number or angel_numbers_today. The agent gets no guidance on selecting among the four angel-number siblings.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavior: catalogue misses fall back to pattern classification plus reduced single digit, and it flags that the endpoint is absent from the public credit manifest (a cost-uncertainty signal). It stops short of describing response shape, but annotations carry the rest.

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 prose sentences are front-loaded and waste-free, with the fallback behavior stated immediately after the core purpose. The bracketed metadata block (Group/Endpoint/Required/Cost) adds some length, though the cost caveat carries real signal.

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 detail is not needed. Purpose, fallback behavior, and a cost caveat are present; the only meaningful gap is the absence of routing guidance among the several angel-number siblings.

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

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

Schema description coverage is 100% and all three parameters (number, fields, precision) are documented in the schema, so the schema does the heavy lifting. The description echoes 'Required: number' without adding syntax or edge-case meaning beyond what the pattern already states.

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: 'Look up the meaning of a specific angel number sequence.' This is clearly a single-number lookup. However, it does not distinguish itself from close siblings like astroway_esoteric_angel_numbers_decode, _by_life_path_n, or the base astroway_esoteric_angel_numbers list tool, leaving the agent to infer the split from names 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?

Usage is implied (pass a specific number to get its meaning) but the description never says when to prefer this over _decode, _today, or _by_life_path_n, nor when the number is required vs. derivable. The fallback note is behavioral, not a routing rule, so no explicit alternative is named.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description usefully adds cost ('5 credits, Tier ½') and the endpoint path, but says nothing about permissions, rate behavior, or how the date is resolved. With annotations carrying most of the load, 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?

Front-loaded with the core action in the first sentence, with group/endpoint/cost metadata bracketed compactly. No filler, though the parameter detail in sentence two is the part that misfires rather than over-length.

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

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

An output schema exists, so return values needn't be explained, and the description covers purpose, endpoint, and cost for a simple zero-required-parameter read tool. The only gap is the mismatch between the described date query and the actual schema parameters.

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

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

Schema coverage is 100%, so baseline is 3, but the description introduces an 'Optional ?date=YYYY-MM-DD query' that does not appear among the two schema parameters (fields, precision). This phantom parameter can mislead an agent, and the actual schema parameters are never mentioned, so the description adds no useful meaning and introduces confusion.

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 ('Compute today's personal angel number') and clarifies the derivation ('digit-sum reduced to single digit'), which separates it from the generic angel-number siblings. It does not explicitly name which sibling it differs from, keeping it below 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?

Usage is implied by 'today's' – an agent can infer this is the daily-variant versus the by-life-path/by-number/decode siblings – but no explicit when-to-use, when-not, or named alternative is given. This is minimum-viable context rather than guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds useful non-schema context: the tag dimensions present in each entry, the fact that chakra/purpose taxonomies are returned, and the 5-credit (Tier ½) cost. It stops short of describing pagination or result-size behavior for a 'full directory'.

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

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

Two front-loaded sentences state the resource and its return taxonomies with no filler, followed by compact bracket metadata for group, endpoint, and cost. Slightly more could be trimmed from the tag enumeration, 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 present, annotations covering safety, and a fully documented 2-parameter schema, the definition only needs to orient the agent — which it does by naming the resource, its tag fields, and what taxonomies come back. The remaining gap is the lack of explicit routing to the filtered crystal siblings.

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

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

Schema description coverage is 100%, so both `fields` (dotted-path projection) and `precision` (decimal rounding) are fully documented in the schema, and baseline is 3. The description adds nothing about either parameter — notably it does not hint that `fields` can be used to trim this large directory response.

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

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

The description states a specific resource and scope: a 'reference list of crystals' with named tag dimensions (chakra, zodiac, planet, element, hardness, purpose), which is clearly distinguishable from the geomancy, runes, and Mayan siblings. It does not, however, name the closely related siblings (astroway_esoteric_crystals_by_chakra_chakra, _by_purpose_purpose, _by_zodiac_sign, _recommend) to explain how this differs from 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?

The line 'Returns chakra and purpose taxonomies for filtering' implies the intended pipeline: call this first to discover valid filter values, then use the filtered crystal endpoints. That is genuine but implied guidance — there is no explicit statement of when to prefer this over the by_chakra/by_purpose/by_zodiac variants, nor any exclusion.

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-annotation context: the HTTP endpoint path and a cost caveat that the endpoint is not in the public credit manifest, which is worth knowing before calling. It says nothing about result size, pagination, or unknown-chakra behavior.

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

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

One front-loaded sentence with the essential resource and its value domain, followed by a compact metadata block. No filler, though the bracketed metadata lines add bulk that could be tighter.

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

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

An output schema exists, so return values need no explanation, and all three parameters are documented. The only meaningful gap is sibling disambiguation among the four other crystal tools, which an agent choosing between them would want.

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 baseline is 3, but the description goes further by enumerating the accepted chakra names (Root through Crown), which the schema does not provide as an enum. It still leaves case/format expectations to the schema's 'lowercase' note.

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

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

States a specific verb-and-resource pairing ('Crystals indexed for a given chakra') and enumerates the seven valid chakra values, so the agent knows exactly what it returns. It does not explicitly contrast itself with the sibling crystal endpoints (by_purpose, by_zodiac_sign, crystals_recommend), so it stops short of a 5.

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

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

There is no when-to-use guidance and no mention of when to prefer this over astroway_esoteric_crystals_by_zodiac_sign or astroway_esoteric_crystals_by_purpose_purpose. Usage is only implied by the 'given a chakra' phrasing and the enumerated values.

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 a genuinely useful non-schema detail — substring matching semantics (also mirrored in the schema) and a cost caveat that the endpoint is absent from the public credit manifest. It adds some value, but not rich behavioral detail beyond that.

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

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

The opening sentence is front-loaded and waste-free, and the bracketed metadata block (group, endpoint, required param, cost note) is compact and scannable. Slight redundancy between the description's substring-matching mention and the schema's own note, but overall efficient.

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

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

With a 100%-covered schema, rich annotations, and an output schema handling return values, the description only needs to orient the agent — which it does. The one real gap is sibling differentiation against the other crystal endpoints, which a competent agent can partially recover from the tool name.

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 all three parameters (purpose, fields, precision) are already documented, including the substring-match example. The description's phrase 'indexed by intent keyword' loosely maps to the purpose parameter but adds nothing the schema does not already say. Baseline 3 is appropriate.

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

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

The description states a specific resource and scope: crystals indexed by intent keyword, with concrete examples (love, prosperity, healing, protection). This is clear enough to distinguish it from a generic crystal listing, but it never differentiates itself from the closely-named siblings (by_chakra, by_zodiac_sign, recommend), leaving that routing to inference.

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

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

Usage is implied by the examples and the 'match a purpose' framing, so an agent can infer this is the tool for intent-based crystal lookup. There is no explicit when-to-use or when-not guidance, and no mention of the by_chakra / by_zodiac alternatives that would be the natural confusion points.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered structurally. The description adds genuinely new context: the cost is plan-dependent and absent from the public credit manifest, and the input is case-insensitive. However it says nothing about response shape or rate limits, which is acceptable given the annotations and 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?

Front-loads the actual purpose in one sentence, followed by compact bracketed metadata (group, endpoint, required param, cost). No wasted prose, though the bracket block is boilerplate that repeats schema-derivable facts like the required parameter.

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 annotations, an output schema, and full schema coverage, the basics are covered. The main gap is the absence of any routing guidance among the four sibling crystals tools, which is the primary decision an agent faces here.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's 'case-insensitive English name' note adds mild clarification, though it slightly diverges from the schema's 'lowercase English name' wording; it does nothing for the fields/precision compact-mode parameters, which the schema already documents.

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 (crystals) and the index dimension (zodiac sign), so an agent can distinguish it from the sibling 'by chakra' and 'by purpose' variants. It does not explicitly name those alternatives, but the purpose itself is unambiguous and specific.

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

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

The description gives no when-to-use guidance and never names the closely related crystals endpoints (astroway_esoteric_crystals, _by_chakra, _by_purpose, _recommend) that an agent must choose between. Only the mechanical [Required: sign] line is present, 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 readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description usefully adds the return shape (top-N matches with score) and the cost metadata (10 credits, Tier 1), but says nothing about ranking mechanics, whether results are deterministic, or what happens when signs are omitted.

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

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

Two front-loaded sentences that state function and return value with no filler, followed by compact group/endpoint/cost metadata. Efficient and easy to scan.

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

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

An output schema exists, so return-value detail is not required. However, for a 7-parameter tool with 0 required parameters, 29% schema coverage, and no usage guidance, the description leaves meaningful gaps about how to compose a call and when to prefer this over the sibling crystal 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 only 29%, and the description compensates partially by naming the sign inputs (Sun/Moon/Asc) and intent keywords. It says nothing about limit, the fields compact-mode path syntax, or precision rounding, so the low-coverage parameters remain only partially explained.

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

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

States a specific verb (recommend) and resource (crystals) plus the scoring basis (natal Sun/Moon/Asc placements and intent keywords), which is more than a tautology. It does not explicitly contrast itself with the overlapping siblings astroway_esoteric_crystals_by_zodiac_sign and astroway_esoteric_crystals_by_purpose_purpose, so an agent must infer the boundary.

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

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

The mention of natal placements and intent keywords implies when the tool applies, but there is no explicit when-to-use statement, no exclusions, and no pointer to the by-zodiac or by-purpose siblings that cover adjacent needs. 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/openWorld=false, so safety is covered. The description goes further with lifecycle and cost context the annotations omit: RED data quality, sunset date, the 2017 stability-policy window, and a 10-credit Tier 1 cost. This is genuinely useful operational context beyond the structured fields.

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

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

The core purpose sentence is front-loaded after a deprecation preamble, which is the right ordering. However, the deprecation is stated twice – once as the "DEPRECATED: RED quality" prefix and again in the bracketed "[⚠️ DEPRECATED — will be removed...]" block – and the [Group]/[Endpoint]/[Required] boilerplate is largely redundant. Some trimming would earn more of its space.

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

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

An output schema exists, so return values needn't be explained. The description covers purpose, deprecation timing, migration, required input, and cost – everything an agent needs to decide and invoke. The absence of a named successor endpoint is the only 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 67%, and the schema already documents both `fields` and `precision` in detail with examples. The description only restates the required `date` ("for date") without adding format, range, or semantics beyond the schema's pattern. Baseline 3 is appropriate when the schema carries the detail.

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

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

"Calculate Djamaspa planetary positions for date" gives a specific verb+resource and the input it needs. The esoteric/Djamaspa subject matter distinguishes it from the geomancy, runes, and mayan siblings, though it doesn't explicitly contrast with a near-neighbor tool. Clear enough for selection despite the deprecation noise surrounding it.

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 tells the agent not to use it ("Avoid using", "DEPRECATED") and provides a migration route ("Migrate to broader /reference endpoints or remove the dependency") plus a hard sunset date. This is strong when/when-not guidance. It doesn't name a specific replacement endpoint, which keeps it from a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is fully covered without the description. The description adds cost (5 credits, Tier ½) and the endpoint, which is useful call context, but it does not disclose anything further about response size, pagination, or limits.

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

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

A single front-loaded sentence describes the payload, followed by a compact metadata block (group, endpoint, cost). There is no filler, though the bracketed metadata is somewhat mechanical and could be trimmed.

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 low-complexity read tool, the essentials are present: annotations carry safety, a 100%-covered 2-param schema carries inputs, and an output schema exists so return values need no prose. The only real omission is routing guidance versus the four sibling dream 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%, with both optional compact-mode parameters ('fields' and 'precision') fully documented in the schema itself. The description adds no parameter meaning, so the baseline 3 for schema-covered parameters 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 concrete resource ('full dream symbol dictionary') and enumerates its contents (category, element, archetype, common/shadow meanings, recurring-dream readings), so an agent knows what it returns. The word 'Full' hints it is the complete dictionary rather than a lookup, but no sibling is named to make the distinction explicit, which keeps it at a 4 rather than 5.

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

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

There is no when-to-use statement and no alternatives surfaced. Siblings such as astroway_esoteric_dreams_symbol_keyword, astroway_esoteric_dreams_decode, astroway_esoteric_dreams_by_element_element, and astroway_esoteric_dreams_recurring_themes overlap heavily, yet the description gives no rule for choosing among them.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety is fully covered. The description adds one genuinely new behavioral fact — that this endpoint is not in the public credit manifest, so pricing must come from the plan — which is useful for cost-sensitive agents, but it says nothing about result size or depth of the symbol corpus.

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 prose sentence followed by four bracketed metadata tags — group, endpoint, required param, cost. Nothing is padded, and the operative fact (what is indexed by what) is front-loaded.

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

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

With an output schema present, the description need not describe return values; annotations cover the safety profile and the schema covers all three parameters. The only real gap is the absence of sibling routing, which keeps it out of the top band for a tool in a very crowded namespace.

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

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

Schema description coverage is 100% and the element enum is fully documented, so the schema carries the parameter burden. The description only repeats the enum values and adds no semantics about what 'spirit' contains versus the four classical elements, or about how fields/precision interact with this response.

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 indexing dimension: dream symbols grouped by element, with the five valid groupings enumerated. An agent can tell this is a lookup/list tool rather than a decoder, but the description never contrasts it with nearby siblings like dreams_symbol_keyword, dreams_decode, or dreams_recurring_themes.

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. "[Required: element]" merely restates the schema's required field and does not explain when an agent should browse by element versus looking up a single symbol keyword or decoding a full dream.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely new operational context not in structured fields: the POST endpoint and the 10-credit Tier 1 cost, which matters for an agent deciding whether to call it.

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

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

Purpose is front-loaded in the first sentence, followed by a compact bracketed metadata block (group, endpoint, required, cost) with zero filler. Slightly terse on the behavioral sentence, but nothing is wasted.

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

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

For a simple single-text-input tool with an output schema present, the description needn't explain return values, and the cost/input-requirement disclosure covers the practical needs. The only real gap is not distinguishing this decoder from the sibling symbol-keyword lookup.

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

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

Schema coverage is 50%: 'fields' and 'precision' carry their own descriptions, while 'text' and 'recurring' do not. The description partially compensates by flagging 'text' as required and gesturing at the recurring/single-event distinction, but never explains what the recurring toggle actually changes. Baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource: 'Scan dream narrative text for known symbols,' then states the output shape (matched symbols with meanings). This clearly separates it from keyword-lookup siblings, though it never names an alternative like astroway_esoteric_dreams_symbol_keyword explicitly.

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

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

There is no when-to-use or when-not-to-use guidance and no alternative named, despite several close siblings (dreams_symbol_keyword, dreams_recurring_themes, dreams_by_element). The parenthetical '(recurring or single-event)' hints at a mode but does not tell the agent which one applies to a given request.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds genuinely useful non-schema context: the endpoint path and a cost of 5 credits (Tier ½), which an agent needs for budgeting. It says nothing about response size or shape, though an output schema exists to cover that.

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

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

One compact sentence that front-loads the resource and its examples, followed by clearly delineated bracketed metadata for group, endpoint, and cost. No filler prose; the metadata block is terse and skimmable.

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

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

For a zero-required-parameter, non-nested, read-only lookup with a 100%-covered schema and an output schema, the description supplies enough to call the tool correctly, and the cost hint covers a real decision factor. A brief note on what the catalogue returns per theme would make it fully self-contained.

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 both parameters (fields, precision) are already fully documented in the schema. The description adds no syntax, default, or usage detail beyond that, which is the expected baseline when the schema does the work.

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

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

States a specific resource (a catalogue of recurring dream themes) and illustrates it with four concrete examples plus the kind of content returned ('universal psychological meanings'). This is clearly distinguishable from siblings like astroway_esoteric_dreams_decode or astroway_esoteric_dreams_symbol_keyword by subject matter, but the description never explicitly contrasts itself with 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 statement, no condition that selects this tool over the many adjacent dream/divination siblings, and no prerequisites. The name and the phrase 'recurring themes' imply it is a reference lookup, but the agent must infer that entirely.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real behavioral detail beyond them: exact match takes priority, falling back to partial substring matches, plus a cost caveat that the endpoint is absent from the public credit manifest.

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 behavioral sentence is front-loaded and the bracketed metadata lines are compact and scannable. The endpoint path line is redundant with the tool name, but nothing is bloated.

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

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

An output schema exists, so return-shape explanation is not required, and all three parameters are fully described in the schema. Matching behavior, required input, and cost uncertainty are covered; only sibling routing is missing.

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

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

Schema coverage is 100%, so all three parameters are already documented in the schema, including the 'fields' compact-mode path syntax and 'precision' rounding. The description only restates the required 'keyword' and its match semantics, adding little beyond structured data; 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: 'Look up a dream symbol by keyword.' That is clearly distinct from the sibling decode/element/theme dream tools, which take different inputs. It stops short of naming those siblings to route the agent, so it lands at 4 rather than 5.

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

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

The only guidance is about matching behavior, not about when to pick this tool over astroway_esoteric_dreams_decode or astroway_esoteric_dreams_by_element_element. No prerequisites, no exclusions, no alternatives 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 read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds real context: 'input ignored' (the cast is not parameterized), the sunset date, and a 10-credit cost. It stops short of describing the random/seedless nature of the cast beyond the implicit contrast with the seeded replacement.

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 deprecation warning is front-loaded, which is correct, but it is repeated three times (title, description opener, and the trailing bracket block). Group/Endpoint/Cost metadata and the ⚠️ footer add bulk that competes with the routing message.

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 no explanation, and the deprecation, replacement routing, cost, and sunset are all stated. Nothing an agent needs in order to avoid or correctly invoke this tool is missing.

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

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

Schema description coverage is 100%, so both params (fields, precision) are already documented as compact-mode output shapers. The description adds only the indirect note that input is ignored, which slightly conflicts in spirit with the presence of params, but no syntax or semantics are added beyond the schema. 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 ('Casts a single I Ching hexagram') and explicitly positions itself against the entire /iching/* sibling namespace, listing each replacement and its distinguishing trait. An agent can tell this apart from astroway_iching_throw_coins without opening a schema.

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

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

Explicitly says when NOT to use it (deprecated, sunset 2027-06-16, avoid) and names six concrete alternatives with their differing capabilities. Nothing is left to inference about routing.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered without the description. The description adds genuinely new behavioral context — the endpoint and the 10-credit (Tier 1) cost — but says nothing about auth, rate limits, or response shape beyond what the output schema covers.

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 terse: a keyword fragment followed by three bracketed metadata tags. Nothing is wasted and the meaning is front-loaded, but for a tool that never states an action, the brevity shades into under-specification rather than disciplined 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 an entity that is read-only, idempotent, has no required parameters, fully documented parameters and an output schema, the description need not explain return values. What remains missing is the core statement of what the tool actually produces, so it is adequate-but-gapped rather than complete.

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

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

Schema description coverage is 100% for both optional parameters (fields, precision), and their descriptions are detailed (dotted-path syntax, decimal rounding guidance). The description adds no parameter meaning, which is acceptable here since the schema carries the full burden; 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 is a semantic gloss of the figure's name ("Gain, profit, abundance") rather than a statement of what the tool does. There is no verb and no statement of the resource returned; an agent must infer from the name and the endpoint tag that this returns a geomancy reading for the Acquisitio figure. It is closer to a restatement of the title than a purpose statement.

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

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

No guidance on when to use this versus the 14 sibling geomancy figures (albus, amissio, puer, rubeus, etc.), no prerequisites, no exclusions. The only implicitly useful cue is the group tag placing it in the Geomancy family, which helps a little but gives no selection criteria.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new operational context that annotations do not carry: the POST endpoint and a cost of 10 credits (Tier 1), which matters for an agent budgeting calls. It says nothing about what is returned or the semantics of the reading, so it is useful but incomplete.

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 three-word lead and three bracketed metadata lines are free of filler and reasonably front-loaded (meaning first, then group/endpoint/cost). However, this is under-specification rather than true conciseness: for a tool with fifteen interchangeable siblings, a three-word semantic gloss does not earn its place as the whole description.

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

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

With annotations covering the safety profile, a 100%-covered schema, and an output schema handling return values, the description's remaining job is purpose and sibling routing — exactly what it omits. An agent cannot tell from this text what distinguishes Albus from coniunctio or puella, nor what the call produces conceptually. The cost/endpoint lines help but do not fill the gap.

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

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

Schema description coverage is 100% and both parameters are optional (fields, precision), so the schema fully documents them; baseline 3 applies. The description adds no extra meaning about compact mode, dotted-path syntax, or precision defaults, so it neither compensates nor detracts.

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

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

The description gives only three symbolic keywords ("Wisdom, peace, clarity") for the figure Albus; it never states a verb or says what the tool actually returns (a figure reading? an interpretation? a chart?). Against 15 near-identical sibling geomancy tools (coniunctio, puella, rubeus, etc.) nothing here distinguishes this endpoint from them. The bracketed group/endpoint lines hint at the domain, but the prose itself is closer to a title gloss than a purpose statement.

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, no when-not-to-use, and no mention of alternative geomancy figures or how to choose Albus over the other fifteen figure endpoints. The only usable signal is the implicit "this is a geomancy figure" from the group tag. No guidance is provided.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds genuine behavioral context the annotations lack: the POST /v1/geomancy/amissio endpoint and the cost of 10 credits (Tier 1), which lets an agent budget calls.

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

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

The description is short and front-loads the figure's meaning, with endpoint and cost in bracketed tags at the end. It wastes no words, but it is under-specified rather than concise — there is no wasted text because there is barely any text.

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 100% schema coverage handles parameters. What is missing is the operational framing — what the call actually produces for a geomancy figure and when it is the right figure to request — leaving a simple lookup tool only minimally complete.

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

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

Schema coverage is 100% and both parameters (fields, precision) are fully documented in the schema itself. The description adds nothing about parameters, so the baseline 3 applies — the schema does all the work.

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

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

The description gives the figure's gloss ('Loss, letting go, slipping away') but never states the operation — there is no verb such as 'retrieve' or 'interpret'. An agent can infer this returns the Amissio geomancy figure's reading and can distinguish it from siblings like astroway_geomancy_acquisitio by the meaning gloss, but the purpose remains implied rather than stated.

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

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance anywhere in the description. With 15 sibling geomancy figure tools plus other divination systems, nothing tells the agent how to pick Amissio over the other figures.

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 behavior. The description adds useful non-annotation context: endpoint, group, and a cost of 10 credits (Tier 1). However, it does not explain what the tool returns or any other behavioral traits beyond cost and endpoint.

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

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

The description is very short and front-loads the symbolic meaning before bracketed metadata. It avoids waste, though the content is minimal for the tool's complexity.

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 a rich schema, annotations, and an output schema, the description never states the tool's action or purpose. It supplies endpoint and cost metadata, but an agent still cannot tell from the description alone that this tool provides a geomancy reading for Caput Draconis.

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

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

Schema description coverage is 100%, so the input parameters (fields, precision) are fully documented in the schema. The description adds no parameter meaning, but the baseline is 3 when the schema carries the parameter semantics.

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

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

The description gives only the symbolic meaning of Caput Draconis ('Dragon's Head: beginnings, threshold') without a verb or resource indicating what the tool actually does. It effectively restates the title rather than specifying an action such as retrieving a geomancy interpretation.

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

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

There is no guidance on when to use this tool versus its many geomancy siblings (e.g., cauda_draconis, puer, via). It provides no context, prerequisites, or exclusions that would help an agent choose it.

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

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful operational context beyond annotations, chiefly the cost (10 credits, Tier 1), group, and endpoint, but does not cover auth, rate limits, or return behavior.

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

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

The definition is extremely concise and well structured: thematic meaning first, then bracketed group, endpoint, and cost. Every element earns its place with no filler.

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

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

With an output schema present and annotations covering safety, the description need not explain return values. It supplies cost, endpoint, group, and thematic meaning, but still lacks explicit usage guidance and a clear statement of what the tool does operationally.

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

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

Schema description coverage is 100% and both parameters ('fields', 'precision') are fully documented in the schema. The description adds no parameter meaning, so the baseline of 3 applies.

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

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

The description gives thematic keywords ('Restriction, confinement, isolation') for the Carcer figure, but no verb or explicit statement of operation. The bracketed group and endpoint imply it is the Carcer geomancy endpoint, so the purpose is inferable rather than clearly 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 explicit when-to-use guidance, no conditions, and no mention of alternatives among the many geomancy sibling tools. The thematic keywords faintly imply a use case, but nothing tells an agent when to select this over another figure.

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

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

Annotations already cover the safety profile: readOnlyHint=true, idempotentHint=true, openWorldHint=false, destructiveHint=false. The description adds useful operational context such as the POST endpoint and 10-credit cost, but it does not disclose auth needs, rate limits, or return behavior beyond what the output schema provides. The POST endpoint does not contradict the read-only annotation.

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

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

The description is very concise: one symbolic line followed by clearly structured metadata (group, endpoint, cost). It is front-loaded and wastes little space, though the main line is a fragment rather than a full operational statement.

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 no-required-parameter tool with a rich output schema and safety annotations, the description plus structured fields is close to callable. However, it still omits what the operation actually does or returns, and it provides no selection context relative to sibling geomancy figures.

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

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

Schema description coverage is 100%, and both optional parameters ('fields' and 'precision') are fully documented in the input schema. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description names the specific geomantic figure and gives its symbolic meaning, but it never states the operation the tool performs (e.g., returns/retrieves a Cauda Draconis reading). It is identifiable as a geomancy figure tool, yet the purpose remains vague at the action level.

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 mention of alternatives among the many geomancy sibling tools. 'Endings, exit' is symbolic meaning, not an instruction about when this tool should be selected.

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 closed-world, so the safety profile is covered. The description adds genuinely useful non-schema context — the POST endpoint and the 10-credit (Tier 1) cost per call — which helps an agent weigh invocation. It stops there, offering no notes on inputs needed, rate limits, or result characteristics.

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 the metadata tags earning their place by conveying endpoint and cost. The opening keyword line is concise but semantically thin rather than wasteful.

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?

Structurally the gaps are small: an output schema exists so return values need no explanation, both parameters are documented, and annotations cover safety. What is missing is the semantic core — what a Coniunctio reading represents and when to request it instead of another figure — leaving the tool only minimally callable with confidence.

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%: `fields` and `precision` are both fully documented in the schema, including compact-mode syntax and rounding guidance. The description adds nothing about parameters, 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 is a bare keyword list — "Union, meeting, partnership" — which is the symbolic meaning of the Coniunctio geomantic figure, not a statement of what the tool does. There is no verb and no indication that it returns a geomancy reading, so an agent must infer the operation from the name/title alone. It also does nothing to distinguish this from the 15 sibling geomancy figure 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?

No when-to-use guidance, no prerequisites, and no mention of when to prefer this figure over siblings like astroway_geomancy_puella or astroway_geomancy_via. The only context given is group/endpoint/cost metadata.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully adds the endpoint path and cost (10 credits, Tier 1), which is real behavioral context an agent cannot get from annotations. It does not contradict anything, but discloses nothing further about behavior.

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

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

The text is short and front-loads the figure's meaning, with metadata tags on separate lines. Nothing is padded, but the substantive description is a single clause followed by bookkeeping lines, so there is little structure to reward.

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 rich annotations, the description need not explain returns or safety. It covers endpoint and cost but omits what the tool actually produces or when it should be chosen over sibling geomancy tools, leaving the core functional statement 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?

Both parameters (fields, precision) have 100% schema description coverage with detailed usage notes. The description adds nothing about them, but that is acceptable since the schema already does the work — the baseline of 3 applies.

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

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

The description is essentially a restatement of the title: 'Fortuna Major' is glossed as 'Greater Fortune: lasting success.' It gives the figure's divinatory meaning but never states a verb or what the tool actually does (e.g., return a geomancy reading for the Fortuna Major figure). An agent must infer the function from the name and the '[Group: Geomancy]' 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 guidance on when to use this tool versus alternatives such as astroway_geomancy_fortuna_minor or the other fifteen geomancy figure tools. The group tag hints at a category but provides no selection criteria or exclusions.

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, so the safety profile is covered. The description adds genuinely useful operational context the annotations lack: the endpoint, the '10 credits (Tier 1)' cost, and the group. It does not, however, describe the nature of the result beyond flavor.

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 the metadata block is tidy and scannable, but the front-loaded sentence carries no functional information, so the leading real estate is spent on flavor rather than purpose.

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

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

With an output schema and full annotations, return values and safety need not be restated. What is missing is the core fact an agent needs — that this returns the 'Fortuna Minor' geomantic figure reading — making it hard to pick against the crowd of sibling geomancy 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 both optional params (fields, precision) are fully documented in the schema. The description adds nothing about them, which is the correct baseline when the schema already does the work.

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

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

The description opens with flavor text ('Lesser Fortune: quick gains') that essentially restates the title 'Fortuna Minor' without stating a verb or what the tool returns — presumably a geomantic figure reading. Nothing distinguishes it functionally from its many geomancy siblings such as astroway_geomancy_fortuna_major; only the group/endpoint metadata hints at context.

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 conditions, and no reference to alternatives despite ~14 sibling geomancy figure tools. The cost tier is metadata, not usage guidance.

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

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

Annotations already declare this as a safe, idempotent, non-destructive, closed-world read, so the safety profile is covered. The description does add genuine behavioral context beyond annotations: a cost of '10 credits (Tier 1)' and the endpoint POST /v1/geomancy/laetitia. It says nothing about auth, rate limits, or what the reading contains, but the cost disclosure is real added value.

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

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

The definition is tight and front-loaded: the thematic keywords come first, then compact bracketed metadata. Every line earns its place (group, endpoint, cost), though the keyword-only opening leaves the core purpose underspecified.

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 needn't explain return values, and no parameters are required, so the calling mechanics are adequately covered by structured data. However, the description never conveys what the tool actually produces or when to reach for it, leaving a gap an agent must fill by inference.

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

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

Schema description coverage is 100% and both parameters (fields, precision) are fully documented in the schema. The description adds no parameter meaning at all, so the baseline 3 for schema-driven param documentation 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 is a bare keyword list ('Happiness, optimism, healing') with no verb stating what the tool does. The Group tag '[Group: Geomancy (Agrippa)]' and the name/title make it inferable that this returns the Laetitia geomancy figure, but the description itself never states the action or resource explicitly. It distinguishes the figure from siblings only via the name, not the description text.

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 condition for selecting Laetitia over the other fifteen geomancy figures, and no mention of alternatives. The agent is left to 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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful operational context the annotations do not: the endpoint (POST /v1/geomancy/populus) and the cost (10 credits, Tier 1). It says nothing about what the reading contains or whether any prerequisites apply.

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, and the bracketed metadata block is easy to scan. However, the brevity comes from under-specification rather than discipline — the keyword list occupies the place where purpose should be.

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

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

An output schema exists, so return-value documentation is not required, and annotations cover the safety profile. But for a divination endpoint whose entire value is the meaning of the Populus figure, the description gives no indication of what a caller receives or how this figure's reading differs from its many siblings.

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

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

Schema description coverage is 100% and both parameters (fields, precision) are documented there with examples and rationale. The description adds no parameter meaning of its own, so the baseline 3 applies.

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

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

The description is a bare keyword gloss of the figure's meaning ("Crowd, gathering, public") and simply restates the name and title. It never states a verb or what invoking the tool actually returns — a reading, an interpretation, a cast figure — so an agent cannot tell what the tool does beyond the word 'Populus'.

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 and no differentiation from the 15 sibling geomancy figures (Puer, Puella, Via, Rubeus, etc.) that share the identical pattern. An agent has no signal for choosing Populus over Albus or Coniunctio.

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 a closed world, so the safety profile is covered. The description adds genuinely useful non-schema context – the group, the POST endpoint, and the cost (10 credits, Tier 1) – but says nothing about what the reading contains or any constraints on invocation.

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, but the brevity stems from under-specification rather than disciplined concision: the theme phrase carries no operational information, and the bracketed metadata is the only concrete content. It is neither wasteful nor adequately informative.

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

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

With an output schema present, annotations covering safety, zero required parameters, and full schema coverage, much of the burden is carried elsewhere, so the definition is not grossly incomplete. However, for a tool embedded among 16 near-identical geomancy siblings, the absence of any statement about what a reading returns or when this figure applies leaves a real selection 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 both optional parameters (`fields`, `precision`) are fully documented in the schema itself; the description adds nothing about them. Per the baseline rule, a 3 is appropriate when the schema does the heavy lifting.

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

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

The description gives only the divinatory keywords "Beauty, harmony, love" – the symbolic meaning of the Puella figure – with no verb or statement of what calling the tool actually does (e.g. returns a geomancy reading for this figure). It does not distinguish the tool from the 15 sibling geomancy figure tools beyond the figure name already present in the tool name. This is keyword association rather than a purpose statement.

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 indication of what input/question triggers this figure versus Puer, Albus, or any other geomancy sibling, and no prerequisites. The agent is left to infer everything from the one-word theme.

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 endpoint and a 10-credit Tier 1 cost, which is genuinely useful billing context, but says nothing about what the invocation returns or whether any inputs beyond formatting matter.

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, with no filler sentences. However, the one prose sentence conveys symbolic flavor rather than operational information, so brevity comes at the cost of substance rather than being efficient communication.

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

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

An output schema exists, so return values needn't be described, and the params are self-documenting. Still, the description never confirms what the tool produces (a geomancy figure reading) or how its output differs from the other figure endpoints, leaving an agent to guess from naming convention.

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?

Both parameters (fields, precision) are fully documented in the schema at 100% coverage, so the baseline is 3. The description adds no parameter meaning of its own, which is acceptable here since the schema carries the load.

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 'Young man, energy, impulse' restates the symbolic meaning of the Puer figure rather than stating what the tool does. It never says it computes or returns a geomancy figure/reading, so an agent must infer the operation from the name and title 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?

No when-to-use guidance, no prerequisites, and no differentiation from the ~15 sibling geomancy figure tools (puella, rubeus, albus, etc.). The mystical keywords imply a divinatory context but give no condition for choosing this figure over another.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond annotations — the endpoint (POST /v1/geomancy/rubeus) and a concrete cost of 10 credits (Tier 1) — but says nothing about what the response contains or any limits.

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

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

The semantic line is front-loaded and the bracketed metadata (group, endpoint, cost) is compact and scannable with zero filler. It is arguably too sparse rather than bloated, 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?

An output schema exists, so return values needn't be spelled out, and annotations cover safety. Still, for a zero-required-param divination endpoint in a large sibling family, the description leaves the core behavior (that it yields the Rubeus figure's reading) implicit and gives no selection criteria.

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

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

Schema description coverage is 100% and both optional params (fields, precision) are fully documented in the schema with examples. The description adds no parameter detail, which is acceptable given the schema does the heavy lifting — baseline 3.

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

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

The description conveys the specific figure's symbolism ('Passion, anger, blood: ill omen') and the endpoint/group identify it as the Rubeus geomancy figure, distinguishing it from the other 15 geomancy siblings by name. However, it never states what the tool actually does or returns — no verb like 'returns' or 'retrieves' — so the purpose is only implied.

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 explanation of how to choose Rubeus over Acquisitio, Puella, or the other geomancy figures, and no prerequisites stated. The agent must infer everything from the figure's meaning alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful cost and endpoint context, but does not disclose return format, auth needs, or rate limits. It does not contradict the annotations.

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

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

The definition is very concise and front-loads the thematic keywords before structured metadata. The first sentence is arguably redundant with the title, but overall it wastes little 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?

Output schema exists, so return-value details are not required, but the description still fails to state what the tool produces (e.g., a Tristitia geomancy reading). For a tool with many similar siblings, this leaves a critical purpose gap.

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

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

Schema coverage is 100%, so both optional parameters (fields, precision) are fully documented in the schema. The description adds no parameter information, 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?

"Sadness, depression, melancholy" restates the title and gives thematic keywords, but never states a verb or what the tool actually does. It does not distinguish this geomancy figure from any of the dozens of sibling geomancy 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?

The description provides no when-to-use guidance, no alternatives, and no prerequisites. Only metadata (group, endpoint, cost) is present, so an agent cannot tell when to select Tristitia over Laetitia or other figures.

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 only added disclosure is the endpoint path and the 10-credit cost, which is mildly useful but says nothing about behavior, permissions, or result shape.

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

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

It is short, but the brevity reflects under-specification rather than economy: the single content sentence is a keyword list and the rest is bracketed metadata. There is nothing front-loaded that helps an agent decide or invoke.

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

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

An output schema exists so return values need not be explained, and the schema documents parameters fully. What remains missing is the tool's actual function and its relationship to the many sibling geomancy figures, which is the core information an agent needs here.

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

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

Schema description coverage is 100% and both parameters (fields, precision) are thoroughly documented in the schema itself. 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?

"Movement, change, journey" is a keyword gloss on the geomantic figure Via, not a statement of what the tool does or returns. It never uses a verb or names a resource, so an agent cannot tell whether this computes a chart, looks up a figure, or returns a reading.

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 guidance at all, despite 16 sibling geomancy tools (acquisitio, albus, puer, etc.) that an agent must choose between. Nothing routes the agent to or away from this figure.

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

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the bar is low. The description adds two genuinely useful facts beyond them: that output is deterministic (same question yields the same hexagram) and that the call costs 10 credits at Tier 1, which is real budgeting context.

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

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

The functional sentence is front-loaded and there is no filler prose. The bracketed metadata lines are terse and skimmable, though they read as structured tags rather than prose that earns every word.

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

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

An output schema exists so return values need no explanation, and annotations cover the safety profile, leaving the definition adequate for a one-required-param tool. The gap is the unelaborated 'deterministic' claim and the absence of any sibling routing, which matters given how crowded the I Ching family is.

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 67%: `fields` and `precision` are already documented in the schema, and `question` is self-evident. '[Required: question]' merely restates the schema's required array, adding no syntax or constraint meaning beyond it, so baseline 3 applies.

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

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

The first sentence gives a specific verb (derive) plus resource (hexagram) and names the input (question text). 'Deterministic' meaningfully separates it from the random astroway_iching_throw_coins sibling, but no sibling is named explicitly, so an agent must infer the distinction.

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

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

There is no when-to-use, when-not-to-use, or alternative routing guidance despite five closely-related I Ching siblings (daily, lookup_number, throw_coins, with_changing_lines, plain iching). The agent is left to guess which variant fits its intent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description's 'deterministic' reinforces the idempotency claim and the metadata block adds useful operational context (cost of 10 credits, POST endpoint). It does not, however, describe what the date input does when omitted or the shape of the reading returned.

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 terse and front-loaded: the core capability leads, followed by a compact bracketed metadata block for group, endpoint and cost. No filler sentences. It is arguably too terse, 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 present, return values need no explanation, and annotations plus the cost/endpoint block cover operations. What is missing is the behavior of the `date` parameter (format, default-to-today semantics) and any routing signal among the five I Ching siblings, which is the main completeness gap for this tool.

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

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

The description adds no parameter information whatsoever, and coverage is 67% because the primary `date` parameter has no schema description and is not marked required. The agent is left guessing the date format and whether omitting it yields today's hexagram, which the description could easily have clarified. Only `fields` and `precision` are documented, and that documentation comes from the schema, not the description.

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

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

States the resource (hexagram) and its distinguishing scope ('per-date', 'deterministic'), which separates it from siblings like throw_coins (random) and by_question. It is a noun phrase rather than a verb+resource, and it never names the sibling alternatives explicitly, so an agent must infer the distinction rather than read it.

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 and no mention of the four sibling I Ching tools (astroway_iching, astroway_iching_by_question, astroway_iching_throw_coins, astroway_iching_lookup_number, astroway_iching_with_changing_lines). The 'per-date' qualifier only implies a daily use case; nothing tells the agent when this is preferable to the generic or question-based variants.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds genuinely useful non-annotation context: the HTTP endpoint, the group, and a cost caveat ('see your plan — endpoint not in the public credit manifest'). That cost/pricing note is the one real behavioral addition; no rate limits or result-shape notes beyond that.

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

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

The first sentence is front-loaded and complete, and the bracketed metadata lines are dense, scannable and free of filler. Minor redundancy between 'Fetch hexagram 1-64' and '[Required: number]' / the schema's 1-64 range, but overall tight.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety semantics. Endpoint, group, required parameter and a cost caveat are all supplied. The only real gap is the absence of any routing hint among the many I Ching siblings.

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

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

Schema description coverage is 100%, so 'number', 'fields' and 'precision' are already documented in the schema with ranges and examples. The description only restates the number parameter as required and King Wen ordered, adding no syntax or format detail beyond the schema. 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 states a specific verb and resource ('Fetch hexagram 1-64 by King Wen number') with an explicit lookup key and range, which is unambiguous on its own. It does not, however, distinguish this from the five sibling I Ching tools (throw_coins, by_question, daily, with_changing_lines), so it stops 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?

Usage is only implied by 'by King Wen number' — an agent must infer that this is the direct-number path rather than a cast/divination path. No alternatives are named despite astroway_iching, astroway_iching_by_question, astroway_iching_throw_coins and astroway_iching_with_changing_lines all being plausible destinations, and no when-not guidance is given.

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

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

Annotations already declare readOnly, non-destructive and idempotent, so safety is covered. The description's one genuinely additive fact is the cost (10 credits, Tier 1) plus the endpoint, but 'seeded' merely restates the idempotentHint rather than explaining determinism, randomness fallback, or output shape.

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

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

The prose is a single front-loaded sentence, with the remaining lines being compact structured metadata (group, endpoint, cost) rather than filler. Nothing is redundant, though the metadata block is more operational than descriptive.

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

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

An output schema exists, so return values need not be explained, and there are zero required parameters, making this a low-complexity call. Combined with annotations covering the safety profile, the definition supplies enough for an agent to invoke it, though the seed semantics remain thin.

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

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

Schema coverage is 67%: `fields` and `precision` are well documented in the schema, while `seed` has none. The word 'Seeded' in the description partially compensates by hinting that `seed` drives determinism, but it never states the accepted types or the effect of omitting it. Baseline 3 given the moderate 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?

"Seeded 3-coin method" signals an I Ching coin-toss divination, but it names neither the verb (cast/generate) nor the resource (hexagram) explicitly and never distinguishes itself from siblings like astroway_iching_with_changing_lines or astroway_iching_by_question. The name carries most of the meaning; the description adds only the 'seeded' qualifier.

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 — nothing says when to pick this over astroway_iching_daily, by_question, or with_changing_lines, nor what happens when no seed is supplied. The cost/group metadata 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 establish readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-annotation context (POST endpoint, 10-credit Tier 1 cost, group membership), which helps budget-aware routing, but says nothing about return behavior, rate limits, or what a 'transformed' result 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?

The bracketed metadata block is compact and easy to scan, and nothing is padded. However, the brevity is under-specification rather than economy — the single content sentence carries almost no information, so terseness here works against the tool.

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

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

For a divination tool sitting among five sibling I Ching endpoints, the description omits what changing lines produce, how it differs from astroway_iching, and what `seed` controls. An output schema exists so return values need not be described, but the remaining gaps leave an agent unable to confidently choose or parameterize this tool.

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

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

The description contributes zero parameter meaning. Schema coverage is 67%, and the uncovered parameter is `seed` (anyOf number|string), whose type ambiguity and purpose are left entirely unexplained; `fields` and `precision` are documented in the schema but the description does not reinforce or clarify them.

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

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

The description is a noun fragment, 'Primary + transformed hexagrams,' with no verb and no stated action, so an agent cannot tell it casts an I Ching reading rather than looking up or formatting data. It restates the title's notion of changing lines and adds a hint about output shape, but never distinguishes itself from siblings like astroway_iching, astroway_iching_throw_coins, or astroway_iching_by_question.

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 reference to any of the five sibling I Ching tools. The only selection-relevant signal is the embedded cost/tier metadata, which is informational rather than directive.

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?

Beyond the annotations, which already confirm readOnly, idempotent, non-destructive, and closed-world behavior, the description discloses rich domain-specific behavior: vowel points and cantillation are stripped, final letters count as ordinary forms in absolute value and as 500–900 in large value, and both results are returned rather than chosen.

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

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

The description is two efficient sentences plus clearly bracketed metadata, with the cipher list front-loaded and the final-letter rule immediately after. Every sentence carries distinct information with no redundancy.

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

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

An output schema exists, so return values need not be explained, and the annotations already carry the safety profile. The description supplies the remaining domain context—Hebrew text input, cipher behavior, and final-letter handling—while the schema covers the compact-mode parameters.

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

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

Schema coverage is 67%: fields and precision are documented in the schema, while text has no schema description. The description compensates by specifying that text is Hebrew, which is a meaningful constraint not present in the structured schema, though it adds nothing further for the other two parameters.

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

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

The description names a specific operation—seven standard gematria ciphers over Hebrew text—and lists the exact ciphers (absolute, large, small, ordinal, inclusive, AtBash, AlBam). This distinguishes it from sibling Kabbalah tools like sephiroth and shem names without ambiguity.

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

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

The description does not state when to select this tool over sibling Kabbalah or esoteric tools, nor does it name any alternatives or conditions that would favor it. Usage must be inferred entirely from the stated purpose, with no explicit 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, non-destructive and closed-world, so the safety profile is covered without the description. The description still adds genuine context beyond that: it clarifies the payload is a fixed reference table with no computation, and the metadata block discloses the endpoint and 5-credit cost.

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

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

The content claim is front-loaded in the first sentence, and the bracketed Group/Endpoint/Cost block is scannable metadata rather than prose. Slightly odd phrasing in "the response says so" is the only friction; nothing is padded.

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

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

An output schema exists, so return-value detail is unnecessary, and annotations cover the safety profile. Cost, endpoint, and the static nature of the lookup are all disclosed, leaving little an agent needs but would not find; only explicit sibling routing is missing.

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

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

Both parameters (fields, precision) are documented at 100% schema coverage, so the schema already carries their semantics (compact-mode field selection and decimal rounding). The description adds nothing about them, which is acceptable but earns only the baseline.

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

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

The description names the specific resource (the Tree of Life / ten sephirot) and enumerates exactly what the reference table contains: Hebrew, meaning, pillar, triad, and the Golden Dawn planetary attribution, grouped by pillar. This clearly separates it from the other Kabbalah siblings (gematria, shem_names), though it doesn't call those out by 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?

"Nothing here is computed" implies the tool is for static lookup rather than derived calculation, which is a usable hint about when to reach for it. But there is no explicit when-to-use, when-not-to-use, or named alternative among the Kabbalah sibling tools, so the guidance stays 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real context beyond them: the results are deterministically computed from a defined verse rather than table-sourced, plus the endpoint and a 5-credit cost that an agent should factor into budgeting. Return-shape details are rightly omitted since 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 core definition is front-loaded in one dense sentence, followed by a short filtering sentence, then templated group/endpoint/cost metadata. Little is wasted, though the bracketed boilerplate slightly dilutes the prose.

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

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

For a parameterless read-only lookup with an output schema, the description covers what the tool returns and how to filter it. Nothing essential is missing; the only gap is the absence of explicit sibling comparisons, which the group label partially compensates for.

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 of the two declared params (fields, precision) is 100%, so a baseline of 3 applies. The description goes further by documenting two filter parameters (index, longitude) with explicit ranges that are not declared in the schema, giving the agent usable selection syntax. This adds value, though the fact that these filters are undocumented in the schema itself is a mild inconsistency.

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

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

The description states a specific resource (the 72 three-letter Shem HaMephorash names) and adds a distinguishing provenance detail — computed from Exodus 14:19-21 rather than looked up. That scope is clearly separable from kabbalah siblings like sephiroth or gematria. It stops short of naming an alternative sibling, so it lands at 4 rather than 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?

It gives concrete filter guidance ('?index=1..72 or ?longitude=0..360'), which tells the agent how to narrow the call. It never says when this tool is preferable to the other Kabbalah or esoteric tools, so there is implied usage but no genuine when-to-use/when-not routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds operational context the annotations lack — the credit cost and the HTTP endpoint — but says nothing about the cost of repeated calls or response behavior.

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

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

The core sentence is tight and front-loaded, giving the meaning and cycle length in one line. The bracketed metadata block is terse and scannable rather than prose bloat, though it foregrounds plumbing (endpoint) over task guidance.

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

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

An output schema exists, so the description needn't explain return values. Coverage of purpose, the required parameter, cost, and endpoint is sufficient for a single-date calculator. The missing element is sibling routing, which is scored under usage guidelines.

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 67%: `fields` and `precision` carry their own descriptions (including the 'compact mode' semantics and the 14-vs-2 decimal note), and `date` is constrained by a regex pattern. The description adds nothing beyond restating that `date` is required, so baseline 3 is appropriate.

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

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

The description states a specific computation — combining the Tzolkin and Haab cycles into a unique 52-year Calendar Round label — with the concrete scope (18,980 days). It implicitly distinguishes itself from the sibling astroway_mayan_tzolkin and astroway_mayan_haab by naming them as the combined components, but it never explicitly frames the alternative choice.

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

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

The only routing signals are the '[Required: date]' and '[Cost: 10 credits]' tags. There is no statement of when to pick Calendar Round over astroway_mayan_full, astroway_mayan_long_count, or the single-cycle Tzolkin/Haab tools. The agent must infer the use case entirely.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context the annotations don't carry: the 10-credit cost, the POST endpoint, and the fact that a numeric 0-100 score is returned. It says nothing about failure modes or input validation, so it is adequate rather than rich.

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

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

The core sentence is front-loaded and dense, and the bracketed metadata lines (group, endpoint, required, cost) are compact and scannable. Minor redundancy in repeating the required parameters, but nothing is verbose or 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 needn't be explained, and the description still helpfully notes the 0-100 score. However, for a two-person nested-object tool it omits any when-to-use routing and leaves the person date inputs semantically unexplained, so it is minimally viable rather than complete.

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

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

Schema description coverage is 50%: fields and precision are documented in the schema, but person1/person2 (nested date objects with only a regex pattern) are not. The description merely restates 'Required: person1, person2', which the schema already declares, and adds no semantic detail about date format or the person objects, so it does not compensate for the coverage gap.

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

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

The description names a specific result (pair compatibility), the method (Tzolkin name + tone alignment plus elemental/directional affinity), and the output shape (0-100 score), which distinguishes it from sibling Mayan tools like tzolkin, haab, or full. It stops short of explicitly contrasting itself with those siblings, so it is clear but not fully differentiated.

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

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

No guidance on when to prefer this over astroway_mayan_full, astroway_mayan_tzolkin, or other compatibility-style tools. The only routing signal is the bracketed 'Required: person1, person2' metadata, which is not a usage condition.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, covering the safety profile. The description adds the credit cost/tier and frames the calculation as a modern reinterpretation, but adds little else about behavior beyond the annotations.

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

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

Front-loads the identity and return shape, then compact bracketed metadata for group, endpoint, required param, and cost. No wasted sentences, though the bracketed block is somewhat boilerplate.

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

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

With an output schema present and annotations covering the safety profile, the description only needs to establish identity, differentiation, and the required input, all of which it does. Cost/tier is a useful extra for an agent weighing calls.

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

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

Schema coverage is 67%: 'fields' and 'precision' are well documented in the schema, while 'date' only carries a regex pattern with no description. The prose adds no parameter meaning beyond the schema, so the baseline of 3 for mostly-covered params 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 (Dreamspell / Argüelles synchronometer) and its output shape (kin 1-260 + tone + seal). It also distinguishes itself from the traditional Tzolkin, which is the key sibling confusion in this group, though it doesn't name the sibling tool explicitly.

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

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

The phrase 'Distinct from traditional Tzolkin' implies when to choose this over the Tzolkin tool, but there is no explicit when/when-not guidance, prerequisites, or alternative routing. 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?

Read-only/idempotent safety is already covered by annotations, and the description adds genuinely new context: the endpoint, the required parameter, and a 10-credit Tier 1 cost. That cost disclosure is valuable for an agent deciding whether to call a composite endpoint. It does not, however, describe response shape or any rate-limit behavior.

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