MCP 入门：让 AI 接上你自己的工具

一句话说清

MCP（Model Context Protocol）是一套约定：应用怎么发现你有哪些工具、怎么调用、结果怎么返回。它不负责干活，负责让「干活的东西」被看见、被用上。

传输层是 JSON-RPC 2.0；走标准输入输出时，一条消息一行。就这点东西，剩下的都是围绕它的约定。

为什么需要一个标准

假设有 5 个 AI 应用、8 个外部系统。没有标准，要写 40 个适配器；有标准，两边各写一次，加起来 13 个。这就是 MCP 最朴素的价值：把乘法变成加法。

对使用者来说，好处更直接：同一个工具服务器，Codex 能用，别的支持 MCP 的客户端也能用，不用为每家重写。

三个角色

角色	是谁	负责什么
客户端	你用 AI 的那个应用	连上服务器、把工具列表交给模型、执行调用
服务器	你自己写的小程序	声明有哪些工具、收到请求后真正去做
工具	服务器里的一个动作	有名字、说明和参数格式，比如「查一条笔记」

模型看到的不是你的代码，而是一份工具清单：每个工具叫什么、干什么、要哪些参数。所以描述写得清不清楚，直接决定它会不会用错。

报文长什么样

先问「你有哪些工具」：

{"jsonrpc":"2.0","id":1,"method":"tools/list"}

服务器回一份清单（省略了部分字段）：

{"jsonrpc":"2.0","id":1,"result":{"tools":[
  {"name":"search_notes",
   "description":"按关键词查本地笔记，返回标题和摘要",
   "inputSchema":{"type":"object",
     "properties":{"q":{"type":"string"}},
     "required":["q"]}}
]}}

要用了，就发一次调用：

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"search_notes","arguments":{"q":"发布流程"}}}

看懂这三段，MCP 就没有神秘感了：列清单、按名字调用、把结果交回去。剩下的复杂度都在「怎么把服务器跑起来」和「怎么把权限管住」。

接进 Codex 的三步

先单独跑通服务器。不接任何客户端，用一行命令发个请求，确认它真的能回话。
登记。用 codex mcp add 把启动命令写进去，或者在配置文件里加一段服务器声明。
让它调一次。问一个必须用这个工具才能回答的问题，看它是否真的调用了、结果是否正确。

第三步最容易被跳过。只看「已连接」不算数，要看一次真实的调用记录和返回内容。

最容易踩的坑：审批策略

如果你把审批设成了「永不询问」，那些需要确认才能执行的工具调用会被直接拒绝。表现很像「服务器坏了」：连得上、列表也有，就是一调用就失败。

正确做法是给这个服务器单独设一个审批模式，而不是为了省事把全局审批全关掉。权限是分层给的，不是一次性全给。

安全边界

先给只读工具，确认行为符合预期，再考虑写操作。
服务器能碰到的目录越小越好，别一上来就开放整个磁盘。
返回结果要短。把整张表塞回去，既费钱又容易让模型抓错重点。
密钥、令牌这类东西留在服务器自己的配置里，不要出现在提示词和返回内容中。

什么时候别用 MCP

一次性任务，直接跑一条命令就够了。MCP 的价值在「反复用」：同一套查询、同一组操作，今天用、下周还用，才值得为它写一个服务器、维护一份权限。

判断标准很简单：这件事你会不会做第二次。会，就考虑标准化；不会，别为它建基础设施。