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

Annotations only say readOnly=false, destructive=false, openWorld=false; the description adds genuinely useful behavior: one token consumed per call, an XBOSS job created and its result persisted, and the explicit warning that the call is "순수 읽기 전용이 아닙니다" (not purely read-only). The idempotency semantics (reuse only to recover a lost response, new key for a new execution, and that a provider-specific idempotency_key is a different field) go well beyond the annotations, though the "anonymous taste calls" sentence is garbled and adds confusion rather than clarity.

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 precondition is front-loaded, but the body is bloated: the idempotency paragraph repeats itself across four sentences, mixes Korean and English mid-stream, and the closing lines about institutional data changes and per-tool confirmation procedures are generic boilerplate that could apply to any tool. The single most important fact (that this stages a deletion request before submission) is buried mid-paragraph.

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 13-parameter, 10-required, non-read-only tool with no output schema, the description omits both halves of what an agent needs: the meaning of the core filing identifiers and what the call returns (a prepared request handle? a snapshot?) and how that handle is consumed by the later execution step. Prerequisites, cost and idempotency are covered well, but the parameter and return-value burden is not.

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 only 15% across 13 parameters, so the description must carry the load and it largely does not: business_no, year, half, period_kind, source_job_id, expected_snapshot_hash, original_filing_reference and original_receipt_no are never explained. Only consent, applicant_name, applicant_phone, account_link_id and request_idempotency_key get any meaning, and the idempotency key is the sole parameter discussed in depth. The critical snapshot-hash and original-filing linkage, which determine whether the call is safe, is undocumented in prose.

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 sentence "최종 제출 전에 선택한 신고, 신청인, 전화번호, 개인정보 동의를 준비합니다" states a concrete verb (prepare) plus the specific items being staged ahead of final submission, so an agent can tell this is a pre-submission staging step rather than the delete itself. It stops short of naming a sibling submit/execute tool, so the boundary with the eventual execution call must be inferred.

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?

"REQUIRES prior hometax__session__login call with same account_link_id" gives a clear precondition, and the idempotency-key paragraph explains when to reuse versus regenerate a key. However, there is no explicit "do not use this when…" and no named alternative for the actual submission or for the draft/snapshot path, leaving callers to infer sequencing.

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