MCP模型上下文协议入门指南

可视化演示

动态演示MCP模型上下文协议入门指南的核心机制，通过全局/局部/动态/静态四种模式展示关键概念与交互流程。

一、MCP是什么：AI世界的USB-C

打开你家抽屉看看，是不是有一堆“充电线葬品”？Micro-USB、Lightning、圆头DC，还有不知道属于哪台设备的专用线……十年前每买一台设备就多一根线，桌面乱成一团。后来USB-C出现了，手机、平板、耳机、音箱统统用同一根线。一根线解决所有连接问题，世界从此清爽了。AI世界正在经历同样的“线缆混乱”：AI应用想查天气、搜网页、读数据库，传统做法是给每个工具单独写一段适配代码，本质上就是为每个“设备”配一根专属“充电线”。工具一多，适配代码成倍增长，每次对接新工具都要从头折腾。

MCP就是Anthropic在2024年提出的“AI版USB-C”：一套开放标准，让AI模型用同一个协议连接所有外部工具和数据源。在MCP之前，N个应用对接M个工具，需要N×M条专属适配；有了MCP，每方只需对接一次标准接口，连接数从乘法级降为加法级。工具方只实现一次MCP Server，就能被所有支持MCP的AI应用复用；AI应用只实现一次MCP Client，就能连接生态内的全部工具。这种解耦是MCP最核心的价值主张。

就像USB-C让“一根线走天下”，MCP让AI应用“一个接口连万物”。以后再遇到新工具，不必担心要写多少适配代码——只要对方实现了MCP，你的AI应用立刻就能“插上就用”。这正是MCP希望带给AI开发者的清爽体验。

二、核心架构：手机、数据线与设备接口

用USB-C充电时，其实有三个角色在配合：你的手机（需要电和数据的设备）、那根USB-C线（传输通道）、以及充电头或电脑（供电和数据的源头）。三者缺一不可。MCP的架构也精妙地分成三个角色，各司其职。

MCP的架构分为三层：Host（宿主应用）、Client（客户端）、Server（服务端）。Host就是AI应用本身，比如Claude Desktop、Cursor这类工具；Client负责与Server建立和维持连接，处理协议细节；Server部署在工具方，向外暴露数据和能力。用户可以感知到Host，看不到Client和Server的细节，就像你用USB-C充电时只看到手机和线，不会在意线缆内部的芯片协议。

技术实现上，三层之间通过JSON-RPC 2.0格式的消息进行通信。Host收到用户指令后交给模型推理，模型若决定调用某个工具，Host就把这个意图交给Client，Client将请求封装成标准协议消息发给Server，Server调用具体函数后把结果返回。消息传递路径是严格单向的：Host → Client → Server → Tool，每一层只和自己相邻的层通信，互不越界。

就像USB-C的插头、线缆和设备接口各司其职，MCP的三层架构让“谁负责什么”清清楚楚。工具方只需做好自己的Server，模型方只需关注Host和Client，中间通过标准协议交流，谁也不越界。这种分层设计让两端可以独立演进——服务器升级内部实现不影响客户端，客户端换模型也不影响服务器。

三、核心概念：Resource、Tool 与 Prompt

插上USB-C后，电脑能从这个设备读到什么？能对它做什么？USB-C规范里区分不同的“设备类型”：有的只提供数据读取，有的支持写操作，还有的是复合设备。MCP也定义了三种“能力类型”，让AI模型清楚地知道站在对面的是谁、能干什么。

MCP定义了三个核心原语：Resource（资源）、Tool（工具）、Prompt（提示模板）。Resource代表可读取的数据源，比如数据库查询结果、文件内容、API返回的数据；Tool代表可执行的操作，比如发送邮件、创建订单、运行代码；Prompt则是预设的提示词模板，方便复用常用交互模式。三者解决的问题不同：Resource让模型“查资料”，Tool让模型“动手做”，Prompt让模型“按套路说话”。

为什么要刻意区分Resource和Tool？因为读操作和写操作的安全要求完全不同。Resource是只读的，AI模型通过 resources/read 获取内容，可以被安全地开放给模型探索；Tool是可执行的，通过 tools/call 触发，必须经过严格的参数校验和权限控制。一个MCP Server可以同时暴露多个Resource和Tool，让模型既能查询上下文，又能实际操作。Tool本身用元数据描述“叫什么、有什么用、需要什么参数”，模型据此判断何时调用、怎么调用。

