Skip to main content
Glama
lawchat-oss

mcp-taiwan-legal-db

by lawchat-oss

search_legislative_records

Search Taiwan's legislative records to retrieve bills, gazettes, drafts, and JOIN platform announcements. Filter by keyword, status, and term to track legislative progress.

Instructions

搜尋立法動態與立法紀錄。

kind:

  • bills:立法院議案(法律案草案、修正草案)。status=pending 審查中(預設只看本屆,屆期不連續)、 all 全部、passed 已三讀。每筆含提案人、提案日期、會期、進度與關係文書 PDF(含條文對照表)

  • gazette:立法院公報(院會、委員會、公聽會紀錄,含委員與官員發言);全文檢索,matches 是命中片段。 查立法者原意時可用「法律名稱+條次」,例如「勞動基準法第五十五條」

  • drafts:行政院公報刊登的法規命令訂定、修正草案預告(各部會的辦法、細則草案,含陳述意見截止日期)

  • join:JOIN 平臺的法律草案預告,補足行政院公報法規命令以外的法律草案。

結果的 id 傳給 get_legislative_record 取得全文。每頁 20 筆(drafts 10 筆)。

Args: keyword: 關鍵字(法律名稱、條次、議題) kind: bills、gazette、drafts 或 join status: bills 使用 pending、all 或 passed;join 使用 pending(進行中)或 closed(已結束) term: 立法院屆別(如 11);0 = bills 審查中只看本屆、其他不限 page: 頁數

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNobills
pageNo
termNo
statusNopending
keywordYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.7.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses pagination (20 per page, 10 for drafts), the default term scoping rule ('屆期不連續', term=0 semantics), that gazette is full-text with hit snippets in 'matches', and that each bill carries proposer, date, session, progress and a comparison-table PDF. It does not discuss result ordering, totals, or failure modes.

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 the purpose sentence, then a well-organized bulleted breakdown by kind that lets an agent scan to the relevant branch. Slightly long and repeats the kind names in both the list and the Args block, but every section carries information.

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

Completeness4/5

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

With no output schema and no annotations, the description fills the gap by explaining what each result set contains, how pagination works, and how to chain the returned id into get_legislative_record. Minor omissions remain (ordering, total counts, empty-result behavior) but nothing blocking correct invocation.

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 description coverage is 0%, yet the description documents every one of the 5 parameters with value semantics: keyword types, the four kind values, status values split per kind (pending/all/passed vs pending/closed), term meaning including the special 0 behavior, and page. This fully compensates for the empty schema descriptions.

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+resource ('搜尋立法動態與立法紀錄') and then enumerates the four distinct record families (bills, gazette, drafts, join) with their content, which makes the tool's scope unambiguous and clearly distinct from siblings like search_regulations and get_legislative_history.

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

Usage Guidelines4/5

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

Gives concrete selection guidance: which kind to pick for which need, a specific retrieval recipe for gazette ('查立法者原意時可用「法律名稱+條次」'), and routes to get_legislative_record for full text via the returned id. It lacks explicit 'do not use this for X' exclusions against the many sibling search tools, so not a full 5.

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