36. MCP 技术协议的主体内容是什么？

难度 P1 高频 · 岗位应用 · 频率 ★★★★☆ · 预计阅读 8 min 公司 Anthropic 相关题 Q34 MCP 简介 · Q35 MCP 作用 · Q40 MCP 实践

本题阅读地图

面试场景还原 — 1 min
TL;DR 速记 — 30 sec
图解 — 30 sec
详细解析 — 5 min
- 4.1 MCP 协议设计背景
- 4.2 四层架构详解
- 4.3 三种能力类型与控制权
- 4.4 通信机制与生命周期
- 4.5 MCP vs 传统 Function Calling
常见踩坑与反例 — 1 min
面试官可能继续追问 — 1 min

面试场景还原

👔面试官：你知道 Anthropic 提出的 MCP 协议吗？它主要解决什么问题？

🙋‍♂️我：MCP 是 Model Context Protocol，让 LLM 可以调用外部工具。就像给 Claude 装插件一样。

👔面试官：对，但这只是表面。MCP 不只是"插件协议"，它定义了标准化的角色分工和能力类型。你知道 MCP 协议的主体结构吗？

🙋‍♂️我：有 Tools、Resources、Prompts 三种能力类型？

👔面试官：很好。但关键问题是：这三种能力的控制权分别属于谁？ Tools 由模型决定是否调用，Resources 由应用决定何时读取，Prompts 由用户选择使用。这个控制权的设计是 MCP 的核心思想。

TL;DR 速记

MCP 是什么：Anthropic 提出的开放协议，标准化 LLM 与外部能力的集成
四层架构：参与角色（Host/Client/Server）→ 能力类型（Tools/Resources/Prompts）→ 通信机制 → 传输方式
控制权设计：Tools（模型控制）、Resources（应用控制）、Prompts（用户控制）
通信机制：JSON-RPC 2.0，支持能力发现、请求响应、通知推送
核心价值：解耦 LLM 应用与工具实现，构建可插拔的生态系统

图解

图 1：MCP 四层架构

图 2：三种能力类型的控制权对比

详细解析

MCP 协议设计背景

问题背景：

传统 Function Calling 是模型厂商私有的（OpenAI 的函数调用格式与 Claude 不同）
每个 LLM 应用都要为不同工具写不同的适配代码
工具开发者需要为每个模型单独实现接口

MCP 的解决方案：

定义开放、标准化的协议
解耦 LLM 应用与工具实现
构建可插拔的工具生态系统

类比理解：

USB 协议统一了外设接口，MCP 统一了 LLM 与外部能力的接口
就像浏览器插件生态，MCP 构建 LLM 应用的工具生态

四层架构详解

第一层：参与角色（Roles）

角色	职责	示例
Host	AI 应用，提供交互环境	Claude Desktop、IDE、ChatUI
Client	Host 内的 MCP 客户端组件	与 Server 建立连接、管理会话
Server	暴露能力的服务端	文件系统服务、数据库服务、API 服务

角色关系：

Host (AI应用)
  └── Client (MCP客户端)
        └── 连接多个 Server (能力提供方)
              ├── FileSystem Server
              ├── Database Server
              └── GitHub Server

第二层：能力类型（Primitives）

能力	描述	控制权	典型场景
Tools	模型可调用的函数	模型控制	搜索、计算、发送邮件
Resources	应用可读取的数据	应用控制	文件内容、数据库记录
Prompts	可复用的提示模板	用户控制	代码审查模板、分析模板

第三层：通信机制（Communication）

基于 JSON-RPC 2.0：

能力发现（Discovery）

json

// Client 查询 Server 能力
{
  "jsonrpc": "2.0",
  "method": "tools/list",
  "id": 1
}

// Server 返回能力列表
{
  "jsonrpc": "2.0",
  "result": {
    "tools": [
      {
        "name": "search",
        "description": "搜索网络",
        "inputSchema": {...}
      }
    ]
  },
  "id": 1
}

请求/响应（Request/Response）

json

// 调用 Tool
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {"query": "MCP protocol"}
  },
  "id": 2
}

