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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior: results come with follow-up identifiers for subsequent lookups. However, it says nothing about pagination despite a cursor parameter, or about the perSource cap, both of which materially affect how the agent calls it.

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

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

Two sentences, no waste. The scope-and-output statement comes first, and the usage cue follows, which is the right ordering for an agent scanning for relevance.

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

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

There is no output schema, and the description only says results carry identifiers — it doesn't indicate how results are grouped by source or what a partial/empty source yields. Combined with the undocumented cursor and perSource, the definition is adequate but leaves real gaps for a 4-parameter aggregation 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 only 25% — only 'issue' is documented in the schema. The description explains the issue concept and nods at source types via '법령 조문 / 행정규칙 / 판례·심판례·해석례', but leaves cursor, perSource, and the four rulingSources enum values (court, constitutional, tribunal, moleg) completely unexplained in either place.

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 ('모아 ... 돌려줍니다') and enumerates the three source families it bundles: statute provisions, administrative rules, and ruling/tribunal/interpretation candidates. It implicitly differentiates itself from single-source siblings like find_statute or find_rulings by emphasizing aggregation ('한 번에'), though it never names those siblings explicitly.

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 positive trigger: '검토메모 작성의 첫 단계로 사용하세요,' which tells the agent this is the entry point before follow-up reads. It does not state when to prefer the granular siblings instead, nor any exclusions, 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.

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered; the description adds what is actually compared (existence, deletion, 항·호 range) and what is deliberately not evaluated. It does not say what a mismatch report looks like or how mass citations affect runtime, and there is no output schema to fill that gap.

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

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

Two sentences: the first front-loads the action, input domain, and comparison target; the second is a single, high-value scope exclusion. No restatement of the tool name and 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?

Given three simple parameters and no output schema, the agent knows what is checked, against what source, at what time basis (via asOf in the schema), and what is explicitly out of scope. The only shortfall is that the shape of the result — per-citation status list versus aggregate summary — is left implicit.

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 draft, asOf, and defaultLaw are already documented in the schema. The description only echoes the input by quoting the citation format ('법인세법 시행령 제89조제3항') and does not explain the effect of asOf or defaultLaw beyond the schema, 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 concrete verb+resource: extract statutory citations from a draft and verify their existence, deletion status, and article/paragraph range against the 법제처 original text. It distinguishes itself from lookup siblings (find_statute, read_provision) by operating on a draft document rather than on a single provision, and it names the boundary case ('같은 법 제52조') it handles.

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

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

Gives a clear triggering context — 의견서·검토메모·답변 초안 — and an explicit exclusion ('문언의 의미가 맞는지까지는 판단하지 않습니다'), which usefully routes semantic questions to provision-reading/interpretation tools. It never names a specific sibling as the alternative, so the when-not guidance is stated as a scope limit rather than as 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?

The annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety needs no restating. The description does add one real behavioral constraint beyond that, namely that only the most recent amendment is covered. It says nothing about how the comparison is structured or how results are paginated, even though a cursor parameter 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?

Two short sentences, front-loaded with what the tool returns before the filtering note. Nothing is padded, but the second sentence largely restates what the article parameter's schema description already says, so it earns only partial credit.

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

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

For a 3-parameter read tool with full annotations, the description covers what is returned and the main scoping limit. It leaves gaps that matter for correct invocation: whether the comparison spans a selectable period or only the newest amendment, how cursor paging behaves, and what comes back when a law had no recent revision.

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 law and cursor are fully documented in the schema and the description repeats no value there. The only parameter the description touches on, article filtering, is already described in the schema with examples. This is the expected baseline when structured fields carry the load.

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 a concrete resource: shows the pre/post wording of a statute's most recent amendment (신구조문 대비표). An agent can tell what the tool returns. It does not, however, distinguish itself from the sibling trace_amendments, which on its name alone sounds adjacent, so a reader is left to infer the division of labor.

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

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

