korea-tax-law-mcp

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety bar is low. The description still adds real behavior: the selection ordering (경과조치→적용례→당시 판→후속 개정), the fact that only clauses mentioning the article are excerpted, and that changed wording at version boundaries is appended. It stops short of describing the response shape or how many items come back beyond the schema's limit.

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 purpose, then the why, then the mechanics, then the fallback – no filler sentences. The middle sentence is long and packs several rules at once, which costs some readability but every clause is load-bearing.

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

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

No output schema exists, so the description must carry the return-value burden; it does so partially by explaining ranking order, excerpting scope, and appended wording changes. It leaves the actual returned fields unstated, but for a lookup tool with full schema coverage and clear annotations this is close to sufficient.

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 goes further by stating what period_start/period_end actually mean (event dates such as 취득·증여·양도일) and how they drive selection. It also gives the default-order behavior when they are omitted, which the schema does not convey.

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: find an article's 적용례/경과조치 in the 부칙 (supplementary provisions), and explicitly contrasts this with looking at the 조문 itself ('언제부터 적용되는지는 조문이 아니라 부칙에 있다'). The resource is distinctive enough to separate it from get_article / get_article_history, though no sibling is named outright.

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 triggering context (when you need to know from when a provision applies) and a concrete calling pattern: supply period_start/period_end as event dates. It also states a fallback when no dates are given ('날짜가 없으면 최근 공포 순'), so behavior is predictable. No explicit when-not or named alternative tool.

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, so the description's job is to add what they cannot: it discloses truncation at 6,000 characters per call and continued reading via offset. Not stated: what happens when the annex number does not exist or how the continuation value is signalled.

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?

Three short sentences, each carrying distinct information: what it returns, when to reach for it, and how paging works. Purpose is front-loaded and nothing is redundant.

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

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

For a read-only lookup with no output schema, the definition covers return content (annex body text), the reason to call it, and the pagination limit. Failure behavior on a missing or ambiguous annex number is the only notable 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 adds real meaning about offset: it exists because long tables are paginated in 6,000-character chunks, which explains how to use it rather than just what it is.

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 ties it to annex/form body text, which separates it cleanly from get_article (article text) and search_annexes (searching). An agent knows exactly what it gets back without opening the schema.

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

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

Gives a concrete triggering condition: use it when an article delegates via '별표 N에 따른다' to check tax rates or threshold amounts. That is a genuinely useful routing cue, but it never names alternatives such as search_annexes or states when not to use this tool.

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 annotations, the description discloses important behavior: no substitution of current law when the requested dated version is unloaded or unverified, explicit 'unable to confirm' handling, and a caveat that the current three-column view is not the historical version. It also notes non-tax-law handling and that citations do not confirm application.

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 front-loaded with the core purpose and every sentence appears to carry relevant legal-retrieval caveats. It is dense and somewhat run-on for the number of edge cases it covers, but it avoids redundant 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?

With no output schema, the description still explains what is returned in both current and as_of modes, including effective dates, delegated statutes, annexes, citations, effective periods, version lists, and supplementary-provision summaries. It also covers the critical unverified-date and non-tax-law edge cases, making it complete enough 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 coverage is 100%, so the schema already documents the parameters in detail. The description adds meaningful parameter behavior beyond the schema, especially the unverified-date fallback for as_of and the warning that a current three-column view in an as_of response is not the historical version.

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 uses a specific verb and resource: it returns the full original text of a particular article, and it explains the current-version versus as_of-version distinction. It does not explicitly distinguish itself from sibling tools such as get_reference_article or search_articles, so it is clear but not fully sibling-differentiating.

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 concrete usage contexts, especially for as_of when determining past fiscal years, tax periods, or refund-claim years, and states that exact rates, limits, and requirements must be confirmed through this tool. It does not name alternatives or explicitly say when not to use it, so the guidance is strong but not complete.

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 annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the description's added value is the semantic caveat: some versions are unverified and must not anchor an assertion. That is real behavioral context that the annotations cannot convey. It still doesn't say how many versions come back or whether the full history or a windowed slice is returned.

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?

