Korean Law MCP

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds the concrete payload ('도구 이름과 설명을 돌려준다') and the breadth of the index (80+), but leaves the matching behavior unexplained — whether it matches on tool names, descriptions, or both, and whether results are ranked.

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 sentences: identity and scope first, then return format. Dense but front-loaded with no filler. The category enumeration is long, though it doubles as usable query vocabulary, so it largely earns its space.

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 does correctly state the return content, and the single parameter is fully covered. What's missing is the workflow contract for a meta tool — that discovered tools are then invoked via execute_tool, and whether results can be refined by re-querying with different intents.

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% with an example-laden intent description, so the baseline is 3. The description earns an extra point by enumerating eleven concrete query categories (조세심판, 관세, 헌재, 행심, 공정위, 개인정보위, 노동위, 학칙, 조약, 영문법령, 용어) that work directly as intent values, materially beyond the schema's four examples.

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 action (category search) over a specific resource set (80+ specialized tools: 조세심판·관세·헌재·행심·공정위·개인정보위·노동위·학칙·조약·영문법령·용어) and says what it returns (tool names and descriptions). The '[메타]' tag plus the category inventory makes it distinguishable from retrieval siblings like search_law or get_law_text, though it never names a sibling explicitly.

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 'meta / discovery' framing implies you call this when you don't already know the right specialized tool, and the schema examples clarify the query style. But there is no explicit when-to-use or when-not statement, and no mention of the natural follow-up (execute_tool), which is the key routing decision an agent faces in this 10-tool set.

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 and openWorld, so the safety profile is covered. What the description fails to add is the behavior that actually matters for a dispatcher: what happens when tool_name is unknown or params don't match the target tool's schema, and what the response looks like (the sub-tool's output, presumably).

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 short line with no padding, which is good, but here the brevity comes at the cost of under-specification rather than discipline — the dispatch contract is not explained at all.

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 an open-world meta-dispatcher with a free-form nested params object and no output schema, the description should at minimum say how to discover valid tool_name values and how errors are surfaced. Neither is present, so an agent must guess before it can invoke this 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 coverage is 100% and both parameters are described in the schema, so the baseline of 3 applies. The description restates the same two fields and adds nothing about the crucial constraint that the params object must conform to the signature of whichever tool tool_name selects — a nested-object semantic the schema cannot express.

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?

"[메타] 전문도구를 이름(tool_name)과 인자(params)로 실행" states the verb (execute) and the resource (a specialized tool), plus the dispatch mechanism. However, it never says what a "전문도구" is in this server's context or points to discover_tools as the source of valid names, so the agent cannot map it against nine siblings on the description alone.

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 statement of when to call this dispatcher instead of calling search_law, legal_research, get_law_text, etc. directly, and no mention of discover_tools as the prerequisite for obtaining a valid tool_name. The only guidance is implicit in the word "[메타]".

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 destructiveHint=false, so the safety profile is covered structurally. The description adds real behavioral context beyond that: it downloads the annex file and extracts text when bylSeq is given, and extracts the body directly when query narrows to a single annex. However, it never says what a multi-match response looks like versus a single-match extraction, leaving the return shape ambiguous.

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?

Purpose and the core lawName+'별표N' pattern are front-loaded, and every sentence carries usable information (amounts in annexes, retroactive lookup, query-over-number advice). It is a dense run-on block with parenthetical asides and some overlap with the schema text, which 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?

With 7 parameters, a 100% covered schema, and full annotations, the description supplies the missing decision context: retroactive date semantics, jurisdiction/naming quirks, and narrowing strategy. There is no output schema, and the description only partially covers the return shape (file-download text vs. direct body extraction vs. presumably a list when ambiguous), so a small gap remains.

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; every parameter already carries an inline description with examples (jo, knd enum, bySeq, annexNo). The description's date and query guidance largely restates what is already written in those schema fields, adding little genuinely new parameter meaning. The interaction hint that query is safer than a number when the annex number varies is the main marginal contribution.

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 resource and retrieval method: 별표/서식 (annexes/forms) of a Korean statute, extracted via lawName + '별표N'. It also notes that monetary amounts and standards often live in annexes rather than the main text, which clarifies what kind of content this tool returns. It never names the sibling get_law_text as the alternative for main-article text, so the differentiation is implicit rather than explicit.

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 clear context for the date parameter (retroactive standards at time of permit/construction/disposition, renamed statutes) and advises using query by annex name because annex numbering shifts over time. This is genuine when-to-use guidance. It stops short of stating when NOT to use it or naming a sibling to fall back on.

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 read-only, idempotent, non-destructive profile, but the description adds a genuinely non-obvious behavioral fact: with full=false (the default) the body is returned in cascading abbreviation rather than in full. That is the single most important thing an agent needs to know before interpreting the output. It stops short of describing response shape or per-domain differences.

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?

Extremely short and front-loaded, which is good, but it is written as clipped fragments that require the reader to reconstruct the meaning. The 'Korean-law-mcp —' prefix is pure overhead with no informational 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?

For a 4-parameter tool with a nested options object and a 21-value enum, the description covers only the domain/id pair and the full default; the domain-specific options (treaty language code, english_law mst/lawName, caseName) are left entirely to the schema. Adequate given the 100% schema coverage and existing annotations, but thin for the tool's 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 description coverage is 100%, so the schema already documents id, full, domain, and the nested options object in more detail than the description does. The description's 'domain+id' and 'full=false(기본)' merely restate schema content, and the options object is never mentioned. 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?

States a specific action and resource: full-text retrieval of decision bodies across 21 domains, keyed by domain+id. It is clear enough to act on, but it never distinguishes itself from siblings like get_law_text or search_decisions, and the telegraphic 'Korean-law-mcp —' prefix adds noise rather than clarity.

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 statement of when to call this versus search_decisions (to find ids) or get_law_text (for statutes). The only hint of a workflow, obtaining the id from search results, lives in the schema, not the description. There are no exclusions or alternative routing at all.

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 (readOnly, idempotent, non-destructive, openWorld). Beyond that, the description discloses real behavior: efYd auto-corrects to the version in force on the given date (including pre-renaming versions), jo='부칙' returns supplementary provisions from the latest promulgation, and jo accepts natural-language notation. These are meaningful behavioral details not in 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 dense but front-loaded with the core action first, then parameter-specific rules. The encoding examples (제10조의2→001002) earn their place by preventing a real error, though the paragraph is information-heavy for a single block.

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 4-param, no-output-schema retrieval tool whose schema fully documents parameters, the description covers how to specify the target law and version. It omits what the returned text looks like (structure, truncation) and the mst/lawId requirement contradicts the schema's empty required list, leaving a small 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 coverage is 100%, so the baseline is 3, but the description adds value by explaining that efYd is used both for prospective effective dates and for historical lookup dates with automatic version correction, and by restating the 6-digit JO encoding rule. It also notes mst/lawId are required, which conflicts with the schema's empty required array and could confuse an agent.

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 and resource (법령 조문 전문 조회 — retrieving the full text of statute articles) and clarifies that jo narrows to a specific article. It does not explicitly differentiate itself from siblings like search_law or get_annexes, so an agent relies on the title/resource to tell them apart.

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 useful conditions for the jo parameter (natural-language notation recommended, 부칙 for supplementary provisions) and for efYd (historical version retrieval). However, it offers no guidance on when to use this tool versus search_law or get_decision_text — the usage advice is parameter-level, not tool-selection-level.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses operational tradeoffs the schema does not: maxCitations means '많을수록 느림', and deepScan=false is '빠르지만 변경·폐기 감지 생략', and includeOrdinances=false skips the nationwide ordinance fan-out. It also explains the epistemic output distinction for citations (실존불가 vs 미확인), which is exactly the kind of behavioral context an agent needs to interpret results.

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 leading purpose sentence is front-loaded, but the mode breakdown is a single dense pipe-delimited run-on mixing purpose, required params, examples, and edge cases in one breath, making it harder to scan than a structured list would be. The volume is defensible for a four-mode tool, yet the formatting costs readability.

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?

All four modes are covered with required inputs, accepted formats, and defaults, which is strong for an 11-parameter multiplexed tool with no output schema. The only gap is that return shapes are only hinted at (mermaid graph, citator status) rather than characterized, and there is no note on failure behavior when a cited provision cannot be resolved.

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 schema alone already justifies a 3; the description goes further by tying each parameter to its mode and explaining why (e.g., applicable_law resolves renaming laws to their old-name versions and handles administrative rules like 'NFTC 103'). The mode-to-parameter mapping table in prose adds navigational value beyond the flat per-property schema descriptions.

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

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

The description names a specific resource (Korean statutory/case-law citations) and enumerates four distinct operations with concrete examples like '민법 제750조' and '대법원 2013다61381', so an agent knows exactly what each mode does. It frames the tool as the '[정밀분석] integrated 4-mode' option, which implicitly separates it from lookup siblings such as get_law_text or search_decisions, but it never names those siblings directly.

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 trigger condition and required inputs (verify_citations needs text, cite_check needs caseNumber, applicable_law needs lawName+date, impact_map needs lawName+jo), and one use case is spelled out explicitly ('LLM 환각 방지'). What is missing is guidance on when to prefer legal_research or search_law over these modes, so selection against siblings is still inferred.

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 safety is covered. The description adds genuinely behavioral context: it fans out to multiple APIs in parallel and auto-detects scenario from the query when unspecified, which tells the agent to expect higher latency and broader output. It does not warn about response-size limits in the description body itself (the #158 truncation caveat lives only in the includeHistory parameter).

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 core distinction — complex parallel research only — is front-loaded before the enumeration, which is the right ordering. The pipe-delimited task/scenario list is dense but information-bearing rather than padded; it is long, though, and the scenario guidance spills into a second clause that could be tightened.

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 13-parameter aggregator with no required params, the description does the hard work of explaining which task/scenario combinations are legal and coherent. With no output schema, the return shape (what sections a full_research vs. amendment_track response contains) is left entirely unspecified — the one meaningful gap for a tool that merges many sources.

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 each parameter is already tagged with its governing task, so the schema carries most of the load. The description still adds value by supplying the per-task examples that the task enum's own description explicitly defers to ('도구 설명의 task 표 참조') — without the description the enum would be much less interpretable.

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 immediately constrains scope to '복합 질문 전용' — questions that require stitching multiple APIs in parallel. The eight enumerated tasks with concrete example queries make it unmistakable that this is the orchestrator, not a single-lookup sibling like search_law or get_law_text.

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 task table is effectively a routing guide: each task names a question shape and an example, and it declares full_research as the fallback for unclear natural-language queries. Scenario compatibility per task is spelled out in the enum description. What's missing is an explicit statement of the negative case — that simple single-law lookups should go to the lighter siblings instead.

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 establish that the tool is read-only, idempotent, open-world, and non-destructive. Beyond that, the description explains the substantive behavior: citation extraction, effective-date comparison, and automatic flagging of possible maintenance targets. It does not describe output format or handling of missing citations, but the core behavioral logic is disclosed.

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 front-loaded: it names the tool, states the extraction/comparison behavior, then gives the intended user and parameter rule. Some title duplication at the start is redundant, but the remaining text earns its place.

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

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

With no output schema, the description still conveys the conceptual return value — flagged ordinance provisions whose superior law was amended after the ordinance took effect. It does not specify the exact result structure or edge-case behavior, but it covers enough for an agent to understand the tool's purpose and invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds a meaningful constraint beyond the schema: despite all parameters being optional in the schema, the caller should specify one of ordinSeq/id or ordinanceName. It omits the query alias, but the main identifier-selection rule is useful.

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-and-resource combination: it extracts superior statutes cited by an ordinance and compares effective dates to flag provisions needing review. This is far more precise than the title alone, though it does not explicitly distinguish itself from sibling tools such as legal_analysis or 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?

It gives a clear use context — ordinance officials tracking amendments to superior laws and deciding whether an ordinance needs maintenance. It does not state when to use this instead of alternatives or when not to use it, so it falls short of full routing 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 cover read-only, idempotent, open-world, non-destructive, so the description only needs incremental behavior. It delivers: the non-obvious default that precedent search matches case names only, and the includeText/detailLimit toggle needed for full body text. Pagination, result caps, and response shape are not described, keeping it below a 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?

Front-loaded with the unified-search premise, and every subsequent sentence carries routing or mode-selection information. Deducted for re-listing all 21 domain names parenthetically, which duplicates the enum, and for a dense single block with no structure that makes the search-mode distinction easy to miss.

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 6-parameter, nested-object tool with no output schema, the description covers the hard parts: domain routing, name-vs-body search modes, and text inclusion. It leaves page/display/sort behavior and the differing result shapes across the 21 domains to the schema or the agent's discovery.

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%, but the enum values are cryptic strings ('iaciac', 'eiac', 'moel'), and the description does the real work of translating them into sources. It also documents options.includeText and options.detailLimit, which appear nowhere in the schema's options description (only additionalProperties: {} allows them) — genuine value beyond structured fields.

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

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

The description opens with a specific verb+resource (통합검색) and states the exact scope: 21 named Korean legal domains in one call, with the domain parameter selecting the corpus. It also distinguishes the body-text variant ('판례 본문까지 필요하면 domain=precedent, options.includeText=true'), so an agent can tell it apart from get_decision_text 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?

Strong routing guidance: it maps real-world needs to specific enum values (국세청 해석 → nts, 고용노동부 질의회시 → moel, 산재보험 재심사 → iaciac, 고용보험 재심사 → eiac) and explains that precedent search defaults to case-name lookup, so doctrinal or fact-pattern exploration needs options.search='both'. It stops short of naming sibling tools (get_decision_text, search_law) as explicit alternatives.

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 read-only and idempotent annotations, the description discloses substantive behavior: automatic fallback to local ordinances and administrative rules on zero hits, automatic abbreviation conversion, display of renamed and upcoming-amendment laws, and guidance for repealed rules including successor provisions. These are exactly the behavioral traits an agent needs before relying on results.

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 text is front-loaded with the tool purpose and then lists concrete behavioral features. It is dense and slightly overpacked into a single paragraph, but each clause contributes operational information rather than filler.

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

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

There is no output schema, yet the description states the key return values (lawId, mst) and covers fallback, abbreviation conversion, amendment notation, and repealed-law guidance. For a search/discovery tool, this is complete enough for an agent to call and interpret results 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 coverage is 100%, so the baseline is 3, but the description adds real meaning to the query parameter by explaining that abbreviations are auto-converted and by giving example queries including ordinance and administrative-rule names. It does not add detail about the display parameter beyond what the schema already says.

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 and resource: keyword search of law names, ordinance names, and administrative rule names, returning lawId and mst. It clearly distinguishes this discovery step from retrieval siblings such as get_law_text and get_annexes by framing itself as identifier acquisition before lookup.

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 a clear usage condition: use this before retrieving laws, ordinances, or administrative rules in order to secure identifiers. It also explains fallback behavior when there are zero results, though it does not explicitly contrast itself with sibling search tools such as search_decisions.

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