一句话解释

MCP，Model Context Protocol，模型上下文协议，是一个开放协议，用来标准化 AI 应用连接外部工具、数据源和上下文的方式。

如果 Function Calling 解决的是“模型如何调用一个函数”，MCP 更像是在解决“不同 AI 应用如何用同一种方式发现、连接和调用许多外部工具与数据源”。

为什么最近变火

Anthropic 在 2024 年 11 月 25 日发布 MCP，目标是减少 AI 应用与外部系统之间碎片化的集成方式。Anthropic 当时的说法很直接：AI 系统需要访问数据源，但每个工具、每个应用、每个平台都单独接一遍，会形成大量重复的自定义集成。MCP 试图提供一个通用接口。

2025 年之后，MCP 快速变火，主要有几方面原因。

第一，Agent 需要工具。大模型如果只会聊天，价值有限；如果要查代码仓库、读数据库、操作文件、访问业务系统，就需要稳定的工具连接方式。

第二，工具生态需要标准。没有 MCP 时，每个 AI 应用都要为 GitHub、Slack、Postgres、文件系统、浏览器、内部 API 各写一套适配；有了 MCP，工具提供方可以暴露一个 MCP server，多个 AI host 可以复用。

第三，AI 编程工具推动了采用。Claude Desktop、Claude Code、Cursor、VS Code、OpenAI Agents SDK、Responses API 等产品和开发工具陆续支持 MCP 或兼容 MCP 风格的连接方式，让它从协议概念变成开发者实际会碰到的基础设施。

第四，MCP 的治理走向中立化。截至 2026 年 5 月，Anthropic 已在 2025 年 12 月宣布把 MCP 捐赠给 Linux Foundation 旗下的 Agentic AI Foundation，使其作为更中立的开放项目继续发展。

MCP 之所以值得单独写一篇，是因为它不是一个模型能力，而是大模型应用生态里的“连接层”。它回答的不是“模型有多聪明”，而是“模型应用怎样安全、标准、可复用地接入外部世界”。

它解决了什么问题

• 集成碎片化：不同 AI 应用接同一个工具时，不必各自发明一套接口。
• 工具复用困难：一个 MCP server 可以被多个支持 MCP 的客户端或 host 使用。
• 上下文来源复杂：文件、数据库、Git 仓库、网页、API、企业系统都可以用统一协议暴露。
• Agent 缺少行动接口：MCP 让 Agent 更容易发现工具、读取资源、调用能力。
• 工具说明不统一：MCP 用 schema、capability 和 JSON-RPC 消息描述工具和资源。
• 权限边界不清：MCP 架构把 host、client、server 职责拆开，方便控制授权和隔离。
• 本地与远程工具混用：MCP 支持本地进程和远程服务等不同连接方式。

一句话：MCP 试图把“AI 应用接工具”这件事，从一堆临时胶水代码，变成一个可复用的协议生态。

核心概念

1. Host

Host 是用户直接使用的 AI 应用，例如 Claude Desktop、AI IDE、Agent 平台、聊天应用或自动化工具。

Host 负责协调模型、用户界面、权限、多个 MCP client，以及最终是否把某些上下文交给模型。根据 MCP 官方架构，host 也负责控制连接权限、生命周期、安全策略、用户授权和上下文聚合。

你可以把 host 理解为“总控台”。

2. Client

Client 是 host 内部创建的协议客户端。一个 client 通常对应一个 MCP server 连接。

如果一个 AI 应用同时连接 GitHub server、Postgres server、文件系统 server，那么 host 可能会创建多个 client，每个 client 维护一条独立会话。

Client 的作用是处理协议协商、能力交换、消息路由、订阅通知和连接隔离。

3. Server

Server 是暴露工具、资源和提示模板的一端。它可以是本地进程，也可以是远程服务。

例如：

• 文件系统 MCP server：读取指定目录文件。
• GitHub MCP server：查询 issue、PR、仓库内容。
• Postgres MCP server：查询数据库 schema 和执行受控查询。
• 浏览器 MCP server：打开网页、读取页面内容、执行点击。
• 企业内部 MCP server：连接 CRM、工单、审批、知识库。