通知（Notifications）
- Server 主动推送更新
- 资源变更通知
- 进度通知

第四层：传输方式（Transports）

传输方式	适用场景	特点
stdio	本地进程间通信	安全、低开销、适合本地工具
HTTP	远程网络通信	标准、易扩展、适合云服务
Streamable HTTP	需要流式响应	SSE 推送、实时更新

三种能力类型与控制权

Tools（工具）- Model Controlled

python

# Server 定义 Tool
@mcp.tool()
def search_web(query: str) -> str:
    """搜索网络获取信息"""
    return search_engine.query(query)

# 模型决定是否调用
# LLM 推理："用户问天气，需要搜索" → 生成调用请求

控制权归属：LLM 模型
决策内容：是否调用、调用哪个、参数填充
触发方式：模型在推理过程中自主决定

Resources（资源）- Application Driven

python

# Server 定义 Resource
@mcp.resource("file://{path}")
def read_file(path: str) -> str:
    """读取文件内容"""
    return file_system.read(path)

# 应用决定何时读取
# 例如：用户打开文件时，应用主动读取 resource 进上下文

控制权归属：Host 应用
决策内容：何时读取、怎么呈现、是否进上下文
触发方式：应用逻辑控制，不由模型直接调用

Prompts（提示模板）- User Controlled

python

# Server 定义 Prompt
@mcp.prompt()
def code_review_prompt(code: str) -> str:
    """代码审查模板"""
    return f"请审查以下代码的质量和安全性：\n\n{code}"

# 用户选择使用
# 用户在 UI 上选择 "代码审查" 模板，填充代码

控制权归属：终端用户
决策内容：选择哪个模板、填充什么变量
触发方式：用户主动选择使用

通信机制与生命周期

连接生命周期：

1. 初始化（Initialization）
   Client ──→ Server: 协议版本、能力协商
   Server ──→ Client: 确认连接、返回 Server 信息

2. 能力发现（Discovery）
   Client ──→ Server: 查询 Tools/Resources/Prompts
   Server ──→ Client: 返回能力清单

3. 正常运行（Operation）
   - Tools: 模型决定调用 → Client 转发 → Server 执行 → 返回结果
   - Resources: 应用决定读取 → Client 请求 → Server 返回
   - Prompts: 用户选择 → Client 获取 → 填充变量

4. 断开连接（Teardown）
   Client ──→ Server: 关闭通知
   Server: 清理资源

错误处理机制：

json

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32602,
    "message": "Invalid params",
    "data": {
      "details": "Missing required parameter: query"
    }
  },
  "id": 2
}

标准错误码：

-32700: Parse error
-32600: Invalid Request
-32601: Method not found
-32602: Invalid params
-32603: Internal error

MCP vs 传统 Function Calling

对比维度	MCP	传统 Function Calling
标准化	开放协议，跨模型兼容	厂商私有，各模型不同
角色分离	明确的 Host/Client/Server 分工	应用与模型耦合
能力类型	Tools + Resources + Prompts	只有 Functions
控制权	明确区分 model/app/user	主要是模型控制
生态建设	工具可复用、可共享	每个应用单独实现
传输方式	支持 stdio/HTTP/流式	通常是 HTTP

核心区别：

Function Calling 是模型能力，解决"模型怎么调工具"
MCP 是应用架构协议，解决"应用怎么集成工具、数据、模板"

常见踩坑与反例

踩坑 1：把 MCP 当成简单的"插件市场"

错误理解： "MCP 就是给 Claude 装插件，和 Chrome 插件差不多。"

问题：

忽略了协议的分层设计
不理解控制权分离的重要性
把 Resources/Prompts 也当 Tools 用

正确理解： MCP 是应用架构协议，定义了标准化的集成方式，不只是插件机制。

踩坑 2：混淆三种能力的控制权

错误做法：

把 Resources 设计成模型可调用的（应该是应用控制）
让 Tools 的调用由应用决定（应该由模型决定）
Prompts 自动填充不由用户选择

