mcp-taiwan-legal-db

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool serves a distinct purpose: citations, interpretations, judgments, regulations, and searches for each. No overlapping functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., get_interpretation, search_judgments).
Tool Count5/5
8 tools cover the main legal document types and operations without being excessive or insufficient.
Completeness5/5
The tool set covers retrieval of interpretations, judgments, and regulations with both search and full-text access, including citation analysis and law code conversion.
Average 4.2/5 across 8 of 8 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It describes the action (extract citations) and optional context, but it does not mention whether it is read-only, what happens on missing case_id, rate limits, or any side effects. Significant gaps remain.
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 relatively concise, with a clear structured args section. It front-loads the main purpose and then details parameters. However, it could be slightly shorter without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain the return format. It only states that citations are extracted and optionally with context, but does not describe whether it returns a list, the structure of each citation, or any other details. This is inadequate for an agent to fully understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains case_id format (same as get_interpretation) and include_context function (attaches 80-character context snippets). This adds value beyond the schema, which only provides names and types. The coverage is good for both parameters.
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 clearly states the tool extracts all cited interpretation/judgment numbers from the reasoning of constitutional interpretations. It specifies the direction (backward tracing) and distinguishes itself from siblings like get_interpretation which returns full text.
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?
The description implicitly indicates when to use (to get citations from a given case), but it does not explicitly state when not to use or mention alternatives. No comparison with siblings is provided, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that law_name is auto-converted to pcode and include_history condition, but given no annotations, lacks disclosure on read-only nature, authentication, or side effects. Adequate but not comprehensive.
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?
Well-structured with Args section and front-loaded purpose. About 150 words, efficient but could be slightly more concise. No wasted sentences.
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?
Covers all parameters, usage modes, and return structure. Lacks error handling or examples, but for a tool with zero annotations and no output schema, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains each parameter's role, dependencies (pcode can be omitted if law_name provided), and usage, adding substantial value beyond the schema.
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 clearly states it queries regulation articles from a national database, with specific options for single article, range, or full text. This distinguishes it from siblings like get_judgment or search_regulations.
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?
Provides clear context for use (querying regulation articles) and details usage modes (single, range, full text), but does not explicitly exclude alternative siblings or mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers behavioral traits: it performs full-text search across topic and reasoning documents, supports multiple filters (year, number range, old/new systems), and returns case IDs. It does not mention pagination or rate limits but is adequate for a read-oriented search tool.
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 well-structured with a concise opening sentence followed by a bulleted parameter list. It is not overly verbose, but the parameter documentation could be slightly more compact. Overall, it efficiently communicates the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the parameters thoroughly but lacks details about the return format beyond 'each result includes case_id'. It does not describe pagination, error handling, or behavior if no results are found. Given no output schema, this is a moderate gap.
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?
Despite 0% schema description coverage, the description provides detailed explanations for all 7 parameters in Chinese, including default values and effects (e.g., 'year=0 means no filter', 'include_old only works when year=0'). This adds significant semantic value beyond the input schema.
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 clearly states the tool lists grand justice interpretations or constitutional court rulings with full-text search capabilities. It distinguishes itself from sibling tools like get_interpretation by specifying that results carry case_id for direct retrieval.
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?
The description implies usage when searching for interpretations, mentioning it supports keyword and year filters, and note that results can be used with get_interpretation. However, it does not explicitly state when to use this tool over other search tools like search_judgments or search_regulations, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes behavior beyond name: returns name and pcode, sorted by active first, paginated 50 per page. Also explains the exclude_abolished parameter effect. No annotations are provided, so the description carries the full burden and does so adequately.
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?
Description is front-loaded with purpose and structured with an Args section. It is clear but slightly redundant (Args section repeats info from prose). No waste, but could be more integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 mentions 'list of regulations' but lacks details on return fields beyond name and pcode. Status is mentioned only for abolished cases. Could be more complete about the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds meaning: explains keyword with examples, offset default 0, exclude_abolished default false and its effect. This compensates for the lack of 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?
Description clearly states 'search regulation names by keyword' and specifies it searches a complete list of 11,700+ regulations. It distinguishes from siblings like search_interpretations and search_judgments, which are for different legal resources.
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?
Provides context for when to use (keyword search for regulations), mentions ordering by active regulations first, and lists default pagination. Does not explicitly exclude use cases or mention alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions data sources (Open Data API vs direct page load) but does not disclose behavioral traits like idempotency, authentication needs, or rate limits. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections for Args and Returns. Every sentence adds value, and the overall length is appropriate.
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 no output schema, the description adequately lists return fields. The tool's complexity is moderate, and the description covers input methods, return structure, and source. It is complete for the intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaningful semantics: explains the format of jid (e.g., 'TPSV,104,台上,472,20150326,1') and url (e.g., printData.aspx), filling the gap left by the schema.
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 clearly states the tool retrieves the full text of a single judgment, with specific verbs and resources. It distinguishes from sibling tools like search_judgments (which returns multiple results) by stating '單一裁判書全文'.
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?
The description provides guidance on two query methods (JID vs URL) and when to prefer each. However, it does not explicitly state when not to use the tool or mention alternatives beyond the sibling tools list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: default layer is from local cache (no network), reasoning text limited to 15000 characters, keyword parameters override include parameters. It also explains case_id format acceptance. No contradictions found.
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 well-structured with a clear header, operational details, and an Args list. It is slightly verbose with inline examples, but each sentence adds value. Front-loaded with purpose and cached behavior.
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?
Covers main functionality: different query modes, parameter interactions, and caching. However, it omits output format details and error handling. Given the tool complexity (5 params, no output schema), it is largely complete but could improve with return value description.
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%, but the description provides semantic meaning for all parameters: explains case_id format with examples, notes that reasoning_keyword overrides include_reasoning, and describes opinions_keyword similarly. This fully compensates for the lack of 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?
The description clearly states the tool retrieves full text of Constitutional Court interpretations (釋字第 1-813 號) and court rulings (憲判字). It distinguishes from sibling tools like get_judgment and search_interpretations by specifying the exact document types and providing case_id format examples.
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?
It explains default cached instant response and describes two modes for reasoning/opinions (full text vs keyword snippet). While it implies usage for retrieving specific interpretations, it does not explicitly contrast with search_interpretations or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses the tool's behavior: it performs a lookup with fuzzy matching, returns a dictionary with pcode or suggestions. It does not mention rate limits or auth, but for a read-only lookup this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct with no wasted words. It front-loads the purpose, then provides coverage, parameter details, and return format in a clear, structured way.
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?
Given the tool's simplicity (1 parameter, no output schema), the description covers the essential: purpose, coverage, fuzzy matching, and return type. It could mention error cases or multiple matches, but overall it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining the 'law_name' parameter with examples like '民法' and '勞基法'. It clarifies that the input is a law name and implies that fuzzy matching is supported, adding value beyond the schema's bare 'Law Name' title.
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 uses a specific verb '轉換' (convert) and clearly states the resource: law names to pcode. It covers 11,700+ regulations, supports fuzzy matching, and is distinct from siblings like get_citations or get_judgment which serve different purposes.
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?
The description implies usage: when you have a law name and need its pcode. It provides context (coverage, fuzzy matching) but lacks explicit when-not-to-use or alternative tool comparisons. The sibling list provides indirect guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description bears full burden. Discloses sorting by court hierarchy, returned fields (court, case_type, court_level), and that main_text is semi-structured. Does not cover auth needs or rate limits.
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?
Well-structured with sections and examples. Somewhat lengthy due to detailed main_text variants, but all information is relevant and adds value. Front-loaded with purpose and key usage.
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?
Comprehensive for a complex tool with 9 parameters. Covers sorting, caching, return format, parameter interactions, and advanced filtering. No output schema, but description details the return structure.
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 has no parameter descriptions (0% coverage). Description adds full semantics: keyword for full-text, court name, case_type domain, ROC year format, case_word/number for exact lookup, main_text for win/loss, max_results default and limit.
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?
Description starts with '搜尋司法院裁判書系統' (Search the Judicial Yuan judgment system), clearly stating the verb and resource. It is distinct from sibling tools like get_judgment (single judgment fetch) and search_interpretations.
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?
Provides explicit guidance on when to use keyword vs case_word/case_number, with a concrete example. Describes advanced main_text usage for win/loss filtering. Does not explicitly mention when not to use or compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-taiwan-legal-db MCP server](https://glama.ai/mcp/servers/lawchat-oss/mcp-taiwan-legal-db/badges/card.svg)](https://glama.ai/mcp/servers/lawchat-oss/mcp-taiwan-legal-db)

Score Badge

Copy to your README.md:

[![mcp-taiwan-legal-db MCP server](https://glama.ai/mcp/servers/lawchat-oss/mcp-taiwan-legal-db/badges/score.svg)](https://glama.ai/mcp/servers/lawchat-oss/mcp-taiwan-legal-db)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/lawchat-oss/mcp-taiwan-legal-db'

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