Cline MCP 配置与实际使用：从文件目录到一次工具调用

MCP 可以让 Cline 使用模型之外的工具，例如读取限定目录、查询数据库或访问某个服务。模型配置解决“由谁思考”，MCP 配置解决“可以调用什么工具”，两者需要分别验证。

下面先用官方 filesystem 示例服务做一轮小实验：连接成功、列出目录、读取文件，再确认目录之外的访问会被拒绝。

如果 Cline 还没有正常回复，先完成 Cline 安装与模型配置，再继续。

先理解三个角色

角色	在这个例子里负责什么
Cline	连接服务，展示工具请求，让你决定是否批准
MCP Server	提供列目录、读取文件等具体工具
模型	根据任务决定是否请求工具，并使用工具返回的数据

安装一个 MCP Server，不会给模型增加知识库，也不会自动让它读取所有文件。服务器必须启动、连接正常、公开相应工具，并在任务中被实际调用。协议和连接方式的完整说明见 Cline MCP 文档。

准备一个单独的演示目录

先确认 Node.js 和 npx 能在扩展运行的环境中执行。使用目前仍受支持的 Node.js LTS，并检查服务包自身的版本要求。

bash

node --version
npx --version
mkdir -p "$HOME/cline-mcp-demo"
printf 'MCP demo: read this file only.\n' > "$HOME/cline-mcp-demo/hello.txt"
cd "$HOME/cline-mcp-demo"
pwd

记下最后打印的绝对路径。macOS 可能是 /Users/yourname/cline-mcp-demo，Linux 可能是 /home/yourname/cline-mcp-demo。Windows JSON 路径可写成 C:/Users/yourname/cline-mcp-demo，或正确转义反斜杠。

不要直接授权整个用户目录。这个例子使用的 filesystem 参考服务也提供写文件等工具，它并不是只读沙箱；目录范围与人工审批都需要保留。

在 Cline 中添加本地服务

打开 Cline 的 MCP Servers 面板，进入 Configure，再打开 Configure MCP Servers。入口名称可能随版本略有变化，优先使用扩展提供的配置入口，避免编辑到另一份 CLI 配置。

将下面的 demo-files 项合并到现有 mcpServers 对象中。已有服务器时不要覆盖整个文件。

json

{
  "mcpServers": {
    "demo-files": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/[email protected]",
        "/Users/yourname/cline-mcp-demo"
      ],
      "disabled": false,
      "autoApprove": []
    }
  }
}

把最后一个参数改成刚才的真实路径。这里不使用 ~，因为参数会直接交给程序，不能假设它经过 shell 展开。JSON 也不能包含注释或尾随逗号。

npx -y 会自动确认下载执行 npm 包；首次使用前应确认包名与来源。这里固定到本次核对的 2026.8.31，避免下次安装时悄悄换版本。升级前先查看包的变更与运行时要求，再更新配置。

保存后等待服务连接。autoApprove: [] 表示没有在这份配置里列出自动批准工具；仍要检查 Cline 的其他审批设置。不要为了消除提示就打开全部自动批准。

做三次调用，确认它真的工作

第一轮先要求列出授权范围：

代码

使用 demo-files MCP 服务的 list_allowed_directories 工具，
告诉我当前允许访问的目录。不要使用终端命令代替。

第二轮读取刚创建的文件：

代码

使用 demo-files 的 list_directory 查看演示目录，
再用 read_text_file 读取其中的 hello.txt。
在执行前展示工具名与参数，不要修改文件。

工具请求中的路径应落在演示目录内，返回内容应包含 MCP demo: read this file only.。要看工具调用记录，不能仅凭模型回答“我已读取”就判断成功。

第三轮验证拒绝行为。先在演示目录之外另建一个不含敏感信息的测试文件，再请求读取它。预期结果是路径不在允许范围内，服务拒绝访问。如果请求成功，先检查授权目录和当前客户端提供的 roots，不要继续放入真实资料。

这个实验验证的是目录访问配置，不是恶意代码隔离。运行在本机的第三方服务本身仍然是程序；只使用可信来源，并给它实际需要的环境权限。

远程 MCP 应该怎么填

本地服务通常由 Cline 启动进程，通过标准输入输出通信。远程服务则使用 URL，还可能要求认证。对于明确支持 Streamable HTTP 的服务，配置形状如下：

json

{
  "mcpServers": {
    "remote-demo": {
      "type": "streamableHttp",
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer REPLACE_WITH_YOUR_TOKEN"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

这是结构示例，域名与令牌必须替换为服务商提供的值。旧服务如果只支持 SSE，要按其文档配置，不能仅把 type 改名就完成协议升级。认证使用 OAuth 的服务，也应走其支持的授权流程，而非套用静态 Bearer 示例。

令牌属于密钥。不要把带真实令牌的配置截图、提交到 Git 或粘贴到公共问题区。

连接失败时，按发生位置排查

左右滑动查看完整表格

现象	优先检查	下一步
`spawn npx ENOENT`	扩展所在环境找不到 npx	用该环境的终端确认安装与 PATH，必要时配置可执行文件绝对路径
安装包阶段超时	npm 网络、代理、包名	在同一环境安装并核对包，避免把下载失败当协议故障
服务启动后立即断开	参数、Node 版本、日志	查 MCP 面板错误；协议输出不能被普通 stdout 日志污染
工具返回路径不允许	服务参数与实际文件路径	核对绝对路径和允许目录，不要直接扩大到整个磁盘
远程服务返回 401 / 403	认证与服务权限	检查令牌有效期、授权范围和账号权限
服务已连接却没被调用	任务、可用工具、模型能力	明确工具名发起小任务，再查看调用记录

Remote SSH 和容器尤其容易配错：文件路径、Node.js、MCP 进程必须在扩展实际运行的环境里成立。本机有这个文件，不代表远程主机也有。

本次用 2026.8.31 版服务做了独立的 MCP stdio 检查：列目录、读取演示文件均成功，读取目录外测试文件被拒绝。这验证了示例服务及参数；没有代替你在 Cline 内使用实际模型完成审批和调用。

接入真实项目时，先增加一个工具

完成演示后，可以先把只含项目文档的目录交给服务，练习“读取文档、列出依据、提出修改方案”。需要写入时再批准具体操作，并检查 Git diff。

不要一次连接多个数据库、文件系统和云服务再让模型自由尝试。一次增加一项能力，出了问题才容易知道是哪个服务、哪条权限或哪个参数导致的。

如果你还在比较扩展，可以看 VS Code AI 编程插件选型；如果想从终端完成一个小改动，则看 Claude Code 安装与第一次使用。