taiwan-law-mcp

Does the description disclose side effects, auth requirements, rate limits, or destructive 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?

描述為單句，以主要動詞「將使用者輸入」開頭，直接切入核心功能，後續簡潔列出標示項目與限制，無冗詞，資訊密度高。

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?

對於僅一個參數、無輸出 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 已完整描述 text 參數（100% 覆蓋），描述本身未對參數添加額外語意或格式要求，因此依規則維持基線 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?

描述明確指出工具的核心功能：將使用者輸入初步分類為案例事實、法律問題或引註研究，並標示領域、隱私風險與建議檢索詞。這與其他搜尋/取得類兄弟工具形成明顯區隔，非僅重複名稱或標題。

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?

從描述可推知此工具用於初步分析使用者輸入以引導後續檢索，但未明確說明何時應使用此工具而非直接搜尋，也未提及替代工具或排除條件。使用時機僅是隱含而非明確陳述。

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?

No annotations are provided, so the description carries the full burden of disclosure. It reveals that the output includes official URLs and can include recent regulation messages (amendments, administrative rules), but it does not mention pagination, the definition of 'recent', or any potential limitations. The read-only nature is implicit in '取得' but not explicitly confirmed.

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 a single sentence that efficiently front-loads the core action and resource, then adds the optional feature and scope. Every phrase earns its place with no redundancy or 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?

The description provides the essential context: what is returned (list with official URL), optional inclusion of recent news, and scope limited to MOJ. However, with no output schema and no annotations, it omits details such as the exact list structure, how 'recent' is determined, and whether pagination is supported. These are notable gaps for a simple list-type 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 50% (only include_all_news has a schema description). The tool description adds meaningful detail to include_all_news by specifying it returns amendments and administrative rule releases, but it adds nothing about limit, which is already constrained by default/min/max in the schema. This partial compensation aligns with a baseline of 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 the verb '取得' (get) with a specific resource '法務部主管法規系統的法規草案預告清單' (MOJ regulatory draft announcement list) and explicitly notes the scope '涵蓋範圍限法務部'. This clearly differentiates it from sibling legal search tools by naming the unique resource and scope.

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 usage for obtaining MOJ draft announcements and optionally recent legal news, but it does not explicitly state when to use this tool versus siblings like search_taiwan_laws or get_taiwan_law_progress. No exclusions or alternatives are mentioned, but the specific domain provides clear context for appropriate use.

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?

With no annotations provided, the description carries full burden. It discloses default concise output, opt-in behavior for reasoning/opinions, token-saving strategy, and the 15,000-character truncation warning. This is transparent and sufficient for a read-only lookup 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?

Two dense sentences: the first states purpose/scope, the second gives parameter strategy and limits. Every clause contributes practical information, no filler.

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

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

No output schema exists, but the description tells exactly what default fields are returned (字號/日期/爭點/解釋文), how to get reasoning/opinions, and warns about truncation. This is enough for an agent to decide invocation and interpret results.

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 already covers all 5 parameters (100% coverage), giving baseline 3. The description adds meaningful layer: it explains precedence of keyword params over include_* flags, the default return level, and truncation behavior—adding value beyond the schema without fully detailing each parameter.

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 it retrieves content of specific 釋字 (No. 1-813) and 憲判字 (since 111), sourced from a local snapshot of official announcements. This specific verb+resource scope distinguishes it from sibling search/citation 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?

The description provides clear internal usage guidance: use keyword parameters first to save tokens, only use include_* for full text when needed, and warns about truncation. It lacks explicit reference to sibling alternatives (e.g., when to use search instead), but the direct-lookup nature is evident from the required case_id and default response behavior.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that citations are extracted from reasoning documents, that the direction is backward ('往前追溯'), and that context can be included as '前後 80 字片段' – useful behavioral details beyond 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?

The description is a single, tightly written sentence that front-loads the core action and then adds the optional context feature. No wasted words, and it is appropriately sized for the tool's complexity.

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 simple tool shape (2 params, no output schema), the description adequately explains the function and expected result (extracted citation numbers, optionally with context). It does not cover edge cases or output formatting, but that is not critical for this level of complexity.

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 parameters already have descriptions. The tool description adds minor value by specifying the exact context length (80 characters) for include_context, but it does not significantly enhance understanding of case_id beyond what the schema provides.

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

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

The description clearly states the tool extracts cited interpretation numbers (釋字/憲判字) from reasoning documents, with backward tracing. This specific verb+resource makes it distinct from sibling tools like get_taiwan_interpretation (which retrieves full text) and search_taiwan_interpretations (which searches content).

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 usage: use this tool when you need to find which earlier interpretations are cited in a given one. However, it does not explicitly name alternatives or state when not to use it, so an agent must infer usage from the purpose.

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?

