MCP

Model Context Protocol

也常被叫作：模型上下文协议工具协议给 AI 装插件的那个标准

AI 与 Agent 通常止于「运行时」约 2 分钟读完

你可能会这么说

「我想让 AI 能直接看我的文件和数据库，别老让我复制粘贴给它。」

MCP Model Context Protocol

一套让 AI 助手统一接入外部工具和数据源的开放协议，写一次接口，多个 AI 客户端都能用。

在 MCP 出现之前，每个 AI 客户端接工具的方式都不一样：你给 Claude 写的插件，Cursor 用不了；给 Cursor 写的，又得为下一个工具重写。MCP 把这件事标准化了——你把能力做成一个 MCP 服务器（提供工具、资源、提示模板），任何支持 MCP 的客户端都能挂上去。

它解决的是连接问题，不是智能问题。这句话很重要，因为大多数关于 MCP 的失望都来自搞错了这一点：装上一个数据库 MCP，AI 并不会因此就懂你的业务；它只是从「无法访问」变成了「可以访问」。能不能用对，取决于工具描述写得清不清楚、权限边界划得对不对。

还有一个更容易被忽略的现实：工具注册成功 ≠ 模型能发现它 ≠ 模型真的调用了它。 这三件事分别会在三个不同的地方失败——配置文件写错、工具描述让模型认不出该在什么时候用、以及调用了但结果没有正确回填给模型。日志里出现工具名，只证明第一步。

最后是权限。MCP 服务器跑在你自己的机器或服务器上，它能做的事就是 AI 能做的事。给一个「可以执行任意命令」的 MCP，等于把终端交给了模型。默认应该只给读，写和删要单独授权。

长什么样真实可交互，不是截图

你的问题→AI 客户端→MCP 协议→MCP 服务器→你的文件 / 数据库 / API

// 典型的客户端配置：告诉 AI「有这么一个工具服务器」
{
  "mcpServers": {
    "my-files": {
      "command": "npx",
      "args": ["-y", "@some/mcp-filesystem", "D:/work"],
      "env": { "READ_ONLY": "true" }
    }
  }
}

已连接3 个工具可用只读模式

注意配置里那个 READ_ONLY：能力边界是在接入的时候定的，不是靠事后叮嘱模型「你别删东西」。

拆开看，里面有这几块

1
MCP 客户端 Client
你用的那个 AI 应用（编辑器、桌面客户端、Agent 框架）。它负责发现工具、把工具列表告诉模型、执行调用。
2
MCP 服务器 Server
你或别人写的能力提供方。一个服务器可以暴露多个工具，跑在本地进程或远程服务上。
3
工具 Tools
模型可以主动调用的动作，比如「查询这张表」。每个工具的描述文字决定模型认不认得该什么时候用它。
4
资源 Resources
可被读取的内容（文件、记录、文档）。和工具的区别是：资源是拿数据，工具是做事。
5
提示模板 Prompts
服务器预置的常用指令模板，让用户一键触发复杂操作。
6
传输方式 Transport
本地用标准输入输出（stdio），远程用 HTTP/SSE。传输层出问题的表现通常是「连不上」而不是「用不对」。

常见的有哪几种

本地 stdio 服务器Local stdio

作为子进程启动，最常见。延迟低，能碰本机文件。

用在：文件、Git、本地数据库、本机命令

远程 HTTP 服务器Remote HTTP/SSE

跑在服务器上，多人共用，需要考虑鉴权。

用在：团队共享的内部系统、SaaS 接入

只读服务器Read-only

只提供查询，不提供写入。风险最低，应该是默认选择。

用在：任何你还没完全信任的场景

可写服务器Write-enabled

能改数据、发消息、执行命令。必须明确授权并限定范围。

用在：确实需要自动化落地的动作

容易搞混？这样区分

MCP ≠ 工具调用 Tool Calling

工具调用是模型的能力（模型能输出「我要调用这个函数」）；MCP 是接入的标准（工具从哪来、怎么描述、怎么连）。没有 MCP 也能有工具调用；有 MCP，是为了不用为每个客户端重写一遍。

看工具调用

MCP ≠ API API

API 是给程序用的接口，参数和错误码写给开发者看；MCP 服务器是给模型用的接口，工具描述要写给模型看——说清「什么时候该用我」，而不只是「我有哪些参数」。

看 API

MCP ≠ Skill Skill

Skill 通常是一段给模型看的说明书（怎么做这类事），本身不带执行能力；MCP 提供的是真实的执行通道。一个成熟的搭配是：Skill 教方法，MCP 给手脚。

看 Skill

什么时候用得上

让 AI 读你的项目

挂一个只读的文件系统服务器，限定到具体目录。它就不用你一段段贴代码了。

查数据库不写 SQL

挂只读数据库服务器，用自然语言问数据。写权限单独考虑，别一起给。

接内部系统

把公司内部接口包一层 MCP，团队里所有 AI 客户端都能复用，不用各自对接。

你可以这样跟 AI 说

直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。

【任务】帮我接入一个 MCP 服务器，让你能读取 [具体目录 / 具体数据源]
【范围】只改客户端的 MCP 配置文件，不改项目代码
【权限边界】先只给**只读**权限，限定在 [具体路径]；不要给执行命令、写入或删除的能力；不要接入任何含密钥、账号或私人数据的目录
【交付】
  1. 配置文件的完整路径，以及你加了哪几行
  2. 重启客户端后，把你现在**实际能看到的工具名称逐个列出来**（不是文档里应该有的，是你这一轮真的看到的）
  3. 真实调用其中一个工具一次，把请求参数和返回结果原样贴给我
  4. 如果连接失败，贴出原始报错，不要猜原因
