How do I use aluris-caselibrary-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@aluris-caselibrary-mcp 搜索与工伤认定争议相似的案例" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

aluris-caselibrary-mcp

by alexchenlin1996-pixel

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

法随·案例库 MCP

面向法律实务的权威案例与司法规则 MCP。聚焦最高法指导案例、公报案例、典型案例、案例库案例，同时纳入最高检指导性案例、最高检典型案例和法答网问答，方便法律人在办案、文书写作和类案检索中快速找到可引用、可核验、低噪音的权威依据。

大型法律数据库解决“查得全”，法随案例库 MCP 解决“AI 办案时优先查到权威案例和司法规则”。

案例覆盖

类型	数量	引用价值
案例库案例	5,211	重要参考
指导案例	556	应优先引用
典型案例	544	重要参考
公报案例	461	权威参考
最高检指导性案例	239	重要参考
最高检典型案例	196	参考
法答网	165	辅助参考
合计	7,372

Related MCP server: MCP Taiwan Judgment Search

适用场景

办案时检索最高法、最高检权威案例和司法规则
起诉状、答辩状、代理意见中的裁判规则论证
类案检索报告中的案例筛选和引用摘要
法律适用口径、司法问答和实务规则核验
AI 法律助手需要调用低噪音案例来源时

快速配置（远端模式，推荐）

推荐地址：https://aluris.top/mcp

该地址同时兼容 Streamable HTTP 和 SSE。

无需安装 Python，无需下载数据，直接在 AI 客户端里填入以下配置即可。WorkBuddy、Claude、Cursor 等使用“URL / HTTP MCP”配置的客户端，直接填写推荐地址；如果客户端要求选择类型，优先选择 Streamable HTTP / HTTP MCP。

WorkBuddy（推荐）

远端 MCP 地址：

URL: https://aluris.top/mcp
类型: Streamable HTTP / HTTP MCP

已在 WorkBuddy v4.22.16 实测通过。推荐配置路径：

打开 WorkBuddy 左侧「连接器」
点击右上角「自定义连接器」
进入「MCP 服务管理」后点击「配置 MCP」
在 ~/.workbuddy/mcp.json 的 mcpServers 中加入：

{
  "mcpServers": {
    "fasui-caselibrary": {
      "type": "http",
      "url": "https://aluris.top/mcp",
      "description": "法随案例库：最高法、最高检、法答网权威案例检索，结果包含裁判规则、引用摘要和原文链接。",
      "disabled": false
    }
  }
}

返回 MCP 列表，点击「信任」；正常状态会显示 fasui-caselibrary 7/7 个工具已启用

不要填写 https://aluris.top/mcp/http。如果在普通聊天框里直接粘贴 URL，WorkBuddy 可能会把它当作网页抓取；请通过「连接器 / 自定义连接器」入口配置 MCP。

如果 WorkBuddy 的配置项只有 SSE 类型，仍使用同一个地址：

URL: https://aluris.top/mcp
类型: SSE

Claude Desktop

配置文件路径：

macOS：~/Library/Application Support/Claude/claude_desktop_config.json
Windows：%APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "法随案例库": {
      "url": "https://aluris.top/mcp"
    }
  }
}

如果文件里已有其他 MCP 服务，在 mcpServers 对象里追加一个键即可：
{
  "mcpServers": {
    "已有的服务": { "...": "..." },
    "法随案例库": {
      "url": "https://aluris.top/mcp"
    }
  }
}

修改完重启 Claude Desktop 生效。

Cursor

配置文件路径：~/.cursor/mcp.json（全局）或项目根目录 .cursor/mcp.json

{
  "mcpServers": {
    "法随案例库": {
      "url": "https://aluris.top/mcp"
    }
  }
}

Windsurf

配置文件路径：~/.codeium/windsurf/mcp_config.json

{
  "mcpServers": {
    "法随案例库": {
      "url": "https://aluris.top/mcp"
    }
  }
}

MyAgents / 其他支持 SSE 的 MCP 客户端

在 MCP 服务器配置里填入：

URL: https://aluris.top/mcp
类型: SSE (HTTP)

MCP 工具说明

配置完成后，AI 可使用以下工具：

