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

Annotations already declare readOnlyHint/idempotent/destructive=false, so the safety profile is covered; the description's '읽기 전용' is partly redundant. It does add real behavioral context beyond the annotations: no API key required, public 조회 on the 국세법령정보시스템, and a 1-day cache for identical requests — useful for an agent deciding on repeat calls.

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

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

Front-loaded with the core action, then cleanly sectioned into 언제 (when) and 반환 (return) blocks. Every sentence earns its place 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?

With no output schema, the description supplies the return shape ({법령, 기준, 통칙[{번호·제목, 본문}], 링크}) plus auth and caching behavior. Nothing an agent needs to call and interpret this tool 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 lang, article, keyword, and law_name with examples and defaults. The description restates 'by article or keyword' but adds no syntax or format detail beyond what the schema provides; baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Get NTS Basic Rules full text') with two access modes (by article or keyword), and explicitly contrasts itself with two named siblings. An agent can distinguish it from execution_standards and rulings_by_article without opening any 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 '언제' clause gives the triggering condition (when the official NTS interpretation standard for a statutory article is needed) and names the alternatives with the condition that selects each: execution_standards for practical enforcement lists, rulings_by_article for case-specific interpretation. Explicit when/when-not/alternatives.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, and the description partly repeats that ('읽기 전용, 외부 호출 없음'). However it adds genuinely new traits: the 'offline, instant' latency profile and, since no output schema exists, an explicit return shape showing each result carries score and citation. The repetition of annotation content 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?

Front-loaded with the core purpose, then cleanly labeled sections for when ('언제') and return ('반환'). Every sentence carries distinct information with no padding.

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

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

Covers purpose, scope (96 cases), when-to-use, the competing sibling, and the return structure despite there being no output schema. Combined with annotations that fully cover the safety profile, an agent has everything needed to call it 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 description coverage is 100%, so the schema already documents query, k, area, and lang (including the lang behavior and the enum values). The description adds no parameter meaning beyond that, 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 (search the NTS 2025 Tax Interpretation Casebook) and scopes it precisely with '96 curated cases.' It also names the sibling search_tax_rulings so the agent can distinguish this curated/offline corpus from the full/latest rulings search without opening either schema.

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

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

The '언제' clause gives an explicit when: quickly viewing NTS-selected representative interpretations (offline, instant). It also names the alternative ('최신·전체 해석은 search_tax_rulings') with the condition that selects it, leaving nothing to inference.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint=false, destructiveHint=false) the description discloses that it is read-only, invokes Upstage Solar requiring the UPSTAGE_API_KEY env var, incurs token cost per call, and takes ~10 seconds. It also constrains output ('문서번호는 검색 결과에 있는 것만'), which is behavioral context the annotations cannot carry.

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 and labeled (purpose, 언제, 반환, cost), so it is easy to scan. The English and Korean first sentences are near-duplicates, which adds length, but every section 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 tool with no output schema, the description supplies the return shape ({해석, 요약, 주의}), the cost/latency/API-key requirements, and the read-only nature. Nothing an agent needs to call 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 tax, lang, facts, and our_view, including the 1500-char limit and enum values. The description adds little parameter-level meaning beyond the schema, 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 (해석·논리 vs 판례), and the scope is per-item adjudication into 지지/반대/구별. It explicitly contrasts itself with the sibling search_tax_rulings ('단순 검색은 search_tax_rulings'), so an agent can separate the two without opening schemas.

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

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

The '언제' line names the concrete trigger (점검 근거와 반대 사례를 한 번에, 의견서·불복 검토) and the alternative for plain retrieval (search_tax_rulings). Both when-to-use and when-not are given 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the trailing 읽기 전용 is largely redundant. The description does add genuinely new operational context beyond annotations: no API key required for the public NTS lookup and a one-day cache for identical requests.

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-loads the one-line purpose, then uses labeled 언제/반환/operational blocks that each carry distinct information. Dense but waste-free; only the 읽기 전용 phrase overlaps structured 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?

