MCP 实战：用模型上下文协议给 AI "长手"
以前给 AI 接一个工具，要为每个客户端单独写一套集成——接 10 个工具、用 3 个客户端，就是 30 份适配代码，写不完、改不动。MCP（Model Context Protocol，模型上下文协议）就是为了消灭这个"M×N 适配地狱"而生的：它把"模型"与"工具/数据源"之间的连接标准化，写一次 Server，处处可用，被戏称为"AI 应用的 USB-C"。官网。本文讲清它的架构，并带你"接一个现成的 + 写一个自己的"。
1、MCP 是什么、解决什么
MCP 是 Anthropic 于 2024 年底提出、现已获多家厂商支持的开放协议。它规定"AI 客户端"与"外部能力提供方（MCP Server）"之间如何发现能力、调用工具、读取数据。打个比方：以前每个电器配一种充电线（M×N），MCP 统一成一种接口（USB-C）——只要 Server 遵循协议，任何支持 MCP 的客户端（Claude Desktop、Claude Code、Cursor 等）都能即插即用。
2、核心架构：Host、Client、Server
┌──────────────┐ MCP 协议 ┌──────────────┐
│ Host (AI端) │ ─────────▶ │ MCP Server │ ──▶ GitHub / 数据库 / 文件 / ...
│ Claude/Cursor │ ◀───────── │ (能力提供方) │
└──────────────┘ └──────────────┘
- Host：运行 AI 应用的地方（Claude Desktop、Claude Code、Cursor）
- Client：Host 内负责与 Server 通信的组件（1 Host 可带多 Client）
- Server：暴露具体能力的进程（文件系统、数据库、GitHub...）
- 传输：stdio（本地子进程）/ HTTP+SSE（远程），新版统一为 Streamable HTTP关键认知：一个 Host 可接多个 Server，一个 Server 可服务多个 Host——这正是"写一次处处用"的来源。本地工具用 stdio 启动子进程，远程能力用 HTTP 传输。
3、三类能力：Tools、Resources、Prompts
能力 本质 何时用
-------------------------------------------------------------------
Tools 可调用的函数（有副作用） 模型要"做事"：发邮件、查库、建 issue
Resources 可读取的数据（只读） 模型要"看东西"：读文件、读配置、读日志
Prompts 预定义的提示模板 常用交互套路：代码审查模板、总结模板分清这三类很重要：Tools 是"动手"（有副作用、需谨慎授权），Resources 是"动眼"（只读、较安全），Prompts 是"套路复用"。一个 Server 可以同时暴露三类能力。
4、实战一：接入一个现成 Server
以官方"文件系统"Server 为例，让 AI 能读写指定目录。不同客户端配置文件不同：Claude Desktop 是 `claude_desktop_config.json`；Claude Code 是项目根的 `.mcp.json`（团队共享）或用户级配置；Cursor 在设置里配置 MCP。以 Claude Desktop 为例：
// claude_desktop_config.json
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/Documents"]
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "你的token" }
}
}
}核心实现：
1. 在配置中声明要启动的 Server 及参数（命令、参数、环境变量）
2. Host 启动时拉起 Server 子进程，完成能力握手
3. 模型在对话中按需调用 Server 暴露的 Tool / 读取 Resource
4. Server 执行操作并把结果回传给模型
配好后重启客户端，就能在对话里直接说"读一下 Documents 里的笔记""帮我看下 GitHub 上 #123 的描述"，AI 会自动调用对应 Server。
5、实战二：写一个自定义 Server
用官方 SDK，几十行就能把任意内部能力暴露给 AI。下面是一个最小 Server 骨架（TypeScript SDK，注册一个"查天气"工具）：
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
const server = new McpServer({ name: "weather", version: "1.0.0" });
// 注册一个工具
server.tool(
"get_weather", // 工具名
"查询某城市天气", // 描述（模型据此判断何时调用）
{ city: z.string() }, // 入参 schema
async ({ city }) => {
const data = await fetchWeather(city); // 你的业务逻辑
return { content: [{ type: "text", text: JSON.stringify(data) }] };
}
);
// 用 stdio 传输启动
const transport = new StdioServerTransport();
await server.connect(transport);几个要点：工具描述要写清楚（模型靠它判断"该不该调用"）；入参用 schema 校验（防模型乱传参）；返回统一格式（content 数组）。写完用 `npx` 或打包成可执行命令，再在客户端配置里引用即可。调试可用官方的 MCP Inspector 工具，单步测试每个工具。
6、安全：Server 能干什么，就代表 AI 能干什么
这是最容易被忽视、却最重要的一点。MCP Server 是一个进程，它的权限 = 它能访问什么。给文件系统 Server 一个根目录参数，AI 就能读写整台机器；给数据库 Server 写权限，AI 就能删数据。安全准则：最小权限（只暴露必要目录/表/操作）；敏感操作要用户授权（让客户端弹确认）；只读优先（能只读就别给写）；警惕命令注入（本地 Server 的命令参数要做校验）；token 与密钥别硬编码。把 Server 当成"给 AI 的权限边界"来设计。
7、生态全景
Server 生态在 2026 年已爆发，常见几类：文件系统（读写本地）、GitHub / GitLab（仓库、issue、PR）、数据库（PostgreSQL、SQLite，自然语言查数）、搜索与浏览器（Brave、Google、Playwright）、协作工具（Slack、Notion、Linear）、记忆库、云服务（S3、K8s）等。挑选原则：优先官方/高星 Server，自建敏感能力时自己写并严控权限。
8、MCP vs Function Calling：何时用谁
Function Calling 模型能力：输出"结构化工具调用请求"（模型侧）
MCP 连接协议：统一"工具从哪来、怎么标准接入"（生态侧）
关系：MCP Server 暴露的工具 → 通过 Function Calling 被模型调用
MCP 解决"工具的供给与标准化"，FC 解决"模型如何发起调用"两者不冲突，而是配合：少量、固定、自有的工具，直接用 Function Calling 即可；大量、可复用、跨客户端的能力，封装成 MCP Server 更省心。随着 Agent 生态对"工具丰富度"的要求暴涨，MCP 的标准化价值会越来越大。
9、总结
MCP 把"AI 接工具"从"一对一定制"升级为"即插即用"：它用 Host/Client/Server 架构 + 三类能力（Tools/Resources/Prompts）+ 标准传输，化解了 M×N 适配地狱。配一段 JSON 就能接入现成 Server，用 SDK 几十行就能写出自定义 Server。
关键要点：
- MCP 统一 Host 与工具/数据源的连接，化解 M×N 适配地狱
- 三类能力：Tools（做事）/ Resources（看东西）/ Prompts（套路）
- 配 JSON 接现成 Server，用 SDK 写自定义 Server，权限按"最小授权"设计
- 与 Function Calling 配合而非替代
对于想给 AI"长手"的开发者而言，MCP 是当前最省心的方案：不必再为每个客户端重复造轮子，把精力放在"定义好能力、守好权限边界"上。挑几个现成 Server 快速获得读写万物的能力，再为自己最核心的业务写一个专属 Server——你的 AI 应用，会因此从"只能聊"变成"真能干"。
