MCP Fetch Server:让 AI 把网页抓成可读 Markdown
官方 Fetch Server 的价值不是“会发 HTTP 请求”,而是把网页内容安全抓取、分块截断和 Markdown 转换做成了可复用的 MCP 能力。
官方 Time Server 解决的不是“查现在几点”这么简单,而是把 IANA 时区、系统时区检测和时间换算标准化了。
内容摘要
Time Server 是 MCP 官方 reference servers 里看起来最朴素,但实际上非常有用的一类。它解决的不是“问一句现在几点”,而是更通用的时间能力问题:
Time Server 是 MCP 官方 reference servers 里看起来最朴素,但实际上非常有用的一类。它解决的不是“问一句现在几点”,而是更通用的时间能力问题:
官方 README 的定位很清楚:这是一个提供时间与时区转换能力的 MCP Server。
这类能力为什么值得单独做成 Server?因为时间问题看着简单,实际上是最容易被“拍脑袋字符串处理”写坏的一类问题之一。只要你涉及:
把时间换算交给标准工具,通常比让模型自己口算更稳。
| 要素 | 作用 |
|---|---|
| 当前时间查询 | get_current_time 用来查某个时区或本机时区当前时间 |
| 时区换算 | convert_time 用来在不同时区之间换算 HH:MM 形式时间 |
| IANA 时区名 | 官方 README 明确要求使用如 America/New_York、Europe/London 这种标准时区名 |
| 系统时区检测 | 默认自动检测本机时区,必要时可通过参数或配置覆盖 |
| 结构化输出 | 返回的不只是文本,而是带 timezone、datetime、is_dst 等字段的结构化结果 |
这就是官方 README 一开始就把 IANA timezone names 写进工具参数说明的原因。
官方推荐的最简单方式是:
uvx mcp-server-time
如果你习惯 pip,也可以:
pip install mcp-server-time
python -m mcp_server_time
官方 README 的最小配置是:
{
"mcpServers": {
"time": {
"command": "uvx",
"args": ["mcp-server-time"]
}
}
}
README 给出的 .vscode/mcp.json 形式是:
{
"mcp": {
"servers": {
"time": {
"command": "uvx",
"args": ["mcp-server-time"]
}
}
}
}
官方 README 给出的典型调用参数是:
{
"name": "get_current_time",
"arguments": {
"timezone": "Europe/Warsaw"
}
}
返回结构里会包含:
timezonedatetimeis_dst这比只给一句“现在是下午几点”更适合程序和模型后续继续处理。
另一个常见调用是:
{
"name": "convert_time",
"arguments": {
"source_timezone": "America/New_York",
"time": "16:30",
"target_timezone": "Asia/Tokyo"
}
}
这类结果除了源时区和目标时区的结构化时间,还会给你:
time_difference也就是时差本身。
官方 README 还说明了一个实用配置:如果默认系统时区检测不适合你的运行环境,可以显式传:
{
"command": "python",
"args": [
"-m",
"mcp_server_time",
"--local-timezone=America/New_York"
]
}
这对于容器、远程环境或者系统时区设置不干净的场景很有用。
如果目标都是“让 AI 处理时间”,常见方式有三种:
| 维度 | Time Server | 模型直接口算 | 通用脚本 / Shell 时间命令 |
|---|---|---|---|
| 结构化程度 | 高 | 低 | 中 |
| 跨时区稳定性 | 高 | 一般,容易猜错 | 高,但要自己包成工具 |
| 对夏令时意识 | 更好 | 不稳定 | 取决于实现 |
| 跨客户端复用 | 能 | 不能 | 取决于你自己有没有封装 |
| 上手成本 | 低 | 最低 | 中 |
核心区别:
| 误区 | 准确理解 |
|---|---|
| 以为 Time Server 只是“查现在几点”的玩具 | 不对,它的重点是时区与换算标准化 |
以为随便写个 New York 就总能稳定工作 | 官方参数设计更强调 IANA 时区名,如 America/New_York |
| 以为模型自己算 13 小时时差就够了 | 遇到夏令时、边界时间和本地时区问题时,显式工具更稳 |
| 以为系统时区一定总能检测正确 | 不一定。官方 README 明确支持 --local-timezone 覆盖 |
| 以为它只适合 Claude Desktop | 不是。README 里同样有 VS Code、Zed、Zencoder 等配置方式 |
| 以为时间结果只会返回人类文本 | 不是。它返回带 datetime 和 is_dst 的结构化信息 |
| 优势 | 劣势 |
|---|---|
| 边界清楚:就是做时间和时区,不会掺别的复杂语义 | 能力范围窄:只解决时间问题,不是日历或调度系统 |
| 标准化强:IANA 时区名 + 结构化结果很适合机器处理 | 输入要求稍严:得尽量使用正确的时区标识 |
| 对跨时区协作很实用:远程团队、国际会议都常用 | 场景简单时会显得“有点重”:问一句本地现在几点,不一定总要开工具 |
| 支持本地时区自动检测和显式覆盖:部署弹性好 | 不是完整日程系统:不会帮你解决会议安排、节假日、工作日逻辑 |
| 跨客户端复用好:不是写死在某个聊天产品里的小功能 | 仍要依赖宿主正确配置:尤其容器 / 远程环境时区要注意 |
参考答案:
因为这类问题表面上像小学算术,实际上经常会踩进时区和夏令时的坑。
模型直接回答时,可能只是在“记忆里大概知道时差是多少”,而不是基于当前标准时区规则做精确换算。Time Server 的价值,就是把这种本来容易凭感觉乱算的问题,交给结构化工具。
参考答案:
当你运行环境的“系统时区”不可信时,就应该显式传。
典型场景包括:
这时手动指定会比“希望系统猜对”稳得多。
参考答案:
因为个人场景里,你很多时候只关心自己本地时间,模型口头回答出错的代价也没那么高。
但在团队协作里,一旦跨时区:
这些都需要对齐。Time Server 的价值就在于,它把这些时间转换交给统一工具来做,减少“大家脑补一个时差”的风险。
优先展示同分类且标签更接近的内容,方便继续串联学习。
官方 Fetch Server 的价值不是“会发 HTTP 请求”,而是把网页内容安全抓取、分块截断和 Markdown 转换做成了可复用的 MCP 能力。
官方 Filesystem Server 的核心价值不是“能读文件”,而是把文件访问范围、读写能力和多客户端复用都标准化了。
官方 Git reference server 不是替代 Git 客户端,而是把状态、Diff、日志和分支操作包装成一组可被 AI 调用的标准工具。