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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral content beyond that: the response is localised by language, and longitude combined with trueSolarTime affects how the double-hour is cut (a genuine accuracy caveat). It stops short of disclosing cost/tier or error behavior, but the added context is substantive.

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 aggregate's value proposition, then the enumeration of contents, then the practical solar-time tip — a sensible order. The single dense listing sentence is long and the text is visibly truncated mid-clause ('cut the double-hour fro…'), but there is little filler for a tool of this scope.

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 covers the payload contents and the main calculation caveat well. For an 11-parameter aggregate with low schema coverage, the remaining gap is the absence of any statement about when to choose this over its many granular 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 36% (roughly 4 of 11 params), so the description carries some of the burden and it partially does: it explains the longitude + trueSolarTime interaction and the language localisation. It says nothing about stageSchool (classical vs unified), includeFullTable, the compact-mode fields/precision pair, or the date/time formats, leaving several parameters undocumented in both places.

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

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

Names a specific resource (the full BaZi four-pillar chart) and enumerates exactly what the aggregate returns — hidden stems, na yin, twelve stages, element balance, strength verdict, symbolic stars, interactions. Because the sibling set contains a granular tool for nearly each of those items (astroway_bazi_hidden_stems, astroway_bazi_na_yin, astroway_bazi_element_balance, etc.), the phrase 'everything ... in one call' is precisely the differentiator an agent needs.

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?

'in one call' implies this is the aggregate alternative to the granular BaZi siblings, and the closing sentence gives a conditional ('Pass longitude with trueSolarTime true to...'), which is configuration guidance rather than tool-selection guidance. It never explicitly states when to prefer this over astroway_bazi_four_pillars or the individual endpoints, so the routing decision is left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds operational context the annotations do not: the 10-credit Tier 1 cost and the BaZi group membership. It adds no pagination, caching, or dependency behavior, so it earns a moderate rather than high score.

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

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

The definition is short, front-loaded with what the tool returns, and every element (including the group and credit tags) carries information. Slightly clipped on the phrasing of the second sentence but free of 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 prose, and the safety profile is in annotations. What is missing is workflow context: whether time is needed for a day-master-only reading, where this fits relative to four_pillars or ten_gods, and any preconditions on the date input. Adequate but with clear gaps for a 7-parameter chart 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%, and the two central parameters (date, required, and time) carry only regex patterns with no descriptions in either the schema or the description. The description explains nothing about how the date/time inputs drive the day master or how fields/precision/language behave, so it fails to compensate for the coverage gap.

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

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

States a specific output: day stem element, yin/yang polarity, and canonical archetype description, and situates it in BaZi as the 'self' character. It is distinguishable from siblings like four_pillars or year_pillar, though it never names a contrasting sibling explicitly. Clear verb+resource, one notch below full sibling differentiation.

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

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

No explicit when-to-use or when-not guidance, and no alternative tool is named, despite the dense BaZi sibling cluster (four_pillars, hidden_stems, ten_gods, strength). The reader can infer this is one sub-step of BaZi analysis, but nothing routes them to or away from it.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: the `balance` object opens branches and counts three ways, and the top-level elementCounts/dominantElement/missingElements are deprecated but keep their legacy (four-character) semantics until 2027-09. This is exactly the kind of output-contract disclosure that helps an agent interpret results.

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

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

Purpose is front-loaded and the deprecation caveat is placed after it, which is the right ordering. But the text is dense with internal jargon ('opens the branches', 'stays at eight') and appears truncated mid-sentence at '2027-09…', which weakens the 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?

An output schema exists, so return values need not be restated, and the deprecation note usefully covers the output contract. What is missing for a tool of this complexity is any parameter guidance and any differentiation from the many sibling BaZi tools, leaving gaps the agent must guess around.

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?

Eleven parameters at only 36% schema description coverage, and the description says nothing about any of them – not date/time, not timezone vs timezoneOffset, not fields compact mode. With coverage this low the description is expected to compensate for the undocumented parameters and does not.

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

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

The opening sentence names a specific resource (element balance across the whole chart) and the following sentences specify the computation precisely: three counting methods over all eight characters. However, it never distinguishes itself from close siblings such as astroway_bazi_hidden_stems or astroway_bazi_strength, which also operate on the same chart, so the agent gets no routing signal.

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 conditional information is about deprecated output fields, which affects interpretation of the response, not tool 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 cover read-only/idempotent/non-destructive, so the bar is low, and the description adds genuinely useful domain behavior: the 60-jiazi anchor (1990-01-01 = Bing-Yin), the 23:00 local rollover for day/hour, and the exact Lichun/節 instants for year/month. The 10-credit cost is also disclosed. It does not mention timezone requirements or output shape, but annotations plus the output schema carry those.

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

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

Two tightly written sentences front-load the resource and the key computational rules, followed by compact group/cost metadata. No filler; each clause carries information.

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

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

With an output schema present, return values need no explanation, and annotations cover the safety profile. The description supplies the timing rules an agent needs to interpret results correctly; the only gap is that it doesn't note the date/timezone prerequisites for accurate hour-pillar output.

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%: timezone, fields, precision and timezoneOffset are documented in the schema, while date and language are bare. The description only adds semantics for `time` (hour-pillar computation), so it does not compensate for the undocumented parameters. Baseline 3 is appropriate.

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

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