工具	用途
`search_authoritative_cases`	检索权威案例与司法规则，优先返回高引用价值来源
`search_similar_cases`	语义检索类案，兼容旧客户端调用
`get_case_detail`	按案例编号展开完整信息、权威类型、引用价值、适用场景
`find_rules_by_issue`	按法律争点查裁判规则
`generate_case_citation_brief`	按案例编号生成可放进检索报告或代理意见的案例引用摘要
`filter_cases`	按法院、年份、案由、来源精确过滤
`library_stats`	查看案例库统计数据

检索结果默认以卡片方式返回，每条卡片直接包含详情摘要、裁判规则、引用摘要和原文链接。案例编号主要用于继续展开全文或重新整理格式；需要最终汇总清单时，可以再要求整理为表格。

为方便直接写入类案检索报告，卡片会展示“命中原文依据”和“来源位置”。该段文字只从已入库的裁判要点、裁判规则、法答网答复正文或其他原文字段中截取，不根据标题或案情补写；正式引用前仍建议点击原文链接核验上下文。

示例提问：

“帮我找小股东被拒绝查阅会计账簿的案例”
“搜索建设工程优先受偿权的指导案例”
“有没有涉及格式条款无效的公报案例”
“查一下最高检关于公益诉讼惩罚性赔偿的指导性案例”
“法答网有没有关于执行异议之诉的答复口径”
“给我生成这个案例的代理意见引用摘要”

权威排序

检索结果会综合考虑语义相似度、来源权威、新近程度和来源匹配。默认权重如下：

来源	权重	引用提示
指导案例	1.00	应优先引用
公报案例	0.94	权威参考
典型案例	0.88	重要参考
最高检指导性案例	0.86	重要参考
案例库案例	0.82	重要参考
最高检典型案例	0.78	参考
法答网	0.70	辅助参考

引用安全

案例库会把检索和引用分开处理。语义检索可以返回相关案例，引用摘要只基于原始字段或原文中已经存在的规则段落生成，不根据标题、案情或相似案例补写规则。

规则质量分为：

等级	含义	用途
A	裁判要点、裁判摘要、执行实施要点、法答网答复等明确规则文本	可生成引用摘要
B	典型意义、案例分析、法院认为、检察监督意见等规则线索	可生成引用摘要，但提示核验
D	未提取到可引用规则段落	只作为案例线索，不生成引用摘要

search_authoritative_cases 和 find_rules_by_issue 默认只返回 A/B 级结果。generate_case_citation_brief 遇到 D 级案例会拒绝生成摘要，并提示打开原文核验。

本地部署（可选）

如需本地运行（数据存本地、支持增量同步），参考以下步骤：

git clone https://github.com/alexchenlin1996-pixel/aluris-caselibrary-mcp.git
cd aluris-caselibrary-mcp
uv sync
uv run python sync.py          # 首次拉取案例数据（需要时间）

本地 stdio 模式（Claude Desktop）：

{
  "mcpServers": {
    "法随案例库-本地": {
      "command": "uv",
      "args": ["run", "python", "/path/to/aluris-caselibrary-mcp/server.py"],
      "env": {
        "CASE_DB_PATH": "/path/to/case_db"
      }
    }
  }
}

本地 HTTP 模式：

uv run python server.py --transport http --port 8765

无外部 API 依赖——embedding 使用本地 BGE 模型，首次运行自动下载（约 100MB）。

目录结构

├── server.py           # MCP 入口，支持 stdio / HTTP 双模式
├── search.py           # 两阶段检索（embedding + reranker）
├── embed.py            # fastembed + BAAI/bge-small-zh-v1.5
├── sync.py             # 增量同步协调器
└── sources/
    ├── case_library.py # 最高院案例库（rmfyalk，需登录）
    ├── guide_case.py   # 指导案例（公开）
    └── public_sources.py # 公报案例 + 法答网（公开）

Available Tools

8 tools

filter_casesB

按条件精确过滤案例（不做语义搜索），支持法院、年份、案由、来源等维度。

ParametersJSON Schema

Name	Required	Description
`cat`	No
`cause`	No
`court`	No
`limit`	No	返回数量上限，默认 30
`source`	No
`year_max`	No
`year_min`	No

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It mentions exact filtering behavior but does not disclose whether the tool is read-only, how results are returned, pagination, or error handling. This is insufficient for a 7-parameter 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 a single, concise sentence that front-loads the key purpose. It contains no redundant information. However, additional structure (e.g., listing dimensions) could improve clarity without adding length.

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?

