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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so '읽기 전용' is largely redundant. The description does, however, add real behavioral context beyond annotations: the LAW_OC credential requirement (an auth prerequisite the annotations don't cover) and an explicit return shape. It stops short of pagination/rate-limit notes, so a 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-loads the core question, then usage, then return shape, then access constraints — a sensible order with little waste. Minor redundancy ('읽기 전용' duplicating readOnlyHint) and bilingual mixing cost it a point but not much else.

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 inline return structure ({법령, 조, 연혁[...], 요약, 주의}) is genuinely load-bearing and lets an agent interpret results. Combined with the auth prerequisite and the sibling routing, an agent has enough to call it correctly; only deeper detail on the history array semantics 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 effectively 100% (article format, last 2-20 range, lang behavior, law_name examples are all in the schema), so the baseline is 3. The description adds no parameter-level meaning beyond what the schema already documents; it focuses on purpose and return shape instead.

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 opening sentence states a specific verb+resource: it returns an article's amendment history and any upcoming (not-yet-effective) amendments. It also distinguishes itself from the sibling law_article by noting that raw text at a specific date belongs there. An agent can tell what this tool does and what it is not 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 explicit trigger questions ('when did this article change', 'will it change soon') and names the decision context (whether applicable articles differ by business year). It names the alternative explicitly: law_article(as_of) for dated original text. Both when-to-use and the routing condition are present.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description goes beyond that with genuinely new operational context: no API key required, source is the public NTS tax-law portal, and identical requests are cached for one day. The '읽기 전용' restatement is redundant but doesn't hurt.

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 compact labeled sections (언제/반환/behavior) so each line carries distinct information. Dense but no filler sentences.

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, and the description supplies the return shape ({법령, 기준, 통칙[], 링크}), plus access and caching constraints. Combined with full schema coverage and rich annotations, 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 explains lang, article, keyword, and law_name in detail. The description's 'by article or keyword' summarizes the parameter behavior but adds no syntax or format detail beyond the schema, so 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, and scope: retrieves the full text of NTS Basic Rules by article or keyword. It names sibling tools (execution_standards, rulings_by_article) so an agent can separate this from adjacent lookup tools 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 '언제' line gives an explicit trigger condition (need the NTS official interpretation for an article) and routes two distinct alternatives: enforcement-standard lists go to execution_standards, case-specific interpretations to rulings_by_article. When-to-use and alternatives are both covered.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so '읽기 전용, 외부 호출 없음' largely repeats structured data. However, the description adds genuinely new behavioral context: the tool works offline and returns instantly, and it enumerates the returned record fields — valuable since no output schema exists.

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 cleanly split into '언제' (when) and '반환' (returns) blocks that an agent can scan quickly. The only waste is the purpose sentence being stated twice, once in English and once in Korean, which is mild redundancy rather than bloat.

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 enumerating the return fields, and it covers scope, selection criteria, an alternative tool, and the offline/instant behavior. Nothing an agent needs in order to call this 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 k, area, and lang are already documented in the schema, including the enum values. The description adds no syntax, formatting, or query-construction guidance beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Search the NTS 2025 Tax Interpretation Casebook') and scopes it precisely with corpus size (96 curated cases) and vintage (2025). It also explicitly distinguishes itself from the sibling search_tax_rulings, so an agent can choose 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 '언제' block gives an explicit when-to-use condition (quickly viewing interpretations the NTS selected as representative, offline/instant) and names the alternative for the contrasting case ('최신·전체 해석은 search_tax_rulings'). Both the selection condition and the exclusion are stated.

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

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

Beyond the annotations (readOnly/idempotent/openWorld/destructive=false), it discloses that outcome verdicts are read from the 본문 주문·결론 by rule and not model-inferred, that arguments/reasons are cut excerpts from the body, the explain-mode behavior (host_ai vs solar_cloud/onprem), and a latency of roughly 5–10 seconds. That is rich behavioral context, though it doesn't discuss failure modes or result limits beyond the n cap.

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

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

The purpose is front-loaded and the body is information-dense with labeled sections (언제 / 결과 판정 / 반환 / explain). It is bilingual and the two language blocks largely mirror each other, which adds length, but for a Korean-first tool this is largely functional rather than filler.

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

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

There is no output schema, so the description carries the return-value burden and does so by enumerating the return shape (쟁점, 집계, 납세자 승/일부 인용/패, 각하·기타, 갈린 지점?, mode?, 주의). Combined with the mode and latency disclosures, an agent has nearly everything needed to call it correctly; missing only explicit limits on result volume beyond n.

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 n, tax, lang, issue and explain, giving a baseline of 3. The description adds a little on explain's mode-dependent behavior but does not add format or syntax meaning beyond what the schema text 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 states a specific verb and resource: it splits decisions on one issue into taxpayer-won / partial / lost and lays out both sides' arguments plus the deciding reasoning ('납세자 승(인용·취소)/일부 인용/패(기각)'). It is concrete about what is produced, but it never names or distinguishes a sibling like compare_with_case or research_issue, so an agent must infer the boundary from the 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?

It gives explicit context: use it in 불복·조사 대응 when you want to see what the winning side proved and what the losing side lacked, with the explicit constraint not to filter only winning cases (both sides must be shown). This is useful when-to-use guidance, though no alternative tool is named as a fallback.

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

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

Goes well beyond the annotations: it discloses two operating modes (host_ai vs Solar), the exact return shape of each, the data-privacy consequence (no transmission by default; input sent to api.upstage.ai only when UPSTAGE_API_KEY/on-prem base URL is set), ~10s latency, and the constraint that document numbers come only from search results. That is substantive context the readOnly/openWorld annotations cannot convey.

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 purpose, then when-to-use, then a compact breakdown of default vs Solar return shapes. It is longer than typical and the Korean/English duplication adds bulk, but every section earns its place for a configuration-dependent tool.

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 delivers both return shapes, latency, data-flow caveats and the '주의' field. It is nearly complete, leaving only the unexplained mode selector that is not reflected in the input 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 tax, lang, facts and our_view are already documented, making 3 the baseline. The description explains output modes driven by configuration rather than adding syntax or constraints for the actual parameters, and it references a 'mode="host_ai"' setting that does not exist in the schema, which adds mild ambiguity rather than parameter clarity.

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: compare facts/argument against rulings, producing supports/contradicts/distinguish verdicts. It explicitly names the sibling search_tax_rulings as the alternative, so an agent can distinguish this tool without opening the schema.

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

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

'언제: 주장의 근거와 반대 사례를 한 번에 점검할 때' gives the exact scenario (opinion letters, appeal reviews), and '단순 검색은 search_tax_rulings' rules out the alternative. Both when-to-use and the exclusion are 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?

Annotations already cover readOnly/idempotent/openWorld/destructive, so the description adds value by disclosing that no API key is required for the public 국세법령정보시스템 lookup and that identical requests are cached for one day. It does not describe pagination or result-size limits, so it falls short of a 5.

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

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

Front-loads the one-line purpose, then cleanly segments 언제 / 반환 / behavioral notes. Every sentence earns its place, though the mixed bilingual phrasing makes it slightly denser than necessary.

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 available, the description compensates by spelling out the return shape ({법령, 기준, 항목:[{항목, 쪽}], 링크, 주의}), which tells the agent exactly what it will receive. Combined with the usage routing and access notes, nothing needed 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 coverage is 100%, and each parameter (lang, article, keyword, law_name) already carries a detailed description including an enum and examples, so the baseline is 3. The tool description adds no parameter-level meaning beyond what the schema states.

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') plus a bilingual gloss of the resource name. It establishes scope (items + page numbers) and distinguishes itself implicitly from full-text tools by noting the body is a PDF booklet.

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 (checking whether a per-article standard exists and on which page), and it names the alternative — 'basic_rules' — for when the agent needs the 통칙 body text. This is exactly the when/when-not/alternative structure the dimension rewards.

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/open-world safety, and the description goes further with genuinely new operational facts: an authentication requirement (LAW_OC needed, otherwise error) and a hard output cap of 4,000 characters. It also sketches the return record shape, which matters because no output schema exists.

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 cleanly labeled sections (언제 / 반환 / 다음 단계) that a scanning agent can parse. The English and Korean halves restate each other, so some text is duplicative rather than additive, which keeps it short of a 5.

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 search tool with no output schema, the description supplies everything an agent needs: trigger condition, example query, return field list, result-size ceiling, auth prerequisite, and the next tool to call. Nothing required to invoke 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 n, lang, as_of, keyword, and law_name (including the default search scope). The description adds only a usage example for keyword and the shape of the law_article follow-up call, so the baseline of 3 is the right level.

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

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

States a specific verb and resource ('Find statute articles by keyword') plus the scope of the lookup. It explicitly positions itself against the sibling law_article by stage ('first step when you don't know the article number'), so an agent can tell which tool to reach for 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?

Gives an explicit trigger condition ('쟁점 키워드는 있는데 조문 번호를 모를 때'), a concrete example mapping a keyword to a statute article, and the follow-up step with the exact tool and arguments ('law_article(law_name, 조, keyword=...)'). When-to-use and the alternative are both spelled out.

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, and non-destructive traits, but the description adds genuinely new behavioral facts: public access with no API key and a 1-day cache for identical requests. It also discloses return shape and a 20,000-character body cap, which the annotations do not provide.

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 purpose, then labels and sequences 'when', 'return', and behavioral notes so the agent can scan quickly. The Korean/English duplication doubles the raw length, but each block is purposeful and no sentence is 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 simple two-parameter fetch with no output schema, the description carries the return-value burden itself, enumerating fields and body structure including the length cap. Combined with the auth and caching notes, nothing needed 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 both the required 'id' (sourced from search results) and the 'lang' enum are fully documented in the schema itself. The description adds nothing about parameter syntax or format, 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 ('Get the full text') and a precise resource ('one ruling or decision'), so it is unmistakably a single-document fetch rather than a search. This cleanly separates it from siblings like search_tax_rulings 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 '언제' line gives explicit context: use after picking a document to cite/summarize from search results, and don't judge from the summary alone. It implies the search-then-fetch workflow but does not name the search sibling or state when-not to use it, so it falls short of full routing guidance.

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

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

Annotations already cover the safety profile (readOnly/idempotent/non-destructive/openWorld), and the description adds substantial non-obvious context: the 법제처 API (LAW_OC) credential requirement, a guarantee that article text is verbatim from the in-force version and never fabricated, the verdict-classification rules, the 0.3-overlap guard that downgrades '모순' to '판단 필요', and the caveat that '판단 필요' is a textual-comparison result rather than legal advice.

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 definition is long but front-loaded with the purpose and organized under clear labels (언제/입력/처리/반환/판정), so it is scannable rather than rambling. The '처리' section exposes internal pipeline steps (law.version → law._full_units → claims.judge) that are the least essential part for a caller, but the rest of the sentences each carry actionable information.

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

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

With no output schema available, the description carries the full burden of describing the return shape (법령/시행본/후보조/보기별 fields/요약/주의) and it does so in detail, alongside the verdict taxonomy and the reading caveat. For a 6-parameter, multi-step judgment tool, nothing an agent needs to call and interpret 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% and the description's '입력' section largely mirrors the schema text (statement id ordering, articles format, as_of default, also_decree candidate expansion), so it adds little meaning beyond what the structured fields already state. Baseline 3 applies 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?

The first sentence states a specific verb, resource and scope: batch character-level comparison of multiple statements/claims against 1–5 articles, returning a per-statement table of best-matching article and verdict. It also explicitly distinguishes itself from the sibling verify_statement ('보기마다 verify_statement를 따로 부르지 않고 한 번 호출로 처리'), so an agent can route between them 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 '언제' section gives an explicit trigger condition (multiple options/statements to compare against a specific 1–5 articles at once) and names the alternative approach (calling verify_statement per statement), including why this tool replaces that pattern. No inference is required to decide when to use it.

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

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

Annotations already declare read-only/idempotent, but the description adds what they don't: a required LAW_OC environment variable with a specific failure mode ('없으면 발급 안내 오류'), the long-article truncation fallback, and a full enumeration of the return envelope including '읽기 주의', '기준일 안내?' and the delegation-chain alternative shape. That is substantive behavioral disclosure, not restatement.

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

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

It is front-loaded with the one-line purpose, then uses labeled segments (언제, 반환) that scan well. It is dense but nearly every clause carries operational value; the main waste is the as_of advice appearing in both the description and the schema's as_of field.

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 8 parameters and no output schema, the description carries the return-shape burden and does so: it enumerates the keys of the normal response, the delegation-chain variant, and the caveats field. Nothing an agent needs to call this correctly or interpret the result appears to be 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 the baseline is 3, but the description adds selection strategy beyond the schema: put the period-end date in as_of when the facts contain a fiscal/imputation year or tax period, and choose keyword vs paragraph based on whether the paragraph number is known. The as_of guidance is partly duplicated from the schema field text, limiting it to a 4.

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 opening sentence names a specific verb and resource ('Get statute text as in force on a date') plus the optional Act → Decree → Rule chain, which is a scope claim no sibling makes. The Korean subtitle repeats the same precise scope (조문 원문 + 3단 위임), so the agent can distinguish it from find_article (article lookup) and article_history.

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

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

It states when to use it ('세액·요건 판단처럼 사실 발생 시점의 법령이 필요할 때'), how it relates to rulings/interpretations (compare against the law in force at the year in question), and routes to the alternative explicitly ('조문 번호를 모르면 find_article로 먼저 찾는다'). It also gives an intra-tool decision rule: for articles over 4,000 characters use keyword or paragraph, otherwise get the paragraph list.

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, openWorld, idempotent, non-destructive. The description adds valuable behavioral details beyond annotations: it requires LAW_OC for the article portion (otherwise only interpretations/rulings are returned), notes a 10–30 second latency, and describes the return structure including timing rules and caveats. This is meaningful supplementary transparency.

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

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

The description is front-loaded with the core purpose, then provides when-to-use, return structure, dependency, and latency. It is dense but every sentence conveys information necessary for a complex, multi-output tool. The bilingual repetition adds slight length but no wasted 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?

Given the tool's complexity (8 params, composite output, no output schema), the description is largely complete: it covers purpose, usage context, return format, external dependency, and latency. It does not detail error handling or the '주의' field's semantics, but these are minor gaps for an experienced agent.

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 baseline is 3. The description adds semantic meaning by explaining how period is interpreted for different tax types and events (e.g., corporate/income/VAT use fiscal period end; transfer uses transfer date, inheritance uses death date, etc.) and ties event to date requirement. This exceeds the schema's individual param descriptions.

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: 'Bundle everything that applied to an issue at a past date.' It then enumerates the bundled components (article at past date, basic rules, execution standards, interpretations, cases), making the composite nature clear. It does not explicitly contrast with siblings like law_article or basic_rules, but the bundle concept distinguishes it.

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

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

It gives a clear usage context: '언제: 세무조사·불복처럼 특정 사업연도에 적용되는 근거를 정리할 때' (when organizing the basis applicable to a specific fiscal year for tax audits/appeals). No when-not or explicit alternatives are provided, so it falls short of a 5, but the context is clear.

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

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

Annotations already declare read-only/idempotent/non-destructive, but the description adds substantial context: rules-based with no Solar key required, host AI performs the judgment, tax_treaty is an optional external call that degrades to mock text, and it enumerates the full return payload. This tells the agent exactly how the tool behaves under failure and offline conditions — 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?

Content is front-loaded (purpose, then when, then return shape, then the ordered steps) and each block is scannable. Minor waste: the 'no external calls' claim is restated ('외부 호출 없이 동작' at the top and '읽기 전용, 외부 호출 없음' later), and the mock-oriented parenthetical is somewhat verbose.

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 31-parameter tool with no output schema, the description carries the missing structural burden: it enumerates the return object (input, legal basis, each of the three steps, final determination, top-3 precedents, divergence points, cautions) and spells out the legal source sequence and citation exclusions. Nothing essential for calling it correctly appears to be 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 baseline is 3, but the description adds real meaning by mapping parameters to the tie-break sequence (항구적 주거 → 중대한 이해관계 중심지 → 일상적 거소 → 국적 → 상호합의) and by explaining that tax_treaty(country, keyword='거주자') is invoked when a counterparty country is supplied. That interpretive layer on top of the schema's field labels is useful.

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 line states a specific verb+resource: a rule-based 3-step resident/non-resident/dual-resident determination, and immediately scopes it as deterministic ('규칙 기반, 외부 호출 없이 동작'). It is distinguishable from judgement-heavy siblings such as residency_report because it declares the logic is fixed code, not host-AI inference.

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

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

'언제:' gives an explicit trigger — when you have judgment input data and want the resident/non-resident/dual-resident/tie-break result immediately. It also clarifies the division of labor (host AI does the substantive judgment; the code is fixed). It stops short of naming an alternative sibling (e.g. residency_report) or when NOT to use it, so it is clear but not fully routable.

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/openWorld), it discloses real behavioral traits: Solar selection via UPSTAGE_API_KEY (cloud) or KOREAN_TAX_MCP_SOLAR_BASE_URL (on-prem), a graceful fallback that returns only the residency_check result when no key exists, that the report conclusion cannot override the code-based judgment, and the external reads (tax_treaty, rules.md) plus the Solar call. This is well beyond what structured fields convey.

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 cleanly labeled '언제:' and '결론:' sections; every line carries information. Slightly dense but no filler sentences.

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 31-param, no-output-schema tool it covers purpose, trigger, auth/fallback behavior, and the non-authoritative nature of the output. The only mild gap is a brief note on what the returned markdown contains, but the format reference (report_template.md) largely covers that.

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% across 31 params, so the schema already documents each field and its enums. The description adds only that inputs mirror residency_check results; it gives no additional syntax, format, or interaction detail, 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 (판정 검토 보고서 마크다운 작성) and names the exact inputs (residency_check 결과 + rules.md via Solar Pro 4). It also explicitly distinguishes itself from the sibling residency_check by noting the report only narrates while the judgment stays in code, so an agent can separate the two without opening a schema.

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

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

'언제:' gives an explicit trigger — when you want a detailed narrative review report in report_template.md format from a residency_check result. It implies the alternative (call residency_check directly for the judgment) but never names a 'do not use for X' exclusion, so routing guidance is clear but not fully complete.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so '읽기 전용' is largely a restatement. However, the description adds genuinely new behavioral context: a public 국세법령정보시스템 lookup requiring no API key, and a 1-day cache for identical requests. The return shape is also disclosed. Missing only rate-limit/error 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?

Front-loaded purpose, then when-to-use, return shape, and behavioral notes in that order. Four short labeled blocks (언제/반환/behavior) with no filler; the example earns its place by disambiguating article citation.

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, but the description supplies the return structure {법령, 조, 결과:[...]}. Combined with rich annotations and fully documented parameters, 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 all 8 parameters with format hints, enums, and defaults. The description reinforces the law_name+article combination via its example but adds little syntax or format detail beyond what the schema provides, warranting the baseline 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?

States a specific verb ('List') and resource ('rulings and decisions that cite a specific statute article') in both English and Korean. It explicitly differentiates from the sibling search_tax_rulings, so an agent can choose between them 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 explicit when-to-use guidance with a concrete example (법인세법 제52조 → 부당행위계산) and names the alternative condition ('키워드만 있으면 search_tax_rulings'). Both the selection condition and the fallback are stated.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive. The description adds non-obvious behavior: no API key required for the public NTS query, 1-day caching of identical requests, and dedup to the latest effective version of duplicate forms. It stops short of describing pagination or failure modes, so not a full 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 English summary followed by clearly labeled sections (언제 / 반환). Every sentence earns its place and the return shape is compactly specified.

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 structure itself, and the usage section routes the agent correctly. For a 4-param filtered search tool, nothing needed 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 n, kind, lang, and query. The description only echoes query semantics ('별표·서식 이름에 들어가는 말') already captured in the schema, adding no syntax or formatting detail. Baseline 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?

States a specific verb (Search) and resource (statutory annexes and official tax forms), scoping it to rate/useful-life tables and forms. It explicitly contrasts with the sibling law_article ('조문 본문은 law_article'), so an agent can distinguish it 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 names concrete triggers (rate tables, useful-life tables, depreciation tables, report/statement/notice forms) and the explicit exclusion sent to law_article. When-to-use and the alternative are both stated, 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?

Annotations already declare readOnlyHint/idempotentHint/openWorldHint/destructiveHint, so the safety profile is covered (and '읽기 전용, 외부 호출 없음' merely repeats it). The description adds genuinely new behavior: required env var KOREAN_TAX_MCP_DOCS, a pypdf dependency with the uvx invocation, and first-call index construction that can take tens of seconds on large files.

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 (언제 / 설정 / 반환). The bilingual duplication doubles the length, but for a Korean tax tool that is functional rather than padding, and each section carries distinct information.

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

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

With no output schema, the description takes on the return-value burden and delivers it ({결과: [{파일, 쪽, 점수, 발췌}], 색인}), plus setup prerequisites and index-building latency. Everything an agent needs to call this correctly and set expectations is present.

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

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

Schema description coverage is 100%, so query (with multilingual and paragraph-number examples), k (1-10), and lang (en/ko semantics) are already fully documented in the schema. The description only implies page-level granularity and adds nothing about parameter syntax 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 concrete verb and resource ('Search PDFs you downloaded yourself, page by page') plus the scope ('문서는 이 패키지에 들어 있지 않음'), making it unmistakable against sibling tools that query built-in corpora (search_tax_rulings, law_article, casebook_search). An agent can tell this is a local-file search, not a server-side corpus lookup, 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 '언제' section gives an explicit usage condition: use it for copyright-restricted material like OECD guidelines that cannot be redistributed. It supplies clear context for selecting the tool, but names no alternative sibling and states no when-not-to-use case.

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

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

Annotations already declare readOnly/idempotent/openWorld/destructive=false, but the description adds non-obvious context: no API key required (공개 조회, 키 불필요), a 1-day cache for identical requests, and where the original full text lives. These are real operational facts not present in structured fields.

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?

Bilingual content is tightly organized with explicit 언제/반환 labels, front-loading purpose and use-case before return format and operational notes. Every line (search scope, when, return shape, cache/auth) 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, which is complete for a read-only search tool. Naming a differentiating sibling would have made it fully airtight.

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 n, lang, and query thoroughly (including examples and enum behavior). The description reinforces the return shape but adds no syntax or format detail 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 (full-text search) and resource (NTS official guidebooks/reports), and enumerates the covered publication types (transfer pricing, APA reports, overseas business guides, filing guides). This distinguishes it from generic siblings like search_tax_rulings or casebook_search, though it does not explicitly name a competing tool.

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

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

The '언제:' line gives clear context for when to use it – when practical guidance from NTS official booklets is needed – with concrete examples of the covered material. It stops short of naming alternatives or stating when NOT to use it, so it does not reach 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?

Beyond the readOnly/openWorld/idempotent annotations, the description discloses that no API key is required, that identical requests are cached for one day, and that full text requires a follow-up get_tax_ruling(id) call. Auth, caching and follow-up behavior are exactly the traits 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?

Front-loads the purpose, then uses labeled sections (언제 / 반환 / constraints), which is easy to scan. The Korean/English mix and the inline enumeration of subtypes make it slightly dense, but virtually every clause carries information the agent needs.

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 itself (구분, 문서번호, 제목, 요지 400자, 세목, 일자, id, 링크 plus 주의) and routes to get_tax_ruling for body text. Combined with the auth/caching notes, an agent has everything needed to call and consume the result 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 all eight parameters (n, tax, lang, sort, kinds, query, since, until) are already documented in the schema, including enum meanings and defaults. The description adds only a general notion of keyword search, so the baseline 3 applies with no extra semantic content.

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 (Korean tax rulings and decisions), then enumerates the exact document subtypes covered (질의회신·과세기준자문·사전답변 as 해석, 법원·조세심판·이의·심사 as 판례). An agent can distinguish this from rulings_by_article and casebook_search 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?

Explicit '언제' section names the triggering condition (issue known, statute unknown → first step) and names the two alternatives with the condition that selects each: rulings_by_article if the article is known, casebook_search if only summaries are needed. 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 readOnly/idempotent/non-destructive annotations, the description discloses that it is a public NTS lookup requiring no key and that identical requests are cached for one day. It also gives the return shape, adding real operational context.

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 and organized under clear semantics (when / return / behavior) markers. The bilingual duplication inflates length, but each segment carries non-redundant 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 read tool with no output schema, the description covers purpose, when-to-use, alternatives, return structure, caching, and auth requirements. An agent has everything needed to select and 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 coverage is already 100%, so the baseline is 3, but the description adds genuine guidance: article numbering varies per treaty so keyword lookup is more reliable, and an unknown country name returns the contracting-state list. This meaningfully supplements 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?

Names a specific verb (read) and resource (Korea's bilateral tax treaties, 96 countries) with the article-by-article scope and language options. It also explicitly demarcates itself from siblings by pointing to law_article for domestic statutes and search_tax_rulings(tax='국조') for international tax interpretation.

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 lists concrete triggering scenarios (non-resident withholding limited rates, permanent establishment, residency determination) and routes the agent to explicit alternatives with the condition that selects them. 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real context: it is read-only, backed by data/timing_rules.json, and makes no external calls. It also discloses the response shape and the tax-present vs tax-absent branching, which the annotations cannot convey. Minor internal tension: it advertises Solar translation when lang='en' while also stating no external 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?

Labeled blocks (언제 / 반환) front-load the use case and the return contract, so an agent can scan it quickly. The only waste is the full Korean-English duplication of every line, which roughly doubles length without adding information.

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

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

With no output schema, the description steps in to describe the return object (규칙 array with 세목/구분/항목/시기/예외/근거, plus 시행본 and 주의), which is what an agent needs to consume results. Combined with read-only and data-source disclosure, only the lang/Solar translation path is left slightly underspecified.

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, and the description goes beyond it by explaining the branch semantics: passing tax yields tax-keyed rules, omitting it returns common rules plus per-tax counts. It does not clarify kind or keyword behavior beyond the schema's own text.

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

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

Names the resource precisely (timing rules table) and enumerates the four rule families it covers: tax liability establishment, P/L business-year attribution, income receipt timing, and VAT supply timing, all with statutory basis. That is enough to separate it from law_article or basic_rules, though it never explicitly contrasts itself with those siblings.

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 "언제" block states the triggering condition and backs it with three concrete scenarios (December delivery/January payment, advance-issued tax invoice, deemed bonus attribution), which is unusually actionable. It stops short of naming an alternative tool or a when-not case, so it earns 4 rather than 5.

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

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

Goes well beyond the annotations: discloses the auto-extraction limitation and that amendments/exchange of notes are flagged in the 개정 문서 언급 field and must be verified before applying, plus a 1-day response cache, no API key required, and a public source (국세법령정보시스템). readOnlyHint is echoed but the caveat, caching and provenance context are net-new information.

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 a one-line English purpose, then clearly labeled blocks for when-to-use, return shape and caveats. Every sentence carries a constraint or routing fact; nothing is padded.

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

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

There is no output schema, but the description inlines the return structure (국가, 발효일, 제한세율 with per-income rates and 요건, plus 주의 and 링크), and adds the amendment and domestic-law caveats. An agent has everything needed to call it and interpret the response.

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%: lang, income and country are all documented in the schema, including the default of all three income types and the requirement for a Korean country name. The description adds no syntax or format detail beyond what the schema already carries, 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 resource and scope: treaty withholding caps on dividends, interest and royalties with clause text, plus a one-line example question it answers. It explicitly carves out the boundary against the sibling tax_treaty ("조문 전체는 tax_treaty"), so an agent can distinguish the two 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?

Has an explicit 언제 (when) section keyed to a real question type ("미국 법인에 배당하면 몇 %?"), names the alternative tool for full article text, and rules out domestic taxes such as local income tax ("지방소득세 등 국내법은 별도"). When-to-use, when-not-to-use, and the alternative are all present.

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 openWorldHint, so safety is covered. The description adds genuinely new behavioral context: it states the tool is 읽기 전용, that statute checking requires LAW_OC, and that '확인' means existence only (not content match). The one gap is that it doesn't warn about unverified/failed lookups beyond naming the 결과 values.

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 English purpose statement, then uses compact labeled sections (언제 / 반환) so an agent can scan quickly. The enumerated return keys are dense but each carries meaning; there is little 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?

With no output schema, the description correctly takes on the burden of describing the return shape (문서번호/조문/요약/주의) and the caveat about existence vs. content. Auth prerequisite (LAW_OC) and the existence-only semantic are covered, leaving little an agent needs that 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 text, lang and as_of fully. The description adds no syntax or format detail for these parameters, so the baseline 3 applies; its detail is spent on return values rather than inputs.

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: 'Check that cited rulings, decisions and statute articles actually exist.' It also explicitly scopes itself against content-matching siblings, noting that '확인'은 존재만 뜻함 and that content verification belongs to get_tax_ruling·law_article. An agent can distinguish it from verify_statement and law_article without opening a schema.

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

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

Gives an explicit trigger ('언제: AI나 사람이 쓴 초안을 내보내기 전') and the goal it serves (filtering fabricated document numbers and non-existent articles). It also names the alternative tools for the adjacent task of content matching, so the when/when-not boundary is clear.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, but the description adds value: the LAW_OC API dependency, an explicit no-fabrication guarantee ('지어내지 않는다'), and the rule logic that triggers each verdict. These are behavioral traits the 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?

Purpose and usage are front-loaded in two short lines, and the return block is dense but justified since there is no output schema. The verdict-rule sentence is long and nested, costing some readability, but no sentence is wasted.

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

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

With no output schema, the description fully carries the return contract: the verdict enum, the signal-based rule, the 0.5 overlap threshold, and the shape of 대조/단서 arrays. Combined with API and read-only notes, an agent has everything needed to invoke and interpret 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%, so all six parameters are already documented in the schema; the description adds no per-parameter syntax or format detail (e.g., how paragraph '②' interacts with article). Baseline 3 applies 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 precise verb (글자 수준 대조) and resource (조문 원문), plus the exact output signal ('모순 신호(숫자·양태·반대말·시점)와 단서 누락'). An agent can immediately tell this is a statement-vs-statute comparison tool, not a search or lookup tool, distinguishing it from siblings like law_article or find_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?

The '언제' line gives explicit context ('보기 문장·주장·고객 진술이 특정 조문과 맞는지 확인할 때') and an exclusion ('법적 판단을 대신하지 않는다'). It does not name a sibling alternative (e.g., verify_citations) or say when NOT to use it versus those, so it falls 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.