contract-compass

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.

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

Annotations declare readOnly/idempotent/non-destructive, and the description goes well past them: it discloses the vendor_conditional_candidates split for missing status flags, the law_currency/laws_checked/laws_not_verified verification contract with the 2026-10-15 date, and the selection_ignored_reason fallback. This is exactly the edge-case behavior an agent cannot infer 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?

It is long, but the length is defensible for an 18-parameter rules tool with zero schema descriptions, and it is front-loaded with purpose before the Args block. There is mild repetition in the flag blocks ('위와 같은 목') that could be tightened, keeping it short of a 5.

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 must carry return semantics, and it partially does by naming key response fields (follow_up_questions, final_recommendation, vendor_conditional_candidates, law_currency). It stops short of a full response shape, and the undocumented project_name is a small hole, so 4 rather than 5.

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 it does: it documents nearly every one of the 18 parameters with meaning, enum values, monetary thresholds, governing statutes (e.g. 국가 시행령 제26조①5호가목3 vs 지방 시행령 제25조①5호라목), and the non-obvious fact that is_special_expertise also applies to products. Only project_name is undocumented, a negligible gap.

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 first line states a specific verb and resource ('계약방법 결정론 판정') plus the deliverable ('적용 가능한 계약방법 후보와 법령 근거를 반환'), which cleanly separates it from the law-lookup siblings (get_law_article, search_law). An agent can tell this is a rules-engine judgement tool, not a document retrieval tool.

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?

It gives explicit operational guidance: how to handle the two-stage call (re-invoke with follow_up_answers to get final_recommendation), and explicit prohibitions ('지위를 추정하지 말고 사용자에게 확인하라', '답을 모르면 넣지 마라'). It does not name alternatives, but no sibling actually competes with this judgement tool, so the guidance is sufficient if not framed as routing.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds a lot beyond that: refusal behavior (ground_not_applicable), non-silent filtering (grounds_excluded_by_contract_kind, day_count_rules_excluded), corpus-coverage flags (general_conditions_in_corpus, admin_rule_version_in_corpus), and an explicit anti-fabrication instruction for links and truncated quotes. It stops short of describing response shape or latency/limits, so 4 rather than 5.

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?

Long, but front-loaded with the core distinction in bold and organized into labeled blocks (usage order, filtering behavior, verification semantics, caveats). Nearly every sentence carries operational content; some redundancy in restating the non-silent-filtering point keeps it from a 5.

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 carries the return-value burden — and it does, naming must_establish, ground_not_applicable, grounds_excluded_by_contract_kind, day_count_rules_excluded, and verification's sub-flags plus quote_truncated. For a two-parameter read-only lookup, an agent has everything needed to call and interpret it.

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%, but the description compensates: contract_kind is tied to estimate_delay_penalty's value space, mapped to the general-conditions family, and flagged as not being the truth source (the incorporated conditions are); ground is explained as single-reason detail view vs. full list when omitted. The 10 individual ground enum values and 6 contract kinds are still not defined outside one example (sw_requirement_change), leaving a residual gap.

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 resource (지체일수 불산입 사유 지도) and explicitly positions it against the sibling estimate_delay_penalty as 'the part it does not determine'. The negative scope ('이 도구는 해당 여부를 판정하지 않는다') is stated up front, so an agent can distinguish it from an adjudicating tool 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 ordering ('이 도구로 사유를 좁힌다 → must_establish 확인 → estimate_delay_penalty의 excluded_days'), and the hand-off to the sibling tool. It also flags the sw_requirement_change half-credit edge case and warns not to misread omitted entries as non-existent rules.

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

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

Annotations already mark it read-only/idempotent/non-destructive, and the description adds real behavior: deterministic application of statutory rates, a hard warning that wrong org_type yields wrong amounts, disclosure that counted_days carries a disclaimer, inferred=true flagging of interpretive (non-statutory) rates, and warnings for undeclared items and cap application. Far beyond annotation-level detail.

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 the purpose sentence and organized into scoped, bolded blocks (usage, disclaimer, response fields, args). Every section is substantive, though the org_type rate-difference warning is echoed again in the Args entry, a minor redundancy in an otherwise tight document.

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?

Given a 7-parameter legal calculation with no output schema, the description enumerates every response field (term, rate, base_amount, counted_days, amount_raw/cap/amount, warnings, legal_basis) and points to get_law_article for the source text. Nothing an agent needs to invoke or interpret results 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 0%, so the description carries the full burden and does so: contract_kind maps 1:1 to rate clauses, org_type must not be guessed, contract_amount must be the per-year amount for long-term contracts, delay_days includes excluded days, excluded_days omitted vs explicit 0 produces different warnings, accepted_portion_amount omitted vs 0 differs, and design_build_approved is a rate exception.

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 precise verb (산정/calculate) and resource (지체상금/지연배상금) and immediately distinguishes it from siblings by naming search_references for exemption cases. It also makes the legal-term asymmetry by org_type explicit, so the agent knows exactly what it computes.

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?

