Skip to main content
Glama
oldbear-meme

mcp-taiwan-legal-db-integrated

by oldbear-meme

search_judgments

Search Taiwan court judgments by keyword, case type, court, case number, or year. Results sorted by court hierarchy. Supports boolean operators and main text search for outcome filtering.

Instructions

搜尋司法院裁判書系統。

結果自動按法院權威性排序(最高法院→高等法院→地方法院),同層級按原始排序。 每筆結果含 court(法院名稱)、case_type(民事/刑事/行政)、court_level(1=最高/2=高等/3=地方)。

【重要】查特定案號時,必須用 case_word + case_number(精確查詢),不要把案號放在 keyword。 所有案件類型(包含一般案件、簡易案件、小額案件)都使用相同方式查詢,系統會自動同時查詢裁判書系統與簡易案件系統。 例如查「114年度上易字第503號」→ case_word="上易", case_number="503"(不傳year_from/year_to)。 例如查「114年度羅小字第412號」→ case_word="羅小", case_number="412"(不傳year_from/year_to)。 例如查「114年度北簡字第100號」→ case_word="北簡", case_number="100"(不傳year_from/year_to)。 注意:案號年度與裁判日期年度可能不同,查精確案號時不傳年度可避免遺漏。 keyword 僅用於主題式全文檢索(如「預售屋 遲延交屋」),不可用於查詢特定案號。

【裁判書系統 vs 簡易案件系統】: 本工具可查詢兩個系統:

  1. 裁判書系統(通常系統)- 完整判決,支援所有參數過濾

  2. 簡易案件系統 - 地方法院簡易/小額案件,但有以下限制: ❌ 不支援 court 參數過濾(無法指定特定地方法院) ❌ 不支援 case_type 參數過濾(無法指定民事/刑事) ✅ 支援 keyword、main_text、case_word、case_number、year 等參數

【search_system 參數說明】:

  • "auto"(預設)- 智能判斷:

    • 指定非地方法院(高等/最高/智財/懲戒) → 只查裁判書系統

    • 指定地方法院 → 查詢兩個系統(⚠️ 簡易系統會混入其他地院案件)

    • 未指定法院 → 查詢兩個系統

  • "both" - 強制查詢兩個系統(即使指定了 court/case_type)

  • "regular" - 只查裁判書系統(不含簡易案件)

  • "easy" - 只查簡易系統(僅地方法院簡易/小額案件)

【指定地方法院時的注意事項】⚠️: 當指定地方法院(如「臺灣臺東地方法院」)且 search_system="auto" 或 "both" 時:

  • 裁判書系統:正確過濾,只回傳該地院判決 ✅

  • 簡易系統:無法過濾,會混入全國所有地院的簡易案件 ❌

解決方法:在 keyword 中加入法院名稱進行二次過濾 範例:查臺東地院的侵權行為案件 → keyword="侵權行為 臺灣臺東地方法院", court="臺灣臺東地方法院" → 簡易系統雖會查到其他地院,但因缺少「臺灣臺東地方法院」關鍵字而被排除

或者使用 search_system="regular" 只查裁判書系統(不含簡易案件)

【進階實務研究欄位】:

  • main_text: 裁判主文關鍵字 — 最有效的輸贏方篩選方式。 主文措辭高度制度化(依民刑訴訟法條生成),substring match 接近 解析半結構化欄位,精度高:

    • 「被告應將 移轉」→ 被告敗訴(物權移轉類)

    • 「被告應給付」→ 被告敗訴(金錢給付類)

    • 「原告之訴駁回」→ 原告敗訴

    • 「上訴駁回」→ 維持原審 支援布林運算:+(或)、-(不含)、&(且)、()(組合)

    • 「被告應給付&損害賠償」→ 主文同時包含兩者

    • 「原告之訴駁回+上訴駁回」→ 主文包含任一種 可與 keyword 併用,例: 找「借名登記成立、被告敗訴」→ main_text="被告應將 移轉", keyword="借名登記", case_type="民事"

【分頁機制】: 本工具每次最多回傳 max_results 筆(上限 200),但實際總筆數可能遠超過 200 筆。 回傳結果中的 total_count 欄位顯示真實總筆數(從司法院網頁解析)。

