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

Annotations only provide readOnlyHint=true, so the description carries the burden and does add real value: it discloses the automatic fallback to same-family 시행령/시행규칙 annexes and the shape of the response (total count, page, file links). It still omits pagination/truncation behavior (maxBytes, part).

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 dense sentences with the core action front-loaded and no wasted filler. Efficient, though it packs the fallback and return-shape information tightly without structuring them.

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 12-parameter tool with no output schema, the description covers the fallback logic and return fields but leaves the key identifier-selection and pagination parameters unexplained. An agent could still call it, but not confidently choose among name/lawId/mst.

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?

12 parameters with only 58% schema description coverage, and the description does not disambiguate the identifiers (mst vs lawId vs name), asOf, part, or maxBytes. It hints at page and file links but adds no real meaning 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?

States a specific verb+resource: fetches the list and body of a statute's annexes/forms (별표·서식), which is clearly distinct from article_get or statute_outline. It also states the scope of the fallback behavior. However, it never names a sibling tool to sharpen the boundary.

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

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

Usage is only implied by the resource type; there is no explicit 'use this when...' statement or comparison against article_get/statute_outline. The fallback condition (no annex in the statute body) is a useful trigger but is about internal behavior, not tool selection.

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?

readOnlyHint=true already establishes this is a safe read, so the bar is lower. The description adds real value beyond that: it picks the edition in force at asOf and returns 항·호·목 hierarchy plus amendment markers. It is silent, though, on pagination/truncation behavior implied by the 'part' (이어받기) and maxBytes budget parameters.

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

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

Two compact clauses, front-loaded with the core action, and no filler. The parenthetical about empty articles earns its place by defining a distinct output mode.

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 9-parameter tool with no output schema, the description covers purpose, version selection, and return structure, which is the essential part. It omits the paging/byte-budget story (part, maxBytes) needed to know how truncated results are continued, leaving a meaningful 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 89%, so the schema already documents every parameter (including 'articles 비우면 목차', asOf, format, maxBytes). The description largely restates those semantics rather than adding new syntax or interaction rules, so the baseline 3 applies.

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

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

The verb+resource are concrete: fetch the full text of statute provisions (법령 조문 원문을 전문으로 가져온다), with a stated variant when articles is empty (TOC only). This clearly separates it from a pure-outline sibling. However, it never names or routes against the actual siblings (statute_outline, statute_find), so an agent must infer the boundary.

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

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

Usage is only implied: passing articles yields full text, empty articles yields just the number/title TOC, and asOf selects the version. There is no explicit 'use this instead of statute_outline when…' or any exclusion against annex_get/statute_history. Adequate but leaves sibling disambiguation 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?

readOnlyHint=true already tells the agent this is a safe read, and the description adds genuinely non-obvious behavior: law names are matched only via dictionary (so a name miss is not proof of hallucination) and upstream failures yield UNCHECKED rather than a hallucination verdict. That distinction materially changes how an agent interprets results. It still omits rate limits and whether asOf affects cached data.

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 dense sentences with no filler, and the core capability leads before the caveats. The parenthetical clarifications (UNCHECKED, dictionary match) are compact and earn their place, though the phrasing is compressed enough that the two model modes (text vs citations) never get separated.

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 outline the verdict space (exists / title-content mismatch / UNCHECKED), which is the most important return semantics. However, with five parameters at 20% schema coverage and no output schema, the absence of any guidance on text-vs-citations inputs, threshold, and checkContent leaves real gaps for correct 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 description coverage is only 20% – only asOf is documented – so the description carries the burden and largely drops it. It hints at the law-name matching rule relevant to citations.law and repeats the base-date concept already in the schema, but says nothing about text vs citations, what threshold (0.5–1.0) controls, or what checkContent toggles.

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 concrete verb+resource pair: extract statutory/case citations from text and judge whether they actually exist and whether title/content match. That is far more specific than the bare name citation_audit, though it never names a sibling to contrast with (statute_find, precedent_trace) so the agent must infer the boundary itself.

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

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

Usage is implied rather than stated: 'audit' plus the existence/match judging makes the verify-my-citations case clear, but there is no explicit when-to-use or when-not, and no routing to the sibling lookup tools (statute_find, article_get) that an agent would otherwise consider for similar needs.

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?

The readOnlyHint annotation already establishes this is a safe read, so the bar is lower, and the description adds real context beyond it: it discloses the shape of the return (근거 조문 with 법령·조문·시행일, plus 수치·충돌·등급) and an explicit non-goal (not a legal determination). It does not cover latency, limits, or failure behavior, which keeps it from 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?

