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

With readOnlyHint=false, the description does real work explaining why: it states that each call consumes one token, creates an XBOSS job, and stores the processing result, so the call is not purely read-only regardless of whether the underlying institution data is only read. It also discloses the no-login precondition and full idempotency-key semantics (generate before first request, reuse only for recovery, new key for new execution, not available to anonymous calls, distinct from a provider key). The trailing sentence about institution-data changes is vague boilerplate, keeping it short of a 5.

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 statement comes first, which is good, but the bulk of the text is a long mixed Korean/English block devoted to an optional key that most calls will omit, plus a vague closing sentence about institution data changes. Sentences are individually readable but the proportions are off — a one-parameter read-list tool should not be dominated by idempotency boilerplate.

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 simple list call with one optional parameter and no output schema, the description supplies what an agent needs: no-auth precondition, what each row contains, the ids that feed sibling tools, per-call token cost, and the hidden job-creation side effect. Minor gaps remain (whether the list is paginated or what an empty registration set looks like), but these are small relative to the tool's complexity.

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% for the single optional request_idempotency_key, so the baseline is 3. The description goes beyond the schema's one-line note by spelling out when to generate the key, when reuse is legitimate versus when a new key is required, and by warning that a provider-specific idempotency_key is a different field — meaningful guidance the schema alone does not convey.

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 verb and resource in Korean ('이 호출자가 등록한 계좌 연동 목록을 조회한다' – retrieve the caller's registered account-link list) and explicitly notes it needs no credential or login. It also distinguishes itself from the balance and transaction-history siblings by explaining that each item carries the account_link_id and bank_account_credential_id those tools consume. The only weakness is that this core purpose is buried in a bilingual paragraph rather than front-loaded cleanly.

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 only implied: by saying the returned ids are used by the balance and transaction-history tools, an agent can infer this is the prerequisite discovery call, but the description never says 'call this first before nh_fast_account__balance__query' or names any exclusion. There is no when-not guidance or explicit alternative routing.

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