contract-compass

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

Annotations indicate read-only, idempotent, and non-destructive behavior. The description adds that it returns candidates and legal basis, but does not disclose additional behavioral traits beyond what annotations provide. No contradiction.

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 purpose and includes an Args block. It is mostly concise but the parameter list is lengthy; minor room for structural improvement.

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 (8 parameters, no output schema), the description covers all parameters with examples and explains the return value. It is complete for the tool's purpose.

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 tool description lists all 8 parameters with Korean meanings and enum hints, significantly compensating. It adds full semantic value for each parameter 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's purpose: determining contract method decision theory using a rule engine, returning candidates and legal basis. It uses specific verbs and resources, and distinguishes from sibling tools which focus on retrieving laws or 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 implies usage by listing parameters and their contexts, but does not explicitly state when to use this tool versus alternatives. No guidance on when not to use it or prerequisites.

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, openWorldHint, and non-destructive. The description adds value by specifying the allowed values for kind ('prec' | 'expc') and listing the content components returned. It does not mention rate limits or authentication, but for a read-only tool with strong annotations, this is sufficient.

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 very concise: one sentence defining the purpose, a Korean explanation of the content, and a clear Args list. Every sentence adds value, and the structure is front-loaded with the main purpose. 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 and the strong annotations, the description is largely complete. It explains parameters (including values and source), purpose, and retrieved content. However, it does not describe the output format or structure (no output schema), which would be helpful for an agent to parse the result. The Korean terms may require localization 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?

The input schema has 0% description coverage, so the description must compensate. It does so fully by explaining that both kind and case_id come from search_cases results, and explicitly lists the allowed values for kind. This provides essential meaning missing from 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 the tool retrieves the full text of Korean precedents/interpretations, listing specific components (판시사항, 판결요지, etc.). It distinguishes from sibling tools like search_cases (which returns a list) and get_law_article (which retrieves law articles). The verb '조회' and resource 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 states that both arguments come from the results of search_cases, providing contextual usage guidance. It implies the tool is the next step after searching, but does not explicitly state when not to use it or list alternatives. However, with sibling tools named differently, the context is clear enough.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it retrieves full text ('전체 조회'), providing marginal extra 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?

The description is extremely concise with a one-line purpose and a single example. Every sentence is necessary and front-loaded, achieving maximum information 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?

Given the simplicity (one required string parameter, no output schema), the description covers the core function and usage. However, it could briefly mention the response format (e.g., returns the full article text) for full 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?

With 0% schema description coverage, the description compensates by giving an explicit example format for the 'ref' parameter, adding meaning beyond the schema's bare 'Ref' title.

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 '법령 조문 원문 전체 조회' (query full text of a legal provision), specifying the verb and resource. It differentiates from sibling tools like search_law (search) and get_case (case retrieval).

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 an explicit usage example for the 'ref' parameter ('국가계약법 시행령 제26조'), guiding the agent to use precise references. While it doesn't explicitly state alternatives, the context of sibling tools implies when to use this vs. search tools.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint. The description adds '실시간 조회(항상 현행)' indicating real-time and always current data, and 'LLM 미사용' (no LLM used). This goes beyond annotations by clarifying timeliness and data source. 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?

The description is concise: a one-line header, one-line usage context, and a structured Args section. Every sentence is informative and well-organized, with no 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?

No output schema exists, and the description does not detail the return format (e.g., fields like case ID, title, date). However, it advises using get_case for full text, partially addressing output. For a search tool with three parameters, this gap is noticeable but not critical.

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 'Args:' section thoroughly explains each parameter: query (핵심 명사 위주 검색어 with examples), top_k (종류당 반환 건수, 기본 5, 최대 10), kind (prec/expc/all). This provides essential meaning beyond the bare-bones 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 states '판례·법령해석례 검색 — law.go.kr 실시간 조회(항상 현행). LLM 미사용.' which clearly identifies the tool as searching court precedents and statutory interpretations from law.go.kr in real-time. It distinguishes itself from siblings by noting that full text should be retrieved via get_case, and specifies usage when statutes alone are insufficient.

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 states when to use: '분쟁·처분취소·해석 다툼...에 조문만으로 부족할 때 쓰라.' (disputes where statutes are insufficient). It provides query examples and notes follow-up with get_case. However, it does not explicitly contrast with sibling tools like search_law or search_references.

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, openWorldHint, idempotentHint, and destructiveHint as false, so the safety profile is clear. The description adds behavioral context: returns snippet results and recommends get_law_article for full text. No contradictions. Additional details like rate limits are absent but not critical given 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 three concise sentences plus two parameter explanations. Every sentence adds value, with the most important information (purpose and key sibling reference) front-loaded. No extraneous 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 two parameters, no output schema, and annotations, the description covers the core functionality and key usage note (full text via sibling). It could mention output format or error handling, but for a simple search tool, it is adequately complete.

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

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

Schema description coverage is 0%, but the description compensates by explaining query with examples (e.g., '수의계약', '시행령 제26조') and top_k with default (8) and max (20). This adds significant 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 searches law articles by keyword or article number, returning snippets (top k), and distinguishes from sibling get_law_article by noting that for full text, that tool should be used. The purpose is specific and 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?

The description explicitly states when to use the tool (keyword/article number search) and provides an alternative for full text (get_law_article). It does not explicitly list when not to use, but the context and sibling names imply exclusions. Guidance is clear enough.

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.