绕过Power Automate，我用MCP直连省了1小时

接上回。Part 2里，我花了3小时、踩了8个坑，终于用Power Automate把REST API跑通了。但流程刚通，我就忍不住想：有没有更短的路？

有。答案叫MCP。

这次我没建任何自动化流，没配轮询循环，没调HTTP连接器——直接把LDX hub的MCP服务器接进Copilot Studio agent。全程2小时，大半时间耗在两个藏得很深的设置上。

以下是完整记录。

环境配置

• Microsoft Copilot Studio（Kawamura International租户）
• LDX hub MCP服务器（https://gw.ldxhub.io/mcp）
• 现有agent：Minutes Assistant（議事録アシスタント）
• 耗时：约2小时

为什么弃Power Automate选MCP？

Part 2的REST API路线能跑通，但代价不小：

• 要搭Do Until轮询循环
• HTTP连接器颜色陷阱（白标vs绿标）
• triggerBody()引用报错
• 异步结果的变量类型管理

MCP把这些全砍了。agent直接调工具——没有中间层，没有要维护的流。如果你的场景能接受这个tradeoff，上线速度快得多。

当然，tradeoff真实存在：MCP更适合交互式、单条记录场景。批量处理20个文件？Power Automate仍是正解。这部分留到Part 4展开。

背景与目标

Kawamura International正在全公司推进生成式AI驱动的业务流程。这次验证的核心，是把LDX hub的StructFlow（结构化数据提取）集成进"Minutes Assistant"——自动从会议记录中提取：

• 任务与行动项（含负责人、截止日期）
• 已做出的决策
• 按发言人整理的摘要
• 下次会议议程候选

架构链路

用户（粘贴会议记录）
↓
Copilot Studio "Minutes Assistant"
↓ MCP tools/call（Streamable HTTP）
LDX hub MCP服务器
↓ createStructFlowJob
StructFlow引擎（异步任务）
↓ getStructFlowJob（轮询）
结构化JSON结果
↓
Copilot Studio格式化输出

第一步：连接前验证端点

碰Copilot Studio之前，先确认LDX hub MCP端点符合要求。

⚠️ 关键提醒：SSE传输协议已于2025年8月废弃

Copilot Studio已移除SSE支持，现仅接受Streamable HTTP。连接前务必核实协议版本。

PowerShell验证命令：

$headers = @{
"Content-Type" = "application/json"
"Accept" = "application/json, text/event-stream"
"Authorization" = "Bearer YOUR_API_KEY"
}
$body = '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'
$r = Invoke-WebRequest -UseBasicParsing -Uri https://gw.ldxhub.io/mcp -Method POST -Headers $headers -Body $body

返回状态200且包含serverInfo，说明端点就绪。

第二步：Copilot Studio端配置

进入agent设置 → 知识 → 操作 → 新增操作 → 选择"MCP服务器"。

这里藏着第一个坑：Transport类型必须选"Streamable HTTP"，默认的SSE选项会直接导致连接失败——但界面不会提醒你SSE已废弃，只会报模糊的连接错误。

第二个坑在认证头。LDX hub要求Bearer token格式，但Copilot Studio的"API密钥"字段会自动添加"Bearer "前缀。如果你在密钥框里手动写了"Bearer "，实际发出的是"Bearer Bearer xxxx"，必然401。

正确做法：密钥框只填纯token，前缀交给系统自动处理。

第三步：工具暴露与测试

连接成功后，LDX hub暴露两个核心工具：

1. createStructFlowJob - 提交异步提取任务
2. getStructFlowJob - 轮询查询任务状态

在Copilot Studio的"操作"面板中，这两个工具会自动生成对应的动作卡片。但别急着发布——先点"测试"跑通端到端。

测试时的典型失败：agent调用createStructFlowJob后，不会自动轮询getStructFlowJob。需要显式在对话流中加入"调用操作"节点，把jobId传给getStructFlowJob，并设置重试逻辑直到status为completed。

这里省下的时间，正是Power Automate里Do Until循环的等价替代——但MCP版本更透明，调试时能看到每次轮询的原始响应。

耗时对比

路线 | 总耗时 | 核心障碍
REST API + Power Automate | 3小时 | 连接器配置、轮询循环、变量类型
MCP直连 | 2小时 | 两个隐藏设置（传输协议、认证头格式）

1小时的差距，本质是"可视化编排的复杂度"vs"协议层配置的隐蔽性"。

当前局限

MCP路线并非万能。实测发现：

• 单条会议记录处理流畅
• 批量提交场景下，agent对话上下文会膨胀，需手动清理
• 超时控制不如Power Automate精细（无图形化重试策略配置）

这些边界条件，正是Part 4要对比的决策框架：什么场景该用MCP，什么场景必须回Power Automate。

下一步

Minutes Assistant现已上线内部测试。Part 4将整理完整决策矩阵——包括成本、维护负担、扩展性三个维度的对比。