MCP 协议：用标准方式让 AI 控制硬件

你已经会让大模型通过 Function Calling 调用一个函数去控制硬件了。开心几天之后，麻烦来了：你给板子加了个舵机，要写一套描述告诉模型"有个 move_servo 工具、参数是角度"；又加了个继电器，再写一套；接了个温湿度传感器，又一套。每多一个硬件动作，你就得重新对接一遍——描述格式、调用约定、返回结构，全是你这一家自己定的。

更糟的是换平台。你这套写法绑死在某个模型服务上，换一家模型，"工具怎么描述、怎么调用"的规矩又变了，前面写的全得改。每个人都在用自己的方言，跟 AI 解释"我有哪些能力"。 这件事没有标准，就注定重复造轮子。

---

Function Calling 的问题：不统一，各家各写一套

先把上一节学的东西放到天平上称一称。Function Calling 解决了"让模型能调外部函数"这个核心问题，但它留了一个洞：没人规定"工具该长什么样"。

• 描述格式各家不同：同样是"告诉模型有个控灯工具"，A 家模型要你写成这种结构，B 家又是另一种。
• 调用与返回约定不统一：模型决定要调工具时怎么发、你执行完怎么把结果递回去，不同服务细节各异。
• 能力没法复用：你给一块板子写好的一套工具描述，换块板子、换个项目、换个模型，基本没法直接搬。

结果就是：每接一个新硬件动作、每换一个平台，你都在重写对接。能力本身（控 LED、转舵机）没变，变的全是"怎么跟 AI 描述这个能力"的外壳。这正是标准化该出手的地方。

---

MCP 是什么：给 AI 接硬件的"USB 接口"

MCP，全称 Model Context Protocol（模型上下文协议），由 Anthropic 提出。一句话讲清它干的事：它把"一个工具/能力长什么样、怎么被调用"这件事标准化了。

打个你一定有体感的比方。USB 出现之前，鼠标、键盘、打印机各有各的插口，换台电脑可能就插不上。USB 把"插口"统一了，于是任何设备只要做成 USB，插上就能用。MCP 想做的是同一件事，只不过统一的不是物理插口，而是**"AI 和外部能力之间的对接口"**：

• 你按 MCP 的规矩，把一个能力（比如"开灯"）描述清楚——它叫什么、要什么参数、做什么事。
• 任何支持 MCP 的一方（模型、客户端）都能用同一套规矩发现你有哪些能力、并调用它们。
• 你不必再为每个模型、每个平台重写一遍描述。写一次，到处能接。

所以 MCP 不是某个新模型、也不是某个 SDK，它是一份"大家都遵守的约定"。它的价值不在某个炫技功能，而在"统一"本身——把原本一对一、各写一套的混乱，收敛成一对多、写一次的秩序。对要给一堆硬件接 AI 的人来说，这个"统一"省掉的正是最磨人的重复劳动。

---

在硬件上：设备端 MCP vs 云端 MCP

概念落到硬件，MCP 在小智 xiaozhi-esp32 里有两种用法，分工很清楚。小智用 MCP 把硬件能力（控制 LED、舵机、GPIO、智能家居）暴露给大模型，让模型"知道这台设备能做什么、并能直接指挥它做"。

设备端 MCP：模型直接指挥这块板子

第一种，把板子自己的本机能力暴露成 MCP 工具。比如这块小智板子上接了 LED、舵机、几路 GPIO，你就把"开灯""转舵机到某角度""读某个引脚"这些动作，按 MCP 的规矩注册成工具。

于是当你对它说"把灯调暗一点""把头转过来"，模型理解意图后，就能通过 MCP 直接调用板子本机的这些工具——控制就发生在这块板子上，不必绕一大圈。这是"AI 能动手"最直接的形态：大脑（模型）和手脚（板子的 LED/舵机）通过 MCP 这套标准口对接上了。

云端 MCP：联动设备之外的世界

第二种，把设备之外的能力通过云端的 MCP 暴露给模型。比如查天气、查日程，或者联动你家里别的智能家居设备（不在这块板子上、而在你的智能家居网络里的灯、空调、窗帘）。

这类能力不在这块小智板子本机，而是挂在云端或别的服务上。通过云端 MCP，模型同样能用那套统一的规矩发现并调用它们。于是一句"我要睡了"，可能既关了这块板子上的灯（设备端 MCP），又联动关了客厅的空调（云端 MCP）——对模型来说，这两类工具用的是同一套调用方式，它不必关心能力到底在板子上还是在云上。

两者配合，就是小智这类设备的能力地图：本机能直接控的走设备端 MCP，要联动外部世界的走云端 MCP，但对大模型暴露的是同一套标准接口。这正是 MCP 的好处——能力在哪不重要，描述和调用的方式统一了。

---

一段概念示意：把一个硬件动作"注册"成 MCP 工具

下面用伪代码演示"把一个硬件动作注册成 MCP 工具"是个什么概念。注意：这是概念示意，不是完整实现，也不代表真实的 MCP 报文或 API。 真实写法以官方与小智上游为准，这里只为让你"看见"标准化长什么样。

