contract-compass

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

Annotations declare readOnly/openWorld/idempotent/non-destructive, but the description adds crucial behavioral depth: it is deterministic, cannot calculate adjustment rates, sets 'met: null' if the rate is absent, and reveals default decision rules (e.g., item method unless index specified). It includes explicit 'do not fabricate' and 'no guessing' instructions, going well beyond annotation 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?

Although long, the description is well-structured: a bold limitation up front, a numbered list of deterministic checks, and bulleted parameter explanations. Every sentence conveys essential domain knowledge or an operational rule; there is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's high complexity (12 parameters, multiple thresholds, conditional verdicts) and the absence of an output schema, the description thoroughly covers decision rules, verdict enum, missing-rate behavior, and exceptional paths. It is fully self-sufficient for an agent to decide when to invoke the tool and how to interpret its response.

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 covers 0% of parameter meaning, but the description provides rich semantics for all 12 parameters. It adds critical constraints like org_type not being guessable, long-term contract date special rule, negative adjustment_rate_pct for decreases, and the server's inability to verify single_item_share_over_5permille. This fully compensates 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?

The description immediately states the tool performs '물가변동 계약금액 조정(에스컬레이션) 요건 판정 + 산식 적용' and enumerates five specific deterministic checks and response verdicts. This precise verb+resource+scope clearly distinguishes it from siblings like delay-exemption or law-search 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?

It explicitly frames when to use the tool with example user questions and identifies the contract lifecycle phase ('이행단계 Phase 3'). It also warns against using it when the adjustment rate is unknown, telling users to supply the rate or expect an 'undetermined' verdict. It does not explicitly name alternative sibling tools, so a small deduction.

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 adds significant behavioral context beyond the annotations (readOnlyHint, idempotentHint, etc.). It explicitly warns about the consequence of missing required flags: '[빠뜨리면] 수의계약 후보가 통째로 빠지고 경쟁입찰만 제시된다' (if omitted, negotiated-contract candidates are entirely dropped and only competitive bidding is offered). It also clarifies nuanced rules like '국가·공기업 2천만원 초과~1억원 이하는 무조건 소액수의가 아니다' (national/public corp over 20M~100M won is not automatically small-amount negotiation), which are behavioral disclosures beyond what structured fields 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 intentionally lengthy due to the tool's complexity (13 parameters), but it remains structured and front-loaded with a clear purpose sentence. Each parameter explanation serves a purpose, and the critical warnings (e.g., for is_small_enterprise) are placed within the relevant parameter line. However, the length is at the upper edge of conciseness; a few sentences could be trimmed if legal citations were abbreviated, but overall every sentence earns its place.

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 highly complete for input parameters, providing extensive context for each flag and their legal basis. It also states the high-level output (candidates and legal basis). However, it does not describe the output format or structure (e.g., whether it returns a list of objects with reason codes), which would be useful given there is no output schema. The description also does not explicitly mention the openWorldHint or that the tool may infer missing flags, but the annotations cover that. Overall, the description is thorough for the given complexity.

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?

With schema_description_coverage at 0%, the description carries the full burden of explaining parameters. It provides detailed meaning and legal context for 12 of 13 parameters, including enum values, conditions, and special cases. For example, it explains that is_women_enterprise is needed specifically for local government product/service contracts between 20M and 100M won, and that is_social_enterprise requires an additional administrative rule (행정안전부 고시 취약계층 고용비율 충족). It even documents parameters absent from the schema description (e.g., is_small_enterprise) with legal references. Only project_name is not elaborated, but it is a trivial default 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 description clearly states the tool's purpose: '계약방법 결정론 판정 — 룰엔진이 적용 가능한 계약방법 후보와 법령 근거를 반환' (Determines contract method and returns applicable candidates and legal basis). It uses a specific verb ('판정' = decide) and resource ('계약방법' = contract method), and clearly distinguishes itself from sibling tools like search_law or get_law_article by being a decision/analysis tool rather than a retrieval tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (when contract type, estimated price, and relevant flags are known) but does not explicitly state when not to use it or mention alternatives. The extensive parameter guidance (e.g., '2천만원 초과 1억원 이하 수의계약 판정에 필요') provides contextual usage hints for specific flags, but there is no direct 'use this vs. use that' guidance relative to 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?

