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

Goes well beyond the annotations: it warns that despite being a lookup, '이 호출은 순수 읽기 전용이 아닙니다' because an XBOSS job is created and the result stored — directly explaining readOnlyHint=false — and discloses the 1-token-per-call cost. It also discloses artifact retention (15-minute download_url, 7-day file retention), recovery_receipt semantics for anonymous results, and idempotency_key reuse rules. Some of this is generic platform boilerplate rather than tool-specific behavior, keeping it from a 5.

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 first two sentences are excellently front-loaded: data source, identifier, and return shape. But a large middle block about artifacts, recovery receipts, and idempotency keys is generic infrastructure text duplicated across the platform and dilutes the tool-specific content. The trailing sentence about token cost and job creation is buried at the end where an agent may miss it.

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 returns and does so concretely: named fields in statements, the latest row, and the empty-result-with-reason case for individual businesses. What remains thin is pagination semantics (7 params including pageNo/numOfRows, default 100 rows) and how statements behaves across multiple years when bizYear is set, which an agent would have to discover at call time.

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 every parameter is already documented in the schema; the description only adds the bizno→crno fallback and that an empty value for bizYear means all years, both of which the schema descriptions largely state already. It adds no syntax, format, or interaction detail (e.g. how pageNo/numOfRows interact with the statements list) beyond the schema, 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 ('법인 요약재무제표 … 법인등록번호로 조회'), names the source dataset id, and enumerates exactly what is returned (매출액, 영업이익, 당기순이익, 총자산, 총부채, 총자본, 자본금, 부채비율) in statements vs latest. It also explains the separate-vs-consolidated row split per 사업연도, which no other sibling (e.g. corp_outline) would cover, so an agent can distinguish it 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?

Gives clear entry conditions: crno or bizno, with bizno used only to resolve a missing crno, bizYear omitted to get all years, and '별도 연동 없이 사용할 수 있습니다' telling the agent no prior login/integration step is needed. It states the individual-business (개인사업자) case returns an empty result with a reason, which is a useful when-not signal. It never explicitly contrasts itself with siblings such as corp_outline or nts__status, 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.