Three short sentences, with the return contents stated first and the caveat last, so nothing is buried. There is no filler. The only weakness is that the trigger advice and the caveat could be tightened into one line.

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, but the description covers what the result contains (history, notation, verification flags), which partly compensates. The gap is the callable side: the required law_name/article_number formats are left entirely unaddressed, and the agent can easily supply the wrong shape. This is adequate but incomplete for a two-required-param lookup.

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%, so the description should carry the burden for law_name and article_number, but it says nothing about expected formats (for example, whether article_number is '3' or '제3조'). The phrase '특정 조문' only implies what the parameters are, without giving an agent enough information to fill them in reliably.

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 (returns) and a well-scoped resource (revision history of a specific article), and it enumerates what the payload contains: version history, revision notation, verification/source status. It does not explicitly distinguish itself from get_article (current text), but the scope is clear enough that an agent can tell the two 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?

The description names the trigger question ('when did it change') directly, so the agent knows when this tool is the right call. It also adds an exclusion ('don't use unverified versions for definitive application'), which is useful usage guidance. It stops short of naming an alternative tool for current text.

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, closed-world), and the description adds genuine behavior: it expands up and down the delegation chain, bundles annex forms tied to the article, and flags non-tax laws with a '세법 아님' marker. It does not discuss resolution limits or what happens when no tier linkage exists, 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?

The three-tier return is front-loaded in the first sentence, followed by input flexibility, annex forms, and the non-tax-law caveat — each sentence carries distinct information. It is dense but nothing is redundant.

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

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

With no output schema, the description does the work of describing the return shape (three tiers, annex forms, non-tax marker), which is the key thing an agent needs. Missing only edge-case behavior such as articles with no decree/rule counterpart.

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: law_name may point at a decree/rule level and article_number still resolves the surrounding tiers, which is not obvious from the schema alone. The 약칭 acceptance is only echoed from 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 action (3단으로 반환한다) and a specific resource (법률·시행령·시행규칙 조문 본문), plus a concrete extra output (별지 서식). An agent can tell it is the multi-tier/expanded lookup rather than a plain article fetch, although no sibling is named outright to sharpen the contrast with get_article or get_reference_article.

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 useful applicability cues: it works even when you pass an enforcement-decree or enforcement-rule article ('시행령·시행규칙 쪽 조문을 넣어도 위아래를 찾는다') and it covers non-tax referenced laws. However, it never states when NOT to use it or which sibling to prefer for a single-law article, so the routing decision is left 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds that what comes back is the raw DB source text (원문) rather than a summary, which is useful context. It says nothing about truncation or paging despite a 12000-character default limit, which matters for a full-text reader.

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, front-loaded with the operation and followed by the coverage list; nothing is redundant. It is terse to the point of omitting behavioral detail, but there is no 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?

An output schema exists so return values need not be explained, and annotations cover the safety profile. Yet for a 5-parameter full-text retrieval tool with a default 12000 / max 24000 character limit, the absence of any note on truncation, paging, or how this generic getter relates to the type-specific siblings leaves gaps an agent would hit in practice.

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 source_field has a description), so the description carries real weight here and does help by glossing evidence_type values in Korean (판례=case, 해석례=interpretation, 예규=ruling, 통칙=basic_rule, 별표=annex, 부칙=amendment, etc.). However, evidence_id format, limit, offset, and source_field are left entirely to the schema, and source_field is not mentioned 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?

States a specific verb (reads the raw DB text) plus the resource (evidence original text), and enumerates the nine supported evidence categories, which maps directly onto the evidence_type enum. It never distinguishes itself from the type-specific siblings (get_article, get_annex, get_treaty_article, get_article_history), so an agent cannot tell from the text alone when this generic getter beats the specialized ones.

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: 'reads the raw original text' suggests calling it after a search when full text is needed, and the type list hints at coverage. There is no explicit when-to-use, no exclusion, and no naming of alternatives such as get_article or get_annex, which overlap heavily.

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, so the bar is lower, yet the description adds substantive behavior: as_of returns the version in force on that date, coverage begins at 2016-01-01, and out-of-range dates are refused rather than silently resolved to the current text. That refusal rule and the tax-law rejection are exactly the failure modes an agent needs to know about.

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?

Three sentences, front-loaded with the resource scope, then the temporal rule, then the tax-law caveat — each earns its place. The long statute enumeration is lengthy but functions as a scope boundary, so it is defensible 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?

