taiwan-law

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 clearly states the tool does not provide legal conclusions, which is a key behavioral trait, and describes the outputs it produces. It doesn't detail edge cases or error handling, but the core behavior is 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 a single sentence that packs the core function, output dimensions, and a critical limitation. Every clause earns its place with no filler or 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?

For a simple single-parameter classification tool, the description sufficiently conveys the role, outputs, and a caveat. Without an output schema or annotations, it does not specify the exact response format, but it provides enough for an agent to understand what the tool does and when to use it.

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

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

The schema already covers the single 'text' parameter at 100% with a description ('使用者的案例事實或法律問題') that matches the tool's purpose. The description adds no additional parameter-specific semantics 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 uses a specific verb '將使用者輸入初步分為' and enumerates the three concrete output categories (案例事實、法律問題或引註研究) plus additional outputs (領域、隱私風險與建議檢索詞). This clearly differentiates it from the sibling tools, which are retrieval/search 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 implies a preliminary classification role before legal research and explicitly sets a boundary ('不做法律結論'), giving clear context on when it applies. However, it does not explicitly name alternative tools or contrast with them, so it lacks explicit exclusions.

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. It discloses that the return includes an official URL and that enabling include_all_news adds recent regulation messages such as amended provisions and administrative rules. However, it does not describe pagination, ordering, authentication requirements, or the response structure, leaving some behavioral ambiguity.

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, front-loading the main action, then the optional behavior, then the scope restriction. Every phrase adds information without 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?

For a low-complexity tool with two optional parameters and no output schema, the description provides the core purpose, scope limitation, and optional behavior. It lacks response format details and limit semantics, but is sufficient for an agent to select and invoke the tool in most straightforward scenarios.

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 useful meaning by enumerating examples of regulation news ('修正條文、行政規則發布等'), which clarifies include_all_news. However, it does not clarify how limit interacts with include_all_news or whether limit applies only to the draft list, so compensation for the coverage gap is only partial.

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 ('法務部主管法規系統的法規草案預告清單' / MOJ regulatory draft announcement list), notes the inclusion of official URLs, and optionally describes returning recent regulation news. It also explicitly scopes itself to the Ministry of Justice ('涵蓋範圍限法務部'), which clearly distinguishes it from sibling tools covering broader Taiwan legal 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 for MOJ-specific draft announcements and related regulation news through the scope statement '涵蓋範圍限法務部', giving clear context. However, it does not explicitly mention alternative tools or state when NOT to use this tool, so the guidance is more implied than explicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses data source (local snapshot of official documents), response default, opt-in behaviors, token-saving rationale, and a 15000-character truncation warning, offering substantial behavioral 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 two sentences that efficiently front-load purpose and then detail usage nuances. Every clause adds value—no filler or 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?

Despite lacking an output schema, the description explains default response fields (字號/日期/爭點/解釋文), opt-in reasoning/opinions, and truncation warning. It covers the tool's full behavior adequately for an agent to use 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%, but the description adds critical semantics: the priority relationship between keyword and include parameters, why to prefer keywords (省 token), and full-text truncation behavior. This significantly enriches the bare schema 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: 取得釋字 or 憲判字 content, with specific scope (第 1-813 號, 111 年起) and resource type. It also lists default return fields, distinguishing 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 context: this is for direct retrieval of specific interpretations, with parameter-level usage guidance (prefer keyword snippets, use include_* only when necessary). However, it doesn't explicitly mention alternatives or exclusions relative to sibling tools like search_taiwan_interpretations or get_taiwan_interpretation_citations.

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 reveals that the tool only extracts citations within the reasoning, traces backward to earlier citations, and optionally includes surrounding text. This goes beyond the schema by specifying the 80-character context length and temporal direction. It doesn't detail edge cases (e.g., no citations found, invalid case_id), but for a read-only extraction tool, the key behaviors are sufficiently 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?

The description is a single, concise sentence that leads with the action ('從...理由書中抽取') and front-loads the core functionality. Every element earns its place—describing the source, the extraction type, the backward-citation direction, and the optional context. No wasted words.

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

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

