AstroWay Chinese metaphysics

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description correctly focuses elsewhere: it discloses that the true-solar-time correction reaches only day and hour, never year or month, and that output is localised by language, plus a cost of 20 credits (Tier 2). These are non-obvious traits not present in 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?

Front-loads the payload contents, then gives the one operational caveat; every sentence adds information and the metadata block is compact. The first sentence is an admittedly long enumeration, but it is dense rather than redundant.

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

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

An output schema exists, so return values need no explanation, and the annotations carry the safety profile. Still, for a 14-parameter tool at 29% schema coverage, the description omits the meaning of several behavioural flags and any explicit routing versus the many bazi_* siblings, so an agent cannot call it optimally without more.

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%, so the description must carry weight, and it does explain the longitude/trueSolarTime interaction and language localisation. However, most parameters (gender, dayBoundary, stageSchool, includeLuck, includeFullTable, time, date) remain undocumented in both schema and description, leaving substantive gaps.

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

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

States a specific resource (the full BaZi four-pillar chart) and enumerates exactly what it computes: hidden stems, na yin, twelve stages, element balance, strength verdict, symbolic stars, and stem/branch interactions. The phrase 'in one call' signals it is the aggregate superset, which subtly separates it from the sibling subset tools (bazi_hidden_stems, bazi_na_yin, bazi_strength, etc.), though it never names an alternative outright.

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

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

Gives real when-to guidance for one decision – pass longitude with trueSolarTime true to derive the double-hour from the sun – but offers no routing between this aggregate and the individual bazi_* subset tools that return the same components. Usage is implied by 'everything ... in one call' 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-annotation context - the endpoint, the required input, and the 10-credit Tier 1 cost - but says nothing about accuracy caveats (e.g. how dayBoundary or trueSolarTime affect the derived day master), which matters for a BaZi computation.

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

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

Two front-loaded sentences that state the returned content first, followed by a compact metadata block. Little waste; the structure is efficient for scanning.

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 elaboration, and the description adequately frames the payload. However, for a 10-parameter astrological computation it leaves key gaps: no guidance on sibling selection and no explanation of the parameters that alter the day master calculation.

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

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

Schema description coverage is only 40%, and the description contributes nothing beyond restating that 'date' is required. Parameters that materially change a BaZi day master - dayBoundary, trueSolarTime, timezone, and the undocumented 'time' and 'language' - get no explanation here, so the description fails to compensate for the coverage gap.

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

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

The description names the concrete output (day stem element, yin/yang polarity, canonical archetype) and frames it as 'the self character in BaZi from which all other pillars are interpreted,' which lets an agent distinguish it from broader outputs like bazi_four_pillars. It lacks an explicit action verb, but the resource and returned payload are unambiguous.

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

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

Beyond the metadata line '[Required: date]', there is no guidance on when this tool is preferable to siblings such as bazi_four_pillars, bazi_chart, or bazi_strength. The 'self character' framing implies a use case but names no alternatives or exclusion conditions.

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

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

With readOnly/idempotent annotations already covering safety, the description adds genuine behavioral context: the three counting methods (visible, hidden stems, weighted), the RFC 8594 Deprecation and Sunset headers, and the exact date the deprecated fields stop answering. That is real value beyond structured fields, though rate/cost behavior is only in the meta block.

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 dense but front-loaded sentences carry the substantive information, followed by a compact structured meta block with endpoint, required param, and cost. Nothing is padding, though the second sentence is long and mixes several ideas.

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 deprecation and counting semantics are well covered. The remaining gap is input-side: for a 14-parameter tool at 29% schema coverage, the definition supplies almost nothing about the non-required inputs an agent might need to set.

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% across 14 parameters, so the description must compensate and largely does not. It notes only that `date` is required; it says nothing about time, timezone, gender, dayBoundary, trueSolarTime, stageSchool, or the compact-mode fields, leaving most parameters undocumented in either place.

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 verb+resource ('Element balance across the whole chart') and is scoped to the BaZi group tag. It distinguishes itself from siblings like hidden_stems and day_master by describing exactly what it counts. It does not explicitly contrast itself against the closest siblings, keeping it short of a 5.

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

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

There is no statement of when to use this tool versus the many BaZi siblings (chart, four_pillars, strength, hidden_stems). The group tag and '[Required: date]' imply context, but no condition or alternative is ever spelled out.

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/finite-world, so the safety profile is covered. The description adds real behavioral depth beyond that: the 60-jiazi anchor (1990-01-01 = Bing-Yin) and the exact boundary rules — day/hour rolling at 23:00 local, year/month at Lichun and 節 instants — which are the edge cases that actually change results. 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?

Two dense sentences that front-load output scope, then methodology, then boundary behavior; the metadata footer is compact. No filler, though the astronomical caveats make the second sentence long.

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

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

An output schema exists, so return values need not be described, and annotations cover safety. For a single-date computation tool the description supplies the key semantics (input shape, pillar scope, boundary rules). The one residual gap is that '23:00 local' is not tied explicitly to the timezone/timezoneOffset 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 57% (time, date, and language have no schema descriptions), so the description carries part of the load: it clarifies that `time` drives the hour pillar and that day/hour boundaries are 23:00 local. It adds nothing for `language` and only partially ties the 23:00 boundary to the timezone/timezoneOffset parameters.

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

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

States a concrete output ('All four pillars: year, month, day, hour') for a named resource, and the phrase 'All four pillars' implicitly contrasts with the sibling single-pillar tools (bazi_year_pillar, bazi_month_pillar, bazi_hour_pillar). An agent can distinguish it from the per-pillar siblings without opening the schema.

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

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

'Pass `time` to compute the hour pillar' is a genuine conditional usage hint. However there is no explicit when-to-use statement versus alternatives such as astroway_bazi_chart or the individual pillar endpoints, and no stated exclusions. Usage is implied rather than spelled out.

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, closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: it discloses the storage-branch quirk where the middle role belongs to the stored element rather than the second list entry, which warns the agent about a non-obvious output layout. It stops short of describing permissions, cost, or caching, but the metadata block supplies the cost.

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

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

