Daily Alignment

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

Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds the conversion direction and mentions leap-month handling, but it does not disclose supported year ranges, invalid-date behavior, or output format. With annotations doing most of the behavioral work, a 3 is appropriate.

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

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

The definition is front-loaded with the core conversion purpose and then uses a compact example sentence to illustrate use cases. Both sentences earn their place, though the examples are somewhat illustrative rather than strictly necessary. Overall it is appropriately sized and easy to scan.

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

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

For a simple two-calendar conversion tool, the description plus rich annotations and fully documented schema give an agent enough to call it correctly. The main remaining gap is that there is no output schema and the description does not state the return format or supported date range. Those omissions keep it from a 5 but are minor for a straightforward conversion.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the input schema. The description echoes the same inputs (lunar year, month, day, leap month) and adds bilingual terminology plus example dates, but it does not add syntax or constraints beyond the schema. Baseline 3 is correct when the schema carries parameter semantics.

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

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

The description states a precise verb and resource: it converts a Chinese lunar calendar date (with lunar year, month, day, and leap month) to the Western Gregorian date. The direction of conversion is unambiguous, and the examples clarify exactly what kind of question it answers. This is specific enough that an agent can distinguish it from sibling almanac or zodiac tools without opening the schema.

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

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

The description supplies concrete question examples such as 'when is my lunar birthday this year' and 'when is the 15th of the 8th lunar month in 2027', which clearly frame when the tool is applicable. It does not explicitly name alternatives or exclusions, so it stops short of full when-to-use / when-not guidance. The intended use context is nevertheless clear from the examples.

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 notably openWorldHint=false, so the safety profile is fully covered. The description adds only that the result includes timezone and coordinates; it does not say what happens on an unmatched city, whether multiple matches are returned, or how matching is performed (exact vs fuzzy), which is the meaningful behavior for a lookup tool.

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 sentence, front-loaded with the action and its return values, with the usage hint trailing. No filler, no restatement of the title.

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 one-parameter read-only lookup with no output schema, the description usefully names the returned fields and the ambiguity use case. However, it leaves unresolved the exact question it raises — how ambiguous or unmatched names are handled and what the caller should pass to resolve them.

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 single required parameter "query" has 0% schema description coverage, so the schema supplies no meaning at all. The description's phrase "place name" is the only clue about accepted format, and it gives no guidance on disambiguation syntax (e.g., "City, Country") despite explicitly raising ambiguity as the core use case.

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

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

The description names a specific verb and resource ("look up a city") and states what the caller gets back (IANA timezone and coordinates), which is more than the title alone conveys. No sibling tool overlaps — the others cover almanac, lunar, and zodiac data — so there is nothing to disambiguate against, but it also doesn't mention its place in that family.

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

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

"Useful when a place name may be ambiguous" hints at the triggering situation but is phrased as a benefit rather than an instruction. There are no when-not conditions, no prerequisite statements, and no guidance on how to react if the lookup is itself ambiguous.

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 and non-destructive behavior, so the bar is lower. The description adds real value beyond them: results are computed from actual astronomical positions, the supported date window is 1901–2099, and the client's shared location is used as a default for city/timezone.

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

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

The resource and its output contents are front-loaded before the query examples and constraints, so the important material comes first. The single sentence is long and the query-phrase list is somewhat repetitive, but those phrases do earn their place as retrieval anchors.

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 carries the burden of describing return values, and it does so thoroughly: lunar date, ganzhi pillars, day officer, solar terms, zodiac, phase colour and moon phases. Coverage of defaults and date limits is adequate; only cross-tool routing is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description nonetheless adds meaning by pinning the 1901–2099 date range and clarifying that omitting city/timezone falls back to the user's shared location. It does not expand on the include_planetary_hours flag beyond the schema's default note.

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

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

