Skip to main content
Glama
lawchat-oss

mcp-taiwan-legal-db

by lawchat-oss
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

search_regulations

Search Taiwan's regulations by name keyword or find laws amended since a specific date to track compliance changes. Filter by category or exclude abolished laws.

Instructions

以關鍵字搜尋法規名稱，或列出某日之後新制定／修正公布的法規（法遵追蹤）。

在完整法規清單（11,700+ 部法律與命令）中搜尋，每頁 50 筆。每筆含 law_name、pcode、status、 last_amended（最新公布日）、category（主管機關分類，如「行政＞勞動部＞勞動條件及就業平等目」）。 有 amended_since 時依公布日新到舊排列，否則現行法規優先、依名稱排列。

Args: keyword: 法規名稱關鍵字（如「勞動」「消費」「智慧財產」）；有 amended_since 或 category 時可省略 offset: 分頁偏移（從第幾筆開始，預設 0） exclude_abolished: 排除已廢止法規（預設 False，已廢止法規仍可搜尋但標記狀態） amended_since: 只列這天以後（含）公布的法規，如「2026-09-01」「115-09-01」 category: 主管機關或分類關鍵字（如「金融監督管理委員會」「勞動部」「稅務」），比對 category 欄

Returns: 符合條件的法規列表

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offsetNo
keywordNo
categoryNo
amended_sinceNo
exclude_abolishedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.7.0
    • addedInput schema / properties / amended_since
      Added value: +{
+  "default": "",
+  "title": "Amended Since",
+  "type": "string"
+}
    • addedInput schema / properties / category
      Added value: +{
+  "default": "",
+  "title": "Category",
+  "type": "string"
+}
    • addedInput schema / properties / keyword / default
      Added value: +""
    • removedInput schema / required
      Removed value: -[
-  "keyword"
-]
  2. First observedv1.0.0

TDQS

A4.1/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 the corpus size (11,700+ 部), page size (50 per page), the exact return fields, and the ordering rule that switches based on amended_since. It stops short of stating read-only nature, rate limits, or permission needs, but the behavioral profile is otherwise strong.

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 purpose sentence followed by clearly labeled Args and Returns blocks; each parameter line earns its place with a concrete example. Slightly dense with parenthetical examples, but nothing is redundant filler.

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 five-parameter search tool with no output schema and no annotations, the description supplies everything needed: scope, page size, ordering semantics, per-parameter meaning, and the return fields. Nothing an agent needs to invoke it correctly is missing.

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%, so the description must compensate, and it does for all five parameters: keyword with omission rule and examples, offset as pagination start, exclude_abolished with its default and the caveat that abolished laws remain searchable but flagged, amended_since with dual date-format examples (2026-09-01 / 115-09-01), and category with the matching column and examples.

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

Purpose4/5

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

States a specific verb and resource (搜尋法規名稱 / 列出某日之後新制定或修正的法規) and clearly frames two operating modes including compliance tracking. It does not distinguish itself from close siblings like query_regulation, search_other_regulations, or get_other_regulation, so an agent cannot route between them from this text alone.

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

Usage Guidelines3/5

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

Gives concrete in-tool conditions (keyword may be omitted when amended_since or category is supplied; amended_since triggers newest-first ordering) and names the compliance-tracking use case. However it never says when NOT to use it or which sibling to prefer for adjacent needs, so alternatives remain inferred.

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

Deploy Server

Other Tools