For a single-article retrieval tool with no output schema, the description covers scope, temporal range, known limitation, and the non-tax restriction that define correct use. It does not say what happens for an unknown law name or nonexistent article, a minor remaining 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; the description still adds meaning by explaining the temporal semantics of as_of (version in force, 2016 floor, no substitution with current law) and by reinforcing that law_name rejects tax-law names. article_number syntax is left entirely to 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 and resource: returns provisions (조문) of non-tax reference statutes, with an explicit enumeration of which statutes count. It also draws the boundary against the tax-law siblings ('세법 아님', '세법 이름은 받지 않는다'), so an agent can distinguish it from get_article/search_tax 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?

Gives clear when-to-use (non-tax statutory provisions, optionally as of a date) and when-not (tax-law questions must be confirmed against tax provisions separately), plus a hard coverage cutoff before 2016-01-01. It stops short of naming the specific fallback sibling tool, leaving the agent to infer that the tax route is get_article/search_tax.

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?

Goes well beyond the readOnly/idempotent annotations: discloses the data source (관보 원문 대조), the coverage start date, the exact fields returned (효력일·공고일·공고번호·범위·관보 출처), and the deliberate '부분 지정' behavior when 읍면동·지구 단위 공고 applies rather than guessing. That is exactly the kind of result-shaping behavior an agent needs before calling.

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 resource and scope, and each following sentence adds distinct value (caveat about 부분 지정, redirect to tax-law sources). It is dense and slightly long as a single block, but nothing is redundant.

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

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

With no output schema, the description carries the return-shape burden and does so by enumerating the fields and their meaning. Combined with annotations covering safety, an agent has everything needed to call it and interpret the answer 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; the description still adds value by explaining what as_of actually governs (the designation state as of that date, defaulting to today) and by tying partial-scope designations to that evaluation. The region granularity '시군구별' also clarifies expected input shape beyond the schema 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 verb and resource — returns the designation/release history of 조정대상지역·투기과열지구·투기지역 by 시군구 — plus scope boundaries (since 2017-08-03, based on 관보 원문, explicitly '세법 아님'). The 'not tax law' framing separates it cleanly from the tax-law siblings like get_article/search_tax.

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?

Clearly says when to use it (historical designation status as of a given date) and when not to (중과·거주요건·계약 예외 등 세법 효과는 세법 조문으로 확인), which routes the agent elsewhere. It stops short of naming the specific sibling tool to use instead, so the redirect requires inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful context beyond that — the return is bilingual full text — and imposes a verification obligation for exact numbers. It does not say what happens for a missing country/article or how large articles are handled, so it stays at adequate rather than rich.

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 with zero waste: the return content comes first, the verification rule second. Nothing is repeated from the schema or annotations.

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 correctly states what comes back (full article text, Korean and English) and when to trust it over other sources. Only the empty/not-found case is unaddressed, which is a minor gap for a two-required-param read tool.

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

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

Schema coverage is 100% and both parameters carry their own descriptions with examples ('미국', '제12조'/'12'), so the schema does the work. The description adds nothing about accepted country-name forms or article-number formats beyond what the schema already states; 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 verb and resource: returns the full original text of a given country's tax treaty article, in both Korean and English. The '특정국 조세조약' qualifier separates it from domestic-law siblings like get_article, but it never explicitly names or contrasts those siblings, leaving the agent to infer the treaty-vs-statute split.

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 an explicit use condition: for precise figures such as 제한세율 (limited tax rates), the original text must be confirmed with this tool. That is a real routing directive rather than implied usage, though it offers no exclusion or named alternative for broader article lookups.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds what the response contains — current statutes plus effective dates and a separate non-tax reference section. It does not describe ordering or pagination, but the payload is a simple inventory.

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?

Four short sentences, with the core purpose front-loaded and the usage hint last — no filler. Slight redundancy between the current-only statement and the historical-exclusion statement, but both sharpen scope.

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, and the description compensates by describing the returned content, including the separate non-tax reference section. No parameters need explaining, so an agent has enough to call this correctly, though the return shape is described only at a high level.

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?

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline is 4. The scope statements still clarify what the implicit 'unfiltered listing' means.

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: returns the list of current tax statutes (법률·시행령·시행규칙) with effective dates stored in this DB. It also demarcates scope precisely — current versions only, historical laws excluded — which effectively separates it from history-oriented siblings like get_article_history.

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 closing line explicitly says to use it to confirm coverage before using other tools, which is a clear usage context. The exclusion of historical laws implies when not to rely on it, though no alternative tool is named for that case.

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=false, so the safety profile is covered. The description adds useful behavioral detail absent from annotations: what each call mode returns, including effective dates. With no output schema, this return-content disclosure is genuinely valuable.

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 sentences, zero waste, with the resource statement front-loaded and the mode behavior immediately after. Nothing is redundant or 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 single-optional-parameter read tool with annotations covering the safety profile, the description supplies everything an agent needs: what is returned in each mode. With no output schema required, nothing material is missing.

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

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

