contract-compass

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

Annotations already cover safety (readOnly, non-destructive, idempotent), and the description adds far more: the tool cannot compute rates and defers with met: null when the rate is absent, the five verdict values with the meaning of single_item_only (only that material adjusts, not the whole contract amount), the 2026-08-29 revision making the two tracks independent so that verdict can be single_item_only below the 3% threshold (answering '조정 불가' would be wrong), and the default-to-item method with disclosure in the response. No contradiction with 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?

Long but dense and well front-loaded: the critical limitation (cannot compute rates) is bolded early, verdict meanings and the two-track revision are bolded, and the Args section is one-line-per-parameter. There is minor repetition — the rate-computation limitation and the 3% threshold appear more than once — but the length is justified by 12 parameters and intricate legal logic.

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 a 12-parameter legal decision tool with 0% schema description coverage and no output schema, the description covers the five deterministic criteria, all five verdict values including exception_path (recognition subject is the ordering agency) and undetermined, the single-item two-track edge case, formulas, and default behaviors. Nothing critical for calling it correctly appears 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 succeeds: all 12 parameters get meaning, format, or defaults — org_type enum with a '추측 금지' warning because thresholds differ, YYYY-MM-DD format plus the first-contract rule for long-term contracts, negative rates allowed for adjustment_rate_pct, omission behavior for method_specified_in_contract, and the 30%→0.3 conversion example for advance_payment_ratio.

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: '물가변동 계약금액 조정(에스컬레이션) 요건 판정 + 산식 적용 — 이행단계 Phase 3'. The three example questions ('자재값이 올랐는데 계약금액을 올려받을 수 있나', '90일 지났나', '단품 조정 되나') act as concrete routing triggers that separate it from delay/penalty siblings like delay_exemption_guide and estimate_delay_penalty.

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 when-to-use triggers (the '쓰라' example questions) and a hard boundary: the tool cannot compute the adjustment rate, so adjustment_rate_pct must come from the user, otherwise requirement ② is left as met: null and judgment is deferred. It also warns against fabricating missing values. It does not name sibling tools as alternatives for rate computation or legal reference, 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?

With annotations already declaring readOnly/openWorld/idempotent behavior, the description adds meaningful behavioral detail: first vs. second call behavior, server-side continuation without session ids, and the selection_ignored_reason mechanism. It also discloses that omitting enterprise flags can silently remove negotiated-contract candidates.

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 purpose is front-loaded and the parameter explanations are dense with necessary legal detail. It is long and somewhat repetitive—especially the warning about women/disabled/social enterprise flags—but each section contributes operational value for a complex 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?

Given the tool's high complexity and lack of output schema, the description covers the two-stage recom-mendation flow, key return objects (follow_up_questions, final_recommendation, selection_ignored_reason), and per-parameter rules. Still, it does not fully describe the structure of candidate/final_recommendation objects or provide a concrete output example.

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?

The schema provides 0% description coverage, so the description fully compensates by explaining each parameter's meaning, conditional relevance, legal thresholds, and examples. It even gives concrete JSON format for follow_up_answers and explains when fields like selected_rule_id are ignored.

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 sentence clearly states the tool's function: the rule engine returns applicable contract-method candidates and statutory basis. The verb "반환" plus the specific resource (계약방법 후보/법령 근거) distinguishes it from sibling search/case/law 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?

