Click on "Install 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., "@mcp-chinese-time parse 明天"
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.
A Model Context Protocol (MCP) server for parsing Chinese fuzzy time expressions to standard datetime formats.
Relative Time: 昨天, 今天, 明天, 三天前, 两周后
Time Ranges: 昨天到今天, 上周一到周五
Time of Day: 上午9点, 下午3点30分, 晚上8点
Holidays: Both solar (国庆节, 劳动节) and lunar (春节, 中秋节, 端午节)
Specific Dates: 2024年1月1日, 1月15号
Weekdays: 周一, 上周三, 下周五
Chinese Numbers: Supports both Arabic (3) and Chinese (三) numerals
Related MCP server: time-mcp
pip install mcp-chinese-timeuvx mcp-chinese-timeAdd to your claude_desktop_config.json:
{
"mcpServers": {
"chinese-time": {
"command": "uvx",
"args": ["mcp-chinese-time"]
}
}
}Add to your VS Code settings or .vscode/settings.json:
{
"mcp": {
"servers": {
"chinese-time": {
"command": "uvx",
"args": ["mcp-chinese-time"]
}
}
}
}{
"mcpServers": {
"chinese-time": {
"command": "mcp-chinese-time"
}
}
}from mcp_chinese_time import FuzzyTimeParser
parser = FuzzyTimeParser(timezone="Asia/Shanghai")
# Parse relative time
result = parser.parse("昨天")
print(result.value) # "2024-01-14"
# Parse time range
result = parser.parse("上周一到周五")
print(result.value) # ["2024-01-08", "2024-01-12"]
print(result.is_range) # True
# Parse holiday
result = parser.parse("国庆节期间")
print(result.value) # ["2024-10-01", "2024-10-07"]
# Parse time of day
result = parser.parse("下午3点30分")
print(result.value) # "2024-01-15 15:30:00"
print(result.is_date_only) # False
# Parse lunar holiday (requires zhdate)
result = parser.parse("中秋节")
print(result.value) # "2024-09-17"# Using the installed command
mcp-chinese-time
# Or using Python module
python -m mcp_chinese_timeparse_timeParse fuzzy Chinese time expressions to standard datetime format.
Parameters:
Parameter | Type | Required | Default | Description |
| string | Yes | - | Fuzzy time expression in Chinese |
| string | No | "Asia/Shanghai" | Timezone for parsing |
Returns:
{
"success": true,
"parsed": {
"value": "2024-01-15",
"is_range": false,
"is_date_only": true,
"original_expression": "今天",
"confidence": 1.0
},
"error": null
}For time ranges:
{
"success": true,
"parsed": {
"value": ["2024-10-01", "2024-10-07"],
"is_range": true,
"is_date_only": true,
"original_expression": "国庆节期间",
"confidence": 0.95
},
"error": null
}Expression | Description |
今天, 今日 | Today |
昨天, 昨日 | Yesterday |
前天, 前日 | Day before yesterday |
大前天 | 3 days ago |
明天, 明日 | Tomorrow |
后天, 后日 | Day after tomorrow |
大后天 | 3 days from now |
N天前 | N days ago |
N天后 | N days from now |
Expression | Description |
本周, 这周 | This week |
上周, 上一周 | Last week |
上上周 | 2 weeks ago |
下周, 下一周 | Next week |
下下周 | 2 weeks from now |
N周前 | N weeks ago |
N周后 | N weeks from now |
Expression | Description |
本月, 这个月 | This month |
上个月, 上月 | Last month |
下个月, 下月 | Next month |
N个月前 | N months ago |
N个月后 | N months from now |
Expression | Description |
周一 ~ 周日 | Weekday (this week) |
星期一 ~ 星期日 | Weekday (this week) |
上周X | Last week's weekday |
下周X | Next week's weekday |
Expression | Description |
上午X点 | X AM |
下午X点 | X PM |
晚上X点 | X PM (evening) |
X点Y分 | X:Y |
Expression | Date |
元旦 | Jan 1 |
情人节 | Feb 14 |
劳动节, 五一 | May 1-5 |
儿童节 | Jun 1 |
国庆, 国庆节 | Oct 1-7 |
圣诞, 圣诞节 | Dec 25 |
清明, 清明节 | Apr 4-5 |
Expression | Lunar Date |
春节, 过年 | 1st month, 1st day |
除夕, 年三十 | 12th month, 30th day |
元宵, 元宵节 | 1st month, 15th day |
端午, 端午节 | 5th month, 5th day |
七夕, 七夕节 | 7th month, 7th day |
中秋, 中秋节 | 8th month, 15th day |
重阳, 重阳节 | 9th month, 9th day |
# Clone the repository
git clone https://github.com/wyl116/mcp-chinese-time.git
cd mcp-chinese-time
# Install development dependencies
pip install -e ".[dev]"pytest tests/ -vruff check src/ tests/
ruff format src/ tests/MIT License - see LICENSE for details.
Contributions are welcome! Please feel free to submit a Pull Request.
Fork the repository
Create your feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add some amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
解析模糊时间表达式为标准日期时间格式。
Parse fuzzy Chinese time expressions to standard datetime format.
Supported expressions:
Relative time: 昨天, 今天, 明天, 三天前, 两周后
Time ranges: 昨天到今天, 上周一到周五
Time of day: 上午9点, 下午3点30分
Holidays: 国庆节期间, 春节, 中秋节 (including lunar calendar)
Specific dates: 2024年1月1日, 1月15号
| Name | Required | Description | Default |
|---|---|---|---|
| timezone | No | Timezone for parsing (default: Asia/Shanghai) Supports standard timezone names like "UTC", "America/New_York" | Asia/Shanghai |
| expression | Yes | Fuzzy time expression in Chinese (e.g., "昨天", "三周前", "国庆节期间", "上午9点") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It details supported expression types and notes holiday support including the lunar calendar, which is valuable behavioral context. However, it does not describe behavior for invalid or ambiguous expressions, nor clarify the exact output format or whether ranges return multiple values. The output schema exists but the description alone leaves these aspects unclear.
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 bilingual, doubling its length, but the content is well-organized with a clear list of supported expression types. Every sentence provides useful information, and the structure enhances readability. The duplication is a minor inefficiency but not excessive.
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?
Given the availability of an output schema and 100% schema coverage, the description is largely complete. It covers the main input categories and adds relevant details like lunar calendar support. It does not address edge cases or default timezone behavior in the description, but these are partly covered by schema defaults and the output schema, resulting in a minor gap.
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 100% with descriptions for both `expression` and `timezone`. The description adds value by enumerating supported expression patterns and providing concrete examples (e.g., '昨天', '国庆节期间'), which goes beyond the schema's brief examples. This enriches the understanding of the `expression` parameter.
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's purpose: parsing fuzzy Chinese time expressions into a standard datetime format. It lists specific supported expression categories (relative time, time ranges, time of day, holidays, specific dates), making the functionality explicit. Although there are no sibling tools to distinguish from, the verb+resource combination is precise and unambiguous.
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 provides concrete examples of supported expressions and expression categories, which strongly implies when to use the tool. However, it does not explicitly state when not to use it or mention any alternatives, though no siblings exist. The examples serve as effective usage guidance for a parser.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With only one tool, there is zero ambiguity between tools. The single tool has a clear, well-defined purpose of parsing fuzzy Chinese time expressions.
The tool name 'parse_time' follows a clear verb_noun pattern, which is consistent as the only tool. There are no naming conflicts or mixed conventions.
The server is narrowly scoped to Chinese time parsing, and one tool fully covers this focused domain. The count is exactly appropriate for the stated purpose, not thin or excessive.
The tool supports a comprehensive range of Chinese time expressions: relative times, ranges, times of day, holidays, and specific dates. It fully covers the domain of interpreting fuzzy Chinese time references.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server providing attendance data queries via the CloudTime API.
MCP server for Speech-to-Text
MCP server for progressive tool usage at any scale (see https://klavis.ai)
MCP server for AI dialogue using various LLM models via AceDataCloud
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wyl116/mcp-chinese-time'
If you have feedback or need assistance with the MCP directory API, please join our Discord server