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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description does add one real behavioral trait beyond that — the default full=false returns a tiered/abridged body — but '계단식 축약' is jargon and the detail is largely repeated from the `full` parameter description.

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?

It is short and front-loaded with the integration scope, with no filler sentences. However, the telegraphic fragments and mixed Korean/English abbreviations ('[통합조회]', '계단식 축약') trade clarity for brevity on a fairly complex 4-parameter nested 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?

For a unified 23-domain retrieval tool with a nested options object and no output schema, the description omits what the returned body looks like, what happens on an invalid or cross-domain id, and why domain-specific options matter. The schema fills in the parameter details, but the description itself is thin relative to 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%, including enum values for domain and detailed per-domain options, so the schema carries the parameter burden. The description only echoes 'domain+id' and the full=false default, adding no meaning beyond what the schema already documents; 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 verb+resource: retrieves the body text (전문 조회) of precedents/decisions, keyed by domain+id, across 23 domains. That is enough to distinguish it from search_decisions, though the contrast is only implicit in the word 전문 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?

There is no explicit when-to-use guidance and no sibling is named; the agent must infer that this is a follow-up call after search_decisions (the 'search 결과에서 획득' hint lives in the schema, not the description). Nothing says when not to call it or what to do for other domains.

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?

Annotations declare readOnlyHint=true, but the description explicitly states that in local execution outputPath saves an .hwpx file ('로컬 실행에서는 outputPath 로 한글(.hwpx) 저장'), which is an environment-modifying write and directly contradicts the read-only hint. Other behavioral details (legal DB cross-checking, hallucination prevention, reverse citation graph) are informative, but the contradiction overrides.

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 front-loads the tool identity and mode list, but then packs five modes and detailed amendment_table formatting rules into one dense paragraph with pipe separators. It is not wasteful given the tool's complexity, yet it is hard to scan and would benefit from clearer structure.

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?

It covers invocation for all five modes, required parameters, and key behavioral constraints (e.g., hallucination prevention, version-at-incident-time, omission of amendments counted as deletion). However, with no output schema it gives little detail on return structures for four of the five modes, leaving the agent unable to anticipate response shapes.

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 schema already documents all 14 parameters including the mode enum, required tags, and format notes. The description organizes which parameters belong to each mode but adds little beyond the schema's own parameter descriptions, so the baseline of 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 clearly states that this tool integrates five precise legal-analysis modes and names each specific operation (verify_citations, cite_check, applicable_law, impact_map, amendment_table) with the legal resource it handles. However, it does not mention or differentiate from sibling tools such as legal_research, search_law, or get_law_text, so an agent gets no explicit routing guidance against alternatives.

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 mode-by-mode breakdown gives clear conditions for each mode and marks required parameters (e.g., text 필수, caseNumber 필수, lawName+jo 필수), so the agent knows how to invoke each mode. But it never states when not to use this tool or which sibling to choose instead, leaving alternative selection implicit.

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 declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds a non-obvious behavioral default that the annotations cannot convey: precedent search defaults to case-name matching only, so body/fact-pattern searches silently miss results unless options.search is changed. It does not discuss result limits/truncation behavior or error cases, so it falls short of 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?

Purpose is front-loaded and nearly every clause carries information, but the description is one long run-on sentence packed with parenthetical enumerations. The 23-domain list in the opening sentence and repeated field lists consume space that could be structured as domain→option pairs, making it harder to scan under time pressure.

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-options, 23-domain tool with no output schema, the description covers the decision-critical parts: which domain to pick, when to enable body search, and which nested options exist. It does not describe the shape of returned results or how paging/sort codes behave across domains, which leaves a residual 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 baseline is 3, but the description earns above baseline because the options object is a loosely typed bag (additionalProperties: {}) and the description supplies the actual per-domain option keys and value encodings (search 1/2/'both', ministry code requirement, explYd, gana, caseNumber, etc.). It also mentions options.includeText and options.detailLimit, which are not documented in the schema at all.

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: an integrated search across 23 Korean-law domains, with the domain parameter choosing the source. It explicitly enumerates the domain families (판례, 해석례, 헌재, 행심, 조세심판, 관세, 부처 해석, 재심사 재결 등), which makes it clearly distinguishable from siblings such as search_law and get_decision_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?

It gives routing guidance that would otherwise require guessing: domain='precedent' plus options.includeText for full text, options.search='both' when the agent wants legal reasoning/fact patterns rather than case-name matches, and explicit source-to-domain mappings (NTS replies → 'nts', labor ministry → 'moel' with search=2, local tax → 'mois', all other ministries → 'ministry' with a ministry code, industrial-accident review → 'iaciac', employment-insurance review → 'eiac'). That is when-to-use-which guidance in concrete terms.

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.