contract-compass

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

Even though annotations already mark the tool as read-only and idempotent, the description adds substantial behavioral context: it cannot compute the rate itself, it uses user-supplied `adjustment_rate_pct`, it returns distinct verdicts including `single_item_only`, `exception_path`, and `undetermined`, and it explicitly instructs the agent not to invent missing values. This goes well beyond the structured 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 the tool is genuinely complex with 12 parameters and multiple legal branches. It is well front-loaded: purpose and the central 'cannot compute rate' limitation appear before verdicts and parameters. A few points are restated across the verdict list and the Args section, so it could be slightly tighter.

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 compensates by enumerating all possible verdicts and their precise meanings, including the critical `single_item_only` nuance and the exception-path semantics. It covers the omission behavior, the two independent tracks, and the relationship between the 90-day exception and the 3% threshold, leaving little for an agent to infer incorrectly.

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 parameter-documentation burden. It explains every parameter's meaning, format, default, and pitfalls, including that `advance_payment_ratio` is a ratio (0.3 for 30%), `adjustment_rate_pct` may be negative for decreases, and `single_item_share_over_5permille` is a check the server cannot itself calculate.

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 names a specific action and object: '물가변동 계약금액 조정(에스컬레이션) 요건 판정 + 산식 적용', and gives concrete sample questions ('자재값이 올랐는데...', '90일 지났나', '단품 조정 되나'). It also clearly states what the tool cannot do (compute the adjustment rate), which distinguishes it from the surrounding legal-search and contract-decision 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 gives strong when-to-use signals and tells the agent not to fabricate missing rate data, leaving the requirement as 'met: null' instead. It also warns about the single-item track being independent of the 3% threshold. However, it does not explicitly name a sibling alternative for cases where the tool is not appropriate, so it stops just short of a 5.

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 the two-stage decision flow, the behavior of selected_rule_id when invalid (selection_ignored_reason), and the critical consequence of omitting enterprise flags (negotiation candidates disappear). This is rich behavioral context that annotations alone do not 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 long but appropriately so for a 16-parameter legal rule engine. It is front-loaded with the core purpose, then systematically walks through each argument with necessary legal context and warnings. No sentence is wasted; the length is justified by the 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?

With no output schema, the description explains the return concepts: candidates, legal basis, follow_up_questions, final_recommendation, and selection_ignored_reason. It also covers the two-stage invocation model and the conditional logic for enterprise flags. For a tool of this complexity, the description is remarkably complete.

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 delivers. Every meaningful parameter is explained with allowed values, legal references, conditional relevance, and warnings (e.g., is_small_enterprise, is_women_enterprise, follow_up_answers). This far exceeds 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: '계약방법 결정론 판정 — 룰엔진이 적용 가능한 계약방법 후보와 법령 근거를 반환' (rule engine returns applicable contract method candidates and legal basis). This clearly distinguishes it from sibling tools like search_law or estimate_delay_penalty, which address different legal/calculation tasks.

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 provides clear workflow guidance: call once to get follow_up_questions, ask the user, then call again with follow_up_answers to receive final_recommendation. It also warns against guessing answers. However, it does not explicitly state when not to use this tool or name alternative tools, so it stops short of a 5.

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?