Three front-loaded sentences, each carrying content: what is returned, why it matters, and one edge-case caveat. The vivid 'soaked in Water' line earns its place by motivating use. The structured metadata footer is compact and does not pad the 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?

Return values need not be explained because an output schema exists, and the output semantics are described well. However, for a 14-parameter computation tool, the description gives no guidance on which optional BaZi switches to set or what the required input is beyond the footer, leaving the input side 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 description coverage is only 29% across 14 parameters, and the prose mentions no parameter at all — the reader learns only from the metadata footer that `date` is required. Domain-specific inputs such as dayBoundary, stageSchool, trueSolarTime, and includeFullTable are left entirely to the sparse schema, so the description fails to compensate for the coverage gap.

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

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

Names a specific resource — the one-to-three hidden stems sheltered in each BaZi branch, with role and weight — and the description makes clear this is the elementally meaningful layer of the chart. It is more specific than the title alone, but it never distinguishes itself from the many BaZi siblings (bazi_chart, bazi_four_pillars, bazi_element_balance), so an agent must infer which computes the same layer.

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 remark that 'this is where most of a chart's elements live' implies the tool is the right one when hidden element counts matter, but no explicit when-to-use, when-not, or alternative tool is named. With ~20 BaZi siblings, routing guidance is the missing piece.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description still adds genuinely behavioral content beyond that: the explicit day-boundary convention that the Zi hour opens the day at 23:00 local time, which changes computed results at the day edge. It stops short of error behavior or what happens with ambiguous/skipped local times.

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

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

Two tight sentences front-loading the method and the boundary rule, followed by a compact bracketed metadata block. The 'Required: date, time' line duplicates the schema's required array, which is the only real waste; group, endpoint and credit cost are non-redundant and useful.

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

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

With 7 parameters, an output schema and full annotations, the main remaining gap is orienting the agent on time input: an hour pillar is only well defined once the local-hour convention and the timezone/timezoneOffset choice are resolved, and the description only alludes to 'local time' without saying which parameter governs it. Return values need not be explained since an output schema exists. Adequate but not complete for a time-sensitive calculation tool.

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

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

Schema description coverage is 57%, in the middle band. The description only echoes the required list ('Required: date, time'), which the schema already encodes, and adds nothing about how timezone or timezoneOffset interact with the hour boundary — arguably the most consequential semantic for an hour-pillar tool. The richer timezone, timezoneOffset, fields and precision semantics are all carried by the schema, so a baseline 3 is appropriate.

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

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

States a specific computation and its algorithm: the hour pillar derived via the 五鼠遁 (Five-Rats-Escape) day-stem → hour-stem table, plus the Zi-hour day boundary rule. That is far more specific than the bare name 'Hour Pillar'. It never names or contrasts the obvious siblings (astroway_bazi_year_pillar, astroway_bazi_month_pillar, astroway_bazi_four_pillars), so sibling differentiation is left 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?

No when-to-use guidance at all. The description does not say to prefer this over astroway_bazi_four_pillars when all four pillars are wanted, nor when a standalone hour pillar is appropriate, nor what date/time combination is meaningful. The only procedural hints are the metadata lines (endpoint, required params, cost), which are call mechanics rather than usage guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered without the description. The description adds useful output-shape context (pillars involved, resulting element) and the metadata block discloses a 10-credit cost, but it says nothing about authentication, whether a full birth time/location is needed for meaningful results, or any limits on the interaction set.

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 dense sentence front-loads the enumerated interaction types, and the bracketed metadata (group, endpoint, required param, credit cost) is compact and scannable. No filler, though the metadata lines are boilerplate shared across the whole BaZi family.

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

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

An output schema exists, so return values need not be explained, and the description correctly sketches what comes back. However, for a 14-parameter tool with 29% schema coverage and a single required parameter, the description leaves the agent without enough to know which optional inputs change the result or how this relates to its many BaZi 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 only 29% across 14 parameters, so the description should carry the burden — and it explains none of them. It never clarifies why time, timezone, longitude, gender, dayBoundary, stageSchool, trueSolarTime, includeLuck or includeFullTable matter for an interactions lookup, nor does it reconcile 'present in the chart' with a schema whose only required input is a date.

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 content the tool computes — stem combinations, six harmonies, full and half trines, clashes, harms, punishments, self-punishments — plus the pillars involved and the element a combination produces. That is far more informative than the title 'Branch and stem interactions'. It stops short of differentiating itself from sibling BaZi tools (bazi_chart, bazi_four_pillars, bazi_hidden_stems), so it does not reach 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 or when-not-to-use guidance. An agent cannot tell from the description whether this should be called alongside astroway_bazi_chart or astroway_bazi_four_pillars, or whether the chart is derived internally from the single required date. The credit-cost note is metadata, not routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds only that a full ten-by-twelve reference table can be requested and that stageSchool selects a calculation rule; it says nothing about output shape, cost implications beyond the context tag, or limitations. Adequate but thin on 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?

Three compact sentences, front-loaded with the concept and then the two tool-specific options. No filler, though the jargon-heavy phrasing ('Chang Sheng ... Di Wang ... Jue') is dense for an agent that may not know the terms.

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

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

With an output schema present, return values need not be explained, and annotations cover the safety profile. What remains missing is how this tool relates to the dense cluster of BaZi siblings and what the single required date parameter actually drives — enough gaps to fall short of 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 only 29% across 14 parameters, so the description must compensate. It does supply real meaning for the two most tool-specific parameters (includeFullTable returns the reference table; stageSchool chooses classical yin-reverse vs unified), but the other twelve parameters, including date and dayBoundary, get no added interpretation.

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 gestures at the concept — 'a stem read against each branch as a life cycle' — and names the day master, but it never states plainly that the tool returns the twelve life stages of the day master through the chart. It leans on domain jargon that overlaps heavily with siblings like astroway_bazi_strength and astroway_bazi_day_master without distinguishing itself.

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 explains two options (includeFullTable, stageSchool) but gives no guidance on when to choose this tool over the many other BaZi endpoints. There is no when-to-use or when-not-to-use framing and no mention of the required date or that the result is chart-wide rather than per-pillar.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the bar is lower. The description adds genuinely non-structured operational context: the POST endpoint, a 10-credit Tier 1 cost, and the deterministic rule ('direction by gender + year-stem polarity per Ziping canon'), which tells the agent the result is computable rather than interpretive.

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

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