Explicitly rations scope: '이 도구는 지체일수를 정하지 않는다' declares fact-finding items out of scope and routes the agent to search_references for 면책 사유 disputes. It also mandates confirming org_type with the user before invoking, giving clear when-to-use and when-not-to-use conditions.

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

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

Goes well beyond the readOnly/idempotent annotations by documenting failure modes (case_body_unavailable, case_id_invalid), the meaning of existence_verified=false and source_url=null, the inability to distinguish 'not provided' from 'does not exist', and the trap that a 200 from the law.go.kr viewer proves nothing. It even prescribes a non-fabrication policy for citation links.

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 and return fields are front-loaded, then error semantics follow in a logical order. The heavy bolding and some restatement ('이건 본문만 없다가 아니다') add length, but nearly every sentence carries operational information given the error-handling surface.

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 fully carries the burden: it names the return fields (source_url, existence_verified, headnote_available, headnote_note, referenced_laws, body_excerpt), explains when each is empty, and tells the agent how to proceed in each case. Nothing needed to call it correctly 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 both parameters, and it does: kind is the 'prec'|'expc' value from search_cases output, and case_id is a numeric serial number, with the note that a case number (사건번호) is not valid here. It compensates for the coverage gap without giving format examples.

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 enumerates the exact fields returned for each kind (판시사항·판결요지·참조조문 vs 질의요지·회답·이유). This clearly separates it from sibling search_cases, which finds cases rather than returning their body.

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?

Explicitly anchors the tool to search_cases output ('case_id: search_cases 결과의 case_id') and routes back to search_cases when case_body_unavailable or case_id_invalid occurs, including the specific workaround of passing a case number as a query. It does not spell out a clean when-to-use/when-not sentence, but the conditions are unambiguous.

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

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

Annotations already cover the safety profile (readOnly, idempotent, destructive=false, openWorld), yet the description adds substantial behavior the annotations cannot convey: 6,000-char truncation plus the full set of truncation fields, the dual-corpus scope, `notes` for broken internal cross-references, `assumption` back-fill, delegation to sub-norms, and `law_currency` staleness states. This is exactly the extra context annotations cannot carry.

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?

Core purpose is front-loaded and bold section leads make it scannable, but the description is very long and reads partly as a dated changelog (multiple '(2026-xx-xx)' markers) with repeated advice about not asserting absent provisions. Length is partly justified by the tool's complexity, but it is not tight.

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 must explain return values — and it documents `truncated`, `kind`, `related_article`, `notes`, `assumption`, `implementing_articles`, `delegations`, `law_currency`, and the 404 shape in detail. An agent has everything needed to call and interpret this tool.

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% and there is a single required `ref` parameter, so the description must carry the semantics — and it does, giving three concrete format examples across article, 별표, and 예규 refs, including string-concatenation recipes from sibling tools' output. The gap left by the bare schema is fully compensated.

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 opening line states a specific verb and resource (retrieve the original text of a law article) and the description goes on to enumerate the three ref forms it accepts (statute article, 별표 table, 예규 admin rule). However, it never distinguishes itself from the sibling get_law_article_asof, which an agent must choose between for current vs. historical text.

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 explicit conditional instructions: if truncated, re-call with a paragraph suffix; if `assumption` is present, re-call with the hinted law name; if `implementing_note`/`delegation_note` exists, follow the nested refs and read those first; on 404 with `law_in_corpus=true`, don't claim the norm is absent. It does not state when to prefer get_law_article_asof, so it stops short of full alternative routing.

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

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

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?

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?

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?

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?

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?

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

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

Annotations only convey the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds substantial behavior beyond that: transmitted arguments and the prior tool-call summary are retained for operator review, the privacy policy is linked, PII must be genericized, and the user must be told before sending. This is rich, non-obvious context.

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 the consent condition and organized into clear sections (when to use / when not to use / what is transmitted / args). It is slightly repetitive — the when-not-to-use block restates the 'only when the user asked' rule already stated up front — but the redundancy serves a safety gate, so it is only mildly wasteful.

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, and for a fire-and-forget submission tool the description covers everything an agent needs: the consent prerequisite, what data is retained and where it goes, and PII handling. Nothing required to invoke it correctly 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 0%, so the description must carry the full burden, and it does: every one of the 5 parameters is explained with meaning, the category enum values are glossed in Korean with parenthetical definitions, and related_tool is given a concrete example. This fully compensates for the empty 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?

The description states a specific verb (report/submit an error or improvement request) and resource (to the operator), which is unambiguous and clearly distinct from all sibling tools that are legal search/lookup operations. It even names the exact trigger condition, so an agent can select it without opening the 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?

Explicit when-to-use (user asks to relay a report/request, with concrete example phrasings) and when-not-to-use (do not call for unanswered questions the user did not ask to forward, and do not call before answering). This is a genuine exclusion set plus alternatives, exactly the top of the scale.

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

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

