Chinese Astrology MCP Server by RoxyAPI

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds substantive behavioral context beyond that: 'The year and month pillars here are attributed by whole days' explains the solar-term boundary rule, and 'the response says exactly what it rules on rather than reducing the day to a single score' sets expectations about output granularity. No contradiction with annotations.

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

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

Three information-dense sentences with no filler. The core purpose is front-loaded, followed by the most non-obvious behavioral rule (whole-day solar-term attribution), and closed with concrete use cases. Every sentence earns its place.

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

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

For a complex almanac tool with no output schema, the description names the key return components and gives a decision-relevant behavioral rule about pillar attribution. Combined with 100% schema coverage, an agent has enough to select and invoke the tool correctly without missing critical context.

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

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

Schema coverage is 100%, so the schema already documents date format and range, lang enum/fallback, and compact shape. The description's note about whole-day pillar attribution adds interpretive context but not parameter-level semantic details beyond what the schema provides, 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 opens with 'Return the full almanac reading of one day' — a specific verb and resource — then enumerates the returned components: lunisolar date, pillars with Na Yin, day officer, lunar mansion, clash animal, and favoured/opposed activities. This clearly differentiates it from sibling tools like the monthly or solar-terms endpoints, and explicitly notes it does not reduce the day to a single score.

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

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

The description provides clear context: 'Built for date pickers, daily calendar widgets, and wedding or opening date tools.' It implies this is the per-day almanac tool, but it does not explicitly say when not to use it or name alternatives such as the monthly or solar-terms endpoints, so it misses the 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds visible behavioral context: it returns all days of the month, includes solar terms, and defaults to the current month when year and month are omitted. It also clarifies that this is a batch operation rather than 31 separate calls. No contradiction with annotations exists.

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

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

The description is concise and front-loads the core action and output fields in the first sentence. The second sentence adds useful differentiation from a single-day call, and the third states default behavior. The final sentence about use cases is somewhat redundant with the second sentence but does not significantly bloat the 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?

Even though there is no output schema, the description enumerates the main return fields (lunisolar date, three pillars, day officer, lunar mansion, clash animal, solar terms) and explains default behavior. It gives an agent enough information to know what will be returned and when to call the tool. It does not describe output wrapping or error cases, but for a read-only month-list endpoint this is a minor gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that omitting both year and month yields the month in progress, which reinforces the default behavior noted in the schema. It does not duplicate parameter details, and the parameter meanings are otherwise clear from the schema itself.

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

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

The description opens with a specific verb and resource: 'Return every day of one Gregorian month of the Chinese almanac' and enumerates the exact data fields returned. The phrase 'rather than thirty one' distinguishes it from a single-day calendar tool, and the sibling name get_chinese_astrology_calendar_day_date reinforces that contrast. This is unambiguous and 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?

The description clearly states this is the 'month view a calendar widget renders in one call rather than thirty one' and says it is 'built for calendar UIs, almanac pages, and planning tools that show a whole month at a glance.' This gives the agent a clear context for choosing it over a single-day tool. However, it does not explicitly name an alternative sibling or state when not to use it, so it falls short of the top score.

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

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

Beyond readOnly/destructive annotations, it discloses the key behavioral traits: exact astronomical instant at 15-degree longitude steps, the solar year opening at Li Chun with the last two terms in the following January, and dual UTC/UTC+8 returns. This is precisely the kind of non-obvious behavior an agent needs.

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 sentences, front-loaded with the core function and then adding the critical timezone and boundary quirks. No filler or redundant restatement.

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 tool with no output schema, the description does a good job of covering the return concept (all 24 instants, UTC and UTC+8) and the main boundary edge case. It stops short of specifying exact field names or value formats, which would make it fully self-sufficient, but the invocation-relevant context is present.

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

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

The input schema already documents all three parameters with descriptions at 100% coverage, so the description need not re-explain lang or compact. It reinforces the solar-year meaning of `year`, but that information is already present in the schema, so no substantial parameter semantics are added.

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

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

