korea-tax-law-mcp

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

No annotations are provided, so the description carries the full burden. It states the core behavior (returns body text) and implies read-only by using the verb '반환한다'. However, it doesn't disclose any additional behavioral details such as error handling, output format, or whether any side effects exist. For a simple read operation this is adequate, but the lack of explicit read-only declaration or output description keeps it at a minimum.

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 two sentences with no wasted words. The first sentence states the action, and the second gives the use case. Information is front-loaded, making it easy to scan.

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

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

Given the tool's simplicity (2 parameters, no output schema) and high schema coverage, the description covers the essential purpose and usage context. It lacks mention of return format or error cases, but for a basic retrieval tool, these are minor and not critical. The description is complete enough for an agent to decide when to invoke it.

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 both parameters (law_name, annex_number) fully described including examples. The tool description does not add any additional meaning beyond what the schema already provides, so the baseline score 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?

The description clearly states the tool returns the body text of a specific annex or form ('특정 별표·서식의 본문을 반환한다'), specifying both the verb and the resource. It also explains the context ('조문이 '별표 N에 따른다'로 위임한 세율·기준금액을 확인할 때 사용'), which differentiates it from siblings like get_article and search_annexes.

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 explicitly states when to use the tool: when an article delegates checking tax rates or standard amounts to an annex. This provides clear context, but it does not mention alternatives or when not to use it. Thus it's clear but lacks exclusions.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses that the operation returns the current full text, including enforcement dates and delegated subordinate statute provisions. This goes beyond a generic 'get article' statement and clarifies the read-only nature without needing 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?

Two sentences, no filler, with the core purpose front-loaded and the accuracy directive in the second sentence. Every clause earns its place.

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

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

For a simple two-parameter read operation with no output schema, the description is complete: it states what is returned, the full current text, and what it includes. It gives the agent enough to call it correctly and to treat the result as authoritative for numeric details.

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 fully documents law_name and article_number with examples. The description does not add new parameter-level meaning, though it reinforces that the returned text is the authoritative source for precise figures. This meets the baseline but does not exceed it.

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 entire current original text of a specific article.' The phrase '현행 원문' differentiates it from history tools, and the inclusion of '위임 하위법령 조문' clarifies scope beyond a bare article lookup. It is clearly distinguishable from siblings like get_article_history, search_articles, and get_treaty_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?

Explicitly instructs that exact figures such as tax rates, limits, and requirements must be verified using this tool. This gives a clear when-to-use directive. It does not explicitly name alternatives or when not to use it, but the context is sufficient for an agent to route correctly.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that history/version information is returned, but it does not describe the output structure, ordering, whether the current version is included, or any side effects. This is minimal for a tool with no annotation support.

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

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

The description is a single sentence that front-loads the operation and result, then states the targeted question type. There is no filler or redundancy; every part earns its place.

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

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

For a simple two-parameter retrieval tool, the description gives the core idea and a usage signal. However, with no output schema, it should more explicitly describe the shape of the returned history and clarify parameters. It is minimally viable but leaves meaningful gaps.

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 must compensate for the missing parameter documentation. It only says "특정 조문" (specific article), which loosely maps to article_number, but gives no format guidance for law_name or article_number and no clarity on exact accepted values.

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

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