Beyond the readOnly/idempotent annotations, the description discloses significant behavioral traits: it does not determine eligibility ('해당 여부를 판정하지 않는다'), requires user-confirmed facts (must_establish), returns three distinct outputs, handles sw_requirement_change as half credit, and truncates quotes when quote_truncated is true. 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?

The description is long but every sentence earns its place: purpose, usage, workflow, caveats, parameter semantics, and warning are all tightly packed. The bolded lead and structured flow with numbered items make it scannable despite 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?

For a complex advisory tool with no output schema, the description fully covers what it returns (three items), how to use it in sequence, what must be established, and a critical failure mode (truncated citations). It also integrates with sibling tools and warns against hallucination, making it complete for an agent.

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 parameter burden. It explains contract_kind as the same value expected by estimate_delay_penalty, mapping to general conditions and warning that the actually incorporated terms are ground truth. It also clarifies ground as an optional filter and the meaning of omission ('생략하면 그 계약유형의 전체 목록'), adding meaning the enum schema alone does not provide.

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 purpose: '지체일수에서 빼는(불산입) 사유 지도' and explicitly distinguishes itself from estimate_delay_penalty ('estimate_delay_penalty가 정하지 않는 부분'). It clearly identifies the resource (delay-day exemption reasons) and the action (guide/narrow down), making its role distinct 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 gives concrete use cases in question form ('동절기 공사중지 기간도 지체일수인가'), a step-by-step workflow ('쓰는 순서'), and explicitly references alternative tools: use search_references for truncated quotes and feed excluded_days into estimate_delay_penalty. It also warns when not to rely on truncated items, providing excellent 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?

Beyond the readOnly/idempotent annotations, the description discloses that delay_days/excluded_days are used as declared (not independently verified), that counted_days.disclaimer reveals this, and that rate.inferred indicates non-statutory interpretation. It also explains deterministic application and warnings behavior, adding significant transparency not available from annotations alone.

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 lengthy, the description is tightly structured with bold warnings, a response-field list, and an Args block; each section conveys non-obvious, necessary legal and usage detail. It front-loads purpose and priority caveats before parameter definitions, so every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully enumerates response fields (term, rate, base_amount, counted_days, amount_raw/cap/amount, warnings, legal_basis) and their meaning. Given the tool's legal complexity and 7 params, this makes the description self-sufficient 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%, but the description compensates fully by explaining every parameter, including enum meanings, critical caveats (e.g., contract_amount for long-term continuing contracts, delay_days including excluded days), and defaults. This exceeds the bare schema by providing domain-specific 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?

The description opens with a specific verb+resource: '지체상금(국가·공기업)·지연배상금(지방) 산정' and clearly delineates the calculation scope (legal rates, base amount, 30% cap). It distinguishes from siblings by pointing users to search_references for excuse determinations and to get_law_article for statutory text, so the tool's unique role is unambiguous.

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 provides explicit when-to-use/when-not-to-use guidance: '이 도구는 지체일수를 정하지 않는다' and directs users to search_references when excuse applicability is the issue. It also mandates confirming org_type with the user ('org_type을 반드시 사용자에게 확인해서 넣어라'), which is actionable usage 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 declare the operation as read-only and idempotent. The description adds valuable behavioral context by disclosing that the response includes a `source_url` pointing to the original National Law Information Center document and instructs to present this link when citing, supporting traceability.

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 well-structured with a concise purpose line, an important output-tracking note, and an Args section. Every sentence earns its place with no redundancy or filler.

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 two parameters and no output schema, the description covers purpose, input provenance, and the key output field (source_url). It could detail the full response structure, but the current information is sufficient for correct invocation and downstream use.

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

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