當 total_count > 回傳筆數時,表示還有更多結果: 使用 offset 參數可取得後續結果,例如:

  • 第 1-200 筆:max_results=200, offset=0

  • 第 201-400 筆:max_results=200, offset=200

  • 第 401-600 筆:max_results=200, offset=400

建議:先用小 max_results 測試,確認 total_count 後再用多次呼叫取得完整結果。

【系統別件數資訊】: 查詢結果中會包含 regular_count(裁判書系統件數)和 easy_count(簡易系統件數)。

當件數很多時,建議分系統查詢:

  • 使用 search_system="regular" 查詢裁判書系統

  • 使用 search_system="easy" 查詢簡易系統

  • 可以更精確控制分頁,避免重複抓取資料

司法院 500 筆限制: 每個系統各有 500 筆上限,如某系統超過 500 筆,第 501 筆之後無法取得。 解決方案:(1) 按時間拆分(年度、月份、日期)(2) 按法院拆分

Args: keyword: 全文檢索關鍵字(對應 jud_kw)。支援布林運算:+(或)、-(不含)、&(且)、()(組合),例如「不完全給付&瑕疵擔保」、「民法-刑法」 court: 法院名稱(如「最高法院」「臺灣高等法院」「臺灣臺北地方法院」) case_type: 案件類型(民事/刑事/行政/懲戒) year_from: 起始年度(民國年,如 110),關鍵字搜尋時使用,查精確案號時不填 year_to: 截止年度(民國年,如 113),關鍵字搜尋時使用,查精確案號時不填 case_word: 字別(如「台上」「上易」「重訴」「羅小」「北簡」),查特定案號時必填 case_number: 案號(數字),查特定案號時必填 main_text: 裁判主文關鍵字(對應 jud_jmain)— 結構化篩選輸贏方。支援布林運算:+(或)、-(不含)、&(且)、()(組合) max_results: 回傳筆數上限(預設 10,上限 200) offset: 跳過前幾筆(分頁用,預設 0) search_system: 查詢系統選擇("auto"=智能判斷, "both"=兩者, "regular"=僅裁判書, "easy"=僅簡易),預設 "auto"

Returns: 包含搜尋結果的字典:success, query, total_count, results, cached, timestamp

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keywordNo
courtNo
case_typeNo
year_fromNo
year_toNo
case_wordNo
case_numberNo
main_textNo
max_resultsNo
offsetNo
search_systemNoauto
Behavior5/5

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 thoroughly discloses behavior: result sorting by court authority, fields returned (court, case_type, court_level), the dual-system behavior with limitations, pagination mechanics, the 500-record limit per system, and the meaning of total_count. No contradictions.

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

Conciseness4/5

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

The description is long but well-structured with headings and sections (【重要】, 【裁判書系統 vs 簡易案件系統】, Args, Returns). Some repetition (e.g., pagination explained twice) could be trimmed, but overall it is logically organized and front-loaded with key warnings.

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

Completeness5/5

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

Given the complexity (11 parameters, no schema descriptions, no output schema, no annotations), the description is remarkably complete. It covers dual systems with cross-system interactions, pagination, the 500-record limit, total_count, result fields, and examples. It even explains the rationales (e.g., why not to pass year parameters for specific case numbers). No gaps remain.

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

Parameters5/5

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

With 0% schema description coverage, the description must explain all parameters exhaustively. It does: keyword supports Boolean operators, court is a free-text court name, case_type has allowed values, year_from/to are Republican years, case_word/case_number for exact case search, main_text with examples and Boolean logic, max_results/offset for pagination, and search_system with four modes explained. Every parameter is covered.

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

Purpose5/5

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

The description explicitly states '搜尋司法院裁判書系統' (search the Judicial Yuan judgment system), clearly indicating the verb (search) and resource (court judgments). It distinguishes from sibling tools like get_judgment (single retrieval) and other search tools by its focus on multi-result judgment search.

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

Usage Guidelines5/5

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

The description provides extensive usage guidance: when to use keyword vs case_word+case_number, how to handle specific case numbers, the limitations of the easy system, and explicit examples. It also advises on pagination and splitting queries across systems, making it clear when to use alternative approaches.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/oldbear-meme/mcp-taiwan-legal-db-integrated'

If you have feedback or need assistance with the MCP directory API, please join our Discord server