服务端开发难度 2⏱ 11 分钟工具
01MCP Fetch Server：让 AI 把网页抓成可读 Markdown
官方 Fetch Server 的价值不是“会发 HTTP 请求”，而是把网页内容安全抓取、分块截断和 Markdown 转换做成了可复用的 MCP 能力。
MCPFetch Server网页抓取MarkdownReference Server
更新于 2026-04-11server-fetch
官方 Filesystem Server 的核心价值不是“能读文件”，而是把文件访问范围、读写能力和多客户端复用都标准化了。
内容摘要
Filesystem Server 是 MCP 官方 reference server 里最常用的一类。它干的事情很直接：**把“读文件、写文件、列目录、搜文件、看元信息”这些本地文件系统操作，包装成一组标准 MCP Tools，交给 Claude Desktop、VS Code、Cursor 这类客户端来调用。**
Filesystem Server 是 MCP 官方 reference server 里最常用的一类。它干的事情很直接：把“读文件、写文件、列目录、搜文件、看元信息”这些本地文件系统操作，包装成一组标准 MCP Tools，交给 Claude Desktop、VS Code、Cursor 这类客户端来调用。
很多人第一次听到它，会下意识觉得“这不就是让 AI 随便访问我电脑吗？” 这恰好是最该先纠正的地方。Filesystem Server 的核心不是“给 AI 文件权限”，而是把文件访问严格收在一组允许目录里。你给它哪几个目录，它就只能在那几个目录里活动，超出边界就不该碰。
官方 README 还特别提醒了一点：modelcontextprotocol/servers 这个仓库里的服务端，定位是 reference implementations，也就是“演示协议能力和 SDK 用法的参考实现”，不是替你做完企业级安全治理的成品。这个定位很重要，因为它决定了你应该把 Filesystem Server 当成：
| 要素 | 作用 |
|---|---|
| 访问边界 | 通过命令行参数或 Roots 指定允许目录，所有操作都只能发生在这些范围内 |
| 工具集合 | 不只是读写文件，还包括搜索、目录树、移动、文件信息、批量读取等能力 |
| 客户端复用 | 一个 Filesystem Server 可以同时被多个兼容 MCP 的客户端使用，不用为每个客户端单独写文件工具 |
| Roots 支持 | 如果客户端支持 Roots，Server 可以在运行中动态更新允许目录，不必重启 |
| 风险控制 | 工具本身分读写，有些写操作带 destructive hint，提醒客户端和用户这类调用有破坏性 |
这里有个很容易忽略的细节：当客户端支持 Roots 且真的提供 roots 时，roots 会替换掉服务端原先的命令行目录列表。 不是叠加，而是替换。
用一句话记：
最快跑起来的方法，就是直接用 npx 启动：
npx -y @modelcontextprotocol/server-filesystem /Users/your-name/Desktop /Users/your-name/Downloads
这条命令的意思是：启动官方 Filesystem Server，并把桌面和下载目录设成允许访问的范围。
这是最经典的入门方式：
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/your-name/Desktop",
"/Users/your-name/Projects"
]
}
}
}
保存后重启客户端，Claude 就能通过这个 Server 调用诸如 read_text_file、list_directory、write_file 这些工具。
如果你想把当前工作区直接暴露给 Copilot Agent，用 .vscode/mcp.json 会更自然：
{
"servers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"${workspaceFolder}"
]
}
}
}
这样做的好处是：权限范围和当前仓库天然对齐，比手动写一长串绝对路径更不容易出错。
你：帮我看看这个项目根目录都有什么，顺便把 README 总结成三句话。
客户端：
1. 调用 list_allowed_directories，确认当前允许范围
2. 调用 list_directory，读取项目根目录
3. 调用 read_text_file，读取 README.md
4. 把内容交给模型总结
edit_file 为什么值得单独记一下很多人只盯着 write_file，其实真正适合代码场景的经常是 edit_file。官方 README 给它的定位不是“整文件重写”，而是按模式做局部替换，还能先 dryRun 预览 diff。
一个最小示例：
{
"path": "/Users/your-name/project/src/app.ts",
"edits": [
{
"oldText": "console.log(\"debug\");",
"newText": "logger.info(\"debug\");"
}
],
"dryRun": true
}
这类调用很适合“只改一小段，不想整文件重写”的场景。官方也明确建议：先 dry run，再正式应用。
如果客户端支持 Roots，最佳体验通常不是在启动命令里写死一堆绝对路径，而是让客户端自己告诉 Server：“当前工作区是哪些目录。”
好处有三个：
roots/list_changed 做运行时更新但别忘了一条坑点：如果你既没有传命令行目录，客户端又不支持 Roots 或返回空 roots，Filesystem Server 会在初始化时报错。
如果你的目标都是“让 AI 能碰文件”，并不只有 Filesystem Server 这一条路：
| 维度 | Filesystem Server | 客户端内建文件工具 | Git Server |
|---|---|---|---|
| 能不能跨客户端复用 | 能，标准 MCP | 不能，跟具体客户端绑定 | 能，但偏 Git 仓库语义 |
| 访问范围控制 | 强，按 allowed directories / roots 限制 | 看客户端实现 | 偏仓库与 Git 操作，不是通用目录访问 |
| 适合场景 | 通用文件读写、目录浏览、搜文件 | 单一客户端内快速做事 | 看提交、分支、diff、仓库语义操作 |
| 上手成本 | 低，npx 即可 | 最低，但不可迁移 | 中，要理解 Git 语义 |
| 风险点 | 允许目录内可写操作仍可能改坏文件 | 权限逻辑不透明，跟客户端绑定 | 不是拿来做任意文件系统管理的 |
核心区别：
| 误区 | 准确理解 |
|---|---|
| 以为 Filesystem Server 一启动就能读整台电脑 | 不是。它只能访问命令行参数或 Roots 指定的允许目录 |
| 以为命令行传入目录和 Roots 会自动合并 | 官方 README 说明，当客户端提供 roots 时，会替换掉当前允许目录 |
| 以为没有传目录也没事，客户端总会补 roots | 不一定。如果既没传目录，客户端又不支持 Roots 或返回空列表，初始化会失败 |
以为 write_file 和 edit_file 没区别 | write_file 更像整文件覆盖；edit_file 更适合局部替换，还支持 dryRun 预览 |
| 以为这是生产级企业文件权限方案 | 它是 reference server，适合学习和日常使用，但企业级权限、审计、隔离还得自己补 |
| 以为它只能处理纯文本 | 官方还提供 read_media_file，可读图片和音频并返回 base64 + MIME type |
| 优势 | 劣势 |
|---|---|
| 最容易理解的官方 Server：几乎所有人都能靠它秒懂 MCP 的价值 | 本地路径依赖强：跨机器、跨系统时路径配置容易出问题 |
| 访问边界明确：allowed directories 和 Roots 让风险比“全盘文件访问”小很多 | 允许目录内仍可能误改文件：尤其 write_file、move_file、edit_file 都有破坏性 |
| 工具集完整：读、写、搜、目录树、元信息、批量读取基本够用 | 不是生产成品：官方自己明确定位为 reference implementation |
| 跨客户端复用：Claude Desktop、VS Code 等都能接同一套能力 | Roots 体验取决于客户端：不是每个 MCP 客户端都把 Roots 做得一样完整 |
| 带 ToolAnnotations：客户端更容易区分只读、幂等、破坏性操作 | 文件系统语义有限：它不懂 Git 语义、代码依赖语义、业务权限语义 |
参考答案：
不够稳。因为 Filesystem Server 的允许目录不一定只来自启动参数，还可能在运行后被 Roots 动态替换。
如果模型只依赖“我记得启动时配了哪个目录”，一旦客户端发来了新的 roots，这个记忆就过时了。list_allowed_directories 的价值就在于：让客户端或模型在做文件操作前，先确认当前真实边界是什么。
这相当于先问一句“我现在到底能进哪些房间”，再决定去开哪扇门，能明显减少越界调用和误判。
参考答案：
因为绝对路径天然和个人机器绑定。你写 /Users/alice/project，到 Bob 的电脑上几乎一定失效。
${workspaceFolder} 的好处是：它让“允许目录”跟当前打开的仓库自动绑定。谁 clone 到自己的电脑、在哪个路径打开，VS Code 都会替换成各自机器上的实际目录。这样团队共享的配置才能真正可移植。
另外，这种写法还有一个隐含收益：权限最小化。它默认只暴露当前仓库，而不是顺手把整个家目录都给出去。
参考答案：
如果你的需求只是“受控目录内的通用读写、搜索、目录浏览、局部编辑”，官方 Filesystem Server 往往已经够用，而且跨客户端复用成本最低。
但当你开始出现这些需求时，就该考虑自己写定制版：
docs/，不能动 src/”本质上，官方 Filesystem Server 提供的是“文件系统能力的标准骨架”，不是每家公司都能直接拿来做最终生产方案。
优先展示同分类且标签更接近的内容，方便继续串联学习。
官方 Fetch Server 的价值不是“会发 HTTP 请求”，而是把网页内容安全抓取、分块截断和 Markdown 转换做成了可复用的 MCP 能力。
官方 Git reference server 不是替代 Git 客户端，而是把状态、Diff、日志和分支操作包装成一组可被 AI 调用的标准工具。
官方 Memory Server 不是“无限记忆插件”，而是一个把实体、关系、观察值持久化到本地知识图谱的 reference server。