Lifelaw Korean Law (라이프로 법령)

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add output-shape context — and it does: changed text marked in 【 】, the delegation vs citation distinction, the length warning, and that English input yields an English answer. Pagination behavior is only implied via the schema, which keeps it below a 5.

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

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

Front-loaded with the core purpose and the two modes, then per-kind definitions, then practical notes. Dense but every sentence carries information; the mixed Korean/English parentheticals add length but are necessary for the domain terminology.

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, no-output-schema tool, the description covers output formats, scoping advice, and the edition modifier. Minor gaps remain around paging behavior and default page size, but the schema already documents the page parameter, so an agent can call this correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description goes further by defining what each kind enum actually returns and by explaining that edition=시행예정 surfaces amendments promulgated but not yet in force. That is genuine meaning beyond the terse enum labels.

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 a Korean law's articles before and after amendment') and immediately names the two distinct modes (신구법 vs 3단 비교), which cleanly separates it from siblings like get_article or get_law_status that fetch rather than compare.

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

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

Gives a concrete usage constraint: three-tier output is long, so an article should be supplied — that steers the agent toward narrowing the scope. It also explains when each kind applies (amendment text vs delegation vs citation), though it never explicitly says when to prefer a sibling tool over this one.

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), and the description adds substantive content: the answer is verbatim and unedited, en returns the official English translation plus a version-match notice plus the binding Korean original, and 시행예정 returns not-yet-in-force text. That is real behavioral context beyond the structured fields, especially valuable since there is no output schema.

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

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

Front-loads the core action and scope in the first sentence, then layers the lang and edition behavior. It is dense and slightly long, but every sentence carries information an agent needs; nothing 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 read tool with five parameters and no output schema, the description covers what is returned and the two edition modes well. Minor gaps remain: no mention of what happens when the law name is ambiguous or the article does not exist.

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 adds meaning by explaining why lang defaults to en for English law names and what edition 시행예정 means operationally (promulgated but not in force). It does not add anything for article or branch, which the schema already covers well.

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

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

States a specific verb and resource ('Get the text of an article of a Korean law in force') plus provenance ('verbatim and unedited from the Ministry of Government Legislation'). This clearly separates it from search_law (finding laws) and get_law_status (checking amendment status), which the description itself references.

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 clear context for the 시행예정 path and explicitly tells the agent to first check with get_law_status whether a promulgated amendment exists. It also explains the lang default rule for English law names. It does not spell out when to prefer this over siblings like get_document, but the core usage routing is 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 destructiveHint=false, so safety is covered structurally. The description adds genuinely non-obvious behavioral context beyond that: precedents are decisions on individual cases, are not law, and may later change — an important caveat for an openWorldHint source. It does not describe pagination or size of the full text, which is a minor 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?

Three sentences, front-loaded with the resource and its returned components, then the caveat, then the parameter note. The only inefficiency is the final sentence, which largely duplicates the input schema's parameter description rather than adding to it.

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 has to carry return-value meaning, and it does by listing the four sections returned. Combined with the caveat about precedents not being binding law and the id provenance hint, an agent has everything needed to call this correctly on the first try.

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 the single parameter's description already explains that id is the digits from a search_case result, not the case number such as 2018다287034. The description restates this same point with no additional semantics, so the schema does the work and a 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?

The description names a specific verb and resource ("Get a Korean court precedent") and enumerates the returned components (판시사항, 판결요지, 참조조문, 판례내용). This clearly separates it from siblings like get_article, get_interpretation, and get_law_status, which cover other document types.

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

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

It establishes the retrieval flow by stating the id comes from search_case results, which tells an agent to search first and fetch second. It also warns that precedents are reference material that may change, which frames appropriate reliance. However, it never states when *not* to use this tool (e.g., when get_article would be the better source for statutory text).

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 read-only/idempotent/non-destructive profile, and the description adds real operational detail beyond them: 15,000-character page chunking, the fact that annexes and forms have no body, and that HWP is unsupported. It does not say what happens on an invalid page number or a failed PDF fetch, but the substantive behavior is disclosed.

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 primary behavior, then the pagination limit, then the annex/forms exception and its filtering options. Dense but every sentence carries information; the parenthetical Korean term is the only mild 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 still explains what comes back (summary, order, reasons sections), how large a page is, and how the annex path differs, which is enough to call the tool correctly. Remaining gaps, such as end-of-document signaling or error cases, are minor.

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%, yet the description still adds meaning: file is only for annexes/forms and must be the PDF link, page maps to 15,000-character chunks, and keyword is scoped to annexes with two lines of surrounding context. That is genuine semantic value over the schema 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?