Schema coverage is 100% and the country parameter is already documented in the schema. The description still adds value by spelling out the consequence of omitting country (full partner list) versus supplying it (treaty, protocol, and exchange-of-notes list plus effective dates), clarifying the mode switch beyond the schema.

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

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

The description states a specific verb (returns) and resource (Korea's concluded tax treaties, listed status), and it distinguishes the two call modes clearly. It does not explicitly name the sibling search_treaties to differentiate list vs. search, so it stops 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?

It gives concrete usage context: call without country for the list of treaty partners, with country for that country's instruments and effective dates. No explicit exclusions or alternatives (e.g., search_treaties) are named, so it is clear context without 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the shape of the return payload (enforcement date, law, list of changed articles), which no annotation provides. Pagination and empty-result behavior are still unstated.

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?

Three compact sentences/fragments, front-loaded with the definition before the usage rationale, with no filler. The middle fragment is telegraphic ('시행일·법령·달라지는 조문 목록') but it earns its place by conveying the return fields.

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 one-parameter, annotation-covered, read-only list tool with no output schema, the description covers purpose, payload contents, and the decision context that motivates a call. Only edge cases (no results, volume of results) are left out.

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

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

Schema coverage is 100% and the single law_name parameter already documents partial-match behavior including 시행령·시행규칙. The description adds nothing about the filter, 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?

States a precise verb and resource: returns amendments that are promulgated but not yet in force (시행예정), and names the returned fields (시행일·법령·달라지는 조문). The scoping distinguishes it in practice from get_amendments, but the sibling is never named explicitly, so an agent must infer that 'amendments' means already-in-force changes.

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 an explicit usage trigger: questions involving future tax periods, where answering from current articles alone would be wrong. It stops short of saying when NOT to use it or pointing to get_amendments as the alternative for in-force amendments.

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=false, so the safety profile is fully covered. The description adds only a content hint (annexes hold tables rather than article prose); it says nothing about result shape, ranking, or what happens at the limit cap. With annotations doing the heavy lifting, this is adequate but thin.

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 sentences, purpose front-loaded, followed by a single justifying sentence with compact parenthetical examples. No filler or repetition of schema/annotation content.

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 3-parameter read-only search with no output schema, the definition gives enough to call it correctly and to know why annexes matter. Minor gaps remain: no indication of what a hit looks like or how annex results relate to their parent law, which matters for a full-text search tool.

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

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

Schema description coverage is 100% — query, law_name (부분 일치), and limit (기본 5, 최대 15) are all documented in the schema. The description adds no meaning about search semantics (e.g., whether query matches table titles only or cell contents), 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?

States a specific verb and resource (법령 별표·서식을 전문검색한다) and implicitly differentiates from article search by explaining that rate tables, thresholds, limits, and classification tables live in annexes rather than 조문. It never names the sibling tools (search_articles, get_annex), so routing still requires the agent to infer which sibling to avoid.

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 a clear use context: reach for this when the value sought is a tax-rate table, threshold, cap, or classification table, with two concrete examples (간이세액표, 면세 미가공식료품 분류표). It does not state exclusions or name alternatives such as search_articles for narrative text or get_annex for retrieving a single annex by ID.

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 annotations already establish that this is a safe, read-only, idempotent, closed-world operation. The description adds that it searches current tax law articles via full text and gives keyword guidance, but it does not explain result ordering, pagination behavior, or what the response contains.

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 short and front-loads the main purpose before giving query tips and the law_name filter. It is efficient, though one sentence partially repeats information already present in the schema.

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

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

For a simple three-parameter search tool with full schema coverage and safety annotations, the description covers the essential purpose, query style, and filtering option. It does not describe return values, but no output schema exists and the core calling information is present.

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

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

Schema description coverage is 100%, so all three parameters are already documented. The description adds examples and a no-particle keyword nuance, but it largely repeats the schema's query and law_name descriptions rather than adding substantial new parameter semantics.

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: full-text search of current tax law articles. It is clear enough to distinguish from retrieval tools like get_article, though it does not explicitly differentiate itself from the sibling search_tax tool.

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

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

It gives useful query-formulation guidance, such as using noun-oriented keywords without particles and limiting by law_name. However, it does not explicitly say when to use this tool instead of alternatives like search_tax or get_article.

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 closed-world, so safety is covered. The description adds genuinely non-obvious behavior: case-number queries are hoisted to the front with 주문·원심·환송 후 판결 appended. The caveat that keyword hits are unverified against current law is a valuable reliability 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?

Three sentences, all load-bearing: scope enumeration, query-form guidance, and the citation caveat. The most decision-relevant information (what corpus this searches) is front-loaded with no 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?

For a 2-parameter read-only search with no output schema, the description covers scope, query construction, ranking special-cases, and a caveat about result validity. Only a hint about result shape/pagination is missing, which is minor given annotations and the simple surface.

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 50% — limit is documented in-schema but query is not. The description compensates by explaining query semantics (single keyword preferred, case-number format with two concrete examples). It does not discuss limit, but that gap is already filled by the schema.

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

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

The description opens with a specific verb+resource ("판례·불복 결정례를 전문검색한다") and then enumerates exactly which corpora are covered (court precedents, Tax Tribunal decisions, NTS 심사청구/이의신청/과세전적부심사). This clearly separates it from sibling search tools like search_articles, search_interpretations, and search_tax.

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 concrete usage guidance: a single core keyword works best, and a case number (with example formats 2015두41937, 조심2020서8493) triggers special ranked behavior. It also warns that keyword hits are not verified citations to current statutes. It stops short of naming a sibling as the alternative for those cases, so 4 rather than 5.

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

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

With annotations already covering read-only and idempotent behavior, the description adds useful behavioral detail: document-number queries return that document first, and keyword hits should not be treated as verified citations. It does not describe rate limits or output structure, but it provides meaningful context beyond the annotations.

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

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

Three sentences, front-loaded with the core purpose, then usage, query behavior, and a reliability caveat. Every sentence adds useful information without repetition.

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

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

For a two-parameter search tool with no output schema, the description gives enough guidance to invoke it correctly and understand the key caveat about citation verification. It could say more about the shape of returned results, but the essential invocation context is 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 coverage is 50%, with limit documented in the schema but query undocumented there. The description compensates well by explaining that query can be an issue sentence or a document number and by describing the resulting ranking behavior when a document number is used.

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: full-text search of interpretation cases from the National Tax Service, Ministry of Government Legislation, and Ministry of Public Administration and Security. This distinguishes the source material from sibling tools like search_cases or search_articles, though it does not explicitly name those 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?

It gives a clear usage context: confirming the tax authority's position on practical issues. It also explains that either an issue sentence or a document number can be used, and warns that keyword hits are not verified citations to current statutory provisions. It does not explicitly route users to alternatives such as verify_citations, but the context is clear.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds real behavioral context: this is full-text (전문검색) matching over non-tax statutes only, which tells the agent what kind of matching to expect and that tax-law hits will not appear here.

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 sentences, front-loaded with the scope constraint and followed by the use case. The parenthetical example list is compact and directly supports routing decisions, so no sentence 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?

For a 3-parameter, fully documented read-only search with annotations, the description supplies domain scope and intent. It could say slightly more about what a hit contains (law name, article number) or result-ordering, but nothing essential to calling it correctly is missing.

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

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

Schema description coverage is 100%, with limit defaults/max, query phrasing advice, and law_name examples all documented in the schema. The description adds nothing parameter-specific, so the baseline of 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 verb+resource ('비세법 참조 법령 조문을 전문검색한다') and explicitly narrows scope with '(세법 아님)', which implicitly separates it from the tax-law search siblings like search_articles and search_tax. It does not name a sibling directly, so it stops 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?

The second sentence gives concrete when-to-use context: verifying premises behind real-estate and inheritance/gift tax issues (inheritance shares, rental-business registration, management-disposal approval, housing definitions). It lacks an explicit negative rule or a named alternative for the tax-law case, but the domain boundary is clear.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive, closed-world), the description discloses substantive behavior: delegation is followed a maximum of 2 hops from law articles, results carry effective date/applicable version/unconfirmed status, the traversal path is summarized as graph_route, and results without full text fall back to a table of contents (not_shown). These are non-obvious traits an agent could not derive from the annotations alone.

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?