Usage is only implied: use it to see old-vs-new text, and use the article parameter to narrow to one provision. The '최근 개정' phrasing implicitly scopes it to the latest amendment, which is useful. But no explicit when-to-use, when-not, or pointer to alternatives such as trace_amendments or read_provision is given.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is fully covered. The description adds domain behavior — it is a pure computation that returns a threshold judgment, not a lookup — but says nothing about return shape, rounding/unit conventions, or how the 5% vs 3억원 branch is resolved. Useful context, not rich 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?

One sentence, zero filler, computation and judgment front-loaded in that order. It is dense enough that the two distinct operations (calculate, then judge) run together, but nothing is wasted and no restatement of the title appears.

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 closed-world pure-computation tool with no output schema, the description covers what goes in (balance segments, actual interest received) and what comes out (적수, 인정이자, a threshold verdict). Gaps are minor: output field naming and how the two threshold criteria (5% ratio vs 3억원 absolute) are combined are left implicit.

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

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

Schema coverage is 100%, so baseline is 3. The description earns one step above baseline by explaining the relationship between parameters: segments feed the 적수 calculation and receivedInterest is the comparison base for the threshold judgment, which is meaning the schema's per-field descriptions do not convey. ratePct, rateKind, and yearDays are still left entirely to the schema.

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

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

The description states a specific verb+resource pair: computing 적수 (day-weighted balance) and 인정이자 from 특수관계인 가지급금 balance segments, then judging the 부당행위계산 threshold (5% or 3억원). No sibling tool (find_statute, estimate_tax, estimate_penalty, entertainment_limit, etc.) covers this computation, so the agent can distinguish it without opening the schema. It stops short of explicitly naming an alternative for the same task.

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

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

The description implies the usage context (특수관계인 loans, comparing computed vs. actual interest) but never states when to pick this tool over e.g. estimate_tax or when it does not apply. No prerequisites, no exclusions, no mention of what data must be gathered first (balance change history) before calling.

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

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

The annotations already declare readOnlyHint, idempotentHint, non-destructive behavior, and closed-world scope, so the safety profile is covered. The description adds the calculation basis—basic limit based on SME status and fiscal-year months, and a revenue-based limit including 10% related-party transactions—but does not explain how optional parameters such as spent or passiveCompany affect the result.

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

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

The description is two focused sentences with no filler. The primary purpose is front-loaded, followed by the key calculation factors.

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 seven-parameter tax calculator with no output schema, the description explains the core calculation and names the main factors. It leaves some gaps around optional-parameter behavior, especially spent and passiveCompany, and the exact output structure is only implied by '한도와 한도초과액'.

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 high at 86%, so the baseline is 3, but the description adds meaningful relationships: it connects sme and months to the basic limit, and revenue and relatedRevenue to the revenue-based limit with a 10% related-party rate. It does not mention passiveCompany or clarify the optional spent parameter's effect, so it is not fully comprehensive.

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

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

The description uses a specific verb, '계산합니다' (calculates), and a precise resource, '법인의 기업업무추진비(접대비) 손금 한도와 한도초과액'. It also scopes the calculation to SME status, fiscal-year months, and related-party revenue, which clearly distinguishes it from broader sibling tools such as estimate_tax.

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

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

The description states what the tool calculates but gives no guidance on when to use it versus alternatives like estimate_tax or estimate_penalty. It also provides no prerequisites, exclusions, or when-not-to-use conditions.

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

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

While the annotations cover safety (ReadOnly), the description adds crucial behavioral context by identifying the core logic—calculating penalties based on specific filing types and applying reduction ratios according to National Tax Law Article 48. This explains the 'how' and 'why' of the calculation.

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 uses two concise sentences, each serving a critical function: the first defines the calculation and legal basis, and the second defines the strategic use case.

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 100% schema coverage and the ReadOnly nature of the tool, the description provides all necessary contextual and logical information an agent needs to invoke the tool accurately for its designed purpose.

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?

Since the schema coverage is 100%, the baseline is 3. The description significantly elevates this by providing domain expertise (e.g., defining '무신고' and '과소신고' contextually within the workflow) which helps the agent select the correct `kind` enum value.

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 purpose is perfectly clear: it calculates specific types of taxes (non-filing, under-reporting, late payment) and applies specific statutory rules (Article 48 reduction rates). It clearly differentiates itself from other research tools like estimate_tax.

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

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

