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

Annotations only declare the read-only/non-destructive profile; the description adds real context the annotations do not carry: authentication requirement, per-call token cost (호출마다 토큰 1소진), and the exact retry semantics of the recovery key. It also guards against a real failure mode by warning that provider idempotency_key is a different field. What it never states is what the preview validates or returns, which matters for a no-output-schema tool.

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 and the token-cost note at the end is efficient. However, three consecutive sentences circle the same idempotency point (reuse, new-key, 'without it, calling again remains a new request'), and "not available to anonymous taste calls" is opaque filler given authentication is already mandatory.

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?

With no output schema, the description is the only place an agent can learn what a preview yields (warnings, computed amounts, a preview token, blocking errors) or whether passing preview gates submission — and it stays silent on all of it. It is complete on auth and idempotency but incomplete on outcome, for a step embedded in an init → save → preview → submit chain.

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 the baseline is 3 and the schema already documents all six parameters. The description does add genuine semantics beyond the schema by distinguishing idempotency_key from request_idempotency_key and explaining when reuse is legitimate versus when a new key is required, which lifts it slightly but not to the level of explaining expected_state_version or annex_document.

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?

"Preview a regular-withholding draft before submission" gives a specific verb, resource, and lifecycle position, so an agent can tell it apart from submit/init/basic_save. It does not differentiate itself from the sibling review tool, which is the closest alternative and the one an agent would most plausibly confuse it with.

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 prerequisite is explicit and actionable (prior hometax__session__login with the same account_link_id) and the placement "before submission" implies when in the workflow to call it. What is missing is an explicit exclusion or routing rule versus __review, so the agent still has to infer which of the two to pick.

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