It is a single front-loaded sentence that leads with the action and input, then the output, then the disclaimer, with no filler. The eleven-item signal enumeration makes it dense, but each item is load-bearing content rather than 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?

With no output schema, the description must carry return-value meaning and it does describe the finding categories and evidence fields, which is adequate. It is thin on the remaining gaps an agent needs: what the 등급 scale means, how docType changes behavior, what maxFindings does, and how the 100k-character input limit interacts with the 200-character floor.

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 only 25% (only asOf is documented), so the description must compensate and does so only partially: it supplies the 200-character minimum for text, which the schema lacks, and its signal list loosely maps to docType. The docType enum values, maxFindings, and the overall text limit are never explained, leaving half the parameters undocumented in both places.

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 gives a specific verb (훑어/scan clause-by-clause) and a specific resource (계약서·약관 전문), and enumerates the exact signal categories it returns, so its function is unambiguous. It does not explicitly name or contrast with the sibling legal-research tools (statute_find, article_get, citation_audit), but the task is distinct enough that an agent can separate it without opening 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?

Usage is implied through the input constraint (full text of 200+ characters) and the scope exclusion '위법 판정 아님' (this is not a legal-violation verdict), which usefully tells the agent when the output should not be relied on. However, no alternative tool is named and no positive condition for choosing this over statute_find/precedent_trace is stated, so guidance stays 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?

The readOnlyHint annotation already establishes this as a safe read, so the bar is lower. The description usefully discloses the return categories and that a status signal ('후속 인용 없음/인용됨/변경 가능성') comes with its basis, but says nothing about depth semantics, result limits, or how the const depth=1 constrains output.

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 front-loaded sentence with a colon-enumerated breakdown of outputs; dense but every clause carries content. Slightly heavy as one sentence, but nothing is wasted.

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

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

With no output schema, the description does well to describe the return structure, which is its main strength. However, for a 4-parameter tool at 0% schema description coverage, the ambiguity between 'id' and 'caseNo' and the unexplained 'depth' leave an agent without enough to construct a correct call in all cases.

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 0%, so the description must carry the load. It effectively documents the three values of the 'include' parameter (outgoing/incoming/constitutional map directly to the Korean categories), but the distinction between 'id' and 'caseNo' and the role of 'depth' remain unexplained.

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 ('판례 한 건의 인용 관계를 본다' — view the citation relationships of a single precedent) and then enumerates exactly what the trace covers: outgoing references, incoming citations, Constitutional Court decisions, and the citation-status signal. This is distinct from siblings like citation_audit or source_search, so an agent can route correctly.

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

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

Usage is implied by the enumerated outputs — you would call this to inspect a single precedent's citation network — but there is no explicit when-to-use statement, no when-not-to-use, and no named alternative among the many siblings. Adequate but leaves the agent to infer the trigger.

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?

readOnlyHint=true already tells the agent this is a safe read operation. The description adds genuine behavioral context by stating the return shape (step summary plus the next call), which is a useful orchestration hint. It does not disclose what quick vs. standard budget changes, pagination, or limits on the 100k-char text input, so it stops short of rich disclosure.

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 front-loaded sentence that states the action first and the return behavior second, with no filler. The long parenthetical enumeration is dense but earns its place by listing the supported domains.

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 orchestration tool with seven parameters, 0% schema coverage, and no output schema, the description is too thin. It explains neither the required scenario/query contract nor the optional law, date, text, article, and budget inputs, so an agent cannot reliably construct a call from the description alone.

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

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

Schema description coverage is 0% across seven parameters, so the description must compensate and largely does not. It paraphrases the scenario domains in Korean, loosely aligning with the scenario enum, but never mentions query, law, date, text, article, or the budget enum values quick/standard, leaving six parameters semantically opaque.

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 function: bundling multi-step research per consultation-question type and returning a step summary plus the next call. The parenthetical enumerates the ten research domains (lease, subscription, redevelopment, brokerage, zoning, tax, contract, applicable law, statute map, amendment), which makes the scope tangible. However, it never distinguishes this orchestration tool from the many granular siblings (statute_find, article_get, source_search), so an agent cannot tell why it should pick this one.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of alternatives, despite eleven sibling tools that overlap heavily. The phrase '상담 질문 유형별' weakly implies it is for consultation-style multi-step questions, but nothing states the condition that selects this tool over calling the primitives directly.

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?

