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 declare readOnly/idempotent/non-destructive/safe-read, so the bar is the extra behavioral context — and the description supplies a great deal: rejection behavior (ground_not_applicable), silent-omission guarantees (grounds_excluded_by_contract_kind, day_count_rules_excluded), provenance limits (general_conditions_in_corpus: false for construction, admin_rule_version_in_corpus: false meaning version UNKNOWN not latest), the half-credit rule for sw_requirement_change, and anti-hallucination instructions (don't invent URLs; don't quote quote_truncated items). This is exactly the beyond-annotation disclosure the dimension rewards.

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 purpose and the non-judgment constraint, then ordered into workflow and per-field caveats. Most sentences target a concrete failure mode (fabricated links, silent omissions, truncated quotes), so they earn their place; there is mild editorializing ('이 서버가 막으려는 오답이다') and date annotations that could be trimmed.

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 shape — and it does, naming ground_not_applicable, grounds_excluded_by_contract_kind, day_count_rules_excluded, verification, general_conditions_article_ref, general_conditions_in_corpus, admin_rule_version_in_corpus, and quote_truncated. For a 2-parameter guide tool whose value is in its structured output, nothing an agent needs to interpret the response is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning and it largely does: contract_kind is tied to estimate_delay_penalty's value and mapped to the general-conditions series, with a warning that the contractually incorporated general conditions are the true source; ground is described as single-reason detail, omitted meaning the full list. It does not individually explain all 6 contract_kind or 10 ground enum values, only illustrative ones (sw_requirement_change), so it compensates well but not exhaustively.

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 resource and scope: it is a guide (지도) to reasons for excluding (불산입) delay days, and explicitly names the boundary — 'the part estimate_delay_penalty does not determine.' It also names the sibling it complements and the specific question types it answers (force-majeure-like excuses, winter suspension, late government-supplied materials), so an agent can distinguish it from estimate_delay_penalty 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?

It gives an explicit workflow ('narrow reasons with this tool → confirm must_establish with the user → feed excluded_days into estimate_delay_penalty and recalculate') and an explicit when-NOT clause: '이 도구는 해당 여부를 판정하지 않는다' — judgment belongs to the ordering agency. It also names an alternative for full-text recovery (search_references) and get_law_article for article retrieval. Nothing about when to pick this vs siblings is left to inference.

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?

Beyond the readOnly/idempotent hints, the description discloses response-field semantics (notes = unmaintained cross-references, assumption = system-estimated law name, kind = 'table'/'admin_rule'), 404 error semantics (law_in_corpus true means the corpus has the norm but not that article number), and the policy that the original text is returned as-is from law.go.kr ('우리가 고치지 않는다'). It also documents currency statuses (verified/unverified/stale/unmonitored) and instructs agents not to assert delegated numbers from the article alone — all context the annotations 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 core function is front-loaded in the first sentence and every paragraph is keyed to a trigger condition, making the long text scannable. It is not maximally tight, though: the implementing_note and delegation_note paragraphs repeat the same 'why numbers are missing from the text' explanation, and the dated parentheticals are maintenance noise 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?

With no output schema and high domain complexity (two corpora, delegation chains, tables, admin rules, currency freshness), the description documents every significant response field and edge case an agent needs: notes, assumption.hint, implementing_articles, delegations[].how, in_corpus, kind, related_article, cites, law_currency, note_currency, last_verified_at, and the corpus_laws/corpus_admin_rules inventory. An agent can retrieve, interpret, and cite correctly from this text alone.

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 the full burden and meets it: the Args block defines ref as an exact article reference ('국가계약법 시행령 제26조'), an attached-table reference ('국가계약법 시행규칙 [별표 2]'), or an admin-rule reference ('(계약예규) 용역계약일반조건 제18조'), each with a concrete example. It further explains how refs generated by search_law and search_references map directly into the parameter.

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 (retrieve) and resource (the full original text of a statute article), and the body extends the scope to attached tables and administrative rules. It implicitly distinguishes from the search siblings by repeatedly positioning this tool as the reader of refs produced by search_law and search_references, but it never positions itself against the closest sibling 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?

Rich when-to-use context is explicit: follow implementing_note refs through this tool ('거기 적힌 ref를 그대로 get_law_article에 넣어'), accept table refs from search_law and admin-rule refs from search_references, and read the delegated norm first when delegation_note is present. It also states a when-not: when in_corpus is false, do not claim 'no regulation' but direct the user to law.go.kr. The gap is that the alternative for time-specific retrieval (get_law_article_asof) is never mentioned.

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?

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 cover readOnly/openWorld/idempotent, and the description adds extensive context beyond them: real-time always-current semantics, response structure (search_scope, searched, retried, total_cnt), the crucial 0-results interpretation rule ('이 범위에서 못 찾았다' not '없다'), axis boundary semantics (yegyu_in_corpus vs prec_in_corpus), off_topic_warning with axis_verdict.axis values, unseen_cnt/truncated/ledger_total, and axis_unjudged fallback. No contradiction with annotations — the description fully honors readOnly (search) and openWorld (0 results = not found in scope) hints.

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?

Information-dense with purpose front-loaded and every sentence earning its place — no fluff. The dated changelog headers (2026-08-29, 2026-09-02, etc.) are structurally unusual and read like internal dev notes rather than user-facing docs, adding clutter an agent doesn't need to call the tool correctly. The logical organization (purpose → usage → response semantics → parameters) is sound, but the dated scaffolding costs it a 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?

