零代码接入MCP，让助手操作本地文件

让 AI 助手操作本地文件，不必从写一个 MCP 服务开始。作者给出的路线更直接：接入现成的 Filesystem server，只开放一个测试目录，验证读取和写入，再学会断开连接。全程不用编写业务代码，只需修改一份 JSON 配置。

这篇教程最有用的部分，是把「接上了」拆成可以亲眼检查的步骤。不过，「不用写代码」不等于没有安装、权限和文件修改风险。理解配置里每个字段，比复制成功更重要。

不写服务，AI 为什么就能操作文件

MCP（Model Context Protocol，模型上下文协议）是一套让 AI 应用连接外部工具和数据的开放标准。原文引用的「AI 应用的 USB-C 接口」比喻，强调的是统一连接方式：应用和工具遵循同一协议，就不必为每种组合单独开发集成。

在这个例子里，Claude Desktop 是使用工具的客户端，Filesystem server 负责执行文件操作，Node.js 提供服务运行环境。用户配置好启动命令和允许访问的目录后，Claude Desktop 启动服务，再通过它读取、创建、移动和搜索文件。

不用自己开发服务，不代表本地没有程序在运行。

准备工作包括安装 Claude Desktop 和 Node.js。已有 Claude Desktop 的用户，作者建议先通过 Claude 菜单里的 Check for Updates... 检查更新。在终端执行 node --version，能看到版本号即可继续；如果提示找不到命令，则安装 Node.js LTS。原文没有规定具体版本号。

作者把后续操作说明为依据文档整理的接入流程，没有给出自己的测试环境、成功率或跨平台验证记录。因此，它适合当作操作指南，不能当作所有系统上的兼容性证明。

配置里最重要的，是允许它访问哪个目录

作者没有照搬开放 Desktop 和 Downloads 的示例，而是建议先建一个空的 mcp-test 文件夹，放入两三个可丢弃的文件，只允许服务访问这里。

这个取舍很实用。配置成功后的目标是确认连接有效，没必要一开始就把工作资料全部交进去。

入口是系统菜单中的 Claude → Settings... → Developer → Edit Config，不是聊天窗口内部的设置。对应配置文件位置为：

• macOS：~/Library/Application Support/Claude/claude_desktop_config.json
• Windows：%APPDATA%\Claude\claude_desktop_config.json
• Linux：~/.config/Claude/claude_desktop_config.json

下面这段配置解决服务如何启动、能访问哪里的问题，使用时要把 username 换成自己的账户名：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/username/Desktop/mcp-test"
      ]
    }
  }
}

最该检查的是最后一行目录路径。包名后面的每个路径，都是新增的可访问目录，不是随便填写的启动备注。

filesystem 是显示名称；command 指定用 npx 启动；-y 自动确认安装包；@modelcontextprotocol/server-filesystem 是服务包名。原文没有固定包版本，这也是复现配置时需要知道的限制。

Windows 路径在 JSON 中要写成 "C:\\Users\\username\\Desktop\\mcp-test"。如果已经配置其他服务，就在 mcpServers 里新增 filesystem 条目，保留现有内容，并检查条目间的逗号。

权限也不能只看「有没有弹窗」。原文提醒，服务以当前用户账户的权限运行，在获准目录内可以执行用户能够手动执行的文件操作。目录边界和操作确认，承担的是不同作用。

看见工具列表，还不算验证完成

保存配置后，需要完全退出 Claude Desktop，再重新打开。只关闭窗口，可能不会触发配置重载和服务启动。

接着新建聊天，点击输入框左下角的 Add files, connectors, and more /，进入 Connectors → Manage connectors → filesystem。能看到工具列表，说明客户端已经识别服务；还要再做一次实际读写。

作者安排的验证很简单：先让 Claude 列出 mcp-test 中的文件并说明内容，再要求创建 notes.txt，写入三行摘要。按原文引用的文档说明，Claude 应在文件操作前请求批准。阅读操作内容后再确认，最后自己打开目录检查文件和正文。

工具出现在界面里，只证明发现了服务；文件结果符合预期，才证明流程跑通了。

移动、重命名同样会改变真实文件，第一次应使用副本。若服务没有出现，原文建议依次检查：是否完全重启、JSON 是否有效、目录是否为绝对路径，再查看日志。允许目录应写成 /Users/username/Desktop/mcp-test，不能照写 Desktop/mcp-test 或 ~/Desktop/mcp-test。

日志目录分别是 macOS 的 ~/Library/Logs/Claude、Windows 的 %APPDATA%\Claude\logs 和 Linux 的 ~/.config/Claude/logs。其中 mcp.log 用于查看整体连接情况，mcp-server-filesystem.log 用于查看该服务的输出。

仍找不到原因时，下面的命令可以直接暴露启动错误：

npx -y @modelcontextprotocol/server-filesystem /Users/username/Desktop/mcp-test

这里重点核对服务包后面的路径；Node 环境或路径出错，通常能在直接运行时看到提示。

撤销也属于接入步骤：重新打开配置，删除 filesystem 条目，保存并完全重启。删除配置不会撤销之前已经发生的文件修改。

我的判断

我认可作者把范围收窄、人工核验和撤销入口放进教程。对于只想让助手处理一组本地文件的人，使用现成服务确实省去了自行实现协议和文件工具的工作。

但这是一份入门操作指南，没有性能、准确率或效率对照数据。「先理解一个服务，再增加更多服务」是合理的经验建议，不是经过对照实验得出的结论。原文提到接入前的五问检查，也没有在正文完整列出五个问题，不能把它当成已经展开的审查方案。

与临时上传文件相比，Filesystem server 提供了持续访问目录和修改文件的入口。如果只是偶尔让 AI 看一份文档，是否值得增加本地服务，要看实际需求；原文没有证明接 MCP 总是更划算。

Cursor 沿用相同形状的 mcpServers 配置块，项目配置放在 .cursor/mcp.json，全局配置放在 ~/.cursor/mcp.json。原文还提到 Customize 页面的一键安装，以及默认使用工具前请求批准、通过工具名旁箭头查看参数。项目级还是全局级，应按工具使用范围选择。

远程 connector 则免去了本地安装服务的步骤：在 Claude 的 Settings → Connectors → Add → Add custom connector 中填写服务 URL，再按提示登录，通常使用 OAuth。它仍然需要审视权限；按原文描述，可以在 connector 设置中关闭具体工具，只读任务就关闭写入和删除工具。

能拿来做什么

• 首次接入时建立独立的 mcp-test 目录，用两三个可丢弃文件完成「列出内容、生成三行摘要、人工打开检查」的完整验证。
• 在 Cursor 中给单个项目接工具时，优先评估 .cursor/mcp.json 是否足够，确实需要跨项目使用时再配置 ~/.cursor/mcp.json。
• 排查连接失败时，按重启、JSON、绝对路径、日志、手动启动的顺序定位，避免同时修改多处配置。
• 每增加一个服务，都记录发布者、启动命令、可访问目录和移除方法；远程 connector 同时检查具体工具开关，并移除已经不用的连接。