Server 的职责应该聚焦、清楚、最小化。一个 server 不应该默认看到用户完整对话，也不应该越权访问其他 server 的数据。

4. Tools

Tools 是 MCP server 暴露给模型调用的可执行能力。官方文档中，tools 是 model-controlled，也就是模型可以根据上下文选择调用。

例如：

{
  "name": "search_issues",
  "description": "Search GitHub issues in a repository",
  "inputSchema": {
    "type": "object",
    "properties": {
      "repo": { "type": "string" },
      "query": { "type": "string" }
    },
    "required": ["repo", "query"]
  }
}

工具可以查询数据库、调用 API、执行计算、写文件或进行业务操作。但越有副作用的工具，越需要人类确认、权限控制和审计。

5. Resources

Resources 是 server 暴露的上下文数据，通常由应用决定是否纳入模型上下文。官方文档把 resources 描述为 application-controlled。

资源可以是：

• 文件内容；
• 数据库 schema；
• Git 历史；
• 文档片段；
• 日志；
• 项目配置；
• 图片、音频或其他二进制内容。

Resources 和 Tools 的区别很重要：resource 更像“可读取的上下文”，tool 更像“可执行的动作”。

6. Prompts

Prompts 是 server 暴露的可复用提示模板，通常由用户显式选择。官方文档把 prompts 描述为 user-controlled。

例如一个代码仓库 server 可以暴露：

• code_review：代码审查模板；
• write_tests：测试生成模板；
• explain_module：模块解释模板。

Prompts 让工具提供方不仅能暴露数据和动作，还能暴露“如何与这些数据交互”的最佳实践。

7. Transport

Transport 是 MCP client 和 server 通信的方式。常见方式包括：

• stdio：host 启动本地进程，通过标准输入输出通信。
• Streamable HTTP：适合远程 server。
• HTTP with SSE：早期或兼容场景中常见。

本地 stdio 很适合开发者工具和本机文件系统，但安全风险也更直接；远程 HTTP 适合企业服务和云端工具，但需要处理认证、网络、授权和审计。

工作原理

一个 MCP 系统可以简化成下面的结构：

一次典型 tool 调用可能是：

1. Host 连接 MCP server。
2. Client 和 server 初始化，并交换 capability。
3. Host 通过 client 请求 tools/list。
4. Server 返回可用工具及其 schema。
5. Host 把合适工具暴露给模型。
6. 模型决定调用某个工具。
7. Host 或 client 发起 tools/call。
8. Server 执行工具并返回结果。
9. Host 把结果交给模型，模型继续回答或执行下一步。

这里要注意：MCP 不是模型本身，也不是强制模型如何思考。它只是规定 host、client、server 之间如何交换工具、资源、提示和结果。

协议消息长什么样

MCP 在底层用 JSON-RPC 2.0。下面给出几个最常见消息的最小骨架，方便理解上面的时序图。

初始化握手：

// Client → Server
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": { "tools": {}, "resources": {} },
    "clientInfo": { "name": "claude-desktop", "version": "1.0.0" }
  }
}

// Server → Client
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": { "tools": { "listChanged": true } },
    "serverInfo": { "name": "weather-server", "version": "0.1.0" }
  }
}

列出可用工具：

// Client → Server
{ "jsonrpc": "2.0", "id": 2, "method": "tools/list" }

// Server → Client
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [{
      "name": "get_weather",
      "description": "查询某个城市的当前天气",
      "inputSchema": {
        "type": "object",
        "properties": { "city": { "type": "string" } },
        "required": ["city"]
      }
    }]
  }
}

调用工具：

// Client → Server
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "上海" }
  }
}

// Server → Client
{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      { "type": "text", "text": "上海当前 24℃，多云。" }
    ],
    "isError": false
  }
}

理解这几条就够看懂大部分 MCP server 的行为。其他常见方法还有 resources/list、resources/read、prompts/list、prompts/get，结构都类似。

最小可运行的 MCP server（Python）

官方 Python SDK（mcp 包）让写一个 MCP server 非常简单。下面是 30 行左右的完整例子：

