目前来看
MCP协议可以说是AI开发领域里一块分量十足的 "敲门砖"，重要程度堪比武侠小说里的武林秘籍
前言
本文将循序渐进地掌握介绍MCP的脉络知识。首先，我们先从最基础的 AI 大模型 API 调用开始分析。接着，对Function Caling的作用进行分析。 最后，从Function Caling过渡到MCP,进而讲清MCP的发展脉络。
AI接口调用
或许你并不具备AI大模型相关领域的专业知识，但这并不会影响你上手AI开发 。这主要是因为不断有公司对外提供可以调用AI大模型的的接口，进而不断降低AI开发的门槛。换言之，普通开发者构建开发聊天应用的关键秘诀是如何和像 OpenAI 这样的人工智能 "大拿" 打交道。
简单来说，你只需要按照特定的格式，给 OpenAI 的接口发送一些数据，它就会像个知识渊博的 "智能大脑"，立刻给你返回相应的AI答案。这就好比你去餐厅点菜，只要把菜品名称告诉服务员，后厨就会把做好的菜端上来。
事实上，有关AI的调用，我们主要把握三点要素。
第一是模型名称，它就像是不同的厨师，每个厨师擅长的菜系不同，不同的模型也有各自擅长的领域和风格。比如有的模型擅长写诗，有的擅长解答科学问题。
第二是角色名称， 可以把它理解成对话中的身份设定。比如在聊天过程中，你可以设定一个 "客服专员" 的角色，专门解答用户问题；也可以设定一个 "故事讲述者" 的角色，给用户讲精彩的故事。
第三是角色对应的消息 ，也就是你想让 AI 帮你处理的具体内容。比如你输入 "请推荐几部好看的科幻电影"，这就是一条消息。
举个例子，当你向AI接口发送请求时，就像给它递上一张 "任务清单",表明你要用哪个 "厨师" 来处理任务；再带上角色名称 "user"，告诉AI这是用户提出的问题；最后带上具体的问题。把这些信息一起发送给 AI，然后其会将答案反馈给你。
提示词工程
当你的AI聊天应用上线后，用户一开始会觉得很新鲜。但用不了多久，大家就会提出各种各样的问题。比如，有用户问："西安今天的天气怎么样？" 。 针对这类特殊场景的问题，如果AI没经过训练则很难准确回答。
因此，在解决这类问题时提示词工程 就显得尤为重要。提示词工程主要是通过设计和优化输入给 AI 的文本指令，来引导AI输出更符合预期的回答。简单来说，就是用合适的 "提问方式"，让AI更好地理解需求。 比如，想要获得详细的回答，提示词就需要更具体；想让 AI 按特定风格回复，也要在提示词里明确说明。
具体来说，你需要先给 AI 设置一条系统提示词，告诉它："当需要获取天气信息时，输出包含函数名称和参数的 JSON 数据。" 这里就用到了提示词工程的思路，即通过明确规则和输出格式，引导AI给出可用的数据。
例如，当用户提问 "查询北京今天的天气"，AI就会按照要求生成对应的 JSON 数据。开发人员拿到这些数据后，调用外部天气API获取实时天气，再把结果返回给 AI进行处理，进而再将处理后内容返回给用户。
但这种方式依赖于提示词工程的精细程度，而且存在明显不稳定性。即使设计了详细的提示词，AI 也并不总能严格按照要求生成 JSON 数据，就像掷骰子一样，结果难以预测。这是因为AI在理解和执行提示词时，存在一定的随机性，单纯依靠提示词工程很难完全控制输出。
Function calling函数调用
有没有更可靠的解决方案？答案是肯定。2023 年，OpenAI 推出 function calling（函数调用）功能，大幅降低了对提示词工程的依赖。打个比方，如果把AI比作一个聪明 "手无缚鸡之力" 的助手，那么Function Calling 就像是给它配备了各种 "工具包"。
当用户提出需求时，AI 能判断该用哪个工具包（函数），并准确告诉开发者需要什么 "工具参数"，从而完成实际操作。而使用Function Calling 的方式，其实就和平时我们定义函数并无差别。
具体来看，在上图中我们定义一个名为getWeather的Function Calling以获取天气查询。该函数功能描述为 "获取指定城市的实时天气"，参数包含city（城市名称，字符串类型）等。
当用户提出需求，比如 "上海今天天气如何"，AI 接收到问题后，会根据内置的逻辑和开发者定义的工具信息，判断是否需要调用外部工具。如果需要AI 会在回复中包含function call字段，明确告知要调用的函数名称和具体参数。例如，下面结构中
json
{
"name": "getWeather",
"arguments": {
"location": "北京",
"date": "2025-03-08"
}
}在接收到AI的调用指令后，其会根据name确定要调用的函数，将arguments中的参数传入函数，执行外部调用。比如调用天气API获取具体城市的天气数据，得到结果后再将数据整理成新的提示词发送给 AI。最后，AI 根据收到的信息，用自然语言组织回复，反馈给用户。
Function Calling 的优势非常明显。一方面，它大幅提升了 AI 调用外部工具的准确性和稳定性，避免了因AI 输出格式不规范导致的错误；另一方面，它让开发者专注于核心业务逻辑开发，无需花费大量精力优化提示词或处理数据格式问题。有了 Function Calling，AI 应用开发变得更加高效、可靠，能够轻松实现丰富多样的功能，满足用户复杂的需求。
MCP规范化协议
事实上，Function Calling 很大程度上依赖于具体的AI模型。 例如，我好不容易基于ChatGpt构建了一个Function Calling但如果我切换AI模型，那我可能就需要重新基于新的模型重新构建，难以实现一次编写，处处运行的效果，那有没一种方式能让我开发的Function Calling让各类大模型均可适用呢？当然有，它就叫做MCP协议。
简单来说，MCP 就像 AI 世界的 USB 接口，只要按照这个标准开发插件，就能在各种聊天应用里通用，真正实现 "一次开发，随处运行"。 而这一切的基石全部源自 Function Calling（函数调用）。
事实上，MCP协议的强大之处，远不止Function Calling 那一套。它新增了三大核心模块：
-
工具（Tools） ：就像给 AI 配备了各种 "工具箱"，查天气、算数据都能搞定；
-
资源（Resource） ：服务器可以在这里声明文件、权限等信息，比如哪些文件需要用户授权才能访问；
-
提示词（Prompts） ：服务器提供一套现成的提示词模板，用户直接调用就能快速发起请求，不用每次都绞尽脑汁写指令。
那MCP具体怎么运作呢？我们以 Cursor 类的聊天客户端为例，探讨 MCP（Model Communication Protocol，模型通信协议）的运行机制。当客户端配置好对应MCP服务后，其每次进行对话时都会自动与 MCP 服务器建立连接，并向服务器发送tools/list请求，获取可用工具清单。服务器会响应返回所有工具的详细信息，包括功能描述、输入参数等。
当用户在客户端输入 "查询西安天气" 时，客户端会将用户的指令与从服务器获取的工具列表，按照 AI 接口规范封装成 Function Call 格式，发送至 AI 平台。AI 接收到请求后，根据工具列表选择 "查询天气" 工具，并传入参数进行调用。
此时，客户端作为中介，将 AI 的调用指令转发给 MCP 服务器。服务器执行查询任务后，返回 "西安晴，25 度" 的结果。客户端获取结果后，再将其反馈给 AI，由AI 对结果进行整理，最终向用户展示 "西安天气晴朗，温度 25 度"。
其实MCP并不复杂，而Function Calling 与 MCP(模型控制协议)的核心差异在于实现层面：Function Calling 在 AI 接口层直接完成功能对接；而 MCP 作为一套独立的通用协议，通过定义资源提供者规范，如工具声明、提示词声明及资源声明等，实现数据交互的标准化。客户端接收 MCP 定义的信息后，将其转化为与 AI 接口兼容的数据格式进行传输。
除工具相关规范外，MCP 协议还涵盖资源提示（resource prompts）等丰富内容，开发者可根据需求进一步探索拓展。从普通开发角度来看，MCP 是前后端交互的约定框架，明确规定后端需暴露特定接口，前端则通过这些接口完成数据请求与传递。
总结
事实上，MCP 协议基于 JSON RPC 标准。当聊天客户端（比如 Cursor）访问tools/list接口时，MCP 服务器会返回一份详细的工具清单，包括每个工具的名称、功能和参数要求。客户端拿到清单后，会自动把它转成 AI 能识别的 Function Calling 格式。
另一方面，在控制权分配方面，传统的函数调用依赖聊天客户端转发，由模型自主决定触发时机；而 MCP 中的资源和提示词管理完全由用户主导。例如，当 AI 需要删除资源时，必须获得用户授权；用户如需使用特定提示词，可在输入框中输入斜杠，从系统生成的列表中快速选择（如选择预设提示词）。因此，MCP 本质上是在基础接口交互的基础上，通过标准化协议赋予用户更强的操作控制权 。