Despite having no output schema, the description fully specifies the return shape ({법령, 기준, 항목:[{항목, 쪽}], 링크, 주의}), plus the critical limitation that content is PDF-only. Nothing an agent needs to call or interpret this tool 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%, so law_name, article, keyword and lang are all documented in the schema itself; baseline 3 applies. The description's mention of '조문별' loosely echoes the article filter but adds no syntax, format or default guidance beyond what the schema already supplies.

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 ('List Tax Execution Standards items with page numbers') and pins the scope to the latest published edition. It explicitly distinguishes itself from the sibling basic_rules for body text, so an agent can route correctly without opening either schema.

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

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

The '언제' line gives the exact triggering condition (checking whether an article-level standard exists and on which page), and it adds an explicit exclusion plus alternative: body text is not provided here, so use basic_rules when the 통칙 body is needed. This is textbook when/when-not/alternative 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, openWorldHint, and destructiveHint=false. The description adds useful context beyond annotations: it states no API key is needed, that it uses the public 국세법령정보시스템, and that responses are cached for 1 day. This is solid additional behavioral detail, though return format is partially covered by the '반환' note (which is helpful since there's no output schema).

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?

Very well-structured with front-loaded purpose, followed by clear sections for when to use (언제) and what is returned (반환), plus a brief note on behavior. Every sentence is informative and 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 tool's simplicity (2 parameters, no output schema), the description is quite complete. It covers purpose, usage, return structure, and operational context. Minor gap: the '반환' section describes fields but not their exact data types or edge cases (e.g., missing fields), which could be helpful without an output schema.

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 both parameters, including the id's origin and format, and the lang enum's behavior. The description does not add parameter-level detail beyond what the schema provides. 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?

States a specific verb (Get) and resource (full text of one ruling or decision), and clearly scopes it to retrieving a single document's body. It is easily distinguishable from sibling search/list tools like search_tax_rulings and rulings_by_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 states when to use it ('after selecting a document from search results to cite or summarize') and includes a caveat ('don't judge based only on the summary – use this to read the full text'). This gives clear direction versus alternatives.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds material context beyond them: the required LAW_OC environment variable, the free key requirement, and the failure/error behavior when it is missing. It also describes the return payload shapes, which no output schema provides.

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

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

Front-loaded with the core purpose, then structured by 언제/반환, which is easy to scan. The bilingual English/Korean content is mildly redundant but each block serves a purpose, so it earns its length without much waste.

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 description covers purpose, temporal semantics, return structure, and the auth prerequisite — everything an agent needs to invoke it correctly. 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 description coverage is 100%, so the schema already documents all six parameters including as_of date format and the delegation flag. The description echoes the delegation-chain concept and the as-of date framing but adds little syntax or semantics beyond the schema, 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 ('Get statute text as in force on a date') plus a scope qualifier (optional Act → Decree → Rule chain). This clearly distinguishes it from the rulings/case/publication siblings, which retrieve interpretation or precedent rather than statute text.

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

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

The '언제' section gives explicit when-to-use guidance (when the law at the time of the fact event matters, e.g., determining tax amounts or requirements) and contrasts with interpretation/precedent tools that use reply-date law. It lacks explicit sibling tool names, so it stops at clear context rather than full routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds genuinely useful behavior beyond them: the LAW_OC dependency (article text is omitted and only interpretations/basic rules are returned without it) and the 10–30 second latency. The explicit "읽기 전용" restates the annotation. Dependency and latency disclosure elevate this above baseline.

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 purpose, then the when/return/dependency/latency facts in labeled clauses (언제, 반환). Bilingual duplication and dense Korean add length, but every clause carries distinct information and the structure is scannable. Slightly heavier than ideal but 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?

With no output schema, the description carries the return-value burden and does so by enumerating the response keys. It also documents the external dependency, latency, and read-only nature for a 6-parameter tool. What remains thin is error/failure behavior when LAW_OC is absent or the period is malformed.

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

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

Schema description coverage is 100%, so the baseline would be 3. The description adds value beyond field-level schema docs by tying the parameters into a temporal-resolution model: the reference date, whether then-vs-current article text changed, and whether each interpretation/case was registered under text matching the reference date. This conceptual framing of 'period' exceeds what the schema conveys 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?

