MCP协议实战指南：从REST接口到智能体工具连接

先跟各位说个事：我最近在折腾“测试发布mcp5”这个项目，本来以为是随手把几个接口暴露出去的小事，结果一头扎进去才发现，MCP（Model Context Protocol，模型上下文协议）这套东西，远比想象中复杂，也远比想象中有意思。如果你最近也在研究智能体开发、想让AI工具链真正“连起来”，或者只是好奇大家都在说的“MCP”到底是什么，这篇文章应该能帮你少走很多弯路。

简单说，MCP解决的是一个大问题：现在大模型再聪明，它也是“闭着眼睛”的，拿不到你的本地文件、数据库、设计稿、代码仓库里的实时数据。以前要打通这些，得给每个AI应用单独写插件、做适配，一个萝卜一个坑，累死个人。MCP干的事，就是给“AI应用”和“数据/工具”之间定了一套通用插座标准，插座统一了，插头才能随便换。我这次“测试发布mcp5”，本质就是在验证这套标准的落地效果。

这篇分享不搞虚的，我会从MCP的核心概念、为什么需要它、实际怎么把一个REST接口发布成MCP服务、以及它跟“Agent Skill”“Tool”这些热词到底有什么区别这几个角度，完整走一遍我的实操过程。适合正在用Spring AI、Codex、Trae、IDEA这些工具搞开发的同学，也适合产品经理和架构师想快速搞懂技术趋势的。

1. MCP到底解决什么问题：先搞懂它诞生的逻辑

1.1 从“满世界适配器”到“一个插座标准”

先说个让我印象很深的场景。我团队里同时用着蓝湖传设计稿、Figma画原型、GitLab管代码、内部系统还有一堆REST接口。以前想让AI助手去读这些工具里的数据，基本是噩梦：

• 蓝湖有自己的API，Figma也有自己的API，每个平台都得单独写一套鉴权、单独处理数据格式。
• 就算给AI写好了某个平台的插件，换个AI产品（比如从某AI助手换到Codex），插件又得重来。
• 更麻烦的是，数据从工具到AI手里，中间往往经历“工具API→中间服务→提示词拼装→上下文截断”，过程一长，信息损耗特别严重。

MCP的核心思路就是用一套协议来解决“工具/数据源”和“AI应用”之间的连接。它把提供数据或能力的一方称为“MCP Server”（服务器），把使用这些数据或能力的AI应用称为“MCP Client”（客户端），两者之间跑在最常见的JSON-RPC消息上。这么一来，蓝湖只需要做一个官方MCP Server，Figma也做一个MCP Server，所有支持MCP的AI应用（比如Claude Desktop、Codex、IDEA插件、Trae的Builder等）就能直接识别并调用，再也不用每个组合写一套适配了。

我拿生活里的例子打个比方：以前你家里每个电器都配一个专用插座，电视插座只能插电视，冰箱插座只能插冰箱，换个牌子就插不上。MCP就相当于把全屋插座统一成了国标五孔，不管什么牌子、什么功能的家电，只要按国标做插头，进门就能通电。

1.2 MCP协议的两大角色与实际消息流

理解MCP协议，先抓住“三角色”和“三能力”。

三角色分别是：

• MCP Host：可以理解为用户直接打交道的那些AI应用或开发环境，比如Claude Desktop、IDEA、Trae、Android Studio这些。Host负责发起会话，并把AI模型和MCP Server连接起来。
• MCP Client：它实际上是Host内部的一个组件，负责与Server建立连接、发送请求。严格说，Client和Host常在同一个进程里，所以日常说“客户端”时，经常指代整个Host应用。
• MCP Server：轻量级服务，暴露了“工具（Tools）”“资源（Resources）”“提示词模板（Prompts）”三种能力。

三能力分别对应三种使用场景：

• Tools：可执行的函数，比如“查天气”“创建工单”“执行SQL查询”“提交代码”。这是目前用得最多的能力，AI模型根据你的问题决定“该调用哪个工具”，参数由模型生成，Server执行后把结果返回给模型，模型再组织语言回答你。
• Resources：可读取的数据，比如“某个文件的内容”“某个画板的设计稿数据”“某个系统里的配置信息”，类似把文件的“只读视图”暴露给AI。
• Prompts：预置的提示词模板，你可以理解成“给AI准备好的起手式”，比如“一键生成周报”的完整Prompt结构，用户选中这个模板，AI就按模板流程走。

实际调用一条工具的消息流大致是这样的：用户在Host里发了一句话，模型分析后认为“需要调用Server A的某个工具”，于是Client按协议把“工具名+参数”包装成一个JSON-RPC请求，通过stdio（本地子进程通信）或Streamable HTTP（远程通信）发给Server。Server执行完毕，把结构化结果返回给Client，Client把结果交给模型，模型进一步总结出人话反馈给用户。每一步都有清晰的请求-响应关系，这也是它能在不同编程语言、不同厂商之间互联互通的底气。

1.3 为什么2025年MCP突然成为开发圈“顶流”

早些年也有类似“插件系统”的想法，比如给编辑器做插件、给浏览器做扩展，但那些都是单机时代的产物，服务范围局限在单一宿主里。MCP之所以从2024年底到2025年爆发，我分析有几个关键推力：

第一，大模型从“聊天机器”走向“操作助手”。大家不再满足于让AI写一段话，而是想让AI真正干活：改代码、提交PR、查数据库、操作设计软件。要干活就必须碰工具，MCP提供了一个统一的“干活接口”。

第二，头部工具厂商主动下场建生态。像代码编辑器JetBrains的IDEA、新兴AI原生IDE Trae、设计工具Figma、甚至办公软件WPS和剪映，都在陆续推出自己的MCP Server或接入MCP Client。工具厂商做一套标准Server，所有AI应用都能用，等于一次接入、全网通用，性价比极高。

第三，开发者苦“碎片化集成”久矣。我接触过不少做AI Agent的团队，痛点很一致：大量时间花在“适配某个平台的工具A