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

Annotations already declare readOnlyHint=false, and the description reinforces this with non-obvious detail: each call consumes one token, creates an XBOSS job and stores the result, so the call is not purely read-only even though the underlying institution lookup is. It additionally discloses download_url lifetime (15 minutes), file retention (7 days), anonymous recovery_receipt scoping and non-transferability, and idempotency-key reuse rules. That is substantial behavior beyond 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 exclusions are front-loaded and clear, but the body is bloated with a long generic block on artifacts, receipts and idempotency that reads like shared boilerplate pasted across many tools, with some redundancy ("It grants access to that result only, until the original file retention expires" restates the receipt scoping). Mixed Korean/English and run-on English sentences make it harder to scan than it needs to be.

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 6-parameter tool with no output schema, the definition covers the prerequisite, cost, side effects, return shape (count, next-page flag, artifacts[] with download_url), file lifecycle, the recovery path via xdata__job__result, and the anonymous receipt flow. An agent has everything needed to call it correctly and to handle the result.

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 baseline is 3, but the description adds real meaning: account_link_id is tied to the login prerequisite and lane selection, and request_idempotency_key semantics (generate before the first request, reuse only to recover a lost response, new key for a new execution, distinct from provider-specific idempotency_key) are carried entirely by the description since the schema just points back to it. Page-splitting behavior beyond the first page is only in the schema, not the description.

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 Korean sentences state a specific verb and resource: it returns the institution's recent enforcement records (최근 단속 내역) with a count and a next-page indicator, and explicitly excludes 납부 and 이의신청. That distinguishes it from the paid/unpaid penalty and violation siblings. The English boilerplate about files, receipts and idempotency dilutes but does not obscure the core purpose.

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 gives a hard prerequisite (a prior efine__session__login call with the same account_link_id) and states what the tool does not cover (payments, objection filing), which routes the agent elsewhere. It also names the follow-up path for expired download links (xdata__job__result with the job_id). It does not explicitly say when to prefer this over the paid/unpaid violation query siblings, but the exclusions make the boundary largely inferable.

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