# pip install mcp
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather-server")

@mcp.tool()
def get_weather(city: str) -> str:
    """查询某个城市的当前天气（演示用，返回假数据）。"""
    fake_data = {"上海": "24℃，多云", "北京": "20℃，晴"}
    return fake_data.get(city, f"暂无 {city} 的天气数据")

@mcp.resource("weather://cities")
def list_cities() -> str:
    """返回已知支持的城市列表。"""
    return "上海, 北京"

if __name__ == "__main__":
    mcp.run(transport="stdio")

把这段代码保存为 server.py，在 Claude Desktop 的配置里加：

{
  "mcpServers": {
    "weather": {
      "command": "python",
      "args": ["/abs/path/to/server.py"]
    }
  }
}

重启 Claude Desktop，模型就能看到 get_weather 工具并主动调用。这套机制对 Cursor、VS Code、Claude Code、Cline 等 host 完全一致——这正是 MCP 的价值：一处实现，到处可用。

MCP 和 OpenAPI 的区别

开发者常会问：OpenAPI 也能描述工具，为什么还要 MCP？

维度	OpenAPI / REST	MCP
设计目标	描述 HTTP API 的接口契约	描述 AI 应用与工具/资源/提示的会话协议
连接方式	客户端按需调用 HTTP	双向连接，server 可主动推送变化
内容类型	单一返回（JSON、文件）	结构化的 content[]，支持文本、图像、资源引用
资源模型	没有专门概念	一等公民：可被订阅、列出、读取
提示模板	不在标准内	内建 prompts 概念
鉴权	OAuth2、API Key 等	由 host 负责，server 通常假定已可信
适用范围	服务对服务	模型应用 ↔ 工具/数据源

可以把 MCP 看作"为 AI 助手量身定做的协议"：它假设了模型会消费工具描述、需要列出资源、需要看见 prompts。OpenAPI 完全可以被一个 MCP server 内部代理给模型，但反过来 MCP 的资源订阅、提示模板等概念不是 OpenAPI 的标准能力。

典型应用场景

1. AI 编程助手连接代码仓库

MCP 很适合编程场景。AI IDE 可以通过 MCP server 读取文件、搜索符号、查看 Git 历史、查询 issue、运行测试。

这比把整个代码仓库一次性塞进模型上下文更可控。模型需要什么，host 就通过工具或资源提供什么。

2. 企业知识和业务系统集成

企业可以为内部系统提供 MCP server，例如：

• CRM；
• 工单系统；
• 数据仓库；
• 文档系统；
• 审批系统；
• 项目管理系统；
• 日历和邮件。

这样不同 AI 应用就可以用统一协议接入企业上下文，而不是每个应用都写一套私有集成。

3. 本地桌面助手

Claude Desktop 早期支持本地 MCP server，就是一个典型例子。用户可以让 AI 访问本地文件、项目目录、数据库或开发工具。

本地 MCP 的优点是能力强、延迟低、适合开发者工作流；缺点是安全风险更高，因为本地工具可能拥有文件读写或命令执行能力。

4. 数据分析 Agent

数据分析 Agent 可以通过 MCP 连接数据库、表格、BI 系统和 Python 执行环境。模型负责理解问题和生成分析步骤，MCP server 负责提供可控的数据访问和执行能力。

5. 多工具 Agent 平台

Agent 平台需要接很多工具：搜索、浏览器、文件、代码、数据库、企业 API。MCP 让这些工具可以以标准 server 形式被发现和调用。

这使 Agent 平台不必为每个工具单独设计协议，而可以围绕 MCP 做工具发现、权限、日志和审计。

和其他概念的区别

概念	解决的问题	和 MCP 的关系
Function Calling	模型如何生成结构化函数调用	MCP 可以把许多工具以标准协议暴露给模型应用
Tool Use	模型使用外部工具	MCP 是 tool use 的协议化基础设施之一
RAG	检索外部知识增强回答	MCP server 可以暴露检索工具或知识资源
Plugin	面向某平台的扩展机制	MCP 更强调开放协议和跨 host 复用
API	程序之间的接口	MCP 可以封装 API，并增加工具发现、schema、资源和提示
Agent	多步规划和执行系统	Agent 可以通过 MCP 连接工具和数据源
Workflow	可控流程编排	Workflow 可以在某些步骤调用 MCP 工具
A2A	Agent 与 Agent 通信	MCP 更偏 Agent/模型应用与工具、数据源的连接
Skill	可复用能力包	Skill 可包含说明和脚本，MCP 更偏运行时协议连接

