MCP 由哪几部分组成？一篇讲透组件分工

很多人第一次看 MCP，会把它理解成“AI 调工具”。这个说法没错，但太粗了。因为 MCP 不是单个函数调用能力，而是一套协议：它规定 AI 应用、连接模块、外部服务之间怎么建立连接，怎么发现能力，怎么传输消息，怎么控制权限。

MCP 要解决的不是“模型会不会调用函数”，而是“一个 AI 应用如何稳定、安全、可复用地连接外部世界”。只要抓住这个问题，MCP 的组件就很好理解。

一、先建立全局视角：MCP 可以拆成三层

MCP 的组成可以先按三层来看：第一层是角色层，解决谁和谁通信；第二层是能力层，解决 Server 能暴露什么；第三层是协议层，解决消息怎么传。除此之外，所有层外面还要包一层安全边界。

这比单纯说“Client + Server”更准确。因为在 MCP 里，Host 和 Client 不是一回事，Tools、Resources、Prompts 也不是一回事。把这些概念混在一起，后面讲安全、权限、调试、部署都会出问题。

二、第一层：角色架构，Host / Client / Server

角色层是理解 MCP 的入口。MCP 官方规范把通信对象拆成 Host、Client、Server 三类：Host 是 AI 应用本身，Client 是 Host 内部负责连接某个 Server 的模块，Server 是真正提供工具、资源和模板的外部能力方。

可以用公司合作来类比：Host 是公司总部，决定要接哪些外部供应商；Client 是派出去的对接人，一个对接人负责一个供应商；Server 是外部供应商，提供具体能力。总部不会直接和所有供应商乱连，而是通过标准化的 Client 连接去管理。

Host：宿主应用，比如 Claude Desktop、Cursor、VS Code 插件、自研 Agent 平台，负责 UI、模型上下文、权限确认和连接管理。

Client：Host 里面的连接模块，一个 Client 通常维护一条与某个 MCP Server 的会话，负责初始化、能力发现和消息转发。

Server：能力提供方，可以是本地进程，也可以是远程服务，负责暴露 Tools、Resources、Prompts 等能力。

注：一个 Host 可以同时连接多个 Server。比如一个开发者在 Cursor 里同时接 GitHub Server、文件系统 Server、数据库 Server，模型就能在同一个对话里读代码、查数据库、开 PR，但每个 Server 仍然通过独立连接和独立权限边界管理。

三、第二层：Server 能力，Tools / Resources / Prompts

很多人会把 MCP Server 暴露的所有东西都叫“工具”。这不准确。MCP Server 主要暴露三类能力：Tools、Resources、Prompts。三者的差别非常大，尤其是 Tools 和 Resources，前者会改变外部世界，后者只是提供只读上下文。

1. Tools：让模型执行动作

Tools 是最接近 Function Calling 的部分。它代表一个可执行动作，比如查询天气、写文件、发 Slack 消息、创建 GitHub Issue、调用数据库查询接口。模型可以根据用户意图选择某个 Tool，并生成结构化参数。

但 Tools 最大的特点是“可能有副作用”。读一下天气没什么风险，删除文件、发邮件、下单、转账就必须严格控制。所以生产环境里，Tools 不能裸奔，至少要做工具白名单、参数校验、用户确认和审计日志。

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/list",
    "params": {

    }
}

{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
        "name": "get_weather",
        "arguments": {
            "location": "Shanghai"
        }
    }
}

2. Resources：给模型提供只读上下文

Resources 是“资料室”。它不负责执行动作，而是把上下文交给模型看。比如读取项目 README、读取数据库 schema、读取日志文件、读取某个文档片段。Resources 的重点是只读，不应该修改外部状态。

这类能力非常适合 RAG、代码助手、企业知识库。比如模型要理解一个项目，不一定要调用“read_file”工具乱翻文件，也可以由 Server 暴露一组 Resource，Host 决定哪些资源可以放进上下文。

{
    "jsonrpc": "2.0",
    "id": 3,
    "method": "resources/read",
    "params": {
        "uri": "file:///project/README.md"
    }
}

3. Prompts：沉淀可复用提示模板

Prompts 是“模板库”。它不是让模型直接调用 API，也不是单纯读取数据，而是把团队常用的提示词、工作流、最佳实践封装成模板。比如代码审查模板、接口文档生成模板、周报模板、SQL 优化模板。

Prompts 通常由用户主动选择，类似斜杠菜单。这样做的好处是团队经验可以复用，输出风格更稳定，不用每个人都手写一遍长 Prompt。

{
    "jsonrpc": "2.0",
    "id": 4,
    "method": "prompts/get",
    "params": {
        "name": "code_review",
        "arguments": {
            "language": "Java",
            "code": "public class Demo { ... }"
        }
    }
}

四、补充最新版：Client 也能提供能力

如果只讲 Server 侧的 Tools、Resources、Prompts，还不够完整。MCP 是双向协议，官方最新版规范里 Client Features 也很重要，主要包括 Roots、Sampling、Elicitation。

