법이 닿는 곳 (Where Law Reaches)

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and closed-domain behavior are covered structurally. The description's only added behavioral fact is the geographic scope ('in Korea'), which is genuinely useful context not present in the schema or annotations. It says nothing about auth requirements, rate limits, or how large/expensive the response is.

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?

A single dense Korean sentence plus a one-line English gloss; the scope ('around a point') and the Korean-market constraint are front-loaded. The mid-sentence output inventory is list-heavy but every item conveys what data is available, so little is wasted.

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 usefully enumerates the return contents, which is the right compensation. However, for a 4-parameter geo tool it omits the coordinate format, how to source lat/lon (the geocode sibling), and any sense of result size or pagination, leaving real gaps an agent must guess at.

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 only 50%: radius_m and category_code are documented in the schema (including the 500/1000/2000 enum values, which the description does not repeat), while lat/lon carry no description at all. The description's '좌표 둘레 반경' and '업종별' loosely map to radius and category but add no coordinate system, format, or unit information to compensate for the undocumented required parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource — commercial-district statistics within a radius of a coordinate in Korea — and enumerates the payload (business counts by industry, nearby businesses, district demographics/causes of death/ordinances, openings/closings trends). It is a noun-phrase inventory rather than a verb-led statement, but an agent can tell exactly what it returns. Sibling differentiation is moot since none of the listed siblings (geocode, get_law, search_bids...) overlap in domain.

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?

There is no when-to-use or when-not-to-use guidance and no named alternative. Critically, the tool requires lat/lon and a sibling tool (geocode) exists that presumably produces them, yet the description never says 'geocode an address first' or otherwise explains how to obtain the required inputs. Usage context is only implicit from the phrase 'around a point in Korea'.

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 and openWorldHint=false, so the safety profile is covered by structured data. The description adds the meaningful input-domain constraint that only Korean addresses/places are supported, but says nothing about lookup latency, failure behavior for unresolved queries, or result format. It contributes some context beyond annotations, appropriate for a 3.

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?

Very compact and front-loaded, stating the core transformation first and the consumer second. The Korean and English sentences are semantically redundant, which serves a bilingual audience but slightly duplicates content rather than extending it. Still efficient overall.

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 single-parameter, read-only lookup tool with a fully documented schema and safety annotations, the description covers purpose, input domain, and downstream use. The only minor gap is that with no output schema, the description does not indicate the shape of the returned coordinates, but that is a small omission for such a simple 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 100% for the single 'query' parameter, and the schema already supplies the examples (강남역, 세종대로 110). The description does not add syntax, format, or disambiguation guidance beyond the schema, so the baseline 3 for high coverage applies.

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 verb+resource pair: it converts Korean addresses or place names into latitude/longitude. It also names the downstream consumer (area_stats), so an agent instantly understands the tool's role and cannot confuse it with any sibling. Nothing here restates the tool name as a tautology.

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 parenthetical '(coordinates to use in area_stats)' gives explicit context for when this tool is needed, effectively routing the agent from area_stats to geocode. There are no exclusions or when-not-to-use conditions stated, but with no competing geocoder sibling, little more is required. Clear context without exclusions lands this at 4.

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 and openWorld (false), but description adds that it returns links like citations and related cases, which is useful behavioral 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?

Bilingual, concise: one sentence in Korean, one in English, both front-loading purpose and output. 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?

Complete for a read-only single-article fetch: purpose, output (full text + links), and key format/source are all stated. No output schema needed.

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 100% and schema documents the key parameter. Description adds that key comes from search_law/search_procurement results, providing provenance not in 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?

States a specific verb+resource: fetch full text and links of one statute article. Distinguishes from siblings by implying a single article vs search_law/search_procurement which find multiple.

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?

Describes output includes full text and links (citations, delegations, related cases). Does not explicitly say when to use vs alternatives like get_law, but the context of one article vs entire law is 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 and openWorldHint=false, so the safety profile is covered. The description adds useful return-shape context (article number, title, key) absent from any output schema, but says nothing about lookup failures, ambiguity handling for abbreviations, or ordering.

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?

Compact and front-loaded, with the lookup semantics stated first and the return contents in a trailing parenthetical. The bilingual duplication is slightly redundant but justified for an English-reading agent on a Korean-domain 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?

With no output schema, the description carries the return-value burden and does describe the article list contents. Combined with annotations covering safety, it is nearly complete; only error/not-found behavior is unaddressed.

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 100% and the single parameter is documented with examples, so baseline is 3. The description adds meaning by clarifying that the 'name' accepts both formal names and abbreviations (정식 이름·약칭), which the schema examples alone do not state.

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 and resource ('look up a Korean law by name and list its articles') and specifies the returned units (조·제목·key). It is clearly distinguishable from search_law and get_article by its name-based retrieval, though it does not explicitly name those 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?

Usage is implied by 'by name (정식 이름·약칭)' – the agent can infer this is for when the exact law name is known – but there is no explicit when-to-use versus search_law or get_article, and no exclusions or prerequisites are stated.

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 and openWorldHint=false, so the safety profile is covered. The description does add one behavioral fact beyond the annotations — the '매일 새벽 대조' daily-dawn reconciliation cadence that explains the data's freshness — but says nothing about ordering, snapshot behavior, or result size.

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?

Two short clauses, no filler, and the resource is front-loaded. The Korean/English duplication is mildly redundant but serves bilingual agents and costs little.

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 single-parameter read-only list tool with a fully documented schema and safety annotations, the essentials are present, but the description omits result ordering and what 'amended' covers, which an agent would want before routing to this tool over search_law.

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 100%, with the lone 'limit' parameter documented with range and default in the schema itself. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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 (recently amended/enacted Korean laws) with an implied list verb and adds a scope qualifier ('최근', recently) that distinguishes it from a general search_law or get_law. It stops short of naming the sibling it replaces, so an agent must infer the boundary itself.

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?