For a tool with 3 params, no output schema, and complex response semantics (axis boundaries, off_topic warnings, unseen counts), the description is remarkably complete. It covers what it does, when to use it, all parameter constraints, response field semantics, edge-case interpretation rules, and the follow-up tool. With no output schema present, the description rightly carries the full burden of return-value explanation, and it does so thoroughly — 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 coverage is 0%, and the description fully compensates. query: explains keyword-based, 2-100 char constraint with specific error names (query_too_short/query_too_long), natural language acceptance, and auto-retry up to 2 times. top_k: documents default 5, allowed 1-10, clamping behavior for out-of-range values (0/negative→1, >10→10), and the top_k_applied disclosure field. kind: explains each enum value ('prec'(법원 판례), 'expc'(법제처 법령해석례), 'all'). This is comprehensive compensation for zero schema coverage.

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?

Opening states a specific verb+resource: '판례·법령해석례 검색 — law.go.kr 실시간 조회(항상 현행)'. It names the follow-up tool get_case(kind, case_id) for full text, distinguishing this search tool from the retrieval tool. The scope (precedents + legal interpretations from law.go.kr, always current) is unmistakable and separates it from siblings like search_law 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?

Explicit when-to-use: '분쟁·처소취소·해석 다툼("~해도 되나", "~취소될 수 있나")에 조문만으로 부족할 때 쓰라' — clear triggering conditions. It also names get_case as the follow-up for full text. However, it doesn't explicitly name search_law or search_references as alternatives to route away from; the contrast with search_law is implied ('조문만으로 부족할 때') rather than stated. A small gap in exclusion guidance keeps this from 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?

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint:false, but the description adds substantial behavioral context beyond that: the dual-corpus axis determination, meaning of fields like note_corpus, truncated, complete, total_found_is_lower_bound, degraded, and note_currency, plus the warning about no_corpus_match not meaning absence. It also explains the clamping behavior of top_k. No contradiction with annotations; this is a rich disclosure of the tool's operational 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?

The description is long, but each section addresses a distinct operational aspect (corpus behavior, field semantics, error handling, currency checks). It is front-loaded with the core purpose and then layers edge cases. While it could be trimmed slightly, the density of essential information justifies the length. The structure uses bolded warnings and section breaks, aiding readability. It is appropriately sized for 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?

Given the tool's complexity (dual corpus, many result fields, error cases, no output schema), the description is remarkably complete. It covers the meaning of total_found vs count, truncated, complete, total_found_is_lower_bound, search_scope/searched, degraded, note_currency, implementing_articles, delegated, related_article, and the no_corpus_match error. It also explains how to handle table hits and the corpus flag in responses. An agent has all the information needed to call and 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?

The input schema has 0% description coverage, so the description carries the full burden for parameter meaning. It does so thoroughly: `query` is illustrated with concrete examples ('수의계약', '시행령 제26조', '제21조', '소득세법 제55조'); `top_k` is explained with default, allowed range (1–20), and clamping behavior (0·음수→1, 20 초과→20) plus the disclosure in `top_k_applied`; `corpus` is documented with its two values ('contract'|'tax') and the auto-selection fallback. This fully compensates 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?

The description opens with a clear statement of the tool's function: '법령 조문 검색 — 키워드 또는 조문번호로 조문 스니펫 반환(상위 top_k건)' — a specific verb (검색), resource (법령 조문), and output (snippets). It further distinguishes itself from the sibling get_law_article by noting '전문이 필요하면 get_law_article(ref)로 이어서 조회', making the separation explicit. An agent can immediately understand what this tool does and how it differs from related 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 provides explicit when-to-use guidance: it explains the dual-corpus behavior and when to force corpus via the `corpus` parameter, and it explicitly routes to get_law_article for full text. It also states when not to cite results (e.g., 'hit에 note가 있으면 삭제·폐지된 조문이다 — 판단 근거로 인용하지 마라') and warns against re-searching when implementing_articles are present. This is thorough, actionable guidance for both selection and invocation.

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 annotations already declare readOnly, openWorld, idempotent, and non-destructive, but the description adds substantial behavior beyond them: no LLM generation, no backend LLM budget usage, matched_section semantics, as_of and superseded_risk, off_topic detection, and top_k clamping behavior. It explains exactly how returned fields should and should not be interpreted. 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?

The description is long and dense, and each section adds operational context that prevents a user from drawing false legal conclusions. It is front-loaded with purpose and sibling differentiation, though the date-stamped warnings and multiple caveats make it heavier than a minimal-purpose description. Overall the length is justified, but it is not maximally concise.

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 semantics itself, and it does: it covers hit-level fields, query expansion behavior, as_of and vintage semantics, superseded_risk, off_topic handling, and parameter coercion. Given the tool’s complexity, an agent has what it needs to invoke it correctly and interpret results 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?

Schema description coverage is 0%, so the description carries the full burden for the parameter semantics. It provides a query example and precisely documents top_k defaults, allowed range, clamping rules, and the top_k_applied response disclosure. This greatly exceeds the bare schema and fully compensates for the missing schema 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?

The description opens with a specific verb and resource: it is a public-contract corpus search across laws, contract rules, detailed standards, and practical guides. It explicitly differentiates from search_law, and names concrete use cases like '낙찰하한율·적격심사 배점·실무 절차', so an agent can recognize when this tool is the right one.

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 clear when-to-use and when-not-to-use guidance: use this for questions outside statutory text, and route tax-law questions to search_law or get_law_article instead. It also warns against treating zero hits as evidence of absence in tax law and instructs when to escalate to report_issue, making the boundary between siblings explicit.

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