contract-compass

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true. The description goes further: it reveals that missing adjustment_rate_pct leads to met:null and deliberation (not fabrication), that org_type must not be guessed because thresholds differ (15% vs 10%), and it explains the verdict enums including exception_path. All consistent with the annotations, adding depth beyond them.

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 intentionally structured: bolded key concepts, a clear verdict list, and a parameter-by-parameter breakdown. Every sentence carries useful information—no filler. The length is justified given 12 parameters and the domain 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 fully covers return values (verdict categories) and all decision rules: period requirement, 3% threshold, single-item threshold, method selection default, and adjustment amount formula including advance-payment deduction. An agent can operate this tool without external domain knowledge.

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%, yet the description manually explains every parameter: format (YYYY-MM-DD, decimals), defaults, special rules (e.g., long-term contracts use first contract date, negative rates for decreases), and constraints (single_item_share_over_5permille must be verified from bill of quantities, not calculated). This fully compensates for the bare JSON 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: '물가변동 계약금액 조정(에스컬레이션) 요건 판정 + 산식 적용' (judge price adjustment requirements + apply formula), and scopes it to Phase 3. It clearly distinguishes this tool from siblings like estimate_delay_penalty by focusing on escalation/adjustment, not delays or contract method decisions.

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 concrete usage examples ('자재값이 올랐는데 계약금액을 올려받을 수 있나'), and explicitly warns '이 도구는 조정률을 산정하지 못한다' (cannot compute the adjustment rate), telling the agent to accept user-provided rates and set requirements to undetermined if absent. This is strong when-to-use and when-not-to-use guidance, even without naming a sibling tool.

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 read-only, idempotent, open-world, and non-destructive. The description adds significant behavioral context beyond annotations, including warnings about missing enterprise flags causing negotiation candidates to be omitted, the nuance that national/public corp small-amount contracts require specific requirements, and the additional social enterprise condition. This transparently discloses consequences of input choices.

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 an intro and an Args block. Every sentence adds value, though the length is substantial. It is not overly repetitive, but could be slightly more front-loaded; the most critical parameter warnings are placed later.

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 13 parameters and no output schema, the description is quite complete. It covers all parameter semantics, legal bases, and critical caveats. However, it does not describe the return format beyond 'candidates and legal basis' or address error conditions (e.g., what happens with invalid combinations), which keeps it from a 5.

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

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