Annotations only cover safety (readOnly/idempotent/openWorld), while the description discloses the entire response contract: search_scope, searched/total_cnt, retried, body_scope_caveat with relevance_verified:false, axis.gated_kinds / out_of_axis, off_topic_warning, unseen_cnt and axis_unjudged. It also warns that 0 results mean 'not found in this scope' rather than 'no such case', which is behavior an agent cannot infer from annotations.

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, usage and the alternative are front-loaded, which is good, but the body is very long and cluttered with dated changelog markers like (2026-08-29) and (2026-09-02) that add no selection value, plus repeated restatements of the same 'don't claim there are no cases' rule across several paragraphs.

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 must explain the return payload — and it does so field by field, including truncation semantics (unseen_cnt, ledger_total), verdict evidence fields, and degradation states. Given the tool's complexity and openWorld nature, an agent has everything needed to call it and to interpret results correctly.

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: query length bounds (2–100 chars) with the specific error codes query_too_short/query_too_long, automatic retry behavior, top_k allowed range 1–10 with clamping (0/negative→1, >10→10) disclosed via top_k_applied, and kind enum meanings (prec/expc/all) expanded in prose.

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?

First line states a specific verb+resource (판례·법령해석례 검색) plus the data source and freshness property (law.go.kr 실시간 조회, 항상 현행), and immediately names the sibling it hands off to for full text (get_case). An agent can distinguish it from search_law, search_references and get_case without opening any 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 an explicit when-to-use condition — use it when statutes alone are insufficient for 분쟁·처분취소·해석 disputes — and names the alternatives: get_case for body text and 국세법령정보시스템 when the user wants 국세청 예규. It also says when NOT to cite results (off-axis or off-topic hits must be verified with get_case first).

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

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

Far exceeds what readOnlyHint/idempotentHint/openWorldHint convey: it discloses truncation (truncated/backend_cap), lower-bound totals (total_found_is_lower_bound), degraded semantic search (semantic_unavailable), currency uncertainty (note_currency), and that no_corpus_match does not mean the provision is absent. That is substantive operational context. It loses a point only because the mass of caveats is hard to apply in one pass.

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 opening sentence is well front-loaded, but the body is a dense wall of dated changelog annotations, bolded asides, and response-field caveats interleaved with the core instructions. The essential call contract (query, top_k, corpus, then get_law_article) is hard to extract, and several sentences restate the same point.

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 return values — and it explains the corpus/total_found/count/truncated/degraded fields at length, which is a plus. But for a 3-parameter, dual-corpus, degraded-mode search, it omits any statement of result ordering/ranking (relevance vs article order) and what a minimal hit looks like, so an agent cannot predict the response shape beyond individual named fields.

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 the parameters — and it does document top_k's 1–20 range with out-of-range clamping to top_k_applied, and corpus values with auto behavior. But `query` gets only example strings with no described semantics (keyword vs article-number vs law-name forms are implied, not specified), leaving the required parameter underspecified for a 0% coverage 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 (검색 / return article snippets) and resource (법령 조문), and distinguishes the search step from the follow-up get_law_article. It does not explicitly contrast itself with sibling search_cases or search_references, so it falls short of a 5.

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 when-to-use routing: name a tax law → tax corpus, name a 시행령/시행규칙 → restrict to that sub-law, and `corpus` to force a side. It also says when to stop re-searching and go straight to get_law_article via implementing_articles. The one gap is no explicit statement of when to prefer another sibling search entirely.

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

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

Annotations only cover the safety profile (readOnly/idempotent/openWorld); the description goes far beyond them: no LLM/AI generation, no backend budget consumption, degradation mode `retrieval_degraded: "dense_unavailable"` with `search_unavailable` error semantics, stale-source risk via `as_of`/`superseded_risk`/`vintage_warning`, and off-corpus detection via `off_topic`/`off_topic_distance`. This is unusually rich behavioral disclosure.

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?

Well front-loaded with purpose, then sibling differentiation, then response-field semantics; bold headers make it skimmable despite its length. It is long, and the no-LLM point is stated twice ('LLM 미사용' then 'AI 생성 없이'), a minor redundancy, but the remaining length is justified by ~10 response fields with no output schema to explain them.

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 must explain return values — and it documents `matched_section`, `query_expanded`, `matched_reference`, `as_of`/`as_of_unknown`, `vintage`/`superseded_risk`, and degraded/off-topic flags. Together with the sibling routing and parameter clamping rules, nothing an agent needs to call and interpret this correctly 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 0%, so the description carries the full burden — and does: `query` is documented as natural language with a concrete example, and `top_k` gets its default (6), hard range (1–12), and out-of-range clamping behavior (0/negative→1, >12→12) disclosed via `top_k_applied` rather than erroring. No meaningful gap remains.

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+scope: integrated search over a public-procurement corpus (statutes + contract 예규 + PPS/MOIS detailed standards + practical guides). It explicitly contrasts itself with the sibling search_law ('법령 조문 전용인 것과 달리'), so an agent can route 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 affirmative use cases (낙찰하한율·적격심사 배점·실무 절차 — questions outside statutory text) and explicit exclusions with named alternatives (tax-law questions → search_law or get_law_article). It even warns against misreading a 0-result here as 'no such regulation exists'.

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