The description names a specific resource (all four pillars: year, month, day, hour) and implicitly differentiates from the single-pillar siblings (bazi_year_pillar, bazi_month_pillar, bazi_hour_pillar) by emphasizing 'All four.' It is clear what gets computed, though it never explicitly names an alternative tool to route against.

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 usage hint for one parameter, but there is no explicit when-to-use/when-not guidance versus bazi_chart or the per-pillar siblings. The agent must infer that this is the full-chart option from the word 'All.'

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 and the bar is lower. The description adds a genuinely non-obvious output-semantics caveat ('On the four storage branches the middle role belongs to the stored element, not to the second in the list'), which is useful interpretive context. It does not cover return shape, auth, or limits, so it earns a middling score rather than a high one.

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 concept and reasonably short, but the middle sentence ('This is where most of a chart's elements live: a chart with no visible Water can still be soaked in it') is evocative illustration rather than functional guidance. The group/cost tags are compact and useful, but the descriptive rhetoric could be trimmed without loss.

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

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

For an 11-parameter tool with only 36% schema coverage, the description omits everything an agent needs to invoke it correctly: no param semantics, no usage context, no sibling routing. An output schema exists so return values need not be explained, but the input and selection gaps are substantial.

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

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

Schema description coverage is only 36% (11 params, ~4 described), so the description must compensate and it adds zero parameter information. Required 'date', 'time', 'language', 'stageSchool', 'trueSolarTime', and 'includeFullTable' are unexplained in both schema and description. The 'role and weight' and 'storage branches' language refers to output, not inputs, so it does not close 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 defines the concept (the one-to-three stems each branch shelters, with role and weight) and clearly belongs to the Hidden Stems domain, distinguishing it from other BaZi siblings by topic. However, it never states the action a verb+resource framing would give ('returns the hidden stems for a chart built from the supplied date'), leaving the agent to infer that this computes data rather than explains it. Concept is specific; the operation is only implied.

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

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

No when-to-use guidance, no prerequisite conditions, and no named alternatives among the many BaZi siblings (bazi_four_pillars, bazi_element_balance, etc.). Nothing tells the agent when hidden-stem data is the right call versus, say, the element balance tool that uses the same underlying concept.

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 needs no restating. The description adds genuinely useful domain behavior: the day opens at the Zi hour at 23:00 local time, which materially affects which hour pillar is returned and is not derivable from the annotations or schema. Cost tier is also disclosed. It stops short of stating the input source (birth date/time/location) or output shape, but the output schema covers the latter.

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 and tight: the operative sentence comes first and the Group/Cost tags are compact metadata rather than filler. The untranslated 五鼠遁 term is slightly opaque for a non-specialist but is followed by an English gloss, so no meaning is lost.

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. For a specialized BaZi sub-tool buried among hundreds of siblings, however, the definition omits the minimal context an agent needs to select it: what the Hour pillar represents, how it differs from the sibling pillar tools, and what inputs it draws on. 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?

With 7 parameters and 57% schema description coverage, the schema already documents the tricky ones (timezone, timezoneOffset, precision, fields). The description adds no parameter-level detail and never clarifies the required date/time formats (patterns only) or the language field, which the schema leaves bare. The mention of 23:00 'local time' loosely signals the timezone parameter's relevance, so it is not a total wash, but 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 states a specific verb+resource: it derives the Hour pillar using the 五鼠遁 day-stem-to-hour-stem table, and clarifies the Zi-hour day boundary. That is more precise than a tautology. It does not, however, distinguish itself from closely-named siblings like astroway_bazi_four_pillars, astroway_bazi_year_pillar or astroway_bazi_chart, 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?

There is no guidance on when to reach for this tool versus the other BaZi pillar tools or the aggregate bazi_four_pillars/bazi_chart. No prerequisites, exclusions, or alternatives are named. The Group and Cost tags give taxonomy and price but not usage conditions.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and a closed world, so the safety profile is covered. The description usefully discloses the report contents (pillar pairs plus resulting element) and the credit cost (Tier 1, 10 credits), which annotations do not carry. It says nothing about determinism against the input, error behaviour, or how a chart with no interactions is represented.

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 most distinctive content (the interaction types) before the secondary details. Nothing is redundant, though the enumeration is long and the appended group/cost tags are bracketed boilerplate rather than prose.

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

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

An output schema exists, so the description need not spell out return values, and it covers the computed content well. However, for an 11-parameter chart tool with patchy schema documentation, the absence of any statement about required birth data, the stageSchool choice between classical and unified, or the includeFullTable toggle leaves the agent under-informed about how to call it.

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

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

With 11 parameters and only 36% schema description coverage, the description should carry meaning for the undocumented inputs, but it mentions none of them — not date, time, timezone, trueSolarTime, stageSchool, includeFullTable, fields, precision or language. The schema leaves several of these bare, so the gap is real rather than theoretical.

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

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

The description names a concrete resource — the set of stem/branch interactions (combinations, harmonies, trines, clashes, harms, punishments) found in a BaZi chart — and even says what is reported alongside each one (pillars involved, produced element). That is far more specific than the title alone. It stops short of differentiating itself from near neighbours such as astroway_bazi_four_pillars or astroway_bazi_chart, so an agent must infer the boundary.

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

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

There is no when-to-use guidance, no prerequisite (a birth date/time is required by the schema but never mentioned), and no routing to or away from alternative BaZi tools. The only framing is the group/cost tag, which is metadata 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 readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds conceptual output context (that the pipeline yields the twelve-stage cycle, and includeFullTable returns a ten-by-twelve reference table), but says nothing about how the two stageSchool modes differ in result or what the default is; adequate, not rich.

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

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

Three tight sentences that lead with the concept and then the two option hints. The first sentence is a little convoluted, but there is no padding and the metadata tags are 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. What remains thin is the conceptual/usage framing for a BaZi tool and the unaddressed parameters; it is callable but not fully self-explanatory.

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 36% across 11 params, so the description must compensate. It does explain includeFullTable (returns the ten-by-twelve reference table) and stageSchool (classical yin-reverse rule vs unified), which is real added value, but leaves date, time, trueSolarTime, longitude and language entirely unaddressed in both schema and description.

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

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

The description conveys the concept being computed – a stem read against each branch as a life cycle (the twelve life stages, Chang Sheng through Jue) via the day master. However, it never states a verb+resource plainly and gives no differentiation from dense BaZi siblings such as bazi_day_master or bazi_strength, so an agent cannot cleanly distinguish this tool's output from adjacent ones without domain knowledge.

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

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

The only guidance is parameter-level (includeFullTable, stageSchool) rather than situational. There is no statement of when to reach for this tool versus the many other BaZi tools, no prerequisites, and no 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 read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds useful non-annotation context: a fixed 10-credit (Tier 1) cost and the Ziping-canon direction method. It says nothing about how many pillars return, timezone handling, or any auth/rate constraints, so it stays at the baseline-plus level.

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

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

Two compact sentences with the core concept and direction logic front-loaded, followed by clearly tagged Group/Cost metadata. No filler, though the second sentence is borderline trivia for an agent deciding whether to call the tool.

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

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

The existence of an output schema removes the need to describe return values, and cost is disclosed. However, for a 9-parameter tool with 44% schema coverage and no usage guidance, the description leaves gaps an agent must fill via the schema and sibling list.

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 9 parameters and only 44% schema description coverage, the description should carry more of the load. It touches only gender (as a direction input) and says nothing about count, fields, precision, time, timezone, or timezoneOffset, so callers must read the schema for the majority of inputs.

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

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

States a specific verb+resource: the 10-year luck pillar sequence (Da Yun), plus the direction rule (gender + year-stem polarity per Ziping canon). An agent can tell it computes a BaZi period sequence rather than a single pillar. It does not explicitly distinguish itself from sibling tools like astroway_bazi_year_pillar_decade or astroway_bazi_yearly, which prevents a 5.

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

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

The description explains how the direction is derived, not when to call this tool versus alternatives. There is no mention of prerequisites, exclusions, or sibling tools such as astroway_bazi_yearly or astroway_bazi_year_pillar_decade, leaving selection entirely to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious behavior beyond them: the month branch is resolved via mid-month jieqi (which determines which month boundary is used) and the cost is 10 credits (Tier 1). 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 tight sentences front-load the method and scope, followed by compact structured metadata (group, cost). No filler or repetition; every line carries information.

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

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

With an output schema present, return values need no explanation, and annotations cover safety. However, for an 8-parameter tool with 3 required inputs and 25% schema coverage, the description leaves the date/time/timezone inputs and their interaction underspecified, which is a real 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 only 25% across 8 parameters, so the description carries the burden and fails to compensate. Only 'a specific calendar month' loosely gestures at targetMonth; natalDate, natalTime, targetYear, natalTzOffset, and language are undocumented in both the schema and the description, leaving timezone and year/month coupling unclear.

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 analytical method (Sheng-Ke + branch-clash) and its scope (a single calendar month), and explicitly frames it as the monthly counterpart to the yearly analysis. It differentiates scope from the sibling astroway_bazi_yearly by implication rather than naming the tool, so it is clear but not maximally sibling-aware.

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?

Framing it as 'same as yearly but applied to a specific calendar month' implicitly tells the agent when to reach for this rather than the yearly tool, but there is no explicit when-to-use, no exclusions, and no mention of the adjacent astroway_bazi_month_pillar (natal month pillar), which could easily be confused with this forecast tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the solar-term boundary semantics and the cost/group metadata, which is useful context, but says nothing about how missing time or timezone inputs affect the computed 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?

A single front-loaded clause carries the core meaning with no filler; the group and cost tags are compact metadata. It is terse rather than padded, though it verges on under-specification.

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, but for a 7-parameter tool with partial schema coverage and no usage context, the description leaves the agent without enough to select it confidently among dozens of 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 57% and the description contributes zero parameter meaning. The undocumented parameters (date, time, language) include the required one, so the description does not compensate for the gap even though the date/time patterns are somewhat self-explanatory.

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 (month stem + branch) and its derivation rule (solar-term boundaries), which is a real distinguishing detail versus a calendar-month calculation. It does not, however, differentiate itself from the many sibling pillar tools (year_pillar, hour_pillar, four_pillars), which share the same phrasing pattern.

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

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

There is no statement of when to call this tool versus alternatives such as astroway_bazi_four_pillars or astroway_bazi_monthly, and no prerequisite information. The agent must infer usage from the name alone.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered by structured data. The description adds genuine domain context (the two-pillar collapse, the year-pillar reading) but says nothing about the credit cost beyond the header note, and nothing about output shape.

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

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

Two tight sentences that front-load the definition and then the disambiguation, plus a compact metadata footer for group and cost. No wasted text, though the cost/group lines are boilerplate rather than value.

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

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

An output schema exists, so return values need not be explained, and the concept is well-defined. But for an 11-parameter tool with low schema coverage and a domain-specific concept, the description leaves too much about input handling and the year-vs-other-pillar choice unstated.

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 11 parameters at only 36% schema description coverage, the description must carry more of the load than it does. It adds nothing about date, time, timezone, or the fields/precision compact-mode behavior, yet the nà yīn result depends critically on how the birth data is supplied.

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 concept ('the sound-element of each pillar') and pre-empts the most likely confusion by clarifying what it is NOT ('it is not the day master'), directly differentiating it from the sibling astroway_bazi_day_master. The sixty-jiazi-to-thirty-names mechanism makes the resource 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?

The description implicitly signals it answers the popular 'what is your element' question, but it never states when to call this vs. alternatives like bazi_day_master or bazi_element_balance. It distinguishes the concept but not the usage decision.

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 genuine methodological context beyond the annotations: the month is counted like any other branch, the three criteria are reported unweighted, and the cut points are this API's own convention. That limitation disclosure is exactly the kind of behavior an agent needs, though auth/rate-limit details are absent (credit cost is given in the metadata 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 sentences are front-loaded with the core concept, and the caveat sentence names both limits economically. The prose is dense jargon ("support-and-suppress", "weighted hidden-stem count") which reduces immediate readability, but nothing is wasted or padded.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. What remains missing is any positioning against the large BaZi sibling set and any description of the many input parameters, which a tool with 11 options arguably needs. The methodology and cut-point caveats partially fill the gap, making this 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?

With 11 parameters and only 36% schema description coverage, the description is expected to compensate, but it mentions no input parameters at all. Nothing is said about date/time handling, timezone vs timezoneOffset, stageSchool, precision, fields or includeFullTable, so the coverage gap is unaddressed.

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

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

The description names a specific computation: the day-master support-and-suppress reading over the weighted hidden-stem count, with the three classical criteria (season, root, allies) and the favourable elements. This is a concrete verb-plus-resource statement rather than a tautology. It does not, however, explicitly distinguish itself from close siblings such as astroway_bazi_day_master, astroway_bazi_hidden_stems or astroway_bazi_element_balance, leaving the agent to infer the boundary.

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

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance. The description explains what is computed but not the conditions under which an agent should pick this over the many adjacent BaZi endpoints (e.g. day_master, element_balance). No prerequisites or sequencing are stated.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it discloses the dual-pillar computation, the disagreement between transmissions, and the specific handling rule that both placements ship and cross-reference each other. It also surfaces a cost tier (10 credits).

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

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

Two sentences, front-loaded with the star names and followed by the key methodological caveat, plus compact group/cost metadata. It is reasonably tight, though the second sentence about cross-naming placements is slightly dense.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. However, for an 11-parameter tool at 36% schema coverage, the description leaves a significant parameter gap and gives no usage routing, making it only adequate rather than complete.

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

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

Schema description coverage is only 36% across 11 parameters, so the schema cannot carry the load and the description must compensate. It instead says nothing about date/time format, timezone, precision, fields, stageSchool, trueSolarTime, or includeFullTable, leaving most parameters undocumented in both places.

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

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

The description names the specific resource concretely (Peach Blossom, Travelling Horse, Canopy, Heavenly Nobleman, Blade and Void) and states it is 'computed from BOTH the year and the day reference pillar,' so an agent knows this yields Shen Sha symbolic stars. It is distinguishable from BaZi siblings by the star names, though it never explicitly contrasts itself with neighbors like astroway_bazi_four_pillars or astroway_bazi_ten_gods.

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

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

There is no statement of when to call this versus another BaZi tool, and no prerequisites or input context beyond the required date. The only guidance is methodological (why both pillars are used), which explains the output rather than the usage decision.

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

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

Annotations already declare this a safe, idempotent, non-destructive read, so the safety profile is covered. The description adds operational context beyond annotations only via the '[Cost: 10 credits (Tier 1)]' and group tags; it says nothing about the computation performed, determinism relative to input, or limits. Adequate but thin given annotations carry the behavioral burden.

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 statement, followed by a compact enumeration and two bracketed metadata tags. Efficient and free of filler, though the enumeration of ten terms is dense and the metadata tags sit outside the prose.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. But the description omits the essential framing that this is a birth-chart-derived computation requiring a date/time, and gives no routing against the numerous BaZi siblings - a real gap for a 7-parameter tool in a dense toolset.

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%, and the description supplies no parameter meaning at all - it never mentions date, time, timezone, fields, or precision. With over half the parameters documented only in the schema and the remainder undocumented anywhere, the description 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 and operation ('Ten Gods classification per day master') and enumerates the ten gods with their category labels (peer, output, wealth, officer, resource), which tells an agent what the output represents. However, it does not distinguish itself from the many sibling BaZi tools (day_master, four_pillars, hidden_stems) that an agent might otherwise reach for.

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 (e.g. that a birth date is needed), and no mention of any alternative sibling. The agent must infer usage entirely from the name and group tag.

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 useful semantic content (what relations are computed) and a cost tag (10 credits, Tier 1), but says nothing about auth, limits, or how natal time/zone defaults affect results. Adequate but not rich 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 tight sentences with the operation front-loaded before the return contents, plus compact group/cost metadata. No padding or repetition, though the enumerated return fields partly duplicate what the output schema already provides.

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 re-explained, and the safety profile is carried by annotations. However, for a 7-parameter tool with low schema coverage, the missing parameter documentation and absence of any sibling routing leave real gaps an agent must guess around.

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% (fields and precision only), so the description must compensate — and it does not. It never mentions natalDate, targetYear, natalTime, natalTzOffset, or language, leaving the two required parameters and the timezone input undocumented in both places.

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

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

States a specific operation (compares target year pillar against natal day master and natal year branch) and enumerates the analytical outputs (Sheng-Ke element-flow relation, 六冲 branch clashes, 三合 trine support). Clear verb+resource, but it never distinguishes itself from close siblings such as astroway_bazi_year_pillar, astroway_bazi_year_pillar_decade, or astroway_bazi_monthly, so an agent cannot route between them from the text alone.

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

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

No when-to-use statement, no when-not-to-use, and no named alternative despite a dense BaZi sibling cluster. The only scoping hint is implicit in the phrase 'target year pillar', which an agent must infer means an annual forecast use case.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful operational context beyond that: the group (BaZi Four Pillars) and the cost (10 credits, Tier 1). It does not disclose what input the pillar is computed from or any limits.

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

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

It is a single front-loaded fragment with no filler, and the cost/group tags are compact. But it is under-specified rather than concise — the terse form leaves the core routing question unanswered.

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 carry the safety profile. Still, for a tool sitting in a cluster of four ambiguous pillar siblings, the description omits both sibling disambiguation and parameter meaning, which is the minimum needed to invoke it correctly.

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

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

Schema description coverage is 57%, and the description adds nothing about any of the 7 parameters. Notably the required `date` parameter has only a regex pattern in the schema and no description anywhere, so the agent must guess whether it is a birth date, a reference year, or a calendar date — the one thing this tool's semantics hinge on.

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

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

The description names the resource contents precisely (year stem, branch, animal, element, yin/yang), so an agent knows what data comes back. However, it is a noun fragment with no verb and no differentiation from the many near-identical sibling pillars (astroway_bazi_month_pillar, astroway_bazi_hour_pillar, astroway_bazi_four_pillars, astroway_bazi_day_master). The naming pattern makes the distinction inferable, but the description itself does not make 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?

There is no when-to-use guidance at all: nothing states when to call this instead of astroway_bazi_four_pillars, astroway_bazi_chart, or astroway_bazi_yearly, all of which overlap heavily. No prerequisites, no mention that a birth date is required.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds useful cost/group metadata (10 credits, Tier 1, BaZi group), but says nothing about output volume, whether language affects the pillar labels, or how the decade window is bounded.

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 waste-free; the bracketed group/cost tags are compact and machine-scannable. Slightly more verbose than a single clean sentence, but nothing is extraneous.

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

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

An output schema exists, so return values needn't be explained, and annotations handle safety. However, for a tool with three comparably named BaZi siblings and a required year parameter, the description is thin on routing and on what the decade output represents, leaving an agent to infer selection.

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

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

Schema coverage is 50%: 'fields' and 'precision' are well documented in the schema, while 'startYear' and 'language' are undocumented. The description's 'from a given starting year' loosely maps to startYear but adds no format or edge-case detail (e.g., whether the 10 pillars begin at that year inclusive). Baseline 3 fits given the schema carries the parameter detail.

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

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

States a specific resource and cardinality: '10 consecutive year pillars from a given starting year.' An agent can distinguish it from the singular astroway_bazi_year_pillar by the '10 consecutive'/decade framing. It stops short of naming the sibling alternative explicitly, so it's clear but not fully differentiated.

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

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

There is no when-to-use guidance and no routing to alternatives among the many BaZi siblings (year_pillar, yearly, luck_pillars, monthly). The '10 consecutive' scope implies a range flavor, but nothing tells the agent when this is preferred over the single-year or yearly 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 cover read-only, idempotent, non-destructive, closed-world safety. The description adds genuine value beyond them by disclosing the year-boundary rule (the year turns at Li Chun, computed from the exact solar term), which affects how a given input date is interpreted. It does not describe pagination, return shape, or the interaction of date/year/time 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?

Two dense, front-loaded sentences that enumerate the outputs first and the optional layer and year boundary after. No padding, though jargon density means a non-domain reader gains little.

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?

Percentages: an output schema exists so return values need not be explained, and annotations carry the safety profile. But for a 9-parameter tool with 44% coverage and a near-duplicate sibling, the definition leaves the input contract and tool-selection decision underspecified.

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?

Nine parameters at 44% schema coverage, so the description must carry more weight than it does. It maps 'Optionally the monthly layer' to includeMonthly, but says nothing about how date, year, time, timezone, or fields interact or which should be supplied. The parameter surface is left largely 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?

Specific verb+resource: the nine annual stars for a solar year plus named afflictions (Tai Sui, Sui Po, San Sha, five yellow, two black) with sectors, and an optional monthly layer. Clear what is produced, but it never distinguishes itself from the near-identical sibling astroway_chinese_feng_shui_flying_star, so an agent cannot route between them from the text alone.

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

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

Only implicit guidance: 'Optionally the monthly layer' hints at when to add the monthly data. There is no statement of when this tool is preferred over astroway_chinese_feng_shui_flying_star or the other feng-shui siblings, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds no behavioral context beyond the topic — nothing about how date/gender drive the result, determinism, or any constraints, so it does not earn credit above the annotation baseline.

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

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

One front-loaded sentence plus group/cost metadata; no filler. The parenthetical enumeration of the nine life areas is long but carries real information, though the overall text is thin for a 9-parameter tool.

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

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

An output schema exists, so return values need not be described. But with 9 parameters, 44% schema coverage, required gender/date whose roles are unexplained, and no usage guidance, the definition is not complete enough for confident invocation.

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

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

Schema description coverage is only 44% across 9 parameters, and the description mentions none of them. Critically, it never explains why 'gender' and 'date' are required (kua number derivation) — a domain-specific semantic an agent cannot recover from the schema, which just lists an enum.

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 ('Eastern-school Bagua mapping of 9 life areas ... onto compass sectors') and enumerates the nine areas, so an agent knows exactly what is produced. It does not explicitly contrast itself with close siblings such as astroway_chinese_feng_shui_lucky_directions or astroway_chinese_feng_shui_kua, which also deal with sectors/directions.

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

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

No when-to-use statement, no prerequisites, and no alternatives named among the many feng shui siblings (flying_star, kua, annual_stars, lucky_directions). The agent must infer from the name alone whether this is the right tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the two key inputs are not defaulted, which is useful, but discloses nothing about rate limits, auth, or computation behavior. Adequate but not rich 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, front-loaded with what the tool produces and then how to feed it. Every clause 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?

For a 10-parameter tool with 0 required fields and an output schema present, the description covers the two decisive inputs and notes they are mandatory in practice. It omits the role of year and language, but since the output schema covers return values and three params carry their own schema descriptions, the remaining gap is minor.

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

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

With only 30% schema description coverage, the description compensates well by reconciling the input alternatives: facing vs facingMountain (degrees or 24 mountains) and period vs occupiedDate (direct period or occupation date). It leaves year, language and occupiedTime unexplained, but it adds real meaning over the raw schema for the critical parameters.

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

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

The description states a specific resource and its contents: 'the nine-palace natal chart of a building: mountain star, period star and facing star per sector, the named arrangement... and the special patterns.' This distinguishes it clearly from siblings like astroway_chinese_feng_shui_annual_stars or _kua, which cover different Feng Shui computations.

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

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

It gives clear input guidance ('Send the facing in degrees or as one of the 24 mountains, and the period directly or as the date the building was occupied') and warns 'Neither is defaulted,' which is essential since no parameter is formally required. It does not, however, name an alternative tool or state exclusions versus sibling tools, so it falls short of a full 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add context. It does add two useful facts: the cost tier (10 credits, Tier 1) and that the computation is keyed to the *solar* year, which is a real behavioral subtlety. However it omits edge cases (birth dates near the Chinese New Year boundary, effect of the time/timezone inputs) and does not say what the returned group field contains.

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

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

Two tight sentences with the core computation front-loaded, followed by group/cost metadata tags. No filler or repetition, though the bracketed metadata lines are 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?

For a simple birth-data calculation this is roughly minimum viable: the required inputs are implied, annotations cover safety, and an output schema exists so return values need not be described. The gap is input guidance for the seven optional parameters, which are neither explained nor flagged as ignorable for this particular computation.

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 9 parameters. The description conceptually covers the two required inputs (date via "solar-year digit sum", gender) but says nothing about the seven optional plumbing parameters (time, timezone, timezoneOffset, solarYear, fields, precision, language) or how solarYear relates to date. With low coverage the description should compensate and it does not.

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

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

The description names a specific computed artifact ("Personal Kua number") and its derivation ("solar-year digit sum + gender"), plus the output grouping (East/West). It is clearly not the same as bagua, flying_star, or annual_stars, though it does not name a sibling to distinguish itself from lucky_directions, which consumes the same grouping.

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?

"Maps to East/West group for direction work" implies the downstream use case, so usage is inferable but never stated. There is no explicit when-to-use, when-not-to-use, or pointer to the sibling (lucky_directions) that consumes this output.

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 real context by disclosing the method (derived from Kua, standard Pa Kua mapping), which is useful, but says nothing about output shape or assumptions beyond that.

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

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

Two tight sentences with the core output front-loaded, plus a group/cost tag. No waste, though it is arguably too terse for a 9-parameter tool.

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

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

An output schema exists, so return values need no explanation, and the read-only annotations cover safety. However, for a 9-param tool with low schema coverage and no usage guidance, the definition leaves an agent short of what it needs to choose this over the Kua sibling and to populate non-required params.

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 9 parameters, and the description contributes no parameter-level meaning at all. The phrase 'from Kua' weakly implies a birth date and gender are needed, but the many optional params (fields, precision, timezone, timezoneOffset, language) remain unexplained here and largely undocumented 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 output (4 lucky + 4 unlucky compass directions) and the derivation basis (Kua / Pa Kua mapping), which is concrete enough to distinguish it from the generic sibling astroway_chinese_feng_shui_kua. It does not explicitly name the sibling it differs from, so it falls short of a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no routing to alternatives. With a closely related sibling (astroway_chinese_feng_shui_kua) that yields the underlying Kua number, the omission of any 'use X for the number, this for the directions' guidance is a real gap.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the useful fact that leap months are detected and that the year's Chinese New Year is returned, plus the cost tier, but says nothing about the effect of the time/timezone inputs on the result.

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

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

A single front-loaded sentence that states the transformation and its outputs, followed by standardized group/cost tags. No filler; the only mild overhead is the bracketed metadata that is templated across the toolset.

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 safety profile is covered by annotations. However, for a 7-parameter tool with 57% schema coverage and no usage guidance, the definition is only minimally adequate: an agent gets the 'what' but not the 'when' or the parameter implications.

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

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

With only 57% schema description coverage and 7 parameters, the description compensates for almost nothing: it alludes to 'a Gregorian date' (the required param) but is silent on time, timezone, timezoneOffset, precision, fields, and language. The richest schema hints (timezone offset rules, precision) are left entirely to the schema.

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

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

The description states a specific verb+resource: it converts a Gregorian date into the Chinese lunar month/day and names two concrete outputs (leap-month detection and that year's Chinese New Year). That is enough to distinguish it from generic calendar siblings, but it never contrasts itself with the closely named astroway_calendar_lunar_calendar or nearby Chinese tools.

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

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

There is no when-to-use guidance, no exclusions, and no mention of alternatives such as astroway_calendar_lunar_calendar or astroway_chinese_solar_terms, which sit right next to it. The agent must infer applicability purely from the purpose sentence.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds useful domain context (UTC/Beijing time output; role in BaZi and leap months). It does not add operational details such as whether all 24 terms are always returned, count limits, or how language affects output. No contradiction.

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 main resource and then the domain role; the group/cost tags are metadata and don't bloat the prose. 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?

For a low-complexity lookup with an output schema, the description establishes what the tool returns and why it matters. It leaves open the when-to-use decision and two undocumented input parameters, so an agent still has gaps before invoking it confidently.

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

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

Schema coverage is 50%: fields and precision have descriptions, while year and language do not. The description adds no parameter-level meaning, such as whether fields supports solar-term paths, what language controls, or why year is bounded 2–2899. It fails to compensate for the coverage gap.

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

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

States exactly what is returned: the 24 solar terms for a given Chinese solar year as exact instants in UTC and Beijing time. It even explains the 12/12 split between BaZi pillar months and leap-month determination, so the resource and its significance are clear. It does not explicitly differentiate itself from nearby Chinese-calendar siblings, so 4 rather than 5.

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

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

Explains what the data is for (BaZi month boundaries and leap-month placement) but never states when to call this instead of alternatives like astroway_bazi_month_pillar, astroway_chinese_lunar_date, or astroway_chinese_tong_shu. Usage is implied by domain context, not directed.

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 behavioral context beyond that: it discloses the credit cost (10 credits, Tier 1) and the group, which an agent needs for planning. It stops short of describing format, pagination, or any rate/limit behaviour.

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 dense but well-structured sentence front-loads the core purpose and output list, followed by two short bracketed metadata lines (group, cost). There is no filler, though the single sentence is somewhat list-heavy.

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 usefully signals what the payload contains. However, with 7 parameters at 57% coverage and no usage guidance versus the tong_shu_select sibling, the definition leaves an agent guessing about routing and about the un-documented date/time/language 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 description coverage is only 57%, and the description adds no parameter meaning whatsoever — nothing about date, time, language, or how 'fields'/'precision' compact mode interacts with this endpoint. The rich timezone/timezoneOffset descriptions live in the schema, not the description, so the description does nothing to close the coverage gap.

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

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

The description gives a specific verb+resource ('the almanac reading of one day') and enumerates the exact contents returned: day pillar, day officer (建除十二神) with endorsements/forbids, the 28 mansion with quadrant and planet, and the clash animal. That is far more concrete than the name alone. It does not, however, distinguish this single-day tool from the close sibling astroway_chinese_tong_shu_select, so the agent must infer the boundary.

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

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

There is no explicit when-to-use or when-not-to-use statement. The phrase 'the almanac reading of one day' implies a single-date scope and hints at a range-selecting sibling, but no alternative is named and no prerequisite or selection condition is given.

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

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

Annotations already declare read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: a 366-day range cap that hard-refuses rather than truncates, and the optional clash filter keyed to a person's animal. It stops short of noting cost/auth handling, which the separate cost line partly supplies.

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, zero waste. The core behavior is front-loaded and the constraints (clash filter, range cap, refuse-not-truncate) follow immediately; nothing is repeated from the schema or annotations.

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 unnecessary, and the description covers the main behavioral risks (range cap, refusal semantics, clash filtering). The gaps are the unaddressed includeNeutral and language parameters and the exact date format, which the schema pattern supplies.

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

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

With only 25% schema description coverage across 8 parameters, the description must compensate and partly does: it clarifies activity (one per call), from/to as a walked range, and avoidClashWith as dropping animal-clash days. It says nothing about includeNeutral or language, leaving two parameters unexplained in both schema and prose.

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

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

States a precise verb+resource: walks a date range and returns almanac-endorsed days for a single activity, each annotated with the deciding officer. This clearly separates it from the singular sibling astroway_chinese_tong_shu, which covers one date rather than a selection sweep.

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 use case is clearly articulated (pick auspicious days for one named activity, optionally excluding days that clash a person's animal), and the 366-day cap sets a boundary on valid input. It does not, however, name an alternative (e.g. the single-date tong_shu tool or the vedic_muhurat family) or state when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds conceptual behavior — that the result is split into a meridian term and equation of time, and that it can shift the hour pillar — which is useful context beyond the annotations, but it says nothing about precision limits, error cases, or dependence on the timezone/longitude 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-loaded with the core definition followed by one well-chosen illustrative example; the group and cost lines are metadata. Every sentence carries weight, though the example is slightly expansive.

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 safety. However, with 8 parameters at 50% coverage and no usage guidance, the definition leaves the agent to infer when and with what inputs to call it, which is a meaningful gap for a computation tool.

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

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

Schema description coverage is only 50%, with date, time, longitude and language left undocumented in the schema. The description conceptually anchors the longitude input ('corrected to the sun over the birth longitude') and the timezone issue, but it adds no format or syntax detail and never mentions the compact-mode fields/precision parameters, so it only partially compensates 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 — the clock corrected to the sun over the birth longitude, decomposed into meridian term and equation of time — so the agent knows this converts clock time to true solar time rather than producing a chart. It does not explicitly differentiate itself from related siblings like astroway_bazi_hour_pillar, which it only alludes to via 'which moves the hour pillar'.

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 statement, no prerequisite guidance, and no named alternative. The Kashgar example implies the tool matters for Bazi hour-pillar accuracy, but the agent must infer that context rather than being told to reach for this before a Bazi computation.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real domain behavior beyond the annotations: the sign is determined by the exact Lichun instant rather than a calendar-year cut, which materially affects results.

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

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

Two sentences, front-loaded with the output and then the boundary-case instruction; nothing is wasted. The trailing group/cost tags are metadata rather than prose, so they don't hurt the core definition.

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 tz/offset/precision params are documented in the schema itself. For an 8-parameter tool the description covers the output and the one genuinely tricky input case, leaving only minor gaps such as solarYear's purpose.

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

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

Schema coverage is 50% and the description adds meaning for two of the undocumented-in-prose parameters (time and timezoneOffset) by tying them to the boundary-day case. It says nothing about date, solarYear, language, or why offset and timezone are mutually exclusive, so it only partly compensates 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?

It names a specific verb-less but concrete output: the Chinese zodiac animal sign of the birth year plus the full pillar (stem + branch + element), which is more than the name alone conveys. It distinguishes itself from other zodiac siblings by defining the Lichun boundary, though it doesn't explicitly contrast with astroway_chinese_zodiac_element or astroway_chinese_zodiac_inner_animal.

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

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

It gives one concrete conditional (pass time + timezoneOffset for births on the boundary day), which is genuine when-to-use guidance for an edge case. However, it never states when to prefer this tool over the many neighbouring zodiac/bazi pillar tools, so routing is left to inference.

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

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

Annotations already establish read-only, idempotent, non-destructive, non-open-world behavior, so the safety profile is covered. The description adds two genuinely non-obvious facts: the score scale (0-100) and the metered cost (10 credits, Tier 1), plus the methodology. It says nothing about what happens with missing birth times or how the score is composed.

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 carries the whole meaning, followed by structured group/cost tags that are metadata rather than prose. Nothing is redundant; the only mild cost is that the tags occupy lines that could hold input guidance.

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

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

With an output schema present, return values needn't be described, and annotations cover safety. What is missing is any input-side context for a nested two-person tool with 40% schema coverage – no note that birth dates are required or that time is optional.

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

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

Schema coverage is only 40%: person1.date, person2.date, time, language, and solarYear carry no schema description, and the description compensates for none of them. It never states that the tool takes two people's birth dates as its core input, leaving the required nested persons objects to be discovered from the schema.

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

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

States a specific resource (pair compatibility score), the output range (0-100), and the exact doctrinal basis (San He trine + Liu Chong conflict-pair canon), which is unusually precise. It does not name or differentiate itself from the nearest siblings (astroway_chinese_zodiac_animal, astroway_horoscope_compatibility, astroway_relational_match_score), so it falls short of a 5.

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

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

There is no when-to-use guidance, no exclusions, and no mention of alternatives such as the Vedic ashtakoot or Western synastry compatibility tools. The agent must infer from the name and canon alone that this is the Chinese-zodiac-specific pairing tool.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered. The description adds a genuinely non-structured behavioral trait — the 10-credit Tier 1 cost — which is useful for a cost-aware agent, but says nothing about return shape, limits, or auth.

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 tightly written line front-loads the substantive output description, with group and cost tags after it. Nothing is wasted, though the tags are boilerplate rather than value-adding prose.

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

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

For an 8-parameter tool with four undocumented parameters, the description is thin. An output schema and annotations exist so return values and safety need not be restated, but the ambiguity between date and solarYear is left entirely unresolved.

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%, leaving date, time, language and solarYear undocumented. The description mentions 'given solar year' but does not clarify the crucial distinction between the required 'date' and the optional 'solarYear', nor how time/timezone interact with them.

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

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

The description names the exact outputs (fixed-branch element, cycling-stem element, yin/yang) and the input dimension (solar year), so the agent knows what this computes. It is distinguishable from siblings like chinese_zodiac_animal, though it never explicitly contrasts with them.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as chinese_zodiac_animal or chinese_feng_shui_bagua. The '[Group: Chinese: Zodiac & Feng Shui]' tag implies a domain but does not tell the agent when to select this tool over its 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 safety is covered. The description adds only the credit cost (10 credits, Tier 1) and the semantic domain; it says nothing about what the response contains or whether time is needed for a month-branch derivation.

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

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

Extremely short and front-loaded: the purpose sentence comes first, followed by compact group/cost metadata. Nothing is padded, though the brevity is partly under-specification rather than disciplined concision.

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

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

For an 8-parameter tool with only half the schema documented and no output explanation needed, the description should at least clarify the required date/time inputs and the month-branch dependency. It omits all of that, leaving an agent to infer call requirements 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 only 50% across 8 parameters, and the description contributes zero parameter detail — it never mentions the required `date`, the optional `time`, or that month-branch determination depends on the solar term boundary. The description 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 derived resource — the month-branch animal — and states its interpretive meaning ('inner motivations and private self'), which lets an agent distinguish it conceptually from the year animal. It does not, however, explicitly contrast itself with the close sibling astroway_chinese_zodiac_secret_animal, so it falls short of full sibling differentiation.

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

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

There is no guidance on when to call this versus astroway_chinese_zodiac_animal, astroway_chinese_zodiac_secret_animal, or astroway_chinese_zodiac_element. No prerequisites, no context about needing a birth date/time, and no exclusions are stated.

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

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

Annotations already declare a safe, idempotent, closed-world read, and the description does not contradict them. It adds the genuine prerequisite that a birth time is needed, plus the credit cost, but says nothing about what the response contains or what happens if time is omitted (the schema marks only date as required).

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

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

Two compact sentences, with the core definition front-loaded and the prerequisite second. The group and cost tags are boilerplate metadata but short and informative; 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?

Return values need not be explained since an output schema exists, and the prerequisite is stated. For a domain with four near-identically named zodiac siblings, though, the definition leaves the agent without enough to reliably pick this tool over inner_animal.

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

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

With only 50% schema description coverage across 8 parameters, the description's 'requires birth time' usefully elevates the `time` parameter beyond its optional schema status. However, it adds nothing about date format, timezone/timezoneOffset interaction, or the compact-mode fields, leaving half the surface undocumented in both places.

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

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

States a specific resource and scope: the hour-of-birth branch animal, with a plain-language gloss ('represents the deepest self'). That distinguishes it from the year-based astroway_chinese_zodiac_animal, but it never names the closest sibling, astroway_chinese_zodiac_inner_animal, which an agent could easily confuse it with.

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

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

'Requires birth time' is a real prerequisite, which is more than most sibling definitions offer. It still gives no when-to-use or when-not-to-use guidance relative to zodiac_animal, inner_animal, or zodiac_element, so selection relies on the name alone.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already establish readOnly, idempotent and non-destructive behaviour, so the safety bar is low. The description adds genuinely useful operational facts the annotations do not carry: the tool is an MCP Advanced feature costing 100 credits (Tier 4). It still says nothing about how rounds affect runtime or output, or whether chart context is mandatory for a meaningful debate.

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

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

Two short lines, front-loaded with the core purpose followed by group and cost metadata; there is no filler or repetition. The brevity is somewhat a result of under-specification rather than disciplined editing, but structurally it is clean.

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

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

This is a high-complexity tool: 8 parameters, a nested chart object with detailed validation rules, and an output schema. The description covers none of that complexity and omits the astrological framing entirely, leaving an agent to infer from the schema alone what inputs matter. Output format is covered by the output schema, so that omission is acceptable, but the rest is a real gap.

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

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

Schema description coverage is only 38% and several parameters (topic, agentA, agentB, rounds, language) carry no schema description, so the description is expected to compensate — and it does not, adding no parameter meaning whatsoever. 'multi-round' only obliquely hints at the rounds parameter, and nothing explains what agentA/agentB strings should contain or how chart is consumed.

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 verb and output ('2 personas debate a topic, multi-round transcript'), so an agent knows this produces a debate transcript rather than a single answer. However, it never differentiates itself from near-neighbours like astroway_mcp_ai_chat or astroway_mcp_multi_agent_coordinate, and it omits that the debate is anchored to an astrological chart, which the schema makes 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?

There is no when-to-use guidance at all: no statement of what situation calls for a two-persona debate over a single-shot chat, no prerequisites, and no mention of alternatives. The only extra text is group and cost metadata, which is billing context 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 and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely new context by disclosing a 10-credit Tier 1 cost, but omits what the status payload represents or whether it reflects live pool state.

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

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

It is very short and front-loads the one substantive fact, but the first sentence is a dangling fragment rather than a complete statement of purpose, and the bracket tags read as metadata padding rather than description.

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

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

With an output schema present, return values need not be explained, and annotations cover safety, so the description's remaining burden is small. It is still thin on what 'pool status' reports and when it should be invoked, leaving a minor gap for a zero-required-parameter status tool.

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

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

Schema description coverage is 100% and both optional compaction parameters (fields, precision) are thoroughly documented in the schema with examples. The description adds nothing about parameters, so the baseline 3 applies.

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

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

The description '8 personas with specialties' is a noun fragment that hints at the returned content but never states what the tool does or what 'pool status' means. It does not distinguish this from siblings like astroway_agent_tools or astroway_mcp_tools_list, which also concern agent/persona inventory.

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 indication of when to call this versus the many sibling agent/tools-listing tools, and no prerequisites or exclusions. The only guidance offered is the cost tag '[Cost: 10 credits (Tier 1)]', which helps budget decisions but says nothing about selection.

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

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

Annotations already declare the safety profile (readOnly, non-destructive, openWorld, non-idempotent), and the description usefully adds context beyond that: a 10-turn history cap, 21 supported languages, four persona voices, and a cost behavior where sending your own provider key drops the turn to 5 credits. It stops short of describing failure modes or what the chart object must contain to succeed.

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