"Bundle everything that applied to an issue at a past date" names a specific verb (bundle/retrieve) and a well-defined resource (all authorities applicable to an article at a historical point). The Korean gloss enumerates the bundled categories (3-tier article text, 기본통칙, 집행기준, interpretations, cases), which also implicitly distinguishes it from the single-category siblings. It stops short of explicitly naming alternatives like basic_rules or casebook_search, so not quite 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?

"언제: 세무조사·불복처럼 특정 사업연도에 적용되는 근거를 정리할 때" gives a concrete triggering scenario (tax audit/appeal needing point-in-time authority). It explains the governing logic (fixed reference date, comparing then-vs-now article text), which is clear context. No explicit exclusions or sibling routing is provided, so it is not a full 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?

Annotations already cover read-only/idempotent/openWorld, but the description adds material context beyond them: it confirms read-only, states no API key is needed (public 국세법령정보시스템 lookup), and discloses a 1-day cache for identical requests. That caching/auth detail is genuinely useful and not derivable from 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?

Front-loaded with the purpose, then structured into 언제 (when) and 반환 (returns) sections. Efficient and scannable, though the inline return-shape literal is dense and slightly overlaps what the schema could carry.

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 proactively documents the return shape ({법령, 조, 결과:[...]}), plus auth/caching behavior, giving an agent everything needed to call and interpret the tool 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 all eight parameters are already documented, including the law_name and article formats and the tax/kinds enums. The description reinforces the law_name+article pairing with an example but adds no syntax or constraints beyond the schema, so the 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?

States a specific verb (List) and resource (rulings/decisions citing a specific statute article), and explicitly distinguishes itself from search_tax_rulings by the input condition. An agent can tell it apart from siblings 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?

Provides explicit when-to-use guidance ('when you know the article and want practical interpretations'), gives a concrete example (법인세법 제52조 → 부당행위계산), and routes the agent to the alternative when only keywords exist. Nothing is left to inference.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive, closed-world), the description discloses setup prerequisites (KOREAN_TAX_MCP_DOCS env var, pypdf dependency), a real latency characteristic (first call builds the index and can take tens of seconds on large files), the absence of external calls, and the return shape. These are exactly the operational facts an agent needs that annotations cannot express.

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?

Content is front-loaded (what it does, then when, setup, return) and every section carries useful information. It is somewhat dense and the bilingual restatement in the opening line duplicates meaning, costing a little efficiency.

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 compensates by spelling out the return structure ({results:[{file, page, score, excerpt}], index}) and the indexing latency. Combined with setup requirements and usage context, an agent has everything needed to invoke it 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 description coverage is 100%, so query, k, and lang are already fully documented in the schema (including query examples and the lang enum behavior). The description adds no parameter-level detail beyond what the schema provides, 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 (search) and resource (local PDFs you downloaded yourself), plus the granularity (page by page) and a concrete example (OECD Transfer Pricing Guidelines). This clearly separates it from siblings like search_tax_rulings or search_nts_publications, which query built-in corpora rather than user-supplied local files.

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 '언제' (when) section gives an explicit trigger: use it for copyrighted material that cannot be redistributed and that the user must supply themselves, and warns that documents are not bundled with the package. It lacks an explicit named-alternative routing (e.g. 'for published rulings use X instead'), so it stops just short of a 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuinely new operational context: no API key required, public query, and a 1-day cache for identical requests. It stops short of richer detail (pagination, result size behavior), keeping it at a solid 4 rather than 5.

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

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

Front-loaded with the core purpose, then cleanly labeled sections for when-to-use, return shape, and operational notes. Dense but not padded. The Korean/English mix is slightly redundant in the opening line but earns its place for bilingual routing.

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 carries the return-value burden and does so by specifying the result object fields (book, publish date, field, department, excerpt, link). Combined with the cache/key notes and 3-param schema, an agent has nearly everything needed, though result-set behavior (paging, total count) is unmentioned.

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

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