MCP 和 Function Calling 的区别

Function Calling 更像一个模型 API 能力：开发者把函数 schema 给模型，模型生成函数名和参数。

MCP 更像一个连接协议：server 可以向 host 暴露 tools、resources、prompts；host 通过 client 发现和调用这些能力。

简单说：

Function Calling：这个模型怎么调用我给它的函数？
MCP：不同 AI 应用怎么用统一方式连接外部工具和上下文？

很多时候二者会一起出现。Host 可以通过 MCP 获取工具列表，再把这些工具转换成模型能使用的 function/tool schema。

MCP 和 RAG 的区别

RAG 是一种应用模式：先检索资料，再生成答案。

MCP 是一种协议：让 AI 应用连接外部资料和工具。

一个 RAG 系统可以通过 MCP 暴露 search_docs 工具，也可以把文档片段作为 resources 提供给 host。但 MCP 本身不等于 RAG。

MCP 和 Plugin 的区别

Plugin 通常绑定某个平台，比如某个聊天应用、某个 IDE、某个应用商店。MCP 则希望工具提供方写一个 server，多个 host 都可以连接。

这也是 MCP 经常被比作“AI 应用的 USB-C”的原因：不是每个设备都单独发明接口，而是通过一个标准连接。

一个简单例子

假设你想让 AI 编程助手读取本地项目里的 README，并帮你总结安装步骤。

没有 MCP 时，可能要手动复制 README 内容给模型。

有 MCP 时，可以是这样的流程：

如果 server 还暴露了工具，例如 list_files、read_file、search_text，模型就可以先搜索项目结构，再读取相关文件，而不是一次性读取所有内容。

这体现了 MCP 的价值：让 AI 应用用标准方式获取上下文和行动能力，同时由 host 控制权限和边界。

常见误解

误解 1：MCP 是一种模型

不是。MCP 不是 GPT、Claude、Gemini 这样的模型，也不是让模型变聪明的训练方法。它是连接 AI 应用与外部系统的协议。

误解 2：MCP 会自动保证安全

不会。MCP 提供了架构边界和协议机制，但安全仍取决于实现。

MCP 官方工具规范也明确强调，server 需要验证输入、访问控制、限流、清洗输出；client 应提示用户确认敏感操作、展示工具输入、验证工具结果、设置超时并记录日志。

MCP 是连接能力，连接能力越强，越需要安全设计。

误解 3：所有工具都应该通过 MCP 接

不一定。简单应用中，直接 function calling 可能更轻量。如果只有一两个内部函数，而且不需要跨应用复用，MCP 可能过重。

MCP 更适合工具多、上下文来源多、希望跨 host 复用、需要标准化发现和调用的场景。

误解 4：MCP server 可以随便装

不要随便装。MCP server 可能访问本地文件、数据库、浏览器、命令行或企业系统。安装不可信 server，相当于给 AI 应用打开一个潜在高权限接口。

安装前至少要确认：

• server 来源是否可信；
• 需要哪些权限；
• 能访问哪些目录或系统；
• 是否会执行命令；
• 是否会联网；
• 是否有日志和审计；
• 是否能限制工具范围。

误解 5：MCP 只适合 Claude

MCP 由 Anthropic 发布，但它是开放协议。截至 2026 年，OpenAI Agents SDK、OpenAI Responses API remote MCP、多个开发工具和 AI IDE 都已经支持或兼容 MCP。它正在从某个厂商生态扩展为更广泛的 Agent 工具连接标准。

未来趋势

1. 从工具调用到工具市场

当越来越多工具以 MCP server 形式发布，开发者会希望像安装包一样安装工具。未来 MCP 生态可能会出现更成熟的 registry、权限说明、评分、审计和企业白名单。