Without annotations, the description discloses a key behavioral trait: the response may be cached for up to 6 hours (至多 6 小時邊緣快取) and indicates cached/retrieved_at markers. It also explains how to force a fresh fetch with fresh=true, adding meaningful operational context.

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

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

The description is two sentences, front-loaded with the main action, and no wasted words. It efficiently covers both purpose and usage caveats.

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 retrieval tool with 2 well-documented parameters and no output schema, the description covers essential aspects: what is returned, caching caveat, and refresh logic. It does not address error handling or missing judgments, but given the low complexity, this is nearly complete.

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 adds context for the fresh parameter by specifying when to set it (latest status or suspected removal). For the jid parameter, it does not add much beyond the schema, but the overall semantic gain is above baseline.

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 tool's function: 依司法院 JID 取得裁判全文與官方網址 (get full judgment text and official URL by JID). This is a specific verb+resource pattern that distinguishes it from sibling search tools like search_taiwan_judgments.

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 provides clear context for when to use the fresh parameter: 需最新狀態或裁判疑似已下架時 (when latest status is needed or judgment may be removed). It implies usage for fetching a specific judgment by ID, but does not explicitly compare with search 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?

No annotations are provided, so the description carries the full burden. It discloses the key behavioral aspects: the data source (LYAPI), the specific information returned (proposer, reading progress, status, dates, links), and the data license (CC-BY-4.0). It does not mention error handling or explicitly state that it is read-only, but for a query tool, this is reasonably transparent.

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 concise, with two sentences that front-load the main purpose and output. The license information is extra but relevant for usage. There is no fluff, and every sentence contributes to understanding the tool's function and data source.

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 should explain return values. It lists the key fields (proposer, reading progress, status, council date, document links) and mentions the data format implicitly via '每個修法提案'. However, it does not describe the structure (e.g., list of objects) or potential errors/limitations. Given the tool's complexity, this is fairly complete but not exhaustive.

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 not add parameter-specific meaning beyond the schema; it only describes the overall output. The schema already documents both 'law' and 'max_bills' with examples and defaults, so the description provides no additional parameter semantics.

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 tool's function: query the Legislative Yuan LYAPI to obtain the legislative history ('立法歷程') of a law. It specifies the returned data (proposers, reading progress, status, council dates, official document links) and explicitly positions it as supplementing the upstream process of '修法沿革', distinguishing it from sibling tools like get_taiwan_law_versions.

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 gives clear context for when to use this tool: to access the legislative process upstream of the amendment history ('補「修法沿革」上游'). It implies it complements the law versions tool but does not explicitly name alternatives or provide exclusion criteria. This is clear but could be more explicit about when not to use it.

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

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

With no annotations, the description carries the full burden. It discloses the data source (LYAPI), the type of data returned (dates, actions, main proposers), and the CC-BY-4.0 license. It does not cover behavior around missing laws, rate limits, or pagination, but the provided context is useful.

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 a single, front-loaded sentence covering the main purpose, followed by two short clauses with complementary context and license info. It is concise, with every part earning its place.

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

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

For a simple 2-parameter tool, the description gives a clear purpose, data source, key output fields, and license. However, it does not explain the 'limit' parameter's behavior or the full return structure, which would be helpful given the absence of an output schema and annotations.

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 schema covers only 50% of parameters (law has a description, limit does not). The description adds no parameter-level guidance, such as the meaning of 'limit' or its default/maximum values. This does not compensate for the low schema 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?

The description clearly states the tool queries LYAPI to obtain historical versions of laws, listing specific data fields (dates, actions, main proposers). It does not explicitly differentiate from sibling tools, but the focus on '歷次版本' (historical versions) is a specific, distinct resource.

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 says it complements the National Laws Database's amendment history, providing some context for when it might be used. However, it does not compare with sibling tools such as get_taiwan_law_progress or search_taiwan_laws, nor does it mention when not to use it.

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

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

No annotations are provided, so the description carries the burden. It discloses that fuzzy matching and suggestions are supported, which is useful behavioral context. However, it does not mention what happens when no match is found, the exact return format, or whether multiple pcodes may be returned. For a read-only conversion tool, this is adequate but not thorough.

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 a single, well-structured sentence. It front-loads the primary action and includes relevant qualifiers (common abbreviations, fuzzy matching) without any redundant or vague content. Every phrase earns its place.

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

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

For a tool with just one parameter, no output schema, and no annotations, the description covers the main purpose and behavior. It mentions fuzzy matching and suggestions, giving some idea of possible return variations. The only gap is the lack of an explicit return format, but the simplicity of the tool mitigates this. Overall, it is sufficiently complete for an agent to understand the tool's role.

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 schema provides 100% coverage for the single parameter (law_name) with examples. The description adds value by explicitly stating that common abbreviations like 勞基法 and 個資法 are accepted, which enriches the schema's explanation of valid inputs. This goes beyond the baseline for high schema 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?

