MCP 接上了，然后呢：从连接成功到实际可用

连接列表里多了一个绿色状态，不代表文章检查已经多了一项可用能力。工具可能没出现在当前会话里，调用可能失败，也可能读到了一份不相关的资料。

上一篇讨论怎样验证 Skill。这一篇继续检查同一条工作流里的工具入口：接入 MCP 之后，怎样知道它真的能帮助完成任务。

先写出缺少的那项能力#

如果现有工具已经能读取博客文件，检查本地文章通常不用再接一个文件服务。更值得接入的情况，是任务需要读取另一个系统里的文档，或者从某项服务查询原本无法取得的数据。

先把需求写成一句能验收的话，比如“读取指定知识库里的一篇版本说明，返回正文和可定位的出处”。这样才能判断接入有没有解决问题。

如果需求只是“让 AI 更强”，连接完成后往往不知道该测什么。工具数量增多，还可能让模型选择错误的入口，增加维护成本。

初次验收尽量用公开或专门制作的测试材料。以文件读取为例，预先知道文章标题和正文内容，就能分清模型实际读取了文件，还是凭文件名猜了内容。

客户端与服务要匹配#

接入前需要确认三件事：你使用的客户端支持什么接入方式，服务提供什么连接方式，以及当前账号或运行环境能否使用它。

常见的本地接入使用 stdio：客户端启动服务进程，通过标准输入输出交换协议消息。远程服务可以使用 Streamable HTTP，通过服务提供的 MCP 地址连接。旧教程中的 HTTP+SSE 与当前方式有版本差异，不能只因地址里都有 HTTP 就直接互换。

远程地址也不一定是网站首页，更不是任意 REST API。应该使用服务方提供的 MCP 端点，并按客户端和服务要求完成认证。

不同产品的配置入口、字段和账号条件可能不同。下面以 Claude Desktop 的本地配置和文件服务演示验收思路，配置结构与工具名按 2026 年 10 月 3 日读取的官方文档核对。它是一份接入示例，本文没有实际运行这套配置，使用时还要在自己的设备上测试。

用一个小目录做首次接入#

先在自己可以管理的项目里准备一个专门的测试目录，例如 Windows 上的 D:\blog-lab\mcp-input。放入一份不含私人信息的 sample.md，写上你能核对的内容：

1
# 测试文章
2

3
本文用于验证文件读取，正文只有这一段。

假设设备已有符合服务要求的 Node.js 和 npx，可以按客户端文档打开 claude_desktop_config.json，在现有配置里合并这个服务条目：

1
{
2
  "mcpServers": {
3
    "article-files": {
4
      "command": "npx",
5
      "args": [
6
        "-y",
7
        "@modelcontextprotocol/server-filesystem",
8
        "D:\\blog-lab\\mcp-input"
9
      ]
10
    }
11
  }
12
}

路径要换成真实存在的测试目录；其他系统使用对应的绝对路径。已有 mcpServers 时增加其中的条目，保留原有配置，不能用这个片段覆盖全部设置。

npx -y 可能下载并运行服务包，-y 会跳过安装询问。执行前应确认包来源与安装行为；这里未固定包版本，重复执行可能使用不同版本。验收后若要长期运行，需要记录实际版本，并按包与客户端支持方式固定下来。

按客户端说明重新加载配置或完整重启，然后查看服务状态与可用工具。若启动失败，先看客户端记录的进程错误，确认命令是否可找到、路径是否有效、JSON 是否解析成功。

这个服务包含写入工具。限定目录减少了可访问范围，却不等于只读。首次只批准读取测试文件的调用；需要强制只读时，应另外使用支持只读的服务、挂载或账户权限，不能只在提示词里写一句“不要改”。

验收目录、工具，再验收内容#

连接之后，先确认当前工具列表。文件服务的官方说明包含 list_allowed_directories 和 read_text_file；实际名称与参数以当前客户端发现的定义为准。

我会先要求查询允许访问的目录，再读取指定文件：

1
先调用 article-files 的 list_allowed_directories，核对实际允许的范围。
2
若范围超过本次测试目录，暂停读取并报告。
3
范围符合后，用 read_text_file 读取该目录中的 sample.md。
4
只读取，不调用写入工具。报告实际工具、输入路径和返回正文。

当前实现还支持由客户端 Roots 动态更新允许目录。因此不能只看启动参数，就认定实际范围始终只有一个文件夹。应以工具返回的允许范围及当前配置为依据。

读到结果后，对照预先写入的标题和那一段正文。调用记录里要有真实的工具调用，返回内容要与文件一致。模型说“读取成功”，却没有调用记录或只概括了文件名，都不够完成验收。

然后读取测试目录里一个故意不存在的文件。预期是明确报告读取失败，不能补出文章正文。这项测试只在专门目录内进行，不用访问个人目录来试探权限。

迁移到真实文章检查时，还要核对编码、内容完整性、截断情况和定位方式。能读一行示例，只能证明最小调用可用，不能证明长篇 MDX 或外部资料库的结果都合适。

连接故障与结果不合格分开处理#

同样是“没有拿到资料”，原因可能在不同位置：

现象	先检查什么	本次结果怎样记录
服务没有启动	命令路径、依赖、配置解析和进程日志	连接未完成
服务已连接，但工具没出现	服务是否提供工具、客户端是否加载到当前会话	工具发现未完成
工具存在，调用报错	实际参数、允许目录、认证和服务错误	调用失败，保留原因
调用成功，但只有片段	返回范围、分页或截断限制	读取范围不足
正文完整，却与问题无关	查询对象、版本和资料内容	资料不能支持当前判断

日志只读取排错所需的部分，避免复制包含凭证或私人内容的完整记录。远程查询遇到限流时，按服务返回的等待要求处理；参数无效应修正参数，权限不足应停止相关操作，反复发送同一个请求不会改善这些问题。

MCP 工具可能在结果里用 isError 标记执行错误，也可能返回协议错误。看到一次网络请求成功，不能因此把业务错误当成正常结果。文章检查报告应把“工具返回了错误”和“工具返回了不适用的资料”分别写清楚。

返回材料还需要阅读和判断#

如果工具返回了一篇版本说明，下一步仍要确认它讲的是哪个产品、哪个版本，能否支持文章中的说法。搜索摘要、旧文档或一段不完整的正文，都可能缺少关键条件。

工具描述里的只读提示也不是权限保证。服务是否可信、实际授权范围是什么，仍要单独判断。某项只读查询即使不修改外部数据，也可能把查询文本发送给服务方，因此测试时不应随手提交整篇私人草稿。

返回正文里可能夹着“忽略此前规则”之类指令。它属于待核实的材料，不能因此改变任务目标，扩大读取范围，或让 Agent 调用发布工具。

留下一条可复核的验收记录#

第一次接入后，可以记录：客户端与服务版本、连接方式、实际工具名、允许范围、测试输入、返回内容是否完整，以及失败样例的结果。记录凭证的位置或配置方式即可，不保存凭证值。

这些信息能帮助下一次升级后复测。只有连接状态，没有调用和内容记录，很难判断工具是不是仍然可用。

当指定对象能被正确读取、失败能如实报告、权限范围明确时，才把这个入口加入文章检查流程。下一篇会把文件读取、固定校验和资料核实交给一个 Agent，要求它交付可追踪的报告。