China Context MCP

china-context-mcp

中国語圏のデータソースを AI ツールに橋渡しします。認証情報不要、セットアップ不要、検証可能です。

🔎 公式 MCP Registry に登録済み：io.github.mouseart2025/china-context-mcp —— 詳細を見る

mcp-name: io.github.mouseart2025/china-context-mcp

なぜこれを作るのか

AI にツール／サービス／リソースを提供することは、今後重要なニーズとなる方向性です。しかし、調査の結果、構造的なギャップが見つかりました。

• 国際サービス（GitHub / Slack / Notion…）の MCP サーバーのカバレッジは、リポジトリ数の中央値が約 1554 件です。
• 中国のサービス（WeChat / Alipay / Feishu / Douyin…）の MCP カバレッジは、中央値がわずか 88 件で、17.7 倍の差があります。 （データ：GitHub Search 「<サービス> mcp」 in:name,description、2026-09-25）

ギャップが存在するのは、「広義の中国サービス→AI」という層に限られます。このリポジトリは、この「橋渡し層」という方向性の最小の検証可能な実装です。 まずは認証情報不要、公開 API、中国語 AI に実際に役立ち、公式サービスに独占されていないデータソースを接続します。

⚠️ Alipay の「決済 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 の 2 つのインターフェースが返すのは、いずれもフラットなデータだけです。holiday_info は一度に 1 日、holiday/year は一度に年間の項目を返します。しかし、以下の結論は導き出せません。しかも、まさに計算を間違えやすい内容です。

2026 年中国节假日与调休摘要

【假期区间】共 7 个，合计 33 天（不含补班）
  · 元旦  01-01 ~ 01-03   3天（3倍工资 1 天）
      3倍 1 天：01-01
      2倍 2 天：01-02、01-03
  · 春节  02-15 ~ 02-23   9天（3倍工资 4 天）
      3倍 4 天：02-16、02-17 初一、02-18 初二、02-19 初三
      2倍 5 天：02-15、02-20 初四、02-21 初五、02-22 初六、02-23 初七
  · 清明节  04-04 ~ 04-06   3天（3倍工资 1 天）
      3倍 1 天：04-05
      2倍 2 天：04-04、04-06
  · 劳动节  05-01 ~ 05-05   5天（3倍工资 2 天）
      3倍 2 天：05-01、05-02
      2倍 3 天：05-03、05-04、05-05
  · 端午节  06-19 ~ 06-21   3天（3倍工资 1 天）
      3倍 1 天：06-19
      2倍 2 天：06-20、06-21
  · 中秋节  09-25 ~ 09-27   3天（3倍工资 1 天）
      3倍 1 天：09-25
      2倍 2 天：09-26、09-27
  · 国庆节  10-01 ~ 10-07   7天（3倍工资 3 天）
      3倍 3 天：10-01、10-02、10-03
      2倍 4 天：10-04、10-05、10-06、10-07

【调休补班】共 6 天
  · 01-04 元旦后补班（调休上班，非假日）
  · 02-14 春节前补班（调休上班，非假日）
  · 02-28 春节后补班（调休上班，非假日）
  · 05-09 劳动节后补班（调休上班，非假日）
  · 09-20 中秋节前补班（调休上班，非假日）
  · 10-10 国庆节后补班（调休上班，非假日）

【工资倍率】3倍 13 天 / 2倍 20 天

日ごとの詳細を一目で確認できる必要がある理由：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-04 ではなく、04-05 です。「開始日と終了日」だけを見ると、回答を間違えます。

必ず覚えておくべき落とし穴：連休の期間を統合するときは、名称ではなく日付の連続性に基づいてください。中国の法定祝日は「春節」を除夕／初一／初二…に分けることがよくあります（また、祝日の項目では target フィールドが常に - で、グループ化に使えません）。同じ名称で統合すると、春節が 9 つの単日区間に分かれてしまい、「春節は 9 日間休み」というユーザーの認識と大きく食い違います。

外部とのクロスチェック（2026-09-25）

