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

Annotations already carry the full safety profile (readOnly, idempotent, non-destructive), and the description still adds substantial undisclosed behavior: the deterministic rule set, the five possible verdicts, the independence of the single-item track from the 3% threshold, the 90-day limit that the exception does and does not relax, and that the exception's granting authority is the 발주기관. It also discloses the silent default for method_specified_in_contract and the nulled requirement ② when the rate is absent.

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?

Front-loaded with purpose, then trigger scenarios, stated limitation, deterministic rules, verdicts, and finally args — a sensible order for a long definition. The prose is dense and nearly every line carries rule content, though the '두 트랙은 독립이다' paragraph restates the threshold relationship already implied earlier and the whole thing runs long even for a 12-parameter tool.

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?

No output schema exists, so the description must explain returns — and it enumerates all five verdict values with the meaning of the ambiguous one (single_item_only applies only to that material, not the whole contract amount). All 12 inputs, the default behavior, and the workflow position (Phase 3) are covered, leaving nothing an agent needs 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 0%, so the description carries the full burden and does: it annotates all 12 parameters, including domain rules the schema cannot express — org_type must not be guessed because thresholds differ, long-term contracts use the first contract date, last_adjustment_date shifts the period start, reduction rates are passed as negatives, and single_item_share_over_5permille must come from the 산출내역서 rather than being computed.

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+resource (물가변동 계약금액 조정 요건 판정 + 산식 적용) and pins its scope to Phase 3 of the performance stage. It also declares a negative capability (no rate computation), which sharply separates it from calculation-oriented or law-lookup siblings.

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?

Gives concrete trigger utterances ('자재값이 올랐는데 계약금액을 올려받을 수 있나', '90일 지났나', '단품 조정 되나') plus explicit when-not guidance: it will not compute the rate, and the agent must not invent one, returning undetermined instead. It also warns that answering '조정 불가' when single_item_only applies is a wrong answer, which is exactly the kind of routing caution an agent needs.

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