正确做法：严格遵循控制权设计：Tools（模型）、Resources（应用）、Prompts（用户）。

踩坑 3：Server 实现不规范

错误做法：

不实现完整的能力发现协议
错误处理不规范
不通知资源变更

正确做法：严格按照 MCP 规范实现 Server，支持完整的生命周期管理。

踩坑 4：忽视安全性

错误做法：

Server 可以任意访问文件系统，无权限控制
不验证 Client 身份
敏感操作无确认

正确做法：

最小权限原则
用户授权机制
敏感操作确认

踩坑 5：一个 Server 做太多事

错误做法：一个 MCP Server 实现了搜索、文件操作、数据库查询、邮件发送等所有功能。

问题：

职责不清
难以维护和复用
权限难以控制

正确做法：一个 Server 专注一类能力，如 FileSystem Server、Search Server、Email Server。

面试官可能继续追问

追问 1：MCP 和 LangChain 的 Tools 有什么区别？ 答题要点：MCP 是标准化协议，LangChain 是开发框架；MCP 跨模型兼容，LangChain Tools 主要是 OpenAI/Anthropic 格式；两者可以结合使用（LangChain 可以接入 MCP Server）。
追问 2：如果要做一个企业内部的 MCP Server，要注意什么？ 答题要点：权限控制（谁可以调用什么）；审计日志（记录所有调用）；错误处理（企业级稳定性）；版本管理（向后兼容）；文档和发现（便于其他团队使用）。
追问 3：MCP 的 Resources 和 RAG 有什么区别？ 答题要点：Resources 是实时读取（如文件当前内容），RAG 是预索引检索；Resources 适合动态数据，RAG 适合静态知识库；两者可以结合：Resource 读取后做 RAG 检索。
追问 4：MCP 协议的未来发展方向？ 答题要点：更多模型支持（不只是 Claude）；标准化的 Server 市场/商店；安全机制的完善（OAuth、权限细化）；性能优化（流式、批量调用）。

面试总结

MCP 协议是 LLM 应用架构的重要创新。面试时强调三点：

四层架构：角色（Host/Client/Server）→ 能力（Tools/Resources/Prompts）→ 通信（JSON-RPC）→ 传输（stdio/HTTP）
控制权设计：Tools（模型控制）、Resources（应用控制）、Prompts（用户控制）——这是 MCP 的核心思想
核心价值：标准化、解耦、生态——构建可插拔的 LLM 工具生态系统

记住：MCP 不只是 Function Calling 的包装，它是一套完整的应用架构协议，定义了 LLM 与外部世界交互的标准方式。

章节首页 · ← Q35 · Q37 →

36. MCP 技术协议的主体内容是什么？ ​

本题阅读地图 ​

面试场景还原 ​

TL;DR 速记 ​

图解 ​

图 1：MCP 四层架构 ​

图 2：三种能力类型的控制权对比 ​

详细解析 ​

MCP 协议设计背景 ​

四层架构详解 ​

三种能力类型与控制权 ​

通信机制与生命周期 ​

MCP vs 传统 Function Calling ​

常见踩坑与反例 ​

踩坑 1：把 MCP 当成简单的"插件市场" ​

踩坑 2：混淆三种能力的控制权 ​

踩坑 3：Server 实现不规范 ​

踩坑 4：忽视安全性 ​

踩坑 5：一个 Server 做太多事 ​

面试官可能继续追问 ​

面试总结 ​

36. MCP 技术协议的主体内容是什么？

本题阅读地图

面试场景还原

TL;DR 速记

图解

图 1：MCP 四层架构

图 2：三种能力类型的控制权对比

详细解析

MCP 协议设计背景

四层架构详解

三种能力类型与控制权

通信机制与生命周期

MCP vs 传统 Function Calling

常见踩坑与反例

踩坑 1：把 MCP 当成简单的"插件市场"

踩坑 2：混淆三种能力的控制权

踩坑 3：Server 实现不规范

踩坑 4：忽视安全性

踩坑 5：一个 Server 做太多事

面试官可能继续追问

面试总结