Skip to main content
Glama
lawchat-oss

mcp-taiwan-legal-db

by lawchat-oss

search_agency_interpretations

Search Taiwan government agencies' administrative interpretations, rulings, and review standards by keyword, agency, year, or document number for legal research.

Instructions

搜尋各機關的行政函釋(解釋令、函釋、法規諮詢意見)與審查基準,即時查詢各機關官方系統。 大法官解釋(釋字)與憲判字不在這裡,用 search_interpretations。

來源:法務部(行政函釋、法規諮詢意見)、勞動部(行政函釋、解釋令)、衛生福利部、 財政部(各稅法令彙編、新頒令釋;主管法規系統另含關務署、國有財產署、國庫署的核釋令)、 經濟部(本部解釋令、商業發展署公司法等函釋、智慧財產局著作權函釋與專利商標審查基準、標準檢驗局解釋函令)、 工程會(政府採購法令)、金管會、環境部、交通部、中央銀行、教育部、農業部、文化部、國科會、原民會、海委會、公平會、 陸委會、中選會、行政院人事行政總處(公務員人事法令)、主計總處、行政院消費者保護處(消保法函釋)、 內政部(戶政司、國土管理署、地政司、消防署及部本部)、考試院系統(銓敘部、保訓會、考選部)、 監察院陽光法令主題網(政治獻金法、利益衝突迴避法、財產申報法的主管機關函釋)、 臺北市政府、新北市政府(兩者都另收中央機關函釋)、司法院法學資料檢索系統(跨機關函釋), 以及行政院公報(其他機關依行政程序法第 159 條發布的解釋性規定)。 外交部、退輔會、核安會、國發會的行政規則多為內部作業要點,只在 agency 指名時查。 部分機關(金管會、教育部等)的函釋放在「行政規則」類別,結果會混有一般行政規則。 不指定 agency 時查上述指名才查以外的全部來源;同一件函釋在多個來源出現時只保留一筆。

結果依發文日期新到舊排列,每筆含 id、agency、category、doc_number(發文字號)、date、summary(要旨或主旨)。 要讀全文請把 id 傳給 get_agency_interpretation。categories 列出每個來源/類別的總筆數與是否還有下一頁; 某來源連線失敗時該類別帶 error,其他來源照常回傳。

效力標示(status)是官網對該筆資料的標示,引用前必看:

  • 「停止適用」:官網標示已停止適用或廢止;status_note 附停止日期、依據的函或原標示

  • 「部分停止適用」:交通部的標示

  • 「適用中」:只在官網有「現行/停止適用」兩態欄位的來源出現(勞動部、衛福部、考試院系統、環境部、地政司、 各部會主管法規共用系統的行政規則),表示官網標為現行;財政部法令彙編的函釋也標「適用中」(經重新研審保留適用, 彙編後才廢止的不另標示)

  • 沒有 status:官網沒有標示或沒標示,不代表仍然有效(戶政司、消防署、智慧局、行政院公報等官網完全沒有效力欄位)。 官網偶有漏標,引用前請讀全文、留意 notes(編註)與後續函釋

Args: keyword: 關鍵字(全文檢索;多個詞以空白分隔)。查特定法條時可用「勞動基準法第24條」這類寫法。 智慧局審查基準只比對章名(如「專利要件」「混淆誤認」) agency: 機關名稱,可用逗號分隔多個,例如「勞動部」「財政部,經濟部」「銓敘部」「地政司」「臺北市」「智慧局」。 NCC、客委會、僑委會、運動部、關務署新頒釋函與陸委會主站廣告函釋須指名才查。 NCC 可查個別函復;陸委會主站限廣告規範。數位發展部只收行政院公報中依法公告的解釋性規定 year_from: 起始年度(民國年,如 110) year_to: 截止年度(民國年,如 114) doc_number: 發文字號或其號碼(如「法律字第11403512580號」或「11403512580」) page: 頁數(每個來源各自分頁:多數每頁 20 筆;衛福部、各部會主管法規共用系統、考試院系統、中央銀行、環境部、 行政院公報每頁 10 筆;交通部每頁 25 筆)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo
agencyNo
keywordNo
year_toNo
year_fromNo
doc_numberNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: result ordering (newest first), returned fields (id, agency, category, doc_number, date, summary), per-source pagination with differing page sizes, per-category error handling on source failure, and a detailed explanation of the status field semantics including the crucial warning that missing status does not mean still-valid.

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?

Front-loaded with purpose and the sibling alternative, and each section (sources, return format, status semantics, args) earns its place for a tool spanning dozens of sources. The exhaustive agency/source enumeration is heavy, but it is functionally load-bearing because agency behavior depends on it, so the length is defensible rather than padded.

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?

For a highly complex tool with no annotations, no output schema, and 0% schema coverage, the description covers everything an agent needs: source list, default vs named-agency behavior, return shape, pagination quirks, error handling, and status interpretation caveats.

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?

Schema coverage is 0% for all 6 parameters, so the description must compensate and does: keyword (full-text, space-separated, article syntax, IP-office chapter-name limitation), agency (comma-separated with examples and named-only agencies), year_from/year_to (民國年), doc_number (two accepted formats), and page (per-source page sizes). Every parameter is documented with format and behavior.

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?

States a specific verb and resource (searching 各機關的行政函釋、解釋令、法規諮詢意見、審查基準) and immediately contrasts itself with the sibling search_interpretations, which covers 大法官解釋/憲判字. An agent can distinguish this from search_interpretations 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.

Usage Guidelines5/5

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

Explicitly names the alternative (search_interpretations) and the condition that selects it, plus states that certain agencies (外交部、退輔會、核安會、國發會) are only queried when named, and what happens when agency is omitted. Deduplication behavior across sources is also stated.

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