实际执行报错呢？

[YoungCan-Wang]

我已经把这条链路又往前推了一大步，结果是：
现在状态
didi-ride-skill 已安装
MCP key 已写进配置
Feishu 提权也开通了
mcporter 也已经装好，版本是 0.8.1
真正卡点
现在不是权限问题了，而是 滴滴 MCP 服务和当前 mcporter 协议不兼容，报错是：
SSE error: Invalid content type, expected "text/event-stream"
我还直接 curl 了滴滴这个地址，返回是：
Content-Type: text/plain
响应内容：Missing KEY parameter
这说明至少有一个问题成立：
这个 skill 文档里写的 mcporter 调法，和当前线上滴滴 MCP 接口 / 当前 mcporter 版本 对不上
很可能需要 特定版本的 mcporter，或者需要 另一种配置方式，不是直接拿 URL 去 call

[SmallSongSong]

感谢 @YoungCan-Wang 的详细反馈！🙏 您把整条链路从安装到调用都跟下来了，这种粒度的反馈对我们非常有帮助。

---

这个问题的根因并不是 mcporter 协议不兼容，也不是需要特定版本的 mcporter，AI 当时的分析有一些误导。

Content-Type: text/plain + Missing KEY parameter 的组合，实际上是滴滴 MCP 网关没拿到 key= 查询参数时返回的统一错误。它看起来像"协议不匹配"，但实际触发原因通常是以下几种（按频率排序）：

1. $DIDI_MCP_KEY 没被 shell 展开成真实 Key：最常见于 MCP_URL 用了单引号或中文引号包裹，导致变量没替换，URL 实际发出去就是字面的 ?key=$DIDI_MCP_KEY，网关解析为空 key。
2. 额外加了 --server 标志：比如 mcporter call --server didi-mcp "$MCP_URL" ...，这种写法会让 mcporter 先去找已注册的命名 server，和 URL 参数冲突，丢失 key。
3. URL 本身 key 参数格式错误：直接用 curl 测试时很容易少写 ?key=...，或者环境变量没 export。

总结一下：mcporter 0.8.1 + URL 直连模式是完全支持当前滴滴 MCP 服务的，不需要降级或换配置方式。

---

我们已经针对这个问题在 v1.1.2 做了重点优化，让 AI 在遇到类似错误时能更准确地排查：

• SKILL.md §3.2.3：显式声明使用 URL 直连模式，禁止创建或修改 config/mcporter.json
• SKILL.md §3.2.4：固化 mcporter 调用格式、强调必须用英文双引号、禁用 --server 标志，并列出常见参数名致命错误（keyword→keywords、region→city、六字段 from_lat/from_lng/from_name/to_lat/to_lng/to_name）
• references/error_handling.md：新增「mcporter Missing KEY parameter」专门章节 + -32xxx 错误码统一恢复指南，AI 读到这些错误时会按文档指示的步骤而不是乱猜方向

您可以在 ClawHub 上拉取最新版本重试一下，应该就不会被同一个报错误导了。

再次感谢您的反馈，这类"AI 分析方向不对"的真实 case 对我们改进 skill 非常有价值！