Schema description coverage is 0%, but the description compensates by explaining that `kind` accepts 'prec' or 'expc' and that both parameters are derived from search_cases results. This adds relational meaning 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 clearly states the tool retrieves the full text of precedents/interpretations ('판례/해석례 본문 조회') and enumerates specific content sections (판시사항, 판결요지, 참조조문 or 질의요지, 회답, 이유). This specificity distinguishes it from sibling tools like get_law_article and search_cases.

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 specifies that `kind` and `case_id` come from `search_cases` results, implying a search-then-retrieve workflow. It does not explicitly name alternatives or when-not-to-use, but the parameter provenance gives clear contextual 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?

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses important behaviors: it returns unmodified current text from law.go.kr, notes field indicates a cross-reference defect in the law itself, and assumption field means the law name was guessed. It also tells the agent how to act on these signals, adding significant context 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 front-loaded with a clear one-sentence purpose, then uses structured paragraphs and inline emphasis to explain the special response fields (notes, assumption) and their handling. Every sentence adds value, and the length is justified by the complexity of the tool's behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully covers the meaningful return contexts: the main content (full original text), the notes field, and the assumption field, including how to proceed in each case. It also clarifies the current-version nature of the text. This is complete for an AI agent to use the 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 schema only says 'Ref' with no description, and schema coverage is 0%. The description compensates by defining ref as '정확한 조문 참조' (exact article reference) and providing a concrete example: '국가계약법 시행령 제26조'. This adds meaningful guidance for a single-parameter tool, though it could be even more detailed about formatting variations.

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 '법령 조문 원문 전체 조회' (retrieve the full original text of a statute article), which is a specific verb plus resource. It further differentiates itself from sibling tools by noting the returned text is 'law.go.kr 현행 그대로' (current as-is), implicitly distinguishing 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?

The description provides clear context on how to handle responses: if notes are non-empty, the agent should inform the user and avoid assertions; if assumption exists, the agent should re-call with the correct law name per assumption.hint and disclose the law to the user. However, it does not explicitly contrast with alternatives like get_law_article_asof or search_law, 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds valuable behavioral context: it returns historical versions with effective_date, is_current, prev/next_effective_date, and warns about unmanaged cross-references. This enriches transparency beyond 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 moderately long but well-structured: purpose, contrast, usage examples, response fields, and args. Uses bold for emphasis. Every sentence adds value; no wasted words.

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 simplicity (2 required parameters, no output schema), the description covers all necessary aspects: what it does, when to use it, how parameters work, and what the response contains. No gaps identified.

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 has 0% description coverage for parameters, but the description's 'Args' section explains both 'ref' (with examples like '국가계약법 제27조') and 'date' (with format YYYY-MM-DD or YYYYMMDD). This sufficiently compensates for the schema deficiency.

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 retrieves the original text of a law article as of a specific date (historical version). It explicitly contrasts with sibling 'get_law_article' (which returns current version), making the purpose unambiguous and well-differentiated.

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 usage guidelines: 'must use this tool' for past events like contracts, bids, audits, and disputes. It also provides concrete examples of when using the current version would be incorrect, establishing clear when-to-use and when-not-to-use criteria.

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 are neutral (no readOnly/destructive hints), but description adds that the report goes to an operator pipeline and server attaches previous call logs, providing useful context beyond 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?

Well-structured with a clear header, usage rules, and parameter list. Slightly longer than necessary but each sentence adds value.

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 no output schema, the description adequately covers purpose, usage, parameters, and behavioral notes. It doesn't explain return values but that's acceptable for a reporting 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?