// 概念示意（非完整实现）：把"控制 LED"这个本机能力注册成一个 MCP 工具
//
// 标准化的核心，是用一套统一的方式把"这个工具"讲清楚：
//   - 它叫什么（名字，模型靠它来点名调用）
//   - 它是干嘛的（描述，模型靠它来判断什么时候该用）
//   - 它要什么参数（参数定义，模型靠它来填值）
//   - 调用时实际执行什么（绑定到你真正控硬件的代码）

registerMcpTool({
  name: "set_led",                       // 工具名：统一规矩下的"点名牌"
  description: "控制板载 LED 的开关与亮度", // 给模型看的说明：它据此决定要不要调
  params: {
    on:         "布尔，是否点亮",
    brightness: "整数 0~255，亮度（可选）"
  },
  // 模型决定调用、并填好参数后，最终落到这里——你真正控硬件的代码
  onCall: (args) => {
    pinMode(LED, OUTPUT);
    analogWrite(LED, args.on ? args.brightness : 0);  // 真正动手的一行
    return "已执行";                                    // 把结果按标准回给模型
  }
});

关键不在 analogWrite 那一行——那是你早就会的、L1 就动手过的点灯。关键在外面那层"注册"：你用一套标准格式把这个能力描述出来，于是任何支持 MCP 的模型都能发现它、按统一方式调它。你换块板子，把 onCall 里换成控舵机的代码，外面这层描述结构一模一样——这就是标准化省掉的事。

---

为什么这是 Agent 控硬件的未来

把视角拉高一点。一个能自己规划、自己调工具去完成任务的 AI，我们叫它 Agent。Agent 要在物理世界"动手"，前提是它能发现并调用一堆五花八门的硬件能力——而这些能力来自不同厂商、不同板子、不同协议。

如果没有统一标准，Agent 每接一种新硬件就得专门适配一次，这条路根本扩展不开。MCP 提供的恰是这个缺失的统一层：任何硬件只要把自己的能力按 MCP 暴露出来，Agent 就能即插即用地发现和调用它，不必为每一家单独写适配。

这就像 USB 之于外设、HTTP 之于网页——一旦"对接口"被标准化，上面能长出来的东西会爆发式增多。对硬件而言，这意味着：一块板子把能力做成 MCP 工具，它就不只服务于某一个固定程序，而是能被任何懂 MCP 的 AI 接管和编排。从"我写死了它的反应"到"任何 Agent 都能发现它、指挥它"——这一步迈过去，硬件才真正进入了"被 AI 自由调度"的时代。当然，这是方向，不是说今天就已经处处现成；但路标已经立在那儿了。

---

避坑：别把概念当成定稿

再点两个新手容易踩的认知坑：

• 别把 MCP 当成"又一个要学的大框架"。它的内核就一句话：用统一方式描述和调用能力。看懂这一层，剩下的都是查文档对字段。
• 别指望它替你写控硬件的代码。MCP 只统一了"怎么把能力告诉 AI、怎么被调用"这层皮；皮底下真正控 LED、转舵机的代码，还是你 L1~L3 一路学下来的那些。MCP 接的是"AI 和你的代码之间"，不是替你写代码。

---

动手挑战

这一节不写完整工程，先动脑设计——这恰恰是用 MCP 前最该想清楚的一步：

1. 给你手上的设备列一张"能力清单"：把这块板子上所有能被控制或被读取的东西列出来——LED、舵机、蜂鸣器、某个传感器读数……每一项都想成一个潜在的 MCP 工具。
2. 给其中两三个写出"四件套"：照前面示意的格式，给每个能力写出它的名字、描述、参数（执行那层先不管）。比如 set_servo：描述"把舵机转到指定角度"，参数"angle，整数 0~180"。
3. 分一分设备端还是云端：清单里哪些是这块板子本机能直接干的（设备端 MCP），哪些得联动外部服务或别的智能家居（云端 MCP）？分类的过程，就是在画你这台设备的"能力地图"。

做完这三步，你对"给设备暴露 MCP 工具"是怎么回事，就从概念变成了具体设计。等你真去看小智上游怎么实现，会发现自己设计的骨架和它八九不离十。

---

小结 · 你现在掌握了什么

• 你说得清 Function Calling 的痛点：能调函数，但"工具怎么描述、怎么调"没标准，各家各写一套，每接一个新硬件、每换一个平台都得重写对接。
• 你理解了 MCP 是什么：一份让 AI 以统一方式发现和调用外部能力的约定，像给 AI 接硬件配了个 USB 口；由 Anthropic 提出，且仍在演进。
• 你分得清小智里的两种用法：设备端 MCP 让模型直接控这块板子的 LED/舵机/GPIO，云端 MCP 让它联动智能家居、查信息——但对模型是同一套接口。
• 你能用"名字 + 描述 + 参数 + 执行"这四件套，去设想给自己的设备暴露哪些 MCP 工具。

记住那条红线：MCP 细节以官方和小智上游为准，本文是概念解读。 把"统一对接口"这个内核刻进脑子，再去看任何 AI 控硬件的项目，你都能一眼认出它在哪一层做了标准化。

下一步：把"能动手"接回"会说话"——回头看 ESP32 调大模型的语音链路，理解 MCP 工具调用是嵌在那条"唤醒 → ASR → LLM → TTS"链路的哪一环；想看工业级的完整落地，去实战项目里逐行拆小智旗舰怎么把 MCP 和语音串成一台真能用的设备。