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

Goes well beyond the annotations by describing the two-phase write protocol: the first call is not executed and returns an exact preview plus a one-time confirmation_token (WRITE_CONFIRMATION_REQUIRED), the token must be added only with user agreement, expires in 10 minutes, is single-use, and is invalidated by any argument change. It also discloses side effects the annotations cannot express — an XBOSS job is created and the result persisted — and is consistent with destructiveHint=true/readOnlyHint=false.

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 critical prerequisite and the confirmation flow are front-loaded, but the text is a Korean/English patchwork with real redundancy: read-only is disclaimed twice ('This writes to the institution' and '순수 읽기 전용이 아닙니다') and the closing sentence about 기관 데이터 변경 is generic boilerplate. The fragment '호출마다 토큰 1소진' is cryptic and sits awkwardly between the confirmation instructions.

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 destructive, four-parameter, no-output-schema write tool with a confirmation handshake, this covers prerequisites, rejection modes, token lifecycle, side effects, and where the outcome is read. The remaining gap is minor: it does not say how or when to poll status after acceptance, nor how long the content-validation run typically takes.

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 per-parameter meanings are already carried by the schema; the description still adds the behavioral rule that changing any argument invalidates the token and that re-calling without it produces a fresh preview, which the schema does not state. It says nothing about source_job_id/expected_snapshot_hash beyond what the schema covers, so it does not exceed that baseline by much.

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 (원천세 전자파일 내용검증을 기관에 요청 = request content validation for a withholding electronic-file conversion report) and explicitly separates it from 형식검증, which is named as a precondition. An agent can distinguish this from format_validate and status without opening any 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 explicit preconditions (prior hometax__session__login with the same account_link_id, a successful format validation, same org/environment/institution connection) and states what happens when they are unmet (409 rejection, not executed). It also routes the agent forward: once accepted the work is finished and results, errors and warnings must be read via status.

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