The usage guideline is explicit: 'Use for comparing burdens by amended filing timing' (수정신고 시점별 부담 비교에 사용하세요). This guides the agent on the specific analytical use case for this tool.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the bar is lower; the description still adds real behavior by disclosing that years not registered in the system are not computed, which tells the agent to expect a no-result case. It stops short of saying how that failure surfaces (error vs. null) or what the returned result looks like.

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

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

Two sentences, no filler, with the core computation and the two tax-type branches front-loaded and the year-registration caveat placed last. Every clause carries information an 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?

For a five-parameter computation tool with full schema coverage, strong annotations, and no output schema, the description covers the essential: what is computed, from which input, per tax type, and the registration constraint. The main remaining gap is return-value detail — '누진 구간별로' hints at bracket-level breakdown but does not confirm the output shape.

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 every parameter (taxType, taxBase, year, months, fiscalStart) is already documented with units and roles. The description's mapping of fiscalStart to corporate and year to personal merely restates the schema descriptions, and it never touches the proration semantics of 'months'.

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 (계산합니다) and a specific resource (산출세액) and scopes it to exactly the two supported tax types with progressive-bracket computation. It implicitly separates itself from the other calculator siblings (estimate_penalty, entertainment_limit, deemed_interest) by naming the tax types, but never explicitly contrasts with them.

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

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

Usage is only implied: compute output tax from a tax base. The sentence '등록되지 않은 연도는 계산하지 않습니다' is a precondition rather than routing guidance, and no alternative or exclusion is named (e.g., when to use estimate_penalty instead). An agent can infer intent but gets no explicit when/when-not rules.

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, open-world, so the safety profile is covered. The description usefully adds that results include per-statute definitions plus 출처 and that 'law' filters the result set — behavior the annotations do not convey — but says nothing about result volume, ambiguity handling, or empty results.

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

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

Two short sentences, zero filler: the core behavior and the optional-parameter effect, each front-loaded. Nothing redundant with the title or schema.

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

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

For a simple two-parameter lookup with full annotation coverage, the description conveys what is returned (definition and source per statute) and how the optional parameter changes it. Minor gaps only: no output shape detail and no guidance for terms with no definition.

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

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

Schema coverage is 50%: 'law' is documented in the schema and the description adds its filtering semantics, while 'term' has no schema description but is explained through the examples in the description. That partial compensation for the gap lands at the baseline for mid coverage.

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: shows the legal definition and source of a term, per statute, with concrete examples (특수관계인, 사업연도, 내국법인). An agent can distinguish it from find_statute/read_provision, though it never names a sibling explicitly.

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

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