Front-loaded with the core purpose in the first sentence, followed by compact bracketed metadata lines. No filler, though for a 12-parameter tool the space saved is partly paid for by missing parameter guidance.

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

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

An output schema exists, so return values need not be explained, and required inputs plus cost are stated. However, with 12 parameters, low schema description coverage, and a dense field of near-named BaZi siblings, the definition leaves an agent unable to distinguish intent or set pragmatic options like count or dayBoundary.

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

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

Schema description coverage is 33%, below the 50% threshold, so the description is expected to compensate and does not. It names only date and gender, both already required and documented in the schema, and says nothing about count, dayBoundary, trueSolarTime, longitude, or language, all of which materially change the pillars produced.

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 concrete resource and scope: a '10-year luck pillars sequence' (Da Yun), which is a specific BaZi artefact rather than a generic chart. It does not, however, disambiguate against closely named siblings such as astroway_bazi_year_pillar_decade or astroway_bazi_yearly, which an agent could easily confuse with a decade-length sequence.

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

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

The only usage information is '[Required: date, gender]', which merely restates the schema's required list. There is no statement of when to reach for this tool versus the other 20+ astroway_bazi_* tools, no exclusions, and no prerequisites such as needing an existing chart.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive safety. Beyond that the description adds a non-obvious methodological fact (month branch resolved via mid-month jieqi) and the cost of 10 credits at Tier 1, which materially affects invocation. It does not cover auth or response shape, but the output schema exists so that is less critical.

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

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

The purpose sentence is front-loaded, followed by compact bracketed metadata for group, endpoint, required params and cost. Every element earns its place with no redundancy.

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

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

For a 12-parameter tool the definition gives purpose, endpoint, required inputs and cost, and an output schema exists to cover return values. However, the low parameter coverage means an agent is left without guidance on timezone, dayBoundary, trueSolarTime or natalTzOffset, which are the semantically tricky inputs 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 only 33% (four of twelve params documented), so the description carries the burden of compensating for the undocumented parameters, but it does not. It merely restates the three required parameters already declared in the schema's required list, adding no syntax, format, or interaction 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 names the analytical technique (Sheng-Ke + branch-clash) and the scope that differentiates it (a specific calendar month, resolved via mid-month jieqi). It anchors itself to astroway_bazi_yearly, so an agent can tell it apart from the year-scoped sibling. The only weakness is that it is defined relatively to the yearly tool rather than standing on its own.

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 month scope implies when this tool is appropriate versus a yearly or daily forecast, but usage is only implicit. There are no explicit when/when-not statements and no routing to alternative BaZi forecasting siblings. Adequate but leaves the agent to infer selection.

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

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

Annotations already declare a safe read (readOnlyHint, idempotentHint, non-destructive), so the bar is lower. The description still adds real behavioral context: the value is derived from solar-term boundaries rather than calendar months, and it discloses the endpoint and a 10-credit cost. It does not disclose how time/timezone affect boundary resolution.

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 behavior, then a compact bracketed metadata block covering group, endpoint, requirement, and cost. Every line carries a distinct fact; 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 values need no explanation, and the cost/endpoint metadata is present. For a solar-term-boundary calculation, though, the description never explains that the result depends on exact local time and timezone, nor does it distinguish itself from astroway_bazi_monthly — a meaningful gap for correct invocation.

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

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

Schema description coverage is 57%, mid-range, and the description only repeats the required flag for 'date' — information already in the schema's required array. It adds no syntax, format, or defaulting guidance for time, language, or the boundary-critical timezone parameters, 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?

States a specific resource ('Month stem + branch') and a distinguishing mechanism ('from solar-term boundaries'), which sets it apart from astroway_bazi_year_pillar and astroway_bazi_hour_pillar by name. It does not, however, clarify its relationship to the confusingly similar sibling astroway_bazi_monthly or to astroway_bazi_four_pillars.

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 name and by '[Required: date]' and the credit cost line, so an agent knows the minimum to invoke it. There is no explicit when-to-use vs. when-not guidance, and no routing between this tool, astroway_bazi_monthly, astroway_bazi_chart, and astroway_bazi_four_pillars, which overlap heavily 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 readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds domain content (how the 60 jiazi map to 30 na yin names) but says nothing about defaults, required inputs beyond the footer metadata, or response shape, so it neither undercuts nor richly extends the annotations.

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

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

Two tight sentences, front-loaded with the core concept and followed by the disambiguating clarification. No filler, though the definition of the jiazi collapse is arguably more domain color than operational guidance.

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

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

For a 14-parameter BaZi endpoint the description supplies no routing context against ~30 bazi siblings and no parameter guidance, leaving the agent dependent on a mostly unannotated schema. The output schema existing means return values need not be described, but the usage and input gaps remain large.

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?

Fourteen parameters at 29% schema description coverage, and the description never mentions any of them (date, time, timezone, precision, dayBoundary, stageSchool, etc.). The footer's '[Required: date]' only restates schema data, so the description does not compensate for the large uncovered parameter surface.

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 what is computed (the na yin sound-element of each pillar) and explains the underlying domain rule (60 jiazi collapse into 30 names, two consecutive pillars per name). It also explicitly disambiguates from the common confusion with the day master, which differentiates it from the many other bazi sibling tools that return pillars.

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 rather than stated: the note that na yin 'is not the day master' indirectly tells an agent not to reach for this when the user wants their day master, but there is no explicit when-to-use, when-not-to-use, or named alternative among the dense bazi sibling set (year_pillar, four_pillars, day_master).

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lowered. The description adds real value beyond that: it discloses that the weighting applies to hidden stems, that the three classical criteria are reported unweighted, and two explicit caveats (month treated like any other branch, cut points being an API convention). That is meaningful methodological transparency.

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 densely packed sentences that front-load the core computation before the caveats, followed by terse bracketed metadata. Nothing is wasted, though the technical jargon makes it harder to scan than it could 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?

