AI 사주풀이 (Korean Saju)

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 is free to add real behavioral detail: it discloses edge-case handling for lunar and leap-month dates, solar-term month boundaries, and local solar-time correction, plus a data-handling guarantee ('the input is not stored') that no annotation conveys. It stops short of describing failure behavior for invalid dates or out-of-range coordinates.

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 verb and resource, then outputs, then input-format edge cases, then the storage disclaimer. The output enumeration is long but earns its place because no output schema exists; nothing is redundant with the title or schema.

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 domain-specific tool with no output schema, the description carries the return-value burden well and covers the tricky calendar/locale cases. The remaining gap is conditional behavior: it does not say whether omitting gender or location silently suppresses the luck cycles or solar-time correction, which matters 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 coverage is 100%, so baseline would be 3, but the description adds meaning the schema does not: birth_place/latitude/longitude are explained as feeding local solar-time correction rather than being an unexplained locator, and the lunar/leap-month path ties calendar and lunar_leap_month together. That linkage is genuine semantic value beyond the per-field descriptions.

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 plus resource ('Calculate a Korean saju / Chinese BaZi chart from a birth date'), followed by an enumeration of exactly what the chart contains (pillars, day master, five-element counts, ten gods, luck cycles, solar terms). It also distinguishes itself from the fortune/interpretation siblings with 'Calculation only', so an agent can tell it apart 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?

'Calculation only; the input is not stored' establishes the context in which this tool is appropriate versus the interpretation-oriented siblings. It does not explicitly name an alternative for follow-up interpretation (e.g. point at the fortune tools), so the routing 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description usefully adds that Samjae and the year relation are rule-derived (deterministic) while the narrative reading is Korean text, but it leaves an unresolved tension with the lang parameter's 'en' option and says nothing about response size or structure.

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 that front-loads the year and resource, then lists the returned components; there is little waste. It is long but each clause carries content, though the parenthetical transliterations (丁未 Jeongmi, 삼재) are somewhat decorative.

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 by enumerating the returned sections (overall luck, money, love, health, work, monthly, lucky points), which is the key missing structured information. The only real gap is the unexplained interaction between the lang parameter and the stated Korean-only reading text.

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%, with the animal parameter already documenting Korean/English names and birth-year input, so the schema does the heavy lifting. The description restates the birth-year acceptance and adds that output text is Korean, but does not clarify how lang=en interacts with that claim.

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: the 2027 New Year fortune for a zodiac animal, and enumerates what the answer contains (Samjae, relation to the 未 year, birth years, reading sections, lucky points). The '2027 New Year' scope implicitly separates it from get_daily_zodiac_fortune, but no sibling is named 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?

Usage is only implied: an agent can infer this is the annual 2027 reading rather than a daily one, and that a zodiac animal or birth year is accepted. There is no explicit when-to-use/when-not statement or pointer to calculate_saju or get_daily_zodiac_fortune as alternatives.

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 and determinism are handled. Beyond that the description adds real context the annotations don't cover: the computation basis is Korea time, content is published daily by sazuai.com (a freshness/source signal), and the full set of returned fields is disclosed despite there being no output schema.

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

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

Two sentences, front-loaded with the operation and its scope, then input formats, then source. The parenthetical field list earns its place since no output schema exists. Minor redundancy in restating the Korean/English animal input, which the schema already covers.

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 three-parameter read-only tool with no output schema, the description covers purpose, time zone, accepted input forms, source, and returned fields — enough to call it correctly on the first attempt. Gaps are minor: no statement on what happens with an invalid animal name or an out-of-range birth year, and no note on the default answer language.

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

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

Schema description coverage is 67%, so the schema already documents animal and lang. The description reinforces the accepted animal forms and, importantly, gives the day parameter semantic footing ('today's or tomorrow's fortune (Korea time)'), which the day enum itself doesn't explain. However, it never mentions the lang parameter's effect on the answer language, which is the one under-documented dimension.

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 — a daily fortune for one of the 12 zodiac animals (띠), covering today or tomorrow in Korea time — and enumerates exactly what comes back (luck score, love, money, health, advice, lucky color/number). The daily scope implicitly contrasts with the sibling get_2027_zodiac_fortune, but no sibling is named outright, so differentiation is left for the agent to infer.

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 makes the use case obvious (fetch one animal's fortune for today or tomorrow) but offers no explicit when-to-use or when-not-to-use guidance, nor does it route the agent toward calculate_saju or get_2027_zodiac_fortune for other time horizons. Usage is inferable, not stated.

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

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

Annotations already establish read-only, idempotent, non-destructive lookup behavior, and the description adds that interpretations combine traditional and psychological views with situation-by-situation meanings. However, 'Text is in Korean' is in tension with the lang enum that permits English answers, so output-language behavior is not fully clear.

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 topic range is conveyed compactly, though the long parenthetical topic list and overlapping keyword examples add bulk. Most sentences still carry useful scope 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?

For a simple read-only lookup with no output schema, the description gives enough on topic coverage, interpretation lenses, and situation-by-situation output to call it correctly. It leaves some gaps around unknown-topic behavior and output-language consistency.

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

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

Schema coverage is 100%, so both topic and lang are already documented. The description adds only matching hints such as 'English slug or Korean keyword' that largely overlap with the schema examples, and it does not clarify the lang parameter.

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, interpretation, and resource, dream topics, and scopes it to Korean traditional dream reading plus a psychological view. The listed topics and Korean/English keyword forms make it distinguishable from the sibling saju and zodiac fortune tools even without naming 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?

It implies use for dream-topic interpretation and gives matching guidance for the topic parameter, but never explicitly states when to choose it over the fortune/saju siblings or what to do for unknown topics. There are no exclusions or prerequisites.

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