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

The annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is largely covered structurally. The description adds real value by disclosing that each call consumes one token and that the call creates an XBOSS task rather than being a pure read, but this arrives in untranslated boilerplate and is partly contradictory-sounding ("순수 읽기 전용이 아닙니다") without concrete consequences such as session lifetime or what a failed login leaves behind.

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 instruction is front-loaded, but the body is bloated with duplicated idempotency prose, mixed English/Korean boilerplate, and a confusing line about the key being "not available to anonymous taste calls" that reads as an artifact. Several sentences restate the same idea and dilute the two things an agent actually needs: call this first, and reuse the key only to recover a lost response.

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, annotation-covered session bootstrap with no output schema, the description should nail the essentials of authentication lifecycle, but instead it spends most of its length on idempotency mechanics and never clarifies session persistence, reuse across subsequent tools, or expiry. The statement that it "Returns a session credential" is the only return-value information, and there is no guidance on handling a login failure or a missing NPKI certificate.

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 both parameters are already documented in structured form, which sets the baseline at 3. The description does not add field-level meaning for account_link_id (the schema already explains the UUID/certificate fallback), though it does give procedural guidance for request_idempotency_key (generate before the first request, reuse only to recover a lost response, new key for a new execution).

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 and resource ("Login to Hometax via NPKI certificate") plus the return value ("Returns a session credential"), and the opening "Call this FIRST before any other tool for this provider" makes its role distinct from the sibling *_status and business tools. It loses a point because the trailing Korean boilerplate about XBOSS task creation and non-read-only behavior is generic provider text that muddies rather than sharpens the stated purpose.

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" is an explicit, actionable ordering rule that an agent can follow without inference. It does not name the natural alternative (the *_session__status sibling) or state what to do if a session already exists, so the when-not side is absent.

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