For a 14-parameter tool with 29% schema coverage, the description should orient the agent on the key options that change the result, but it is silent on all of them. It correctly omits return-value explanation since an output schema exists, and it does not guide tool selection against the many BaZi siblings, leaving substantial gaps.

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

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

Schema description coverage is only 29%, so the description must carry weight but does not. None of the 14 options (dayBoundary, stageSchool, trueSolarTime, includeLuck, includeFullTable, gender, timezone, etc.) are explained or even alluded to; the only hint is the passing remark about how the month is counted. 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 concrete computation: a support-and-suppress reading over the weighted hidden-stem count, plus three classical criteria (season, root, allies) reported unweighted. An agent can tell what is produced. It stops short of differentiating from obvious siblings such as astroway_bazi_day_master or astroway_bazi_element_balance, which overlap thematically.

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

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

There is no when-to-use guidance, no prerequisites beyond the bracketed 'Required: date', and no mention of any alternative tool. The methodology caveat explains limits of the calculation but does not help an agent decide whether this tool or a sibling is the right call.

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

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

Annotations already establish the safe read-only/idempotent profile, so the bar is lower, and the description adds real behavioral detail: stars are computed from both year and day pillars, and when transmissions disagree both placements are returned with cross-references. That tells the agent to expect duplicate/paired placements, which is non-obvious output 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 star list is front-loaded, the rationale follows, and the trailing metadata block (Group, Endpoint, Required, Cost) is compact and scannable. The disagreement sentence is slightly convoluted but each part earns its place; no filler.

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

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

An output schema exists, so return values need not be explained, and the description covers what is computed and how ambiguity is handled. However, for a 14-parameter endpoint with low schema coverage, the absence of any parameter or usage context leaves meaningful gaps.

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

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

With 14 parameters and only 29% schema description coverage, the description carries a heavy compensation burden, yet it says nothing about any parameter (date, time, timezone, gender, school options). The structured schema describes a handful (fields, precision, timezone, timezoneOffset), but the description contributes zero parameter meaning.

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 concrete resource (Peach Blossom, Travelling Horse, Canopy, Heavenly Nobleman, Blade and Void) and states exactly what it computes (Shen Sha from the year AND day reference pillars). An agent can distinguish this from sibling BaZi tools like ten_gods or na_yin. It stops short of a crisp verb-first statement of purpose, but the resource and computation are unambiguous.

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

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

There is no when-to-use guidance or routing to alternatives. The description explains internal computation logic (why both pillars are read) but never tells the agent the conditions under which this tool should be selected over bazi_chart, bazi_four_pillars, or other Shen Sha-adjacent endpoints.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description usefully adds operational context the annotations do not carry: it is a POST endpoint and costs 10 credits (Tier 1). It says nothing about output shape or how sensitive the result is to the time/timezone inputs.

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

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

Front-loads the purpose and the five god pairs in two tight lines, then a compact metadata block. The pinyin glossary is dense but on-topic and earns its space; nothing redundant is present.

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 cover the safety profile. However, given a 10-param chart tool whose accuracy hinges on time/timezone/day-boundary choices, the description supplies no guidance on which inputs matter and no contextual framing beyond cost and endpoint.

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

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

With 10 parameters and only 40% schema description coverage, the description is expected to compensate and does not. It merely restates that date is required (already in the schema) and never explains BaZi-critical inputs such as dayBoundary (23:00 vs midnight) or trueSolarTime, which materially change the classification.

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

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

Names a specific analysis (Ten Gods / Shi Shen classification relative to the day master) and enumerates the actual categories computed, so an agent knows precisely what is returned. It does not, however, name or contrast itself with the many adjacent BaZi siblings (chart, day_master, hidden_stems, element_balance), leaving differentiation 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?

No when-to-use guidance at all: no statement of prerequisites (e.g. that day master/date must be known), no conditions for preferring this over astroway_bazi_day_master or astroway_bazi_element_balance, and no exclusions. The metadata block gives endpoint/cost but nothing about workflow context.

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 usefully adds the 10-credit Tier 1 cost and the analytical nature of the output, but says nothing about determinism, auth requirements, or rate behavior beyond what annotations imply.

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

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

The core computation is front-loaded in one dense sentence and the metadata block is compact and scannable. The bracketed lines are slightly repetitive of schema-level facts but earn their place by surfacing cost and endpoint.

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 13-parameter analytical tool, purpose and cost are well covered and an output schema exists so return values need not be re-explained. However, usage context versus siblings and the semantics of the many optional BaZi parameters remain unaddressed.

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

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

Schema coverage is only 31% across 13 parameters, so the description must compensate, yet it only names the two required fields (natalDate, targetYear). Meaningful parameters such as dayBoundary, trueSolarTime, includeMonths, gender, and natalTime receive no explanation here or in the schema.

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

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

States a specific operation: comparing the target year pillar against the natal day master and natal year branch, and names the exact outputs (element-flow relation, branch clashes, trine support). It is clear what the tool computes, but it never distinguishes itself from close siblings like astroway_bazi_year_pillar, astroway_bazi_year_pillar_decade, or astroway_bazi_monthly.

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

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

No when-to-use or when-not-to-use guidance is given. The bracketed metadata supplies required params, endpoint and credit cost, but nothing tells an agent when to reach for this over the year_pillar or monthly siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description contributes the cost tier (10 credits, Tier 1) and the endpoint, which are useful operational facts not present in the annotations, but says nothing about whether the result is deterministic across timezone settings or how time/timezone affect the pillar.

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 output summary is front-loaded in one line and the bracketed metadata block is compact and scannable. Nothing is padded, though the boilerplate labels (Group/Endpoint/Required/Cost) consume most of the description's real estate relative to actual explanation.

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 fairly excused, but the central ambiguity remains unresolved: whether `date` is the subject's birth date or the calendar year being inspected, and how `time`/`timezone` interact with that. For a 7-parameter tool with partial schema coverage and several confusable siblings, the definition leaves too much to inference.

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

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

