简介
MCP（全称为Model Context Protocol，模型上下文协议）是一种面向大模型交互过程的通用上下文协议标准。其核心目标在于为模型构建一个结构化、可控、可扩展的语义执行环境，使语言模型能够在统一的上下文管理体系下进行任务调度、工具调用、资源协作与状态保持，从而突破传统Prompt Engineering在多轮交互、指令组合与行为稳定性方面的瓶颈。
在传统的大模型应用中，模型本身只能被动地接收输入、产生输出，要让它调用外部工具或访问自定义的上下文，就需要在代码里逐条写好 API 调用、认证、错误处理的逻辑，既繁琐又难以维护。MCP的初衷，就是将这些”上下文管理”和”工具调用”能力抽象成一个标准化的通信协议，让大模型应用只需关注”我想用什么资源”，由专门的 MCP 服务端来真正执行调用、管理状态、返回结果。
MCP 官方GitHub
有一种说法是，传统的大模型应用叫做Prompt Engineering，而MCP出现后，大模型应用开发应该叫做Context Engineering。传统的提示工程常常依赖于简单的字符串拼接，这种方式有几个问题：
- 歧义性：模型可能难以区分哪些是指令，哪些是用户输入，哪些是检索到的数据。
- 提示注入风险：如果提示中包含恶意指令，例如ignore all previous instructions，模型可能被欺骗。
- 脆弱性：格式的微小变化（比如多一个换行符）都可能导致模型性能下降。
- 难以维护：当上下文变得更复杂时（例如，多个数据源、工具定义、历史消息），这种拼接方式会变得一团糟（亲身体验，塞了一堆历史消息后，模型的回答越拐越远）
核心概念
Tools（工具）
工具是AI模型可以调用以执行特定操作的函数。它们允许模型与外部系统交互，执行有副作用的操作，如：
- 调用API获取实时数据
- 查询或修改数据库
- 执行代码或脚本
- 发送邮件或消息
- 文件操作
工具由模型控制，这意味着AI决定是否以及何时使用它们。工具调用可能会产生副作用，其结果可以反馈到对话中。
sequenceDiagram participant l as LLM participant c as Client participant s as Server Note over c,s: Discovery c ->> s: tools/list s –>> c: List of tools Note over l,c: Tool Selection l ->> c: Select tool to use Note over c,s: Invocation c ->> s: tools/call s –>> c: Tool result c ->> l: Process result Note over c,s: Updates s –>> c: tools/list_changed c ->> s: tools/list s –>> c: Updated tools
Resources（资源）
资源是提供给模型的只读上下文单元（数据源）。它们可以是：
- 文件内容
- 数据库记录
- API响应
- 知识库内容
资源由应用程序控制，托管方或开发人员决定公开哪些数据以及如何公开。读取资源没有副作用，类似于仅获取数据的GET请求。资源提供可在需要时注入模型上下文的内容（例如，在问答场景中检索到的文档）。
Prompts（提示模板）
提示模板是可重复使用的提示模板或指令，可以根据需要调用。它们由用户控制或由开发人员预定义。提示可能包含常见任务或指导性工作流程的模板（例如，代码审查模板或问答格式）。
提示模板的关键特性包括：
- 参数化：支持动态参数输入
- 资源整合：可嵌入资源上下文供模型参考
- 多轮交互：支持构建多轮对话流程
- 统一发现：通过标准接口注册和调用
Sampling（采样）
采样是工具与LLM交互以生成文本的机制。通过采样，工具可以请求LLM生成文本内容，例如生成诗歌、文章或其他文本内容。采样允许工具利用LLM的能力来创建内容，而不仅限于执行预定义的操作。
Elicitation（征询）
征询是一种允许工具向用户请求额外信息或确认的机制。当工具执行过程中需要更多信息才能继续执行时，可以使用征询功能与用户交互。这在处理需要用户确认或提供额外参数的操作时特别有用。
例如，在预订系统中，如果用户请求的日期已满，工具可以征询用户是否愿意选择其他日期。征询机制确保了工具可以在必要时暂停执行，等待用户输入，从而提供更好的用户体验。
征询的关键特性包括：
- 交互性：允许工具与用户进行双向沟通
- 验证：可以对用户输入进行验证，确保数据的正确性
- 可选性：用户可以选择接受、拒绝或取消征询请求
- 结构化：支持结构化数据输入，便于处理复杂信息
Roots（根）
Root表示一次语义执行的起点，携带资源引用、执行目标、响应格式等信息，支持多并发执行流。它作为语义执行的基础输入结构，可以包含多个Prompt和工具，为模型提供完整的上下文环境。
Logging（日志记录）
日志记录是MCP中的一个重要功能，允许服务器和工具向客户端发送日志信息。通过日志记录，开发者可以跟踪工具执行过程、调试问题以及监控系统状态。MCP支持多种日志级别，包括调试(debug)、信息(info)、警告(warning)和错误(error)等。
Notifications（通知）
通知机制允许服务器向客户端发送实时更新信息，例如资源变更、工具列表更新等。通过通知，客户端可以及时了解服务器状态的变化，并相应地更新用户界面或执行其他操作。常见的通知类型包括资源更新通知、工具列表变更通知、提示列表变更通知等。
组件
MCP Server
Server 是一个独立的程序或服务，它通过 MCP 协议向 MCP 客户端暴露特定的功能、工具或数据资源。
角色职责：
- 提供工具/资源：MCP Server 是外部能力（如数据库、API、文件系统、计算服务等）的封装器或适配器。它将这些外部能力以标准化、可供大模型调用的形式暴露出来。
- 执行操作：当接收到 MCP Client 的请求时，MCP Server 负责执行底层操作（例如，查询数据库、调用第三方 API、执行代码等）。
- 返回结果：将执行结果返回给请求它的 MCP Client。
- 独立部署：MCP Server 可以运行在本地机器上，也可以部署在远程服务器上。
MCP Host
Host 是用户直接交互的应用程序或环境。它通常是AI应用程序的入口点，比如：
- 一个聊天机器人界面
- 一个IDE
- 一个自定义的AI代理应用程序
角色职责:
- 用户交互：接收用户的请求和输入，并向用户显示大模型生成的响应。
- 协调与编排：负责整个工作流的协调和编排。它决定何时调用大模型，何时需要外部工具或数据，以及如何将它们的结果整合起来。
- 管理客户端：Host 创建并管理一个或多个 MCP 客户端实例。
- 维护核心上下文：通常由 Host 来维护整个对话历史和应用程序的全局上下文，而不是将所有信息都暴露给单个服务器。
- 安全边界：强制执行客户端和服务器之间的安全边界和权限控制。
MCP Client
Client 是内置在 Host 应用程序中的一个组件，它作为 Host 和 MCP Server 之间的桥梁。一个Host内可以有多个Client。
角色职责：
- 协议转换：将 Host 的请求转换成MCP协议定义的标准格式，以便MCP Server能够理解。同时，它也将MCP Server的响应转换成Host可用的格式。
- 会话管理：与一个特定的MCP Server建立并维护一对一的连接和会话生命周期。
- 能力协商：在建立连接时，与MCP Server协商双方支持的能力和协议版本。
- 消息路由：负责在Host和其Server之间双向路由消息。
- 安全与认证：可以处理与MCP Server之间的认证和授权，确保只有授权的请求才能到达服务器。
京ICP备14020293号-4