Three dense sentences with the core operation stated first, followed by collection scope and return contract. Every sentence carries information, though the return-value sentence is long and packs several distinct concepts (number/title, original text, effective date, unconfirmed status, graph_route, not_shown) into one clause chain.

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 an output schema present and 83% parameter coverage, the description covers what the agent still needs: the composite traversal model, its depth limit, and the not_shown fallback. Remaining gaps — pagination continuity and the result_set_id contract — are handled by the schema, so the description is largely complete for a tool of this complexity.

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

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

Schema coverage is 83%, so the baseline is 3, but the description adds real semantics beyond the schema: it explains that 'law' entries act as starting articles from which delegation is followed two levels, while other intent types are supplemented by full-text search — behavior the schema's bare string arrays do not convey. The detail/limit/pagination parameters are left to the schema, which already documents them well.

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 operation and scope: an integrated graph traversal that starts from law articles and collects cases, rulings, interpretations, reference articles, 통칙, supplementary-provision bases and annexes, supplemented by full-text search. It is clear what the tool does, but it never explicitly distinguishes itself from siblings such as search_articles, search_cases or search_interpretations, so an agent must infer that this is the multi-type composite variant.

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 phrases like '한 번에 모으는' and '전문검색으로 보충한다', suggesting this is the tool for gathering all grounds of a tax issue at once. However, there is no explicit when-to-use/when-not guidance and no routing statement telling the agent to prefer a narrower sibling search when only one source type is needed.

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, non-destructive, and closed-world, so safety is fully covered without the description. The description adds domain framing (treaty article search, optional country narrowing) but says nothing about result shape, ranking, or what happens when limit is exceeded beyond the schema's own note.

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?