年間集約の正確性は、自己テストの結果だけに頼っていません。公開されている情報と項目ごとに照合済みです。

基準	本プロジェクトの出力	第三者の情報源
2026 年の年間休日日数の合計	33 日	国務院弁公庁「2026 年の一部祝日のスケジュールに関する通知」
うち 3 倍賃金の日数（法定祝日）	13 日	済南市人民政府12345 Q&A、Tencent News（労働法第 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」と同じ

この 4 つの数字は、毎年、地方政府やメディアによって再計算され、発表されています。これは、次の 2 つの性質を同時に備えていることを示します。 正解が 1 つに定まる問題 ＋ 毎年繰り返される手作業。 AI が確定した答えを直接提示できる点は、まさにツールの価値が発揮される領域です——これが、本プロジェクトが「伝達層」ではなく「編成層」であることを最もよく示す例です。

idcard_check を個別に取り上げる理由

これは本プロジェクトで唯一、サードパーティ API に依存しないモジュールです。完全なローカルアルゴリズムで、いつでも利用でき、上流サービスの停止や Cloudflare によるブロックの影響を受けません。

価値は「アルゴリズムが希少」であることではありません（Python には既存のライブラリがあります）。AI が 17 桁の加重合計と 11 を法とする参照表の照合を自力で行うと、非常に間違えやすいことにあります。加重係数表のずれ、インデックスのオフセット、X の大文字・小文字の扱いなど、どれか 1 つの小さなミスでも検証結果が逆になってしまいます。この処理を「AI がその場で計算する」から「AI が一度呼び出して確定した答えを得る」に変えることには、確かな価値があります。

[idcard] 11010519491231002X → 有效
  校验位：X 正确（ISO 7064 MOD 11-2）
  出生日期：1949-12-31
  性别：女（顺序码 2 为偶）
  省级行政区：北京市（11）
  回显掩码：110105********X

プライバシーの境界：国家標準で公開されている項目のみを解析し、氏名、住所などのプライバシー情報には触れません。表示時は中間部分をマスクし、平文が返送されないようにします。

公式 MCP Registry に登録済み

• 名前：io.github.mouseart2025/china-context-mcp
• ステータス：active / isLatest=true（2026-09-25 公開）
• 宣言ファイル：リポジトリのルートディレクトリにある server.json。変更後は mcp-publisher publish を実行して再公開してください
• 注意：description には 100 文字の上限があります。超過すると 422 が返されます

Registry 上の他の「中国のサービス」との関係

同じ検索（Registry の search=china、2026-09-25、38 件ヒット）では、中国向け MCP に実際に取り組んでいる人たちがすでに見つかっています。 競合がいないふりをするより、位置づけを明確にするほうが有益です。

サービス	位置づけ	本プロジェクトとの関係
com.ainetcafe/netcafe-china	リモート HTTP：中国本土からのアクセス可否、振替休日、身分証／携帯電話番号の検証	機能が一部重複しています。ただし、番号を ainetcafe.com に POST するリモートサービスです。本プロジェクトの idcard_check はすべてローカルプロセス内で計算するため、番号が端末の外に出ることはありません。身分証を検証するために他者のサーバーを経由する必要があるかどうかは、プライバシーのレベルに関わる違いです
io.github.pipeworx-io/china-*	中国の金融データ群（LPR / A 株 / 税関 / 外国為替 / 大気質…）、いずれも認証情報不要	リモートゲートウェイを使用します。本プロジェクトはローカル 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 は 2 段の slug owner/repo（1 段の china-context-mcp ではありません）を使うため、前回の調査では SPA の外枠ページにたどり着いていました； LobeHub の項目ページはサーバーサイドレンダリングで、200 / 500 自体が掲載状況を判定する手段になります。

意外な収穫：Glama には一度も提出していません。公式 Registry で公開した後、 Glama 自身のクローラーが取得していました —— Registry のリンクはサードパーティのディレクトリにも広がることを示しています。Registry への登録は、複利効果のある取り組みです。