Description opens with a specific verb and object: 'Return all 24 solar terms of a year as astronomical instants rather than dates.' This clearly distinguishes it from the day-date and monthly sibling tools, and the solar-year/Li Chun detail defines its scope unambiguously.

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

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

The description provides concrete use contexts (calendar apps, festival scheduling, BaZi boundary placement) and makes the solar-year vs Gregorian-year scope explicit, so an agent can infer when this tool applies. It does not explicitly name sibling alternatives or state when not to use them, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral details beyond that: both cycles are returned as ordered rings and also attached to each phase, so a caller can render them directly without deriving. This explains the data shape in a non-obvious way.

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 sentences with no filler: the first states what is returned, the second explains the cycle packaging, and the third gives the canonical-vocabulary context. Each sentence earns its place, though the title already conveys a similar top-line 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?

For a read-only list of five fixed phases with no required parameters, the description plus fully documented schema is sufficient. It explains the data contents, the cycle structure, and the canonical role. A response example or explicit return container would be nicebut is not necessary for such a constrained 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?

Input schema coverage is 100%, with clear descriptions for lang, limit, offset, and compact, including enums, defaults, ranges, and fallback behavior. The description adds no parameter-specific semantics, so it does not need to compensate; 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?

Description states a clear action ('Return') and specific resource ('the five phases of Wu Xing') with exact attributes: Chinese character, season, direction, Heavenly Stems and Earthly Branches, and both cycles. It distinguishes itself from sibling zodiac/calendar/BaZi tools by positioning itself as the canonical five-phase vocabulary source.

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

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

The description gives clear usage context: 'This is the one place the five phase vocabulary is defined' and names consumers such as BaZi charts, Na Yin, zodiac element variants, and feng shui stars. It does not explicitly state when not to use the tool or name alternatives, but no sibling element tool exists, so the context is strong.

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 destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond that: it specifies cycle ordering from Rat to Pig, lists exactly what each entry contains, and notes the intended use case. It does not mention pagination behavior or language fallback, but those are documented in the parameter schema.

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

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

The description is two sentences long with no filler. The first sentence states the action and ordering; the second enumerates return fields, which is necessary since there is no output schema. The final phrase about the intended use earns its place by clarifying scope. The structure is front-loaded and tightly packed.

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?

Given there is no output schema, the description compensates by listing the return fields. It covers the core behavior, ordering, and use case. It does not explicitly describe pagination or the effect of offset/limit on the 'whole set' promise, but those details are in the param schema. A mention of the single-id sibling would improve completeness, but the tool name provides a hint.

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 each of the four parameters (lang, limit, offset, compact) already has a clear description. The tool description adds no parameter-specific meaning, which is acceptable because the baseline of 3 applies when the schema carries the full burden. No compensation needed.

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 starts with a specific verb and resource: 'Retrieve all twelve Chinese zodiac animals in cycle order, from Rat through Pig.' It enumerates the exact fields returned (machine id, Chinese character, pinyin, Earthly Branch, Five Element, yin/yang, traits), which uniquely positions it against siblings like get_chinese_astrology_zodiac_animals_id. The title reinforces the 12-animal catalogue, making the tool's purpose unmistakable.

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 clearly states the intended scenario: 'Built for sign pickers, zodiac cards and compatibility widgets that need the whole set in one call.' This gives context for when to choose it over a single-animal lookup. It does not explicitly name an alternative tool or state when-not-to-use, but the 'whole set in one call' phrasing provides a functional boundary.

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 destructiveHint=false, so the safety profile is covered. The description goes further by disclosing the full set of returned data categories, including branch relationships and element variants, and does not contradict the annotations.

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

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

Two dense, front-loaded sentences with no filler. The first sentence delivers the core action and return contents; the second states the intended use cases. Every clause earns its place and nothing repeats the structured schema 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?

