Fabric IQ MCP Server：用自然语言查询Power BI语义模型

什么是 Fabric IQ MCP Server

Fabric IQ MCP Server 的核心作用，是为 AI 工具（例如智能体 Agent）打开一扇访问 Microsoft Fabric 资源的大门。具体到这个 MCP Server，它提供的是对**报表（reports）和语义模型（semantic models）**的访问能力。

理解它的定位有几个关键前提。首先，当前的访问是只读的——这意味着无论你用智能体执行什么操作，都不会对底层模型造成修改，这一点在企业数据治理场景下尤为重要，可以让人放心接入。其次，智能体获得的访问权限，严格遵循登录用户本身的权限。换句话说，它不会越权。

委托认证：权限如何传递

从智能体连接 MCP Server 时，使用的是**委托认证（delegated authentication）**机制。这是整个权限模型的核心逻辑：智能体由登录用户授权，因此它对语义模型、报表的访问范围，以及行级安全（Row-Level Security, RLS）和对象级安全（Object-Level Security, OLS）的限制，都会与登录用户完全一致。

这种设计意味着，如果你用自己的 Fabric 账号登录，智能体就"继承"了你的身份与权限边界。它既不会看到你无权访问的数据，也不会绕过已配置的安全策略——认证动作本身就决定了后续智能体能触达哪些功能。

选择启用MCP Server的属性配置

行级安全（RLS）和对象级安全（OLS）是 Power BI / Microsoft Fabric 中两种互补的数据访问控制机制。RLS 通过在语义模型中定义角色和 DAX 过滤规则，限制特定用户只能看到数据表中属于自己权限范围的行——例如，销售员 A 只能看到自己负责地区的销售记录。OLS 则工作在更粗粒度的层级，控制用户能否看到特定的表或列——如果某列被 OLS 隐藏，该用户不仅无法查询其值，连字段名称都不会暴露。委托认证与这两者的结合意味着：当智能体以用户身份执行 DAX 查询时，数据引擎会自动应用该用户对应的所有 RLS 过滤器和 OLS 可见性规则，智能体无法通过任何技术手段绕过这层限制，从根本上保证了多租户、多角色场景下的数据隔离。

配置流程：以 Copilot 为例

演示中使用 Copilot 作为接入的智能体客户端。整个配置过程并不复杂：

1. 注册 MCP Server

在用户主目录下找到 .copilot 文件夹，里面有一个 mcp-config.json 文件。用记事本打开后，按照官方文档配置 MCP Server 的 URL 即可。这个 URL 可以在配置文档中找到。

2. 启动并认证

配置完成后启动 Copilot，运行教程指定的命令。此时系统会要求认证——这一步至关重要，因为你在这里登录的 Fabric 用户，决定了智能体后续能探索哪些报表和语义模型。演示中由于机器已登录过，系统自动完成了认证，无需再次输入密码。

3. 在 Fabric 端启用开发者端点

需要注意，在 Fabric 的租户设置中有一项属性，控制"用户是否可以使用 MCP Server endpoint 进行开发"。只有启用这一项，才能成功连接到 Power BI 的 MCP，整个流程才会生效。

自定义使用量指标语义模型也被智能体识别

实际演示：芝加哥共享单车模型

演示用的是一个相当简单的语义模型，记录了芝加哥市公共自行车的所有骑行数据。每一次骑行都关联出发站点、到达站点、出发时间和到达时间，并与时间、站点、日期维度建立关系。

一切就绪后，直接用自然语言提问（演示用西班牙语）。第一个问题是"列出 Chicago Dev 工作区中存在的所有语义模型"。结果智能体不仅列出了用户亲手创建的两个模型，还识别出了基于使用量指标报表衍生的自定义语义模型——某种程度上，它比用户自己更了解这个工作区的内容。

官方文档中列出了各工具的说明

工具链是如何工作的

从演示可以看到 MCP Server 暴露的几个关键工具：

Discover Artifacts：用于查看 Fabric 租户中有哪些内容；
获取模型 Schema 的工具：让智能体理解语义模型的结构；
Execute Query：执行 DAX 查询，是真正拉取数据的核心工具。

当被问到"哪个是最重要的站点"时，智能体先获取模型 schema，再执行 DAX 查询，最终用西班牙语回答：发起骑行最多的站点是 Dusable Lake Shore，共 81,290 次。作者表示已通过报表核对过，结果准确无误。

芝加哥共享单车语义模型结构

DAX（Data Analysis Expressions）是 Microsoft 为 Power BI、Analysis Services 和 Excel Power Pivot 设计的公式语言，专门用于在列式内存数据模型上执行聚合、过滤和计算。与 SQL 不同，DAX 的计算逻辑围绕"行上下文"和"筛选上下文"展开，能够自动感知模型中表与表之间的关系，从而简化跨表聚合。在 MCP Server 的工具链中，Execute Query 工具的本质就是向 Power BI 数据集发送 DAX 查询请求，由 Analysis Services 引擎在 Fabric 端执行并返回结果集。智能体先读取模型 Schema（包括表名、列名、度量值定义和关系），再据此自动生成语义准确的 DAX 语句——这一"理解结构→生成查询"的两步流程，是自然语言问答能够落地为精确数值的技术基础。

容量消耗的关键细节

一个容易被忽视但影响成本的要点是：在这种模式下，模型推理不消耗 Fabric 容量。

原因在于，这里执行处理的是智能体关联的模型（如 Copilot 自身的模型），而不是 Fabric 内置的模型。两者有本质区别——如果你在 Fabric 内创建一个 Agent，那个 Agent 会消耗 Fabric 容量来执行模型处理；而通过 Copilot 这类外部客户端接入 MCP Server，处理由客户端一侧的模型承担。

这也揭示了 MCP 协议的开放性：Copilot 并非唯一选择。任何具备连接 MCP Server 能力的客户端——包括 Google 的同类智能体——理论上都能以同样的方式接入 Fabric 的报表和语义模型，实现完全相同的自然语言查询体验。

MCP（Model Context Protocol）是由 Anthropic 于 2024 年末提出并开源的标准协议，旨在统一 AI 智能体与外部工具、数据源之间的通信接口。其设计思想类似于 USB 接口对硬件外设的标准化——只要服务端实现了 MCP Server 规范（暴露工具列表、处理工具调用请求），任何兼容 MCP 的客户端都能自动发现并调用这些工具，无需为每一对"智能体×数据源"单独开发集成代码。Microsoft 将 Fabric IQ 实现为 MCP Server，意味着它在协议层面与具体智能体品牌解耦：Claude、Copilot、Cursor 或其他任何 MCP 兼容客户端，理论上都能用同一套接入方式查询 Power BI 数据，这也是文中提到 Google 智能体同样可接入的底层原因。

小结

Fabric IQ MCP Server 展示了一条清晰的路径：让 AI 智能体以安全、受权限约束的方式访问企业 BI 资源。只读访问保障了数据安全，委托认证继承了用户权限与 RLS/OLS 策略，而标准化的 MCP 协议则意味着你不必被绑定在单一智能体生态中。对于希望用自然语言与 Power BI 数据对话的团队来说，这是一个值得关注的接入方式。