States a concrete verb and resource (fetch full text of one Korean decision, interpretation, or other material) and ties it to the search_documents result set. It never distinguishes itself from similarly named siblings like get_case or get_interpretation, so an agent could hesitate between them, but the scope of returning an entire document body is clear.

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

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

Explicitly frames the tool as a follow-up to search_documents (id, source, file all come from a search result) and gives a clear routing rule for annexes/forms: use the PDF file link rather than expecting a body. It lacks an exclusion statement against overlapping siblings such as get_case or get_interpretation.

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 genuine context beyond them — that interpretations are non-binding reference material that may later change — but says nothing about response size, missing/removed interpretations, or error behavior when an id is invalid.

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 you get, why to be careful with it, and how to supply the id. The most decision-relevant fact (the id source) is front-loaded and 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?

For a single-parameter, no-output-schema retrieval tool this is complete: the description names the returned fields in lieu of an output schema, states the domain caveat, and removes the one likely id-confusion failure mode.

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 the description restates the schema's own id note nearly verbatim ('the number from search_interpretation results (not the item number 안건번호)'), adding no new meaning. Per the high-coverage baseline this lands at 3.

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

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

The description uses a specific verb ('Get') and a specific resource ('Korean statutory interpretation') and enumerates the returned sections (질의요지, 회답, 이유). The caveat that this is not law and the pointer to search_interpretation separates it from the get_tax_interpretation sibling corpus.

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 workflow prerequisite: the id must come from search_interpretation results, and it explicitly warns against passing the 안건번호 item number. It also frames when the content is appropriate to rely on ('reference material, answers to individual questions, may change later'), though it never names an alternative tool to use when a binding statute is actually required.

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 the description is free to add substantive behavior: it discloses that changed articles and addenda (effective dates, transitional provisions) are included, and that an English law name triggers an English answer plus a check of whether the official translation matches the version in force. That is real context beyond the structured fields, though it does not cover size or limits of the returned article list.

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

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

Three sentences, front-loaded with the core in-force/amendment status, with details layered after. The parenthetical glosses on 시행예정 and 부칙 earn their place for disambiguation, though the third sentence is slightly dense.

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 must describe return content, and it does: the effective date, pending-amendment flag, affected articles, addenda details, and translation-match status. For a single-parameter read tool this is nearly complete, lacking only any note on response shape or limits.

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 the single parameter already documents that Korean or English official names are accepted. The description restates the English-name capability (adding that the reply language follows the input) but adds no format or matching rules 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 specific verb and resource: shows a Korean law's effective date in force and whether a promulgated amendment is not yet in force. This is clearly distinguishable from siblings like get_article, search_law, or compare_law, which retrieve text or compare versions rather than reporting in-force/upcoming status.

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 implied by the described output (effective date, pending amendment, addenda), but the description never states when to pick this over search_law or get_article, nor any prerequisites. The English-name behavior hints at a use case but is not framed as 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 declare the read-only, idempotent, open-world profile, so the bar is lower. The description still adds genuine context beyond them: the data is Lifelaw-verified, comes with a legal basis article, verification date, and start date of effect, and is labelled bilingually — all useful for deciding whether to trust and how to present 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?

It is front-loaded with the verb and examples, then closes with the key-discovery pointer. The opening sentence is dense — describing the return fields before the reader knows what the tool is for — but every clause carries 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 only two parameters, full schema coverage, and no output schema, this description is complete: it explains what is returned (value, legal basis, verification date, effect start date, labels), where the data comes from, and how to find a valid key. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the key format and date semantics (default today) are already documented. The description adds value by pointing to list_params as the way to obtain valid keys, which is not in the schema and prevents guessing at lowercase dot-separated identifiers.

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 ("Get a Korean legal reference value") and grounds it with concrete examples (statutory interest rate, minimum wage, lease renewal request period). Those examples make it clearly distinguishable from siblings like get_article or get_case, which return legal text rather than curated reference values.

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 routing for the common blocker: "Find keys with list_params," which tells an agent where to go before invoking this tool. It does not state when to prefer this tool over get_article/get_interpretation for the same subject, but the reference-value scope is clear enough.

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), so the description's job is to add rendering and scale facts — it does: annex tables are returned 'line by line' as text, and a notice body is chunked at 15,000 characters per page. It does not describe failure behavior (e.g., unknown rule name) or whether an outline is truncated.

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?

