datetime.fiscal_year

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses the actual country calendars (KR/US 1/1~12/31, JP 4/1~3/31, UK 4/6~4/5) and the labeling convention (label = year containing the start date), plus a real limitation about company-specific fiscal year ends. That is meaningful behavioral context; only the default-country behavior is left implicit in the 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?

Three sentences, front-loaded with the core action and result, then the country rules, then the exclusion. Dense but every clause carries information (period boundaries, label rule, limitation); only the inline country list makes it slightly run-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?

An output schema exists so return values need not be explained, yet the description still names the returned label and start/end dates. Combined with the calendar rules, label convention, and scope caveat, 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 description coverage is 0% and the schema declares no enums, so the description carries the full burden — and it does: it gives the as_of format (YYYY-MM-DD) and enumerates the accepted country values with their exact period boundaries. This adds information the schema does not contain at all, not a restatement of it.

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 ('as_of가 속한 회계연도의 라벨 fiscal_year 와 시작·종료일을 구한다') and names the returned fields, so it is immediately distinguishable from datetime.fiscal_quarter and the rest of the datetime family. No ambiguity about whether it returns a date, a label, or both.

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

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

Explicitly bounds applicability with '기업별 결산기는 반영하지 않으므로 고정 국가 기준 연도 판정에만 쓴다', telling the agent when this tool is the wrong choice. It does not, however, name the sibling alternative (e.g. datetime.fiscal_quarter or datetime.tax_period_kr) that an agent should reach for in the excluded case.

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