Even without an output schema, the description enumerates essentially all semantic return categories, which is enough for an agent to understand what it will receive. Minor gaps remain around exact response field names or edge-case behavior, but those are not required for selection or correct invocation given the fully documented 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 100%, and every parameter (id, lang, compact) already has a detailed description, enum, default, or example in the schema. The tool description adds no parameter-level meaning beyond what the schema provides, so it meets the baseline.

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

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

The description opens with a specific verb and resource, 'Retrieve the complete profile of one Chinese zodiac animal,' then enumerates exactly what the profile contains. The singular 'one' distinguishes it from the plural-list sibling get_chinese_astrology_zodiac_animals and the dedicated compatibility endpoint.

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 states the intended contexts ('Built for sign detail pages and compatibility features') and the singular scope, which makes the main alternative clear implicitly. However, it never explicitly warns against using it for pair compatibility or the full zodiac list, so the guidance is clear but not exhaustive.

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?

The annotations already establish readOnlyHint=true and destructiveHint=false, and the description stays consistent with those. It adds useful behavioral detail beyond the annotations: the six relations are mutually exclusive by construction, exactly one applies to any pair, a phase is returned only where branches combine, and the output includes a composed reading with strengths, frictions, and advice.

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

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

The description is four focused sentences with no filler. It front-loads the purpose and method, then packs return semantics, exclusivity, and use cases into the remaining sentences, with every sentence earning its place.

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

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

For a read-only tool with four flat parameters, a fully documented schema, and no output schema, the description gives enough return-shaped context: relation, score, phase conditionally, and a composed reading. A precise JSON response shape is not specified, but the absence is minor given the clarity of the described outputs.

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

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

Schema description coverage is 100%, so the baseline is appropriately 3. The description does not add much parameter-level meaning beyond identifying the input as two Chinese zodiac animals, but it does not need to because sign1, sign2, lang, and compact are all well-documented 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?

The description names a specific action (score and explain), a specific resource (the relationship between two Chinese zodiac animals), and a distinct method (classical branch relations rather than a lookup table of opinions). It lists the concrete outputs and clarifies that exactly one of six mutually exclusive relations applies, making the tool easy to tell apart from sibling compatibility tools.

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

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

The description gives clear intended contexts: matchmaking features, relationship reports, and compatibility widgets. It also contrasts itself with lookup-table-based opinion tools, but it does not explicitly say when not to use it or name an alternative such as bazi compatibility, so some exclusion guidance is left implicit.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description reveals meaningful behavior: content is derived from the actual sexagenary day pillar, uses six classical relations, is fixed for a date, and rolls over at midnight UTC. It also lists what the response contains. This is substantial value beyond annotation data.

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

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

The description is dense but well organized: what it does, how it is computed, what it returns, and temporal behavior. Every sentence contributes information, and the key purpose is front-loaded.

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

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

With no output schema, the description sufficiently enumerates the returned fields and key behavior such as date rollover and timezone handling. Slight gaps remain in describing exact output shape and edge cases, but the schema covers the inputs and the description is otherwise complete for 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?

All parameters are already well described in the schema, so the baseline is 3. The description adds useful context by explaining that content is date-fixed and rolls over at midnight and that UTC is the default, reinforcing the date/timezone semantics beyond the schema.

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

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

States a specific verb and resource: get one Chinese zodiac animal's daily reading. It also distinguishes the tool's mechanism from stock-text rotations and names the exact returned content, making it clearly different from sibling 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?

Clearly frames the tool as a daily, single-sign, sexagenary-based forecast and notes the day/timestamp rollover behavior. It does not explicitly name alternatives or exclusions relative to sibling bazi or calendar tools, but the scope is evident from the description.

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 with readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral context by listing exactly what is computed and returned: annual pillar, Ten God relations, hidden stem reading, branch relationships, ben ming nian, and pillar combinations. This gives an agent a much richer sense of the operation than the annotations alone.

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

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

The description is two sentences with no filler. The first sentence front-loads the core action and the complete output scope; the second states the intended use cases and the key distinction from zodiac-only tools. The density is justified by the domain's complexity.

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

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

