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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds genuine behavioral context beyond the structured fields: tables are returned as HTML table markup specifically to preserve merged cells, and numbered-less annexes must be targeted via keyword instead of annex_no. That is useful operational detail.

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 domain-priority bracket is front-loaded, followed by behavior and then a concrete example. It is appropriately sized with no obvious filler, though the bracketed routing note and the parenthetical example make it slightly denser than strictly necessary.

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

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

With no output schema, the description still explains the return shape (a list, or HTML table for extracted annexes) and the two-call pattern, which is enough for an agent to call it correctly. It leaves minor gaps such as pagination or size limits on large annexes, but is otherwise complete for this read-only 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 is 3. The description exceeds the baseline by explaining the interplay between keyword and annex_no (keyword to filter/single out un-numbered annexes, annex_no to extract the table) and by giving a worked law/keyword example, adding workflow meaning the schema 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?

The description states a concrete verb+resource pair (returns a law's annex/form list, and extracts the table content of a selected annex) and clarifies its financial/tax/accounting specialization. It tells the agent this tool is the priority for tax-rate tables and useful-life tables/forms, but it does not explicitly contrast itself against sibling fin_article, so differentiation from the closest sibling is implied 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 clear usage context: prioritize this tool for tax/accounting tables and forms, and it spells out a two-step workflow (call with keyword, confirm the number in the list, re-call with annex_no). No explicit when-not or excluded scenarios are provided, keeping it short of a 5.

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

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

Annotations already declare readOnlyHint and idempotentHint, so safety is covered, but the description adds genuinely valuable behavioral context: the call is a multi-part bundle returned 'in one shot', and the ruling candidates come from a title-keyword search whose applicability is explicitly unverified (적용 관계 미확인). That disclaimer is exactly the kind of caveat an agent needs. It does not, however, mention result size, truncation, or what happens when an article number does not exist.

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 domain and routing directive; each clause earns its place by naming a distinct part of the returned payload, and the example is embedded compactly rather than given its own 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 no output schema, the description carries the full burden of describing return values — and it does so by enumerating every component (본문, 위임 시행령·시행규칙, 예규 후보, 별표, 개정 정보) plus the reliability caveat on the 예규 portion. For a read-only lookup tool with 100% parameter coverage, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including the 약칭 allowance, the '제10조의2' article format, and the basis_date default. The description only echoes the schema's own caveat about keyword-based ruling search and repeats an example article, adding little beyond structured data — 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 bracketed opener states a specific domain (재무·세무·회계 전용) and an explicit precedence rule (세법 조문 질의에는 이 도구를 우선 사용), then enumerates precisely what a single-article query returns: article body, delegated 시행령/시행규칙 articles, 예규 candidates, 별표, and amendment info. The example (법인세법 제26조) makes the unit of work unambiguous, and it is clearly distinguishable from fin_law_search / fin_ruling_search / fin_annex.

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 when-to-use direction ('use this tool first for tax-law article queries') and frames itself as 'the starting point for practical review', which tells the agent where it sits in a workflow. It stops short of naming the sibling tools it supersedes or stating a when-not condition (e.g., use fin_annex for annex-only lookups), so routing is implied rather than fully spelled out.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds real behavioral context beyond that: deterministic computation, output bundled with the calculation process and legal citations, and a scope boundary (ordinary employee severance unsupported). It says nothing about error behavior for out-of-range or unsupported inputs.

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 dense sentences, with the most actionable instruction (do not hand-calculate statutory limits) front-loaded in the bracket. It is appropriately sized for a 22-parameter tool; the supported-types list is a compact enumeration rather than filler.

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

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

For a complex multi-mode calculator with no output schema, the description covers supported calc types, scope exclusions, and what the response contains (process plus cited articles), while the oneOf schema handles conditional parameter requirements. An agent can call it correctly without guessing at the tool's boundaries.

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 22-parameter schema (including oneOf branches) already documents every field in detail. The description only clarifies the meaning/scope of each calc_type value, which the enum and per-parameter bracketed tags already convey, so it adds marginal value over structured data.

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 ('세법에 명문화된 산식을 결정형 코드로 계산한다') and enumerates all five supported calculation types, matching the calc_type enum exactly. It clearly reads as the calculator in a sibling set of search/verification tools, but it never names a sibling to differentiate against, so it lands at 4 rather than 5.

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

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

Gives an explicit use directive in the bracket ('법정 한도·세액은 직접 계산하지 말고 이 도구를 사용') and one concrete exclusion ('일반 근로자 퇴직금은 미지원'). It does not point to any alternative sibling (e.g., fin_verify for checking a result or fin_article for the source text), so no alternatives are covered.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint), yet the description adds genuine behavioral context beyond them: results are re-ranked by financial relevance, repealed/historical/scheduled-enforcement laws are flagged, and topical law hints are attached. It does not describe result shape, counts, or pagination.

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, with the most decision-critical information (financial-domain scope and priority) front-loaded in the bracket. Every sentence carries a distinct payload; only the bracketed form 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?