Schema description coverage is 100% and includes examples for the query parameter plus enum/default/max for n and lang, so the schema does the heavy lifting. The description adds no further parameter semantics, 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+resource: full-text search inside NTS official guidebooks and reports, with a parenthetical enumerating the covered publication types (transfer pricing, APA reports, overseas business guides, filing guides). This is concrete and scoped, though it does not explicitly contrast itself with siblings like casebook_search or search_tax_rulings, which an agent must infer from the publication-type list.

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 '언제' clause gives a clear trigger: use when explanation is needed from NTS's officially published practitioner guides. That is good context, but it offers no explicit exclusions or named alternatives (e.g., use casebook_search for case law), so the agent must infer the boundary against siblings.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description adds extra behavioral context: no API key required, NTS public-source query, and a 1-day cache for identical requests. It also discloses the return payload and that full text requires a separate call. That is solid added value, though return-format depth is limited.

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-loads the core purpose, then uses labeled sections (언제/반환) to separate usage, return shape, and operational notes. Every line carries distinct information with no 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?

No output schema exists, yet the description spells out the return object shape (구분, 문서번호, 제목, 요지, 세목, 일자, id, 링크) and points to get_tax_ruling(id) for full text. Combined with routing guidance and operational notes, nothing an agent needs to call 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 all eight parameters (n, tax, lang, sort, kinds, query, since, until) are documented in the schema with enum meanings and examples. The description adds no parameter-specific syntax or defaults beyond what the schema already provides, 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 (search) plus the exact resource — Korean tax rulings and decisions, itemizing the constituent types (해석, 판례). It explicitly distinguishes itself from siblings rulings_by_article and casebook_search, so an agent can route 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?

The '언제' (when) line gives a concrete trigger — first step when the issue exists but the statutory article is unknown — and names two alternatives with the condition that selects each (rulings_by_article when the article is known, casebook_search for summary-only needs). This is explicit when/when-not/alternatives guidance.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, but the description adds operational context the annotations do not: no API key required, a 1-day cache on identical requests, and a warning that article numbering varies per treaty so keyword search is more reliable. These are genuinely useful beyond the structured hints, though it stops short of describing pagination or size 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?

Front-loads the purpose, then cleanly labels when-to-use, return shape, and operational notes. Each section is dense and earns its place; 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?

There is no output schema, so the description supplies the return shape ({country, effective date, articles with article/title/body, link}), the required parameter, the caching behavior, and the routing alternatives. An agent has everything needed to call it 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?

With 100% schema description coverage the baseline is 3, but the description adds real guidance: the keyword-vs-article tradeoff ('조문 번호는 조약마다 다르니 keyword로 찾는 게 정확') tells the agent which optional parameter to prefer, and it notes the country fallback that returns a treaty-party list. That is meaningfully more than 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?

States a specific verb and resource ('Read Korea's bilateral tax treaties article by article'), with scope (96 countries, Korean/English). It also distinguishes itself from siblings by naming law_article for domestic statutes and search_tax_rulings for international-tax interpretation, so an agent can route 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?

The '언제' section gives explicit triggering scenarios (non-resident withholding limited rates, permanent establishment, residency determination) and names the exact alternatives for adjacent needs. This is textbook when-to-use and when-to-use-something-else guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely non-structured context: article checks require LAW_OC, '확인' means existence only (not content match), and result codes distinguish 국세청 DB 미확인 from 조회 실패. Missing only operational details like rate limits or cost.

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 one-line purpose followed by labeled 언제/반환/주의 blocks. Every sentence earns its place: purpose, trigger, return shape, and the existence-vs-content caveat. 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?

No output schema exists, so the description compensates by sketching the return object (문서번호 array with 인용/결과/제목/일자/링크/비슷한 번호, 조문 array, 요약, 주의). Combined with the auth note and semantic caveat, an agent has everything needed to call and interpret this 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%, so all three parameters (text, lang, as_of) are already documented in the schema, including the 20,000-character limit and the YYYYMMDD format. The description adds nothing parameter-specific, 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 (verify/check) and resource (cited rulings, decisions, statute articles), and explicitly carves out what it does NOT do: content matching is deferred to get_tax_ruling and law_article. An agent can distinguish this from every sibling 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?

The '언제' line gives an explicit trigger (before exporting AI- or human-written drafts) and the goal (filter out fabricated document numbers and nonexistent articles). It also names the alternative tools for the adjacent task of content verification, so the routing boundary is unambiguous.

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