Given 11 parameters and no output schema, the description carries important semantic weight by explaining what the annual forecast contains and when it is useful, while the schema covers parameter mechanics. It could be more complete by describing the response shape, but the combination of description plus schema is sufficient for an agent to select and call the tool correctly.

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

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

Schema description coverage is 100%, so the input schema fully documents all 11 parameters with formats, enums, defaults, examples, and boundary rules. The description itself adds no per-parameter detail, only general context about reading a year against a natal chart, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Read one Gregorian year against a natal BaZi chart.' It then enumerates the concrete returns, making the tool's function unmistakable, and closes by distinguishing it from a read 'against an animal sign,' which separates it from the zodiac sibling tools.

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

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

The description gives clear intended contexts: 'Built for yearly horoscope features, timing tools, and agents that need a year read against a specific chart.' It also provides a meaningful exclusion by contrasting with animal-sign readings. It does not name alternative sibling tools such as the luck-pillars endpoint, so the guidance is clear but not fully explicit.

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 declare readOnlyHint=true and destructiveHint=false, and the description's 'Calculate' framing is fully consistent with them — no contradiction. Beyond the annotations, it discloses meaningful behavior: the day/year/hour boundary conventions are selectable, and 'the applied conventions come back on every response, so a chart is self-describing,' which gives agents a reproducibility guarantee. Error semantics (400s, DST resolution, hour ambiguity) are covered in the schema, and the convention-echo disclosure is genuine added context.

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

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

Three sentences, each earning its place: what it computes and returns, the selectable-convention behavior, and the intended use cases. The long first sentence is justified because there is no output schema, so the return-value enumeration is the agent's primary window into what the tool produces; there is no fluff or repetition of schema 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 10-parameter tool with no output schema, the description is remarkably complete: it enumerates every category of returned data, explains the self-describing convention behavior, and states the intended use cases. The 100%-covered schema supplies validation, defaults, and error semantics. Nothing an agent needs to decide whether to call it and what to expect is missing.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already documents all ten parameters in depth, including validation constraints and 400 cases. The tool description adds value by synthesizing the three convention parameters (dayBoundary, yearBoundary, hourClock) into one guarantee — selectable conventions that come back on every response — helping an agent understand how those parameters interrelate and affect reproducibility.

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?

Opens with a specific action and resource: 'Calculate a complete BaZi chart, the Four Pillars of Destiny, from a birth moment.' It then enumerates the full return set — four pillars, every Heavenly Stem and Earthly Branch, hidden stems, Ten God relations, Na Yin sounds, five-element balance, and combinations/clashes — which clearly distinguishes it from the narrower sibling endpoints like bazi_day_master, bazi_luck_pillars, and bazi_annual_forecast without needing their schemas.

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 closing sentence gives a clear target scenario: 'Built for astrology apps, matchmaking services, and agents that need a Four Pillars reading they can reproduce.' That is strong contextual guidance for when this endpoint is the right choice. However, it never explicitly names sibling alternatives or states when-not-to-use this tool, so an agent must infer the boundary against the other bazi endpoints.

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

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

Annotations already mark it read-only, and the description adds substantial behavior: it returns both resolved charts, the Day Master five-phase relationship, the full interaction list with named positions, and a tallied score. It even explains that the interaction list is returned in full so a caller can recompute its own weighting, which is genuinely useful transparency.

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

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

Every sentence earns its place: purpose, output contents, scoring transparency, and intended use. The description is dense but not bloated, and the primary action is front-loaded.

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

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

There is no output schema, so the description reasonably compensates by describing the returned charts, interactions, and score. It doesn't specify exact response fields, score ranges, or error behavior, but for this complexity level it gives an agent enough behavioral understanding to call the endpoint and interpret results.

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

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

Schema description coverage is 100%, so the schema carries the parameter documentation. The description adds high-level context about what the two charts represent but doesn't add per-parameter meaning beyond the schema, matching the baseline.

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

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