Schema description coverage is only 57%, and the three undocumented parameters are the semantically critical ones: date (no description at all — birth date vs. target year is ambiguous), time, and language. The only param-related text, 'Required: date', merely restates the schema's required array and adds no meaning.

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 line names a specific output bundle — year stem, branch, animal, element, yin/yang — for the BaZi year pillar, which is a concrete verb+resource an agent can recognize. It does not, however, contrast itself with near-identical siblings like astroway_bazi_month_pillar, astroway_bazi_hour_pillar, or astroway_bazi_year_pillar_decade, so the agent must infer the distinction from the name alone.

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

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

The definition never says when to pick this tool over astroway_bazi_four_pillars or astroway_bazi_chart, nor what question it answers. The only routing-style hints are boilerplate ('Required: date', 'Cost: 10 credits'), which tell the agent nothing about appropriate usage.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context in the form of a cost (10 credits, Tier 1) and the backing endpoint, but says nothing about rate limits, auth requirements, or how the 10-year window behaves at the schema's 2100 upper bound.

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 behavior in one sentence, followed by compact bracketed metadata (group, endpoint, required, cost). Nothing is padded, though the bracket block is closer to boilerplate than prose.

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

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

An output schema exists, so return-value explanation is not required, and annotations cover safety. What's missing is routing context among the many BaZi siblings (year vs decade vs luck pillars) and any note on the `language` parameter, leaving the definition merely adequate for a 4-parameter, credit-consuming call.

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

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

