The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the China Context MCP listing page.
把中文世界的数据源桥接成 AI 工具。零凭证、免交付、可验证。
🔎 已收录进官方 MCP Registry：io.github.mouseart2025/china-context-mcp —— 查看详情
mcp-name: io.github.mouseart2025/china-context-mcp
给 AI 提供工具/服务/资源，是未来需求的重要方向。但调研发现一个结构性缺口：
「<服务> mcp」 in:name,description，2026-09-25）缺口只在「广义中国服务→AI」这一层成立。本仓库是这条「桥接层」方向的最小可验证载体： 先把零凭证、公开 API、对中文 AI 真有用、且没被官方垄断的数据源接进来。
⚠️ 支付宝「支付 MCP」已被官方于 2025-04-15 发布，故本项目不重复造支付类 MCP，只接官方未覆盖的真空数据源。
| 工具 | 数据源 | 用途 |
|---|---|---|
random_poem | jinrishici.com | 随机一句中国古典诗词（作者/出处/分类），用于中文创作、文化问答、国学陪练 |
holiday_info(date) | timor.tech | 查询中国某日期是否为法定节假日、调休补班工作日、工资倍率 |
holiday_summary(year?) | timor.tech | 年度聚合摘要：连续假期区间与天数、法定 3 倍工资天数及具体是哪几天、调休补班清单、全年总休假天数。省略 year 用当年 |
history_today(date?) | 60s-api.viki.moe | 历史上的今天：某月某日的历史事件列表（标题/年份/简述）；省略 date 用今天 |
idcard_check(id) | 本地算法（不联网） | 中国身份证号校验 + 解析：按 ISO 7064 MOD 11-2 验证校验位，输出出生日期、性别、省级行政区，回显做掩码 |
holiday_summary 为什么是差异化的一层timor 的两个接口都只给扁平数据：holiday_info 一次一天，holiday/year 一次给全年条目。但它们给不出下面这些结论——而这些恰恰是最容易算错的：
逐日明细为什么一眼就要看全：3 倍工资在多数小长假里只有 1 天（2026 年元旦 01-01、清明 04-05、端午 06-19、中秋 09-25 才是法定节假当日，其余是周末或调休）。任何「不足 2 天就省略」的省流写法，都会让区间标题里的「（3倍工资 1 天）」变成查不到对应日期的空话。明细组是区间的等价划分，两者必须逐日对齐——回归测试用结构断言锁死了这一点。
另外，「2026 年清明节的 3 倍是哪天」这个问题有个易错点：国务院通知写的是「4 月 4 日至 6 日放假」，但清明节气当天是 4 月 5 日（2026-04-05 02:39 交节），所以 3 倍工资落在 04-05，不是区间首日 04-04。只看「起止日期」会答错。
一处必须记住的坑：合并假期区间要按日期连续性，不能按名称。中国法定假常把「春节」拆成 除夕/初一/初二…（且假日条目的 target 字段恒为 -，无法用于分组），按同名合并会把春节拆成 9 个单日区间，与「春节放 9 天」的用户心智严重不符。
年度聚合的正确性不靠自测自说，已逐项对过公开口径：
| 口径 | 本项目输出 | 第三方来源 |
|---|---|---|
| 2026 全年放假天数合计 | 33 天 | 国务院办公厅《关于 2026 年部分节假日安排的通知》 |
| 其中 3 倍工资天数（法定节假日） | 13 天 | 济南市人民政府12345问答、腾讯新闻（引劳动法第 44 条）、工人日报 |
| 其中 2 倍工资天数（休息日） | 20 天 | 同上（= 33 − 13，官方口径一致） |
| 调休补班（须上班）日 | 6 天：1/4、2/14、2/28、5/9、9/20、10/10 | China Briefing《China Public Holiday Schedule 2026》同表 |
这四组数字每年都被地方政府与媒体重算发布一遍，说明它同时具备两个属性： 唯一正确答案的确定性问题 ＋ 每年重做一次的手工劳动。 AI 直接给出确定答案，正落在工具的价值区间——这是本项目「编排层而非转述层」最实在的一处。
idcard_check 为什么值得单独一提这是本项目唯一不依赖第三方 API 的模块——纯本地算法，永远可用，不会被上游关停或 Cloudflare 拦截。
价值不在"算法稀缺"（Python 有现成库），而在于 AI 自己做 17 位加权求和 + 模 11 查表极容易算错：加权因子表错位、索引偏移、X 大小写处理，任何一个小错都会导致校验结论颠倒。把这件事从"AI 现场算"改成"AI 调用一次拿到确定答案"，价值是实打实的。
隐私边界：只解析国标公开字段，不触姓名、住址等隐私项；回显中间掩码，避免明文回传。
io.github.mouseart2025/china-context-mcpactive / isLatest=true（2026-09-25 上线）server.json；改动后执行 mcp-publisher publish 重新发布description 有 100 字符硬上限，超了会返回 422同一批检索（Registry search=china，2026-09-25，命中 38 条）里已经有一批人真在做中国侧 MCP。
把位置摆清楚，比假装没有对手有用：
| 服务 | 定位 | 与本项目的关系 |
|---|---|---|
com.ainetcafe/netcafe-china | 远程 HTTP：中国大陆可达性、调休 holidays、身份证/手机号校验 | 功能有重叠。但它是把号码 POST 到 ainetcafe.com 的远端服务；本项目的 idcard_check 全程在本地进程内算完，号码不出机器。校验一个身份证还要过一遍别人的服务器，这层差别是隐私级别的 |
io.github.pipeworx-io/china-* | 中国金融数据家族（LPR / A股 / 海关 / 外汇 / 空气质量…），均零凭证 | 走远程 gateway；本项目走本地 stdio，数据面是「节日 / 史 / 诗词 / 证件」这类生活与文化语境，不抢同一批用户 |
io.github.bg7iuy/china-phone | 手机号归属（工信部号段数据） | 不同号码体系，无冲突 |
❗修正一条此前的判断：本项目早期做过一轮「天气 / 空气质量 MCP 真空」扫描，GitHub Search 结论是 0 个仓库。 但 Registry 里其实已有
cn.pianam.mcp/weather-mcp-china与io.github.pipeworx-io/china-air-quality—— 只扫 GitHub Search 会漏掉已落地的实现，真空判据必须同时看 Registry。
一、被收录并不等于别人能连上。 2026-09-25 抽样了 Registry 上 40 个带远程端点的服务：
可连且能出工具 7 个（27%），19 个被站点主人拒绝（Cloudflare 1010），14 个因与本网络出口同形错误而无法判定。
Registry 的 remotes[].url 是提交者自己填的，没有任何存活校验。收录只是把地址写进一份名单。
二、目录面：逐条实测（2026-09-25 下午，带阳性/阴性对照）。
| 站点 | 实测结果 | 判定依据 |
|---|---|---|
| Glama | 已收录：glama.ai/mcp/servers/mouseart2025/china-context-mcp，可见 4 个工具（history_today / holiday_info / holiday_summary / random_poem），并带 Glama 自评 A 的 score badge | 直接 GET 详情页；对照一个假 slug 返回 404 |
| Smithery | 命中仅在 {"q":"?q=china-context-mcp"} 里 | 页面查询串自回显 |
| PulseMCP | 命中仅在 <input value="…"> 里 | 搜索框自回显 |
| mcp.so | 未收录；加急发布标 $39 one-time，免费走人工 review | mcp.so/submit 页原文；未登录态下表单 POST 只回到同一 SPA 页，拿不到任何提交回执 |
| LobeHub | 未收录；条目页对已收录项返回 200、对未收录项返回 500 | 阳性对照 upstash-context7 = 200；org 下只有 mcp-hello-world，无公开列表仓库，找不到自提交入口 |
这里推翻了先前「Glama / LobeHub 均为 SPA，HTML 里判不出」的说法： Glama 用双段 slug
owner/repo（不是单段china-context-mcp），所以先前那轮扫到了一个 SPA 外壳页； LobeHub 的条目页是服务端渲染的，200/500 本身就是可用的收录判别器。
一个意外收获：我们从未向 Glama 提交过。它是在官方 Registry 发布后 由 Glama 自己的爬虫抓过去的 —— 说明 Registry 的链接会外溢到第三方目录，提交 Registry 是有复利的动作。
三、已做、仍在自动生效的发行动作（无需人工，爬虫会自己抓）：
mcp-server / model-context-protocol / china / holiday / idcard / pythonsmithery.yaml 与 .mcp.json —— Smithery 的 scanner 两者都要有，只有 smithery.yaml 会校验失败status=active；glama.json 已加在根目录，格式经 Glama 自家
https://glama.ai/mcp/schemas/server.json 校验通过（认领凭证，见下）四、已自动提交的收录申请（2026-09-25）：
| 目标 | 形态 | 状态 |
|---|---|---|
| punkpeye/awesome-mcp-servers（95.5k★） | PR #15083，插入 Data Platforms 段字母序位 | 已开，标题带 🤖🤖🤖 走 CONTRIBUTING 里的 agent 快通道 |
| TensorBlock/awesome-mcp-servers（864★，当日有更新） | issue #2669，走其 add-mcp-server 表单，目标分类 Data Analysis & Business Intelligence | 已开，等待其机器人转 PR |
| Glama 认领 | 仓库根 glama.json → {"maintainers":["mouseart2025"]} | 已就位，下次同步生效 |
前一条「仍需人工的：Glama 认领、mcp.so / LobeHub 表单提交」作废。 Glama 那条其实只要一个 JSON 文件；mcp.so 的免费路径要先登录；LobeHub 压根没有自提交入口。
五、仍未打通的：mcp.so（付费或登录态）、LobeHub（无入口，只能等其运营收录或由人去提 PR）。 这两家规则不同、没有统一入口，且都不影响可运行性 —— 收录只影响被发现的概率。
已发布 PyPI（v0.1.4，Python ≥ 3.10）：
若用 uv，一行即可（自动解依赖）：
也可以直接从 GitHub 装（开发版，未经发布流程校验）：
依赖：mcp、fastmcp（Python ≥ 3.10）。
在 Claude Desktop / Cursor / 任意支持 MCP 的客户端配置：
或指向模块：
⚠️ 默认只绑
127.0.0.1。要对外暴露需显式传--host，并自行承担鉴权 —— 本服务不带任何鉴权层，直接暴露在公网等于开放一个无限制的出站代理入口。 本仓库自身不提供托管端点。
holiday_info 在「上游无数据的年份」会给出自信的错误答案| 项 | 内容 |
|---|---|
| 受影响版本 | v0.1.0 – v0.1.3 |
| 受影响查询 | 查询上游尚未收录年份（如 2027、2028）的日期 |
| 错误表现 | 例如 holiday_info("2027-01-01") 返回「法定假日：否 / 是否工作日：是 / 工资倍率：1x」 |
| 为什么是错的 | 元旦（1/1）、劳动节（5/1–5/2）、国庆（10/1–10/3）是《全国年节及纪念日放假办法》直接规定的公历固定法定节假日，与年度调休、与年份都无关 —— 任何年份都必须是「是」 |
| 根因 | h = d.get("holiday") or {}：把「该年份无数据」与「这天确定是普通工作日」压成了同一种状态 |
| 附带矛盾 | 同一服务的 holiday_summary(2027) 会说「暂无收录」，两个工具互相打脸 |
| 已修复版本 | v0.1.4 |
| 修复方式 | 新增法规常量层（statutory.py + statutory_dates.json，离线、不联网、不引入农历库），holiday_info 改为三态判别：有数据 / 无数据但属固定法定日 / 无数据且未知 ⇒ 未知一律说「无法确定」，绝不说「否」；holiday_summary 同步回落到同一层 |
该缺陷是纯逻辑问题，与网络、部署地域无关，任何环境都会复现。 每年 11–12 月（查询次年假期的高峰）正是它的高发窗口。
MIT