The description states the specific verb 'Compare two BaZi charts pillar by pillar' and names the resource (two BaZi charts). It distinguishes this from single-chart and zodiac sibling tools by emphasizing a 'two-chart reading', matchmaking, and cross-chart interactions.

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 explicitly says this is 'Built for matchmaking products, relationship features, and agents that need a defensible two-chart reading', which gives clear use-context. It doesn't name an alternative tool or explicitly say when not to use it, but the two-person matchmaking framing functionally separates it from the single-chart BaZi 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?

With readOnlyHint=true and destructiveHint=false in the annotations, the description properly adds behavioral depth: it explains the classical three-factor method, the auditable score with per-factor contributions, and the full set of returned metrics. It enriches what annotations alone convey without contradicting them.

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 sentences with each one earning its place: the first states the core purpose, the second explains the methodology, and the third enumerates both the outputs and the intended use. Information is front-loaded and dense without being verbose.

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

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

Because there is no output schema, the description properly carries the burden of explaining return values, listing the verdict, auditable score, factor contributions, seasonal state, root count, headcount, and favorable/unfavorable lists. Combined with the fully self-documenting input schema, the agent has enough to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline applies: the schema already documents all 10 parameters in detail, including formats, defaults, enums, and conditional requirements. The description adds high-level context about the method but does not add per-parameter meaning beyond the schema.

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

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

The description states a specific verb ('Assess') and resource ('Day Master strength'), with a clear definition of what is being measured: how well the Day Master is supported by the rest of a BaZi chart and which elements help it. This clearly distinguishes it from sibling tools like bazi_chart, bazi_luck_pillars, and bazi_annual_forecast.

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 names the intended audience and use cases ('chart readers, remedy features, and agents that need the usable half of a Four Pillars reading'), which gives clear context for when to choose this tool. It does not explicitly list exclusions or alternatives, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: the direction rule for forward/backward sequence, the inclusion of a day count behind the start age, and the optional annual overlay. No contradictions with the annotations.

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

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

Three sentences with no fluff: the first states purpose and outputs, the second captures the critical direction rule, and the third gives use cases. It is front-loaded and every sentence earns its place without repeating schema 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 no output schema, the description appropriately summarizes the return values at a semantic level. The 100% schema coverage handles parameter documentation, including boundary rules such as solar terms, day boundary, and timezone handling. It is complete enough for an agent to select and invoke the tool correctly, though concrete output field names are not given.

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

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

Schema description coverage is 100%, so the schema fully documents all 14 parameters including defaults, formats, enums, and conditional requirements. The description mentions output semantics but adds no parameter-level meaning beyond what the schema already provides, matching the baseline of 3.

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

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

The description uses a specific verb ('Calculate') and a specific resource ('da yun luck pillars, the ten-year periods a BaZi chart walks through after birth'). It enumerates exactly what the endpoint returns (direction, start age, ten-year pillars, Ten God relation, annual overlay), which makes its purpose unmistakable and clearly distinguishes it from siblings like bazi_chart or bazi_day_master.

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

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

The description gives clear context for when to use the tool: 'Built for astrology apps, life-timing features, and agents that need a reproducible forecast spine.' It does not explicitly name alternatives or state when not to use it, so it falls short of a full 5, but the intended use case is clear enough for an agent to route correctly.

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 destructiveHint=false, so safety is covered. The description adds meaningful behavioral detail: result ranking, filtering against a protected zodiac animal, the 93-day limit, and that each candidate day includes officer, pillars, lunar date, and clash animal so reasoning is visible. This goes well beyond the annotations.

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

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

The description is three sentences with no filler. It front-loads the core search behavior, explains the ranking and filtering logic, describes the response content, justifies the range cap, and closes with the intended audience. Every sentence contributes useful decision-making 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 no output schema, the description properly compensates by explaining what each candidate day contains: 'its officer, its pillars, its lunar date and the animal it clashes with.' It also covers ordering, filtering, range limits, and representative use cases, which is enough for an agent to call the tool correctly and interpret results.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description adds reinforcing context such as 'chosen activity' and 'zodiac animal to protect', and it echoes the 93-day range cap, but it does not provide new parameter-level format or syntax details beyond what the schema already offers.

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 uses a specific verb and resource: 'Search a date range for the days a chosen activity is favoured on.' It further distinguishes itself from calendar sibling tools by mentioning ranking by the jian chu day officer, filtering by zodiac animal, and returning pillars and lunar dates. The title reinforces the purpose as date selection for weddings, openings, moving, and travel.

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

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

