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

With readOnlyHint=false already set, the description goes further by warning that despite being labeled a '조회' (lookup), the call is not purely read-only, that it creates an XBOSS job and stores processing results, that it consumes one token per call, and that institution-side data changes follow per-tool execution and existing confirmation steps. That is exactly the kind of behavioral context annotations cannot convey. It stops short of saying whether repeated calls accumulate jobs or what happens on failure, and the 'anonymous taste calls' phrasing is garbled and adds no reliable meaning.

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 front-loaded 'REQUIRES prior login' sentence is well placed, but the body is a dense block mixing Korean and English with a long idempotency digression that consumes roughly a third of the text. Some sentences ('This optional key is not available to anonymous taste calls', 'Keep any provider-specific idempotency_key unchanged') read as boilerplate or mistranslated and dilute the core message. It is not bloated to the point of unusability, but tightening and unifying language would materially help.

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 12-parameter tool with two enum selectors, two nested ref objects, no output schema, and a non-read-only execution model, the description leaves too much unsaid. It never indicates what the loaded return body returns or how it relates to the preparation/source_policy handoff objects, so an agent must infer most of the call contract from the schema. The auth and idempotency coverage is good, but the substantive parameter and result story is missing.

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 only 17% across 12 parameters, so the description must carry most of the semantic load, and it does not. It explains only request_idempotency_key (and even that is delegated back to the description from the schema), and mentions account_link_id only in passing via the login precondition. Key parameters such as year, half, procedure, period_kind, preparation, source_policy, expected_snapshot_hash, and original_receipt_job_id receive no explanation of meaning or interplay anywhere.

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 Korean core sentence ('부가가치세 정기신고에서 신고서 본문 조회 작업을 수행합니다') identifies the domain (VAT regular filing) and the action (loading the return body), but it is generic phrasing rather than a precise verb+resource statement and never says what the '본문' actually contains. The English schema note 'Load the main using the existing HomeTax VAT workflow; selectors are fixed by this action' is the clearest statement of scope, and it lives in the schema rather than the description. Nothing distinguishes it from nearby siblings such as hometax__tax__return_history__search_vat or the withholding return tools.

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?

The description gives a hard precondition ('REQUIRES prior hometax__session__login call with same account_link_id') and detailed procedural guidance on generating, reusing, and regenerating request_idempotency_key, which is genuinely useful for callers. However, it offers no guidance on when to choose this tool over sibling read paths such as return_history__search_vat, and no exclusion conditions beyond the login requirement. Usage is implied rather than explained relative to alternatives.

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