Dense and front-loaded: the default case (name only) comes first, then each optional parameter's effect, then the constraint and the special case. Every clause carries operational information; nothing 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?

With no output schema, the description partly discharges the burden by sketching each return shape (article list plus annex list, article text, text-rendered annex). Still missing are the outline's exact form, how many pages exist for a long annex, and error behavior — minor but real gaps for a 5-parameter fetch 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 baseline is 3, but the description adds real meaning beyond the schema: the mutual exclusion of article and annex, that page means annex page normally but body page for a notice without articles, and that keyword matches on annex/notice-body lines with two lines of surrounding context.

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 ('Get a Korean administrative rule in force') and enumerates the three retrieval modes (outline, article, annex), which makes the tool's behavior distinct. It does not explicitly contrast with the closest sibling, search_rule, leaving the search-vs-fetch boundary to be inferred.

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?

Strong conditional guidance: 'With only name: an outline', 'with article: that article's text', 'with annex: the annex', plus the exclusion 'article and annex cannot be combined' and the notice special case. The gap is that it never says when to use this instead of search_rule or get_article.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. Beyond that the description discloses the return shape per mode (outline vs. item text vs. keyword matches) and the source system, which is genuinely useful behavioral context; only pagination/limit behavior is left implicit in the schema.

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

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

Front-loaded with the purpose and the domain gloss, then the three mode rules, then the allowed-values list. Every sentence carries information, though the long enumeration of law names adds bulk that could have been trimmed or truncated.

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 output schema and no enums, the description supplies the missing pieces an agent needs: what each mode returns and which law names are valid. Remaining gaps, such as page-size limits and how outline entries are structured, are minor for a read-only lookup 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 the baseline would be 3, but the description adds real meaning: it explains how the optional parameters change the result shape rather than just what they are, and it enumerates the 15 available laws, effectively constraining the required `law` value where the schema has no enum.

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

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

States a specific verb and resource ("Get Korean tax basic rulings") and defines the resource ("the National Tax Service's standards for applying tax law articles"), plus a clarifying note that "Basic rulings are not law". It distinguishes the resource conceptually, but does not name nearby siblings such as get_rule or search_rule to pin down the boundary.

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 explicit invocation contexts: law alone returns an outline, item returns that item's text, keyword returns matching items. That is clear operational guidance for choosing among the tool's own modes, but there is no statement about when to prefer a sibling tool or when not to use this one.

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, non-destructive semantics, so the bar is lower; the description still adds real value by explaining the 15,000-character paging behavior and by warning that an interpretation answers an individual question and is not binding like law. It omits any note on rate limits or what happens when an ID is not found, which keeps it 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?

The first sentence front-loads the verb, resource, and return contents; the ID provenance and paging rules follow in a logical order. The final clause about interpretations answering individual questions and not being binding is valuable but slightly crowds the sentence, so the text is dense rather than wasteful.

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 properly compensates by listing the returned fields and explaining the paging of long documents. Combined with annotations covering the safety profile, an agent has nearly everything needed to call it, with only error and rate-limit behavior unaddressed.

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 both parameters are documented there, including the 18-digit ID / link format and the page minimum and default. The description only restates that the id comes from search results or a link and that pages are 15,000 characters, adding marginal meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get one Korean tax interpretation'), names the issuing authorities and the source system, and enumerates the returned parts (summary, body, related laws). It is clearly distinguishable from the sibling search_tax_interpretation, which produces the IDs this tool consumes.

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 tells the agent where the id comes from (search_tax_interpretation results or the original link), which gives a clear usage context. It does not, however, explain when to pick this over the similarly named get_interpretation or get_document siblings, so the routing is not fully closed.

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, non-destructive, open-world behavior, so the safety profile needs no restating. The description adds real value beyond them: an authority caveat ("not law but rulings on individual cases, and may change later") that affects how the agent presents the result, plus the crucial id-provenance warning that prevents a common wrong-key error. It does not describe result size or pagination, 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?

Three short sentences, front-loaded with what the tool returns, then the reliability caveat, then the id rule — a sensible order with no filler. The id sentence partly duplicates the schema description, which is the only redundancy.

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

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

There is no output schema, so the description correctly spends its words enumerating the returned sections, and it supplies the authority caveat and key format an agent needs to call and present results properly. Only minor gaps remain, such as expected result length or whether referenced decisions are returned as identifiers.

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

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