For a tool with 7 parameters, no output schema, and no annotations, the description is too brief. It fails to explain return values, parameter interactions, or typical use cases, leaving significant gaps for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description lists dimensions (court, year, cause, source) that map to some parameters, adding context beyond the schema where only 'limit' has a description. However, it does not explain parameter formats, allowed values, or the 'cat' parameter. Given low schema coverage (14%), the description partially compensates but is not comprehensive.

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 filters cases precisely by conditions and explicitly says it does not perform semantic search, which distinguishes it from siblings like search_authoritative_cases and search_similar_cases. The verb 'filter' and resource 'cases' are specific.

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 for exact filtering (no semantic search) but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. The guidance is implicit from the '不做语义搜索' note, but lacks direct direction.

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

find_rules_by_issueC

按法律争点查找权威案例和裁判规则，例如股东知情权、建设工程优先受偿权、格式条款效力。

ParametersJSON Schema

Name	Required	Description
`cat`	No
`issue`	Yes	法律争点或裁判规则关键词
`top_k`	No	返回结果数量，默认 6
`source`	No
`year_max`	No
`year_min`	No

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits such as authentication, rate limits, or output format. It only states what the tool does without further context.

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 one concise sentence with examples, making it easy to read. However, it could be slightly more structured.

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?

With 6 parameters and no output schema, the description is incomplete. It does not explain optional parameters like cat, source, or year range, which are critical for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% (only 'issue' described). The description adds no parameter-level details beyond the schema, failing to compensate for the low coverage.

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 the tool finds authoritative cases and adjudication rules by legal issue, with examples. It is specific about the resource and action, but could be more distinct from siblings like search_authoritative_cases.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. Siblings exist but no differentiation is provided.

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

generate_case_citation_briefA

按搜索结果中的案例编号生成可放入类案检索报告、代理意见或法律分析的案例引用摘要。

ParametersJSON Schema

Name	Required	Description	Default
`local_id`	Yes	案例编号（搜索结果卡片底部显示的编号）

TDQS

A3.7/5.0

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 states generation of a citation abstract but does not disclose side effects, permissions, rate limits, or whether it is read-only. The description is adequate but lacks depth on 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently conveys the tool's purpose and context. It is front-loaded and free of fluff, though slightly lengthy in Chinese characters.

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?

For a tool with one simple parameter and no output schema, the description provides enough context: input from search results, output for reports. It covers the main use case and the sibling tools list gives broader context. Minor lack of output format details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description of 'local_id'. The description adds context that the number comes from search results and output is a citation abstract, but does not add meaning beyond the schema's parameter description.

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 verb (generate), resource (case citation brief), and context (from search result case number). It distinguishes from sibling tools like get_case_detail and search_similar_cases by focusing on generating a citation abstract for reports and opinions.

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 a case number is available from search results and a brief citation is needed, but it lacks explicit 'when to use' vs 'when not to use' guidance or mention of alternatives. The context from sibling tools helps but is not explicit.

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

get_case_detailA

按搜索结果中的案例编号获取完整信息（基本案情、裁判理由、全文等）。

ParametersJSON Schema

Name	Required	Description	Default
`local_id`	Yes	案例编号（搜索结果卡片底部显示的编号）

TDQS

A3.7/5.0

Behavior3/5

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

No annotations provided, so description carries the burden. It indicates a read operation and lists returned content, but lacks details on side effects, permissions, or rate limits. Adequate for a simple get but not extra informative.

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?

Single sentence that is front-loaded with the action and resource. Efficient with no fluff, but could include brief usage note.

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 param, no output schema), the description suffices for correct invocation. However, it does not clarify the output format, though that might be obvious.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds little beyond the schema's own description of local_id as case number from search results. Baseline 3 is appropriate.

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 specifies the action (获取完整信息) and resource (案例编号), and lists specific content (基本案情、裁判理由、全文等). It distinguishes from sibling tools that focus on searching or filtering cases.

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?

Implies usage after search results are obtained, but does not explicitly state when to use this tool over siblings or mention any prerequisites or exclusions.

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

library_statsA

