datetime.lunar_holiday

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

Annotations already establish readOnly, idempotent and closed-world, so the bar is low; the description still adds real behavioral context by bounding the year range to 2020~2030, stating leap months are unsupported, and warning that substitute holidays and holiday spans are not computed. Those are exactly the surprises an agent would otherwise hit.

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

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

Two dense sentences with zero filler, and the core conversion purpose is front-loaded before constraints. Slightly run-on for a reader, but every clause (enum list, year range, leap-month exclusion, no-substitute-holidays) 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?

An output schema exists, so return values need not be explained, and the description covers the parameters, range limit, and known exclusions. The only residual gap is behavior on invalid names or out-of-range years, which is not stated but is likely enforced by the server.

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 0% and there are no enums, so the description carries the entire burden: it lists all seven valid name values with Korean glosses and defines year as the lunar year with its range. It also explains the non-obvious edge case that seotdal_geumum returns a solar date in the following January/February.

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

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

The description states a specific verb and resource ('음력 명절을 양력 solar_date 로 환산한다') and is clearly narrower than the generic datetime.lunar_to_solar / solar_to_lunar siblings, since it operates on a fixed set of named holidays. It never explicitly names those siblings, but the enumerated holiday list makes the scope unambiguous.

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

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

Usage is only implied through the enumerated names and the 2020~2030 range; there is no explicit 'use this when X, use lunar_to_solar when Y' routing. The exclusion of 윤달 and 연휴/대체공휴일 implicitly says when not to reach for this tool, but it is never framed as guidance.

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