The description clearly states the tool converts regulation names (including common abbreviations) to pcode codes, with fuzzy matching and suggestions. This specific verb+resource ('轉換為...pcode') distinguishes it from sibling search tools like search_taiwan_laws.

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 provides clear context: use this when you have a law name and need a pcode. It implies the tool handles abbreviations and fuzzy matching, but does not explicitly mention alternatives or exclusion conditions. Still, the scope is clear enough for an agent to select it appropriately.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It adds valuable non-obvious traits: real-time querying ('即時查詢') and no saved copies ('不保存副本'), plus the return payload structure. While it doesn't mention rate limits or auth requirements, it provides meaningful safety and behavior context beyond 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?

The description is a single, information-dense sentence that covers system, scope, return fields, and behavioral caveats. While slightly run-on, it avoids filler and front-loads the core purpose. Every clause contributes meaningful detail without excessive length.

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

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

For a tool with 3 parameters and no output schema, the description gives a comprehensive picture: what is searched, what is returned, the coverage limit, and the real-time/no-cache behavior. It lacks error-handling or pagination details, but these are not critical for a straightforward search tool given the schema's constraints.

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 67%, so the description is not solely responsible. It provides examples of keyword usage and lists document types akin to the doc_types enum, but it does not elaborate on the limit parameter or the full range of enum options. The added semantic value is modest and partially redundant with 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 clearly states the action: searching for administrative interpretations and related documents by keyword via a specific system (mojlaw.moj.gov.tw). It explicitly lists return fields (document number, date, summary, official URL) and restricts scope to MOJ competent authority documents, distinguishing it from sibling tools like search_taiwan_interpretations that likely cover judicial interpretations.

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 usage through the coverage constraint ('涵蓋範圍限法務部主管文書'), indicating it is for MOJ-related documents. However, it does not explicitly state when to use this vs. alternatives, nor does it reference sibling tools or provide exclusionary guidance. The scope statement gives context but no direct comparison.

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?

Without annotations, the description discloses the searchable fields and the return fields (bill number, name, proposer, status, related laws) and the data license (CC-BY-4.0). It does not detail pagination or any potential side effects, but for a search operation, this is adequate.

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 a single, information-dense sentence. It is front-loaded with the tool's purpose and includes necessary context about output and licensing without redundant phrasing.

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 covers the tool's purpose, searchable fields, return values, and data licensing. Given the absence of an output schema and annotations, it provides sufficient context for an agent to understand and invoke the tool, though it could mention parameter combinability.

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 80% schema coverage, the description adds value by clarifying that the keyword parameter performs full-text search across specific bill attributes, which is not fully explicit in the schema. It also provides examples for term and bill_status, complementing the schema's descriptions.

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

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

The description clearly states the tool's function: searching Legislative Yuan bills, including types like legal and budget bills. It specifies that keyword searches across bill name, reason, proposer, and description, which differentiates it from sibling tools that search laws or interpretations.

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 context by defining the resource (Legislative Yuan bills) and the types of items included, so an agent can infer when to use it. However, it does not explicitly name alternatives or exclusion criteria, so it stops short of a perfect score.

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?

No annotations are provided, so the description carries the burden. It discloses that the tool can list or full-text search, and that results include case_id. However, it does not mention behavioral aspects like pagination, default filtering (e.g., include_new/include_old), or the performance impact of deep search, leaving gaps for a tool with no annotation safety profile.

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 concise sentences in Chinese, front-loaded with the primary action and scope, followed by a useful workflow hint about case_id. Every sentence adds value with no redundancy or fluff.

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 search tool with 8 parameters and no output schema, the description adequately explains what it searches and how to use results, but it does not describe the result format beyond case_id, nor does it mention pagination or default filters. It is sufficient for basic use but leaves some gaps for interactive or advanced usage.

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 documents most parameters. The description adds context about search scope (title, issue, full text) which maps to the keyword parameter, but it does not elaborate on individual parameters like deep, year, or number ranges. It adds some value beyond the schema but does not fully complement the uncovered 12% of 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?

The description clearly states the tool lists or full-text searches Taiwan constitutional interpretations (釋字/憲判字), covering title, issue, and full reasoning. It also mentions the output includes case_id for direct use with get_taiwan_interpretation, which distinguishes it from sibling tools like search_moj_interpretations and get_taiwan_interpretation.

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

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

The description implies usage context: use this tool to search for interpretations and then pass case_id to get_taiwan_interpretation. While it does not explicitly state when not to use it or compare with other search tools, the case_id linkage provides clear guidance for a common workflow. It lacks explicit exclusions or alternatives, so not 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?

