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

The annotations already state readOnlyHint=false and destructiveHint=false; the description adds real context on top: no certificate password or file is accepted as an argument, each call consumes one token, a XBOSS task is created, the result is stored, and the call is explicitly not purely read-only even though it performs lookups. The score drops to 4 rather than 5 because the idempotency paragraph is boilerplate, is partly untranslated, and mentions an "anonymous taste calls" case that does not apply here.

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 and easy to find. However, the text mixes Korean and English, repeats the idempotency explanation at length, and includes unrelated XBOSS/token boilerplate and a provider-specific idempotency caveat that does not apply to this two-parameter tool.

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?

No output schema exists, yet the description covers session lifetime, re-login after expiry, credit cost, and confirmation that no secrets are passed as arguments. The main remaining gap is that it never says what the call returns or how the session is carried forward, though that is a modest omission for a login 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?

With 100% schema coverage, the schema documents both optional parameters, so the baseline of 3 applies. The description goes past that for request_idempotency_key, spelling out when to generate it, that reuse is only for recovering a lost response under identical arguments, and that omitting it makes a repeat call a new request — despite the schema only saying "see the tool description".

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 names a specific verb and resource — logging into Wetax with the workplace joint certificate registered in the console — and states the outcome: a session shared by later filing and lookup steps. That is enough for an agent to distinguish it from the wetax__tax__* query and filing siblings without opening any schema.

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?

It gives explicit ordering ("Call this FIRST before any other wetax tool"), an explicit recovery trigger ("Call it again if a tool reports the session expired"), and the idempotency-key rule for a new execution versus a retry. Both when-to-call and when-to-recall are covered.

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