readOnlyHint already establishes the safe-read profile, and the description adds real context beyond it: the three mode behaviors (full text vs. sentence excerpt vs. law-name/term frequency) and the fact that cross-referenced provisions and precedents are returned structured. It does not, however, disclose pagination behavior (the part continuation parameter) or output size handling.

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

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

Two compact sentences with the verb and resource front-loaded, and no filler. Dense but well-organized, though the parenthetical mode explanation is slightly buried mid-sentence.

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 seven-parameter read tool with no output schema, the description covers modes and the return of structured cross-references, which is the most important behavioral detail. It leaves notable gaps: how to obtain the id, what the 20 source values mean, and how the part/maxBytes budget interact across pages.

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 43%, so the schema carries part of the load (part, caseNo, maxBytes are documented). The description usefully supplies the semantics of the mode enum values, which the schema leaves bare, but it says nothing about the 20-value source enum, the id field, or the sections array.

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 (가져온다/fetches) plus a precise resource (본문 1건, the full text of a single document) and enumerates the document categories it serves. It implicitly distinguishes itself from source_search by fetching one item rather than searching, but it never names a sibling, so an agent must infer the boundary.

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 mention of alternatives such as source_search (to find the id) or article_get (for a single article). The mode glosses hint at selection between modes, but nothing routes the agent between this tool and its ten 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 declare readOnlyHint=true, so the safety profile is already covered. The description goes beyond that by disclosing the return payload (전체 건수·ID·사건번호·일자·링크), which matters because no output schema exists. It still says nothing about pagination behavior, result limits, or per-source quirks, keeping it 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?

A single dense sentence, front-loaded with the resource list and ending with the return fields; no filler or restatement of the tool name. The source enumeration is long but each item is load-bearing for source selection, so it earns its length.

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?

This is a high-complexity tool (11 parameters, 9% schema coverage, no output schema, annotations covering only read-only safety). The description addresses return values and source types but leaves query syntax, date format (maxLength 12), pagination, sort semantics, and the meaning of org/court/region entirely undocumented, so an agent cannot call it confidently beyond the simplest case.

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 only 9% — of 11 parameters, only 'source' carries a description. The description partially compensates by mapping Korean source names onto the English enum values (헌재결정→constitutional, 조세심판→tax_tribunal, 자치법규→ordinance, etc.) and noting the max-4 parallel array form, which is genuinely useful for the one required parameter. It adds nothing for query, field, sort, page, size, org, court, region, dateFrom, or dateTo.

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?

Names a specific verb (검색/search) and enumerates the exact resource classes it covers — 판례, 헌재결정, 조세심판, 행정심판, 법령해석, 위원회 결정문, 행정규칙, 자치법규, 조약, 영문법령 — and states what it returns. The phrase '법령 외 원천' implicitly carves out non-statute material against siblings like statute_find, but no sibling is named explicitly, which is what separates a 5 from a 4.

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

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

Usage is implied by the source taxonomy: an agent can infer this is the tool for case law and interpretation material rather than statutes. However, there is no explicit when-to-use/when-not statement, no guidance on choosing it over research_run, source_get, or precedent_trace, and no prerequisites or query-construction hints.

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 supply only readOnlyHint=true, so the description carries the behavioral load and does disclose the returned fields (법령ID, MST, 법종, 시행일, 시행예정 판) plus the fact that it returns next-call examples. It omits pagination behavior despite page/size params and says nothing about rate limits, so it is good but not complete.

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 tightly-packed sentences that front-load the core action (find/filter) and then the return payload. No filler, though the parenthetical enumeration is dense and slightly hard to parse.

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 10-parameter tool with 0 required params, 30% schema coverage, no output schema, and only a readOnlyHint annotation, the description is thinner than the complexity warrants. It handles return values and the main search axes but leaves the mode/match/scope enums and pagination semantics for the agent to discover from the schema alone.

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

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

With 10 parameters and only 30% schema description coverage, the description should compensate but only covers part of it: it maps loosely to query/names (name & batch) and promulgatedFrom/To (date range). It leaves mode, match, scope, kinds, page, and size entirely unelaborated, so several enum-driven behaviors remain opaque.

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 (법령을 찾는다 = find statutes) and enumerates the modalities: name/keyword, autocomplete, batch names, and promulgation-date range. The purpose is unambiguous, but it never differentiates itself from likely-overlapping siblings like source_search or statute_outline, so an agent must still guess which search tool to pick.

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

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

Usage is only implied through the listed search modes (autocomplete, batch names, date range) rather than stated as when-to-use conditions. There is no when-not guidance and no named alternative among the ten sibling tools, leaving routing decisions 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?

