Fabric RTI MCP 代理

在事件驱动架构里，团队经常需要从 Eventhouse 取 KQL 结果、管理 Eventstreams 生命周期，或通过 Activator 触发下游动作。传统做法要么是运维人员打开 Fabric 门户手工操作，要么是应用代码里嵌一堆 Azure SDK 调用与 SAS 处理逻辑，不仅难以测试，还容易因为凭据配置错误引发故障。

它解决了什么

这个技能让任何支持 MCP 的客户端（如 Claude、Cursor、Copilot）都能把 Fabric RTI 操作当作普通工具调用来处理：

• 直接执行 KQL 查询、批量诊断命令（如 kusto_diagnostics 统一返回集群状态摘要）
• 管理 Eventstreams 和 Eventstream 目的地，包括创建、更新、删除与运行状态查询
• 通过 Activator 规则触发响应动作，比如向 Teams 频道推送告警
• 读取 Map 渲染的地理可视化结果，便于在对话中展示空间数据

工作原理

技能内部封装了 Microsoft Fabric RTI MCP 服务，工作流程如下：

1. 认证：使用 Azure Identity（默认 Azure CLI 凭据）获取对 Fabric 工作区的访问令牌
2. 工具注册：启动后自动把 RTI 相关工具（查询、流管理、诊断等）暴露给客户端，模型根据意图选择工具
3. 调用链：客户端发送结构化参数，服务端完成 REST API 编排，返回 JSON 或自然语言总结

比如用户说“检查 Eventhouse 容量限制和最近 1 小时错误率”，代理会优先调用 kusto_diagnostics，解析返回的容量槽位、节点信息和权限上下文，再结合自定义 KQL 做深度排查。

适用边界

• 需要 Python 3.10+ 与 uvx 运行环境
• 调用者账号必须在 Fabric 工作区里拥有 RTI 相关 贡献者 权限
• 对高频大规模查询，建议自行实现查询缓存或限流，避免打满服务端配额
• 事件流目的地类型目前只覆盖常用模板（如事件中心、Webhook），更复杂的路由仍需在门户配置

如果你已经用 MCP 客户端做日常运维，这个技能可以把 Fabric RTI 从浏览器标签页里彻底挪进自动化流水线。