A Fabric Data Agent MCP server turns a published conversational data capability into a tool that external AI clients can discover and call. This removes custom integration code at the protocol layer, but it does not remove decisions about identity, authorization, client trust, model routing, data residency, logging, reliability, and answer quality.
Datrick treats the MCP connection as a production data interface. The pilot starts with one governed domain, one published Data Agent, one approved client, one identity pattern, and a bounded set of business questions. Expansion requires evidence that the tool is invoked correctly, returns defensible answers, respects permissions, and keeps sensitive data inside approved processing and retention boundaries.
Which AI client needs governed answers from Fabric, and under whose identity? Define that before copying an MCP endpoint into a client.
Understand the complete MCP request path
Microsoft documents a streamable HTTP endpoint for each published Data Agent. The client authenticates to Fabric, performs the MCP initialization handshake, discovers the single Data Agent tool, and calls it with a natural-language question. The Data Agent then selects an attached source, generates and validates SQL, DAX, or KQL as supported, executes under the calling identity, and returns an answer to the MCP client.
The endpoint is not a generic REST endpoint. A client that skips `initialize`, `tools/list`, or the expected `tools/call` message flow will fail even when the URL and token are valid. Dynamic client registration is not supported; the solution must acquire Fabric credentials through its own approved authentication flow and attach a bearer token to each request.
| Contract area | Implementation decision | Evidence required |
|---|---|---|
| Published Data Agent | Select sources, schema, instructions, examples, description, owner, release version, capacity, tenant, and supported question domain. | Published endpoint works, source bindings are production-approved, and baseline questions meet quality thresholds. |
| MCP endpoint | Use the workspace and Data Agent IDs from the approved production item; manage configuration by environment. | Client completes initialize, tool discovery, and tool call without hard-coded tool-name assumptions. |
| Tool description | Write a specific description of what the agent knows, when to call it, and what it cannot answer. | Orchestrator invokes the tool for in-domain questions and avoids it for out-of-domain requests. |
| Identity | Choose user, delegated, or service-principal behavior based on who should authorize each data query. | Effective access is tested for allowed and denied personas across every attached source. |
| MCP client | Approve the client, orchestrator, model, plugins, downstream tools, telemetry, retention, support access, and update process. | Data-flow and vendor review show where prompts and responses are processed, stored, and disclosed. |
| Runtime | Set timeouts, bounded retry, concurrency, token refresh, error handling, logging, correlation, and capacity safeguards. | Load and failure tests meet SLOs without retry amplification or secret leakage. |
| Lifecycle | Version agent definitions, client configuration, evaluation sets, permissions, publish state, and rollback procedures. | Dev-to-prod promotion and recovery preserve endpoint, identity, source, and answer behavior. |
Make the published description a routing control
The Data Agent publishes one MCP tool, and its published description becomes the tool description seen by clients and orchestrators. Generic descriptions such as “answers questions about company data” invite false-positive invocation and ambiguous routing. Name the domain, authoritative sources, supported metrics, time horizon, intended users, and exclusions in concise language. For Microsoft's managed agent platform, review the separate Foundry and Fabric Data Agent integration guide because its OBO identity path differs from direct MCP.
Evaluate tool selection separately from answer quality. The orchestrator can fail by not calling the Fabric tool when it should, by calling it for an unsupported question, or by combining its response with untrusted context from another tool. Test competing tools, ambiguous requests, prompt injection, multi-step tasks, and explicit no-answer behavior.
Choose identity before choosing the client
Every MCP request needs a Fabric bearer token with access to the target workspace and Data Agent. Microsoft documents user and service-principal tokens for the direct MCP endpoint. The Data Agent can query only attached sources available to that identity. Sharing the agent does not automatically grant source access.
A user token preserves per-user permissions and controls such as RLS and CLS, but requires an interactive or delegated authentication path the chosen client can support. A service principal enables unattended workloads, but all users of that application effectively operate through its fixed permissions unless the architecture adds a separate authorization layer. Treat that as a service identity, not a substitute for user-level authorization.
Microsoft currently documents no dynamic client registration and no managed-identity support for Data Agent authentication. Service principals need explicit access to every attached source, and Data Agents connected to KQL databases have a documented service-principal limitation. Keep direct MCP, Foundry tool integration, and other consumption channels separate: their supported identity patterns are not identical.
Assess the client and the data path, not only Fabric
| Risk | Test | Control |
|---|---|---|
| Compliance and geography | Trace prompts, generated queries, results, and answers across Fabric, client, orchestrator, model provider, telemetry, logs, and support systems. | Approve only clients and regions whose processing, storage, retention, and subcontractor terms meet the data classification. |
| Token exposure | Inspect source control, client configuration, logs, error traces, browser storage, CI/CD, support bundles, and memory handling. | Use approved credential flows, short-lived tokens, secure secret storage, rotation, redaction, and no token logging. |
| Excessive application access | Enumerate every workspace, agent, source, table, model, row, and column available to the service identity. | Use a dedicated principal and security group, least privilege, narrow sources, separation by sensitivity, and periodic recertification. |
| Cross-tool prompt injection | Feed malicious or conflicting content through user input and other connected tools; observe tool routing and data disclosure. | Separate instructions from data, constrain tool use, classify sources, filter untrusted context, and require approval for sensitive workflows. |
| Wrong or unsupported answer | Compare tool selection, source, generated query, raw result, narrative, citations, ambiguity, and refusal against ground truth. | Use deterministic evaluation, verified business definitions, clear tool descriptions, bounded use cases, and human review for high-impact decisions. |
| Uncontrolled client change | Review model, client, extension, dependency, tool configuration, logging, and policy changes across versions. | Pin and approve versions where possible, maintain an inventory, test upgrades, monitor release notes, and preserve a kill switch. |
| Availability and cost | Exercise token expiry, publication changes, invalid IDs, source failure, timeout, throttling, concurrency, and retries. | Use bounded retry with jitter, circuit breaking, explicit degradation, capacity monitoring, budgets, and tested incident response. |
Microsoft explicitly warns that Data Agent responses consumed through MCP can leave Fabric's compliance boundary or geographic region and be processed or stored under the MCP client's terms. This is an architectural control point. A Fabric permission review alone does not approve the full data flow.
Require a production-shaped pilot gate
- Verify prerequisites, tenant settings, published state, endpoint, client protocol support, token scope, and identity lifecycle.
- Measure tool-selection precision and recall with in-domain, adjacent, unsupported, adversarial, and multi-tool requests.
- Score answer correctness against expected source, generated query, raw result, business definition, narrative, and refusal behavior.
- Test allowed, restricted, and denied identities across agent sharing, source access, RLS, CLS, Purview policy, and client behavior.
- Validate client data handling, logging, telemetry, retention, deletion, vendor access, regional processing, and downstream tool boundaries.
- Load-test latency, concurrency, token refresh, timeout, retry, throttling, Fabric capacity impact, and recovery procedures.
- Approve expansion only when the use case has an owner, SLO, quality threshold, support path, cost envelope, incident runbook, and exit plan for preview change.
Run a three-to-five-week MCP implementation assessment
- Select one bounded business question domain, published Data Agent, approved client, orchestrator, identity pattern, and accountable data owner.
- Map the end-to-end data flow, compliance boundary, client terms, regions, telemetry, retention, dependencies, and consumption channels.
- Configure the production-shaped endpoint and authentication flow; establish least-privilege agent and source access for test personas.
- Refine the published tool description and build tool-selection, answer-quality, permission, adversarial, failure, performance, and cost tests.
- Exercise interactive and unattended paths where applicable, including token expiry, invalid IDs, unpublished state, source failures, and bounded retry.
- Deploy through controlled environments, run acceptance tests, verify observability and incident handling, and test disablement or rollback.
- Deliver the target architecture, identity and permission matrix, client risk review, test evidence, runbook, lifecycle controls, and go, limit, or stop recommendation.
Frequently asked questions
Can a Microsoft Fabric Data Agent be used as an MCP server?
Yes. Microsoft documents that a published Fabric Data Agent can expose a single tool through a streamable HTTP MCP endpoint. The client performs the MCP initialize, tool discovery, and tool call flow and attaches a valid Fabric bearer token. The feature is currently preview, so validate supported clients, identity behavior, data handling, reliability, and operational controls before production adoption.
Does the Fabric Data Agent MCP server support service principal authentication?
Microsoft documents that the MCP endpoint can accept a bearer token representing a user or a service principal. For unattended use, the service principal needs access to the published agent workspace and explicit read access to every attached source. Managed identities and dynamic client registration are not currently supported, and service principal authentication has documented source limitations including KQL Data Agent scenarios.
Does a Fabric Data Agent MCP server preserve user data permissions?
The Data Agent queries only sources available to the identity represented by the Fabric token, subject to source permissions and controls such as RLS and CLS. The identity architecture must be explicit: a shared service principal creates a different authorization model from per-user delegated access. Test effective access for every persona, source, client, and prohibited question rather than assuming that sharing the agent grants source access.
Can Fabric Data Agent MCP responses leave the Fabric compliance boundary?
Microsoft warns that responses consumed through an MCP client can be sent outside Fabric's compliance boundary or geographic region and processed or stored under the client's terms and data-handling policies. Assess the client, orchestrator, model provider, logging, retention, telemetry, support access, and downstream tools before exposing sensitive organizational data.
How long does a Fabric Data Agent MCP server implementation assessment take?
A focused production-shaped pilot can often be completed in three to five weeks for one published Data Agent, one approved MCP client, one identity pattern, and a representative question set. The work covers prerequisites, endpoint and client integration, identity, source permissions, tool description and routing, security tests, answer evaluation, observability, failure handling, and an adoption decision.
Official implementation references
- Fabric Data Agent as a Model Context Protocol server
- Service principal authentication with Fabric Data Agent
- Fabric Data Agent sharing and permission management
- Fabric Data Agent concept, governance, and limitations
- Fabric Data Agent with Microsoft Foundry agents
Start with one MCP client, one identity, and one governed question domain. Datrick can build the production-shaped connection, test security and answer quality, and deliver a defensible adoption decision.