MCP Protocol 详解：AI Agent 工具标准协议

TL;DR — MCP（Model Context Protocol）是基于 JSON-RPC 的协议，让 AI Agent 通过标准化接口发现和调用外部服务器上的工具。可以理解为 Agent 工具的 USB-C：一个插头，接所有设备。客户端（Claude、Cursor、Kiro 或你自己的 Agent）连接 MCP Server，问有什么工具可用，然后调用——不需要为每个工具写适配器。目前生态已有 1,900+ 个 Server，覆盖数据库、API、文件系统、浏览器等。

我反复缴纳的”集成税”

去年我花了三周把一个研究 Agent 接到四个数据源：一个 PostgreSQL 数据库、一个网页爬虫、一个 PDF 解析器、和一个 Slack 频道。每个集成都是定制的。Postgres 工具需要连接池封装和 schema 感知的 prompt 注入。爬虫需要独立的重试逻辑和输出标准化。PDF 工具的数据格式又完全不同。每加一个数据源，就多一个适配器、一套错误码处理、一坨和 Agent 核心逻辑无关的胶水代码。

后来我用 MCP Server 重新接了同一个 Agent。Agent 端代码缩减为一个连接四个 Server 端点的客户端。工具 schema 由 Server 自己提供——客户端不再硬编码定义。加第五个数据源只花了 20 分钟，而不是三天。

这就是 MCP Protocol 的核心价值：消除逐个集成的适配器成本。

MCP 之前的痛点

MCP 出现之前，每个 AI 应用都在从头发明工具集成。标准套路：

1. 在应用代码里定义函数 schema
2. 写 handler 把模型输出翻译成实际 API 调用
3. 把结果格式化成模型能消费的形式
4. 处理认证、错误、重试、超时——每个工具都是定制的
5. 对每个工具、在每个 Agent 里重复以上步骤

真正的成本不只是初始开发，是维护。外部 API 改了，你更新适配器。从 GPT-4 换到 Claude，你重写 schema 格式。同事做了另一个 Agent 也需要同样的 Postgres 访问，他自己又写一份适配器——因为你的和你的 Agent 代码缠在一起。

没有标准意味着：

• 无法复用 —— 工具锁在各个应用内部
• 无法发现 —— Agent 运行时问不了”你能做什么？”
• 无法迁移 —— 换底层模型就得重写工具定义
• 重复劳动 —— 每个团队独立做同样的 Slack/GitHub/DB 集成

Anthropic 在 2024 年底发布了 MCP 规范，就是为了解决这种碎片化。

MCP 的工作原理

MCP Protocol 定义了基于 JSON-RPC 2.0 的客户端-服务器架构。心理模型：

• MCP Host —— 用户交互的应用（Claude Desktop、Cursor、IDE、或你自己的 Agent 运行时）
• MCP Client —— 住在 Host 里，管理与一个或多个 Server 的连接
• MCP Server —— 通过协议暴露工具、资源和 prompt 的进程

graph LR
    User([用户]) --> Host[MCP Host<br/>Claude / Cursor / Kiro]
    Host --> Client1[MCP Client]
    Client1 --> Server1[MCP Server<br/>PostgreSQL]
    Client1 --> Server2[MCP Server<br/>GitHub]
    Client1 --> Server3[MCP Server<br/>Web Scraper]
    Server1 --> DB[(数据库)]
    Server2 --> API1[GitHub API]
    Server3 --> Web[网页]

三个核心原语

MCP Server 暴露三种能力：

原语	谁控制	做什么
Tools	模型发起	Agent 可调用的函数（查询数据库、发消息、创建文件）
Resources	应用控制	客户端可读的数据（文件内容、数据库 schema、配置值）
Prompts	用户发起	预构建的 prompt 模板，引导交互方式

Tools 是最常用的原语。Agent 连接到 MCP Server 时，调用 tools/list 发现可用工具及其名称、描述、JSON Schema 参数定义。然后 Agent 通过 tools/call 传参调用，Server 执行并返回结果。

传输层

MCP 支持两种传输机制：

stdio —— 客户端把 Server 作为子进程启动，通过 stdin/stdout 通信。零网络开销。用于本地工具，如文件系统访问或 CLI 封装。

Streamable HTTP（原来的 SSE） —— 客户端通过 HTTP 连接 Server。支持远程部署、auth header、多个并发客户端。托管式 MCP Server 用这个。

协议本身与传输无关——同样的 JSON-RPC 消息，无论是走 Unix pipe 还是 HTTP 连接。

连接生命周期

一次典型会话：

1. 初始化 —— 客户端发 initialize 带上自己的能力，Server 回复它的能力
2. 发现 —— 客户端调用 tools/list、resources/list 或 prompts/list
3. 调用 —— Agent 按需调用工具
4. 关闭 —— 客户端发 shutdown 通知，连接断开

协议在 session 内是有状态的——Server 可以在调用间保持上下文。但 session 是临时的，跨重启没有内建持久化。

搭建你的第一个 MCP Server

以下是一个最小的 TypeScript MCP Server，暴露一个工具——字数统计：

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: "word-counter",
  version: "1.0.0",
});

// 注册工具
server.tool(
  "count_words",
  "Count words in a given text string",
  {
    text: z.string().describe("The text to count words in"),
  },
  async ({ text }) => {
    const count = text.trim().split(/\s+/).filter(Boolean).length;
    return {
      content: [
        {
          type: "text",
          text: `Word count: ${count}`,
        },
      ],
    };
  }
);

