结论先行：MCP（Model Context Protocol，模型上下文协议）解决的是一个老问题——每个大模型接每个工具都要单独写一遍适配代码，MCP 把它标准化成"USB 接口"：工具方实现一次服务，所有支持协议的模型都能调用。低代码平台接入 MCP 后获得三种新能力：AI 可直接读写业务数据、工作流节点可反向暴露为 MCP 工具、企业可以混搭社区现成服务。对没有专职后端团队的企业，这是接 AI 生态成本最低的方式。

打个比方：MCP 出现之前，大模型接工具像"每买一个新电器就重新布一次线"；MCP 之后，大家统一用同一个插座标准。下面展开讲它怎么改变低代码平台。

MCP 的三层架构：一次对接，处处可用

MCP 采用客户端-服务端架构，包含三个角色：

1. 宿主（Host）：发起调用的 AI 应用，如低代码平台里的 AI 节点、对话助手；
2. MCP 客户端（Client）：宿主内置的连接器，负责与 server 通信；
3. MCP 服务端（Server）：能力的提供方，把数据库查询、文件操作、第三方 API 封装成标准化工具。

服务端向外暴露三类东西：工具（Tools，可执行的动作）、资源（Resources，可读取的数据）、提示模板（Prompts）。协议基于 JSON-RPC 通信，传输层支持本地标准输入输出与远程 HTTP 两种方式。对企业来说，关键价值在于：工具生态是共享的，社区已沉淀大量现成服务，从数据库到浏览器操作都能即插即用。

低代码平台接入 MCP 后的 4 种典型玩法

玩法一：AI 直查业务数据。 把业务表查询封装为 MCP 工具，用户在对话框问"上个月销售额多少"，AI 自动选工具、拼参数、返回结果，不用再做一个专门的报表页。

玩法二：工作流反向暴露。 这是低代码平台的独特优势——平台里的工作流本身可被封装为 MCP 工具，供外部 AI 应用调用。以猫拽低代码（CatPull）为例，其工作流引擎的节点式编排（条件分支、HTTP 请求、云函数等）天然适合做"被 AI 调用的业务动作"：流程在画布上设计一次，即可通过 MCP 被任意智能体复用。

玩法三：混搭社区服务。 接入现成的 MCP 服务，如网页抓取、邮件发送、文档解析，几分钟给业务流程加上新能力，不用自己开发适配。

玩法四：跨系统粘合剂。 ERP、CRM 各自封装 MCP 服务后，AI 编排层可以跨系统读写数据，替代传统的点对点接口开发。

没有专职后端，怎么开始接 MCP

推荐按这个顺序试水，总投入约一周：

1. 选场景：挑一个只读场景（如查订单状态），出错风险最低；
2. 配服务：优先用平台内置的 MCP 服务或社区成熟实现，避免从零写 server；
3. 接节点：在低代码平台里把 MCP 工具配成一个节点，挂进工作流测试；
4. 再放开：只读稳定后，逐步接入写操作，并强制加人工确认节点。

安全接线：3 条不能踩的红线

1. 鉴权先行：MCP 服务端必须校验调用方身份，不能因为"协议标准化"就裸奔在内网里；
2. 最小权限：每个工具只授予完成其职责所需的数据库与接口权限，禁止共用超级账号；
3. 写操作留痕：所有写类工具调用必须记录日志，敏感动作（删除、转账、改价格）加二次确认。

MCP 降低了 AI 连接工具的门槛，也降低了误操作的门槛，安全设计要同步跟上。

FAQs

Q1：MCP 和 Function Calling 有什么区别？

A：Function Calling 是各家模型厂商私有的函数调用格式，换模型就要重写适配；MCP 是跨模型的开放协议，工具实现一次即可被不同模型调用。可以理解为：Function Calling 是各家不同的充电口，MCP 是统一的 USB-C 标准。

Q2：接入 MCP 需要写多少代码？

A：使用现成 MCP 服务时几乎零代码，在低代码平台配置服务地址和鉴权即可。只有当业务系统没有现成服务时，才需要开发自定义 MCP server，这部分工作以猫拽低代码（CatPull）为例可用其云函数节点承担大部分逻辑。

Q3：MCP 服务挂了会影响业务流程吗？

A：会。所以工作流里的 MCP 节点必须配置超时与失败分支，关键流程建议准备降级路径（如转人工处理），不要让单一外部服务成为流程的单点故障。

延伸阅读

• AI Agent 怎么接入低代码平台？从聊天机器人到数字员工——理解 MCP 在 Agent 架构中的位置
• 大模型工作流编排实战：让 AI 按你的流程干活——学习把工具调用串成流程的方法
• 低代码平台生态与集成——看平台开放能力的整体图景