什么是MCP协议？ - 代码学习笔记

一、什么是MCP协议？

MCP（Model Context Protocol，模型上下文协议）是一个开放标准协议，旨在为大型语言模型（LLM）提供一种标准化的方式，去访问外部的数据源、工具和功能。你可以把它想象成AI应用的“万能适配器”或“USB接口”。在没有统一协议之前，每个AI应用想要连接数据库、调用API或读取本地文件，都需要写一套定制化的连接代码，过程繁琐且无法复用。

MCP的核心思想是解耦。它将“AI模型如何思考”与“AI模型如何与世界互动”分离开来。模型本身专注于推理和生成，而通过MCP，它可以动态地、安全地调用一个由“MCP服务端”提供的各种工具（Tool）和数据资源（Resource），就像给模型装上了可随时插拔的手脚和眼睛。

二、MCP的核心架构与角色

MCP采用经典的客户端-服务器架构，但这里的“客户端”特指发起请求的AI应用（如一个聊天机器人或自动化代理），而“服务端”则是提供具体能力的程序。理解这个架构是掌握MCP的关键。

一个完整的MCP交互涉及三个核心角色：

MCP客户端：通常是承载大模型的应用程序（Host），例如IDE插件、聊天界面或自动化脚本。它负责理解用户意图，并决定是否以及如何调用MCP服务。
MCP服务端：一个独立运行的进程，对外暴露具体的工具（Tool）和资源（Resource）。例如，一个连接GitHub的服务端可以提供“创建Issue”、“查询代码仓库”等工具。
大语言模型：核心推理引擎。它根据上下文生成需要调用工具的指令（如JSON-RPC格式的调用请求），并理解工具返回的结果。

提示：MCP协议本身并不直接与大模型交互，它定义的是客户端与服务端之间的通信标准。客户端收到模型的工具调用指令后，再通过MCP协议与正确的服务端通信。

三、一个简单的代码示例

理论比较抽象，我们通过一个简化的Python代码示例来看MCP服务的定义和调用流程。以下是一个使用MCP SDK的伪代码示例，展示如何创建一个提供“获取当前时间”工具的服务端。

# 示例：一个极简的MCP时间服务端 (server.py)
import datetime
from mcp.server import Server
from mcp.server.stdio import run_server
from mcp.types import Tool, TextContent

# 初始化MCP服务端
server = Server(name="time-server", version="0.1.0")

# 定义工具
@server.tool()
def get_current_time(timezone: str = "UTC") -> TextContent:
    """获取指定时区的当前时间"""
    if timezone == "UTC":
        now = datetime.datetime.utcnow()
    else:
        # 简化处理，实际需用pytz等库
        now = datetime.datetime.now()
    return TextContent(type="text", text=f"当前时间是: {now.strftime('%Y-%m-%d %H:%M:%S')}")

# 运行服务端（通常通过标准输入输出通信）
if __name__ == "__main__":
    run_server(server)

在客户端侧，当大模型判断需要获取时间时，它会生成一个工具调用请求。客户端解析后，会通过MCP协议连接到上述服务端并执行get_current_time函数，再将结果返回给模型继续推理。

四、MCP的典型应用场景与优势

MCP的价值在于将碎片化的AI能力连接起来，形成强大的生态。其典型应用场景包括：

本地数据访问：让AI安全地读取用户电脑上的文档、数据库或日志文件，进行分析总结。
API集成：统一封装各种第三方API（如Slack、Jira、电商平台），AI模型只需描述意图，无需关心具体接口细节。
开发工具链：在IDE中，AI可以通过MCP服务操作Git、运行测试、查询文档，成为真正的开发伙伴。

它的主要优势体现在：

标准化与互操作性：不同厂商开发的MCP服务可以无缝接入任何支持MCP协议的客户端应用。
安全与可控：权限管理集中在服务端，客户端/模型无法越权访问。用户可以在客户端明确授权使用哪些服务。
可发现性与动态性：客户端可以在运行时发现并列出服务端提供的所有工具，模型可以动态选择最合适的一个。

五、MCP与传统API/Function Calling的区别

很多人会问，这和OpenAI的Function Calling或者直接调用API有什么本质区别？最大的区别在于上下文与状态。

传统的Function Calling通常是无状态的单次调用。模型发出一个调用指令，得到一个结果，交互就结束了。而MCP设计用于维护一个有状态的上下文会话。客户端和服务端之间可以建立持久连接，进行多次交互。例如，一个“数据库查询服务”可以先执行一个查询，将结果集缓存在会话中，然后模型可以要求“对上次的结果做分页”或“计算总和”，而无需重新传输整个数据集。

此外，MCP强调资源的抽象化。它不仅提供工具（执行动作），还提供资源（只读数据）。模型可以像浏览文件系统一样，先列出服务端有哪些可用的资源和工具，再决定下一步操作，这更接近人类使用工具的方式。

提示：可以将MCP的会话理解为一次“远程结对编程”，模型是思考者，MCP服务是拥有各种具体技能的操作员，双方通过协议紧密协作完成复杂任务。

六、展望与学习建议

MCP协议仍处于快速发展阶段，但它代表了AI应用工程化的一个重要方向：从追求单一模型的强大，转向构建模型与工具协同的智能系统。未来，我们可能会看到“MCP服务市场”，开发者可以像发布手机应用一样，发布各种垂直领域的MCP服务。

对于想要学习和实践MCP的开发者，我的建议是：

动手跑通官方示例：先从最简单的示例开始，理解客户端、服务端和模型三方的数据流转。
尝试封装一个现有API：把你经常使用的一个API（如天气查询、翻译）封装成MCP服务，这是最好的学习方式。
关注安全与边界：在设计服务时，务必思考工具的权限范围和数据过滤，防止提示注入攻击。

MCP不仅仅是一个技术协议，它更是在塑造一种新的人机协作范式。理解它，就是理解下一代AI应用是如何“长出手脚”并真正落地工作的。