Real-Time AI with Fabric Eventhouse and the MCP Connector
How the Eventhouse MCP connector lets AI agents query live telemetry with KQL in Microsoft Fabric — architecture, patterns, and governance for real-time intelligence.
Most "real-time AI" demos are not real-time at all. They answer questions about data that landed in a lake hours ago, dressed up with a chat box. The genuinely hard problem — letting an autonomous agent reason over telemetry that is seconds old, safely, with an audit trail — is exactly what the Eventhouse MCP connector in Microsoft Fabric is built to solve.
This is the pattern we have been deploying at CC Conceptualise when clients need agents that act on live signal rather than yesterday's batch. It is also one of the more consequential 2026 additions to the Fabric AI stack, because it closes the gap between streaming analytics and agentic execution.
TL;DR / Key takeaways
- Eventhouse MCP exposes live KQL-queryable telemetry as a tool any AI agent can call. The agent asks in natural language; the MCP server generates and runs KQL against real-time data and returns structured results.
- The Eventhouse is the hot path; OneLake is the governed history. Use the Eventhouse for sub-second analytics over recent events and the medallion layers for curated, durable history.
- Schema quality determines answer quality. The language model grounds its KQL on your table and column metadata, so a well-modelled, documented Eventhouse is non-negotiable.
- Treat the MCP endpoint as a production interface from day one. Least-privilege identities, row/column security, and query logging are launch requirements, not clean-up tasks.
- It is the real-time tool for Fabric Data Agents and Copilot Cowork. Agents call Eventhouse MCP when a workflow needs live signal, then correlate with gold-layer data.
Why real-time changes the agent equation
Batch analytics and real-time analytics are not the same problem at a different speed; they are different problems. Batch answers "what happened" over a settled, curated dataset. Real-time answers "what is happening" over a moving target where the data you queried a second ago has already been superseded. For an AI agent, that distinction is decisive: an agent that can only see history can describe a problem, but an agent that can see live telemetry can intervene while it still matters.
The obstacle has always been the interface. Real-time stores like a Fabric Eventhouse are queried with KQL, a powerful but specialised language. Wiring an agent to a real-time store traditionally meant either pre-baking a fixed set of queries — which defeats the point of an autonomous agent — or trusting the agent to write correct KQL with no grounding, which produces confident nonsense. The Eventhouse remote MCP connector resolves this by putting a Model Context Protocol server in front of the Eventhouse. The agent expresses intent in natural language; the server, grounded in the Eventhouse schema, generates and executes the KQL and returns typed results.
This matters because MCP is the lingua franca of 2026 agent tooling. Any MCP-aware agent — a Fabric Data Agent, a Copilot Cowork session, or a custom Azure AI Foundry agent — can now treat your real-time intelligence estate as a first-class tool without bespoke integration code.
Where the Eventhouse sits in the Fabric estate
It helps to be precise about the layering, because conflating these workloads is the most common architectural mistake we see.
| Workload | Store | Query language | Best for | Latency profile |
|---|---|---|---|---|
| Real-Time Intelligence | Eventhouse | KQL | High-velocity events, time-series, logs, IoT telemetry | Sub-second over recent data |
| Curated analytics | Lakehouse / Warehouse (OneLake) | SQL / Spark | Historical, governed, medallion-layered data | Seconds to minutes |
| Streaming ingest | Eventstream | n/a (pipeline) | Routing and shaping events into the Eventhouse | Continuous |
| Semantic / BI | Power BI semantic model | DAX | Governed metrics and reporting | Interactive |
The Eventhouse is the hot path. It ingests high-velocity events — often via Eventstream — and serves sub-second KQL queries over the most recent window. OneLake remains the unified data lake holding your durable, governed history across the bronze, silver, and gold layers. A mature design uses both: the agent reaches into the Eventhouse for live signal and into the gold layer for the curated context that makes that signal meaningful.
A worked architecture
A typical real-time agent flow we deploy looks like this:
- Ingest. Telemetry — application events, device signals, transaction streams — lands in an Eventhouse via Eventstream, with minimal transformation on the hot path.
- Expose. The Eventhouse is published through its remote MCP endpoint, scoped to a dedicated agent identity with read-only access to a defined set of tables.
- Ground. Table and column names are modelled deliberately and documented so the MCP server's KQL generation is accurate.
- Query. An agent — a Fabric Data Agent or a Foundry agent — calls the MCP tool with a natural-language question. The server emits KQL, runs it, and returns structured rows.
- Correlate. The agent joins the live result against gold-layer context from OneLake (customer tier, asset criticality, SLA thresholds) to decide what the signal means.
- Act. The agent triggers a downstream action — an alert, a ticket, a remediation workflow — and the entire run, including every generated KQL statement, is logged.
The point of step 5 is worth dwelling on. Live telemetry in isolation is noise; an anomaly only matters relative to context. The combination of Eventhouse MCP for the hot path and OneLake gold for context is what makes the agent's reasoning sound rather than reactive.
Governance is the hard part, not KQL generation
The technology to generate KQL from natural language is impressive, but it is not where production programmes fail. They fail on governance. Three controls are non-negotiable before you expose an Eventhouse to agents.
Identity and least privilege. The MCP endpoint must be reached through a dedicated, least-privilege identity — never a broad service principal with estate-wide access. Scope it to the specific tables an agent needs and nothing more. A natural-language interface over an over-privileged identity is a prompt-injection amplifier: a crafted question becomes a crafted query against everything.
Row- and column-level security. Enforce data-access policies in the Eventhouse itself, not in the agent's prompt. The model must never be the security boundary. If a query should not return certain rows or columns for a given identity, that constraint belongs in the platform, where it is auditable and cannot be talked around.
Logging and observability. Every generated KQL statement, its parameters, and its result metadata must be logged. This is your audit trail, your debugging tool, and your evidence base. When an agent makes a decision on live data, you need to reconstruct exactly which query produced the signal it acted on. This discipline is the same one we apply to the broader lake; our notes on OneLake governance and security carry over directly to the real-time tier.
These controls also map cleanly onto European regulatory expectations. Where agents touch personal or operational data in essential-entity environments, NIS2, GDPR, and DORA all demand traceability, access control, and the ability to demonstrate human oversight. Building query logging and least-privilege scoping in from the start turns a compliance liability into evidence you already have.
How it fits with Data Agents and Copilot Cowork
The Eventhouse MCP connector is not a standalone product; it is the real-time tool in a larger agentic Fabric stack. Fabric Data Agents orchestrate autonomous, multi-step data workflows, and Copilot Cowork executes work across the platform. Both reach for the Eventhouse MCP endpoint when a workflow needs current signal rather than settled history.
A concrete example: a Data Agent monitoring a payments platform pulls the last few minutes of transaction telemetry through Eventhouse MCP, correlates failure rates against gold-layer merchant tiers and SLA thresholds in OneLake, and — if a threshold breaches — opens an incident and notifies the on-call team, logging every KQL statement and decision along the way. The architecture and orchestration of agents like this is something we cover in depth in our piece on Microsoft Fabric Data Agents architecture.
This is also where the rest of the 2026 Fabric MLOps story matters. Cross-workspace MLflow logging lets you bring models trained in Azure Databricks or Azure ML into Fabric, so the model an agent uses to score a live anomaly can be governed, versioned, and audited in the same estate as the data it scores. Real-time intelligence, agentic execution, and MLOps stop being separate islands.
A pragmatic adoption sequence
If you are bringing agents to your real-time estate, sequence it so that governance leads and scope follows.
- Model and document the Eventhouse schema. Deliberate names and clear documentation are what the MCP server grounds its KQL on. This is the single highest-leverage step.
- Define the security boundary. Create dedicated agent identities, scope them to specific read-only tables, and enforce row/column security in the platform.
- Enable query logging before any agent connects. You want the audit trail in place from the first query, not retrofitted after an incident.
- Pilot read-only against non-sensitive tables. Validate query accuracy and answer quality on low-risk data before widening scope.
- Add correlation with OneLake gold. Wire in the curated context that turns raw signal into a meaningful decision.
- Introduce action only with human oversight gates. Let the agent recommend before it acts autonomously, and keep an approval step where the regulatory classification demands it.
The temptation is to start with the impressive part — an agent answering live questions — and bolt on governance later. We have consistently found that inverting the order is faster overall, because retrofitting access control and audit logging onto a live agentic system is far more expensive than building them in.
The bottom line
The Eventhouse MCP connector is a genuine step change for real-time intelligence in Fabric: it makes live, KQL-queryable telemetry a callable tool for any MCP-aware agent, without bespoke integration or pre-baked queries. The engineering that matters is not the natural-language-to-KQL translation — Microsoft has handled that — but the architecture and governance around it: keeping the Eventhouse as the hot path and OneLake as the governed history, grounding generation in a well-modelled schema, and treating the MCP endpoint as a production interface with least-privilege identity, platform-enforced security, and complete query logging.
Get that foundation right and you have agents that act on what is happening, not what happened — safely, and with an audit trail your CISO and your regulator will both accept.
If you are designing real-time intelligence or agentic Fabric workloads and want a partner who has delivered them under European regulatory constraints, our AI and data platform team is happy to talk through your architecture.
FAQ
What is the Eventhouse MCP connector in Microsoft Fabric?
It is a remote Model Context Protocol endpoint that exposes a Fabric Eventhouse to AI agents. Instead of hand-writing queries, an agent sends a natural-language question, the MCP server translates intent into KQL, runs it against the real-time data in the Eventhouse, and returns structured results the agent can reason over. It turns live operational telemetry into a tool any MCP-aware agent can call.
How is an Eventhouse different from a Lakehouse or Warehouse in Fabric?
An Eventhouse is purpose-built for high-volume, high-velocity event and time-series data and is queried with KQL, optimised for sub-second analytics over recent telemetry. A Lakehouse and Warehouse sit on OneLake for batch and historical analytics over the medallion layers. In practice you use the Eventhouse for the hot, streaming path and OneLake for the curated, governed history; they complement rather than replace each other.
Do AI agents need to know KQL to use Eventhouse MCP?
No. The point of the MCP connector is that the agent works in natural language and the server generates and executes the KQL. That said, the quality of answers improves dramatically when the Eventhouse schema is well modelled, well named, and documented, because the language model uses that metadata to ground its query generation. Garbage schema produces plausible-but-wrong queries.
Is querying real-time data via natural language safe for production?
It can be, with the right guardrails. Scope the MCP endpoint to least-privilege identities, apply row-level and column-level security in the Eventhouse, log every generated query for audit, and treat natural-language input as untrusted to defend against prompt injection. The risk is not KQL generation itself; it is over-broad access and unlogged actions, which are governance problems you solve the same way you would for any data tool.
How does Eventhouse MCP fit with Fabric Data Agents and Copilot Cowork?
Fabric Data Agents orchestrate autonomous data workflows and Copilot Cowork executes multi-step work; the Eventhouse MCP connector is the real-time tool those agents call when a workflow needs live signal rather than batch history. A Data Agent might pull recent telemetry through Eventhouse MCP, correlate it with curated gold-layer data, and trigger an action — all in one governed run.
What does CC Conceptualise recommend before exposing an Eventhouse to agents?
Model and document the schema first, define the security boundary and the agent identities, enable query logging, and pilot against read-only, non-sensitive tables before widening scope. We treat the MCP endpoint as a production interface from day one, with the same identity, observability, and least-privilege discipline we apply to any other data service.
Topics