Korean Law MCP

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond that: it is a meta/category-search tool for 80+ specialized domains. Nothing in the description contradicts the annotations — '카테고리 검색' (category search) is consistent with a read-only, idempotent lookup.

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 compact — a single sentence with the meta/fallback context front-loaded before the category list. While the parenthetical enumeration is dense, there is no waste and the key routing instruction comes first.

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 simple one-parameter discovery tool with rich annotations and 100% schema coverage, the description is mostly sufficient: it states when to use it and what it searches. However, it does not describe the output/return format (there is no output schema), and the Korean-only text plus ambiguous '위 도구' reference leaves some agent-facing details unresolved.

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%: the 'intent' parameter is described with meaning and examples ('공정위', '조약', '용어', '헌재'). The description's listing of categories (조세심판, 관세, 헌재, etc.) reinforces what 'intent' accepts but adds little beyond the schema. Baseline 3 applies since the schema already carries the heavy lifting for the single 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 states a clear purpose: a meta-tool for category-based search across 80+ specialized legal tools (tax appeal, customs, constitutional court, etc.). It distinguishes itself from the sibling tools by branding itself as '[메타]' (meta) and a fallback when standard tools fail. The purpose is specific and recognizable, though it never names actual sibling tools and is written in Korean.

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

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

It gives an explicit condition — '위 도구로 안 되는 경우' (when the above tools don't work) — framing it as a fallback/discovery gateway. However, '위 도구' is vague and does not identify which siblings it applies to, nor does it state when NOT to use it or what 'not working' means. The guidance is present but underspecified.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description does not repeat that. It adds the important constraint that the tool must come from discover_tools, which is behavioral context beyond the annotations. 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 a single, brief sentence that front-loads the purpose and parameter essentials without any fluff. It is appropriately short for a simple proxy concept, though it could benefit from slightly more elaboration without losing conciseness.

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 proxy tool that can execute any tool, the description is minimal and omits key guidance. It does not explicitly state the prerequisite of calling discover_tools first, nor does it explain error handling or what happens with invalid tool names. The schema provides some context, but the tool description itself is insufficient for a complete 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 100%, and the description merely restates the parameter names (tool_name + params) without adding further meaning. Since the schema already documents both parameters fully, the description adds no extra value, matching the baseline score for high 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 that this is a proxy execution tool for tools discovered via discover_tools, taking a tool_name and params. It effectively identifies the function as a meta-tool that runs other tools, which distinguishes it from the specific sibling tools. However, it does not explicitly mention the return value, though that is implied to be the result of the underlying 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 the tool is to be used after discover_tools by referencing 'discover_tools 결과 도구' (tools from discover_tools results), but it does not explicitly state when to use it versus directly calling a specific tool. It lacks clear guidance on prerequisites or exclusions, leaving usage conditions 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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds non-obvious behavior beyond them: unspecified date means the currently-in-force version, a specified date reaches back to renamed/superseded laws, and a single query match returns the annex body directly. It omits return-size/pagination and rate-limit context, keeping it at a 4.

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 definition is front-loaded — resource identification opens, then parameter behavior — with no filler sentences. It is dense with parentheticals and mid-sentence dashes that make it slower to parse, but each clause carries semantic content rather than repetition.

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 tool with one required argument and no output schema, the description covers the critical defaults (현행 vs historic via date), the numbering-shift caveat, and the narrowing-by-name path. It does not explicitly describe output form (download vs extracted text beyond the bylSeq schema note), so it is strong but not exhaustive.

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 every parameter is already documented and the baseline is 3. The description mostly restates the schema's date semantics and adds only one cross-parameter recommendation (narrowing by query name is safer than by number because numbering shifts across versions). Useful but marginal 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 names a specific resource and verb — '[별표] 별표/서식 조회' and 'lawName+별표N으로 내용 추출' — so an agent knows this retrieves annex/form content rather than main law text. It also adds scope color ('금액/기준은 별표에 있는 경우 많음'). It does not, however, explicitly name a sibling such as get_law_text to contrast against, so 5 is not warranted.

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

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

It gives clear conditional guidance: pass date when you need the version in force at a past point (건축허가·착공·처분 시점) and use query when the 별표 number is unknown or has shifted over time. That is actionable when-to-use context. It stops short of stating when NOT to use the tool or pointing to a specific alternative sibling, so it is a 4 rather than 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=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds genuinely useful behavior beyond this: full=false (default) progressively condenses the body, which informs the agent that full=true is required for unabridged text. This complements, and does not contradict, the annotations.

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

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

The description is compact — a single front-loaded line with no filler. The leading 'Korean-law-mcp —' prefix is meta labeling rather than functional content, and the dense Korean shorthand (계단식 축약) reduces immediate parseability, but the description remains efficient and well-oriented.

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 tool is complex — an 18-domain enum, a nested options object with domain-specific structures (treaty, english_law, precedent), and no output schema. The rich schema (100% coverage) carries most of the weight, and the description supplies the key default behavior. Still, the description leaves usage context (fetch vs search) unaddressed, which is significant 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?

Schema description coverage is 100%, so all four parameters (domain, id, full, options) are already documented in the schema, including the full default behavior, domain enums, and options structure. The description restates domain+id and the full=false default without adding meaning beyond the schema, so it only meets the baseline of 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?

The description states a specific action — full-text retrieval (통합조회) of decisions across 18 domains using domain+id. It identifies the resource (decision text) and the retrieval mechanism. However, it does not explicitly name siblings like get_law_text (law text vs decision text) or search_decisions (search vs direct id fetch), so differentiation is implied rather than stated.

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 guidance is given on when to use this tool versus alternatives. The description never mentions search_decisions, get_law_text, or when direct id-based retrieval is appropriate. The only usage hint ('obtained from search results') lives in the schema's id description, not the tool description, so the agent gets no explicit routing help between 9 siblings.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds a genuinely non-obvious behavioral trait: efYd auto-corrects to the version in effect on that date, including versions predating a title change. It does not discuss rate limits or response shape, keeping it below 5.

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 each clause carries actionable detail (jo formats, efYd semantics, sibling routing). It is dense and somewhat redundant with the schema text, which slightly dilutes conciseness.

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 simple read-only lookup with a fully documented 4-param schema and no output schema, the description covers inputs, version-selection behavior, and sibling routing adequately. It omits any note on the returned text's structure or size, which is the only minor gap.

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 the baseline is 3. The description largely restates the schema's own jo encoding rule (001002 vs 023402) and efYd behavior verbatim rather than adding syntax the schema lacks, so it earns no lift above 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 opening '[법령조회] 조문 전문 조회' states a specific verb (조회/lookup) and resource (조문 전문 / full text of provisions) in one line. It also names the sibling it is not for applicable-law determination (legal_analysis), letting an agent place it relative to search_law (which supplies mst/lawId) and legal_analysis.

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 states prerequisites (mst/lawId 필수), how to narrow to a single article via jo, that natural-language notation is recommended, that current text should be fetched without efYd, and that past versions are reached by setting efYd. It explicitly routes to legal_analysis(mode=applicable_law) for the distinct applicable-law/transitional-measure task.

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/openWorld, and the description layers real behavioral detail on top: external DB cross-verification, distinguishing 실존불가 vs 미확인, detecting 변경·폐기 of cited cases, returning the version of a law in force at a date including 부칙 경과조치, and emitting a mermaid reverse-citation graph. This tells the agent what actually happens and how results are shaped.

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 tool name and a one-line summary ('검증·분석 4종 통합'), then a compact pipe-delimited breakdown per mode. It is dense but each clause carries mode-specific content; only minor redundancy with the schema keeps it from a 5.

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 4-mode, 11-parameter tool with no output schema, the description covers each mode's behavior, required inputs, and the shape of key outputs (mermaid graph, change/obsolete detection, distinct existence verdicts). Some mode-level return-format detail is left implicit, but it is sufficient for an agent to 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?

Schema description coverage is 100%, so the schema already documents all 11 parameters, and the description's per-parameter notes (jo accepting '제103조'/'103조'/6-digit JO codes, lawName accepting abbreviations and administrative rules) largely restate the schema. It does consolidate which parameters are required per mode, which adds some navigational value, so baseline 3 is appropriate.

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 the resource (Korean-law verification/analysis) and enumerates four distinct modes, each with a specific verb+resource: cross-verifying citations against the 법제처 DB, checking whether a case is still good law, resolving the law version in force at a date, and building a reverse citation graph. An agent can tell this apart from siblings like get_law_text or search_law 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?

Each mode carries its own triggering condition and required inputs (e.g., verify_citations for LLM hallucination checking, cite_check for a case-number 'Citator', applicable_law for 행위시법 timing), so the agent knows which mode to pick. It stops short of explicitly routing to sibling tools for the cases this tool does not cover, so it is clear context without exclusions.

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/openWorld, so the safety profile is covered. The description adds genuinely non-structured behavior: document_review requires the text field, scenarios auto-detect from the query, task/scenario compatibility is constrained, and includeHistory warns that its section can exhaust the response budget and truncate the comparison table (#158). It does not address runtime cost despite the 'parallel API' fan-out, which would be useful.

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 front-loaded with the identity line, then an efficient pipe-delimited task table where every entry earns its place by decoding a cryptic enum and adding an example. Density is high and justified for a 13-parameter dispatcher, though the scenario enumeration restates much of what the schema already encodes.

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, zero-required-parameter, no-output-schema tool, the description covers routing, per-task prerequisites (text for document_review, query for all others), scenario compatibility, and one documented failure mode with an issue reference. What is missing is any indication of cost/latency or expected response shape for a tool that orchestrates several APIs in parallel.

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%, so the baseline is 3, but the description does real work the schema cannot: it gives meaning and example queries for the otherwise opaque task enum values, and it explains the task-to-scenario compatibility matrix that the schema only alludes to via a cross-reference. The domain enum and per-task parameter tags are also clarified ([time_travel], [ordinance_compare], etc.).

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 concrete verb+resource ('다단계 법령 리서치 통합' running multiple APIs in parallel) and enumerates the eight research modes with representative example queries for each. It also explicitly distinguishes itself from siblings by stating that single-lookup questions should use search_law/get_law_text instead.

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?

Each task value is paired with a when-to-use condition and an example query ('음주운전 처벌 기준', '관세법 체계', '과세처분 불복'), and the closing sentence gives an explicit exclusion routing single queries to search_law/get_law_text. Alternative selection between search_law, get_law_text and this tool is unambiguous.

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, which cover the safety profile. The description adds the specific behavioral logic (extracting cited statutes, comparing effective dates, flagging maintenance targets), which goes beyond the annotations. However, it does not disclose potential limitations (e.g., how the analysis handles missing data, or whether it only works on Korean ordinances), so it provides partial value but not rich behavioral context.

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 three sentences) and front-loaded with a clear purpose. It avoids repeating schema details and each sentence contributes (purpose, target user, input requirement). It is slightly longer than necessary but not wasteful. The structure effectively communicates the essential information without padding.

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 tool has no output schema, so the description should at least hint at the return value. It says results are 'automatically flagged' but does not describe the result format (e.g., a list of flagged statutes, a report, or a structured object). It also does not clarify what happens if both ordinSeq and ordinanceName are provided, or if neither is given, which are common edge cases. Given the complexity of the analysis, the description is incomplete in these respects.

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% — each parameter (id, query, ordinSeq, ordinanceName) has its own description. The description adds a rule beyond the schema: 'ordinSeq(또는 id)나 ordinanceName 중 하나 지정', clarifying that the agent must supply at least one of these two groups, which is not evident from the empty required array. This is a meaningful semantic addition that helps the agent understand how to combine the 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 specific verb ('extracts', 'compares', 'flags') applied to a specific resource (ordinances' cited superior statutes), making it clear this is an analysis tool, not a search or retrieval tool. It uniquely combines extraction with date comparison and flagging, which clearly distinguishes it from siblings like search_law or get_law_text. No ambiguity remains about the tool's function.

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: it is for ordinance officers tracking superior law amendments and maintenance decisions. It also dictates the input requirement (one of ordinSeq/id or ordinanceName). However, it does not explicitly state when NOT to use this tool or point to specific alternative tools for other scenarios, so it lacks explicit exclusions. The context is clear but alternatives are not named.

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, openWorld, non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: default case search targets case names only, and text retrieval is opt-in via includeText/detailLimit. It does not mention rate limits or return format, but for a read-only search this is solid added value.

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 front-loaded: the integrated-search scope leads, followed by targeted parameter-selection tips. No filler sentences; each clause carries a concrete instruction.

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 6 parameters, a nested options object, and no output schema, the description covers search modes and domain routing well but omits return shape, pagination behavior, and how results relate to get_decision_text. Adequate but with clear gaps for a tool of this 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?

Schema coverage is 100% (baseline 3), and the description goes beyond it by documenting options.includeText and options.detailLimit, which are absent from the schema's options description, and by clarifying the search mode semantics for discovery vs. name lookup. It adds meaningful routing meaning to the domain and options 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?

States a specific verb+resource: an integrated search (통합검색) across 18 named Korean-law domains, and lists them. However, it never names the sibling it is not — search_law, get_decision_text, or legal_research — so the agent cannot fully disambiguate from siblings without opening their schemas.

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

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

Gives conditional guidance for parameter selection: domain='precedent' + includeText for full case text, search='both' for doctrine/fact-pattern discovery, domain='nts' for tax-authority interpretations. But it offers no when-to-use-this-vs-alternatives routing against search_law or get_decision_text, so usage is implied rather than explicit.

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 convey the safety profile (readOnly, idempotent, non-destructive, open-world), but the description adds substantial behavior beyond them: automatic fallback to 자치법규/행정규칙 on zero hits, abbreviation auto-conversion, auto-annotation of renamed/pending amendments, and proactive notification of repealed rules with successor statutes. These traits materially affect how the agent interprets results and cannot be inferred from structured fields.

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 and identifier output are front-loaded, and each clause (fallback, abbreviation handling, repeal notices) conveys distinct, useful behavior. It is dense and heavy for a single paragraph, with a few clauses that could be tightened, but nothing is truly 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 compensates by naming the returned identifiers (lawId, mst) and describing result quirks (fallback, repeal notices). For a simple 2-parameter read-only search tool, the agent has everything needed to call it and interpret results.

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 in the schema, and the description only adds a marginal note about abbreviation auto-conversion on the query input. Per the high-coverage baseline, 3 is appropriate since the schema carries the parameter burden.

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 (법령명·조례명·행정규칙명 키워드검색) and even names the output identifiers (lawId, mst), so the agent knows exactly what it produces. It also distinguishes itself from the sibling search_law_bulk by naming it directly, so the two search tools are separable without opening a 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 states when to use it ('법령·조례·행정규칙 조회 전 식별자 확보용') and names the alternative for the contrasting case (execute_tool with search_law_bulk for checking amendments across many laws). This is precise when-to-use plus a named alternative, not implied guidance.

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