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

Annotations only declare readOnlyHint/destructiveHint, and the description adds real behavioral context on top: the required prior hometax__session__login with the same account_link_id, the per-call token cost ('호출마다 토큰 1소진'), and a full idempotency-key contract (generate before first request, reuse only to recover a lost response, new key for a new execution, and that provider-specific keys are a different field). That is the kind of cost/auth/retry detail an agent cannot get from structured fields.

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 and date-mode rules are correctly front-loaded and scannable, but the idempotency-key block runs five sentences for a read-only summary query and includes a self-cancelling line ('Without it, calling again remains a new request'), which costs more attention than it repays. Roughly a third of the text could be compressed without losing information.

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 an 11-parameter tool with no output schema, the description covers prerequisites, mode selection, filters, idempotency and cost, which is nearly everything needed to call it correctly. The remaining gap is return shape: nothing says what the 'summary' totals contain (supply amount, tax amount, counts) or how pagination interacts with aggregated results.

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 date_type/start_date/end_date/year/month/quarter conditional requirements and the search_type enum are already fully documented in the schema. The description restates those same mode-to-parameter mappings rather than adding format, range, or interaction detail, so it sits at the baseline for a fully documented schema.

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 e-tax invoice summary') and disambiguates the aggregation level with '(totals)', which separates it from the line-item search_list/search_detail siblings. It stops short of naming those siblings explicitly, so an agent still has to infer which one returns per-invoice rows.

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 date-mode guidance is unusually explicit: 'Choose ONE date mode' followed by the exact parameter combination for daily, monthly and quarterly, plus the '01'=issued / '02'=received selector. It also states the login prerequisite up front. What it lacks is guidance on when to prefer search_detail, search_list or search_statistics instead of this summary tool.

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