1. Roots：告诉 Server 能访问哪里

Roots 用来定义 Server 可以操作的边界。比如在 IDE 场景里，Host 可以告诉文件系统 Server：你只能看当前项目目录，不能访问用户整个磁盘。这个能力非常关键，因为它把“权限最小化”从口号变成了协议层的边界。

生产环境里不要把用户 home 目录、根目录、密钥目录直接暴露给 Server。正确做法是按项目、按工作区、按任务范围暴露 Roots。

2. Sampling：Server 反向请求 Client 调模型

Sampling 听起来绕，其实很简单：Server 有时候也想让模型帮它做一步判断，但它不应该自己拿模型 API Key 去调用。MCP 的设计是让 Server 向 Client 发起采样请求，由 Client 来控制模型选择、权限、提示词审核和用户确认。

这样 Server 可以拥有更强的智能流程，但模型入口仍然掌握在 Host / Client 手里，不会变成每个 Server 私自调用模型。

3. Elicitation：Server 需要补信息时向用户追问

Elicitation 是“补参数机制”。如果 Server 执行任务时发现缺少信息，比如需要用户选择一个项目、填写一个非敏感参数、确认一个选项，就可以通过 Client 请求用户输入。

这里要注意安全边界：官方规范要求敏感信息不能随便通过普通表单模式收集。密码、API Key、访问令牌、支付凭证这类敏感信息，应走更安全的 URL 模式或外部授权流程。

五、第三层：协议层，JSON-RPC + 生命周期 + 传输

角色和能力只是“谁提供什么”，真正让它跑起来的是协议层。MCP 底层使用 JSON-RPC 2.0 消息格式，所有请求、响应、通知都按统一 JSON 结构传递。

请求里有 method 和 params，表示要做什么、参数是什么；响应里有 result 或 error，表示成功结果或失败原因；通知没有 id，表示只发不回，比如某个资源列表更新了。

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
        "protocolVersion": "2025-11-25",
        "capabilities": {
            "roots": {
                "listChanged": true
            },
            "sampling": {

            },
            "elicitation": {

            }
        },
        "clientInfo": {
            "name": "ExampleClient",
            "version": "1.0.0"
        }
    }
}

六、连接不是直接调用，而是先初始化和能力协商

MCP 不是连上就开始调工具。正确流程是先 initialize，协商协议版本和双方能力；然后 Client 发送 initialized 通知；之后才进入正常操作阶段，开始 tools/list、resources/list、prompts/list，以及后续调用。

这个设计很像两家公司合作前先签接口清单：我支持哪些能力，你支持哪些能力，版本是否兼容，哪些功能可以用，哪些功能不能用。协商清楚以后，后续调用才不会乱。

七、传输层：本地用 stdio，远程用 Streamable HTTP

MCP 把消息格式和传输方式解耦。同一套 JSON-RPC 消息，可以走本地 stdio，也可以走远程 Streamable HTTP。

stdio：Client 启动 Server 作为本地子进程，Server 从 stdin 读消息，从 stdout 写消息。适合本地文件、IDE 插件、个人脚本。

Streamable HTTP：Server 独立部署为 HTTP 服务，通过单个 MCP endpoint 接收 POST/GET，适合团队共享、云端系统、企业数据服务。

旧版 HTTP+SSE 是双端点方案，新版 Streamable HTTP 更适合单端点、负载均衡、Serverless 和远程部署。

八、落地时最容易踩的 6 个坑

MCP 组件看起来清楚了，但真正落地时，问题往往不在协议字段，而在安全边界和工程治理。尤其是企业场景，不能因为 Server 会暴露 Tools，就把所有 Tools 都交给模型自动调用。

把 Host 和 Client 混为一谈：Host 是应用，Client 是连接模块。一个 Host 可以管理多个 Client。

把 Resources 当 Tools：Resources 应该只读；如果会修改状态，就应该设计成 Tool，并加确认。

工具过多不分组：模型看到几十个 Tool，选择准确率会下降，应按场景分组、按任务动态暴露。

Roots 给太大：文件系统类 Server 不能默认全盘权限，应按工作区最小授权。

忽略 Prompt Injection：Server 返回的资源和提示模板都可能带恶意指令，Host 要做隔离和过滤。

没有审计：生产环境必须记录 Server、Tool、参数、结果、用户确认、错误信息和耗时。

九、面试怎么一句话讲清楚？

MCP 由角色层、能力层、协议层和安全层组成。角色层包括 Host、Client、Server；Server 能暴露 Tools、Resources、Prompts；Client 也能提供 Roots、Sampling、Elicitation；协议层使用 JSON-RPC 2.0，通过生命周期协商能力，通过 stdio 或 Streamable HTTP 传输消息；生产环境还要加授权、确认、权限最小化和审计。

MCP 就是 AI 应用连接外部世界的标准插座，Host 负责调度，Client 负责通信，Server 负责提供能力，Tools 做动作，Resources 给上下文，Prompts 沉淀模板，JSON-RPC 和传输层负责把这一切稳定地跑起来。