mcp-taiwan-legal-db-integrated

by oldbear-meme

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation4/5
Most tools have distinct purposes: get_interpretation vs get_legal_interpretation differentiate between local cache and online system; search_interpretations vs search_legal_interpretations target different scopes. However, some pairs (e.g., get_citations vs get_judgment's cited_cases field) could cause minor confusion.
Naming Consistency4/5
Tools consistently use verb_noun pattern with underscores: get_* (7 tools) and search_* (5 tools). The single exception is query_regulation instead of search_regulation, breaking the pattern slightly.
Tool Count4/5
13 tools cover a broad legal research domain (interpretations, judgments, regulations, PCC letters). The count is reasonable, though some tools like get_citations could potentially be merged into get_judgment.
Completeness4/5
The tool surface covers key workflows: searching and retrieving interpretations, judgments, regulations, and PCC letters. Missing are perhaps cross-referencing tools or trend analysis, but core legal research needs are met.
Average 4.5/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it extracts citations and optionally attaches context snippets. However, it does not mention any behavioral traits like whether it requires authentication, rate limits, or performance characteristics. Basic transparency is present but not rich.
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, using a single paragraph with clear bullet points for arguments. It could be slightly more structured, but every sentence adds information. No wasted words.
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 no output schema and no annotations, the description adequately explains input and what is returned (citations with optional context). It lacks mention of return format or pagination, but for a simple extraction tool, 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?
Schema coverage is 0%, so the description must add meaning. It does: it explains that case_id should follow the same format as get_interpretation, and includes that include_context controls whether a snippet of 80 characters is attached. This adds value beyond the bare schema types.
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 that the tool extracts all cited interpretation/case numbers from reasoning documents of Grand Justice interpretations. It specifies the trace direction as backward tracing (which prior judgments a given judgment cites), which distinguishes it from sibling tools like get_interpretation that retrieve a single interpretation.
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 need to know which previous interpretations a specific case cites. It does not explicitly mention when not to use or name alternatives, but the context of sibling tools makes the use case clear. Slight lack of explicit guidance on exclusions.
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 exist, so the description carries full burden. It discloses that keyword search covers '爭點 + 理由書', and explains parameter behaviors (e.g., year=0 applies to old system). However, it does not mention side effects, authentication, rate limits, or explicitly state read-only nature, which is acceptable for a search tool but leaves some ambiguity.
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 short introductory sentence followed by a parameter list. It is slightly verbose due to parameter explanations, but every sentence adds value. Could be more concise by integrating parameter notes into a single paragraph.
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 tool has 7 parameters and no output schema. The description explains parameters well but lacks details on return format (e.g., fields beyond case_id, pagination, sorting). It assumes output structure without specifying, leaving some gaps for an agent to infer.
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 0% parameter description coverage, so the description fully compensates by explaining each of the 7 parameters with conditions (e.g., 'include_old only effective when year=0'). This adds essential meaning beyond the schema's default values and titles.
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 enumerates (列舉) interpretations/constitutional court decisions and supports full-text keyword search across issues and reasoning. It specifies the resource (大法官解釋/憲法法庭裁判) and action (搜尋), distinguishing it from sibling 'get' tools like get_interpretation.
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 explains that results include 'case_id' for direct use with get_interpretation(), and details each parameter's effect (e.g., year filtering, max_results). It does not explicitly state when not to use or alternative tools, but the context of siblings implies appropriate usage.
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, so the description fully addresses behavioral aspects. It discloses automatic law_name-to-pcode conversion, the return structure (law, articles, source_url, optional history), and the functional scope. No destructive behavior is expected, and the transparency is sufficient.
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 purpose statement and bullet-style parameter explanations. It is slightly verbose but every part contributes to understanding. Concise enough for an AI agent to parse efficiently.
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 6 parameters, 0% schema coverage, and no output schema, the description covers all parameters and return structure. It could mention error handling or prerequisites (e.g., either law_name or pcode required), but it is largely complete for the tool's complexity.
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 compensates fully. It explains each parameter's purpose (e.g., law_name vs pcode, article_no for single article, from_no/to_no for range, include_history for history) with examples like '民法' and '247-1'. This adds significant meaning beyond the raw 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 the national regulations database, specifying the types of queries (single article, range, full text). This distinguishes it from siblings like search_regulations, which likely searches across regulations rather than retrieving specific articles.
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 explains parameter usage (e.g., include_history for history queries) but does not explicitly guide when to use this tool versus alternatives like search_regulations or get_citations. Usage context is implied but lacks exclusions or alternative recommendations.
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 fields from local cache (fast), reasoning/opinions have full-text and keyword modes, and reasoning_keyword overrides include_reasoning. It also mentions a 15000-character limit. However, it does not explicitly state whether reasoning/opinions require network access.
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 sections for default mode, reasoning/opinions, case_id format, and parameter details. While somewhat verbose, every sentence adds value. Minor redundancy could be trimmed, but overall efficient.
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 complexity (5 parameters, no output schema), the description covers essential aspects: parameter behavior, caching, and case_id format. It lacks explicit output format details, but the tool's purpose implies returning the interpretation text. Generally sufficient.
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?
The description adds significant meaning beyond the input schema: it explains case_id formats (multiple accepted variants), the override behavior of reasoning_keyword and opinions_keyword, and the character limit for include_reasoning. With 0% schema coverage, this is essential and well-done.
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 judicial interpretations or constitutional court decisions, specifying the range (釋字第1-813號 or 憲法法庭裁判) and caching behavior. It distinguishes from sibling tools like search_interpretations, which imply search functionality.
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 explains when to use the tool (retrieve specific known decisions) and provides formatting examples for case_id. However, it does not explicitly contrast with sibling tools like search_interpretations for when a search would be more appropriate, leaving some ambiguity.
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 carries full burden. It discloses the two query methods, preference for Open Data API with JID, and return structure. Lacks error handling or potential issues, but sufficient for a read-only fetch.
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 structured with Args and Returns, but the return list is somewhat verbose. It is front-loaded with the main purpose, and each part is useful.
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 provides the full return structure. It covers both query methods adequately for a single document fetch tool. No missing critical info.
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%, but the description provides detailed parameter descriptions with examples (jid format, url example), adding significant meaning beyond the schema defaults.
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 gets the full text of a single judgment (specific verb+resource). It distinguishes from siblings like search_judgments (searching) and get_citations (related items).
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 explains when to use the tool (to get a single judgment by JID or URL). It does not explicitly state when not to use it 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behaviors: covering 11,700+ regulations, supporting fuzzy matching, and returning a dictionary with pcode or suggestions. It lacks details on error handling or rate limits but is adequate for a simple lookup tool.
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 with two clear paragraphs, front-loading the purpose and providing Args/Returns sections. No wasted words.
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 simple one-parameter tool with no output schema, the description covers purpose, input, output format, and key behaviors like fuzzy matching and coverage, making it fully self-contained.
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 schema only provides the parameter name and type with 0% coverage. The description adds meaning by explaining law_name as a Chinese regulation name with examples (e.g., 民法, 勞基法), which goes 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 the tool's purpose: converting law names to pcode codes for the national law database. It is distinct from sibling tools like get_citations or get_interpretation, which serve different retrieval functions.
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 for converting law names to pcode, providing context of coverage and fuzzy matching. However, it does not explicitly state when to use this tool versus alternatives or when not to use it.
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 fully explains the two-phase query design, categories mechanism, return values including cached status, and doc_types behavior. It lacks mention of rate limits or authentication but otherwise is transparent about tool behavior.
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 sections, bullet points, code examples, and parameter breakdown. It is front-loaded with core mechanism and workflow. Some repetition could be trimmed, but overall it is efficient for the complexity.
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?
The description covers all necessary aspects: purpose, detailed workflow, parameter explanations, return value structure, error handling, and examples. Given the tool's complexity and no output schema, it is complete and leaves no major gaps.
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 the input schema having 0% description coverage, the description includes a detailed 'Args' section explaining each parameter's format, defaults, and usage, especially doc_types mapping to categories and max_results limit of 200. This adds significant meaning beyond the schema.
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?
The description clearly states it is an advanced search for a specific legal database with date range and document type filtering. It implies differentiation from siblings by being 'advanced' but does not explicitly contrast with similar tools like search_legal_interpretations.
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?
Provides explicit two-phase workflow recommendations, explains when to use doc_types, gives examples of first and second queries, and covers error handling with invalid doc_types. This gives clear guidance on how to use the tool effectively.
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?
Discloses key behaviors: local cache, zero latency, auto-updates every 7 days on server start, returns summary list. No annotations exist, so description carries burden. Does not mention potential staleness or permissions, but sufficient for a 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?
Structured with clear sections: purpose, cache details, scope, then Args. Front-loaded with essential info. Slightly verbose but every sentence adds value given the number of parameters.
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 9 parameters, no output schema, and no annotations, the description is very complete. Explains return format, pagination, filtering options, and links to related tool. No gaps identified.
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%, but description includes an Args section detailing all 9 parameters with examples and format hints (e.g., ISO dates, article_no like '22-1'). Adds significant meaning 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?
Clearly states it searches PCC letters (government procurement law interpretations). Uses specific verb '搜尋' and resource '工程會函釋'. Differentiates from siblings by mentioning local cache and linking to get_pcc_letter for 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use: for procurement law interpretation queries and citation verification. Mentions scope includes sub-laws. Implicitly excludes full-text retrieval (use get_pcc_letter). Lacks explicit exclusions but provides strong context.
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, so description carries full burden. Explains sorting behavior, pagination, and exclude_abolished effect. Does not explicitly state read-only nature but implied by search functionality.
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?
Concise overall, front-loaded with purpose. Some redundancy in explaining exclude_abolished both in overview and in the parameter list. Still efficient.
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?
Covers purpose, scope, parameters, return values, sorting, pagination. No output schema, but return description is adequate. Complete for a search tool.
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 0% description coverage; description adds meaning for all three parameters: keyword with examples, offset with default, exclude_abolished with behavior explanation. Significantly enhances 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?
Clearly states 'search regulation names by keyword', specifies scope (11,700+ regulations), and distinguishes from sibling tools that search other content like interpretations or judgments.
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 on when to use (search in full regulation list), sorting by active regulations first, pagination of 50 per page. Does not explicitly state alternatives but sibling tool names imply different content types.
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?
Despite no annotations, the description discloses the return structure (success, ty, id, doc_type, title, full_text, url, cached, timestamp) and explains ty codes. It indicates a read operation and does not hide any behavioral traits.
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 well-structured with a clear first sentence, a usage instruction, a formatted code mapping, and explicit Args/Returns sections. No extra words.
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 simple retrieval tool with two parameters and no output schema, the description covers purpose, usage context, parameter meaning, and return fields. It is fully sufficient for 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?
The input schema has 0% description coverage, so the description fully compensates by explaining that ty and doc_id come from search results and providing a complete translation table for ty codes.
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 '取得司法院法令判解系統單筆全文' (Get a single full text from the Judicial Yuan law interpretation system), clearly indicating the tool's function as a retrieval tool for a single item. It also specifies the prerequisite of using search_legal_interpretations, distinguishing its purpose from sibling tools.
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 clearly instructs to use parameters from search_legal_interpretations results, providing explicit when-to-use context. It also includes a mapping of ty codes, but does not explicitly contrast with sibling tools or say when not to use it.
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, so the description carries full burden. It describes return fields and advises on handling superseded status, implying a read-only operation. However, it does not explicitly state read-only nature or any side effects, but the 'get' verb makes it clear.
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 with no wasted sentences. It front-loads the purpose, immediately provides usage rules, then details parameters and return fields in a structured manner.
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 simple retrieval tool with no output schema, the description lists all expected return fields (22 items) and includes behavioral advice on handling results. This fully equips the agent to use and interpret the output correctly.
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 0% description coverage (only titles). The description compensates fully: explains letter_id is from search_pcc_letters results, and letter_no is a fuzzy match with an example. This adds critical meaning 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 the tool retrieves full text of a single PCC letter, including specific fields. This distinguishes it from sibling tools like search_pcc_letters (search) and other get_* tools for different document types.
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 states that letter_id and letter_no are alternatives (擇一提供), and provides a crucial usage condition: if status is superseded/partial, do not directly cite but instead refer to the superseding letter or mark as obsolete. This is high-quality guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: it is a search tool returning results with specific structure, lists supported doc types, and explains query syntax and pagination. No destructive actions hidden.
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 clear sections (intro, differences, doc_type list, pagination example, args, returns). Slightly lengthy but all content is useful; could be trimmed without losing clarity.
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?
Complete coverage: source website, query syntax, all parameter details, pagination, return format (fields). No output schema exists, but description fills that gap. Adequate for a complex search tool.
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%, but the description provides comprehensive meaning for all parameters: keyword with boolean operators, doc_type with valid values and default, max_results with default and max, offset with pagination use.
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?
Clearly states it searches a specific online legal database and enumerates the types of documents it can retrieve. Explicitly differentiates from get_interpretation and search_interpretations by describing scope and source.
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?
Provides explicit guidance on when to use this tool versus siblings: it is for online full-text search across multiple document types, while get_interpretation is for offline cache. Also explains pagination with example.
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

mcp-taiwan-legal-db-integrated MCP server

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/oldbear-meme/mcp-taiwan-legal-db-integrated'

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