Schema description coverage is 0%, so the description carries the full burden. It explains every parameter in detail, including enum values, conditional relevance, and legal references. For example, is_small_enterprise is explained with the exact regulation clauses and the caveat about national/public corp thresholds. This far exceeds baseline.

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: '계약방법 결정론 판정 — 룰엔진이 적용 가능한 계약방법 후보와 법령 근거를 반환' (contract method determination rule — returns applicable candidates and legal basis). This is a specific verb+resource that distinguishes it from sibling tools like legal case/law 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 clear context for when to use certain flags and parameters, e.g., explaining that is_women_enterprise is needed for specific local government contract thresholds and that missing enterprise flags will cause negotiation candidates to be omitted. However, it does not explicitly contrast this tool with sibling alternatives or state when not to use it, so a 4 is given.

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 read-only and non-destructive behavior, but the description adds critical context: the tool does not make determinations (the contracting agency's judgment), it returns must_establish facts and precedents, and it warns about truncated quotes (quote_truncated). It also cautions against fabricating continuations, which is valuable behavioral disclosure.

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

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

The description is dense but every section earns its place: purpose, example questions, non-determination caveat, three outputs, usage order, special rule, warning, and args. It uses bold headers and clear lists, making it easy to scan despite its 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 thoroughly explains what the tool returns (list of reasons with citations, must_establish facts, precedents) and how to use the results. It also connects to sibling tools and warns about truncated quotes, making the tool's behavior and integration 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?

The schema has 0% description coverage, but the Args section fully explains both parameters: contract_kind is aligned with estimate_delay_penalty and maps to general conditions with a warning that actual incorporated terms are authoritative; ground is optional and filters to a specific reason, otherwise a full list is returned. This 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 clearly states the tool's function as a guide for reasons excluded from delay days, and explicitly distinguishes it from sibling estimate_delay_penalty by noting it covers the part that 'estimate_delay_penalty가 정하지 않는 부분'. It gives specific example questions, making the scope concrete.

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 usage context with example questions and a sequential workflow: narrow reasons with this tool → confirm must_establish → feed excluded_days into estimate_delay_penalty. It also includes a special rule for sw_requirement_change and a warning about quote_truncated items, guiding proper usage.

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 readOnlyHint and idempotentHint annotations, the description discloses that delay_days and excluded_days are used as user-declared values without verification, and that responses include a disclaimer. It also explains that rates may be inferred (as our interpretation) and warnings highlight undeclared items. This adds rich behavioral context without contradicting any annotation.

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 exceptionally well-structured with clear sections (purpose, key caveats, response fields, args). Every sentence adds value—no fluff or repetition. It front-loads the most critical information (rate differences, org_type confirmation) and maintains readability despite its density.

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 having no output schema, the description comprehensively lists response fields and their meanings, explains the calculation logic (base amount, 30% cap, accepted portion), and includes pointers to related tools. The description covers all necessary context for an agent to correctly invoke the tool and interpret results, making it complete for a complex calculation 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?

With 0% schema description coverage, the description compensates fully by explaining all 7 parameters in the Args section. It provides detailed semantics, including contract kind enum values, rate differences between national and local, special notes for long-term contracts, and the requirement to confirm org_type. Each parameter is given practical meaning beyond the schema's bare types.

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 calculates delay penalties for national/public and local entities, applying statutory rates, base amount, and a 30% cap. It explicitly differentiates between national and local terminology and rates, and references sibling tools (search_references, get_law_article) for specific subtasks. The purpose is unambiguous and well-distinguished.

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

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

The description explicitly states that this tool does not determine delay days or excuse applicability, directing users to search_references for such fact-based issues. It instructs to always confirm org_type with the user to avoid incorrect rates, and mentions get_law_article for verifying legal basis. This provides clear when-to-use and when-not-to-use 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 read-only, idempotent, and non-destructive behavior, so the bar is lowered. The description adds valuable context: the response includes a source_url from the National Law Information Center, and instructs to present this link when citing, which is a behavioral expectation beyond the annotations. It also clarifies the response components, but 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 efficiently organized: a one-sentence purpose, a highlighted citation instruction, and a compact args list. It avoids fluff and gets to the essential points, though the args list could have been formatted more compactly.

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 read-only lookup with two parameters, the description covers the essential aspects: the source of parameters, the content of the response, and the special need to include source_url in citations. No output schema exists, but the description provides enough detail for an agent to correctly invoke the tool and handle the result.

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

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

Schema coverage is 0%, so the description must define the parameters. It does so by stating kind accepts 'prec' or 'expc' and that both values should be taken directly from search_cases results. This gives provenance and avoids ambiguity. It doesn't spell out what each enum value stands for, but the opening line makes the distinction between cases and interpretations, and since the values are passed through from search_cases, this is sufficient.

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 full text for cases (prec) and interpretations (expc), enumerating the included components (e.g., 판시사항, 판결요지, 참조조문). It differentiates from sibling search_cases by being the detail lookup after a search, and mentions the source_url for citation, making the purpose unmistakable.

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

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

The description explicitly notes that kind and case_id come from search_cases results, telling the agent this tool is to be used after a search to fetch the full text. It also instructs to include the source_url when citing, providing additional usage guidance. It doesn't explicitly exclude other uses, but the context is clear enough for a straightforward retrieval tool.

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 discloses important behavioral traits beyond the annotations: it explains that non-empty `notes` indicates detected legal self-inconsistencies, that `assumption` indicates an inferred law name, and that the text is not corrected from law.go.kr. These details are not implied by the read-only and idempotent annotations and add significant transparency.

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

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

The description is well-structured: a one-line purpose statement followed by two clearly labeled paragraphs explaining the `notes` and `assumption` behaviors. Every sentence adds essential value without redundancy, and the formatting improves skimmability.

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?

Since there is no output schema, the description covers the non-obvious response fields (`notes` and `assumption`) that are critical for interpreting results. It does not fully enumerate the entire response structure, but the primary content (full article text) is clearly stated, and the special cases are adequately handled.

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 parameter `ref` has no schema description, so the description compensates by specifying it should be an exact article reference and provides a concrete example ('국가계약법 시행령 제26조'). This adds meaningful semantic information 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's function: '법령 조문 원문 전체 조회' (retrieve full original text of a law article), which is a specific verb and resource. However, it does not explicitly differentiate from sibling tools like get_law_article_asof, so it lacks sibling discrimination.

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 context for use: retrieve a specific article by reference. It also provides handling instructions for special response fields (notes, assumption), including when to re-call with a different law name. It does not explicitly mention alternatives or when-not to use, but the situational guidance is strong.

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 read-only, idempotent, non-destructive. The description adds context about the historical data source (law.go.kr 연혁 라이브) and response fields (effective_date, is_current, prev/next_effective_date), enhancing transparency without contradicting 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 well-structured: bold emphasis on the core purpose, concise use-case examples, listed response fields, and clear parameter descriptions. Every sentence adds value and it is front-loaded with the most critical information.

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 explains response fields adequately. With two parameters and clear usage examples, it is mostly complete, though it could mention error handling for invalid ref or date.

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 0% schema description coverage, the description provides example values for ref ('국가계약법 제27조') and date format ('YYYY-MM-DD' or 'YYYYMMDD'), but does not fully specify allowed formats or validation rules, so it partially compensates but leaves gaps.

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 it retrieves the original text of an article in effect at a specific time ('특정 시점에 시행 중이던 조문 원문 조회') and contrasts with get_law_article which always returns current version, clearly specifying the verb and resource and distinguishing from sibling.

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

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

It explicitly warns that using get_law_article for past events silently yields wrong answers ('과거 사건에 현행 조문을 적용하면 조용히 틀린 답이 된다') and lists specific scenarios (계약 체결, 입찰공고, 처분 시점) where this tool must be used, providing both when-to and when-not-to 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?

The description adds behavioral context beyond empty annotations: it states the report is forwarded to operators and the server auto-attaches previous tool call history. It does not mention rate limits or response details, but provides useful information for a non-destructive reporting action.

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 (about 10 lines) and front-loads the purpose and key usage guideline. The parameter list is well-organized and easy to parse. Every 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?

The description covers purpose, usage, parameters, and behavioral notes (server auto-attach). It lacks details on the output/response after reporting, but for a reporting tool this is adequate given the absence of an 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?

With 0% schema description coverage, the description fully explains each parameter: lists enum values with Korean translations, advises what to include in 'message', and provides examples for 'related_tool' and 'related_query'. This adds significant 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 description clearly states the tool is for reporting errors and improvements to operators, with a specific verb ('제보하다' - report) and resource ('오류·개선' - error/improvement). It is distinct from sibling tools which are for searching and retrieving legal information.

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 instructs when to use: first report when the user points out a mistake, and also when tool results clearly disagree with known provisions or numbers. It provides clear context and no ambiguity.

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, etc. The description adds valuable behavioral context: it is real-time ('항상 현행'), does not use LLM ('LLM 미사용'), and the data source is law.go.kr. No contradictions 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 efficiently structured: a concise headline defining the tool, a usage context paragraph, and a clean parameter list. It is front-loaded with key info. Minor verbosity in parameter examples but overall well-organized 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?

While usage guidelines and parameter semantics are strong, the description lacks information about the return format of search results. No output schema exists, so the agent must infer what fields are returned. The mention of using get_case for full text partially compensates, but more detail on search result structure would improve 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 bears full burden. It comprehensively explains all three parameters: query (핵심 명사 위주 검색어 with examples), top_k (setzen per kind, default 5, max 10), and kind (enum values with Korean labels). This adds significant meaning beyond the 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 it searches '판례·법령해석례' (case law and statutory interpretation examples) from law.go.kr in real-time. It specifies when to use (when disputes or interpretation questions arise and law articles are insufficient) and how to follow up with get_case. This distinguishes it 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 explicitly instructs when to use this tool ('분쟁·처분취소·해석 다툼에 조문만으로 부족할 때') and directs the agent to use get_case for full text retrieval. It does not explicitly state when not to use it, but the context makes it clear.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, and the description adds critical context beyond them: the meaning of the 'note' field (deleted/repealed law) with an explicit instruction not to cite such hits, and the nuanced handling of the 'no_corpus_match' error, warning against assuming a law doesn't exist just because it's outside the corpus.

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?

Dense but efficient: each sentence serves a distinct purpose. The structure flows from purpose → follow-up → critical safety notes → error handling → Args. The bold formatting of critical negative instructions ('그런 규정이 없다는 뜻이 아니므로') highlights the most important caveat, and nothing feels redundant or padded.

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 search tool with only 2 simple parameters and no output schema, the description covers all essential aspects: return scope (snippets), count (top_k), note semantics, error handling, and cross-referencing for full text. It even addresses the compliance/safety-critical scenario of citing repealed provisions, which is comprehensive for a legal domain 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?

With schema description coverage at 0%, the Args section does the heavy lifting and fully compensates: it documents query with concrete examples ('수의계약', '시행령 제26조', '제21조') and specifies top_k's default (8) and maximum (20) — details not present in the schema. This matches the description's burden given low 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 first sentence uses a specific verb (검색/반환) with a clear resource (법령 조문) and scope (키워드 또는 조문번호, top_k건). It clearly distinguishes itself from siblings like get_law_article (full text retrieval) and get_law_article_asof, which are explicitly named as follow-ups.

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 instructs when to switch to get_law_article(ref) if full text is needed, names this alternative directly, and specifies the exact error condition ('no_corpus_match') that should trigger a different response. Also provides guidance on how to handle deleted statutes rather than citing them, giving the agent clear decision 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 already declare readOnly, openWorld, idempotent, non-destructive behavior. The description adds valuable context: no LLM usage, returns only original text, and does not consume backend LLM budget. This goes 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 extremely concise, with no redundant sentences. It front-loads the core purpose and uses bullet-style formatting for clarity. Every 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 the complexity of a multi-source search tool and no output schema, the description covers scope, usage, and return type (original text only). It lacks details on ordering or pagination, but overall complete for agent understanding.

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 burden. It provides an example query for 'query' and specifies 'top_k' maximum of 12 (not in schema), adding meaning. However, no detailed format or constraints beyond that.

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 performs a full corpus search across laws, contracts, guidelines, etc., distinguishing it from the sibling tool 'search_law' which is limited to law articles. The verb 'search' and specific scope are well-defined.

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 advises when to use this tool (questions about procedures, lowest winning bid ratio, etc., outside law text) and contrasts with 'search_law'. It also states that it does not use LLM, providing clear guidance.

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