With a single parameter at 100% schema description coverage, the schema already states that the id is the first number of a search_tax_tribunal result and not the claim number. The description restates essentially the same constraint, adding emphasis but no new semantic detail. Baseline 3 is appropriate where the schema carries the parameter burden.

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

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

The description opens with a specific verb and resource ("Get a Korean Tax Tribunal decision") and then enumerates the exact contents returned: order, claim, summary, related laws, referenced decisions, reasons. That vocabulary is distinct from the case/interpretation/law siblings, so an agent can route correctly 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?

It establishes the workflow explicitly by tying the id to "search_tax_tribunal results," which tells the agent this is a follow-up call rather than a lookup entry point. It also warns that decisions are rulings on individual cases, not law, which frames when the output is appropriate to cite. It stops short of naming an alternative for when the user wants statutory authority (e.g. get_article), so it isn't a full when/when-not treatment.

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 and non-destructive, so safety is covered. The description adds the useful detail of what the listing contains (key, Korean and English names, unit), but says nothing about ordering, pagination, or how large the full list is when unfiltered.

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 resource declared first and the filtering capability second. No filler, nothing repeated, and the key information is front-loaded.

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

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

With no output schema, the description compensates well by naming the returned fields, and this is a simple single-optional-parameter read tool. Minor gaps remain around result ordering and behavior when no prefix is supplied.

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 the schema's own prefix description already supplies example values (rates, labor, jutaek, store). The description only restates that the prefix corresponds to a field, adding essentially no meaning 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?

The description states a specific verb (List) and resource (Korean legal reference values), and enumerates the returned fields (key, Korean/English name, unit). It is clearly distinct from lookup siblings like get_param and get_article, though it never names the singular sibling get_param 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 notes that results can be filtered by field key prefix, which implies when the prefix argument is useful, but it gives no explicit when-to-use/when-not guidance or contrast with get_param for fetching a single value. Usage must be inferred.

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 open-world, so safety is covered. The description adds useful context beyond that: the text is read from the NTS-published PDF, the result shape differs per mode, and the keyword/item mutual exclusion is stated. It stops short of pagination or edition-default behavior for the year 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?

Front-loaded with the definition, then mode behavior, then the availability list. The trailing enumeration of fifteen statutes is long, but it is genuinely useful domain scope rather than filler; a couple of clauses (the parenthetical glossary) could be tightened.

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 and five parameters, the description carries the return-value burden and does so for all three modes, plus it discloses the source of the text and the supported tax domains. Only paging behavior across large result sets 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?

Schema coverage is 100%, so the baseline would be 3, but the description goes further by explaining what each parameter combination actually changes in the response (titles vs. full item text vs. title keyword match) and by enumerating the accepted law values, information not present 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?

The description names a specific verb and resource ('Get Korean tax enforcement standards'), defines the resource precisely (the NTS compilation of Act, Decree, rulings and interpretations), and explicitly separates it from statutory law ('Enforcement standards are not law'), which is exactly the distinction an agent needs against siblings like get_article and search_law.

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 clear mode-selection guidance keyed to the parameters: law alone returns titles, law+item returns that item's text, keyword searches titles. That is real routing advice, but it never names a sibling alternative for the 'I want the actual statute text' case, so exclusion guidance is implied rather than 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered; the description adds genuine context beyond that — the Korean-language input constraint, the semantic nature of the results, and the ID-extraction rule needed to chain into get_case. It does not mention result volume, pagination limits, or ranking, so it stops short of fully describing the response 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?

Four short sentences, front-loaded with the core action, then the input constraint, then the conceptual caveat, then the chaining instruction. No filler or repetition of the title.

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

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

For a two-parameter search with no output schema, the description covers the essentials an agent needs: what is searched, language constraint, what results conceptually are, and how to use result IDs. It omits any indication of result-set size or what fields each result carries, which matters somewhat given the absent output schema.

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

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

Schema description coverage is 100%, with both `query` (Korean search terms with an example) and `page` (page number from 1, default 1) already documented in the schema. The description only reinforces the Korean-language requirement for `query` and adds nothing about `page`, 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 and resource ("Search Korean court precedents (판례) by keyword") and immediately distinguishes the resource from its lookalikes by clarifying that precedents are decisions on individual cases, not law — separating it from siblings like search_law, search_rule, and search_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?