The description gives clear use context: 'Built for wedding planners, business opening tools, and moving and travel date pickers.' It also explains why the 93-day cap exists ('date selection is done inside a planning window rather than across a lifetime'). However, it does not explicitly state when not to use it or name alternative sibling tools.

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

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

With readOnlyHint=true and destructiveHint=false already declared, the description adds substantial non-obvious behavioral context: UTC+8 reference meridian, winter-solstice month-11 rule, leap-month placement rules, timezone invariance, and exactly what the response reports. This goes well beyond the annotations.

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

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

The description is four sentences with no filler. It front-loads the core conversion purpose, then efficiently adds computational rules, response contents, and use cases in descending order of importance.

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 description covers the tool's purpose, timezone behavior, leap-month behavior, response contents, and suitable applications. Since there is no output schema, the response-content summary is valuable, and the input schema plus annotations complete the picture for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters including mutual exclusivity, ranges, defaults, and dependencies. The description adds high-level conversion semantics but does not need to repeat parameter-specific details; the baseline of 3 is appropriate.

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

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

The description states a specific verb (Convert), resource (Chinese lunisolar calendar), and both conversion directions (Gregorian to lunar and lunar back to Gregorian), which makes the tool's purpose unmistakable. It also distinguishes itself from sibling calendar tools by emphasizing that both conversions happen in one endpoint.

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

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

The description gives concrete use cases—festival calendars, lunar-date birthdays, and apps that must handle leap months—so an agent can recognize when to choose this tool. It does not explicitly name alternative sibling endpoints or say when not to use it, leaving room for 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?

With readOnlyHint=true and destructiveHint=false in the annotations, the safety profile is already covered, so the bar for additional credit is lower. The description adds genuine behavioral context beyond that: the two schools genuinely disagree on the year boundary, the choice is a request parameter, and the resolved convention is echoed back so the answer is self-describing. It also discloses the enriched result shape (animal, pillar, element), which matters because 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 sentences, each earning its place: the first states the core resolution and enriched output with a concrete example, the second flags the genuine ambiguity and how it is handled, and the third names use cases. The core action is front-loaded before any nuance, with zero filler.

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

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

With no output schema, the description correctly shoulders the burden of conveying return values — it names the zodiac animal, sexagenary pillar, Five Element phase, and the echoed convention. It also covers the one genuinely surprising behavior (January/February boundary disagreement), and the readOnly annotation covers safety. It does not explicitly distinguish itself from the get_chinese_astrology_zodiac_animals list tools, which a cautious agent might conflate with it.

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

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

Schema coverage is 100% and the individual parameter descriptions are already rich, so the baseline is 3. The tool description adds value above that by explaining why yearBoundary exists (school disagreement) and framing the date as 'a property of the year', plus the schema documents compact's lossless columnar tradeoff. The Metal Horse example also clarifies the output semantics that the parameters feed into, tying parameters to behavior.

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 uses a specific verb and resource: 'Resolve a birth date to its Chinese zodiac animal, the sexagenary year pillar behind it, and the Five Element phase of that year.' The concrete example (1990 → Metal Horse rather than Horse) makes the enriched scope unmistakable, and the focus on birth-date resolution with enriched output separates it from the sibling animal-list and BaZi routes.

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 explicitly names intended use cases: 'Built for sign lookups, onboarding forms and birthday features.' The yearBoundary parameter documentation goes further, telling agents this route answers the folk question and that 'the BaZi routes default to li-chun instead, because a chart and a folk sign are answering different questions' — an explicit when-not that routes agents away from the BaZi siblings. It stops short of naming the alternative list-lookup tools directly.

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