Given the tool's simplicity (2 parameters, no output schema), the description is complete enough to understand the return value: a list of cited interpretation numbers with optional context. It covers the input generation and output type without needing an explicit output schema. Minor gaps include unspecified response structure when no citations exist, but the core usage is fully specified.

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 adds value by elaborating on include_context: it specifies that the excerpt is '前後 80 字片段' (80 characters before and after), which is more specific than the schema's '每個引用附上原文片段'. It also reinforces case_id's format by referencing get_taiwan_interpretation, aiding correct invocation.

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 the reasoning of a specified 釋字/憲判字, with an optional 80-character context excerpt. This specific verb-resource pairing ('抽取引用的其他釋字與憲判字字號') distinguishes it from sibling tools like get_taiwan_interpretation (retrieving a single interpretation) and search_taiwan_interpretations (searching by keywords).

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 conveys a clear context: given a case_id, retrieve the older interpretations it cites, going backward in time. It implies the tool is used for citation relationships rather than general retrieval, but it does not explicitly name alternatives or state when not to use it. The '往前追溯' phrasing provides directional context, making the use case 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?

With no annotations, the description carries the full burden and discloses a key behavioral trait: up to 6 hours edge caching, indicated by cached/retrieved_at fields, and the option to force a fresh fetch. It also hints at removal handling. This is valuable transparency, though it doesn't mention error behavior or authentication.

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 primary purpose, and every clause earns its place. It efficiently covers purpose, caching behavior, and fresh parameter usage without fluff or 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?

For a simple retrieval tool with two parameters and no output schema, the description is complete. It explains the primary return (full text and URL), mentions cached/retrieved_at fields, and provides fresh usage context. It gives enough information for an agent to select and invoke the tool 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%, providing parameter descriptions for both jid and fresh. The description adds meaning by explaining when fresh should be true (latest status or suspected removal), going beyond the schema's 'skip edge cache, force fetch' wording. This extra usage context raises it above the baseline 3.

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

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

The description clearly states the tool retrieves the full text and official URL of a judgment by JID, using a specific verb (取得) and resource (裁判全文與官方網址). It distinguishes from sibling tools like search_taiwan_judgments (search) and get_taiwan_interpretation (different document type).

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 JID to retrieve the full text. It also gives specific guidance on when to set fresh=true (need latest status or suspected removal). However, it does not explicitly name alternatives or exclusions, though the JID-based purpose implicitly differentiates 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 mentions the data source, license, and return content, but does not explicitly state read-only behavior, rate limits, or error handling. The description is not misleading but lacks rich behavioral 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 description is extremely concise—two sentences—with the main action front-loaded, followed by specific data points and licensing context. Every word earns its place with no 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?

Given the simplicity (2 params, no output schema) and lack of annotations, the description is fairly complete: it states the purpose, the fields returned, and how it relates to other tools. It could mention return structure, but it lists the key data points, making it adequate.

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% with descriptions for both parameters, so the baseline is 3. The tool description does not add extra parameter-level detail beyond what the schema already provides, but it does not need to.

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 the Legislative Yuan LYAPI to obtain a law's legislative process, listing specific data points (proposers, reading progress, status, dates, document links). It distinguishes from siblings by focusing on 'legislative progress' rather than law versions or bill search.

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 explains this tool complements the 'amendment history' upstream legislative process, implying usage when the legislative journey of a law is needed. However, it does not explicitly name alternative tools or state when not to use it, leaving some ambiguity.

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 returned fields (date, action, main sponsor), and the license (CC-BY-4.0), which is valuable. However, it doesn't mention pagination, rate limits, error behavior, or any constraints, leaving notable transparency gaps.

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 three concise sentences, each adding distinct value: purpose, complementary context, and licensing. There is no fluff or redundancy, and the structure is easy to parse.

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 with no output schema or annotations, the description covers the basic purpose, source, and some output fields, but it omits the 'limit' parameter's behavior and does not describe the return structure. The complementary note adds context, but the gaps in parameter and output detail make it only moderately 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 50%: 'law' has a description, but 'limit' does not. The tool description adds nothing about the 'limit' parameter, its default, or its maximum, and it merely repeats the law parameter's meaning already present in the schema. The description fails to compensate for the missing limit field, so it provides little semantic value beyond the schema.

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

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

The description clearly states the action ('查立法院 LYAPI 取得法律歷次制定/修正版本') and the specific resource (law amendment history), and it mentions the output fields (dates, actions, main sponsor). However, it does not explicitly distinguish this tool from sibling tools like get_taiwan_law_progress, so it stops 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?

The description provides a clear context by stating it complements the National Laws Database's amendment history, giving the agent a sense of when to use this LYAPI-based tool. It lacks explicit exclusions or direct comparisons to sibling tools, but the complementary note offers useful 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?

