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

Beyond annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), the description discloses that each call consumes one token, creates an XBOSS job and persists the result, and explicitly says it is '순수 읽기 전용이 아닙니다' despite only reading from the agency. It also states nothing is saved or submitted to the agency. Rate limits and failure/retry behaviors beyond idempotency are not covered.

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 prerequisite is correctly front-loaded, but the body is long and mixes Korean and English while restating the same non-read-only point twice. The 'params: definition pending — see docs/...' placeholder is noise that occupies space without informing the agent, and the idempotency paragraph could be tightened.

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 zero-required-parameter draft validation tool with full schema coverage, no output schema and existing annotations, the description covers prerequisites, what is returned, what side effects occur, token cost and idempotency handling. The only real gap is the unresolved 'definition pending' reference, which leaves the parameter contract partially deferred to an external document.

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?

Both parameters are fully documented in the schema (100% coverage), so the baseline is 3, but the description adds real semantics for request_idempotency_key: generate and save it before the first request, reuse only to recover a lost response, use a new key for a new execution, and do not confuse it with a provider-specific idempotency_key. The line 'params: definition pending — see docs/contracts/EDI_JOB_ACTION_PARAMS.md' points at an external document and adds no in-place meaning.

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 gives a specific verb and resource: it validates draft acquisition declarations (name, RRN, per-insurer acquisition values, dependent rows) and returns missing_required_fields, field_errors, attachment guidance and registration eligibility. It also draws a clear boundary by stating '대상자 등록과 신고는 하지 않습니다' (it does not register or report the person). The explicit contrast with nhis_edi__qualification__acquisition__init appears only in the input-schema description, not in the tool description, so sibling differentiation is present but not self-contained.

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?

Prerequisite usage is stated up front: 'REQUIRES prior nhis_edi__session__login call with same account_link_id.' The description also gives exclusions — it does not register the 대상자 or file the report — which clarifies the neighboring action. It never names a concrete alternative tool to use for validation-free submission, so guidance is clear but lacks a routing alternative.

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