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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, and the description meaningfully explains WHY it is not a pure read: each call consumes one token, creates an XBOSS job, and persists the processing result ('이 호출은 순수 읽기 전용이 아닙니다'). It also states credentials are never accepted as MCP input, which is valuable security context. The remaining gap is that it never says what the call returns or how failures surface.

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 most important instruction is front-loaded, which is good, but the text then drifts through a long generic idempotency paragraph and a trailing XBOSS/token paragraph, switching languages mid-stream. Several sentences read as template boilerplate rather than login-specific guidance, so size is not proportionate to the tool's simplicity.

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 two-parameter login tool with no output schema, the description covers what an agent actually needs: call ordering, that no credentials go in the payload, that the call has side effects and costs a token, and how to retry safely. It omits what the session call yields and whether a status/verification step exists, leaving a small but real gap for a session-establishing tool.

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 both parameters are already documented — account_link_id fully so, and request_idempotency_key only by reference ('see the tool description'), which means the description must carry that weight. It does explain the key's lifecycle (generate and save before the first request, reuse only to recover a lost response, new key for a new execution, not available to anonymous calls, distinct from provider-specific idempotency_key), which is genuine added meaning, but the delivery is generic boilerplate not tailored to a login tool. Baseline 3 fits given the schema already does most of the work.

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 '계좌 빠른조회 세션을 기존 연동으로 생성한다' gives a specific verb (create) and resource (fast-account inquiry session) tied to an existing linkage, and the opening 'Call this FIRST before any other tool for this provider' anchors it among the nh_fast_account siblings. The core purpose is clear, but it is buried under idempotency boilerplate that dilutes the front-loaded signal.

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 ('Call this FIRST before any other tool for this provider') is exactly the kind of when-to-use instruction an agent needs for a session tool. It does not state when-not to call it, nor does it reference the sibling account/balance/transaction tools it unlocks, so it stops short of full routing guidance.

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