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

Beyond annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), it discloses several non-obvious traits: no secrets are taken as MCP input, each call consumes one token ("호출마다 토큰 1소진"), an XBOSS task is created and results stored, and this call is explicitly not purely read-only — consistent with readOnlyHint=false. The idempotency paragraph is verbose and somewhat muddled (including an unclear "anonymous taste calls" clause), which keeps it from 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 critical ordering instruction is front-loaded, but the body mixes Korean and English and pads with platform boilerplate (XBOSS task creation, per-tool change policy) plus a repetitive idempotency passage. Several sentences could be merged or deleted without losing actionable information.

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?

Given two optional parameters, no output schema, and thin annotations, the description covers the essentials an agent needs: call-first ordering, existing-link requirement, secret handling, token cost, and the non-read-only nature. It is silent on session lifetime/expiry and what a successful response contains, which are the remaining gaps.

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 description adds genuine semantics for request_idempotency_key: generate and save it before the first request, reuse it only to recover a lost response, use a new key for a new execution, and note it is a different field from any provider-specific idempotency_key. The account_link_id parameter is left entirely 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 description states a specific verb and resource: it creates a 하나은행 빠른조회 session ("세션을 기존 연동으로 만듭니다"), which distinguishes it from the sibling account-listing/query tools. The leading imperative "Call this FIRST before any other tool for this provider" reinforces the role, though the purpose statement is buried after that imperative rather than stated plainly first.

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?

Explicit ordering guidance is given: call this before any other tool for this provider, and the session is built from an existing 연동 (account link) rather than new credentials. It does not name an alternative auth path within this provider or state when a session already exists and can be reused, so an agent must infer re-login behavior.

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