The description clearly states a specific verb and resource: it returns the amendment history (version history, amendment notation) of a specific article. This distinguishes it from get_article, which would return the current article text, and from search_articles, which searches rather than fetches 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 phrase "'언제 바뀌었나' 질문에 사용" explicitly identifies when to use the tool: for questions about when an article changed. It does not name alternatives or explicitly exclude get_article, but the use case is clear enough for an agent to route correctly.

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 no annotations, the description carries the full behavioral burden. It discloses return content (full original text, bilingual KO/EN) and asserts the tool's authoritative role, but it does not state what happens on invalid country names, missing treaty partners, or nonexistent article numbers, and the read-only nature is only implied by 반환한다. Adequate but with a clear gap around edge-case and failure behavior.

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, both earning their place: the first states the core function, the second adds a task-level usage directive. Function is front-loaded and there is zero redundant or filler 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 simple 2-param read-only retrieval tool with no output schema, the description covers the main essentials: what is returned (full original article text), in which languages, and the authoritative use case. Minor gaps remain: no error/not-found behavior, and no workflow hint that list_treaties/search_treaties should be used first to discover treaty names.

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% — both country (체결국 한글명 with example '미국') and article_number (조번호 with examples '제12조', '12') are already documented with formats and examples. The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 is correct.

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 first sentence names a specific verb (반환한다/returns), resource (특정국 조세조약의 조문 원문 전체/full original article text of a specific country's tax treaty), and scope (Korean and English versions). It clearly distinguishes from siblings like get_article and get_annex through the explicit 'tax treaty' framing, though it does not explicitly name or contrast any sibling.

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 provides an explicit when-to-use directive: '제한세율 등 정확한 수치는 반드시 이 도구로 원문을 확인할 것' — agents should route to this tool for authoritative verification of precise figures. However, it offers no when-not-to-use guidance or alternatives (e.g., search_treaties for discovery or get_article for non-treaty articles).

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?

No annotations are provided, so the description carries the full behavioral burden. It clearly states that the tool returns a list and effective dates, and notes the 'current' scope, but it does not disclose output format, limitations, or other behavioral traits. The behavior is simple enough that this is acceptable but not 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 no wasted words. The first sentence states the function and return content; the second states the intended usage context. The key information is front-loaded.

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 zero-parameter listing tool with no output schema, the description is sufficiently complete: it names what is returned, the scope, and the intended use. It could specify the exact output structure, but that is minor for such a simple 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?

The tool has zero parameters and the schema already covers 100% of the parameter surface, so the baseline is 4. The description adds no parameter-specific meaning, but none is needed.

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 clear resource: the list of current tax law statutes (acts, enforcement decrees, enforcement rules) along with their enforcement dates. This clearly distinguishes it from sibling tools like list_treaties and list_upcoming.

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 explicitly frames the tool as a scope-checking step to use before other tools, which gives clear when-to-use context. It does not explicitly name alternatives or exclusions, but the intended placement in a workflow 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?

With no annotations, the description carries the full burden and does disclose the key behavioral trait: it returns a country list or a filtered treaty list with effective dates. It wisely uses '반환한다' (returns), implying a read-only operation, though it does not discuss edge cases, ordering, or data freshness.

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

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

The description is a single compact sentence that front-loads the main purpose and then cleanly explains the conditional behavior. Every phrase conveys useful information with no redundancy or 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 tool with one optional parameter and no output schema, the description is nearly complete: it covers both invocation modes and names the returned treaty list and effective dates. It could go slightly further by specifying output shape or sort order, but the high-level return behavior is sufficient for reliable tool selection.

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 input schema already documents the optional country parameter, its expected Korean-name format, and the behavior when omitted, with 100% schema description coverage. The description restates the parameter's effect but does not add meaningful new semantics beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly identifies a specific resource (tax treaties concluded by Korea) and describes the two distinct output behaviors based on the country parameter. However, it does not explicitly differentiate this tool from sibling tools like search_treaties, so it misses the top tier.

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

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

The description provides clear usage context by specifying what happens when country is omitted versus supplied. It does not mention alternatives or exclusion conditions, but for this simple list tool the two calling modes are effectively practical 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?

With no annotations, the description carries the transparency burden and does a good job: it discloses the temporal scope (promulgated but not yet effective), the returned content (effective date, law, changed provisions), and the intended verification role. Minor details like ordering or default scope when law_name is omitted are not covered, but they are not critical for this simple read-only list.

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

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

The description is compact and front-loaded: the first sentence states the core behavior, the second lists the returned fields, and the third gives the use case. Every sentence adds distinct value, and there is no redundant wording.

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

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

For a simple one-optional-parameter list tool, the description covers what is returned, the temporal state of the data, and when to use it. It does not include a formal output schema, but it does summarize the return contents, making the tool adequately complete for an agent to invoke 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?

The schema already documents the only parameter, law_name, with a filter description and an 'omitted means all' note, so schema coverage is 100%. The tool description adds no additional parameter-specific semantics, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource: it returns amendments that have been promulgated but are not yet in force, with effective date, statute, and changed provisions. It also distinguishes this tool from current-law lookups by warning not to rely on current provisions for future tax periods.

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 explicitly states when to use the tool: for questions involving future tax periods, as a confirmation check before answering from current provisions. It clearly implies the exclusion of current-only tools, though it does not name sibling alternatives explicitly.

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?

No annotations are provided, so the description carries the behavioral burden. It discloses that the search is full-text over annexes/forms and explains the domain, which is useful. However, it does not describe result format, ordering, pagination, or permissions, though these are less critical for a read-only search tool.

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: the first states the core purpose, the second adds high-value clarification with real examples. No wasted words and the key differentiator is visible immediately.

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 search tool with three well-documented parameters and no output schema, the description conveys what it searches, why it exists, and when it is the right tool. It could mention how to retrieve the full annex after finding it, but that is not essential 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 100%, with each parameter already documented in the input schema. The description adds domain-specific examples for what to search for, but it does not add meaning beyond the schema; 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 action ('전문검색한다') and a clear resource ('법령 별표·서식'). It also gives concrete examples of what kind of content lives in annexes, which sharply distinguishes it from article-centric 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 clearly tells the agent when to use this tool—when searching for tax tables, standard amounts, limits, and classification tables that appear in annexes rather than articles. It does not explicitly name alternatives like search_articles or state 'do not use for article text', so it is strong but not fully explicit.

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

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

No annotations are provided, so the description carries the full disclosure burden. It explains search behavior (full-text), the current-law scope, and important query behavior—keyword accuracy improves with nouns without particles—with concrete examples. It does not describe the return shape, but the disclosed behavioral details are genuinely useful for invocation.

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 no filler. The main purpose is front-loaded, followed immediately by actionable search tips and a filter option. Every sentence earns its place.

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

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

For a 3-parameter search tool with no output schema, the description covers the domain, query behavior, and filtering. It does not describe the return format, but the examples and sibling tools like get_article make the intended workflow reasonably clear. Slightly more detail on what results contain would make it fully 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 100%, so the baseline is 3. The description adds meaningful beyond-schema guidance for query semantics (noun-based keywords, particle avoidance, examples) and confirms law_name's limiting role. limit is left to the schema, which is acceptable.

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: '현행 세법 조문을 전문검색한다' (full-text search of current tax law provisions). This clearly distinguishes it from sibling tools like search_cases, search_interpretations, and search_treaties by scope and resource type.

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 gives clear context: full-text search over current tax statutes, with law_name as a filtering option. However, it does not explicitly state when to prefer this tool over siblings such as get_article for known article lookups or search_interpretations for interpretive materials. Usage conditions are implied but not explicit.

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

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

No annotations are provided, so the description carries the burden. It discloses the search scope and the 150k+ document corpus, and hints at behavior with '단일 핵심 키워드가 정확함' (single core keyword is accurate), which implies multi-token natural-language queries may be less reliable. However, it does not disclose return format, pagination, sorting, or what happens with empty/no results. For a read-only search tool this is somewhat adequate but not fully transparent.

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 main purpose and scope, and a useful usage hint. No filler. Could include a bit more guidance on result behavior, but it is concise and structured well for quick parsing.

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 search tool with two params and no output schema, the description covers the core purpose, scope, and a usage tip. Gaps remain: no explicit when-to-use-vs-siblings, no mention of result format or pagination, and no exclusion of administrative rulings vs court cases. It is minimally viable but not fully complete for an agent to predict response behavior.

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 50%: 'limit' has a description (default 5, max 15), but 'query' has no description. The description adds context that 'query' should be a single core keyword for best accuracy, which partially compensates. However, it doesn't specify the expected language, format, or how limit behaves beyond the schema. 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 explicitly states this tool searches case precedents and Tax Tribunal decisions, with a scope (Supreme Court/High Court cases, Tax Tribunal rulings, 150k+ documents) that distinguishes it from sibling search tools (search_articles, search_treaties, search_interpretations). It includes a usage note about single core keyword precision. It could be improved by naming sibling alternatives more directly, but the resource and verb are clear.

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 gives an implied usage guideline: a single core keyword is accurate, suggesting this tool is best for focused keyword searches rather than broad queries. However, it does not explicitly say when to choose this tool over siblings like search_interpretations or search_annexes, nor does it state exclusions or alternative tools. The context is clear but not fully elaborated.

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?

There are no annotations, so the description carries the burden of disclosing behavior. It transparently frames the operation as a read-only full-text search and adds corpus scale (14만+건). It does not mention return shape or rate limits, but the search nature is clear and not misleading.

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 clauses with no filler: the first states the action and resource, the second states the use case. The most important information is front-loaded.

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, the description covers the essential invocation context: what is searched, how it is searched, and why it is used. A note about result fields would be helpful since no output schema exists, but nothing critical is missing for selecting and calling the 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?

The schema describes 'limit' with default and max values, but 'query' has no schema description. The description's '전문검색' clarifies that query is the full-text search expression, partially compensating for that gap. It adds no detail about the limit behavior beyond what the schema already provides.

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 '전문검색한다' (full-text search) and names the exact resources: 국세청 질의회신 and 법제처 해석례. This clearly differentiates the tool from sibling search tools like search_cases or search_articles even without explicit contrast.

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 states the intended use: confirming the tax authority's position on practical issues (실무 쟁점의 과세관청 입장 확인). This provides clear context for when to choose this tool, though it does not explicitly state when not to use it or name alternative tools.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses a meaningful limitation: the main text may not reflect amending protocols, so verification via list_treaties is needed. This is beyond schema information, though it does not cover every possible behavior such as result ordering or rate limits.

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 with no filler: core purpose, then use cases, then the caveat and alternative tool. Information is front-loaded and every sentence earns its place.

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

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

For a search tool with 3 documented parameters and no output schema, the description covers what to search, why, the optional country filter, and an important data-freshness caveat. It is slightly less complete on result shape, but nothing essential to invoking 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%, so the schema already documents query, country, and limit. The description adds only a modest clarification that country restricts to a specific nation, but no new parameter semantics 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 opens with a specific verb and resource: full-text search of tax treaty articles (조세조약 조문 전문검색). It clearly distinguishes itself from sibling search tools like search_articles and search_annexes by targeting treaties and names concrete use cases such as withholding tax rates and permanent establishment rules.

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 explicit when-to-use context (limitation rates, PE, royalties/dividends/interest taxation) and an explicit alternative: list_treaties for treaty history because the main text may not reflect amending protocols. This provides clear guidance for selecting this tool over alternatives.

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