No annotations are provided, so the description carries the burden. It discloses fuzzy matching and suggestions, but does not explain output format, error behavior, or exactly how suggestions are returned. For a simple conversion tool, this is minimal but not severely lacking.

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

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

One sentence that is front-loaded and contains no redundant information. It immediately states the conversion purpose and includes useful examples without 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 simple one-parameter tool, the description covers the core purpose and fuzzy matching, but without an output schema, the return format is not explained, and usage guidance is missing. It is adequate but leaves gaps for an agent.

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

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

Schema coverage is 100% and the schema already describes the law_name parameter with examples. The description adds similar examples and mentions fuzzy matching, but does not add significant new parameter semantics beyond the schema.

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

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

The description clearly states a specific verb (轉換) and resource (法規名稱 to pcode), and distinguishes from siblings by focusing on pcode conversion rather than searching or retrieving laws. Examples of common abbreviations further clarify the 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 when a pcode is needed from a law name, but does not explicitly state when to use this tool over alternatives like search_taiwan_laws or get_taiwan_law_versions. There is no mention of exclusions or prerequisites.

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. It discloses real-time querying and that no copies are saved, and it identifies the source system. It also notes the coverage limit. However, it omits potential rate limits, error handling, or whether authentication is required. Still, the disclosed behaviors are meaningful and not redundant.

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: the first states the action and return fields, the second adds scope and behavioral attributes. Every sentence earns its place; no redundant information 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?

For a search tool with three parameters and no output schema, the description adequately covers purpose, scope, behavior, and what is returned (document number, date, summary, URL). It lacks mention of result ordering, empty-result behavior, or pagination details, but these are not critical for basic use. The coverage is sufficient for an agent to invoke the tool appropriately.

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 67% (keyword and doc_types have descriptions; limit does not). The description aligns with the schema by mentioning the document types and providing context, but it does not add new meaning to parameters. Limit remains undocumented in both schema and description, though its meaning is fairly obvious.

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 specifies the action (search), the resource (法務部主管法規查詢系統), and the document types (行政函釋、法規諮詢意見、法律問題座談等), plus the return fields. The mention of '法務部' and the specific system URL distinguishes it from sibling tools like search_taiwan_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 provides clear context: coverage is limited to MOJ-administered documents and it is a real-time query. This implies when to use the tool (MOJ administrative interpretations) but does not explicitly name alternatives or state when not to use it. The scope is clear enough for differentiation, yet exclusions are not 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?

No annotations were provided, so the description carries the full burden. It discloses the return fields (bill number, name, proposer, status, related laws) and the scope of keyword search, but lacks details on pagination, sorting, or error behavior.

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

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

The description is a single, well-structured sentence with semicolons separating key aspects: the resource, search criteria, output fields, and data license. It is efficient and front-loaded, though it packs several clauses together.

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 no output schema and no annotations, the description adequately explains the search scope and return values. However, it does not mention the behavior of the limit parameter (pagination) or possible values for bill_status, making it slightly incomplete for a tool with no 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 coverage is 80% (4/5 parameters documented). The description adds value by explaining the keyword parameter searches full-text across name/reason/proposer/description, and mentions proposer, term, and status as search criteria, reinforcing their purpose beyond the schema.

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

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

The description clearly states the tool searches Legislative Yuan bills (law bills, budget bills, etc.) and specifies the searchable fields: keyword full-text covering bill name/reason/proposer/description, proposer, term, and bill status. It also explicitly lists the return fields, distinguishing it from sibling tools that search laws, regulations, or 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 does not explicitly state when to use this tool compared to alternatives or any exclusions. However, the title and content make it obvious that this is for bills, so usage is implied rather than clearly guided.

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 search scope (including 理由書全文) and the fact that results carry case_id, but it fails to mention that full-text search of 理由書 is only performed when 'deep' is true, which could mislead an agent into thinking all searches cover the full text. It also does not disclose default limits or result ordering.

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, dense sentence that is front-loaded with the key verb and resource, then specifies search scope and the case_id workflow. Every clause adds value, and there is no redundant or filler content.

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

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

Without an output schema, the description should explain return values more thoroughly. It only states that each result includes case_id, leaving out other likely fields (e.g., title, date) and any pagination/ordering behavior. However, given the tool's search nature and the schema's parameter descriptions, it provides the critical link to retrieve full details, which is acceptable but not 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 description coverage is 88%, so the schema already documents most parameters. The description adds the useful linkage that each result has case_id for use with get_taiwan_interpretation, but provides no additional parameter-level semantics beyond what the schema states.

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

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

