Taiwan law and court decisions for your AI: statutes, articles and rulings, read-only.
Scored across 9 tools
Descriptions explicitly cross-reference alternatives and state when to use each tool (e.g. get_article_by_number vs get_law_details vs get_law_hierarchy; search_decisions vs search_decisions_exact vs search_grand_chamber_decisions). The search family is cleanly split by matching mode (semantic / literal / curated subset) and the get family by granularity (single article / whole law / outline). No two tools overlap in a way that would cause misselection.
Uniform snake_case verb_noun pattern throughout: get_* for retrieval and search_* for discovery. Qualifiers (search_decisions_exact, search_grand_chamber_decisions, get_article_by_number) extend the same convention predictably rather than breaking it.
Nine tools sit comfortably in the well-scoped 3-15 range. Each tool earns its place by covering a distinct retrieval mode or granularity, and none feels redundant or padded.
The surface covers the full read-only legal-research lifecycle: law-name resolution, article/full-text retrieval, hierarchy browsing, and decision search across relevance, literal, and grand-chamber modes, each with a full-text fetch. Minor gaps remain (e.g. no browsing by court/date, no way to enumerate the law or court corpus), but these are workarounds rather than dead ends.
Fetch the exact text of one Taiwan law article by law name + article number. Use this instead of search_law when you already know which article you want. Returns the current version (and, for a pending amendment, its historical counterpart too).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Optional. "en" returns the official government English translation of the article when one exists (only ~21% of laws have one); omit or "zh-TW" for the Traditional Chinese text. | |
| law_name | Yes | Exact law name in Traditional Chinese, e.g. "民法", "中華民國刑法", "勞動基準法". Use the official short name; search_law_titles can resolve a partial name. | |
| article_number | Yes | Article number as it appears in the law, e.g. "184", "12-1", "1211-1". Do not include the 條 character. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the return semantics: the current version, plus the historical counterpart when an amendment is pending. It doesn't cover rate limits or failure modes on unknown article numbers, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with zero filler: purpose, routing guidance, and return behavior, in that order. Every sentence carries distinct information and the critical routing hint is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description proactively explains what comes back (current version, plus historical counterpart for pending amendments), which is the main unknown for this tool. Nothing essential is missing, though edge behavior for unknown laws or missing articles is 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 law_name, article_number, and lang are fully documented in the schema (including the ~21% English-translation caveat and the 條 exclusion). The description only restates 'law name + article number' without adding 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 ('Fetch the exact text of one Taiwan law article') scoped by law name plus article number, which is a precise retrieval operation. It is clearly distinguishable from search_law and get_law_details by the 'one article' 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?
Explicitly routes the agent: 'Use this instead of search_law when you already know which article you want.' The condition that selects this tool over the sibling is stated outright, and the schema further points to search_law_titles for resolving partial names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full text of one Taiwan court decision by its jid (as shown in the results of search_decisions, search_decisions_exact or search_grand_chamber_decisions). Returns every fragment of that ruling in order -- use it to read a decision in full after a search surfaces it. To find a decision from its citation, search for the citation with search_decisions first. It also reads a Constitutional Court judgment or a 釋字 interpretation directly from its citation, e.g. 111年憲判字第8號 or 釋字第748號.
| Name | Required | Description | Default |
|---|---|---|---|
| jid | Yes | The decision's identifier (jid) exactly as shown in the results of search_decisions, search_decisions_exact or search_grand_chamber_decisions, e.g. "TPSM,110,台上大,3997,20220428,2". | |
| lang | No | Optional: "en" returns the official English text of a 釋字 interpretation where one exists. Ignored for ordinary decisions and judgments. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/no-open-world, so the safety profile is covered structurally. The description adds a return-shape behavior not in any annotation or schema: the full ruling is returned as 'every fragment of that ruling in order', and it notes the citation-based lookup path. Pagination and size limits for very long rulings are not addressed, keeping this just short of 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and resource in the first clause, followed by return behavior, then usage routing. Three sentences, all carrying information, though the Constitutional Court / 釋字 sentence is a slight digression that could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only two parameters, the description is complete enough for an agent to call correctly: it covers the identifier source, the return composition, and the citation-based alternative. It stops short of addressing behavior for very large decisions or partial availability of the optional English text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description still adds meaning: it shows that jid is not only the opaque identifier from search results but can also be a citation form (e.g. 111年憲判字第8號 or 釋字第748號), which the schema does not state, and it reinforces the lang parameter's scope by noting ordinary decisions and judgments ignore it.
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?
Specific verb + resource + scope: 'Fetch the full text of one Taiwan court decision by its jid', with an explicit contrast to the sibling tools that produce the jid (search_decisions, search_decisions_exact, search_grand_chamber_decisions). An agent can distinguish this retrieval-by-id tool from the search tools without inspecting any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('read a decision in full after a search surfaces it') and a named fallback path ('To find a decision from its citation, search for the citation with search_decisions first'), plus an extra entry condition for Constitutional Court judgments and 釋字 interpretations. Alternatives and conditions are spelled out rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full text of an entire Taiwan law (all articles, with chapter/section headings), formatted as Markdown. For a single article prefer get_article_by_number; use this when you need the whole statute. The law counterpart of get_decision_details.
| Name | Required | Description | Default |
|---|---|---|---|
| law_name | Yes | Exact law name in Traditional Chinese, e.g. "公司法". Use search_law_titles first if you only have a partial or informal name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful context the annotations do not: the returned payload is Markdown including chapter/section headings. It does not mention auth or any truncation/size limits for very large statutes, which is the only real gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, no filler: capability and return format first, then the disambiguation rule, then a one-line sibling analogy. Every sentence earns its place and the most important routing info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description supplies the missing return-shape information (full statute as Markdown with headings) and full sibling routing, while annotations carry the safety profile. An agent has everything needed to call it 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% and the single law_name parameter is fully documented in the schema, including the Traditional Chinese requirement and the search_law_titles fallback. The description adds no parameter detail beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and resource (return full text of an entire Taiwan law) plus scope (all articles, chapter/section headings) and output format (Markdown). It differentiates itself from siblings by naming get_article_by_number and get_decision_details.
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?
Explicit routing: 'For a single article prefer get_article_by_number; use this when you need the whole statute.' It names the alternative and the condition that selects it, 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.
Return the chapter/section/article outline of one Taiwan law. Useful for orienting in a large statute before drilling into specific articles with get_article_by_number.
| Name | Required | Description | Default |
|---|---|---|---|
| law_name | Yes | Exact law name in Traditional Chinese, e.g. "公司法". Use search_law_titles first if you only have a partial or informal name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the returned structure (chapter/section/article outline). That is genuinely useful given no output schema exists, though it says nothing about size limits or depth.
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 front-loaded sentences with no filler: the first states the output, the second states the use case and the follow-up tool. Every clause 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 simple single-parameter read tool with full annotation coverage, the description supplies what annotations cannot: the shape of the result. Minor gaps around output size or nesting depth remain, but an agent has enough to call it 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% and the single parameter is fully documented in the schema, including the Traditional Chinese format and the search_law_titles fallback. The description adds nothing beyond the schema here, 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 ('Return the chapter/section/article outline of one Taiwan law'), which is exactly distinguishable from siblings like get_law_details and get_article_by_number. The scope ('one Taiwan law') is explicit.
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 clear usage context ('orienting in a large statute') and names the alternative workflow, get_article_by_number, for drilling down. It lacks an explicit when-not-to-use case, but the routing to a sibling is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Taiwan (ROC) court decisions by legal concept, fact pattern, or keyword, ranked by relevance (hybrid semantic + keyword search, reranked). Covers an apex-tier subset: the Supreme Court, Supreme Administrative Court, Constitutional Court, Disciplinary Court and Intellectual Property and Commercial Court (district and high court decisions are not included). For constitutional questions it also covers the Constitutional Court's judgments (憲判字, from 2022) and the Council of Grand Justices Interpretations (釋字第1-813號), shown as 憲法法庭111年憲判字第N號判決 and 釋字第N號. Use it for questions like "how have courts ruled on X" or "find rulings on this fact pattern"; it returns the most relevant decisions, not every match. Use search_decisions_exact instead when the user needs EVERY decision containing a literal phrase, or an exact count; search_grand_chamber_decisions when the question is which interpretation prevails on a point where panels diverged (大法庭, 統一法律見解); search_law for the text of statutes. A citation such as 最高法院 112年度台上字第1234號 also works as the query: the matching decision ranks first. The same case number can exist in civil and criminal matters (and one case can hold several documents), so check the court and case-type code and the date. Each result shows its jid; read it in full with get_decision_details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default 15) | |
| query | Yes | Search query: a legal concept, fact pattern, or keywords in Traditional Chinese, e.g. "車禍 過失責任" or "勞資 資遣費 認定". | |
| sources | No | Optional: limit which kinds of decisions are searched -- any of "decisions" (court rulings), "judgments" (Constitutional Court judgments, 憲判字), "interpretations" (Council of Grand Justices Interpretations, 釋字) or "constitutional" (both 憲判字 and 釋字). Omit to search everything (the default). Set it only when the user explicitly asks to limit the kind of source -- do NOT infer it from the query. | |
| case_types | No | Optional case-type filter: any of C (憲法), V (民事), M (刑事), A (行政), P (懲戒). Omit for no restriction. Set it only when the user explicitly asks to limit the case type -- do NOT infer it from words in the query: terms like 民事/刑事/行政/懲戒 appear constantly in ordinary topical queries with no filtering intent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description nonetheless adds real behavioral context: hybrid semantic+keyword reranking, 'returns the most relevant decisions, not every match', apex-only coverage, citation queries ranking first, and the caveat that the same case number can exist across civil/criminal matters. It does not mention pagination or result limits beyond the schema default, so it sits just above 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?
Front-loaded with what it is, then coverage, then routing, then caveats — a sensible order with no filler sentences. It is on the long side and the court-list enumeration plus the 憲判字/釋字 naming examples could be tightened, keeping it short of a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description covers scope, ranking semantics, result interpretation (check court and case-type code and date), and the follow-up call (get_decision_details via jid). Nothing an agent needs to call and interpret it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3 and the schema already documents limit, query, sources and case_types. The description adds value beyond it by documenting a non-obvious accepted query form (a citation like 最高法院 112年度台上字第1234號, which ranks first) and by explaining the output handle (jid) used with get_decision_details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (search Taiwan ROC court decisions), the ranking method, and the exact court coverage (Supreme Court, Supreme Administrative Court, Constitutional Court, etc.), plus explicit exclusions (district and high court decisions). An agent can distinguish it from every sibling 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?
Gives concrete question shapes ('how have courts ruled on X', 'find rulings on this fact pattern') and then explicitly routes to three alternatives by condition: search_decisions_exact for exhaustive/literal/count needs, search_grand_chamber_decisions for 大法庭 unified-interpretation questions, search_law for statute text. Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List EVERY Taiwan (ROC) court decision in the apex-tier corpus whose text contains the given literal phrase(s) -- with the exact total count, newest first, paged. Use it when the user wants all decisions (or how many) containing a term (「列出所有…」「有幾筆…」), quotes a phrase to find, or asks whether a term appears at all; optionally narrowed by court, case type and decision-date years, with NOT-phrases. Matching is literal (whitespace ignored), never by meaning: for a legal concept, fact pattern, or anything phrased in your own words, use search_decisions instead, which ranks by relevance. Each row gives the citation, date, 案由, match count, jid, and the first matching passage; use get_decision_details(jid) for full text. The first page already gives the exact total: to answer 'how many', do not page. Request further pages only when the user asks to see more rows. Same corpus as search_decisions (top courts only -- no district or high courts). Constitutional Court judgments (憲判字) and Interpretations (釋字) are included and listed together in one 憲法審查 block with its own exact total.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page number (default 1). Results are newest first. | |
| court | No | Optional court filter, exactly one of: 最高法院, 最高行政法院, 憲法法庭, 懲戒法院, 懲戒法院懲戒法庭, 懲戒法院職務法庭, 智慧財產及商業法院, 大法庭 (Grand Chamber rulings). | |
| terms | Yes | Literal phrases in Traditional Chinese that must ALL appear in a decision's text (AND), e.g. ["契約承擔"] or ["借名登記", "信託"]. Each 2-100 characters; matched exactly as written (whitespace ignored), never by meaning -- a synonym or paraphrase will not match. Do not put the court name here; use `court`. | |
| exclude | No | Optional literal phrases that must NOT appear in the decision, e.g. ["租賃"]. terms + exclude: at most 6 in total. | |
| sources | No | Optional: limit which kinds of decisions are listed -- any of "decisions" (court rulings), "judgments" (Constitutional Court judgments, 憲判字), "interpretations" (Council of Grand Justices Interpretations, 釋字) or "constitutional" (both 憲判字 and 釋字, listed as one 憲法審查 block with its own exact total). Omit to include everything (the default). Set it only when the user explicitly asks to limit the kind of source. | |
| year_to | No | Optional: latest decision-date year, inclusive; same format as year_from. | |
| page_size | No | Decisions per page (default 20, max 50). | |
| year_from | No | Optional: earliest decision-date year, inclusive. ROC (民國) year such as 109, or Gregorian such as 2020 (values up to 200 are read as ROC). Filters on the date the decision was issued (裁判日期), not the year in the case number. | |
| case_types | No | Optional case-type filter: any of C (憲法), V (民事), M (刑事), A (行政), P (懲戒). Omit for no restriction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add behavior it alone can supply: the apex-only corpus limit ('no district or high courts'), the special 憲法審查 block for 憲判字/釋字 with its own exact total, and the fact that page 1 already carries the exact total. That is substantive context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the scope and count guarantee, then routing, then result shape. It is dense and slightly redundant -- literal/non-semantic matching is asserted twice ('never by meaning' and again in the search_decisions contrast) and the constitutional-block detail is appended late -- but for a 9-parameter tool with no output schema the length is largely earned.
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 supplies the return shape (citation, date, 案由, match count, jid, first matching passage) and the escalation path to get_decision_details for full text. Corpus boundaries, count semantics, pagination guidance and the constitutional sub-block are all covered, leaving nothing an agent needs to call it 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 description coverage is 100%, so the schema already documents page, court enum values, terms AND-semantics, exclude NOT-semantics, sources, year_from/to ROC-vs-Gregorian handling, and case_types codes. The description only summarizes this ('narrowed by court, case type and decision-date years, with NOT-phrases') and repeats literal matching, adding little the schema does not already state. Baseline 3 is appropriate.
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 precise verb+resource+scope: 'List EVERY Taiwan (ROC) court decision in the apex-tier corpus whose text contains the given literal phrase(s)'. It explicitly distinguishes itself from the sibling search_decisions (relevance-ranked) and even names the helper get_decision_details(jid), so an agent can route 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?
Gives explicit triggers (「列出所有…」「有幾筆…」, quoted phrases, existence checks) and an explicit exclusion: for a concept, fact pattern, or paraphrase, use search_decisions instead. It also tells the agent not to page just to answer 'how many', which is a concrete usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Taiwan (ROC) Grand Chamber (大法庭) rulings -- the mechanism Taiwan's Supreme Court (最高法院, 民事/刑事) and Supreme Administrative Court (最高行政法院) use to resolve DIVERGENT legal interpretations across panels (統一法律見解／法律見解歧異) and set binding precedent on a pure point of law. Use this instead of search_decisions when the question is specifically about which legal interpretation prevails on a disputed point, not an ordinary fact-pattern search. Covers the full thread for each question -- the referring panel's order, the Grand Chamber's binding answer, and the originating case's final judgment applying it -- across civil, criminal, and administrative matters. Backed by the same Qdrant hybrid search as search_decisions, scoped to this curated subset (~225 decisions) instead of the full apex-tier corpus.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default 15) | |
| query | Yes | Search query: the legal question or point of law in Traditional Chinese, e.g. "未遂犯與既遂犯的區分標準" or "借名登記契約的效力". Use this tool specifically for questions about unifying or resolving DIVERGENT legal interpretations across panels (統一法律見解／法律見解歧異) -- not for an ordinary fact-pattern search, which search_decisions covers over a much larger corpus. | |
| case_types | No | Explicit case-type filter: V (民事), M (刑事), A (行政). Omit for no restriction. Set it only when the user explicitly asks to limit the case type -- do NOT infer it from words like 民事/刑事/行政 in the query. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's job is added context — and it delivers: corpus scope (~225 decisions), backing infrastructure (same Qdrant hybrid search), and the fact that each result spans the full thread (referring order, binding answer, final judgment). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the scope and the routing rule, and each sentence carries information. It is somewhat dense with repeated parentheticals (統一法律見解／法律見解歧異 restated in the schema query field), which costs a point but does not obscure the message.
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 no output schema, the description supplies everything needed to call and interpret it correctly: scope, corpus size, the semantic shape of returned results, and the sibling alternative. Nothing material 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 query, limit, and case_types are already well documented in the schema — including the caveat not to infer case_type from query wording. The description adds no parameter-level syntax or format detail beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (search Grand Chamber rulings) and immediately scopes it to Taiwan's 大法庭 mechanism for resolving divergent interpretations. It names the sibling it is not (search_decisions) and the distinguishing question type, so an agent can route without opening either 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?
Explicitly gives the selection rule: use this instead of search_decisions when the question is about which legal interpretation prevails on a disputed point, not an ordinary fact-pattern search. The when-not condition is stated, not inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Taiwan (ROC) law articles by legal concept, keyword, or a specific article reference. Backed by a Qdrant hybrid (dense + bigram-sparse, RRF-fused) search over a curated set of major Taiwan laws and regulations (laws only, not court decisions). Use it when you don't yet know which article applies. Use get_article_by_number instead when you already know the law and article number, search_law_titles to resolve a law's official name, and search_decisions for court rulings. Returns matching articles with law name, article number, relevance and text; historical versions are marked.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default 5) | |
| query | Yes | Search query: a legal concept or keywords in Traditional Chinese, e.g. "民法 侵權行為" or "勞動基準法 資遣費". A specific article reference like "民法第184條" also works. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe read-only, idempotent profile, and the description goes further: it discloses the retrieval backend (Qdrant dense + bigram-sparse with RRF fusion), the curated corpus limitation, and the return shape including that historical versions are flagged. That is real behavioral context beyond structured fields.
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 tight sentences, front-loaded with purpose and scope before usage routing and return format. Every sentence carries distinct information; no repetition of the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly supplies the return contract (law name, article number, relevance, text, historical marking). Combined with corpus scope and sibling routing, an agent has everything needed to call it 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% and the schema already carries query examples, so the baseline is 3. The description adds a useful conceptual typology of query forms (concept vs. keyword vs. article reference) that helps an agent choose phrasing, but it adds nothing about the limit 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?
States a specific verb (search), resource (Taiwan/ROC law articles), and the query modalities supported (legal concept, keyword, article reference). It explicitly names the corpus boundary (laws only, not court decisions), which separates it from search_decisions.
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 when-to-use condition ('when you don't yet know which article applies') and routes to three named alternatives with their own conditions: get_article_by_number for known citations, search_law_titles for name resolution, search_decisions for rulings. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a full or partial law name to the official law name(s) in the corpus. Call this first when you are unsure of the exact name a law is filed under before using get_article_by_number / get_law_hierarchy / get_law_details. Returns a numbered list: an exact match first, then names starting with the query, then other names containing it; at most 50, with the total when more match. To find articles by topic, use search_law instead.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A full or partial law name in Traditional Chinese, e.g. "個人資料" or "營業秘密". Returns matching official law names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral detail beyond that: the result ordering (exact match, prefix matches, substring matches), the 50-item cap, and the total-match count when truncated. It stops short of stating whether matching is case/whitespace-normalized, but that is minor.
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, each doing distinct work: purpose, sequencing/alternatives, and return-shape contract. Front-loaded with the core action and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description compensates by documenting the return structure, ordering, cap, and truncation signal. Combined with annotations covering safety and a fully documented single parameter, an agent has everything needed to call and interpret this 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% and the single parameter is fully described there (including language and example queries), so the schema carries the load. The description only restates the parameter's role conceptually and adds no format, encoding, or edge-case guidance beyond the schema. Baseline 3 is appropriate.
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 (resolve) and resource (law name → official law names), and names the sibling tools it complements (get_article_by_number, get_law_hierarchy, get_law_details) and the one it contrasts with (search_law). An agent can distinguish it from all siblings purely from this sentence.
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 trigger ("Call this first when you are unsure of the exact name a law is filed under") plus a named alternative with its own condition ("To find articles by topic, use search_law instead"). When-to-use, when-to-use-alternatives, and sequencing are all spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_decision_details1 field changedInput schema / properties / langAdded value: +{
+ "default": null,
+ "description": "Optional: \"en\" returns the official English text of a 釋字 interpretation where one exists. Ignored for ordinary decisions and judgments.",
+ "type": [
+ "string",
+ "null"
+ ]
+}search_decisions1 field changedInput schema / properties / sourcesAdded value: +{
+ "default": null,
+ "description": "Optional: limit which kinds of decisions are searched -- any of \"decisions\" (court rulings), \"judgments\" (Constitutional Court judgments, 憲判字), \"interpretations\" (Council of Grand Justices Interpretations, 釋字) or \"constitutional\" (both 憲判字 and 釋字). Omit to search everything (the default). Set it only when the user explicitly asks to limit the kind of source -- do NOT infer it from the query.",
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+}search_decisions_exact1 field changedInput schema / properties / sourcesAdded value: +{
+ "default": null,
+ "description": "Optional: limit which kinds of decisions are listed -- any of \"decisions\" (court rulings), \"judgments\" (Constitutional Court judgments, 憲判字), \"interpretations\" (Council of Grand Justices Interpretations, 釋字) or \"constitutional\" (both 憲判字 and 釋字, listed as one 憲法審查 block with its own exact total). Omit to include everything (the default). Set it only when the user explicitly asks to limit the kind of source.",
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+}get_decision_details1 field changedInput schema / properties / jid / descriptionPrevious value: -"The decision's identifier (jid) exactly as returned by search_decisions, e.g. \"TPSM,110,台上大,3997,20220428,2\"."New value: +"The decision's identifier (jid) exactly as shown in the results of search_decisions, search_decisions_exact or search_grand_chamber_decisions, e.g. \"TPSM,110,台上大,3997,20220428,2\"."search_decisions1 field changedInput schema / properties / case_types / descriptionPrevious value: -"Explicit case-type filter: any of C (憲法), V (民事), M (刑事), A (行政), P (懲戒). Omit for no restriction -- do NOT infer this from words in the query text (see decisions_qdrant.rs's search_decisions_qdrant module comment for why: case-type words like 民事/刑事/行政/懲戒 show up constantly in ordinary topical queries with no filtering intent)."New value: +"Optional case-type filter: any of C (憲法), V (民事), M (刑事), A (行政), P (懲戒). Omit for no restriction. Set it only when the user explicitly asks to limit the case type -- do NOT infer it from words in the query: terms like 民事/刑事/行政/懲戒 appear constantly in ordinary topical queries with no filtering intent."search_grand_chamber_decisions1 field changedInput schema / properties / case_types / descriptionPrevious value: -"Explicit case-type filter: V (民事), M (刑事), A (行政). Omit for no restriction -- do NOT infer this from words in the query text (same reasoning as search_decisions's case_types param)."New value: +"Explicit case-type filter: V (民事), M (刑事), A (行政). Omit for no restriction. Set it only when the user explicitly asks to limit the case type -- do NOT infer it from words like 民事/刑事/行政 in the query."get_article_by_numberget_decision_detailsget_law_detailsget_law_hierarchysearch_decisionssearch_decisions_exactsearch_grand_chamber_decisionssearch_lawsearch_law_titlesTaiwan legal research: court judgments, statutes, and interpretations. 台灣判決、法條、函釋、釋字搜尋。
Taiwan legal research MCP by Dr.Legal (法律偵探): 22.7M court judgments, current statutes, administrative rulings and Constitutional Court decisions. Retrieval-only, per-item citations, appeal-chain history, bundle-level citation audit. Free, no API key; OAuth 2.0 dynamic registration completes automatically. 台灣法律 MCP：2,272 萬筆裁判書、法規、函釋、憲法法庭裁判，逐筆附出處並提供引用查核。免費、免金鑰。Docs: https://dr-legal.com.tw/mcp
tw-law — Taiwan national statutes and the Constitution, in Chinese plus the Ministry of Justice's…
U.S. law library for AI: court decisions, statutes, court rules and citation checks. Read-only.
Add one secure layer between your agents and this server.