With no annotations provided, the description carries the full behavioral transparency burden. It discloses real-time operation, non-persistence of judgment content, sort order by court hierarchy, included result fields, and a critical caveat that candidates without a Judicial Yuan JID are for browsing only and must not be directly cited as court opinions. This is substantial, decision-relevant behavioral information.

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

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

The description is efficiently front-loaded with the core purpose, followed by structured usage patterns and integration guidance. It contains no filler, does not merely restate schema fields, and each sentence adds a new piece of actionable information that earns its place despite the density.

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

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

For a tool with 9 parameters, no annotations, and no output schema, the description is remarkably complete. It covers the search scope, result shape and ordering, case-number mapping, main_text semantics, combination with query, JID-based deduplication with semantic tools, and citation reliability caveats—enough for an agent to select and invoke the tool correctly in most situations.

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?

Although schema coverage is already 78%, the description adds significant meaning not inferable from the schema: it maps a full Taiwan case citation (114年度上易字第503號) to specific structured parameters (case_word=上易, case_number=503, year_from=114), explains the win/loss semantics of main_text terms (e.g., '被告應給付' = defendant lost), and notes that main_text can be combined with query. This makes the parameters genuinely more usable.

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+resource structure: '搜尋公開裁判' via the 司法院裁判書系統, making it immediately clear this tool searches public judgments. It adds scope details (real-time, no content storage, court-level ordering, result fields) and distinguishes itself from sibling search tools targeting legislation or interpretations, as well as from the more specific get_taiwan_judgment retrieval tool.

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

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

The description provides explicit practical usage rules: specific case numbers must use case_word + case_number + year_from rather than going into query; main_text can filter by outcome wording and may be combined with query; and when a semantic/conceptual search tool is also used, results should be run in parallel and merged via JID, with JID-less candidates downgraded to browsing-only. This is concrete when-to-use and integration guidance that goes well beyond general purpose.

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?

With no annotations provided, the description carries the full burden of transparency. It discloses important behavioral constraints: answers must include source_url, users must be reminded to verify the latest version, and results without an official identifier cannot be cited. It also mentions the optional legislative history feature, providing context beyond 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?

The description is concise and front-loaded, with the core purpose stated in the first sentence. Subsequent sentences provide essential usage rules without excessive verbosity. The final sentence is slightly dense with multiple constraints, but the overall structure remains efficient.

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 absence of an output schema, the description adequately conveys the return type (official URL and relevant articles) and optional legislative history. It also covers critical usage constraints (source_url, version verification, and deduplication rules). While it could describe the response structure in more detail, it is sufficient for a search tool with five parameters.

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 80%, so the baseline is 3. The description adds minimal parameter-specific meaning, only referencing the option to include legislative history (matching include_history) and real-time querying (aligning with fresh). Other parameters like limit and article_number are sufficiently documented in the schema, so the description does not need to compensate further.

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 tool performs real-time queries against the Ministry of Justice's national regulations database and returns official URLs and relevant articles. It also mentions the ability to include legislative history, which adds specificity, but it does not explicitly differentiate from sibling tools like search_taiwan_regulations.

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 provides contextual guidance such as requiring source_url inclusion, reminding users to verify the latest version, and deduplicating with pcode/law numbers when used alongside other legal retrieval channels. However, it does not explicitly state when to prefer this tool over alternatives, leaving usage context somewhat implied.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It adds relevant context beyond the schema: the data is an offline snapshot, responses are immediate, and the search is limited to regulation names. This is useful for setting expectations, though it does not mention staleness implications or matching semantics.

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 a single, front-loaded sentence that immediately states the action, scope, and return values. Every phrase earns its place—no filler, redundancy, or vague language.

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 search tool with no output schema, the description fully covers the search domain (regulation names), return fields (name, pcode, status), data source (offline snapshot), and performance (instant response). Pagination and filtering details are handled in the input schema, so no critical gaps remain.

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 each parameter (keyword, offset, exclude_abolished) having clear descriptions, defaults, and examples. The tool description adds no additional parameter-level insight beyond what the schema already provides, so the baseline score 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?

The description clearly states a specific verb and resource: '在 11,700+ 部法規（法律＋命令）名稱中做關鍵字搜尋' (do keyword search in names of 11,700+ regulations). It also specifies return fields (name, pcode, status), and the scope distinguishes it from sibling tools like search_taiwan_laws by covering both laws and commands.

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 a lightweight keyword-search use case with '離線資料快照，即時回應' (offline data snapshot, instant response), but it does not explicitly state when to use this tool versus alternatives such as search_taiwan_laws or search_taiwan_interpretations. No exclusions or alternative guidance are provided.

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