Schema description coverage is 50%: `fields` and `precision` are documented in the schema, while `language` and `startYear` are not. The description only repeats '[Required: startYear]' (already in the schema's required array) and adds no semantics for `language` or the decade windowing, so it fails to compensate for the coverage gap.

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

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

The first sentence names a concrete output (10 consecutive year pillars) and the input that drives it (a starting year), so an agent knows exactly what it gets. It does not, however, distinguish itself from the close sibling astroway_bazi_year_pillar (single year) or explain why one would want the decade form over repeated single calls.

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

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

There is no when-to-use guidance, no mention of the single-year sibling, and no stated prerequisites or exclusions. The bracketed '[Required: startYear]' restates the schema rather than advising usage.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral context beyond them: the year boundary is Li Chun computed from the exact solar term, and the cost/endpoint metadata is stated. It does not discuss how inputs are resolved (date vs year, timezone vs offset).

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 with the core output list front-loaded, then the optional monthly layer, then the year-boundary rule. Nothing is padded, though the trailing group/endpoint/cost block is boilerplate rather than description content.

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

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

An output schema exists so return values need no explanation, and annotations carry the safety profile. What is missing is input-side guidance: with zero required parameters and 44% schema coverage, an agent gets no help deciding whether to send date, year, or both, or whether to prefer timezone over timezoneOffset.

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 44% with nine parameters. The description explains only two loosely (the solar year -> year, and the monthly layer -> includeMonthly); it says nothing about how date/time interact, and nothing about fields, precision, language, timezone or timezoneOffset, 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 resource (the nine annual stars for a solar year) and enumerates the outputs (Tai Sui, Sui Po, San Sha, five yellow, two black with their sectors), which clearly separates it from the adjacent flying-star, bagua and kua tools. It stops short of naming any sibling explicitly, so an agent must still infer the boundary from the field list rather than from a direct contrast.

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

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

The only usage signal is 'Optionally the monthly layer,' which implicitly maps to includeMonthly. There is no when-to-use statement, no mention of when this is preferable to astroway_chinese_feng_shui_flying_star or the tong-shu tools, and no prerequisites 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 and destructiveHint=false, so the safety profile is fully covered. The description block adds genuinely useful non-annotation context in the cost (10 credits, Tier 1) and required-input line, but says nothing about how the mapping is computed or what a 'sector' assignment implies.

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 that delivers the core meaning with no filler. The parenthetical enumeration of all nine life areas is long but is the substance of the tool rather than padding.

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

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

An output schema exists, so return values need no explanation, and the description adequately frames what is produced. What is missing for a nine-parameter, paid computation tool is any pointer on when this reading is the right one versus the sibling feng-shui tools, leaving the agent to guess from names alone.

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 44% across nine parameters, and the description does not compensate: it restates the two required inputs already declared in the schema's required array and adds no meaning for time, language, precision, solarYear, timezone or timezoneOffset. A low-coverage schema needed help here and did not get it.

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 (Bagua mapping of nine named life areas onto compass sectors) and pins the school ('Eastern-school'), which separates it from the kua and flying-star siblings. It never names a sibling it should not be confused with, and the verb is implicit ('mapping') rather than an action, 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?

No when-to-use guidance and no routing against the four closest siblings (feng_shui_kua, lucky_directions, flying_star, annual_stars). The only contextual facts, required date/gender and 10-credit cost, come from the metadata lines rather than usage direction.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is lighter. It usefully adds the behavioral fact that both key inputs must be supplied explicitly ("Neither is defaulted") and states the chart contents, which is genuine context 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?

Two sentences: the first front-loads the output contents, the second the input requirements. No filler, no restating the title, and the most decision-relevant constraint ('Neither is defaulted') lands last for emphasis.

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 10 params, an existing output schema, and annotations carrying the safety profile, the description only needs to cover essential inputs, which it does for facing and period. Minor gaps remain for the auxiliary fields (fields, precision, language, timezoneOffset), but none of these are decision-critical for selecting or calling the tool.

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

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

Schema description coverage is only 30% across 10 params, so the description must compensate, and it does for the critical fields: it explains that facing can be degrees or one of the 24 mountains (mapping the facing/facingMountain duality) and that period can be given directly or derived from the occupation date (period/occupiedDate). This resolves the main input ambiguity not documented in the schema, though language/precision/fields/timezoneOffset remain unaddressed.

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

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

The description names the specific artifact (nine-palace Flying Star natal chart of a building) and enumerates its distinctive contents (mountain/period/facing star per sector, the named arrangement, special patterns), which clearly separates it from feng-shui siblings like annual_stars, bagua, kua, and lucky_directions. It is explicit about what it produces, though it never directly contrasts itself with those siblings.

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

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

Usage is implied rather than stated: it tells you to supply the facing as degrees or a named mountain and the period directly or via the occupation date, and warns that neither is defaulted. There is no explicit 'when to use this vs. alternatives' or prerequisite guidance, so an agent must infer the scenario.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful context in billing (10 credits, Tier 1) and endpoint/grouping, but says nothing about whether results are cached, what happens with time/timezone inputs, or any other runtime trait.

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 dense sentences front-load the purpose, followed by a structured metadata block with group, endpoint, required params, and cost. Every element earns its place; 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 values need not be described, and annotations cover safety. For a 9-parameter billing tool the description is sufficient to select and invoke, but the absent usage routing and undocumented optional parameters leave it 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 description coverage is only 44%, so the description must compensate. It does clarify the two required inputs meaningfully: date is interpreted as a solar year (digit sum) and gender drives the calculation. But seven optional parameters (time, fields, precision, language, timezone, timezoneOffset, solarYear) get no explanation anywhere, leaving a real gap.

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

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

States a specific verb+resource: computes a Personal Kua number from solar-year digit sum plus gender and maps it to East/West group. An agent knows exactly what it produces. It doesn't explicitly differentiate itself from close siblings like bagua or lucky_directions, though the 'Kua' term and 'for direction work' hint at the relationship.

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

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

No when-to-use, when-not, or alternative guidance is given. The phrase 'for direction work' implies the output feeds feng shui direction analysis but never names lucky_directions or bagua as the downstream/follow-up tool. Required params and cost are listed as metadata, not usage reasoning.

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 genuinely useful operational context beyond that: the credit cost (10 credits, Tier 1), the HTTP endpoint, and the required inputs. It does not describe output shape, but an output schema exists so that burden is carried elsewhere.

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 tight, with metadata neatly bracketed below. Nothing is wasted, though the bracket block is mostly transport/bookkeeping rather than agent-facing guidance.

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

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

For a 9-parameter tool with an output schema and full safety annotations, the description covers the essentials but leaves the optional parameters and the Kua derivation dependency unexplained. An agent can call it correctly with the two required fields, but would not know how to use or omit the rest.

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 44% and the description compensates poorly: it merely restates the two required params (date, gender) already enforced by the schema's required array, and mentions 'from Kua' without explaining how the Kua number is derived. The five-plus optional params (time, timezone, fields, precision, solarYear, timezoneOffset) get no semantic help.

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: it returns four lucky and four unlucky compass directions derived from the Kua number via standard Pa Kua mapping. This is clear enough to distinguish from generic chart tools, though it never names or contrasts with the close siblings like astroway_chinese_feng_shui_kua or astroway_chinese_feng_shui_bagua.

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

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

There is no when-to-use guidance, no statement of when to prefer this over the Kua or Bagua tools, and no prerequisite explanation (e.g. that a Kua number must first be derived). The agent is left to infer usage entirely from the group label and endpoint.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context not in annotations: the exact output scope (lunar month/day, leap-month flag, Chinese New Year) and the cost line (10 credits, Tier 1), which informs budgeting. It does not discuss edge cases such as what happens near a day boundary or in a non-China timezone.

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 that names the conversion and the two value-adds, followed by compact bracketed metadata. No filler sentences; the metadata block is boilerplate but terse and useful for cost/endpoint discovery.

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 shape need not be explained, and the description does sketch its scope. What is missing is how the optional temporal parameters affect the answer — whether the lunar day is derived from the supplied `time`/`timezone`/`timezoneOffset` — which is the one thing an agent cannot get from the schema alone.

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 a middling 57%, and the description contributes nothing beyond the schema: it repeats only that `date` is required. The six optional parameters (time, timezone, timezoneOffset, precision, fields, language) get no mention, and for a calendar-conversion tool the timezone assumption materially changes the result, so that silence is a real gap.

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

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

States a specific verb+resource: converts a Gregorian date to its Chinese lunar month and day, plus leap-month detection and that year's Chinese New Year. This is clearly distinct from most siblings (e.g. bazi chart builders, tong shu). However it never names the closest relatives (astroway_calendar_lunar_calendar, astroway_chinese_solar_terms), so the agent must infer the boundary itself.

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 tool is named. The only usage signal is the bracketed [Required: date], which is a schema restatement rather than routing advice. An agent could easily confuse this with astroway_calendar_lunar_calendar.

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

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

Annotations already declare this a read-only, idempotent, non-destructive, closed-world call, so the safety burden is lifted. The description earns credit by adding context the annotations don't carry: the output is exact instants expressed in both UTC and Beijing time, and it explains the astrological role of the two groups of twelve terms. It says nothing about pagination or volume, but with an output schema present that is largely redundant.

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 dense sentences lead with the resource and scope, followed by compact bracketed metadata for endpoint, required input, and cost. Every line carries signal — no filler, no restated name/title padding.

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

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

For a read-only list endpoint with one required parameter, an output schema, and full annotation coverage, the description supplies what an agent needs: what is returned, in which time representations, and why the two halves of the list differ. The remaining gap is the undocumented `language` parameter, which is left to inference.

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

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

Schema coverage is only 50%: `fields` and `precision` are documented in the schema, while `year` and `language` have no schema descriptions. The description confirms `year` is required and that the scope is one solar year, but never clarifies the accepted year range (2–2899) or what `language` controls. It compensates only partially for the coverage gap, so the 3 baseline 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 — the 24 solar terms of a Chinese solar year — and specifies the return form (exact instants in UTC and Beijing time). This is distinctly more than a restatement of the title. It stops short of naming any sibling tool (e.g. astroway_chinese_lunar_date or astroway_calendar_ingresses) to draw the boundary, so it lands at clear-but-undifferentiated.

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 second sentence implies the domain of use — solar terms matter because twelve open a BaZi pillar month and twelve decide leap months — which hints at when an agent would want this. But it gives no explicit when-to-use, no contrast with alternatives, and no stated preconditions. Usage is inferred, not prescribed.

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

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

Annotations already declare the full safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the bar for the description is lower. It adds the cost tier ('10 credits (Tier 1)') and the endpoint, which are genuinely useful behavioral facts, but says nothing about determinism, rate limits, auth, or what happens when optional time/timezone inputs 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?

The payload is a single front-loaded sentence that leads with the tool's identity before listing returned fields, and the bracketed metadata block is compact. The enumerative sentence is dense but every clause names a distinct output, so little is wasted.

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

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

An output schema exists, so return values needn't be re-explained, and the annotations cover the safety profile. However, for a 7-parameter day-reading tool sitting next to a near-namesake 'tong_shu_select', the description omits the one thing an agent most needs: which of the two to call and in what situation.

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

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

Schema description coverage is only 57%, and four parameters (fields, timezone, precision, timezoneOffset) carry rich descriptions while date, time, and language carry none. The description adds zero parameter semantics to close that gap — it never explains the expected date format, what 'time' does for a day-level reading, or which language values are accepted — so the undocumented parameters remain ambiguous.

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 almanac reading of one day) and enumerates its contents precisely: day pillar, day officer (建除十二神) with endorsements and prohibitions, the 28 mansion with quadrant and planet, and the clash animal. That is far more specific than the title. It does not, however, distinguish this from the sibling astroway_chinese_tong_shu_select, so an agent cannot tell which of the two to pick from the text alone.

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

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