The description provides detailed explanations for all 5 parameters in the Args section, including enum values for category, and guidance for message, which the schema lacks entirely (0% 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?

The Korean title and description clearly state it's for reporting errors/improvements to operators, with specific examples. It's distinct from sibling tools which are for searching or retrieving legal info.

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 instructions: use when user points out an error or when tool results conflict with statutes; first report then correct; do not use for guesses. Also notes server auto-attaches logs, reducing agent burden.

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 indicate readOnly, idempotent, non-destructive behavior. The description adds valuable context: real-time query from law.go.kr, always current, no LLM used. 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?

The description is concise: two short sentences plus a bullet list of parameters. It front-loads the purpose and use case, and every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters, no output schema, but comprehensive annotations, the description provides complete guidance: what the tool searches, when to use, parameter details, and next step (get_case). No gaps remain for effective usage.

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?

Although schema descriptions are empty (0% coverage), the tool description itself explains each parameter: query as keyword-focused search term, top_k as result count per kind (default 5, max 10), kind as enum with options and default 'all'. This fully compensates for 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 clearly states it searches court precedents and legal interpretation cases from law.go.kr in real-time. It specifies the use case (when statutes are insufficient for disputes, cancellations, etc.) and distinguishes from sibling tools like get_case and 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?

The description provides explicit when-to-use guidance: for disputes or interpretations where statutes alone are inadequate. It also directs users to get_case for full text after finding a case. However, it does not explicitly state when not to use this tool or mention alternatives beyond 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?

While annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, the description adds crucial behavioral context: it returns only snippets (not full text), hits may carry notes indicating deletion/abolishment (which should not be cited), and the no_corpus_match error means the query is outside the corpus, not that the regulation doesn't exist. This goes beyond annotations and is essential for correct tool use.

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 front-loaded with the core purpose, then flows into usage alternatives, special-case warnings, and parameter explanations. Each sentence adds critical information without redundancy. It's dense but efficient, with no fluff.

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 covers return type (snippets), special conditions (deleted clauses via 'note'), and error handling (no_corpus_match guidance). Combined with the tool's moderate complexity and the clear parameter documentation, the description is complete for an agent to select and invoke the 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 schema describes only types and defaults; the description provides meaningful semantics: query is exemplified as '수의계약', '시행령 제26조', '제21조' etc., clarifying allowed formats, and top_k is defined as '반환 건수 (기본 8, 최대 20)' (return count with default and max). This fully compensates for the 0% 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?

The description clearly states the tool's function: '법령 조문 검색 — 키워드 또는 조문번호로 조문 스니펫 반환' (search statute clauses by keyword or clause number, returning snippets). It distinguishes itself from sibling tools by explicitly naming get_law_article for full-text retrieval, and the context signals show siblings like get_law_article_asof, making this tool specific to snippet-level search.

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: '전문이 필요하면 get_law_article(ref)로 이어서 조회' (use get_law_article for full text) and special handling instructions for hits with notes (deleted/abolished clauses) and for no_corpus_match errors. It also states what not to do ('그렇게 답하지 말고') and directs users to corpus_laws and law.go.kr, offering clear usage boundaries.

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. Description adds that no LLM is used and only source text is returned, including backend budget implications. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-organized: header, purpose, usage, args. Front-loaded with key info. Slightly verbose but each sentence adds value. Could be a bit more terse.

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?

Covers scope, differentiation from sibling, output nature (source text only), and key constraints. No output schema, but description adequately sets expectations. Could mention return structure.

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% so description must compensate. Provides example for query and notes default and max for top_k. But lacks detailed format or operators for query. Some value added but incomplete.

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 it searches across multiple reference types (laws, contracts, standards) and explicitly contrasts with search_law. Uses specific verb+resource (integrated search of corpus) and distinguishes from sibling tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises when to use: for questions outside law text (e.g., bid rates, evaluation scores). Contrasts with search_law. Provides example query. Could explicitly state when not to use, but the contrast implies it.

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