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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description stays consistent with that. Beyond the annotations it adds real operational context: the session prerequisite, the idempotency-key lifecycle (generate/save before the first request, reuse only to recover a lost response, new key for a new execution), and a per-call cost disclosure ('호출마다 토큰 1소진'). It does not describe pagination behavior or the shape of the returned list, which keeps it from a 5.

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 roughly three-quarters of the text is a generic idempotency-key lecture that reads as boilerplate shared across every tool in this provider, while the concrete cost note ('호출마다 토큰 1소진') is buried in the final fragment. The one sentence that actually describes the tool is short and easy to miss.

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?

All 9 parameters are fully documented in the schema and safety is covered by annotations, so the definition is callable as-is. However, with no output schema, the description never indicates what a trade-partner entry contains (name, business number, representative, registration date) or how paging totals are surfaced, leaving the agent to guess at return shape.

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 the schema itself already explains srt_opt, srt_cl_cd, txpr_nm, page_num, page_size, and account_link_id in detail; the description adds nothing for those. It does add genuine semantics for request_idempotency_key (when to reuse vs regenerate, and that a provider-specific idempotency_key is a different field), which is why this sits at the baseline-plus level rather than lower.

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: 'Search the list of trade partners the customer has registered for management.' An agent can immediately tell this is a read/list operation over the customer's registered 거래처 records. There is no competing sibling tool for trade partners, so differentiation is implicitly handled by the namespace rather than by the description itself.

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?

Opens with a hard prerequisite: 'REQUIRES prior hometax__session__login call with same account_link_id,' which tells the agent exactly what must happen first. It does not name any alternative tool or state when-not to use this one, but for a scoped listing tool with no direct sibling the usage context is clear enough.

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