【提醒】不确定路径或权限就先问我，不要自己扩大范围

第 2 条是这段话的关键：让它列出「这一轮真的看到的工具名」。这一步能立刻分辨「配置写了」和「模型真的发现了工具」——这两件事失败率都很高，而且症状完全一样（都表现为「用不了」）。

它说「做好了」，你怎么自己验

这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「运行时」这层：真的跑起来了，能在本机看到结果。

要亲眼看到这些，才算数

客户端里能看到这个服务器处于已连接状态，不只是配置文件里有一段 JSON。
让模型列出它当前实际可见的工具名，和你预期的一致。名字对不上，说明它发现的不是你以为的那个服务器。
真实触发一次调用，看到请求参数和返回结果，而不是模型转述的「我查到了」。
故意问一个需要用到该工具的问题，确认它主动调用了工具，而不是凭记忆编答案。
确认权限范围：尝试访问范围外的路径，应该被拒绝而不是成功。

它常这么糊弄你

「MCP 已配置完成」——但客户端根本没重启，配置没生效。
工具在日志里出现过，就宣称「已接通」。日志里有名字只证明进程启动了，不证明模型能调用。
模型说「我已查询了数据库」，但没有任何调用记录——它是根据上下文猜的。要求贴原始返回。
为了「先跑通」给了完整读写权限，然后忘了收回。这是最常见的真实事故来源。
把「装上了 MCP」说成「AI 现在懂我的业务了」。连接和理解是两件事。

MCP 这类接入类任务最高只能验到「运行时」层：能在你机器上真实调用成功。要说到「生产」层，还需要远程鉴权、失败重试、审计日志和权限回收流程。

考考你选一个你觉得对的

AI 说「MCP 服务器已成功接入，现在可以访问你的数据库了」。最有效的一句追问是？

想再深挖一点靠谱出处

Model Context Protocol 官方文档modelcontextprotocol.io ↗MCP 规范官方规范 ↗

# MCP (Model Context Protocol)

> 一套让 AI 助手统一接入外部工具和数据源的开放协议，写一次接口，多个 AI 客户端都能用。

**你可能会这么说**：我想让 AI 能直接看我的文件和数据库，别老让我复制粘贴给它。

在 MCP 出现之前，每个 AI 客户端接工具的方式都不一样：你给 Claude 写的插件，Cursor 用不了；给 Cursor 写的，又得为下一个工具重写。MCP 把这件事标准化了——你把能力做成一个 MCP 服务器（提供工具、资源、提示模板），任何支持 MCP 的客户端都能挂上去。 它解决的是连接问题，不是智能问题。这句话很重要，因为大多数关于 MCP 的失望都来自搞错了这一点：装上一个数据库 MCP，AI 并不会因此就懂你的业务；它只是从「无法访问」变成了「可以访问」。能不能用对，取决于工具描述写得清不清楚、权限边界划得对不对。 还有一个更容易被忽略的现实：工具注册成功 ≠ 模型能发现它 ≠ 模型真的调用了它。 这三件事分别会在三个不同的地方失败——配置文件写错、工具描述让模型认不出该在什么时候用、以及调用了但结果没有正确回填给模型。日志里出现工具名，只证明第一步。 最后是权限。MCP 服务器跑在你自己的机器或服务器上，它能做的事就是 AI 能做的事。给一个「可以执行任意命令」的 MCP，等于把终端交给了模型。默认应该只给读，写和删要单独授权。

**也叫**：模型上下文协议、工具协议、给 AI 装插件的那个标准

## 你可以这样告诉 AI

```text
【任务】帮我接入一个 MCP 服务器，让你能读取 [具体目录 / 具体数据源]
【范围】只改客户端的 MCP 配置文件，不改项目代码
【权限边界】先只给**只读**权限，限定在 [具体路径]；不要给执行命令、写入或删除的能力；不要接入任何含密钥、账号或私人数据的目录
【交付】
  1. 配置文件的完整路径，以及你加了哪几行
  2. 重启客户端后，把你现在**实际能看到的工具名称逐个列出来**（不是文档里应该有的，是你这一轮真的看到的）
  3. 真实调用其中一个工具一次，把请求参数和返回结果原样贴给我
  4. 如果连接失败，贴出原始报错，不要猜原因
【提醒】不确定路径或权限就先问我，不要自己扩大范围
```

## 怎么验证他真的做到了

通常止于层级：**运行时** — 真的跑起来了，能在本机看到结果

- [ ] 客户端里能看到这个服务器处于已连接状态，不只是配置文件里有一段 JSON。
- [ ] 让模型列出它当前实际可见的工具名，和你预期的一致。名字对不上，说明它发现的不是你以为的那个服务器。
- [ ] 真实触发一次调用，看到请求参数和返回结果，而不是模型转述的「我查到了」。
- [ ] 故意问一个需要用到该工具的问题，确认它主动调用了工具，而不是凭记忆编答案。
- [ ] 确认权限范围：尝试访问范围外的路径，应该被拒绝而不是成功。

常见糊弄：
- 「MCP 已配置完成」——但客户端根本没重启，配置没生效。
- 工具在日志里出现过，就宣称「已接通」。日志里有名字只证明进程启动了，不证明模型能调用。
- 模型说「我已查询了数据库」，但没有任何调用记录——它是根据上下文猜的。要求贴原始返回。
- 为了「先跑通」给了完整读写权限，然后忘了收回。这是最常见的真实事故来源。
- 把「装上了 MCP」说成「AI 现在懂我的业务了」。连接和理解是两件事。

来源：https://mickerbook.com/reference/t/mcp/