Gives a clear precondition ("Search terms must be in Korean") and a concrete follow-up workflow ("Use the first number of each result ... as the id for get_case"), which tells the agent both how to call it and what to do next. It never explicitly says when to prefer this over search_law or search_interpretation, leaving that routing to inference from the "precedents are not law" line.

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, so the bar is lower, and the description still adds behavior the annotations don't: a hard Korean-language input constraint, the id-extraction convention for chaining into get_document, and the caveat that decisions and interpretations are reference material rather than law. It omits result volume, ranking, and pagination behavior beyond the schema's page field.

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 grouping with English glosses helps an agent pick a source value, but roughly half the text is a near-duplicate of the enum that is already fully described in the schema. A long inline enumeration of ~50 agencies makes the definition heavy for the marginal selection value it adds.

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 burden of explaining results, and it does supply the one thing an agent needs to chain calls (the id is the first number of each result). Combined with the source taxonomy and language constraint, that is close to complete for a four-parameter search tool; pagination behavior is the main 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 description coverage is 100%, so the schema already documents query, source, page, and body_search; the description is required to do little. The description's source taxonomy largely restates the enum (though it usefully groups it and glosses the Korean names in English), and it adds only the Korean-language constraint on query — it never mentions body_search or page.

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 gives a clear verb plus resource ("Search Korean decisions, interpretations and other materials (법제처) by keyword") and the bulleted source taxonomy makes the scope concrete. It partially differentiates from siblings by routing 국세청·재정경제부 queries to search_tax_interpretation and result retrieval to get_document, but it never explains how it relates to the overlapping search_case and search_interpretation tools.

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

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

It gives real usage context: pick the material via `source`, queries must be in Korean except for 영문법령, and the first number of each result is the id to pass to get_document — a concrete follow-up workflow plus one explicit exclusion. It stops short of stating when to prefer this over search_case or search_interpretation, which appear to overlap heavily.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely new context: the authoritative status of the material ('not law but reference material') and a structural hint about the result format (first field is an id). It does not mention pagination limits or approximate result volume, which is a minor gap given the page 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?

Four short sentences, front-loaded with purpose, then the language constraint, then the caveat about legal weight, then the next-step pointer. No filler and nothing repeated from the schema beyond a necessary constraint reminder.

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 return-value disclosure and does so partially by explaining that each result begins with an id usable in get_interpretation. For a two-parameter, read-only search tool this is nearly complete; a note on paging through large result sets would close the remaining 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 description coverage is 100% and the schema already documents both query (Korean terms with an example) and page (from 1, default 1). The description only restates the Korean-language requirement, adding no meaning about paging behavior or how many results a page holds, 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?

The description names a specific verb and resource ('Search Korean statutory interpretations') and defines the resource inline (법령해석례: replies by the Ministry of Government Legislation on how laws apply), which separates it from search_case, search_law and search_tax_interpretation. It also points forward to get_interpretation, so the search-vs-fetch split is unambiguous.

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 constraint ('Search terms must be in Korean') and an explicit follow-up path ('Use the first number of each result as the id for get_interpretation'), which routes the agent correctly within the sibling set. It stops short of stating when not to use it, e.g. when the question is about tax rulings rather than statutory interpretations.

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 behavior, so the safety profile is covered. The description adds real behavioral context beyond that: Korean abbreviations are expanded to official names, and English queries match official English titles and return both Korean and English names. It does not mention result limits or pagination, which keeps it 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?

Four short sentences, front-loaded with the core purpose, then abbreviation behavior, English behavior, and the sibling hand-off. Every sentence carries distinct information with no restatement of the name or title.

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 single-parameter read tool with no output schema, the description covers purpose, input interpretation, and enough about returned names to set expectations. It stops short of describing result ordering or limits, a minor gap given the tool's simplicity.

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 would be 3, but the description adds genuine semantics: the query may be Korean or English, abbreviations are normalized, and English queries behave differently (matching English titles and returning bilingual names). That is meaning the schema's example list alone does not convey.

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 laws of the Republic of Korea in force") plus the searchable facets (name, promulgation and effective dates). It is clearly separable from siblings like search_law_by_question, get_article, and search_case 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?

Gives an explicit routing rule: "Use this first when you do not know the official law name," and names the alternative for a different input style ("To ask in a sentence, use search_law_by_question"). Both when-to-use and when-to-use-something-else 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 readOnly, idempotent, openWorld, non-destructive, so the safety profile is covered. The description still adds non-obvious behavior: results are relevance-ranked and may include loosely related articles, which is exactly the caveat an agent needs before trusting output. It does not mention result count or pagination behavior beyond the schema's page param.

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

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

