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

The description adds substantial behavior beyond the sparse annotations: it discloses that each call consumes one token, that a request creates an XBOSS task and stores its result, and that this is not a pure read operation; this is consistent with readOnlyHint=false and destructiveHint=false. The idempotency guidance, including the warning that a provider-specific idempotency_key is a different field that must be left unchanged, is real operational context. Minor deductions for the garbled "not available to anonymous taste calls" sentence, which obscures rather than clarifies the access rule.

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 and the idempotency rule come first, which is the right order, but the text is bloated and switches between English and Korean mid-paragraph, and the machine-translated Korean sentences about XBOSS and read-only semantics are hard to parse. The idempotency rules are restated more than once, so not every sentence earns its place.

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 10-parameter tool with no required fields, no output schema and only a minimal annotation set, the description covers the missing pieces: auth prerequisite, side effects, token cost, and idempotency contract. The remaining gap is that it never explains what the "print and save parameters" output looks like, which matters because no output schema exists.

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 100%, so the baseline is 3, and the description lifts this by explaining the request_idempotency_key lifecycle that the schema itself defers to ("see the tool description"). It also implicitly frames row_key/row_index/document_no as values carried over from a prior search, adding selection meaning beyond field labels.

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 states it will "prepare the print and save parameters for one certificate result," but the tool name says document_view and the body also says a call creates an XBOSS task and stores the result, so the agent gets conflicting frames of what the tool actually returns. It also never contrasts this tool with the sibling application_results__search even though the schema refers back to "앞선 검색 결과," leaving the verb and resource only partly pinned down.

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?

The prerequisite is stated explicitly ("REQUIRES prior nps_edi__auth__npki_session__login call with same account_link_id") and the idempotency reuse rule is spelled out (reuse only to recover a lost response, new key for a new execution). However, nothing says when to call this instead of the results search or the other certificate tools, so the search-then-view workflow can only be inferred from the schema text.

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