为什么MCP很重要，为什么SSE让我们陷入困境——为什么更好的调试工具已经过期
Chris Burns（英国IT顾问）的电源自动化连接器故事
关键词： MCP协议、服务器发送事件（SSE）、Power Automation自定义连接器、Python MCP、调试、SSE转换
______________________________________________________________________
编辑： 这在Python MCP协议的1.12.2版本中已经修复。我将把它留在这里存档，并提醒自己如何在自定义连接器中使用代码功能
引言：宏观视角：MCP——类似于USB‑C，但适用于AI
MCP（模型上下文协议）正迅速成为将大型语言模型插入外部工具和服务的标准方式。把它想象成AI的USB-C——同样的插头，可以在任何地方使用。无论您是使用Claude、Copilot Studio还是滚动自己的Python服务器，MCP都为您提供了一种结构化的、基于JSON-RPC 2.0的方式，将函数、提示和资源公开给LLM。
Python是MCP服务器的首选：易于上手，文档记录合理，维护积极。因此，当我们需要通过SSE将Python MCP服务器连接到Power Automation自定义连接器时，我们认为这很简单。
剧透：不是。
Gotcha：当你的ID在飞行途中更改类型时
我们遇到了一个微妙但令人恼火的问题。
我们的电力自动化流程预期 id MCP响应中的字段作为 字符串，以符合我们连接器的OpenAPI模式。但是，默认情况下，Python MCP服务器会发出：
event: message
data: {"jsonrpc":"2.0","id":1,"result":{…}}那个数字 "id": 1 下游架构验证失败，导致连接器错误。我们需要：
event: message
data: {"jsonrpc":"2.0","id":"1","result":{…}}这很简单，但SSE格式的复杂性和自定义连接器脚本的约束使这成为一个更深层次的挑战。
______________________________________________________________________
SSE≠JSON——电力自动化不会告诉你
我们最初的天真实现只是通过以下方式将响应解析为JSON JObject.Parse(responseString) 并重写了它。不出所料，它以灾难性的失败告终。就在那时，我们意识到：
- SSE响应使用基于线路的流媒体--
event:和data:行--不是纯JSON - 您必须手动解析出来
data:，转换JSON，并使用正确的标头重新构建
尽管微软自己的文档显示了使用MCP的SSE示例，但Power Automation连接器无法开箱即用。没有错误。没有警告。只是无声的失败。
______________________________________________________________________
社区智慧：什么帮助了我们
Power Platform社区是无价的。贡献者强调：
- Power Automation强制执行严格的内容类型/模式验证
- SSE必须逐行处理
- Python MCP服务器ID是“当前”的数字，但MS客户端希望返回字符串ID——MCP规范没有明确规定“类型”应该相同。
GitHub MCP问题(#961)确认这是一个已知的不兼容性：Python MCP发出整数ID，与Copilot Studio的期望相冲突。
______________________________________________________________________
Power Automation的脚本黑盒
现在，让我们谈谈工具。
深入挖掘这一点，揭示了另一个主要的摩擦—— 调试不存在自定义连接器的代码编辑器：
- 不支持单步调试
- SSE管道内不会出现原木
- 编译错误是模糊的，例如。
$"...”字符串插值默默失败 - 您无法查看请求/响应历史记录
这些限制意味着我们实际上是盲目的，猜测转换，并希望它们与模式规则保持一致。一个简单的控制台或通话记录查看器本可以为我们节省几个小时。
______________________________________________________________________
工作解决方案：代码示例+说明
这是最终可用的自定义连接器代码的关键代码片段——有关完整代码，请查看脚本文件：
//// Shortened - Ensure you use full script file attached
//......
HttpResponseMessage response = await this.Context.SendAsync(this.Context.Request, this.CancellationToken).ConfigureAwait(continueOnCapturedContext: false);
// Do the transformation if the response was successful, otherwise return error responses as-is
if (response.IsSuccessStatusCode)
{
var responseString = await response.Content.ReadAsStringAsync().ConfigureAwait(false);
// Split into lines
var lines = responseString.Split(new[] { '\n', '\r' }, StringSplitOptions.RemoveEmptyEntries);
string eventLine = null;
string dataLine = null;
foreach (var line in lines)
{
if (line.StartsWith("event:"))
{
eventLine = line;
}
else if (line.StartsWith("data:"))
{
dataLine = line;
}
}
if (dataLine != null)
{
var jsonPart = dataLine.Substring("data:".Length).Trim();
var result = JObject.Parse(jsonPart);
if (result["id"] != null)
{
result["id"] = result["id"].ToString();
}
// Reconstruct the SSE format
var rebuiltResponse = eventLine + "\n" +
"data: " + result.ToString(Newtonsoft.Json.Formatting.None) + "\n\n";
//_logger.LogInformation("Transformed SSE JSON: {rebuiltResponse}", rebuiltResponse);
response.Content = new StringContent(
rebuiltResponse,
System.Text.Encoding.UTF8,
"text/event-stream"
);
}
}
return response;
为什么有效：
- 仅提取SSE JSON有效负载
- 转换
id到字符串 - 重建符合要求的输出
______________________________________________________________________
还缺少什么？更好的工具，微软！
如果微软希望开发人员构建更丰富的连接器，他们需要投资于基础：
- SSE支持刚刚奏效
- 一个合适的调试控制台（即使是只读日志也可以）
- 编译时错误可见性
- 打电话给历史记录，看看引擎盖下发生了什么
现在，我们正在盲目飞行。
______________________________________________________________________
最后总结
- SSE很特别；把它当作流媒体，而不是静态JSON
- Python MCP在技术上是规范正确的，但连接器消费者可能期望字符串而不仅仅是整数（在修复列表中）
- 社区事务。如果没有论坛和GitHub线程，我们仍然会猜测。
- 微软：把你的工具整理一下。这可能是一个出色的平台——如果我们能看看它在做什么。
______________________________________________________________________
感谢社区
非常感谢 CU24061549-1 和 FW‑24061242‑0 因为他们的早期见解。GitHub MCP编号问题（#961）澄清说，这不是一次性错误，而是规范级不匹配。
______________________________________________________________________
行动号召
- 如果你在建 Python MCP服务器, SSE兼容性测试
- 对于 电力自动化开发人员，分享您的连接器调试经验
- 微软： 为我们提供更好的日志和断点拜托！
______________________________________________________________________
关于克里斯·伯恩斯\ 来自英国的技术架构师和AI自动化设计机构所有者（Kaizenova/Nastar），专门从事Power Platform&Copilot Studio、Azure和AI集成。
______________________________________________________________________
*发布时间：2025-07-09*