就像USB-C设备接入电脑后会自动“自我介绍”：我是硬盘、我是键盘、我是显示器。MCP的每个Server也向AI模型自报家门：这是只读数据（Resource）、这是可写接口（Tool）、这是现成话术（Prompt）。AI模型不必瞎猜，看一眼协议就知道怎么正确地使用对方。

四、工作流程：一次完整的插拔对话

你第一次把新U盘插上电脑，系统会做什么？先识别设备、读取它的描述信息，然后你才能看到里面有什么文件、能执行什么操作。MCP的交互流程也是这个“先识别、后使用”的逻辑，每一步都有清晰的协议消息对应。

一次完整的MCP交互分三个阶段：初始化（initialize）、工具发现（tools/list）、工具调用（tools/call）。初始化阶段，Client和Server相互确认协议版本与能力范围，协商出双方都支持的通信参数；工具发现阶段，Client向Server请求完整工具清单，Server返回每个Tool的元数据描述；工具调用阶段，Client把模型选中的工具请求发给Server，Server执行并返回结构化结果。

这些消息都是JSON-RPC 2.0格式。工具发现请求形如 {"jsonrpc":"2.0","method":"tools/list","id":1}，Server返回工具描述数组；工具调用请求形如 {"method":"tools/call","params":{"name":"toolName","arguments":{...}}}。整个过程有请求有响应，和HTTP一样是“一问一答”的同步模型。如果连接中断，Client会自动尝试重连并重新初始化——就像拔掉U盘再插上，系统会再次识别并挂载。

整个过程就像你插上U盘、双击打开、拷出文件——识别、发现、使用三步走。MCP把物理世界再熟悉不过的即插即用交互，翻译成了AI能理解的协议语言。U盘即插即用的体验，正是MCP想要带给AI工具生态的感受：工具接入零门槛，模型使用零学习成本。

五、对比Function Calling：专用线 vs 通用口

在USB-C普及之前，苹果有Lightning，安卓有Micro-USB，各有各的接口，线不是不能用，但换个品牌就得换根线。AI领域也是这样：OpenAI有Function Calling，谷歌有Function Call，各家大模型都有自己的“专用线”。它们都能解决问题，但换一家模型厂商，适配代码就要重写。

Function Calling是OpenAI在其模型API中提供的函数调用能力：你把函数描述作为参数传给模型，模型在回答中输出函数调用指令，然后由你的代码执行该函数。它很实用，但它是私有的——所有约定都绑定在OpenAI的API规范之上，换个模型就失效。MCP则是完全开放的协议标准，不属于任何单一厂商，协议文档公开、参考实现开源，任何模型只要实现了MCP客户端就能互通。

两者的核心区别有三个方面。第一是开放性：Function Calling是OpenAI生态内的私有协议，MCP是Anthropic提出并捐给社区的开放标准。第二是耦合度：Function Calling的请求格式、函数约束都嵌在模型API里，而MCP Server独立于任何模型，一次实现可以被Claude、GPT乃至开源模型通用。第三是生态配套：MCP自带工具发现（tools/list）、资源读取（resources/read）、提示模板（prompts/get）等标准能力，Function Calling需要开发者在应用层自己搭建这些基础设施。

USB-C之所以成功，是因为它不属于苹果也不属于安卓，而是行业共同认可的标准。MCP正在AI工具连接领域走同一条路——做一个“谁的线都能插”的通用接口，而不是某一家厂商的专用充电线。对开发者来说，这意味着你今天为MCP写的工具，明天换任何模型都能继续用，这是巨大的投资保护。

六、上手实践：亲手接第一根线

你用USB-C充电时其实不需要知道线缆内部怎么走线，插上就行。MCP上手也是这个体验：官方SDK把复杂的协议细节都封装好了，你只需要注册工具、启动服务，剩下的交给协议。

以Python为例，MCP官方提供了 mcp Python SDK，帮助开发者快速搭建Server。核心步骤只有三步：创建Server实例、注册Tool对象、运行Server。每个Tool对象包含名称、描述和实际的函数实现。SDK会自动处理JSON-RPC消息编解码、请求路由和错误处理，你完全不需要手写协议解析。

实际上，“注册工具”这个动作背后做的事情很有讲究：SDK把Tool的函数签名自动转换成JSON Schema，生成协议要求的元数据，然后维护一张工具名到函数实现的映射表。当Client发来 tools/list 请求时，SDK遍历这张表返回全部工具描述；收到 tools/call 请求时，SDK取出对应函数，把arguments解包成函数参数执行并返回结果。这种模式让“加一个新工具”的成本趋近于零——只需要多写一个普通的Python函数并注册进去。