The description names a specific resource (a day's Chinese almanac / tong shu / 黄历 Daily Alignment card) and enumerates its contents, so an agent knows exactly what it produces. It does not explicitly distinguish itself from siblings such as convert_lunar_date or get_four_pillars, which overlap on lunar date and ganzhi output.

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

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

It gives concrete trigger phrasings in English and Chinese ('today's almanac', '今天农历') and states the location fallback when no city is supplied, which is clear usage context. It stops short of stating when to prefer convert_lunar_date or get_almanac_month instead, so there are no explicit 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that it falls back to the client-shared location when no city is supplied — but says nothing about volume, size of a monthly payload, or how timezone affects the returned times.

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

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

The content is front-loaded — what a month returns comes first, use cases second, location fallback last — and every sentence carries information. The middle enumeration is dense but not padded, though it could be tightened slightly.

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, and the description compensates by naming the fields each day entry carries and the extra monthly events (new/full moon times, solar term starts, lunar month starts). Combined with the location fallback note, an agent has enough to call this correctly and describe 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 city, month, and timezone, including the 'omit to use the user's location' default. The description's closing location sentence largely restates that default rather than adding format or interaction detail, so baseline 3 applies.

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

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

The description states a specific resource and granularity (a month of the Chinese calendar, one entry per day) and enumerates the payload: lunar date, day pillar, day officer, moon phase, moon times, solar terms, lunar month starts. That implicitly separates it from get_almanac_day and get_solar_terms, but it never names a sibling explicitly, so an agent must infer the boundary.

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

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

The 'Answers ...' sentence gives four concrete question shapes the tool handles (favorable days, next moon phase, solar term/lunar month starts, Lunar New Year), which is strong positive routing. There are no exclusions or named alternatives, so it stops 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value by warning that results differ under two conventions (Lunar New Year vs. 立春/BaZi), which affects interpretation of the output. It does not cover return structure beyond a list of fields or explain what the optional time/city inputs alter.

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 primary output and the differentiating boundary rule, then example queries. Compact overall, though the example-phrase list is slightly padded for the value it delivers.

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?

No output schema exists, and the description does list what is returned (animal, element, yin/yang, lunar birthday), which is the right compensation. But for a tool with four params and a non-trivial boundary calculation, it omits how optional birth time/city/timezone affect correctness, leaving a real gap for an agent deciding which inputs to supply.

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

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

Schema description coverage is 100%, with each parameter (birth_city, birth_date, birth_time, birth_timezone) documented in the schema itself. The description adds no parameter-level guidance and never mentions why city/time/timezone matter for a zodiac computation, so it does not exceed the schema 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?

States a specific verb and resource (Chinese zodiac animal, element, yin/yang for a birth date) plus an additional output (lunar birthday). The boundary-rule detail (Lunar New Year vs. Start of Spring/立春) makes it distinguishable from sibling tools like get_four_pillars and convert_lunar_date without opening 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?

Provides concrete trigger questions in both English and Chinese ('what is my Chinese zodiac', 'what animal is someone born in January 1990', '我属什么'), which maps well to user phrasing. However, it names no alternatives or exclusions, so an agent must infer when to prefer get_four_pillars or convert_lunar_date instead.

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 real method context (exact Start of Spring, solar months) and the facts-only contract. The notable gap is it does not disclose what happens when the optional birth_time or location is omitted — presumably the hour pillar cannot be computed, but that behavior is left implicit.

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 sentence carries the definition, method, and outputs, followed by a short query-matching line and a scoping clause. Every sentence earns its place and the most important information (what it computes) comes first.

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 compensates well by enumerating the returned components (four pillars, Day Master, five-phase count). What remains unaddressed is optional-input behavior — how the result degrades without birth_time or location — which matters for a deterministic astronomy-style calculation.

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

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

Schema coverage is 100%, so the format of every parameter is already documented and the baseline is 3. The description adds only the loose mapping 'birth date, time and place', which hints that city/timezone exist to establish place, but it does not clarify when birth_city should be used versus birth_timezone or how a missing place affects accuracy.

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

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

The description states a specific computation (deriving year/month/day/hour pillars, Day Master and five-phase count) from a specific input (birth date, time, place), and names the method (BaZi, 四柱, exact Start of Spring and solar months). It is clearly separable from siblings like get_chinese_zodiac or convert_lunar_date, which return different artifacts.

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

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

It gives concrete trigger phrasing ('what is my BaZi', 'my four pillars', 'my day master', '我的八字') so the agent knows when to route here, and adds a scope boundary ('Facts only, no readings'). It never names an alternative sibling or states when another tool would be preferred, so it stops short of full when/when-not 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, closed-world behaviour, so the bar is low. The description still adds substantive context by disclosing the nature of the payload — explanations plus the tradition and sources behind them — which tells the agent to expect prose/reference content rather than computed values.

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 with no filler, and the core purpose is front-loaded before the qualifying examples. Every clause carries information the agent can act on.

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 one-optional-parameter reference tool with no output schema, the description covers what the tool is, what it returns conceptually, and when to reach for it. A brief note on response shape (single prose block vs. per-topic sections) would close the last gap.

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

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

Schema coverage is 100% and the schema already enumerates example keys (dayOfficer, solarTerm, lunarDate, dayPillar, moon), so the baseline applies. The description's examples add term-name glosses but no new parameter semantics, and it does not restate the 'omit for all' default behavior in its own text.

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 pair: it explains how each almanac value is calculated and what terms mean, with sources. This implicitly separates it from value-returning siblings like get_almanac_day or get_solar_terms, but never names them explicitly.

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

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

The phrase 'Answers how something is computed or what a term means' gives a clear triggering condition, reinforced by three concrete example terms (建除, 节气, 日柱). No exclusion is stated, so an agent must infer that actual almanac output comes from get_almanac_day rather than from this 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: results are computed from real astronomy, it's factual data rather than interpretation, and it falls back to client-shared location when no city is given.

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

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

The content is front-loaded with what is returned, followed by example queries and the location/date defaults, in a compact block with no filler sentences. Every clause carries usable information for invocation or selection.

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?

Zero required parameters and no output schema, yet the description enumerates the return content (sign, degree, retrograde status, Moon phase) explicitly. Combined with the location fallback note, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so city, date and timezone semantics and their 'omit for now/user location' defaults are already documented in the schema. The description only restates the default behavior, adding no format or edge-case detail beyond what the structured fields provide, so the baseline 3 applies.

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

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

States a specific verb and resource ('where the Sun, Moon and planets are ... which planets are retrograde, and the Moon phase') and enumerates concrete data fields (tropical zodiac sign and degree). The example queries ('is Mercury retrograde', 'today's astrology') make it clearly distinct from siblings like get_four_pillars, get_solar_terms, and convert_lunar_date.

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 clear usage context ('for now or any date', example question phrasings) and a scope exclusion ('Facts only, no horoscope text'), which tells the agent what this tool will not produce. It stops short of naming alternative siblings for adjacent astrology questions, so no explicit when-not-to-use routing.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile needs no restating. The description adds real context beyond them: local times follow the client-shared location when no city is supplied, and the result set is defined as terms plus Lunar New Year plus zodiac year. It doesn't cover ordering or out-of-range year handling, but that gap is minor.

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 front-loaded sentence defines the payload, followed by a compact set of query phrasings that serve retrieval matching rather than padding. Every clause 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?

With no output schema, the description fully compensates by spelling out exactly what comes back (24 terms with local date/time, Lunar New Year date, zodiac year) and how localization resolves. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100%, so both optional parameters (city, timezone) and the year range are already fully documented. The description only restates the location-fallback rule that the schema already states for city and timezone, adding no new syntax or format detail. 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 resource and scope: all 24 solar terms of a given year with exact local date/time, plus Lunar New Year and the new zodiac year. The enumeration of returned content makes it distinguishable from siblings like get_almanac_month or get_chinese_zodiac without opening a schema.

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

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

Example phrasings ('when is Chinese New Year 2027', 'when is the winter solstice', '二十四节气') give a clear trigger context for when to call it. It stops short of naming alternatives or exclusions, so the overlapping zodiac-year output is not routed against get_chinese_zodiac.

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