There is no statement of when to use this tool, no contrast with astroway_chinese_tong_shu_select or astroway_chinese_lunar_date, and no exclusions or prerequisites. The only usage-adjacent facts are the metadata lines 'Required: date' and the credit cost, which are structural 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, and the description adds genuinely new behavior: a 366-day hard cap that is refused rather than truncated (explicit error semantics) and a 20-credit Tier 2 cost. It stops short of documenting other failure modes, but the refusal-vs-truncation disclosure is exactly the kind of non-obvious trait that matters.

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

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

Two tight sentences with the purpose front-loaded, followed by a compact bracketed metadata block for endpoint, required params, and cost. Nothing in the prose is wasted; the metadata block is largely contextual scaffolding rather than description, which slightly dilutes an otherwise exemplary structure.

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

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

The tool is complex (8 params, an enum activity, output schema present), so return values correctly need no explanation. Still, with 25% schema coverage the definition leaves includeNeutral's semantics and the avoidClashWith value format ambiguous, and it doesn't say how this differs from the sibling single-date Tong Shu tool. Adequate but with clear gaps.

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

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

Schema coverage is only 25%, so the description has to carry weight and it partially does: it explains both from/to ("walk a date range," cap of 366) and avoidClashWith ("drop the days that clash a person's animal"). However includeNeutral, language, and the accepted value format for avoidClashWith (a 2-12 char animal string?) are undocumented in both places, leaving real gaps.

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

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

"Walk a date range and return the days the almanac endorses for one activity, each with the officer that decided it" gives a specific verb (walk/return), resource (Tong Shu almanac days) and unit of output. It is far clearer than a tautology, but it never names its nearest sibling astroway_chinese_tong_shu (single-date almanac) or the many astroway_vedic_muhurat_* alternatives, so the agent must infer the split.

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

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

The description explains what the tool does but not when to reach for it over the single-date astroway_chinese_tong_shu or the Vedic muhurat family. The only conditional statements are param mechanics ("optionally drop days that clash") and a hard range cap, which are constraints rather than usage guidance. No exclusions or alternatives are offered.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the useful fact that the result is split into two named components (meridian term, equation of time) and, via the appended metadata, the endpoint and credit cost — but says nothing about latency, auth, or precision 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 is two front-loaded sentences: the definition first, then a concrete motivating example. The Kashgar anecdote is illustrative rather than wasteful, and the bracketed metadata is compact, though the prose is slightly evocative for a technical tool.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Still, for an 8-parameter computation tool the description does not explain how the two output components are meant to be used or when the tool is the right choice, leaving gaps 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 50%: the complex parameters (timezone, precision, fields) are already documented in the schema, while date, time, longitude and language rely on regex/range only. The description adds only that the longitude is the birth longitude, and its 'Required' line merely restates schema-required fields, so it does not meaningfully compensate for the gap.

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

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

The description names the specific output — a clock corrected to the sun over the birth longitude, decomposed into the meridian term and the equation of time — and ties it to a concrete consequence (the hour pillar moving). It is clear about what the tool produces, though it never states an explicit action verb and does not distinguish itself from sibling tools such as bazi_hour_pillar or chinese_solar_terms.

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 via the Kashgar illustration: it signals that the tool matters for births far from a zone's standard meridian, particularly where the hour pillar is at stake. There is no explicit 'use this when X' or 'prefer Y instead' guidance and no stated prerequisites or ordering relative to bazi tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description still adds real domain behavior: the Lichun instant governs the year boundary, yearStart/yearEnd are reported in both UTC and Beijing time, and boundary-day births need finer inputs. That is more than the annotations provide.

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 front-loaded sentences that lead with the core output and then the boundary semantics, with no filler. Slightly dense in the second clause, and the yearStart/yearEnd mention sits before the agent has been told those are return fields.

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 exposition, yet the description still explains the Lichun boundary and the UTC/Beijing dual reporting, which is the main source of ambiguity for this calculation. Cost tier and required parameter are also carried in the metadata block. Missing only sibling differentiation.

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%: timezone, timezoneOffset, fields and precision are documented in the schema, while date, time, language and solarYear are not. The description compensates only for time/timezoneOffset via the boundary-day rule; it adds nothing about solarYear or language, and its yearStart/yearEnd references describe outputs rather than inputs.

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

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

