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

The description goes well beyond the annotations: it warns the call can take up to 180 seconds, that each job costs 850P including PDF delivery, that no charge is applied if the call fails before payment, and that a previously issued PDF can be re-fetched at 30P via the X-Apick-Job-Id header against the download endpoint. These are exactly the cost, latency and retry facts an agent needs before spending money on a purchase-like operation.

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 purpose is front-loaded in the first sentence and the operational facts follow in a compact sequence. The trailing bracketed '[호출당 850포인트]' repeats the 850P already stated earlier, and the mixed English/Korean phrasing adds minor noise, but nothing else is wasted.

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 paid, potentially 180-second operation with no output schema, the description supplies the pricing, failure-charge policy, latency ceiling and the recovery path for retrieving an already-paid PDF. Combined with the fully documented schema, an agent has everything needed to call it correctly and to decide whether the cost is justified.

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 already 100%, so the baseline is 3, but the description adds real meaning: it frames the tool as keyed on 법인등록번호 and states that reusing the same call returns the existing job's PDF, which explains the idempotency semantics of idempotency_key more concretely than the schema does. `usage` (view vs issue) and `index` are left to the schema.

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 first sentence names a concrete verb pair (view/issue) and the resource (corporate registry certificate), and explains that everything is done in one call with a PDF returned. It never names or distinguishes the obvious sibling, registry_corporate_search, which is the workflow step that probably produces the `index` input, so an agent gets no explicit guidance on how it relates to that tool.

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?

Usage is implied rather than stated: corp_reg_no is the primary identifier and biz_no is the fallback, and `index` picks a row from a prior search. There is no explicit statement of when to use this instead of registry_corporate_search or registry_realestate_jobs_create, and no exclusions or prerequisites, so an agent must infer the search-then-issue workflow.

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