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

Beyond the annotations, it discloses key behavior: calls can take up to 180 seconds, pricing differs for view and issue, failures do not deduct points, PDFs are returned, and previously issued PDFs can be re-downloaded via job_id for 30P. This adds substantial operational context without contradicting the annotations.

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 and key constraints are front-loaded, and most sentences carry useful operational detail. There is some redundancy, especially the final '[호출당 850포인트]' alongside the separate view/issue pricing, but the structure remains efficient overall.

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 complex paid job-creation tool with no output schema, it explains the return value (PDF), timing, pricing, failure billing behavior, idempotency, and re-download path. It does not explicitly document sibling routing or error shapes, but it is largely complete for correct invocation.

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 schema already explains all eight parameters including usage, index, and idempotency_key. The description adds pricing meaning for the view/issue usage values, but does not add parameter-level guidance for most inputs beyond what the schema provides.

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 a specific action and resource: viewing/issuing a real estate registry certificate in one call. It also distinguishes the workflow by indicating the target comes from search results, separating it from the search sibling.

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?

It clearly establishes when to use the tool: after selecting a target from search results, to perform view or issue and obtain a PDF. It does not explicitly name sibling alternatives or exclusions such as corporate registry jobs, but the context is strong enough to guide selection.

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