MCP协议详解：打通大模型与传统软件世界的桥梁

在Agent开发体系中，MCP（Model Context Protocol）已经成为绕不开的核心环节。很多初学大模型的开发者对它既熟悉又陌生——听过名字，却说不清它到底解决了什么问题，与Skill又有什么区别。本文基于B站马氏集团山山老师的公开课内容，用最直白的方式讲清楚MCP的工作机制及其存在的必要性。

什么是MCP：一种连接大模型与外部世界的协议

MCP本质上是一个协议，它的作用是让大模型能够标准化地连接外部工具、外部业务系统或传统开发接口。

说到"协议"，最容易理解的类比就是HTTP协议。我们在互联网中发起一个请求、收到一个响应，整个交互过程都遵照HTTP协议进行。协议的核心含义就是一种规则、一种约束。MCP也是如此——它是一套约定好的规则，规定了大模型该如何与外部工具打交道。

仅看定义可能还是有些抽象。要真正理解MCP的价值，需要先回到大模型出现之前的软件开发世界。

MCP（Model Context Protocol）由Anthropic公司于2024年11月正式发布并开源，目标是成为AI助手连接外部数据源与工具的通用标准。它采用客户端-服务器架构：MCP Client通常内嵌在AI应用（如Claude Desktop、Cursor等）中，MCP Server则由工具或业务系统的开发者实现并对外暴露能力。两者之间通过标准化的JSON-RPC协议通信，支持工具调用（Tools）、资源读取（Resources）和提示模板（Prompts）三种核心能力类型。这种分层设计意味着，任何遵循MCP规范的AI应用都可以无缝接入任何遵循MCP规范的工具服务，真正实现"一次封装，处处可用"。

为什么需要MCP：传统接口是给程序用的，不是给大模型看的

在大模型普及之前，软件行业已经积累了海量的系统。做Java、C++、Go、PHP的开发者，可能已经工作了十年，开发出大量成熟的业务系统。

以一个电商系统为例，里面往往有商品查询接口、库存查询接口等大量接口。当需要对外提供访问时，开发者会暴露一个访问方式，比如通过GET请求访问 /product/query 这样的路径。前端程序通过这个路径调用后端接口，后端再调用具体的服务、访问数据库，最终返回商品列表。

关键问题在于：这些传统接口是为程序设计的，而不是为大模型设计的。程序之间彼此"看得懂"参数、方法和返回值，但大语言模型并不理解。如果你直接把一个原始接口丢给GPT，它根本不知道这个接口是干什么的、参数该传什么。

大模型真正需要的，是一段能够理解的工具描述。也就是说，用自然语言（中文、英文都可以）描述清楚"这个工具是做什么的"，比如"查询库存"，而不是把底层接口的实现细节直接扔过去。MCP正是为解决这个问题而生——让大模型理解工具的能力，并调用已有软件的功能。

MCP如何工作：把已有系统封装成工具供大模型调用

理解了痛点，MCP的工作机制就清晰了。以电商系统的搜索接口为例，可以把它封装成一个MCP工具。这里不限制编程语言，任何语言写的接口都可以封装。封装完成后，大模型只需要调用这个工具即可。

整个调用链条是这样的：用户提出需求，经过Agent传递给大模型，大模型理解需求后发现"我需要查询商品信息"，此时正好有一个对应的MCP工具，它就直接调用这个工具。而工具背后调用的，依然是原先那一套逻辑——走服务、走数据库进行查询。

这带来一个重要好处：原有的业务逻辑无需重写。查询商品的完整逻辑早就写好了，你要做的只是把老系统封装成MCP工具，供大模型调用即可。

在技术实现层面，MCP工具的描述是整个调用流程的关键枢纽。每个MCP工具都需要提供结构化的元数据，包括工具名称（name）、功能描述（description）以及参数的JSON Schema定义。大模型在推理时，会将这些元数据作为上下文读入，通过语义理解判断当前任务是否需要调用某个工具、以及应该传入哪些参数——这一过程被称为"Function Calling"或"Tool Use"。因此，工具描述的质量直接影响大模型的调用准确率：描述越清晰、参数说明越详细，模型越能正确匹配并调用。这也是MCP Server开发中最需要花心思打磨的环节。

MCP的核心价值：复用传统软件资产

可以用一句话概括MCP的意义：它打通了大模型与传统软件世界之间的连接。

在大模型出现之前，Java系统是Java的，Python系统是Python的，大模型是大模型的，它们之间彼此独立，没有直接联系。大模型的出现，并不意味着此前积累的所有传统业务系统都要作废重来——那既不现实也没必要。

现实的做法是：原有系统保持不变，通过MCP这一层协议，让大模型能够复用这些已有的业务能力。这正是MCP能够迅速走红的根本原因——它在新兴的大模型技术与庞大的存量软件资产之间，架起了一座标准化的桥梁。

MCP与另一个常见概念"Skill"（技能）的区别值得简要说明。Skill通常指在AI框架（如Microsoft Semantic Kernel）内部定义的函数式能力，与框架强绑定，跨平台复用性有限。而MCP是跨框架、跨语言的开放协议——只要实现了MCP Server接口，任何技术栈的系统都可以被任何支持MCP Client的AI应用调用。此外，市场上已出现大量开箱即用的MCP Server实现，涵盖文件系统、数据库、GitHub、Slack、浏览器控制等常见场景，开发者可以直接引入而无需从零开发，进一步降低了接入成本。

小结

MCP的核心逻辑并不复杂：传统接口面向程序，大模型看不懂；MCP通过标准化协议和自然语言的工具描述，让大模型能够理解并调用这些能力；而底层实现依然复用已有系统，无需重复开发。理解了"复用存量、连接两端"这一点，也就抓住了MCP最本质的价值。至于MCP与Skill的具体区别及Codex接入等进阶话题，则需要在掌握基础机制后进一步展开。