查看案例库统计数据：总数、类别分布、数据源分布、年份范围。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

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 the outcome (statistics) but does not mention performance, data freshness, or authorization requirements. The tool is simple and read-only, so a moderate score is appropriate.

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 a single sentence that is front-loaded with the main action and lists key statistics clearly. It is concise with no redundant 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?

Given the tool has no parameters, no output schema, and no annotations, the description provides sufficient context for a simple statistics reporting tool. It could be more detailed about output format or error cases, but it is adequately complete for its simplicity.

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?

There are zero parameters, and schema coverage is 100%. The description adds value by explaining what the output contains (total count, distributions, year range), which is beyond the schema's empty definition.

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: viewing case library statistics including total count, category distribution, data source distribution, and year range. It distinguishes itself from sibling tools like filter_cases or get_case_detail, which are for specific queries or details.

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 for obtaining aggregate statistics, but does not explicitly state when to use this tool over alternatives like filter_cases or search functions. No exclusion criteria or contextual cues are provided.

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

search_authoritative_casesA

检索权威案例与司法规则。优先返回最高法、最高检、法答网等权威来源，并标注权威类型、引用价值和适用场景。

ParametersJSON Schema

Name	Required	Description
`cat`	No	案件类别过滤：民事/刑事/行政/执行/国家赔偿/调解
`query`	Yes	自然语言查询，描述案件事实、法律争点或希望查找的裁判规则
`top_k`	No	返回结果数量，默认 8
`source`	No	来源过滤：指导案例/公报案例/典型案例/案例库案例/最高检指导性案例/最高检典型案例/法答网
`year_max`	No	最大年份
`year_min`	No	最小年份
`court_like`	No	法院名称模糊匹配

TDQS

A3.9/5.0

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 the tool prioritizes authoritative sources and annotates results with authority type and citation value. However, it does not detail other behavioral aspects like rate limits, authentication, or handling of edge cases.

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 a single, well-structured sentence that front-loads the main action and includes key details about prioritization and annotations. Every phrase serves a purpose with no redundancy.

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?

Given 7 parameters and no output schema, the description gives a reasonable overview but lacks details on expected output format, pagination, or limitations. It hints at output annotations but is not fully comprehensive for a complex search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema; it only provides a high-level purpose. No parameter-specific elaboration is given.

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 retrieves authoritative cases and judicial rules, prioritizing specific high-level sources like the Supreme Court and annotates authority type and citation value. This distinguishes it from sibling tools like 'filter_cases' or 'search_similar_cases', which lack this focus.

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 the tool is for authoritative case and rule search from specific sources. While it provides clear context for when to use it, it does not explicitly mention when not to use it or suggest alternatives (e.g., for general search).

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

search_similar_casesA

语义检索类案。输入自然语言描述（如'小股东查账被拒'），返回相关案例，并标注权威类型和引用价值。

ParametersJSON Schema

Name	Required	Description
`cat`	No	案件类别过滤：民事/刑事/行政/执行/国家赔偿/调解
`query`	Yes	自然语言查询，描述案件事实或法律问题
`top_k`	No	返回结果数量，默认 10
`source`	No	来源过滤：指导案例/公报案例/典型案例/案例库案例/最高检指导性案例/最高检典型案例/法答网
`year_max`	No	最大年份
`year_min`	No	最小年份
`court_like`	No	法院名称模糊匹配

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided. The description notes that results include authority type and citation value, and implies semantic search (not keyword). However, it lacks details on authentication, rate limits, or data scope.

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 a single clear sentence in Chinese, front-loading the purpose. It is concise but could benefit from a more structured format to include parameter details.

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?

Despite 7 parameters and no output schema, the description focuses only on the query functionality. It does not explain how filtering parameters (cat, source, year, court) interact or describe output format. Underdescribed for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds minimal meaning beyond the schema, only contextualizing the 'query' parameter with an example. No additional semantics for filtering 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 performs semantic retrieval of similar cases using natural language input, with an example. It distinguishes itself from sibling tools like filter_cases (structured filtering) and search_authoritative_cases (specific type search).

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 use for natural language queries to find similar cases, but does not explicitly state when to use this tool versus alternatives like filter_cases or search_authoritative_cases. No exclusions or prerequisites are mentioned.

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

sync_nowA

手动触发案例库增量同步（从 rmfyalk 拉取最新入库案例）。同步可能需要数分钟，完成后返回新增案例数。

