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

Beyond the annotations, it discloses that each call consumes one token ('호출마다 토큰 1소진'), that a XBOSS task is created and results stored, and that the call is not purely read-only even though it queries institution data. It also explains the lost-response recovery semantics of the idempotency key. This is consistent with readOnlyHint=false and destructiveHint=false and adds genuinely useful operational context.

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 call-first instruction is correctly front-loaded, but the body is a dense English/Korean mix with redundant restatements of the idempotency rule and an irrelevant clause about a separate provider-specific idempotency_key field. The phrase 'anonymous taste calls' is an unclear translation artifact that costs the reader effort.

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 session-establishment tool with full schema coverage and no output schema, it covers ordering, cost, side effects, and idempotency adequately. It does not say what the session handle or response contains, which an agent might need to chain into follow-up calls, but nothing critical for correct invocation is missing.

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 baseline is 3, but the schema itself defers request_idempotency_key semantics to the description ('see the tool description'), and the description delivers: generate/save before first request, reuse only with identical arguments to recover, new key for a new execution. account_link_id is left entirely to the schema, and the stray note about a 'provider-specific idempotency_key' field that does not exist in this schema adds confusion.

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 sentence 'IBK기업은행 빠른조회 세션을 기존 연동으로 만듭니다' states a specific verb (create session) and resource (IBK fast-inquiry session) using an existing linkage, which is distinguishable from the sibling accounts-list/transaction tools. It does not explicitly restate the 'login' framing from the title in English, so the action is slightly less crisp than it could be, but the resource and scope are unambiguous.

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?

'Call this FIRST before any other tool for this provider' gives explicit ordering guidance that routes the agent correctly against all siblings. It also details when to reuse vs. regenerate the idempotency key. It lacks an explicit when-not-to-call condition (e.g., if a session already exists), which keeps it from a 5.

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