Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@china-context-mcp Give me a random classical Chinese poem."
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.
把中文世界的数据源桥接成 AI 工具。零凭证、免交付、可验证。
给 AI 提供工具/服务/资源，是未来需求的重要方向。但调研发现一个结构性缺口：
国际服务（GitHub / Slack / Notion…）的 MCP server 覆盖中位数约 1554 个仓库；
中国服务（微信 / 支付宝 / 飞书 / 抖音…）的 MCP 覆盖中位数仅 88 个——差 17.7×。
（数据：GitHub Search 「<服务> mcp」 in:name,description，2026-09-25）
缺口只在「广义中国服务→AI」这一层成立。本仓库是这条「桥接层」方向的最小可验证载体： 先把零凭证、公开 API、对中文 AI 真有用、且没被官方垄断的数据源接进来。
⚠️ 支付宝「支付 MCP」已被官方于 2025-04-15 发布，故本项目不重复造支付类 MCP，只接官方未覆盖的真空数据源。
Related MCP server: 命盘 Mingpan
工具 | 数据源 | 用途 |
| jinrishici.com | 随机一句中国古典诗词（作者/出处/分类），用于中文创作、文化问答、国学陪练 |
| timor.tech | 查询中国某日期是否为法定节假日、调休补班工作日、工资倍率 |
| timor.tech | 年度聚合摘要：连续假期区间与天数、法定 3 倍工资天数、调休补班清单、全年总休假天数。省略 year 用当年 |
| 60s-api.viki.moe | 历史上的今天：某月某日的历史事件列表（标题/年份/简述）；省略 date 用今天 |
holiday_summary 为什么是差异化的一层timor 的两个接口都只给扁平数据：holiday_info 一次一天，holiday/year 一次给全年条目。但它们给不出下面这些结论——而这些恰恰是最容易算错的：
2026 年中国节假日与调休摘要
【假期区间】共 7 个，合计 33 天（不含补班）
· 元旦 01-01 ~ 01-03 3天（3倍工资 1 天）
· 春节 02-15 ~ 02-23 9天（3倍工资 4 天）
· 清明节 04-04 ~ 04-06 3天（3倍工资 1 天）
· 劳动节 05-01 ~ 05-05 5天（3倍工资 2 天）
· 端午节 06-19 ~ 06-21 3天（3倍工资 1 天）
· 中秋节 09-25 ~ 09-27 3天（3倍工资 1 天）
· 国庆节 10-01 ~ 10-07 7天（3倍工资 3 天）
【调休补班】共 6 天
· 01-04 元旦后补班（调休上班，非假日）
· 02-14 春节前补班（调休上班，非假日）
· 02-28 春节后补班（调休上班，非假日）
· 05-09 劳动节后补班（调休上班，非假日）
· 09-20 中秋节前补班（调休上班，非假日）
· 10-10 国庆节后补班（调休上班，非假日）
【工资倍率】3倍 13 天 / 2倍 20 天一处必须记住的坑：合并假期区间要按日期连续性，不能按名称。中国法定假常把「春节」拆成 除夕/初一/初二…（且假日条目的 target 字段恒为 -，无法用于分组），按同名合并会把春节拆成 9 个单日区间，与「春节放 9 天」的用户心智严重不符。
cd prod/china-mcp
pip install -e .依赖：mcp、fastmcp（Python ≥ 3.10）。
在 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 客户端连接历史上的今天（零凭证，已接 60s-api.viki.moe）
空气质量 / 天气（中国，公开源多需 key，待找零凭证源）
成语词典（零凭证）⏸ 暂缓：已实测 muxiaoguo/oick/oioweb/aa1/codelife/xxapi/qqsuu 等候选，均无可达的零凭证源（404 / 隧道拦截 / 空端点），不建立在未验证源上
中国大学 / 专业库（零凭证）
MIT
返回「历史上的今天」：某月某日发生的历史事件列表（标题 + 年份 + 简述）。
参数 date：可选，格式 "MM-DD"（如 "09-25"）或 "YYYY-MM-DD"（如 "2026-09-25"）。 省略则使用今天。 适用：历史问答、内容创作、文化类 AI 陪练。 数据来自 60s-api.viki.moe（公开、零凭证）。
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
描述提及数据来源（60s-api.viki.moe）且公开、零凭证，这增加了透明度；但未详细说明错误处理、速率限制或返回结构细节（有输出 schema）。未发现与注释矛盾（无注释）。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
描述分段清晰：功能、参数、适用场景、数据来源。每句都有价值，无赘余，主用途前置。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具简单且存在输出 schema，描述涵盖输入、默认、适用性和数据源，对于调用已足够。虽未涉及无效日期行为，但重要性较低，考虑整体完整性评为 4。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
schema 描述覆盖率为 0%，但描述完全补偿：清晰说明了 date 参数的格式（MM-DD 或 YYYY-MM-DD）和默认行为（省略则用今天）。远超 schema 本身的信息。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
描述清楚说明了资源（历史事件）、输出（标题、年份、简述）以及功能（列出某日的历史事件）。它明确区别于兄弟工具（random_poem、holiday_info、holiday_summary）。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述给出使用场景（历史问答、内容创作、文化类 AI 陪练），但未明确说明何时不使用或引用替代工具。提供了上下文，但没有排除规则。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询中国某日期的节假日 / 调休 / 是否工作日信息。
参数 date：YYYY-MM-DD，例如 "2026-10-01"。 返回：节假日名称、是否法定假日、是否调休补班工作日、工资倍率。 数据来自 timor.tech（公开、零凭证）。
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the data source (timor.tech), states it is public and requires zero credentials, implying read-only behavior. However, it does not mention error handling, rate limits, or behavior for invalid dates, which are gaps for a data-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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero fluff: the first states the purpose, the second covers the parameter, return fields, and data source. Each element earns its place, and it is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple one-parameter interface, the description covers the core aspects: what it does, how to format the parameter, what it returns, and the data source. Given the presence of an output schema (not shown), the description is adequately complete, though it could mention edge-case behavior for invalid dates or missing data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a string type with no description (0% coverage). The description compensates by specifying the format YYYY-MM-DD and giving an explicit example ('2026-10-01'), which is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries holiday, adjustment, and workday information for a specific Chinese date, and lists the return fields (holiday name, statutory status, adjustment workday, salary multiplier). This is a specific verb-resource combination that distinguishes it from random_poem and history_today, though not explicitly from holiday_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling holiday_summary, nor any exclusions or alternative selection criteria. The description gives no contextual usage hints beyond stating what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
返回中国某年的节假日与调休摘要——聚合推导，不是单日查询。
与 holiday_info 的区别：本工具对 timor 全年扁平数据做聚合，给出 holiday_info 拿不到、而 AI 自身容易算错的结论——连续假期区间与天数、 法定 3 倍工资天数、全部调休补班日、全年总休假天数。
参数 year：4 位年份，省略则用当前年。 适用：年度休假规划、考勤与排班、HR 与薪酬核算。 数据来自 timor.tech（公开、零凭证）。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the data source (timor.tech, public, zero credentials), the fact that it is a read-only aggregation (no mutation implied), and the specific derived outputs (continuous holiday intervals, statutory 3x pay days, adjusted workdays, total annual leave days). It doesn't state response format details, but an output schema exists to cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written with zero filler. The core purpose is front-loaded in the first line, followed by sibling differentiation, then the derived outputs, then parameter and applicability notes. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter), an output schema exists to explain return values, and the description covers purpose, differentiation, aggregation results, parameter semantics, and data source. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the only parameter (year) has no description in the schema, but the description compensates: it states the parameter is a 4-digit year and that omitting it defaults to the current year. This adds real meaning beyond the bare integer type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb+resource+scope: aggregates Chinese holidays and adjusted workdays for a year. The first line explicitly contrasts with single-day queries and names the sibling (holiday_info) it complements, so an agent can distinguish them immediately without inspecting either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the sibling tool holiday_info as the alternative and states the key difference (aggregation of flat yearly data vs single-day lookup). Also enumerates concrete use cases (annual leave planning, attendance/scheduling, HR and payroll), giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
随机返回一句中国古典诗词，含作者、出处与分类。
适用：中文创作灵感、文化问答、语文/国学类 AI 陪练。 数据来自 jinrishici.com（公开、零凭证）。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states the data source (jinrishici.com) and that it is public with zero credentials, which is valuable context about access and side effects. It also discloses the random-selection behavior. It does not mention potential network dependency or failure modes, but for a zero-parameter fetch tool this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: the core function, the intended use cases, and the data source/credential note. The primary purpose is front-loaded, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter, read-only tool with an output schema, the description is complete. It covers what the tool does, what the output contains, when to use it, and the external source/auth model. Nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantic burden for the description to satisfy. The schema covers the parameter space completely, and the description still adds relevant output context (author, source, category). This meets the baseline for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pairing (随机返回一句中国古典诗词) and explicitly states what the result includes: author, source, and category. The tool is clearly distinguishable from holiday/history siblings because it names a distinct domain (Chinese classical poetry) and behavior (random selection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit applicable scenarios (中文创作灵感、文化问答、语文/国学类 AI 陪练), which tells an agent when this tool is relevant. It does not name exclusions or compare against alternatives, but the sibling set is topically distinct enough that no further routing guidance is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0history_todayholiday_infoholiday_summaryrandom_poemScored across 4 tools
random_poem and history_today are clearly distinct, but holiday_info and holiday_summary overlap in domain and could confuse an agent at first glance. The descriptions explicitly differentiate them (single-day vs annual aggregation), which mitigates the ambiguity.
All tool names use lowercase snake_case and a two-word noun-phrase structure, which is readable and predictable. history_today deviates slightly from the noun-phrase pattern of the others, but the overall naming convention is consistent enough.
Four tools is a reasonable count for a niche context server, and each tool covers a distinct aspect of Chinese cultural context. The scope feels slightly thin for a server named 'china-context', but not inadequately so.
The holiday coverage is quite complete (single-day info plus annual summaries), and history_today provides basic historical events. However, the broader 'China context' domain has obvious gaps such as lunar calendar conversion, festivals, idioms, or solar terms, making the surface feel partial.
China holidays and lunar calendar lookup, solar-to-lunar conversion and yearly schedule.
China A-share market data over MCP: 22 tools for quotes, K-line, financials, money flow, top-trader boards, sectors, macro, convertible bonds and factor screening. Five tools need no API key, so you can connect and try it immediately.
Chinese almanac: lunar calendar, BaZi 八字, daily 宜忌, lucky-day picker, public holidays.
China facts a server outside China cannot get: real mainland reachability, 调休 holidays, ID/phone val