The second sentence explains the effect of supplying 'law' (narrowing to that statute's definitions), which is implied usage guidance. There is no explicit when-to-use-versus-alternative statement or exclusion, e.g. versus find_statute when the term itself is unknown.

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 safety is covered. The description adds real value beyond them: the coverage gap for 국세청 기본통칙 and the dual search-vs-fetch-by-id mode of operation. It does not mention pagination behavior or result-set shape, which keeps it from a 5.

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

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

Two sentences, front-loaded with the search-and-read capability, with the source-coverage caveat following as a natural qualifier. Dense but every clause carries information; the parenthetical examples slightly crowd the first sentence.

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 five parameters, no required fields, and no output schema, the description covers the core usage story and the key data-source limitation. However, it leaves the agent without any notion of pagination (limit/cursor) or what inBody toggles, which is a meaningful gap for a paginated search tool.

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

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

Schema coverage is only 40%, so the description must compensate — but it only restates the two parameters the schema already documents (query, id). limit, cursor, and especially inBody are undocumented anywhere, and inBody is behaviorally significant enough that an agent cannot infer its effect from the name alone.

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

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

The description names a specific resource (행정규칙 — 훈령·예규·고시) and two concrete operations: keyword search via query and body retrieval via id, with a worked example (법인세 사무처리규정). It is clearly distinguishable from find_statute/read_provision by resource type, though it never names those siblings explicitly.

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 genuine routing signal by stating that 국세청 기본통칙·집행기준 are absent from 법제처 data and must be looked up in 국세법령정보시스템 — an explicit 'this tool will not cover that' exclusion. It stops short of naming a sibling tool to use for the alternative source, so the agent must infer the 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?

Annotations already declare readOnly, idempotent, open-world, non-destructive, so the safety profile is covered. The description usefully adds that results carry file download links (HWP/PDF), which annotations cannot express, but it says nothing about result-set size or the limit=50 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?

A single front-loaded sentence that names the resource and the return value with zero filler. It is efficiently sized, though the brevity is also why usage and parameter guidance are absent.

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 naming the downloadable file links. For a 3-param read-only lookup with rich annotations, this is close to sufficient, losing points only for the unexplained byLawName search mode and pagination behavior.

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

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

Coverage is 67%: query's example and byLawName's law-name-vs-form-name switch are documented in the schema, but limit is undocumented there. The description adds nothing to any parameter, so it neither compensates for the limit gap nor clarifies the two search modes beyond the schema.

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

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

States a specific verb (찾기) and two concrete resources (시행규칙 서식/신고서·명세서 and 별표/세율표·기준표), plus the output (HWP/PDF download links). This is clearly distinguishable in substance from a statute-text tool, though it never names a sibling to contrast with.

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?

No when-to-use framing, no mention of when to prefer find_statute or read_provision, and no prerequisites. The byLawName toggle changes the entire query semantics but the description gives no hint that this alternative search mode exists.

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/non-destructive, so safety is covered. The description adds real behavioral context: it is a single federated search across four heterogeneous corpora, and results carry source and id fields suitable for hand-off to read_ruling. It does not mention result limits, ranking, or what an empty result means.

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

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

Two short sentences with the main action front-loaded and the follow-up instruction at the end. The parenthetical court=/constitutional=/tribunal=/moleg= mapping duplicates the sources parameter's enum description verbatim, which is the only wasted text.

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 must carry return-value information, and it only tells us results expose source and id. It says nothing about result shape beyond that, whether perSource caps results per corpus or overall, or how to interpret a query that matches nothing in one source.

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 75%, just under the threshold where the schema alone would suffice. The parenthetical source mapping merely restates the sources field's own enum description, adding no new meaning, and perSource (1–30, default 5) has no description anywhere, so its per-source semantics are left unstated. The query example lives in the schema, not the description.

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 enumerates the four ruling resources covered (법원 판례, 헌재 결정, 조세심판원 심판례, 법제처 해석례), which implicitly separates it from statute-oriented siblings like find_statute and read_provision. It also names read_ruling as the downstream tool. It does not explicitly contrast with find_statute or find_admin_rule, so differentiation is inferred rather than declared.

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?

"결과의 source/id를 read_ruling에 넘기세요" gives an explicit chaining instruction to the follow-up tool, so the agent knows this is the discovery step and read_ruling is the retrieval step. What's missing is a negative case (when to use find_statute or find_admin_rule instead) and any statement that the four source values can be mixed or narrowed per query.

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 general read-only annotations, the description adds the crucial detail that law names (abbreviations) are automatically expanded. This is a specific functional trait that significantly helps the agent understand the tool's capability.

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 extremely concise, using two efficient sentences to cover what it finds, how to input it, and how to use the output with other tools.

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

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

The description is highly complete for a search tool by specifying the range of laws found (statutes, decrees, rules) and the practical implication of the results (direct pass-through to the reader tool).

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

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

The description clarifies the semantic difference in the query parameter by mentioning that it can be used for either full law names or section body keywords, and adds the logic of automatic abbreviation expansion.

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

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

The description clearly states the purpose is to find statutes, enforcement decrees, and rules. It distinguishes itself by specifying that it uses both law names and body keywords for searching.

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 provides clear usage instructions regarding the output: the resulting law names can be passed directly to other relevant sibling tools like read_provision. This helps an agent chain operations correctly.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds genuine behavioral detail beyond that: country queries are filtered to treaties, and keyword returns only matching excerpts of the body rather than the full text. It says nothing about pagination, result limits, or response shape.

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

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

Two sentences, front-loaded with the primary lookup mode and immediately followed by the id-based read mode. Every clause carries information; only the trailing keyword clause is slightly belabored by its three examples.

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 five-parameter, no-output-schema tool, the description covers the main retrieval paths well but omits pagination behavior (limit/cursor) and any hint about the shape of returned results. An agent would know how to search but not how to page through large result sets.

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 only 40%, so the description must compensate. It explains query (country name), id (body lookup), and keyword (substring filter on the body), which is solid for three of five parameters, but limit and cursor receive no explanation anywhere, leaving pagination semantics opaque.

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

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

The description names a specific resource (조세조약/이중과세방지협약) and two concrete operations: lookup by country name and body retrieval by id, with worked examples (미국, 베트남, 일본). It also states that country-name queries are restricted to tax treaties only, which implicitly separates it from find_statute. It stops short of naming that sibling explicitly.

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

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

It clearly explains the two invocation modes — pass a country name to get a filtered treaty list, or pass an id to read the body — and gives keyword examples (배당, 이자, 고정사업장) for narrowing within the body. No explicit when-not or alternative-tool routing is given, 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.

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the description's job is added behavior — and it delivers: asOf reaches past and future in-force versions, scheduled-but-not-yet-effective amendments trigger an attached warning, and omitting article silently changes the return type to a TOC. Pagination via cursor is left to the schema, and no note is given on behavior for an unknown law/article.

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

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

Three short sentences, each carrying distinct information: what is fetched, what asOf does plus its warning side effect, and the TOC fallback. The core retrieval statement is front-loaded with zero 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 does cover the realistic return shapes (provision text, TOC, amendment warning), which is the important part for a 5-parameter read tool. It does not address failure modes (unknown law name, article out of range) or how the [MORE] cursor interacts with the TOC mode, leaving a small gap.

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

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

Schema coverage is 100%, so the baseline is 3; the description still earns credit by explaining that article's absence switches output to a TOC and that asOf can address future versions, not just historical ones. It adds no syntax help for article/paragraph beyond the examples already in 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 (조문 원문) with clear scope (특정 조문 및 항). It also distinguishes the degenerate mode (article 생략 → 목차) that siblings like find_statute or compare_revision do not offer.

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 the two operating modes and when to use each: supply article for text, omit it for the article table of contents, and use asOf for a historical/future version. It does not explicitly route the agent away from siblings such as find_statute for discovery or trace_amendments for amendment history, so it stops short of full when-not 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, so the safety profile is covered. The description adds that it returns body content (요지·주문·이유), but it never mentions pagination even though the schema exposes a `cursor` parameter — a meaningful behavioral gap for a document-fetch tool.

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

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

A single sentence with no filler, and the dependency on find_rulings output is front-loaded ahead of the content listing.

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 usefully names what comes back (요지·주문·이유). For a read-only lookup with annotations, that is nearly sufficient; only the cursor/pagination behavior is left unexplained.

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?

At 50% schema coverage, the description covers the two required parameters (source, id) and implies the returned sections, but says nothing about `cursor` (undocumented in both places) or `sectionsOnly` narrowing. Partial compensation only, so 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 (읽습니다/read) and resource (요지·주문·이유 등 본문) and explicitly positions itself downstream of the sibling find_rulings. An agent can tell immediately that find_rulings searches while read_ruling fetches full 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 phrase 'find_rulings 결과의 source와 id로' gives a clear usage context: this tool is called after a search, using values from that result. No exclusions or alternative paths are stated, so it stops 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 readOnly, idempotent, non-destructive, so safety needs no restating. The description adds useful search semantics (keyword matches 부칙 text mentioning a specific 조문), but says nothing about what comes back — full 부칙 text, matched excerpt, or structured fields — leaving the main behavioral question open.

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

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

Three tight sentences: what it finds, the decision it supports, then the narrowing option. No filler and the core purpose is front-loaded.

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

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

For a six-parameter read tool with a fully described schema and safety annotations, the description covers purpose, trigger, and filtering adequately. The one gap is return shape: an agent cannot tell whether results are verbatim 부칙 clauses or paraphrased, which matters for a legal-research tool.

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

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

Schema coverage is 100%, so all six parameters including law, asOf, limit, cursor, keyword, and promulgatedOn are already documented. The description only enriches 'keyword' slightly (filter to 부칙 that mention a given 조문), 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: finds 시행일, 적용례, and 경과조치 within 법령 부칙, and gives a quoted example of 적용례 phrasing. It is clearly distinct from read_provision (본문 조문) by naming the 부칙 section explicitly, though it never names that sibling.

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

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

Explicitly says to use it when judging from which 사업연도/귀속연도 a revised provision applies, which is a concrete task trigger. It also explains the keyword-narrowing option, but gives no when-not guidance or named alternative among the many siblings (find_statute, read_provision, trace_amendments).

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is added context — and it delivers the 5-year correction window and the weekend/fixed-holiday rollover rule, which is a real behavior the agent would otherwise miss. It does not state what the response contains, but that is the main remaining gap.

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

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

Two dense sentences, zero filler, with the core purpose front-loaded before the holiday-rollover caveat. Nothing is wasted or buried.

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 an 8-parameter calculator with no output schema, the description enumerates the outputs conceptually but says nothing about the return shape — notably it never mentions the remaining-days figure that the `today` parameter and its '남은 일수' description imply. It also doesn't flag that non-fixed holidays (설·추석) must be supplied via extraHolidays; that only surfaces in the 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 coverage is 88%, so the schema already documents nearly every parameter including the periodEnd mapping per 세목 and the assessmentCase enum. The description only restates the kind/periodEnd framing and the 5-year constant, adding no format or interaction detail beyond the schema; 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 enumerates the four concrete deadline resources it produces (법정신고기한, 경정청구 5년, 부과제척기간 만료일, 후발적 경정청구 기한), keyed on 세목 and 과세기간 종료일. That is enough to separate it from estimation siblings like estimate_tax/estimate_penalty, though no sibling is named explicitly.

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 purpose implies when to call it (when a statutory date is needed), but there is no explicit when-to-use/when-not or routing to alternatives such as estimate_penalty or read_provision. The agent must infer the boundary between 'compute a deadline' and 'estimate an amount'.

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

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

The annotations already establish that this is a read-only, idempotent, non-destructive, open-world operation. The description adds useful behavioral context that supplying an article changes the output to mark textual-change points, but it does not describe return shape, pagination behavior, or result size.

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

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

Two sentences, front-loaded with the main behavior and followed by the intended use case. There is no redundant or filler content.

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

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

For a read-only tool with fully documented parameters and no output schema, the description covers the core behavior and intended use. It could be stronger if it briefly explained the pagination or output format, but nothing critical for invocation 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 explains law, depth, cursor, and article. The description adds meaning for article by saying it triggers marking of changed versions, but it does not add syntax or constraints beyond the schema.

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

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

The description states a specific action: listing statute versions by enforcement date and, when an article is supplied, marking when that article's text changed between recent versions. This clearly identifies the resource and behavior, but it does not explicitly distinguish the tool from siblings such as compare_revision or read_provision.

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 use case: checking applicable provisions by attribution year. It does not name alternatives or exclusions, so an agent must infer when compare_revision or read_provision would be better.

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, non-destructive, so the safety profile is covered. The description adds that results come from 3단 비교 자료 and that article narrows output to related blocks, but says nothing about result volume or that pagination exists despite a cursor parameter.

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

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

Two sentences, no filler, with the primary capability front-loaded and the article-filter behavior second. Slightly terse given the tool's complexity, but nothing 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?

A read-only, open-world lookup with no output schema needs the description to set expectations about the 3단 비교 structure and paging. The description hints at block structure but omits pagination behavior and does not describe what the compared tiers look like.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the effect of article — it filters the returned blocks to those related to that article — which the schema only labels as '조문번호'.

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: shows where a statute article is delegated or cited, using 법제처 3단 비교 data. This is clear enough to distinguish it from find_statute / read_provision, though the description never names those siblings explicitly.

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?

Use is implied by '위임/인용' terminology and the delegated/cited modes, but there is no explicit statement of when to prefer this over find_statute, read_provision or check_references. The agent must infer routing from the tool name.

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