China Servers

MCP servers for Chinese services that didn't have one.

While compiling awesome-china-mcp we found 88 widely-used Chinese services with a documented official API and no maintained MCP server anywhere. This repo starts working through that list. Round one picks the three where you can get a credential yourself in five minutes — or need none at all.

Server	What your agent can do	Credential
holiday	Is this date a day off in mainland China? Statutory holiday, 调休 makeup workday, weekend or ordinary workday — plus a whole year at once	none
serverchan	Push a notification to your own WeChat (Server酱)	free, self-serve
baidu-translate	Translate text between 20+ languages (Baidu Translate 标准版)	free tier, self-serve

Try it in ten seconds

The holiday server needs no signup, no key, nothing:

npx -y github:zackchewa/china-mcp-servers holiday

Then point any MCP client at it:

{
  "mcpServers": {
    "china-holiday": {
      "command": "npx",
      "args": ["-y", "github:zackchewa/china-mcp-servers", "holiday"]
    }
  }
}

Ask your agent "is 2026-10-01 a working day in China?" and it will answer 国庆节, day off. Ask about a 调休 Sunday and it will correctly tell you that you're working.

Works with Claude Desktop, Cursor, Cline, VS Code, OpenClaw, Hermes, Cherry Studio, or anything else that speaks MCP over stdio.

Not on npm yet, so these run straight from the repo; npm publish will shorten the command to npx -y china-mcp-servers <server>.

The servers

holiday — 中国法定节假日 / 调休

Two tools: holiday_check_date (defaults to today in China time) and holiday_list_year.

Anything that schedules work in China needs this, because a weekend check is not enough — the 调休 system makes some Saturdays and Sundays mandatory working days to pay for a long holiday. A naive calendar gets those exactly backwards.

Data comes from NateScarlet/holiday-cn, a maintained JSON mirror of the State Council's published 放假安排, cached 12 hours in memory.

Why not timor.tech, the API most tutorials use: it sits behind a Cloudflare challenge that blocks non-CN server egress. The two GitHub CDNs used here answer from anywhere, and the second is tried if the first fails.

serverchan — push to your own WeChat

One tool: serverchan_send (title required, desp is Markdown).

This gives an agent a way to reach you rather than waiting to be asked — cron results, alerts, "the deploy finished". Messages go to your own WeChat only.

Get a SendKey free at sct.ftqq.com — scan-login with WeChat, copy the key:

{
  "mcpServers": {
    "serverchan": {
      "command": "npx",
      "args": ["-y", "github:zackchewa/china-mcp-servers", "serverchan"],
      "env": { "SERVERCHAN_SENDKEY": "SCT..." }
    }
  }
}

Both live key formats are handled automatically, which is the part that usually breaks: Turbo keys (SCT…) post to sctapi.ftqq.com, while Server³ keys (sctp<uid>t…) post to <uid>.push.ft07.com, where the uid is the digit run inside your own key. Send the second kind to the first host and you get a confusing 404.

baidu-translate — 百度翻译

One tool: baidu_translate (from defaults to auto-detect, to defaults to Chinese).

The 标准版 tier is genuinely free (50k characters/month) and has a 暂不认证 path, so you can get working credentials at fanyi-api.baidu.com without ID verification.

{
  "mcpServers": {
    "baidu-translate": {
      "command": "npx",
      "args": ["-y", "github:zackchewa/china-mcp-servers", "baidu-translate"],
      "env": {
        "BAIDU_TRANSLATE_APPID": "your-appid",
        "BAIDU_TRANSLATE_SECRET": "your-secret"
      }
    }
  }
}

Two traps are handled for you. The signature is MD5(appid + q + salt + secret) over the raw UTF-8 text — sign the URL-encoded form instead and you get error 54001, which is the single most common complaint about this API. And the per-call limit is 6000 bytes, not characters, so Chinese input hits it at roughly 2000 characters; this bounds on bytes and tells you to split.

What is actually verified

Being specific, because "works" is easy to claim:

• holiday is verified end to end over real MCP stdio against the live dataset — handshake, tools/list, and tools/call returning 国庆节 for 2026-10-01.
• All three servers are verified over real MCP stdio for handshake and tool listing, and the credentialed two return a clear, actionable error when their environment variable is absent rather than hanging or crashing.
• Request construction and error mapping are covered by 21 unit tests over mocked HTTP, including the signature-over-raw-text rule, the byte-length bound, both SendKey host formats, SendKey redaction from errors, the CDN fallback, and the refusal to cache a wrong-year holiday payload.
• The logic in all three is ported from adapters that run in production at OpenClaw Launch, so the API contracts are proven in real use. What has not happened is a live upstream call from this package for the two credentialed servers — that needs your own keys, and this repo ships without any.

Contributing

The 88-row gap list in awesome-china-mcp is the roadmap. If you want to add a server, the ones worth doing first are the ones whose credentials an ordinary developer can actually obtain — an enterprise-only API makes a server almost nobody can run.

House rules, all learned the hard way:

• Fix the host. No user-supplied base URLs, and refuse redirects.
• Bound every input, and bound text on bytes when the upstream limit is in bytes.
• Redact credentials from every error path, especially when the credential rides in a URL.
• Treat a business-level failure as a failure even when HTTP says 200. Chinese APIs very often return {"code": 40001} with a 200.
• Say what a tool cannot do. A read-only server that claims to write wastes everyone's time.

Related

• awesome-china-mcp — the index these came out of: MCP servers for Chinese apps, official first, plus the gap list.
• If you'd rather not self-host, OpenClaw Launch runs a hosted version of these and about a hundred more Chinese app connections.

License

MIT