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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses that inapplicable contract-kind combinations are rejected with ground_not_applicable rather than silently dropped, that filtered items surface in grounds_excluded_by_contract_kind and day_count_rules_excluded, and that it deliberately does not adjudicate eligibility. It also warns about quote_truncated citations, missing corpus originals (general_conditions_in_corpus, admin_rule_version_in_corpus), and forbids fabricating administrative-reply URLs — exactly the failure modes an agent would otherwise fall into.

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?

Purpose is front-loaded, then usage order, then the caveat block, so the structure is sound and each bolded paragraph carries a distinct warning. It is long and dense with dated parentheticals and corpus-versioning detail that could be trimmed, but little of it is genuinely redundant.

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?

There is no output schema, so the description has to explain return shape — and it does, naming verification, general_conditions_article_ref, admin_rule_version/issue_no/issued/effective, grounds_excluded_by_contract_kind, day_count_rules_excluded and quote_truncated. For a read-only lookup with two params, nothing an agent needs in order to call it and interpret the response 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 coverage is 0%, so the description must carry parameter meaning, and it largely does: contract_kind is tied to the same value as estimate_delay_penalty, mapped to a general-conditions family, with a warning that the actually-incorporated conditions are the source of truth; ground is described as selecting one ground for detail and defaulting to the full list for that contract kind. It further notes that the ground list is a cross-type enumeration that must sometimes be narrowed by contract type. It stops short of explaining the individual enum values beyond sw_requirement_change.

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 description states a precise verb+resource in the first line — a map of grounds for excluding days from the delay count — and immediately scopes it against the sibling ('estimate_delay_penalty가 정하지 않는 부분'). It also names the three things it returns (ground list with source quotes, must_establish facts, ministry precedents), so an agent can distinguish it from estimate_delay_penalty without opening either schema.

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 triggering questions ('동절기 공사중지 기간도 지체일수인가', '관급자재가 늦게 와서'), an explicit when-NOT ('이 도구는 해당 여부를 판정하지 않는다'), and an ordered workflow: narrow grounds here → confirm must_establish with the user → feed excluded_days into estimate_delay_penalty, including the halving rule for sw_requirement_change. This is the when/when-not/alternative triad done explicitly.

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