工具市场的关键不是数量，而是可信度。一个高权限 MCP server 必须能被审查。

2. 企业级权限和治理

企业使用 MCP 时，最重要的问题不是“能不能连”，而是“谁能连什么、能做什么、是否可审计”。

未来企业 MCP 平台会更重视：

• OAuth 和细粒度授权；
• 用户身份透传；
• 数据访问策略；
• 工具调用审计；
• 敏感操作审批；
• server 白名单；
• 日志回放和合规报告。

3. MCP 与 Agent 平台深度融合

Agent 要完成任务，需要工具和上下文。MCP 会成为 Agent 平台连接外部世界的重要基础层。

未来 Agent 平台可能会内置 MCP server 管理、工具过滤、权限审批、调用 trace、成本统计和安全扫描。

4. 多模态资源和 UI 扩展

MCP resources 和 prompts 已经支持文本、图片、音频等内容形式。随着多模态 Agent 发展，MCP 可能更多用于传递截图、图表、音频、视频片段和结构化 UI 状态。

这会让 MCP 从“工具协议”进一步扩展到“上下文协议”。

5. 安全攻防会变得更重要

MCP 把模型和真实工具连接起来，也扩大了攻击面。未来需要重点关注：

• prompt injection；
• 工具描述投毒；
• 恶意 server；
• 本地命令执行风险；
• 数据外泄；
• 越权调用；
• 工具结果污染；
• supply chain 风险。

MCP 的普及会让 AI 应用安全从“模型输出安全”扩展到“模型、工具、权限、数据和执行环境的整体安全”。

小结

• MCP 是 Model Context Protocol，一个用于标准化 AI 应用连接工具、数据源和上下文的开放协议。
• 它由 Anthropic 在 2024 年 11 月发布，截至 2026 年已捐赠给 Linux Foundation 旗下 Agentic AI Foundation。
• MCP 采用 host-client-server 架构，host 负责协调和安全边界，client 维护 server 连接，server 暴露能力。
• MCP server 主要暴露三类原语：Prompts、Resources、Tools。
• Tools 偏模型控制，用于执行动作；Resources 偏应用控制，用于提供上下文；Prompts 偏用户控制，用于可复用模板。
• MCP 不等于 Function Calling、RAG、Plugin 或 Agent，但可以和它们组合。
• MCP 的价值在于复用工具连接、降低集成碎片化、支持 Agent 使用外部系统。
• MCP 不会自动保证安全，高权限 server 必须有权限控制、人工确认、日志和审计。
• 未来 MCP 会向工具生态、企业治理、Agent 平台集成、多模态上下文和安全标准演进。

参考资料

• Anthropic, Introducing the Model Context Protocol, 2024: https://www.anthropic.com/news/model-context-protocol
• Model Context Protocol, Official Documentation: https://modelcontextprotocol.io/
• Model Context Protocol, Architecture, 2025-06-18 specification: https://modelcontextprotocol.io/specification/2025-06-18/architecture
• Model Context Protocol, Server Features Overview, 2025-06-18 specification: https://modelcontextprotocol.io/specification/2025-06-18/server
• Model Context Protocol, Tools, 2025-06-18 specification: https://modelcontextprotocol.io/specification/2025-06-18/server/tools
• Model Context Protocol, Resources, 2025-06-18 specification: https://modelcontextprotocol.io/specification/2025-06-18/server/resources
• Model Context Protocol, Prompts, 2025-06-18 specification: https://modelcontextprotocol.io/specification/2025-06-18/server/prompts
• Model Context Protocol GitHub Repository: https://github.com/modelcontextprotocol/modelcontextprotocol
• OpenAI Agents SDK, Model context protocol (MCP): https://openai.github.io/openai-agents-python/mcp/
• OpenAI API Docs, MCP and Connectors: https://developers.openai.com/api/docs/guides/tools-connectors-mcp
• OpenAI, New tools and features in the Responses API, 2025: https://openai.com/index/new-tools-and-features-in-the-responses-api/
• Anthropic, Donating the Model Context Protocol and establishing the Agentic AI Foundation, 2025: https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation