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

Annotations only declare readOnlyHint=true/destructiveHint=false; the description adds real context beyond that, including the session scoping, the token cost per call ('호출마다 토큰 1소진'), and the request_idempotency_key reuse policy after a lost response. The idempotency text is partly generic boilerplate and reads oddly for a read-only select, but it still aids correct invocation.

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 prerequisite and purpose are front-loaded, and the Chinese/Korean cost note is a useful trailing signal. The middle idempotency paragraph is long relative to a simple select operation and includes tangential asides ('anonymous taste calls'), which dilutes rather than informs.

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 3-parameter read tool with no output schema and no destructive behavior, the definition covers the prerequisite, the cost, and the idempotency contract. It never says what the result contains (department identifiers/codes needed for downstream calls), which is the one material gap.

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 account_link_id, department_name, and request_idempotency_key are already fully documented in the schema. The description adds only the idempotency-key lifecycle, which the schema itself defers to ('see the tool description'), so the net gain is marginal and the baseline 3 applies.

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?

States a specific verb ('Select') and resource ('KB Biz Card departments available to the current session'), so the agent knows exactly what is returned in kind. It does not explicitly distinguish itself from the sibling kb_biz_card__common__cards__select, leaving the departments-vs-cards distinction to be inferred from the name.

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?

Gives a concrete prerequisite: a prior kb_biz_card__session__login call with the same account_link_id. It does not state when to prefer this over the cards__select sibling or what to do if the prerequisite has not been met, so the branching guidance is incomplete but the entry condition is unambiguous.

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