// 在 stdio 上启动 Server
const transport = new StdioServerTransport();
await server.connect(transport);

在 Claude Desktop 里使用，把这段加到 MCP 配置：

{
  "mcpServers": {
    "word-counter": {
      "command": "npx",
      "args": ["tsx", "./word-counter.ts"]
    }
  }
}

搞定。Claude 现在能看到 count_words 作为可用工具。客户端不需要适配器代码——协议处理发现和调用。

生产环境的 Server 需要加错误处理、输入验证、日志记录，可能还要切换到 HTTP 传输以支持远程访问。但核心模式不变：声明工具和 schema、实现 handler、连接传输层。

2026 年生态现状

MCP 生态增长速度超过大多数开放标准。截至 2026 年中的数据：

指标	数量
公开 MCP Server	1,900+（在 SandBase Store）
官方 SDK	TypeScript、Python、Java、Kotlin、C#
支持 MCP 的主要 Host	Claude Desktop、Claude Code、Cursor、Kiro、Windsurf、Cline、Continue
GitHub stars（规范仓库）	42,000+

谁在用

Host 生态快速收敛：

• Claude Desktop 和 Claude Code —— Anthropic 自己的产品率先支持
• Cursor —— IDE Agent 用 MCP 做工具扩展
• Kiro —— AWS 的 AI IDE 支持 MCP Server 连接
• Windsurf、Cline、Continue —— 编码助手采纳 MCP 做可扩展性
• 自定义 Agent —— 任何 Agent 框架（LangGraph、CrewAI、AutoGen）都可以集成 MCP 客户端 SDK

常见 Server 类别

SandBase Store 的 1,900+ Server 覆盖：

• 数据库 —— PostgreSQL、MySQL、SQLite、MongoDB、Redis
• 开发者工具 —— GitHub、GitLab、Jira、Linear、Sentry
• 通信 —— Slack、Discord、Email、Telegram
• 文件与存储 —— 本地文件系统、S3、Google Drive
• Web —— 浏览器（Puppeteer、Playwright）、网页搜索、爬虫
• 专业领域 —— 金融数据、天气、地图、分析平台

局限和踩坑

坦率说 MCP 目前的不足。这些是我在生产中真实遇到的问题：

没有标准认证方案。 规范没有定义客户端如何向 Server 认证。每个 Server 各搞一套——环境变量里的 API key、OAuth 流程、HTTP header 里的 bearer token。你连 10 个 Server，就管 10 种不同的认证机制。社区在做 auth 规范扩展，但还没定稿。

session 状态是临时的。 MCP session 扛不住 Server 重启。Server 进程崩溃或重新部署，客户端丢失所有 session 上下文。对无状态工具（数据库查询、API 调用）没问题。对跨调用积累状态的工具（多步工作流、文件编辑 session），你得在协议外自己处理持久化。

stdio 的冷启动延迟。 Host 把 MCP Server 作为子进程启动时，有初始化时间——装依赖、建连接、加载配置。重一点的 Node.js Server 我见过 2-8 秒。用户在第一次工具调用时能感觉到。HTTP 方式的远程 Server 因为一直在运行所以没这问题。

工具描述质量参差不齐。 Agent 能不能正确使用一个工具，完全取决于工具的名称、描述和参数 schema。描述写得差的工具会被模型误用。目前还没有工具描述的 lint 或校验标准。

没有内建限流和费用追踪。 协议不定义 Server 如何通知限流或费用。模型决定循环调用一个 MCP 工具的话，协议层面没有东西能阻止它。你得在应用层自己做防护。

这些问题什么时候全部解决说不清——规范在演进，但多个领域里生产使用跑在标准化前面。

FAQ

MCP 是什么的缩写？

MCP 是 Model Context Protocol 的缩写。这是 Anthropic 创建的开放协议，标准化了 AI 应用连接外部工具和数据源的方式。

MCP 只能给 Anthropic / Claude 用吗？

不是。MCP 是开放规范。任何 AI 应用都可以实现 MCP 客户端。Claude 是第一个主要 Host，但 Cursor、Kiro、Windsurf 以及很多开源框架都支持。Server 端完全模型无关——同一个 MCP Server 适用于任何支持该协议的 Host。

MCP 和 function calling 有什么区别？

Function calling 是模型用来请求工具调用的机制（模型输出结构化 JSON 表示函数调用）。MCP 是标准化工具如何打包、发现和提供给任意客户端的协议层。实际中，MCP 工具在到达模型之前会被转换成 function call schema。两者是组合关系，不是竞争关系。详细对比见 MCP vs Function Calling。

MCP 能用在生产环境吗？

可以，但有前提。工具调用部分协议已经稳定。缺口在认证、可观测性和生命周期管理。生产部署需要额外基础设施——auth 代理、健康检查、重启策略——这些协议本身还没提供。

哪里能找到 MCP Server？

SandBase Store 列出了 1,900+ 个 MCP Server，按类别分类。你也可以在 GitHub 上搜索 mcp-server-*，或用官方 SDK 自己搭建。

延伸阅读

• 2026 年最佳 MCP Server：Agent 工具基础设施
• MCP vs Function Calling：AI Agent 工具集成
• 生产环境 Agent 的 MCP 执行边界
• 把 MCP Server 接入你的 Agent（2026）
• 在 SandBase 上搭建数据分析 MCP Server
• 2026 年最佳开源 AI Agent 框架