States a specific resource and scope: the animal sign of the birth year, explicitly bounded by the Lichun instant, plus the full pillar (stem + branch + element). This clearly separates it from a generic zodiac lookup. It does not, however, differentiate itself from the close siblings astroway_chinese_zodiac_inner_animal, _secret_animal, or _element, which an agent will likely 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?

Gives a conditional usage rule for one edge case ('Pass time + timezoneOffset for births on the boundary day'), which is genuine invocation context. But it never states when to choose this tool over the zodiac siblings (inner animal, secret animal, element, compatibility), leaving the main routing decision to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description contributes the deterministic scoring canon and the 0-100 range, which is genuine added context, but says nothing about what the response contains, rate limits, or determinism caveats beyond idempotence.

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

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

The core sentence is front-loaded and wastes no words; the bracketed metadata block is terse and scannable. Slightly redundant in that Required/Cost duplicate structured data, but the overall package is compact.

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

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

With an output schema present, return values need not be described, and annotations cover the safety profile, so the essentials are present. However, for a 5-parameter tool with nested person objects and 40% schema coverage, the description leaves input construction and any guidance on interpreting the score to inference, making it only minimally adequate.

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

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

Schema description coverage is only 40% and the description adds almost nothing: it merely repeats that person1 and person2 are required (already in the schema's required array). It does not explain the nested person shape (date/time/timezone/timezoneOffset), nor the compact-mode 'fields' and 'precision' parameters, so the low-coverage gap is not compensated for.

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+resource (compute a pair compatibility score on the 0-100 scale) and even names the underlying method (San He trine + Liu Chong canon). This distinguishes it from single-person siblings like astroway_chinese_zodiac_animal or astroway_chinese_zodiac_element, though it never names an alternative 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 only usage signals are the metadata tags '[Required: person1, person2]' and '[Cost: 10 credits (Tier 1)]', which restate the schema's required array and pricing rather than telling the agent when to pick this over e.g. astroway_mayan_compatibility or a relational synastry score. No when-to-use or when-not-to-use 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 establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds the endpoint and a cost tier (10 credits, Tier 1), which is operationally useful, but it says nothing about auth needs, rate limits, or output shape 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?

The core sentence is front-loaded and terse; the bracketed metadata block adds endpoint, group, and cost in a scannable format. However, the metadata is boilerplate that largely restates structured information rather than adding value.

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

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

An output schema exists, so return values need not be described, but for an 8-parameter tool with 50% schema coverage and no usage guidance, the description omits the date/solarYear interaction, the role of time/timezone for a year-based computation, and when to prefer it over sibling Zodiac 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 50%, and the description does not compensate. It asserts a 'given solar year' while the schema makes `date` required and `solarYear` an optional bounded integer (1800–2200); that date-vs-solarYear relationship — arguably the central input decision — is left unexplained.

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

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

States a specific computed output — fixed-branch element, cycling-stem element, and yin/yang for a solar year — which is concrete and distinguishes it from neighboring Zodiac tools (animal, compatibility, inner/secret animal). Missing sibling differentiation explicitly but the resource and returned attributes are clear.

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 conditions, and no mention of alternative tools such as astroway_chinese_zodiac_animal or bazi element tools. Only boilerplate requirement/cost metadata is given, which does not tell an agent when this tool is the right choice.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds genuinely useful operational context — the endpoint, the required input, and a 10-credit Tier 1 cost — but says nothing about output shape or failure modes beyond that.

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

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

The semantic sentence is front-loaded and the metadata block is compact and scannable. Nothing is redundant, though the whole thing is on the terse side for an 8-parameter tool.

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

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

An output schema exists, so return values need not be explained, and the cost/endpoint/required-input metadata is present. The gap is conceptual routing: with four Chinese-zodiac siblings, the agent gets no help choosing among them, which is the main completeness shortfall for a simple read tool.

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

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

Schema coverage is 50% with 8 parameters, and the description only echoes the single required one ('date'), adding no syntax or interpretation beyond the schema. The schema itself carries the substantive param docs (timezone, timezoneOffset, fields, precision), so a baseline 3 is appropriate rather than a penalty.

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 month-branch animal — and defines its meaning ('inner motivations and private self'), so an agent knows this computes the Inner Animal rather than the year animal. However, it never distinguishes itself from close siblings like astroway_chinese_zodiac_animal, astroway_chinese_zodiac_secret_animal, or astroway_chinese_zodiac_element, all of which sit in the same group.

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

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

There is no when-to-use guidance and no named alternative. The '[Required: date]' line is a schema restatement, not a usage condition, and nothing tells the agent when Inner Animal is the right call versus Secret Animal or Element.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the 10-credit cost and the birth-time precondition. Note a mild inconsistency: the schema marks 'time' as optional while the prose says birth time is required. The description adds some billing/input context, but nothing about pagination or error 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?

Two front-loaded sentences followed by a compact metadata block (group, endpoint, required, cost). No filler, and the key constraint and price are immediately visible; only the bracketed metadata formatting is slightly noisy.

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 safety and an output schema present, the description need not explain return values. It supplies group, endpoint, required input, and cost, leaving only sibling differentiation and the time/timezone handling implicit.

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?

Eight parameters with only 50% schema description coverage, so the description should compensate more than it does. It only signals that date is required and time is needed, while language, solarYear, and the compact/fields behavior go unaddressed; 'Requires birth time' also conflicts with the schema where time is not required.

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 names a specific resource and scope: 'Hour-of-birth branch animal' tied to 'the deepest self'. That is concrete enough to distinguish it from generic zodiac lookups, but it never contrasts itself with the very close sibling astroway_chinese_zodiac_inner_animal, which an agent could easily confuse with 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?

'Requires birth time' states a precondition that narrows when this tool is applicable, which is genuine usage guidance. However there is no explicit when-to-use/when-not-to-use statement and no routing to siblings such as astroway_chinese_zodiac_animal or astroway_chinese_zodiac_inner_animal.

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.