There is no when-to-use or when-not-to-use guidance. The description never contrasts this tool with search_law, get_law, or get_article, leaving the agent to guess why it would pick 'recently amended laws' over a normal search.

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 and openWorldHint=false, so the safety profile is covered. The description adds the default filtering behavior (open-only) and the D-n deadline indicator in results, but largely restates the open_only default already present in the schema and says nothing about rate limits, auth, or result size.

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?

Two compact sentences that front-load the primary action and default scope, with a bilingual restatement that costs little. No padding or filler sentences.

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, so the description's mention of the D-n display is helpful, and the read-only nature is covered by annotations. Still missing an explanation of the kind enum and any differentiation from the overlapping search_procurement sibling.

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 67%: query and open_only are documented in the schema, and the description only echoes the open_only default. The kind parameter with its enum (물품/용역/공사) is undocumented in both schema and description, leaving a real 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?

States a specific verb (찾는다/search) and resource (나라장터 입찰공고), plus the query mechanism (공고명으로) and default scope (마감 전 공고만). However, it never distinguishes itself from the sibling search_procurement, which an agent would reasonably consider for the same task.

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 declaring the default is closed-before-only notices, which hints at when the tool is appropriate. But it gives no explicit when-to-use or when-not-to-use guidance and does not point to search_procurement or any alternative for broader procurement searches.

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 and openWorldHint=false, so safety and scope are largely covered structurally. The description adds that the search spans multiple legal source types (statutes, precedents, interpretations, tribunal decisions), which is genuinely useful behavioral context. It says nothing about result limits, ranking, or response shape, so with annotations carrying the safety profile a 3 is appropriate.

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 examples are concrete, but the content is stated twice in Korean and English with the 'plain-language questions are fine' point repeated within the English sentence itself. Roughly half the text is redundant translation rather than new 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?

With no output schema, the description should ideally hint at what comes back (article citations, case numbers, snippets) and how the limit parameter shapes results. It enumerates the source domains but says nothing about return format or result presentation, leaving a modest gap for a search tool with no output schema.

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

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

Schema description coverage is 100%, so both parameters are already documented (limit 1~15 default 8, query as Korean question or keyword). The description's contribution is confirming that natural-language questions are valid input, which the schema already implies with '질문이나 낱말'. This is marginal added value over the schema, matching the baseline 3.

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 (찾는다/search) and enumerates the resources covered: Korean statutes, court precedents, MOLEG interpretations, and Constitutional Court/administrative appeal decisions. This scope is distinguishable from ID-based siblings like get_law and get_article, though those siblings are never named. The bilingual restatement adds nothing new to the purpose.

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 note that plain-language questions work, with examples like '회사에서 갑자기 잘렸어요' and '헬스장 환불', gives useful implied context for how to phrase a query. However, it never says when to use this tool versus get_law, get_article, or verify_citations, nor any exclusion conditions. Usage 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 already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral detail beyond annotations: the ~600K record scale, the fact that change orders are collapsed into a single contract, and the specific aggregate outputs (counts, amounts, sole-source ratio, rankings) it returns.

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?

Two compact sentences in Korean and English that front-load the scope and outputs efficiently. No wasted words, though the bilingual duplication is slightly redundant.

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

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

For a 7-parameter analytics tool with no output schema, the description reasonably conveys the aggregate nature of the result. However, it doesn't describe pagination, result limits, or how to interpret rankings, and provides no usage differentiation from related siblings.

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 71% with 7 parameters, so the schema does substantial work. The description mentions filtering dimensions (품목·기관·업체) which loosely maps to the 'by' enum, but adds no syntax, format, or interaction details beyond what the schema already documents for key parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb+resource: searching Korean public procurement contracts (~600K records, with change orders folded into one) and returning counts, amounts, sole-source ratios, top counterparties, and legal-basis rankings. It is specific and quantifies scale, though it doesn't differentiate from siblings like search_bids, which also appears procurement-related.

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?

No explicit when-to-use or when-not-to-use guidance is provided. The description vaguely implies aggregation/ranking functionality, but doesn't clarify the distinction from search_bids or when an agent should choose one over the other.

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 and openWorldHint=false, and the description complements this by disclosing the response semantics (✓ exists, ✗ missing, ⚠ ambiguous law name) and that validation is against current law. It does not cover latency, rate limits, or partial-match behavior, but adds real value beyond 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?

Front-loaded with the core action and result legend, and the usage condition follows immediately. The English sentence is largely a translation of the Korean, so there is mild redundancy, but nothing is wasted or buried.

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 carries the burden of explaining results and does so via the ✓/✗/⚠ legend. Combined with the schema's 6,000-character input limit, an agent has enough to call it correctly, though failure modes (e.g. non-citation text) are not described.

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?

Only one parameter with 100% schema coverage, so the baseline is 3. The description goes beyond the schema by specifying the expected citation shape ('○○법 제N조(의M)') that the input text should contain, which helps an agent format the call correctly.

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: verifying whether statute citations ('○○법 제N조(의M)') exist in current law. The distinctive output vocabulary (✓/✗/⚠) makes it clearly different from retrieval siblings like get_law or search_law, so an agent can route to it 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?

Explicitly says when to use it: '법률 내용을 답하기 전에 인용을 이것으로 검증하면 헛인용을 막을 수 있다' – i.e. call this before answering legal questions to prevent hallucinated citations. It gives clear context but does not name or exclude alternative sibling tools (search_law, get_article) for related tasks.

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