The description gives an explicit two-stage workflow: call once to get follow_up_questions, then call again with follow_up_answers to get final_recommendation. It also warns not to guess when answers are unknown and explains when flags must be set. However, it does not explicitly compare this tool with sibling alternatives.

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 carry readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds substantial behavior beyond that: the tool refuses to make applicability judgments (deferring to the contracting officer), rejects inapplicable contract-type/ground combinations via ground_not_applicable, surfaces excluded grounds via grounds_excluded_by_contract_kind (they don't silently disappear), and warns about quote_truncated items. All non-obvious state changes and limitations are disclosed. No contradiction with 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?

Long, but every sentence earns its place for a genuinely multi-behavior guide tool. Front-loaded with purpose and a direct answer to typical user questions, then organized with a numbered delivery list, a bolded usage sequence, and a cautions paragraph. Bold key terms (must_establish, quote_truncated) aid scanning. No wasted prose.

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 there is no output schema and 0% schema param coverage, the description carries the full burden — and it is complete. It documents the return fields (must_establish, ground_not_applicable, grounds_excluded_by_contract_kind, quote_truncated), the invocation protocol including an ordering constraint relative to estimate_delay_penalty, a partial-day edge case, and the tool's honest limitation (no judgment). Nothing an agent needs 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 description coverage is 0%, so the description bears full responsibility and meets it. Both parameters are explained: contract_kind ('estimate_delay_penalty와 같은 값', maps to a standard-condition family, and warns that the actually-incorporated conditions are the truth source) and ground (omit → full list; specify → one detailed ground). The enum values get contextual meaning, e.g., the sw_requirement_change example clarifies contract-type narrowing. Excellent compensation for the schema 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 purpose: a guide to grounds for excluding days from delay penalties (지체일수 불산입), explicitly framed as the companion to estimate_delay_penalty ('estimate_delay_penalty가 정하지 않는 부분'). It names exactly what the tool delivers (three items: grounds list, must_establish facts, precedent replies) and clearly declares what it does NOT do (judge applicability). Distinguishes itself cleanly from the sibling estimate_delay_penalty and search_references.

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 usage sequence: narrow grounds → verify must_establish with the user → feed excluded days back into estimate_delay_penalty's excluded_days. Contains a concrete special case (sw_requirement_change counts only 1/2 of days) and a routing rule for truncated quotes (use search_references). No ambiguity about when or how to invoke.

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?

Adds substantial behavior beyond annotations: deterministic computation, asymmetric legal terms, 30% cap application, response field semantics, warnings, and the fact that delay_days/excluded_days are taken as user-declared values without validation. Annotations already mark it read-only and non-destructive; the description enriches trust boundaries.

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 every sentence earns its place: summary, key distinctions, limitations, response field overview, and detailed args. Front-loaded with the core purpose and key warning about rate differences, making it scannable for an agent.

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, but the description lists all response fields with meanings and caveats. Given 7 parameters, no output schema, and legal complexity, this description fully compensates with no obvious gaps.

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 full parameter burden. It explains every parameter, including that delay_days includes excluded days, excluded_days can default to 0 with a warning, contract_amount must be per-year for long-term contracts, and org_type must not be guessed.

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?

Description clearly states the tool computes delay penalties using statutory rates and a 30% cap, with explicit differentiation between national and local terminology. The verb+resource pairing ('산정') distinguishes it from sibling tools like check_price_adjustment or delay_exemption_guide.

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?

Provides explicit when-to-use guidance: use for computing delay penalties per legal rates, but not for fact determinations like delay days. It names an alternative (search_references) for exemption disputes and instructs the agent to confirm org_type from the user.

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 the tool read-only and idempotent; the description adds rich behavioral context beyond that: source_url provenance, the case_body_unavailable error semantics, the inability to distinguish missing body from nonexistent ID, and the law.go.kr 200-blank-page trap. This directly prevents link fabrication and citation errors.

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?

Although long, the description is front-loaded with purpose and every block earns its place: citation requirement, error semantics, and the no-fabrication rule are all operationally critical. Bold formatting and clear paragraph separation make the caveats scannable.

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 a two-parameter read tool with no output schema, the description covers input provenance, error behavior, source_url handling, and the content categories returned per kind. It could more explicitly list the normal response fields, but an agent has enough information to invoke the tool correctly and handle failures safely.

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?

The input schema has no parameter descriptions, so the Args section compensates by specifying that kind is 'prec' | 'expc' and that both parameters must come from search_cases results. It does not explain the meaning of the enum values or case_id format, but the provenance rule is the most important missing schema information.

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 phrase '판례/해석례 본문 조회' names the exact operation and resource, and the dash clause enumerates the body sections returned for each kind (판시사항·판결요지·참조조문 vs 질의요지·회답·이유). This makes it clearly distinct from sibling search_cases, which handles finding cases rather than retrieving full 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?

The description explicitly ties both parameters to search_cases results and gives a conditional rule: if case_id came from search_cases, cite only that result's metadata; otherwise re-run search_cases. This is strong routing guidance, though it does not provide a broad 'use this when...' comparison against all sibling tools.

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 declare readOnly/openWorld/idempotent hints, and the description adds substantial context beyond them: dual-corpus auto-routing by law name, the meaning of notes (unfixed internal cross-references), assumption (inferred law name), implementing_note vs delegation_note, kind variants (table, admin_rule), and 404 semantics distinguishing a missing article from a missing statute — exactly the behavioral disclosures the rubric rewards. No statement contradicts the 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?

The description is long, but it is organized into bolded, dated sections each addressing a distinct failure mode (corpus confusion, delegation, tables, admin rules, 404s), which makes it skimmable. It is front-loaded with the one-line purpose followed by operational detail that genuinely earns its place for a tool with this many edge cases. Minor deduction because the dated changelog markers add noise and total length approaches the upper bound.

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 a tool with no output schema but high complexity, the description documents the conditional response fields (notes, assumption, implementing_note, delegation_note, kind, related_article, cites) and the error case (article_not_found, law_in_corpus, corpus_laws, corpus_admin_rules). It covers corpus scope, delegated norms, table and admin-rule variants, and what not to conclude when values are absent — very little an agent needs is left to inference.

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 delivers comprehensively. The Args section documents three distinct ref formats with concrete examples (statute, table, admin rule), plus equivalence guidance ('국가를 당사자로 하는... 시행령 제26조' = '국가계약법 시행령 제26조') and the note that search hits can be passed through unchanged.

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 opens with '법령 조문 원문 전체 조회' — a specific verb (조회) and resource (full text of statutory articles) that immediately establishes the tool as the canonical read path for statute text. It further separates itself from siblings by explicitly wiring in search_law's law_refs for tables and search_references' source+section for admin rules, and the repeated '현행 그대로' (current as-is) wording distinguishes it from get_law_article_asof.

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?

Usage guidance is dense and operational: it gives exact ref formats for statutes, tables, and admin rules, and states that search-lookup results can be passed in verbatim. It also specifies follow-up actions — re-call with assumption.hint's law name when the wrong corpus was inferred, read implementing_articles refs through this same tool, and redirect to law.go.kr when in_corpus is false instead of claiming a regulation does not 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?

Beyond the readOnly/openWorld/idempotent annotations, the description discloses critical edge-case behavior: uncovered dates return error asof_not_covered rather than approximations, future dates return today's version with as_of_in_future=true, and versions_complete/coverage flags warn about incomplete history. This is rich contextual disclosure that directly affects how an agent should interpret results.

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 description is long but every section earns its place: purpose, usage rule, response fields, and failure modes. It is front-loaded with the core distinction from get_law_article, uses bolded warnings for critical caveats, and structured lists make the edge-case behavior easy to parse.

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 the tool's complexity, zero output schema, and zero schema descriptions, the description is exceptionally complete. It covers the normal response, all relevant response fields, what happens for uncovered dates, future dates, incomplete version history, and explicitly instructs the agent not to fabricate applicable law.

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 carries full responsibility for parameter meaning. It defines ref with a concrete example ('국가계약법 제27조') and date with both accepted formats and a semantic example ('계약 체결일'). Both parameters are meaningfully explained beyond the bare 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 opens with a specific verb and resource: 조회 of the provision text that was in effect at a specific time. It explicitly contrasts with get_law_article, which '항상 현행이다,' making the tool's differentiating purpose unmistakable.

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 description gives explicit when-to-use guidance: if the relevant event is in the past (contracts, bids, dispositions, audits, disputes), use this tool. It also states the alternative get_law_article for current law and warns against applying current text to past events, with concrete example queries.

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?

It discloses important behavior beyond annotations: the server auto-attaches the previous tool call, the server cannot see the user's original question, and personal identifying combinations should be generalized in messages. This adds real context and contradicts nothing in the 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?

The description is long but well-structured with bolded leads and clear sections. Every section adds necessary policy or parameter context, though it could be tightened without losing meaning.

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 a reporting/logging tool with no output schema, the description is complete: it explains the purpose, exclusive triggers, category meanings, privacy handling, and server-side behavior. No critical invocation context 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%, but the description fully compensates by explaining every parameter: enum meanings for category, message semantics per category, and examples for related_tool, related_query, and expected. This is far above the schema alone.

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 clearly states the tool is for reporting errors/improvements and logging original questions (category='question_log'). It uses specific verbs and distinguishes itself from legal research siblings like search_law and get_case.

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 description gives explicit when-to-use instructions: report first when the user says something is wrong, report when tool results conflict with statutes/numbers/precedents, and log question_log only when a hint requests it, not when the agent feels it answered well.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond that: it is a live real-time query to law.go.kr, does not use an LLM, its response describes what and how many items were seen, the meaning of search_scope, the searched/retried fields, the critical interpretation that 0 results means 'not found in this scope' not 'no such case exists', and the axis gating semantics. It even tells the agent how to translate results to the user, including when to refer to 국세법령정보시스템. This is far beyond what annotations alone provide.

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 description is information-dense but quite long, with multiple nested bold sections and dated caveats (2026-08-29, 2026-09-02). While every sentence carries important behavioral warnings, the structure is somewhat sprawling for an agent to parse quickly. It front-loads the core purpose well, but the axis explanation is complex and could be more compactly organized. The length is justified by the semantic complexity, so it earns a 3 rather than a 2, but it is not a model of concision.

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?

The description is exceptionally complete for a search tool with no output schema. It explains the response shape conceptually (searched, retried, axis, gated_kinds, out_of_axis, case_type, data_source), tells the agent exactly how to interpret 0-result cases, warns against misquoting the absence of 예규 versus 판례, and provides user-facing guidance. Given the tool's complexity and the absence of an output schema, the description carries the full burden and does so thoroughly. There is no significant missing context that an agent needs to invoke or interpret this tool 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?

The input schema covers the parameter names, types, defaults, and the kind enum, but has 0% schema description coverage in the sense that it lacks descriptive text for each param. The description compensates richly: query is explained as '핵심 명사 위주 검색어' with examples ('부정당업자 제한', '유찰 수의계약') and the note that natural language sentences are accepted with automatic retry. It also clarifies top_k is per-kind (종류당 반환 건수). The only minor gap is that top_k bounds (max 10) are stated but the schema doesn't enforce them, so the description carries that burden adequately. One could argue a 5, but there is no explicit note about what happens when top_k exceeds the max or is set to 0, so 4 is fair.

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 opens with a clear definition: '판례·법령해석례 검색 — law.go.kr 실시간 조회(항상 현행). LLM 미사용.' It names the resource (law.go.kr), the type of content (판례 and 법령해석례), and distinguishes the use case from simply relying on statutes. It also explicitly contrasts with the sibling tool get_case(kind, case_id) for continuing to read the full text. This is a specific verb+resource+scope statement that clearly separates it from 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?

The description explicitly tells the agent when to use this tool: when disputes, dispositions, or interpretation conflicts arise and statutory text alone is insufficient ('조문만으로 부족할 때 쓰라'). It also names the follow-up tool get_case for reading full text, and distinguishes search_law presumably for statutes. It gives concrete query guidance (핵심 명사 위주) and explains automatic retry behavior. This is explicit when-to-use guidance with alternatives.

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 the operation read-only/idempotent, and the description adds substantial non-obvious behavior: two-corpus routing with fallback, response fields like truncated/complete/total_found_is_lower_bound meaning lower-bounded counts, degraded semantic search, and cautions about deleted/repealed provisions. No contradiction with 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?

Long, but every block addresses a real hazard: corpus misattribution, delegated articles, attached tables, truncation semantics, and degraded search. It is front-loaded with the one-line purpose before deep behavioral detail, and uses bold to mark the most critical warnings.

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 covers the response semantics an agent must interpret correctly: corpus, total_found vs count, truncated, complete, lower-bound flag, search_scope/searched, degraded, and hit-level fields. It also specifies follow-up actions (get_law_article, law.go.kr) and error handling, so nothing required for a safe call 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%, but the Args section fully compensates: query gets concrete examples ('수의계약', '시행령 제26조', '소득세법 제55조'), top_k gets default and max, and corpus gets exact allowed values 'contract'/(공공계약) and 'tax'/(세법). This is far 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?

The opening line '법령 조문 검색 — 키워드 또는 조문번호로 조문 스니펫 반환(상위 top_k건)' names a specific verb, resource, and return shape. It also distinguishes itself from get_law_article by explicitly handing off full-text needs to that sibling.

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 description explicitly states when to use this tool versus get_law_article ('전문이 필요하면 get_law_article(ref)로 이어서 조회'), instructs not to re-search when implementing_articles exist ('다른 도구로 다시 검색하지 말고'), and explains when to force corpus with top_k guidance. Error handling for no_corpus_match also prescribes the correct response behavior.

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 provide readOnly, idempotent, and openWorld hints, but the description goes far beyond them. It discloses that no LLM is used, that only source text is returned, that matched_section refers to the specific clause while the body is the full article, that query_expanded reflects glossary-based query expansion, and how to interpret off_topic responses. It even discloses a tax-law blind spot with an effective date. This is exceptional behavioral transparency.

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 description is long but dense; every paragraph adds necessary operational guidance such as scope, exclusions, return-field semantics, and off-topic protocol. It is front-loaded with purpose and then exclusions, and the warnings are clearly bolded. Minor redundancy and length keep it from a perfect score, but the length is largely justified by the tool's complexity.

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 a two-parameter search tool with no output schema, the description is remarkably complete. It covers scope, usage, exclusions, key return fields (matched_section, query_expanded, off_topic), and even instructs the agent on how to cite evidence and when to report issues. There is no critical missing information for correct invocation.

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 compensate. The Args section explains query as a natural-language search term with a concrete example, and top_k as return count with default 6 and max 12. This adds meaning beyond the bare schema. Slightly more detail about top_k behavior (e.g., truncation or ranking effects) would be useful, but the current coverage is solid.

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 and resource: integrated search over the public contract corpus, covering statutes, contract rules, procurement/MOI detailed standards, and practical guides. It explicitly differentiates from search_law, which is devoted to statutory provisions only. An agent can immediately know what this tool does and how it differs from its closest sibling.

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 explicitly says to use this tool for questions outside statutory text, such as 낙찰하한율, 적격심사 배점, and 실무 절차. It also names alternatives for excluded cases: tax law questions should go to search_law or get_law_article, and off-topic queries should be reported via report_issue. This is clear when-to-use and when-not-to-use guidance with concrete alternatives.

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