三、実施済みで、現在も自動的に有効な公開施策（手動作業不要。クローラーが自動取得します）：

• リポジトリの topics を mcp-server / model-context-protocol / china / holiday / idcard / python に設定済み
• リポジトリのルートディレクトリに smithery.yaml と .mcp.json を配置済み —— Smithery の scanner には両方が必要で、smithery.yaml だけでは検証に失敗します
• 公式 Registry で公開済み、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 の エージェント向け優先ルートを利用
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 ファイルを 1 つ置くだけで済みます。mcp.so の無料ルートは先にログインが必要です。LobeHub にはそもそも自分で提出する入口がありません。

五、まだ未対応のもの：mcp.so（有料、またはログイン状態が必要）、LobeHub（入口がなく、運営側による掲載を待つか、人手で PR を出すしかありません）。 この 2 サイトはルールが異なり、共通の入口もなく、いずれも実行可能性には影響しません —— 掲載によって変わるのは、見つけられる可能性だけです。

インストール

PyPI で公開済み（v0.1.4、Python ≥ 3.10）：

pip install china-context-mcp

uv を使う場合は、1 行でインストールできます（依存関係を自動解決）：

uvx china-context-mcp

GitHub から直接インストールすることもできます（開発版。リリース手順による検証は未実施）：

git clone https://github.com/mouseart2025/china-context-mcp.git
cd china-context-mcp
pip install -e .

依存関係：mcp、fastmcp（Python ≥ 3.10）。

AI クライアントへの接続（stdio）

Claude Desktop / Cursor / MCP に対応する任意のクライアントで設定します：

{
  "mcpServers": {
    "china-context": {
      "command": "china-context-mcp"
    }
  }
}

または、モジュールを指定します：

{
  "mcpServers": {
    "china-context": {
      "command": "python",
      "args": ["-m", "china_context_mcp"]
    }
  }
}

ローカルでの検証

python -m china_context_mcp   # 启动 stdio 服务，由 MCP 客户端连接

HTTP（streamable-http）で起動

python -m china_context_mcp --transport streamable-http --port 8791
# → http://127.0.0.1:8791/mcp

⚠️ デフォルトでは 127.0.0.1 のみをバインドします。外部に公開するには --host を明示的に指定し、認証はご自身の責任で設定してください —— このサービスには認証レイヤーがなく、インターネットに直接公開すると、制限のないアウトバウンドプロキシの入口を開放することになります。 このリポジトリ自体はホストされたエンドポイントを提供しません。

修正済みの不具合（公開開示）

v0.1.4：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) は「登録データなし」と返すため、2 つのツールの回答が食い違います
修正済みバージョン	v0.1.4
修正方法	法規定の定数レイヤー（statutory.py + statutory_dates.json）を新設（オフラインで動作し、ネットワーク接続不要、旧暦ライブラリも追加しません）。holiday_info を 3 状態判定に変更：データあり / データはないが固定法定休日 / データがなく不明 ⇒ 不明な場合はすべて「判定できません」とし、「いいえ」とは回答しません。holiday_summary も同じレイヤーにフォールバックするよう変更

この不具合は純粋なロジック上の問題で、ネットワークやデプロイ先の地域とは無関係です。どの環境でも再現します。 毎年 11～12 月（翌年の休日を照会するピーク時期）が、特に発生しやすい時期です。

---

ロードマップ（データソース待ち、希少性順）

• 今日は何の日（認証情報不要。60s-api.viki.moe に接続済み）
• 大気質 / 天気（中国。公開ソースの多くは key が必要なため、認証情報不要のソースを探索中）
• 成語辞典（認証情報不要）⏸ 保留：muxiaoguo/oick/oioweb/aa1/codelife/xxapi/qqsuu などの候補を実測済みですが、利用可能な認証情報不要のソースは見つかりませんでした（404 / トンネルによるブロック / 空のエンドポイント）。未検証のソースには依存しません
• 中国の大学 / 専攻データベース（認証情報不要）

ライセンス

MIT