MCP 模型上下文协议详解：AI 工具调用标准化原理与开发者接入指南

MCP 解决的是一个真实存在的混乱

在 MCP 出现之前，每家 AI 平台处理工具调用的方式都是自己一套。OpenAI 有 Function Calling，Anthropic 有 Tool Use，Google 有类似机制但参数格式不同，国产模型又各有各的接口。开发者如果想让同一个「查询数据库」工具同时服务于 GPT-5.5 和 Claude Opus 4.8，往往要写两套适配层——字段名不同、错误码不同、上下文传递方式也不同。

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 主导、目前已获得多家主流厂商跟进的开放协议，目标是把「模型如何调用外部工具」这件事标准化。粗略类比：MCP 之于 AI 工具调用，相当于 USB-C 之于充电接口——不是说以前的接口不能用，而是统一之后所有人省力。

协议本身基于 JSON-RPC 2.0，跑在 stdio 或 HTTP/SSE 传输层上。一个完整的 MCP 交互由三个角色构成：

• Host：运行模型的客户端环境，比如 Claude Code、Codex、Gemini CLI，或者你自己的应用
• MCP Client：内嵌在 Host 里的协议客户端，负责与 Server 建立连接、发送请求、接收结果
• MCP Server：暴露工具、资源、Prompt 模板的服务进程，可以是本地进程（stdio）或远程服务（HTTP）

模型本身并不直接"知道" MCP Server 的存在。它看到的依然是工具列表和工具调用结果——MCP Client 负责在中间做翻译，把协议层的通信转换成模型能理解的格式。

协议原理：一次工具调用的完整链路

以「让 Claude Opus 4.8 查询一个 PostgreSQL 数据库」为例，走一遍完整流程。

Step 1：能力协商（Capability Negotiation）

Host 启动时，MCP Client 向 MCP Server 发送 initialize 请求：

{
  "jsonrpc": "2.0",
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-03-26",
    "clientInfo": { "name": "claude-code", "version": "1.8.2" }
  }
}

Server 返回自己支持的能力列表（tools、resources、prompts），Client 据此决定后续交互方式。

Step 2：工具发现（Tool Discovery）

Client 调用 tools/list，Server 返回结构化的工具描述，包含工具名、描述、输入 Schema（JSON Schema 格式）。这份描述会被注入到模型的系统提示或工具列表中，让模型知道它能调用什么。

Step 3：模型决策与工具调用

模型根据用户意图决定调用哪个工具，生成一个工具调用请求。Client 拦截这个请求，转换为 MCP 协议格式，发给 Server：

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": { "sql": "SELECT * FROM orders WHERE status='pending' LIMIT 20" }
  }
}

Step 4：结果回传

Server 执行工具逻辑，返回结构化结果。Client 将结果格式化后塞回模型上下文，模型基于这个结果继续生成回答。

整个链路里，模型完全不感知 JSON-RPC 的细节——它只看到「工具描述」和「工具返回值」，具体传输细节由 MCP 层封装。

三类原生能力：Tools、Resources、Prompts

MCP 不只是「函数调用的包装层」，它定义了三种不同粒度的服务能力：

能力类型	作用	典型使用场景
Tools	执行操作，有副作用	查询数据库、调用 API、写文件
Resources	暴露只读数据，类似文件系统	读取配置、获取文档片段
Prompts	提供参数化的 Prompt 模板	标准化代码审查、报告生成流程

Tools 是最常用的，但 Resources 的设计值得单独说一下。它允许 Server 以 URI 形式暴露数据（比如 postgres://mydb/orders/schema），Client 可以按需拉取，而不是每次都把完整数据塞进上下文——这对管理 128K 甚至更长的 context window 很有价值，避免无效 token 占用。

开发者如何接入 MCP

接入现有 MCP Server（5 分钟内跑起来）

以 Claude Code 为例，在项目根目录创建 .mcp.json：

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRESQL_CONNECTION_STRING": "postgresql://user:pass@localhost/mydb"
      }
    }
  }
}

保存后重启 Claude Code，它会自动发现并连接这个 Server。目前社区维护的官方 Server 列表已超过 80 个，覆盖 GitHub、Slack、Jira、Filesystem、Brave Search 等常见场景。

自己写一个 MCP Server（Python 示例）

官方提供了 mcp SDK，安装：

pip install mcp

最小可用 Server：

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("my-tool-server")

@mcp.tool()
def get_weather(city: str) -> str:
    """获取指定城市的天气"""
    # 实际逻辑替换为真实 API 调用
    return f"{city} 当前晴，25°C"

if __name__ == "__main__":
    mcp.run()  # 默认 stdio 模式

这个 Server 运行后，任何支持 MCP 的 Host（Claude Code、Codex、Gemini CLI，或自建应用）都可以直接调用 get_weather 工具，无需为每个模型单独适配。

选择传输模式

• stdio：本地进程，低延迟，适合开发调试和本地工具
• HTTP + SSE：支持远程部署，适合团队共享工具或 SaaS 集成；Server 可以部署在任意 HTTPS 端点上

多数生产场景建议从 stdio 起步，验证逻辑后再迁移到 HTTP 模式做横向扩展。

当前生态与值得注意的边界

Claude Code、Codex 和 Gemini CLI 三大编码 CLI 目前都已原生支持 MCP。GPT-5.4 系列通过 Codex 的 MCP 集成也能对接，但 OpenAI 自家的 Responses API 仍在推进与 MCP 的深度对齐，部分高级特性（如 Resource 订阅）在不同宿主里支持程度不一。

DeepSeek V3、Qwen 3 等国产模型如果通过 OpenAI 兼容接口接入，可以借助中间层 Host 使用 MCP 工具，但官方原生 MCP Client 支持尚在推进中——这块生态还在快速补全。

协议本身目前稳定版本是 2025-03-26，安全模型上需要注意：MCP Server 拥有执行任意代码的能力，在接入第三方 Server 时要像对待第三方依赖一样做审计，不要无脑 npx -y 一个来源不明的 Server。

---

如果你在给 AI 工具调用搭基础设施，有一个绕不开的现实问题：不同模型的 API 成本和延迟差异悬殊。我自己在测试 MCP Server 时会用 XycAi 词元平台，一个 OpenAI 兼容接口接 200+ 模型，Claude Code 和 Codex 都能一键接入，GPT-5.5 和 Claude Opus 4.8 的价格低至官方价 1.4 折起，全球 CN2 节点延迟 5ms 级别——对于需要频繁调试工具调用链路的开发者来说，这个成本和响应速度差异在长期跑量时会很明显。