readOnlyHint=true already establishes a safe read, and the description adds real behavioral information beyond it: the as-of date acts as a version-selection rule and can surface not-yet-in-force versions. It does not disclose pagination behavior, result size limits, or what happens when a law is resolved by name vs id.

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 dense sentences with the conceptual framing front-loaded and the mode breakdown following immediately; no filler. Slightly compact given the breadth of modes, but every clause carries information.

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

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

For a 12-parameter, multi-mode tool with no output schema and only a readOnlyHint annotation, the description covers the mode axis and the as-of rule but omits the role of the paired date parameters, pagination, and identifier resolution. Adequate to call, incomplete to call confidently.

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

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

Schema coverage is only 33%, so the description is expected to compensate. It does a good job on the highest-value parameter by defining each mode enum value and implying asOf semantics, but eight parameters (from, to, dateA, dateB, article, page, size, mst/lawId relationships) remain undescribed, leaving ambiguity between similar date params.

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 frames the tool as the temporal axis of legislation and then names all five operating modes (versions, article_changes, old_new, compare_dates, lineage), so an agent knows exactly what resource it operates on. It does not name or distinguish itself from siblings such as statute_find or article_get, which keeps it short of a 5.

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?

Mode enumeration implicitly tells the agent which mode to pick for a given task, and the closing sentence hints at the as-of reference-date rule. However, there is no explicit 'use this instead of X' routing against the sibling tools, and no statement of prerequisites, so usage is inferred rather than stated.

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

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

Annotations already establish readOnlyHint=true, so the safety profile is covered; the description adds a valuable negative scope claim (no body text is returned) that the annotations do not provide. It says nothing about pagination behavior despite page/size parameters, which limits 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 core action, then the four view modes in compact parenthetical form, ending with the sibling hand-off. Dense but every clause carries information; the parenthetical enum glosses make it slightly heavy for a single sentence.

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 9 parameters, no output schema and only 56% schema description coverage, the description is expected to carry more. It adequately explains the view modes and the body-text exclusion, but leaves the identifier parameters (mst, lawId, article) and paging semantics unexplained, which an agent needs to call 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 only 56%, so the description should compensate more than it does. It does gloss the four view values meaningfully (목차, 상하위 법령·행정규칙·자치법규 수, 위임 트리, 관련 법령), which maps to the view enum, but mst, lawId, article, delegationKind, page and size receive no explanation.

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 (법령 구조 요약) and enumerates the four output shapes (toc, hierarchy, delegation, related). It also draws an explicit boundary against the sibling article_get by saying body text is not included, so an agent can distinguish it without opening either 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 routes the agent to article_get when the body text is needed, which is real when-to-use guidance against an alternative. It does not say when to prefer this over statute_find or which of the four views to pick in a given situation, so it stops short of full coverage.

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, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing the three-modal structure and the set of sub-tools reachable via call. It does not explain how args are forwarded to the selected sub-tool, nor what discoverability step (describe) is needed before calling. Note a mild tension: readOnlyHint=true while call executes arbitrary sub-tools with free-form args, though the enumerated catalog tools appear read-only so this is not a hard contradiction.

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

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

A single front-loaded sentence that leads with the verb and resource, with the twelve sub-tool names packed into one parenthetical that earns its space by telling the agent what the catalog contains. Dense but not padded.

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 dispatcher with a nested free-form args object and no output schema, an agent needs to know the call flow (describe to get a sub-tool's schema, then call with args) and what each action returns. The description names the modes and catalog but omits this workflow, so it is adequate rather than complete.

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

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

Schema description coverage is 75%, so the schema already documents args, name, and query; only action lacks a schema description. The description compensates partly by binding list/describe/call to finding vs. executing, which clarifies action semantics. It adds no detail on the free-form nested args object, 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 states a specific role: a catalog dispatcher that finds (list/describe) and executes (call) auxiliary tools, and enumerates the twelve categories (legal terms, abbreviations, amendment feeds, article codes, precedents, semantic search, etc.). This makes the meta-tool nature clear. It does not, however, explicitly distinguish itself from primary siblings like statute_find or source_search, leaving the discovery-vs-direct-call relationship implicit.

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

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

The parenthetical mapping of intents to actions (list/describe for finding, call for executing) gives implied usage and the schema confirms the required action enum. But there is no explicit guidance on when to route through toolbox vs. calling a sibling tool directly, and no when-not guidance. Usage is inferable but not spelled out.

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