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

With readOnlyHint=false declared, the description adds genuine context the annotations cannot: each call consumes one token, the call creates an XBOSS task and persists the processing result, and it is explicitly 'not purely read-only' at the provider source. That disclosure is exactly the kind of behavior an agent needs before invoking a nominally 'get' tool, though it stops short of describing latency or failure behavior.

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 is correctly front-loaded, but the middle section sprawls across four sentences of idempotency rules that overlap and partially restate the schema description, before pivoting to Korean sentences about token cost and XBOSS task creation. The key behavioral facts (cost, side effects, non-read-only) are buried at the end rather than surfaced early.

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-light tool with no output schema, the description covers authentication prerequisites, per-call cost, server-side side effects, and idempotency recovery semantics. The remaining gap is that nothing describes what the returned client record contains, which matters somewhat given the absence of an output schema.

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 and the baseline of 3 applies. The description does add real semantics for request_idempotency_key (when to reuse, when to mint a new one, that it is unavailable to anonymous test calls, and that provider-level idempotency_key is a different field), but it adds nothing about account_link_id beyond what the schema already says.

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 first sentence names a specific verb and resource ('Get client/counterparty info for e-tax invoicing'), which is clearly distinct from invoice issuing/searching siblings. It does not, however, contrast itself with the nearby hometax__etax__business_info__get, so an agent must infer the boundary between client info and business info.

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?

A concrete precondition is stated ('REQUIRES prior hometax__session__login call with same account_link_id'), which is real usage guidance. There is no guidance on when to prefer this over sibling lookups, no exclusion conditions, and no note on when the optional account_link_id should be supplied versus omitted.

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