Three sentences, front-loaded with purpose, then the language constraint, then the scope option and the verification advice. No filler; the bilingual parenthetical and example earn their space by preventing malformed queries.

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-only search with no output schema, the description covers the input contract (Korean question, scope) and the critical downstream step (verify with get_article). It could say more about what the result set looks like, but the essential calling information 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 the baseline is 3. The description does add some meaning beyond the schema — the Korean-sentence requirement with an example, and the gloss that 행정규칙 covers 고시 and 훈령 — but leaves page/result-size behavior 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 and resource — finding Korean law articles from a natural-language question — and pins the method ('법제처 intelligent law search') plus the article-level granularity. It does not explicitly contrast with the sibling search_law (keyword search), so the differentiation is inferable rather than stated.

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 real usage conditions: the question must be a Korean sentence (with a worked example), and scope 행정규칙 selects administrative rules. It also prescribes the follow-up step 'check the text with get_article'. What is missing is an explicit statement of when to prefer this over search_law or search_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 read-only, idempotent, non-destructive, open-world behavior. The description adds useful behavioral context beyond them: only rules in force are searched, query terms must be Korean, and administrative rules are agency-internal standards rather than laws; result pagination or format is not described.

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

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

Three sentences, front-loaded with the action and scope. The Korean-language requirement and the administrative-rule-versus-law distinction are important enough to earn their place.

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

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

For a simple one-parameter search with full schema coverage and annotations, the description supplies the critical language, scope, and domain boundary. It does not explain return contents or pagination, but the tool's complexity is low and no output schema 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 coverage is 100% and already documents the single query parameter with an example. The description adds meaningful constraint that search terms must be Korean and are words in the rule name, though the parenthetical about type, ministry, and dates does not clearly map to additional parameters.

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 Korean administrative rules in force, enumerates rule categories, and explicitly separates administrative rules from Acts/Decrees. An agent can distinguish this from search_law and related legal-search 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?

Explicitly says to use this first when the official rule name is unknown and warns that administrative rules are not laws. It does not explicitly name get_rule as the alternative once the official name is known, so the routing guidance is clear but not 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 declare readOnly, idempotent, non-destructive, open-world behavior, so the bar is lower. The description still adds genuine traits beyond them: results are ordered newest first, the query must be in Korean, and interpretations are reference material rather than law — a caveat an agent needs to interpret results responsibly.

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 action and packs ordering, the Korean-language constraint, the follow-up tool, and the agency default into a few tight sentences. It is slightly redundant in restating the schema's 'both agencies by default' behavior, keeping it from 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?

With no output schema, the description carries the return-value burden and does so adequately by explaining ordering and by pointing to get_tax_interpretation for full document reads. It does not describe the shape of search results or pagination beyond the schema's page parameter, 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 all four parameters are already documented in the schema, including the agency enum and the body_search toggle. The description largely restates those semantics (Korean-only query, both agencies by default) without adding syntax, format, or matching-behavior 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?

The description states a specific verb and resource — searching Korean tax interpretations from NTS and MOEF by title words — and adds scope details (newest first, title vs body). It does not differentiate itself from the sibling search_interpretation, which an agent would also see in the tool list, so it falls short of a 5.

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

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

It gives concrete usage context: use body_search to search the body instead of the title, omit agency to search both, and pass a result's 문서ID to get_tax_interpretation to read the full document. It never says when to prefer search_interpretation or another sibling, so it stops short of explicit alternatives.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds real context beyond them: results are ordered newest-decision-first, queries must be Korean, and the returned items are non-binding rulings rather than statutes.

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

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

Four short sentences, front-loaded with purpose and ordered-结果 behavior, each carrying distinct information. The 'not law but rulings' clarification is slightly parenthetical but earns its place by preventing misuse.

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 burden of explaining returns, and it does the most important part: identifying which number in each result is the id for get_tax_tribunal and warning against the claim number. It leaves page size and returned fields unspecified, a minor but real 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 page and query are already documented, making 3 the baseline. The description adds a genuine constraint the schema only implies through an example: the query text must be in Korean.

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+resource ('Search decisions of Korea's Tax Tribunal') and scopes it ('appeals against tax assessments'), which cleanly separates it from siblings like search_case, search_law, and search_interpretation. It also clarifies the nature of the resource ('not law but rulings on individual cases').

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

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

Gives a clear context for use (tax assessment appeals), a hard constraint ('Search terms must be in Korean'), and a follow-up route to get_tax_tribunal. It stops short of explicitly naming when a different sibling (e.g. search_case for court precedent) should be preferred instead.

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