ParametersJSON Schema

Name	Required	Description	Default
`source`	No	数据源：case_library（默认）或 all	case_library
`dry_run`	No	仅检查不写入，默认 false

TDQS

A3.8/5.0

Behavior3/5

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

Discloses that sync may take minutes and returns the count of new cases, and the dry_run parameter hints at idempotency. However, with no annotations, it does not fully describe side effects like whether data is modified or concurrent usage implications.

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?

Two concise sentences, front-loaded with the core purpose, and each sentence provides necessary information without waste.

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?

Adequately explains purpose, inputs, latency, and return value for a simple tool with no output schema. Could elaborate on the return format and the meaning of source options.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters with descriptions; the tool description adds no additional meaning beyond what the schema already provides.

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 the tool triggers an incremental sync from rmfyalk, retrieves latest cases, and returns the count. The verb and resource are specific, and it differentiates from sibling tools that are for filtering, searching, or getting details.

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?

Implicitly indicates manual triggering but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.1.0Jul 7, 2026
- First observedfilter_cases
- First observedfind_rules_by_issue
- First observedgenerate_case_citation_brief
- First observedget_case_detail
- First observedlibrary_stats
- First observedsearch_authoritative_cases
- First observedsearch_similar_cases
- First observedsync_now

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-07-07 10:55 across 8 tools

Disambiguation4/5

Each tool has a distinct purpose: precise filtering, rule finding, citation generation, detail retrieval, statistics, authoritative search, semantic search, and sync. There is minor potential confusion between filter_cases and search_authoritative_cases, but descriptions clarify the difference.

Naming Consistency4/5

Most tools follow a verb_noun pattern in snake_case (e.g., filter_cases, get_case_detail). 'library_stats' and 'sync_now' deviate slightly, but overall naming is predictable and readable.

Tool Count5/5

Eight tools cover the essential operations for a case library: search, filter, detail, rules, citations, statistics, and sync. The count is well-scoped without being excessive or insufficient.

Completeness4/5

The tool set covers core use cases like searching, filtering, and retrieving case details and rules. It lacks explicit tools for adding or deleting cases, but that aligns with a read-only library with external sync. Minor gap in batch operations.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ezelOAuth
ai.ezel
Search U.S. case law, fetch opinions, and ask matter-aware legal questions over your documents.
Legal & Compliance Search
2
kvasir — verifiable German, Austrian, Swiss & EU lawOAuth
legal.kvasir
Resolve, search and verify legal citations against the official sources, with provenance.
Legal & Compliance Search
2
Jurisprudência A
io.github.mcp-dir
Case law search, court decisions and súmulas, across indexed public sources (STF, STJ, TST, state co
Legal & Compliance Search
91
tw-legal-ragOAuth
io.github.aa0101181514
Citation-guarded retrieval over 22M Taiwan court judgments and administrative interpretations
RAG Systems Legal & Compliance
1317

Related MCP Servers

law-search-mcp
Search Government Data Open Data
memorise8
F
license
A
quality
D
maintenance
Enables searching and retrieving Korean Supreme Court precedents from the law.go.kr Open API, with support for keyword search and detailed judgment text.
Updated 4 months ago (2026-05-26 06:04 UTC)
2
-
MCP Taiwan Judgment Search
Legal & Compliance Government Data
asgard-ai-platform
A
license
A
quality
D
maintenance
Enables searching and retrieving Taiwan judicial judgments, including full-text search, document details, PDF download, and legal term lookup via MCP tools.
Updated 5 months ago (2026-04-19 15:38 UTC)
4
MIT
SinoVerdict MCP Server
Legal & Compliance Search Government Data
jack0752168
F
license
A
quality
B
maintenance
Enables AI assistants to search and analyze over 1.1 million structured Chinese labor dispute judgments, providing class cases, statistics, and source links.
Updated a month ago (2026-08-15 07:21 UTC)
7
-
@theyahia/casebook-mcp
Legal & Compliance Search Government Data
theYahia
A
license
A
quality
D
maintenance
Enables searching and retrieving Russian legal cases, court documents, participant information, judge statistics, and hearing schedules from Casebook/Pravo.ru.
Updated 5 months ago (2026-04-01 16:31 UTC)
8
8 npm
MIT