就像买一根USB-C线插上就能用，MCP的SDK让工具方十分钟就能把现有代码变成标准协议服务。你不必理解协议里每一个字段的来龙去脉，SDK把“接线”的复杂工作全部干了。等你想深入了解时，再翻开协议文档，会发现那些曾经晦涩的术语已经在你写过的代码里一一对应上了。

七、生态与展望：万物皆可连

USB-C刚出现时，很多人觉得它不过是又一种充电口，直到苹果、三星、任天堂都开始采用，外设厂商纷纷跟进，USB-C才真正成为“万物皆可插”的国民标准。MCP正处在类似的爆发前夜。

从生态现状看，Anthropic开源了MCP规范与SDK后，社区迅速涌现出大量MCP Server：从数据库连接器、文件系统工具，到Gmail、Slack、GitHub、Stripe等常用服务的封装，npm上已经有数千个MCP相关包。OpenAI已宣布在其产品中支持MCP协议，Google的开发者工具也在跟进。这意味着MCP正在从Anthropic的“自家标准”演变为行业事实标准。

从发展动力看，MCP生态呈现典型的网络效应：接入的Server越多，AI应用选择MCP的意愿越强；支持MCP的AI应用越多，工具方发布Server的回报越大。这种正反馈一旦启动，MCP很可能成为AI Agent时代的“HTTP协议”——就像网页时代的HTTP让全世界的浏览器和服务器互通，MCP让全世界的AI模型与工具互通。

回顾USB-C的成功史：真正让它胜出的不是接口本身，而是围绕它建立起来的庞大生态。MCP正在AI领域复刻这条路径——当每个数据库、每款办公软件、每个云服务都有MCP Server时，AI就不再是“会聊天的机器人”，而是一个真正能动手干活的数字员工。那一天的到来，可能比你想象的更快。

AI 应用场景

Python 演示

"""MCP 核心模式模拟：客户端-服务端-工具调用"""import json  class Tool:    """MCP Server 上注册的一个工具"""    def __init__(self, name, func, description=""):        self.name = name        self.func = func        self.description = description  class McpServer:    """模拟 MCP 服务端：维护工具注册表，处理 JSON-RPC 请求"""    def __init__(self):        self.tools = {}     def register_tool(self, tool):        self.tools[tool.name] = tool     def handle_request(self, request):        method = request["method"]        if method == "tools/list":            return {"tools": list(self.tools.keys())}        if method == "tools/call":            params = request["params"]            tool = self.tools[params["name"]]            return {"result": tool.func(**params["arguments"])}        raise ValueError("未知方法: " + method)  class McpClient:    """模拟 MCP 客户端：发现工具并发起调用"""    def __init__(self, server):        self.server = server     def list_tools(self):        req = {"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}        return self.server.handle_request(req)     def call_tool(self, name, arguments):        req = {            "jsonrpc": "2.0",            "id": 2,            "method": "tools/call",            "params": {"name": name, "arguments": arguments}        }        return self.server.handle_request(req)  def search_web(query):    """模拟搜索工具"""    return "关于「" + query + "」找到 42 条结果"  def add(a, b):    """模拟计算工具"""    return a + b  if __name__ == "__main__":    server = McpServer()    server.register_tool(Tool("search_web", search_web, "搜索网页"))    server.register_tool(Tool("add", add, "两数相加"))     client = McpClient(server)     tools = client.list_tools()    print("发现工具:", tools["tools"])     result = client.call_tool("search_web", {"query": "MCP协议"})    print("搜索:", result["result"])     result = client.call_tool("add", {"a": 20, "b": 22})    print("计算:", result["result"])

1. server.register_tool(Tool("search_web", search_web, "搜索网页"))把普通函数包装成工具注册进服务端，对应真实MCP Server的“暴露工具”操作。
2. client.list_tools()发送 tools/list 请求，对应MCP工作流程中的“工具发现”阶段，返回的是可用工具名称列表。
3. client.call_tool("search_web", {"query": "MCP协议"})发送 tools/call 请求，携带工具名和参数字典，对应“工具调用”阶段。
4. tool.func(**params["arguments"])用参数展开语法把arguments字典解包为函数关键字参数，是“参数校验后执行”的简化版。
5. {"jsonrpc": "2.0", "id": 1, "method": "tools/list"}模拟真实JSON-RPC 2.0请求格式，真实MCP消息结构与之一致。

常见误区

面试题