Despite rich annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description adds substantial behavioral context: the tool never adjudicates (judgment is the owner's), it rejects non-applicable combinations via ground_not_applicable and lists excluded grounds via grounds_excluded_by_contract_kind so they 'don't disappear silently,' and it warns against fabricating continuations of truncated citations. The openWorldHint is consistent with the full-enumeration-plus-exclusion behavior described. 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 — every paragraph carries distinct value appropriate to a domain-specific legal guide. Purpose is front-loaded, followed by the critical 'does not determine' disclaimer, then numbered deliverables, then the integration workflow, contract-kind narrowing, and the truncated-quote safety warning. Bold markers, numbered items, and parenthetical specifics keep it scannable; nothing is 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?

For a complex tool with no output schema, the description is remarkably complete: it covers purpose, the three output categories, usage order and sibling integration, partial-exclusion rule (sw_requirement_change 1/2), contract-type narrowing and grounds_excluded_by_contract_kind behavior, and the quote_truncated safety advisory. The response field names it mentions (ground_not_applicable, grounds_excluded_by_contract_kind, quote_truncated) give the agent enough to interpret returns despite no formal output schema.

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 full weight — and does. contract_kind is explained as 'same value as estimate_delay_penalty,' mapped to the general-conditions series, with a warning that the incorporated conditions are the source of truth. ground is explained as optional, for viewing one reason in detail, with default full-list behavior. The body additionally clarifies subtle enum semantics (e.g., sw_requirement_change applies only to software contracts and contributes 1/2 of days), fully compensating for the schema's lack of descriptions.

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 reasons for excluding (불산입) delay days, explicitly positioned as 'the part estimate_delay_penalty does not determine.' Names the three concrete deliverables (regulation reason list with citations, must_establish facts to verify, and ministry precedents) and distinguishes itself from the sibling estimate_delay_penalty. The opening use-case questions ('이 지연은 우리 책임이 아닌데...') make the intent 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?

Extremely explicit: provides a step-by-step usage order (narrow reasons → verify must_establish with user → feed excluded_days into estimate_delay_penalty), gives the exact question types this tool answers, and names the alternative (search_references) for quote_truncated cases. Also states what the tool does NOT do — determine applicability, which belongs to the contracting officer — preventing misuse.

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 indicate read-only, idempotent, non-destructive behavior, and the description adds substantial behavioral context: it applies legal rates deterministically, does not decide factual delay days, reflects user-declared values, emits a counted_days.disclaimer, and exposes warnings about undeclared inputs. No contradiction with annotations exists.

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 tightly structured with clear sections: headline purpose, critical rate differences, non-responsibilities, response fields, and parameter semantics. Every block adds essential information for a complex legal calculation tool, and the most important warnings are bolded and front-loaded.

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, 7 parameters, no output schema, and no nested schema information, the description is exceptionally complete. It explains all inputs, key calculation behavior, response fields, legal basis lookup via get_law_article, limitation disclaimers, and when to route to another 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%, but the description fully compensates with detailed Korean-language semantics for every parameter. It explains enum values in context, warns against guessing org_type, clarifies that contract_amount should be the annual amount for long-term contracts, and explains the relationship between delay_days and excluded_days.

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 precise verb and resource: '지체상금(국가·공기업)·지연배상금(지방) 산정' making it clear this tool calculates statutory delay penalties. It further specifies scope by naming the legal rates, base amount, and 30% cap, and distinguishes itself from siblings by explicitly stating it does not determine delay days.

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: confirm org_type with the user before invoking, use declared delay/excluded day values rather than adjudicating excuses, and use search_references when exemption eligibility is the real issue. It clearly states what this tool does NOT do, which is strong alternative guidance.

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?

Discloses the error behavior in detail: error:"case_body_unavailable" means source_url is null and existence_verified is false, and that the tool cannot distinguish a missing body from a nonexistent ID. It also explains that law.go.kr returns 200 for nonexistent IDs, so an open link is not proof of existence.

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, then organized into clear paragraphs covering source_url, error behavior, and fallback rules. Every sentence earns its place, especially the warning about not fabricating links.

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 what the response contains, the meaning of key fields, the error case, and the correct action when the body is unavailable. The tool's complexity is high, and the description addresses the main pitfalls an agent would face.

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 Args section carries the burden. It explains that kind must be 'prec' or 'expc' from search_cases results and that case_id comes from search_cases. It could expand the abbreviations or give an example, but it adds the critical provenance semantics.

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 the exact operation ('판례/해석례 본문 조회') and enumerates the content types returned for each case kind. The title and first line make it easy to distinguish from siblings like search_cases or get_law_article.

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 concrete guidance: use case_id from search_cases results, cite only the search_cases fields when the body is unavailable, and fall back to search_cases when the ID is not from that source. It also tells the agent when not to fabricate source_url links.

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/non-destructive, and the description adds substantial context beyond them: the two-corpus auto-routing behavior, the meanings of notes (unmaintained cross-references), assumption (inferred law name), implementing_note, delegation_note, kind ('table'/'admin_rule'), related_article, 404 semantics with law_in_corpus, and the statement that text is returned unmodified from law.go.kr. No contradiction with annotations; '우리가 고치지 않는다' aligns with readOnlyHint=true.

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 front-loaded with the core purpose and each bolded section addresses a real failure mode (wrong-law citation, unmaintained cross-refs, delegated values, table vs. article, admin-rule identity, 404 misinterpretation). Minor deduction for changelog-style date stamps ('2026-08-29', '2026-08-23', '2026-09-04') that add noise for an agent and could be dropped 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?

With no output schema, the description must convey return semantics, and it does so thoroughly: notes, assumption, implementing_note/delegation_note, kind, related_article, law_in_corpus, and the corpus inventory lists. For a single-param tool with a complex response domain this is nearly complete. The gap is the unaddressed get_law_article_asof sibling and the absence of any guidance about very long table truncation, but those are minor against the coverage provided.

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% — the only param 'ref' has no schema description — so the description carries the full burden and fully compensates. The Args section gives three concrete formats (statute article, table/별표 reference, administrative rule reference), notes both full and abbreviated law names are accepted ('국가를 당사자로 하는...' = '국가계약법'), and explains the corpus is auto-selected by law name so the caller need not disambiguate.

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 '법령 조문 원문 전체 조회' is a specific verb+resource statement (retrieve full original text of law provisions), and the description distinguishes this read tool from search_law/search_references by explaining they feed references INTO this tool. However, the closest sibling get_law_article_asof is never mentioned, so the differentiation is incomplete.

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?

Exceptionally explicit guidance: when search_law returns a table ref or search_references returns source+section, feed them here; when assumption.hint indicates a wrong law, re-call with the law name attached; when implementing_note is present, read its refs with this same tool and '추가 검색 불필요'; when delegation_note has in_corpus=false, route the user to law.go.kr instead of claiming the regulation doesn't exist. Alternatives, re-call conditions, and explicit 'do not' instructions are all present.

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 read-only/idempotent annotations, the description discloses many non-obvious behaviors: uncovered early dates return asof_not_covered with coverage metadata rather than a approximate version, future dates return today's text with as_of_in_future true, and the agent must not invent applicable law for uncovered ranges. This is exactly the kind of behavioral context that prevents misuse.

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?

Though long, the description is well-structured with bold headers, bullets, and front-loaded purpose. Every section earns its place: usage warning, response fields, error behavior, and argument examples, and since there is no output schema, the response-field list is necessary.

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 tool with no output schema: it covers purpose, sibling distinction, required argument semantics, response fields, coverage limits, error conditions, and future-date behavior. A agent has enough to call the tool correctly and interpret results without guessing.

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 provides zero description for ref and date, so the description carries the full burden. It defines ref as an article reference with concrete examples and date as a 기준일 in YYYY-MM-DD or YYYYMMDD format with a contract-date example, and the prose further clarifies date edge cases like future dates.

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: querying the original text of an article that was in force at a given time, backed by law.go.kr's history service. It also immediately distinguishes itself from get_law_article, which is always current, so an agent can tell the two apart without inspecting schemas.

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 says get_law_article is always current and that applying it to past events silently gives wrong answers, and instructs to forcibly use this tool whenever the relevant event is in the past. It supplies concrete examples and even warns that future dates cannot be answered, telling the agent to not treat the returned text as applicable law.

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 all false and providing little safety context, the description carries the full burden and does so well. It discloses that the server auto-attaches prior tool-call history, that the server cannot see the user's original question after translation, and that personal identifying combinations must be generalized.

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 key terms and clear sections. Every paragraph adds necessary operational detail, though the question_log explanation is somewhat verbose. It is front-loaded with the core purpose and remains readable.

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 minimal annotations, the description is remarkably complete. It covers purpose, triggers, exclusions, privacy handling, server behavior, and parameter semantics, leaving no major operational gap.

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. It explains category values, message content requirements, related_tool with an example, related_query as a reproducing query, and expected as the believed-correct value or provision. This fully covers all five parameters.

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 identifies the tool as a reporting/logging mechanism for errors, improvements, and original question logs. It distinguishes itself from sibling legal-research tools by using specific verbs like '제보' and '기록' with explicit categories.

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: report before correcting when the user says something is wrong, report on clear mismatches with legal text, and log question_log only when the response hint requests it. It also states when NOT to use it ('네가 스스로 잘 답했다고 느낀 경우까지 남길 필요는 없다').

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(readOnlyHint, openWorldHint, idempotentHint)가 안전성 프로파일을 이미 담았고, 설명은 그 위에 실제 동작 특성을 대폭 추가한다: '0건은... 이 범위에서 못 찾았다이다'는 open-world 의미론과 정합하는 해석 규칙, '넓혀서 다시 찾았으면 retried가 true', axis.gated_kinds/out_of_axis의 필터링 동작, '예규는 담지 않는다/판례는 담는다'는 코퍼스 구성까지 공개한다. 최대 2회 자동 재시도 동작도 포함된다. 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?

분량은 상당하지만 목적→사용 조건→get_case 연결→응답 의미론→코퍼스 경계 순으로 전면 적재(front-load)된 구조다. 각 문단이 서로 다른 운영상 함정(0건 해석, axis 경계, yegyu/prec 반대)을 짚어 중복이 없다. 다만 중간중간 날짜 표기(2026-08-29, 2026-09-02)와 '두 종류의 경계가 서로 반대' 경고 등은 문장 수를 늘리는 비용이 있다.

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?

출력 스키마가 없는 복잡한 도구임에도 응답 필드(search_scope, searched, retried, axis, case_type, data_source)의 의미와 해석 방법, 0건의 오해 가능성, 예규 부재 시 사용자 안내 문구까지 설명한다. 에이전트가 도구를 선택하고 호출하고 결과를 사용자에게 정확히 전달하는 데 필요한 정보가 빠짐없이 담겨 있다.

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가 0%이므로 설명이 전적으로 보완해야 하는데, 세 파라미터 모두 풍부하게 보완한다: query에 '핵심 명사 위주' 패턴과 실제 예시 2개 및 자연어 수용·자동 재시도 조건, top_k에 '종류당 반환 건수'와 schema에 없는 최대 10 제한, kind에 각 enum 값('prec'=법원 판례, 'expc'=법제처 법령해석례)의 의미를 부여한다. 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?

첫 문장 '판례·법령해석례 검색 — law.go.kr 실시간 조회(항상 현행)'이 구체적 동사+자원+소스를 명시한다. '본문은 get_case(kind, case_id)로 이어서 조회'라고 후속 도구를 명명해 형제 도구와의 역할 분담도 드러난다. '조문만으로 부족할 때'라는 표현은 search_law와의 차이까지 간접적으로 구분한다.

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?

'분쟁·처분취소·해석 다툼...에 조문만으로 부족할 때 쓰라'는 사용 조건을 명시하고, get_case를 본문 조회용 대안으로 이름까지 들어 지정한다. 예규 부재 시 '국세법령정보시스템으로 안내하라'는 대체 경로 안내까지 포함한다. 쓰지 말아야 할 상황(예규 찾기)과 그때의 대안이 모두 열거되어 있다.

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?

The description goes far beyond the readOnly/openWorld/idempotent annotations: it discloses dual-corpus fallback behavior, truncated vs lower-bound total semantics, semantic-search degradation, deleted/repealed provision notes, delegated articles lacking implementing_articles, and table-index behavior. It also warns against citing tax results as public-contract grounds. No contradiction with annotations; openWorldHint aligns with the statement that zero results are not evidence of absence.

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 well-structured: a one-line summary, bolded critical warnings, and a final Args block. Every sentence carries operational or safety guidance, and the most important corpus and citation constraints are front-loaded. The density is high enough that parsing requires effort, but the structure mitigates the length.

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 documents the critical response fields (corpus, total_found, count, truncated, complete, total_found_is_lower_bound, search_scope, searched, degraded, hit-level notes, implementing_articles, delegated, related_articles, law_ref) and error cases. It also covers follow-up actions and citation constraints, making it complete for correct invocation and interpretation. The only minor ambiguity is the undefined `corpus_laws`, but it does not undermine the overall completeness.

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 fully compensates. The Args block gives concrete query examples ('수의계약', '시행령 제26조', '소득세법 제55조'), top_k default 8/max 20, and corpus legal values 'contract'|'tax' with auto-selection behavior. This adds meaning the schema cannot convey.

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 action and resource: keyword/provision-number search returning provision snippets with top_k. The '조문' (provision) focus clearly separates it from sibling case/reference searches, and the follow-up to get_law_article for full text is explicitly named. No ambiguity about what this tool does.

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 routes usage: full text needed → get_law_article(ref); implementing_articles present → pass that reference directly to get_law_article and do not search another tool; no_corpus_match → clarify scope and point to law.go.kr. It also gives conditions for forcing corpus and for raising top_k. This is explicit when/when-not/alternatives guidance.

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 the safe read-only/idempotent/open-world profile, but the description adds substantial context beyond them: no-LLM behavior with 'LLM 예산 미차감', the dated tax-corpus blind spot ('2026-08-29 정직 공시'), matched_section meaning the section matched is the '항' while text is the whole '조', query_expanded glossary-alias behavior, and the off_topic flag semantics. It also reinforces openWorldHint with explicit '0건이 나온 것을 세법에 그런 규정이 없다로 옮기지 마라' warnings.

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 organizational devices — bold lead-ins, date stamps, paragraph-per-caveat structure — keep it scannable and the purpose is front-loaded in the first line. Each section carries distinct operational information; the off_topic paragraph is slightly verbose and the anti-negative-inference warnings repeat a similar pattern across the tax and off-topic sections, keeping it just shy 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?

Despite no output schema, the description pre-explains every non-obvious response field an agent will encounter (matched_section, query_expanded, off_topic, off_topic_distance, note_off_topic) and prescribes the fallback action (report_issue with category='question_log'). For a 2-input, multi-caveat search tool, nothing needed to invoke it correctly or interpret its 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 must compensate — and it fully does. query is defined as natural language with a concrete example ('적격심사 낙찰하한율 50억 미만'), and top_k gains a maximum constraint of 12 that the schema does not state (schema only shows default 6). Both parameters receive meaning beyond the raw 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 opening line names a specific verb and resource ('공공계약 코퍼스 통합 검색 — 법령+계약예규+조달청·행안부 세부기준+실무가이드'), and sibling differentiation is explicit: 'search_law가 법령 조문 전용인 것과 달리 예규·적격심사 세부기준·실무가이드까지 검색한다.' An agent can distinguish this from search_law without inspecting schemas.

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 guidance is given ('낙찰하한율·적격심사 배점·실무 절차 등 법령 본문 밖 질문에 사용하라'), and when-not-to-use routing names alternatives: tax questions go to 'search_law... 또는 get_law_article로 가라'. It also tells the agent what NOT to conclude from 0 hits or off_topic results, which is unusually complete usage guidance.

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