For a 3-parameter read-only search with fully documented schema but no output schema, the description supplies the missing pieces: output shaping (relevance re-rank, status flags, hints) and the downstream handoff to fin_article. Nothing essential to correct invocation is absent, though result size/format remains unspecified.

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

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

Schema description coverage is 100%, so all three parameters (query, basis_date, include_ordinance) are already documented with format and defaults. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource (법령을 검색) scoped to 재무·세무·회계, and explicitly differentiates its role from fin_article by noting article-level content is a separate step. An agent can tell it apart from fin_ruling_search and fin_annex without opening any schema.

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

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

The bracketed prefix gives an explicit priority rule ('법령 검색은 이 도구를 우선 사용') and the closing sentence names the alternative and the condition that selects it ('조문 내용까지 필요하면 fin_article로'). It stops short of explaining when a rulings tool (fin_ruling_search) should be preferred instead, so the routing is clear but not exhaustive.

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 declare readOnlyHint and idempotentHint, so safety is already covered; the description adds that it fires one real search request and honestly discloses a limitation (it may not catch API key typos). That side-effect and limitation detail is genuine value beyond the annotations, though the result 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?

Front-loaded with a domain tag and the core action, then the checklist and usage triggers. Dense but every clause (what is checked, the typo caveat, when to use) carries information; only minor trimming is possible.

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 zero-parameter, no-output-schema diagnostic, the description covers scope, checks performed, a known limitation, and usage timing. It could say a bit more about what the response reports (pass/fail per check), but nothing essential for calling 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?

The tool takes zero parameters and the schema is empty, so the baseline of 4 applies. Nothing about argument semantics needs explaining.

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 — diagnosing the fin-law-mcp server connection/configuration — and enumerates exactly what is checked (server liveness, API key presence, live 법제처 response via a light search). This is clearly distinguishable from the sibling lookup tools (fin_law_search, fin_article, etc.).

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 names the two triggering situations: post-install verification and root-causing lookup failures. It does not name alternatives or explicit when-not conditions, but the diagnostic vs. search split with siblings is implied clearly 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 declare readOnlyHint and idempotentHint, so safety is covered. The description adds real behavioral context beyond that: it returns a merged list, and it discloses sorting behavior (most-recent-first where domain ordering is verified, otherwise date order with the reason stated). It does not cover pagination or result limits.

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

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

Dense single paragraph with no filler; the priority directive and the alternative are front-loaded. Slightly heavy nesting of clauses, 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 no output schema, the description compensates by naming the returned fields (document number, date, title) and the ordering behavior. Safe-read profile is covered by annotations. Complete enough to call correctly, with only pagination/limits left 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 description coverage is 100%, so baseline is 3. The description restates the four search domains (mapping to the domains enum) and reinforces the basis_date cutoff semantics, but adds no syntax or format detail 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 (search) and enumerates the four aggregated resources (NTS rulings, Tax Tribunal decisions, MOLEG interpretations, court precedents across all instances) plus the returned fields. It also distinguishes itself from sibling fin_law_search by scoping to '재무·세무·회계 전용' and routing full-text needs to fin_nts_ruling.

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 tool first for rulings/tribunal/precedent queries and names the alternative (fin_nts_ruling) for retrieving ruling body text. The when-to-use and the alternative are both stated, leaving nothing to inference.

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

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

Annotations only cover readOnly/idempotent, but the description goes well beyond: it defines the 3-value return, states it will not disguise errors as '없음', flags that 국세청 기본통칙·집행기준 are absent from the DB and marked ⚠ without number verification, and marks deleted articles as ⚠ (사용 보류). This is exactly the behavioral context an agent needs.

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

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

The priority-usage directive is front-loaded and the behavioral rules follow in a logical order with no filler. It is dense rather than verbose, though the single long sentence packs several distinct constraints together, slightly reducing scannability.

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 discharges it: it defines the three possible verdicts and the scope limit ('✓ = existence of the number only, not 항·호 or content'). Alternatives and edge cases (deleted articles, DB-missing sources) are all covered.

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

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

Schema description coverage is 100%, so both parameters (text, basis_date) are already documented with types and one inline hint ('생략 시 현행'). The description adds no additional parameter syntax or format detail, so the baseline 3 applies.

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

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

States a specific verb and resource: it verifies the existence of cited statutes/articles/administrative rules by cross-checking the 법제처 DB and returns a 3-valued result. It also explicitly differentiates itself from the sibling fin_article by declaring that content-correctness checking belongs there, so an agent can route between them without opening a schema.

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

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

The bracketed lead states the preferred use case ('우선 사용' for citation verification in review/answer drafts) and names the alternative tool (fin_article) with the exact condition that selects it (content verification). Both when-to-use and the sibling boundary are explicit.

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