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?

There are no annotations, so the description carries the behavioral burden. It adds useful context beyond a simple 'returns text' by specifying that the result includes effective date, verified delegated statutes, appendices, and verified citations, and cautions that citations are not confirmed application. This gives the agent a realistic picture of the returned content, though it does not address edge cases or failure modes.

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 well-structured sentences. The main functionality is front-loaded, followed by a clear usage directive and a caveat. Every sentence earns its place with no filler or redundant restatement.

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?

The tool is simple (2 required params, no output schema), and the description sufficiently explains what is returned and the reliability caveat. It is complete enough for an agent to call the tool correctly, though it could optionally mention the difference from treaty articles or historical versions for even stronger 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%, so the schema already documents law_name and article_number with examples. The description does not add any parameter-specific details beyond the schema, matching the baseline score of 3.

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 (returns the entire current original text) and a specific resource (a particular article of a law), and enumerates the included components (effective date, verified delegated laws, appendices, verified citations). This distinguishes it from obvious siblings like get_article_history or get_treaty_article without needing 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?

The description explicitly tells the agent when to use this tool: '정확한 수치는 반드시 이 도구로 원문을 확인할 것' (must verify exact figures with this tool). It also warns that citations are not confirmed as applicable. It does not name specific alternatives or state when not to use it, so it falls just short of full exclusion 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 provided, the description carries the full burden and it does meaningful work: it discloses that the result contains verification/source status and warns that unverified versions must not be used to assert application. This is valuable behavioral context beyond what the name or schema conveys.

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 fluff. The first sentence front-loads what the tool returns, and the second adds a precise usage cue and a critical safety warning. 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?

Given the low complexity of two self-named parameters and no output schema, the description covers the key facts: what is returned, when to use the tool, and a data-quality constraint. It could be more complete with output structure or parameter format examples, but it is sufficient for an agent to invoke the tool correctly in most cases.

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

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

Schema description coverage is 0%, so the description must compensate, but it only refers generically to 'a specific article' and adds no format, examples, or disambiguation for law_name or article_number. The parameter names are self-explanatory, yet no additional semantics are provided to help with edge cases or value formatting.

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: it returns the amendment history of a specific article, including version history, amendment notation, and verification/source status. This clearly differentiates it from siblings like get_article, which presumably returns current article text, and search_articles, which searches rather than returns 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 description explicitly says to use this for 'when did it change' questions, giving clear invocation context. It does not name alternative tools or state when not to use it, so it stops short of a fully explicit usage-versus-alternative guide.

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 mark readOnly=true and destructiveHint=false, and the description adds meaningful behavioral detail: pagination with next_offset is required for complete reads, summary_only means the original full text is absent, and results at an unresolved application time should not be supplemented with current law. These go well 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?

Four dense sentences, each earning its place. The purpose is front-loaded, and the remaining sentences deliver behavioral warnings and usage constraints without redundancy. No filler or schema duplication.

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 5-parameter tool with annotations and an output schema, the description covers purpose, supported types, pagination behavior, summary-only semantics, and a temporal caveat. It could more explicitly connect the evidence_id to search_tax and clarify the next_offset/offset relationship, but the output schema likely fills the return-value 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?

With only 20% schema description coverage, the tool description carries a heavy load. It helps map evidence_type to concrete categories (e.g., case, ruling, article, treaty) and implies evidence_id comes from search_tax results, but it does not explain limit/offset usage, source_field selection, or the exact meaning of each parameter. The pagination comment touches offset indirectly but is not enough to fully compensate.

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 action: reading the DB full text of evidence found by search_tax, and it enumerates supported evidence types. It distinguishes itself from search siblings by tying evidence_id to search_tax, but it does not explicitly differentiate itself from get_article/get_annex/get_treaty_article for direct retrieval.

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: use this after search_tax to read full evidence text, paginate via next_offset for long content, and treat summary_only as non-full-text. It lacks an explicit statement of when not to use it or which sibling to choose instead, but the usage context is otherwise 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 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 burden of behavioral disclosure. It usefully reveals that the tool returns current statutes with effective dates, includes only current entries, and excludes historical ones. However, it does not describe the output shape, ordering, pagination, or any response limitations.

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 three concise Korean sentences, each earning its place: what is returned, the current-only scope, and when to use it. There is no filler, repetition, or redundant restating of the tool name.

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 no-input list tool, the description is nearly complete: it states the returned content, effective dates, scope, exclusions, and intended use before other tools. The only minor gap is the lack of an explicit response format, but no output schema is provided, so this is a limited weakness.

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 is empty with 100% coverage, so there is no parameter meaning for the description to add. The baseline for zero-parameter tools is 4, and the description appropriately focuses on result scope rather than parameter details.

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 ('반환한다' / returns) and a clear resource: the current tax law statute list (laws, enforcement decrees, enforcement rules) with effective dates. This distinguishes it from sibling tools like list_treaties and list_upcoming, so an agent can tell it apart without inspecting other schemas.

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

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