The description clearly states the tool '列舉或全文搜尋釋字與憲判字' (enumerate or full-text search interpretations and constitutional judgments), specifying the resource and action. It also details searchable fields (標題、爭點/案由與理由書全文) and notes that results include case_id for subsequent retrieval. While it does not explicitly distinguish from sibling tools, the resource type is specific enough to orient an agent.

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 hints at a workflow: search using this tool, then pass the returned case_id to get_taiwan_interpretation. This clearly communicates when to use the tool (finding interpretations by keyword or listing) and how it connects to a sibling tool. However, it does not mention when not to use it or any 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?

With no annotations, the description carries the full burden of behavioral disclosure. It states that judgment content is not saved, results are sorted by court level, each entry contains specific fields, and explains JID deduplication behavior. This is rich contextual detail 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 front-loaded with purpose and every clause contributes value, but it runs as one dense paragraph. It could be more scannable with structured formatting (e.g., bullets), but it is not verbose or redundant.

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?

Despite no output schema, the description specifies result fields, sorting order, and usage patterns for different search modes (case number, main_text, query, semantic merge). It sufficiently covers the complexity of a 9-parameter search tool with 0 required 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 coverage is 78%, but the description adds substantial meaning beyond field descriptions: a concrete example for case_word/case_number/year_from, example mapping of main_text phrases to winners/losers, and the note that main_text can be combined with query. This goes well beyond the 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?

Description clearly states it uses the Judicial Yuan judgment system to search public judgments, with a specific verb and resource. It distinguishes itself from siblings by describing result sorting by court level and the fields included, making it clear this is a search tool rather than a retrieval or interpretation 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?

Provides explicit usage guidance: how to search a specific case number using case_word, case_number, and year_from, and to avoid putting the case number in query. It also explains main_text usage for filtering winners/losers and recommends merging with semantic search tools using JID, explicitly warning that results without JID should not be cited. This qualifies as explicit when/when-not guidance with 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 external data source, return content, and the requirement to include source_url and remind users to verify the latest version. It doesn't state whether it's read-only, authentication needs, or cache behavior (though the fresh parameter is 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?

Four concise sentences, front-loaded with the purpose, then usage constraints. Every sentence adds value with no 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?

Given no output schema and 5 parameters, the description covers the main purpose, return values, and critical usage rules. It omits details like limit behavior or error cases, but is adequate for a search tool with a well-described 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 80%, so baseline is 3. The description mentions '可附修法沿革' which aligns with include_history, but adds no new parameter semantics beyond the schema. The limit parameter lacks description in both the schema and the description.

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

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

Description clearly specifies the verb '查詢' (query), resource '法務部全國法規資料庫' (MOJ national law database), and output ('回傳官方網址與相關條文'). It distinguishes from siblings by emphasizing real-time official data and requiring source_url/dedup rules.

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?

Provides implicit usage context: '與其他法規檢索途徑併用時' indicates this is one of several legal search tools and instructs merging/dedup by pcode. However, it doesn't explicitly name alternative tools or state 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 transparency burden. It discloses that the tool uses an offline data snapshot (implying data may not be real-time) and promises immediate response. It also clearly states it searches names only, not full text. These are useful behavioral traits beyond the basic 'search' verb.

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, front-loaded with the core action and scope. It efficiently packs return fields, data snapshot, and performance characteristics without any fluff. Every clause serves a purpose.

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, the description covers the essential aspects: search scope, return fields, data freshness, and performance. It does not explicitly describe pagination (but the schema does) or differentiate from siblings (covered in purpose/guidelines). Overall, it is sufficiently complete for an agent to understand what the tool does and what it returns.

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 input schema already provides complete descriptions for all three parameters (keyword, offset, exclude_abolished), with 100% schema description coverage. The description adds no extra parameter-level semantics, such as examples or edge cases, 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?

The description clearly states a specific verb ('搜尋' / search) and resource ('法規名稱' / regulation names), with a scope of 11,700+ regulations (laws + commands) and defines the return fields (name, pcode, status). This distinguishes it from sibling search tools such as search_taiwan_laws or search_taiwan_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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or point to any sibling tool for different use cases. The agent must infer usage solely from the tool name and scope, which is not sufficient given the presence of closely related search tools.

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