Three short sentences, verb-and-resource first, then use cases, then the optional filter. Every clause carries information an agent needs to decide or to query; nothing is repeated from structured fields.

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 read-only search tool with full schema coverage and no output schema, the description covers what is searched, why, and how to narrow it. The only gap is result-set behavior (ordering, pagination beyond limit) and explicit sibling disambiguation.

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%: query examples (사용료, 고정사업장, 배당 제한세율), limit default/max, and country partial-match are all documented in the schema. The description's 'country로 특정국 한정 가능' only restates the existing country parameter, adding no new syntax or semantics — 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 verb (전문검색) and resource (조세조약 조문), and the parenthetical 이중과세방지협약 removes ambiguity about which treaties. It does not name the nearest siblings (search_articles, get_treaty_article), so an agent must infer the boundary, but the resource is distinctive enough to be actionable.

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 concrete use cases — 원천징수 제한세율 for 비거주자·외국법인, 고정사업장, and 사용료·배당·이자 과세권 — which tell the agent what question shapes select this tool. No explicit exclusions or named alternatives, and the country filter is offered as a refinement rather than a routing condition.

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 read-only, idempotent, non-destructive behavior, so the description does not need to repeat safety claims. It adds useful behavioral context: title_check semantics, unchecked/unresolved_articles meaning, found_reference for non-tax statutes, and the limitation that body-text consistency is not verified.

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

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

The purpose is front-loaded and the paragraph is dense with necessary distinctions rather than filler. It is somewhat long, but the length is justified by the variety of citation formats and result labels it must cover.

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 verification tool with no output schema, the description explains scope, key output labels, and important limitations well. It still leaves some gaps around result structure and how max_citations truncation is surfaced, but it is substantially 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 coverage is 50%: the 'text' parameter is well documented in both schema and description, including citation formats and article enumeration handling. However, the description never mentions 'max_citations' or truncation behavior, leaving half the parameter set to the schema alone.

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 (문서번호와 조문 인용) with concrete citation examples. It clearly distinguishes verification from content matching ("본문 내용 일치 확인은 아니다") and from sibling search tools.

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 explains the intended context (draft answers/opinions) and what it is not for (content match verification), plus how to interpret unchecked/unresolved results. It does not explicitly name alternative sibling tools such as search_cases or search_interpretations for follow-up, but the usage boundary is clear.

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