The description explicitly says it is for checking the DB coverage before using other tools, which gives clear usage context. It also clarifies that only current statutes are included and historical ones are excluded, though it does not name alternative tools or state explicit when-not-to-use conditions.

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?

With no annotations, the description carries the burden of behavioral disclosure. It goes beyond a simple search statement by adding two meaningful caveats: single-core-keyword precision and the warning that keyword hits are not verified citations to current statutes. These are genuine behavioral traits an agent needs.

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 concise sentences, front-loaded with the core function and followed by essential usage caveats. No wasted words; every sentence carries operational meaning.

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 or annotations, the description provides sufficient scope, query guidance, and an important evidentiary caveat. It could mention result handling or ordering, but all essentials for calling the tool are 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?

The schema only describes 'limit' (default 5, max 15) but leaves 'query' undocumented. The description compensates by explaining query semantics: a single core keyword is accurate, which is useful for invocking the tool correctly. Thus it adds value 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 and resource: '전문검색한다' with explicit scope of Supreme Court/High Court precedents and Tax Tribunal rulings. This clearly distinguishes it from sibling tools like search_articles or search_treaties, which target different legal document types.

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 a clear usage context: search when you need case precedents or tax tribunal decisions. The note '단일 핵심 키워드가 정확함' provides practical guidance on query formulation, though it doesn't explicitly name alternatives or state 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?

With no annotations, the description carries the full burden and adds meaningful caveats: it is a full-text search and keyword hits are not verified citations to current provisions. This warns the agent about a non-obvious result characteristic. It could have disclosed more about response structure, but the key behavioral risk is addressed.

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, all informative: function first, then use case, then an important caveat. No filler or redundancy.

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 two parameters and no output schema, the description provides enough to select and invoke it: source agencies, purpose, keyword-search behavior, and a critical limitation on citation validity. It does not describe the return format, but the caveat and scope are sufficiently complete for correct use.

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 'limit' parameter is documented (default 5, max 15) but 'query' has only a type. The description compensates somewhat by framing the query as a full-text keyword search ('전문검색', '키워드 히트'), but it does not detail query syntax or formatting.

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 clearly identifies the resource: interpretation cases from three named agencies. It also states the practical purpose (confirming the tax authority's position), which distinguishes it from sibling tools like search_articles or search_cases.

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 explicitly states when to use the tool: '실무 쟁점의 과세관청 입장 확인에 사용.' This gives clear context, though it does not explicitly exclude alternatives or name sibling 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?

Annotations already declare read-only and non-destructive behavior, so the description does not need to repeat that. It adds useful behavioral context by mentioning that results include graph_paths, DB original text, effective dates, and version status, and that long texts can be continued via get_evidence. However, it does not disclose any potential side effects, rate limits, or system-specific behaviors that go beyond the annotation.

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 verbose and not well front-loaded. The opening phrase '로컬 tax-ai-agent와 같은 통합 그래프 탐색' is vague and references an unspecified local agent. It then lists multiple output details and ends with pagination instructions. While it conveys necessary information, it could be condensed to focus on the tool's primary function and key differentiators, making it less concise than ideal.

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 complexity of the search_intents object and the variety of document types, the description provides some high-level context (e.g., it returns graph paths and version info), but it lacks concrete examples of how to construct effective queries or interpret the response structure. The schema offers some guidance, but the description does not fully bridge the gap for an agent to autonomously use this tool in a nuanced scenario.

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 provides descriptions for as_of, result_set_id, and search_intents, but the tool description does not add any meaningful explanation for limit, offset, or how to structure search_intents beyond what the schema offers. The mention of 'next_offset' refers to an output field, not a parameter, and 'get_evidence' is a separate tool. Thus, the description does not enrich parameter understanding 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 clearly states the tool's core function: an integrated graph search that traverses legal documents (law articles, precedents, rulings, interpretations, annexes, etc.) to collect issue-related materials. It distinctively positions itself as a comprehensive search tool compared to sibling tools that focus on single document types (e.g., get_article, search_cases). The phrase '쟁점 자료 수집의 우선 도구' (primary tool for collecting issue materials) further clarifies its intended role.

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 some guidance by labeling this as the primary tool for collecting issue materials, implying it should be used first for comprehensive searches. However, it does not explicitly contrast it with sibling tools (e.g., when to use search_articles instead) or specify conditions for when this tool is not appropriate. The mention of supplementing with full-text search hints at a workflow but lacks clear directives.

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.