DEV Community: Kartik Anand

# The Enterprise MCP Registry: Why APIM is the Right Home for Governed AI Tool Access

Kartik Anand — Sun, 05 Jul 2026 15:16:51 +0000

By Kartik Anand, Cloud & AI Architect | Agentic Systems on Azure

— -

Every enterprise AI team is solving the same problem independently right now: how do we connect our AI agents to our data systems?

Each team figures out the MCP connection. Each team handles auth. Each team builds their own retry logic. Each team manages their own observability. And when something breaks at 2am, nobody knows which agent called which system or why.

There’s a better pattern. And most organizations already own the infrastructure to build it.

— -

The Problem with Point-to-Point MCP Connections

Model Context Protocol is the right abstraction for connecting AI agents to data systems. Snowflake exposes a managed MCP server. Databricks is building one. ServiceNow, SAP, and a dozen other enterprise platforms are following. The protocol is winning.

But most implementations today look like this:


ClaimsAgent. → Snowflake MCP (custom auth, custom retry)

PharmacyAgent. → Databricks MCP (different auth, different retry)

OpsAgent. → Fabric Data Agent (different auth again)

TicketingAgent. → ServiceNow MCP (yet another auth pattern)

Point-to-point. No consistency. No central observability. No governance. Every team reinventing the same wheel with slightly different spokes.

This is the microservices sprawl problem, arriving in the MCP era right on schedule.

— -

APIM as the Enterprise MCP Registry

Azure API Management is already the right answer to this problem. It’s what you put in front of APIs when you need consistent auth, retry, rate limiting, versioning, and observability across a heterogeneous set of backends. MCP servers are APIs. The same governance logic applies.

The pattern:


Any AI Agent

. → APIM (Enterprise MCP Gateway)

. ├── /mcp/snowflake-claims. → Snowflake CLAIMS_MCP

. ├── /mcp/databricks-pharmacy → Databricks Genie

. ├── /mcp/fabric-hospitalops. → Fabric Data Agent

. ├── /mcp/sap-finance. → SAP MCP server

. └── /mcp/servicenow-tickets. → ServiceNow MCP server

Every MCP server in the enterprise gets a consistent, governed endpoint. Any AI agent calls /mcp/snowflake-claims — it doesn’t know or care what’s behind it. The agent’s job is reasoning. APIM’s job is everything else.

— -

What You Get Per MCP Endpoint

Become a Medium member
Auth normalization. Every backend has its own authentication requirement. Snowflake wants one thing. ServiceNow wants another. APIM normalizes it — the agent sends its Entra ID token once, APIM handles the translation to whatever the backend expects. No agent ever holds a backend credential directly.

Retry per endpoint. Snowflake’s Cortex Agent cold start behavior is different from Databricks Genie’s. Point-to-point connections handle this inconsistently or not at all. APIM lets you define the right retry policy for each backend independently — exponential backoff, max attempts, timeout — without touching agent code.

Rate limiting. One rogue agent shouldn’t be able to hammer a shared Snowflake instance. APIM enforces per-caller, per-endpoint limits. The agent gets a clean error. The backend stays healthy.

Versioning. /mcp/snowflake-claims/v1 and /v2 coexist while teams migrate. Agents that haven’t updated yet keep working. No big-bang cutover.

Unified observability. Every MCP call across every backend flows through one logging layer. When something breaks at 2am, you have one place to look — which agent called which MCP server, what it sent, what came back, how long it took, whether it retried. This is the operational capability that makes the difference between a demo and a system.

Discovery. APIM’s developer portal becomes your internal MCP catalog. Teams browse available MCP servers like an API marketplace — here’s what data sources your AI agents can reach, here’s how to connect, here’s the schema. New agents don’t start from scratch. They pick from the catalog.

— -

The Organizational Story

Right now, connecting an AI agent to Snowflake requires knowing Snowflake’s MCP endpoint, handling their auth pattern, building retry logic, and figuring out observability. Every team does this independently.

With APIM as the registry, that’s solved once, centrally, by the platform team. A new specialist agent doesn’t think about infrastructure. It thinks about its domain:

“I need claims data → call /mcp/snowflake-claims”

“I need hospital ops → call /mcp/fabric-hospitalops”

The platform team owns the registry. Domain teams own their agents. Clear separation. Clean ownership. This is how enterprise AI infrastructure actually scales.

— -

Why This Isn’t Being Built Yet

Most organizations are still on their first or second MCP connection. The governance problem doesn’t feel urgent when you have two endpoints. It feels very urgent when you have twenty, owned by five different teams, called by a dozen agents, with no central visibility.

The teams building MCP connections today are AI engineers. The teams that would naturally own a registry like this — platform engineering, API governance, cloud architecture — aren’t in the MCP conversation yet. That gap is where the mess accumulates.

The organizations that build this registry now, before the sprawl sets in, will have a meaningfully better operational posture when the number of MCP connections scales.

— -

What This Looks Like in Practice

In the architecture I’ve been building — an A2A orchestration platform across Snowflake and Microsoft Fabric — APIM already sits in front of the escalation action layer. The natural next step is extending that same APIM instance to front every MCP connection, not just the action tools.

One APIM instance. Multiple MCP backends. Consistent governance across all of them. Any new data source the organization wants to make available to AI agents gets added as a new route — auth configured once, retry policy set, logging enabled, added to the catalog.

That’s the enterprise MCP registry. It’s not a new product. It’s a new use of infrastructure you probably already have.

— -

The Three Things to Build First

If you’re starting today:

1. Route your first MCP connection through APIM. Pick your highest-value MCP server — probably Snowflake or Databricks if you have them — and put APIM in front of it. Add the inbound auth policy and a basic retry policy. That’s your registry with one entry.

2. Standardize the URL pattern. Establish /mcp/{platform}-{domain} as your naming convention before you have ten endpoints. Renaming later is painful.

3. Enable logging to Application Insights. One line in APIM policy. You’ll thank yourself the first time something fails and you need to know why.

Everything else — versioning, rate limiting, the developer portal catalog — follows naturally once the first connection is clean.

— -

The MCP ecosystem is moving fast. The governance layer is moving slower. The organizations that close that gap early will have the operational foundation to scale agentic AI without the chaos that usually follows platform adoption at speed.

— -

Part of a series on enterprise agentic AI architecture. Full reference implementation: HealthIQ Multi-Agent A2A Architecture · Deep dive: Building a Multi-Agent A2A Architecture on Snowflake and Microsoft Fabric

Kartik Anand — Cloud & AI Architect | LinkedIn · GitHub

# Building a Multi-Agent A2A Architecture on Snowflake and Microsoft Fabric — Without Replacing Either

Kartik Anand — Sun, 05 Jul 2026 15:13:15 +0000

Every enterprise healthcare payer I work with has the same problem.

They have years of investment in Snowflake — semantic models, claims analytics, carefully curated data products. They have Microsoft Fabric rolling out across their organization — lakehouses, Delta tables, real-time intelligence. They have Azure OpenAI licenses and ambitious AI roadmaps.

And they’re asking the same question: how do we put AI on top of all of this without ripping anything out?

This is the story of how I built HealthIQ — a unified healthcare intelligence platform that answers that question with a working, production-grade architecture.

— -

The Problem With “AI on Your Data”

Most “AI on your data” demos show a chatbot connected to a single database. Ask it a question, it writes SQL, returns an answer. Clean. Simple. And completely inadequate for enterprise healthcare.

Real healthcare analytics doesn’t live in one place. Claims financials live in Snowflake. Bed occupancy and staffing data live in Fabric lakehouses. Clinical policy documents live in document stores. Escalation workflows live in Logic Apps. Getting a complete picture of operational health requires crossing all of these — in a single, coherent answer.

The naive solution is to build one giant agent with every tool attached. I’ve seen this fail. At scale, a single agent juggling ten tools loses coherence. Routing degrades. Context windows fill up. The model gets confused about which tool to call when.

There’s a better pattern.

— -

The Architecture: Five Tiers, Two Specialists, One Orchestrator

HealthIQ is built on a five-tier architecture with a multi-agent A2A (Agent-to-Agent) orchestration layer on top.

Press enter or click to view image in full size

Tier 1 — Structured Analytics: Snowflake Cortex Agent

The foundation is a Snowflake semantic view (CLAIMS_SEMANTIC) that exposes curated claims metrics — total paid amounts, PMPM cost, denial rates by specialty, DRG utilization — as named business concepts rather than raw tables.

On top of that semantic view sits a Snowflake Cortex Agent, exposed as a managed MCP (Model Context Protocol) server. This means any AI orchestrator can call it with natural language and get back structured analytics — without writing a line of SQL.


Q: What were total claims paid in Q1 2026?

A: $370,685,724.65

Tier 2 — Operational Intelligence: Microsoft Fabric Data Agent

Four Delta tables in a Fabric Lakehouse capture hospital operational data — bed occupancy, staffing ratios, patient volume, authorization status. A Fabric Data Agent (HospitalOpsAgentV2) sits on top of these tables and answers operational questions in natural language.


Q: Which facility has the highest occupancy?

A: Riverside Health (Southeast) at 92%

Tier 3 — Document Intelligence: Azure AI Search RAG

A RAG layer built on Azure AI Search indexes a curated set of clinical policy documents, CMS benchmark reports, and medical director summaries — included here to showcase the pattern. In practice, this layer can connect to your existing document stores: SharePoint libraries, Azure Blob Storage, OneLake files, or any indexed enterprise content. The point isn’t the five documents I loaded — it’s that your existing knowledge assets become part of the reasoning chain without any restructuring. When the AI needs to explain why a metric looks the way it does — not just what the number is — it pulls context from this layer.

Tier 4 — Orchestration: Azure AI Foundry

This is where the intelligence lives. Two specialist agents coordinate through an A2A protocol:

ClaimsIntelligenceAgent — owns everything financial. It has access to the Snowflake MCP tool and the Policy Search RAG layer. It knows claims analytics the way a Senior Actuary knows claims analytics.

HospitalOpsAgent — owns everything operational. It has access to the Fabric Data Agent and an escalation workflow. It knows clinical capacity the way a COO knows clinical capacity.

Above them sits HealthcareOrchestratorV3 — a master agent that does no data access directly. Its only job is to understand the question, route to the right specialist(s), and synthesize their responses into a single executive answer. I chose GPT-4.1 for both the specialists and the synthesis step — the routing and cross-domain reasoning needed reliable structured output more than raw speed, and GPT-4.1 held up consistently across multi-turn agent calls without drifting off format.

Tier 5 — Action: Azure API Management + Logic App

This is where AI stops being a reporting layer and becomes an operational system. The action tier is unlimited in scope — constrained only by your business case, not the technology. Trigger a care management workflow. Update a claims record. Open a ServiceNow ticket. Push a notification to a clinical team. Invoke an RPA bot. Any system reachable via API becomes an action the AI can take.

For this showcase, I kept it simple: when occupancy hits 92% and the user asks to escalate, the orchestrator delegates to HospitalOpsAgent, which calls an APIM-proxied Logic App and delivers an escalation email to the care management team. The full loop — question to action — closes in one conversation. The email is illustrative. The pattern is production-grade.

— -

The A2A Pattern: Why It Matters

The key architectural insight is the separation between specialists and orchestrators.

Each specialist agent is small, focused, and owns its own tools. ClaimsIntelligenceAgent doesn’t know anything about bed occupancy. HospitalOpsAgent doesn’t know anything about PMPM cost. They’re experts in one domain.

The master orchestrator doesn’t touch data directly. It reasons about the question and delegates. For a cross-domain question like ”which hospitals have the highest occupancy and how does that correlate with our denial rates?” — it calls both specialists in parallel, waits for both responses, and synthesizes them into one answer.

This is how enterprise AI scales. Not one monolithic agent that knows everything, but a network of specialists coordinated by an orchestrator. As your data estate grows, you add specialist agents — one per domain, owned by the team that knows that data best. The orchestrator barely changes.


HealthcareOrchestratorV3

├── ClaimsIntelligenceAgent → Snowflake + Policy RAG

└── HospitalOpsAgent → Fabric Lakehouse + Escalation

— -

What This Enables for Healthcare Payers

For a managed care organization, this architecture answers the questions that actually matter:

”What’s driving our Cardiology denial rate, and how does it compare to CMS national benchmarks?” — Claims agent pulls the rate, RAG layer pulls the benchmark and the medical director’s context.
”Which facilities are at critical capacity right now?” — Ops agent returns live occupancy across all facilities, flags anything above 90%.
”Send an escalation alert for Riverside Health” — Ops agent calls the escalation workflow, email goes to the care management team, confirmation comes back in the chat.

All of this in a single Teams conversation. No SQL. No dashboard hunting. No switching between systems.

The “Aha” Moment for Enterprise AI

The insight that makes this architecture resonate with enterprise clients is simple:

You don’t need to centralize your data to centralize your intelligence.

Snowflake stays in Snowflake. Fabric stays in Fabric. Each system keeps its own governance, its own semantic layer, its own access controls. The AI orchestration layer sits on top and coordinates — it doesn’t absorb.

This is how you sell AI to an organization that has spent years building a data estate and isn’t going to blow it up for a chatbot.

— -

The Production Detail That Matters: APIM as a Proxy

Here’s the real-world detail that demos never show you.

Azure AI Foundry’s OpenAPI tool redacts query parameters before making HTTP calls. If your API uses query string authentication — SAS tokens, API version parameters — they get stripped to ?REDACTED before the call goes out.

The fix: put Azure API Management in front. Foundry sends a clean call with just an Ocp-Apim-Subscription-Key header. An APIM inbound policy uses set-backend-service and rewrite-uri to reconstruct the full URL with all parameters before forwarding. Foundry never sees the sensitive parameters. The API works correctly.

This is the kind of pattern that separates a demo from a production architecture.

Become a Medium member
There’s a second reason APIM belongs in this architecture, and it matters more than the redaction workaround: identity and access control. No enterprise lets AI agents call backend systems anonymously, and an API gateway is exactly where you enforce that. APIM ties into your identity provider — Entra ID, OAuth, whatever your enterprise standardizes on — so every call from an agent carries a verifiable identity, not just a static key. You get centralized logging of who (or what agent) accessed which system and when, rate limiting per caller, and the ability to revoke access without touching the agent itself. For a healthcare payer handling PHI-adjacent operational and claims data, that audit trail isn’t optional — it’s the control that makes the rest of this architecture deployable in production.

— -

Guardrails and Observability: The Parts That Make This Trustworthy

A working demo and a deployable system are different things. Two Foundry capabilities close that gap.

Guardrails. Azure AI Foundry lets you attach guardrails directly to each agent — content filtering, jailbreak detection, and groundedness checks that run before a response ever reaches the user. In a healthcare context this matters concretely: you don’t want an agent confidently answering a clinical policy question from a hallucinated detail, and you don’t want a claims agent exposed to prompt injection through a malformed query. Guardrails sit at the agent level, so each specialist enforces its own policy independent of how the orchestrator routes to it.

Tracing. Every agent call in Foundry — including the A2A hops between the orchestrator and each specialist — generates a trace. When a cross-domain question comes back wrong, or a tool call fails, the trace shows exactly which agent was invoked, what arguments it passed, what the tool returned, and how long each step took. This is the difference between debugging a black box and debugging a system. I used traces directly to diagnose a token-fetch failure in same-project A2A calls — without that visibility, it would have been a guessing exercise.

For any architecture handling claims or clinical data, guardrails and tracing aren’t optional extras. They’re what a security or compliance review will ask about first.

— -

What I’d Harden Before Calling This Production-Ready

It’s worth being honest about what a demo glosses over.

Error handling. Specialist agents occasionally hit transient failures — an MCP server timeout, a token refresh delay. Right now the orchestrator surfaces the error in its synthesis rather than retrying silently, which is the right behavior for a demo but needs a proper retry-with-backoff policy in production, plus a fallback message that doesn’t expose internal error text to the end user.

Cost and latency. Every specialist agent call has its own cost and latency profile. A cross-domain question that fans out to two agents in parallel costs roughly double a single-domain question and adds the synthesis call on top. At scale, the routing logic should account for this — not every question needs both specialists, and the keyword-based router I built for this showcase is a placeholder for a more deliberate semantic routing decision in GPT-4.1 itself.

Same-project A2A auth. As of this writing, Foundry’s native A2A wiring for same-project agents has rough edges around managed identity token exchange. I worked around it with a Python orchestration layer calling each agent’s A2A endpoint directly — which works well, but native in-Foundry publishing to Teams is the cleaner long-term path once that matures.

None of these are dealbreakers. They’re the normal gap between “I proved the pattern works” and “this is hardened for production traffic” — and naming that gap honestly is part of doing this work seriously.

— -

Tradeoffs I Considered and Rejected

Every architectural choice here had a simpler alternative I deliberately didn’t take. Naming them — and why — matters more than the choice itself.

A2A specialists vs. one agent with many tools. The simpler path is a single agent with every tool attached: Snowflake MCP, Fabric Data Agent, RAG, escalation, all in one system prompt. I rejected this after watching it degrade in practice. Past roughly five or six tools, a single agent starts misrouting — calling the wrong tool, or calling the right tool with the wrong framing because it’s reasoning about ten things at once instead of one. The single-agent model also has an organizational failure mode that matters more long-term than the technical one: it has no clean ownership boundary. If the claims team and the ops team are both editing the same agent’s system prompt and tool list, you get merge conflicts in intent, not just in code. A2A specialists cost you orchestration overhead and an extra synthesis call. What you get back is a system where each team owns a contained blast radius, and a routing failure in one specialist doesn’t take down the other. For two specialists, the overhead is a fair trade. For ten, it’s close to mandatory.

API gateway vs. native Foundry connectors. Foundry’s native OpenAPI and MCP tool support is the path of least resistance, and I started there. I moved to an APIM-fronted pattern for two reasons that aren’t visible in a demo. First, the practical one: Foundry’s OpenAPI tool redacts query parameters, which silently breaks any backend using query-string auth — there’s no native workaround inside Foundry itself. Second, the more important one: native connectors authenticate with a static key the agent holds directly. That’s acceptable for a prototype and not acceptable for a system touching claims or clinical data in an enterprise with an identity-provider standard. The gateway costs you one more hop and one more resource to operate. It buys you centralized identity enforcement, audit logging, and the ability to revoke a single caller’s access without touching the agent. For a regulated industry, that’s not a nice-to-have — it’s close to a requirement once this leaves the sandbox.

GPT-4.1 vs. a larger frontier model. I deliberately did not reach for the most powerful available model. The reasoning load in this architecture is mostly routing and structured synthesis — deciding which specialist to call, and combining two already-coherent responses into one — not open-ended novel reasoning. GPT-4.1 holds format reliably across multi-turn agent calls, which matters more here than raw capability, and it’s meaningfully cheaper and faster at the volume an orchestration layer like this generates, since every user question can trigger two to three model calls under the hood. The tradeoff I’m explicitly making is ceiling for cost and latency: if a future specialist needs to do something closer to genuine multi-step clinical reasoning rather than structured retrieval-and-synthesis, that specific agent should probably sit on a more capable model while the orchestrator stays lightweight. Model choice in a multi-agent system doesn’t have to be uniform, and treating it as a single decision for the whole architecture is itself a mistake worth avoiding.

What changes at 20 specialists instead of 2. This architecture works cleanly at two specialists with keyword-based routing. It does not survive unchanged at twenty — the router has to become semantic rather than keyword-based, classifying intent against a registry of agent capabilities instead of matching against a static list of trigger words. The deeper shift is that operational discipline which is manageable per-agent at this scale — tracing, guardrails, governance — has to become a platform-level concern rather than something each specialist handles on its own. I cover what that looks like concretely further down. None of this invalidates the pattern; it’s the normal maturity curve from proof-of-concept to platform, and it’s worth being explicit that this piece describes the former.

— -

Everything That Went Into This

It’s worth listing what actually got built, because the architecture diagram understates the amount of plumbing underneath it. None of this is glamorous, and all of it was necessary.

Data and semantic layer

Snowflake semantic view (CLAIMS_SEMANTIC) exposing claims metrics as named business concepts
Snowflake Cortex Agent configured and published as a managed MCP server
Microsoft Fabric Lakehouse with four Delta tables modeling hospital operations
Fabric Data Agent built and tuned against those tables
Azure AI Search index populated with clinical policy documents for the RAG layer

Agents and orchestration

Two specialist agents (ClaimsIntelligenceAgent, HospitalOpsAgent) built in Azure AI Foundry, each with its own system prompt, tool set, and guardrail configuration
A master orchestrator (HealthcareOrchestratorV3) coordinating both specialists via the A2A protocol
A Python-based orchestration layer as a fallback path, handling routing, parallel agent calls, and GPT-4.1 synthesis directly against each agent’s A2A endpoint

Identity and security

System-assigned managed identities enabled on the Foundry resource and, separately, on the Function App used for the API wrapper — turning these on isn’t a checkbox, it required explicit role assignments at the resource scope rather than relying on subscription-level inheritance
Azure AI Developer role explicitly granted to each managed identity at the project/resource scope it needed to call
Entra ID-based authentication wired into the A2A tool connections in place of static keys
APIM configured with subscription-key and identity-aware policies in front of every externally-callable tool

Integration and action layer

Azure API Management instance fronting the Snowflake MCP connection, with inbound policies (set-backend-service, rewrite-uri) to work around Foundry’s query-parameter redaction on OpenAPI tools
A second APIM-proxied connection in front of a Logic App for the escalation email workflow
Teams channel publishing for the production-facing orchestrator

Operational tooling

Guardrails configured per agent for content filtering and groundedness
Full request tracing enabled across both specialist agents and the orchestrator, used directly to diagnose a same-project A2A token-fetch failure
Python test harnesses validating each A2A endpoint independently before wiring them into the orchestrator

The unglamorous truth about agentic AI architecture is that the agent logic is maybe 30% of the work. The other 70% is identity, networking, observability, and the small production-grade fixes — like the APIM redaction workaround — that never show up in a demo but determine whether the thing actually ships.

— -

The Real Takeaway: This Is a Blueprint, Not a One-Off

Strip away the healthcare specifics and what’s left is a reusable pattern: take a large, ambiguous problem, decompose it into narrow specialist agents that each own one domain and one set of tools, and coordinate them with a master orchestrator that does routing and synthesis but touches no data directly. Claims and hospital operations are this instance of the pattern. The pattern itself applies anywhere a problem is too broad for one agent to reason about coherently but naturally splits along domain lines — financial services, supply chain, IT operations, customer support, regulatory compliance. The five tiers map differently each time; the shape doesn’t change.

What makes a blueprint actually reusable, though, isn’t the happy-path architecture diagram — it’s the checklist of what every specialist agent has to support before it’s allowed into the system, regardless of domain. This is the part teams skip when they’re moving fast, and the part that turns into an incident six months later when they didn’t.

The minimum bar for any specialist agent joining the platform:

Guardrails — content filtering, jailbreak detection, and groundedness checks configured at the agent level, not assumed to be inherited from the orchestrator
Tracing — full request/response tracing enabled by default, not added reactively after the first hard-to-diagnose failure
Identity — authenticates through the gateway with a verifiable identity (Entra ID or equivalent), never a static key held by the agent itself
Tool ownership boundary — a specialist’s tools are its own; no shared mutable state or shared credentials across specialists
Failure mode defined — an explicit answer to “what does this agent return when its tool fails,” not a default that leaks a stack trace to the end user
Cost and latency budget — a known per-call cost and latency profile, so the orchestrator’s routing decisions can be made with that cost visible, not discovered later in a bill
Ownership and versioning — a named team or owner, and a way to version the agent’s prompt and tools without breaking the orchestrator’s contract with it
Onboarding contract with the orchestrator — a clear description of what the agent does and doesn’t handle, so routing logic (keyword-based or semantic) has something accurate to route against

None of these are exotic. Most of them are the same governance disciplines that already exist for microservices, just translated to agents. The mistake is assuming agentic systems get a pass on that discipline because they’re new — they don’t, and the organizations that figure this out early are the ones who get past two specialist agents to twenty without the whole thing becoming unmanageable.

— -

What’s Next

The agent marketplace model is the natural evolution. Today HealthIQ has two specialists — claims and hospital ops. In six months it could have ten: pharmacy, member engagement, regulatory compliance, prior authorization, quality metrics. Each owned by the team that knows that domain best. Each an independent A2A agent that plugs into the master orchestrator.

The orchestrator barely changes. The intelligence scales linearly.

That’s the architecture worth building toward.

— -

Kartik Anand is a Cloud & AI Architect at Microsoft working on enterprise data platform engagements in healthcare. He specializes in agentic AI architectures on Microsoft Fabric, Azure AI Foundry, and Snowflake.

Interested in building something similar? Connect with me on LinkedIn.

# Your Security Team Is Right to Block Local MCP Connections. Here’s the Alternative.

Kartik Anand — Thu, 02 Jul 2026 22:19:37 +0000

# Your Security Team Is Right to Block Local MCP Connections. Here’s the Alternative.

**By Kartik Anand, Cloud & AI Architect | Agentic Systems on Azure**

— -

A healthcare enterprise I work with recently blocked their developers from connecting to MCP servers from local machines. The security team’s reasoning was straightforward: no audit trail, no identity enforcement, no rate limiting, no data loss prevention. Any developer connecting their laptop directly to a Fabric or Power BI MCP server is an ungoverned connection in an environment that can’t afford ungoverned connections.

They were right to block it.

The problem is they had no alternative to offer. Developers who wanted to use AI agents with their Fabric data were told no — full stop. The capability existed, the need existed, and the security posture made it inaccessible.

I built a POC in an afternoon that changes that answer from “no” to “yes, through the right channel.”

— -

## The Problem With Local MCP Connections at Scale

Model Context Protocol is the right abstraction for connecting AI agents to enterprise data systems. Snowflake, Microsoft Fabric, Power BI, Databricks — they’re all building managed MCP servers. The protocol is winning and the ecosystem is accelerating.

But the default implementation pattern looks like this:


Developer laptop → Fabric MCP server (direct)

Developer laptop → Power BI MCP server (direct)

Developer laptop → Snowflake MCP server (direct)

Point-to-point. Each developer managing their own connection, their own credentials, their own everything. No consistency. No governance. No visibility into who called what and when.

For a consumer use case, that’s fine. For an enterprise healthcare environment handling PHI-adjacent data, that’s a compliance problem waiting to happen. The security team’s instinct to block it isn’t obstruction — it’s the right call.

— -

## The Pattern: API Management as an Enterprise MCP Gateway

Azure API Management is already the right answer to ungoverned API access. It’s what you put in front of APIs when you need consistent auth, retry, rate limiting, versioning, and observability across heterogeneous backends. MCP servers are APIs. The same governance logic applies.

The architecture:

Developer Machine (VS Code / Claude Desktop)

→ Enterprise APIM Gateway (/mcp/fabric)

→ Microsoft Fabric Core MCP Server

(api.fabric.microsoft.com/v1/mcp/core)


The developer never touches the MCP server directly. They point their MCP client at the APIM endpoint. APIM validates their identity, enforces rate limits, exchanges tokens, forwards the request, logs the result, and returns the response. The MCP server sees a valid, governed request. The developer gets their answer.

What the security team gets:

- **\*\*Identity enforcement\*\***  — every call validated against Entra ID before it reaches Fabric

- **\*\*Audit trail\*\***  — every call logged with caller identity, timestamp, status, and duration

- **\*\*Rate limiting\*\***  — one developer can’t hammer a shared MCP server and impact others

- **\*\*No credential sprawl\*\***  — developers never hold Fabric credentials directly, only an APIM subscription key and their own Entra token

- **\*\*Single revocation point\*\***  — disable a developer’s subscription key without touching Fabric or the MCP server

What the developer gets: full Fabric MCP access, from VS Code or Claude Desktop, governed and audited. The answer changes from “no” to “yes, through the right channel.”

**— -**

**## What Microsoft Fabric Core MCP Actually Exposes**

Before building the gateway, it’s worth knowing what’s on the other side. Microsoft Fabric Core MCP Server is a remote, Microsoft-hosted endpoint at:

https://api.fabric.microsoft.com/v1/mcp/core


It exposes 27 tools across five capability areas:

- **\*\*Workspace management\*\***  — list, get, create, update, delete workspaces

- **\*\*Item management\*\***  — list, get, create, update, delete, move Fabric items (Lakehouses, Warehouses, Notebooks, Data Agents, Semantic Models, Eventhouses, Pipelines)

- **\*\*Role management\*\***  — full RBAC management via natural language

- **\*\*Catalog search\*\***  — search across the entire Fabric estate

- **\*\*Knowledge\*\***  — Fabric documentation and capability discovery

In practice, a developer in VS Code with GitHub Copilot Agent mode can ask:

What Fabric workspaces do I have access to?

List all items in the Clinical Data workspace

Search the catalog for anything related to claims


And get structured, accurate responses drawn from their actual Fabric environment — through the governed gateway, with every call logged.

**— -**

**## Building It: The APIM Policy That Makes It Work**

The core of the implementation is an APIM inbound/backend/outbound policy that handles auth, token exchange, retry, rate limiting, and audit logging in one place.

**\*\*Step 1 — Create a backend pointing to Fabric Core MCP:\*\***

In APIM → Backends → Add:

- Name: `fabric-core-mcp-backend`

- Runtime URL: `https://api.fabric.microsoft.com/v1/mcp/core`

**\*\*Step 2 — Create an API with suffix `/mcp/fabric` and a wildcard POST operation.\*\***

**\*\*Step 3 — Apply this policy:\*\***

xml

<! — Validate the developer’s Entra ID token →

<validate-jwt header-name=”Authorization”

failed-validation-httpcode=”401"

failed-validation-error-message=”Valid Entra ID token required”>

https://api.fabric.microsoft.com

https://sts.windows.net/{tenant-id}/

<! — Capture caller identity for audit →

<set-variable name=”caller-upn”

value=”@(context.Request.Headers.GetValueOrDefault(“Authorization”, “unknown”))” />

<! — Exchange for managed identity token to call Fabric →

<authentication-managed-identity

resource=”https://api.fabric.microsoft.com"

output-token-variable-name=”fabric-mi-token” />

<! — Replace developer token with MI token →

@(“Bearer “ + (string)context.Variables[“fabric-mi-token”])

<! — Rate limit: 100 calls per minute per developer →

<rate-limit-by-key calls=”100"

renewal-period=”60"

counter-key=”@(context.Subscription.Id)”

increment-condition=”@(true)” />

<! — Route to Fabric Core MCP backend →

<! — Retry on transient failures and cold start →

<retry condition=”@(context.Response.StatusCode == 503 ||

context.Response.StatusCode == 429 ||

context.Response.StatusCode == 500)”

count=”3" interval=”2" delta=”2" max-interval=”10">

<! — Audit trace to Application Insights →

“caller=” + (string)context.Variables[“caller-upn”] +

“ status=” + context.Response.StatusCode.ToString() +

“ duration_ms=” + context.Elapsed.TotalMilliseconds.ToString() +

“ api=fabric-core-mcp”

)

application/json

@(“{\”error\”: \”” + context.LastError.Message + “\”, \”status\”: “ + context.Response.StatusCode.ToString() + “}”)


Replace `{tenant-id}` with your Entra ID tenant ID. That’s it — the policy handles everything else.

**— -**

**## Configuring the Developer’s Machine**

**\*\*VS Code (recommended — handles token refresh automatically):\*\***

In `.vscode/mcp.json` or the user-level `mcp.json`:

json

{

“servers”: {

“enterprise-fabric”: {

“type”: “http”,

“url”: “https://your-apim-instance.azure-api.net/mcp/fabric",

“headers”: {

“Ocp-Apim-Subscription-Key”: “{developer-subscription-key}”

}


VS Code with GitHub Copilot handles the Entra ID token automatically. The developer just needs their APIM subscription key — which the platform team distributes via Key Vault, not email.

**\*\*Claude Desktop:\*\***

json

{

“mcpServers”: {

“enterprise-fabric”: {

“type”: “http”,

“url”: “https://your-apim-instance.azure-api.net/mcp/fabric",

“headers”: {

“Ocp-Apim-Subscription-Key”: “{developer-subscription-key}”,

“Authorization”: “Bearer {entra-token}”

}


Get the Entra token via `az account get-access-token — resource [https://api.fabric.microsoft.com](https://api.fabric.microsoft.com) — query accessToken -o tsv`. Note: tokens expire after 1 hour — VS Code handles this automatically, Claude Desktop requires manual refresh.

**— -**

**## What This Costs If You Already Have APIM**

Zero.

If your organization already runs an APIM instance — which most enterprise Azure environments do — this is one new backend, one new API route, and a policy. No new resource provisioning, no new monthly bill, no new approval process for infrastructure. You’re adding a capability to infrastructure you already own and operate.

If you need a new APIM instance, the Standard tier runs approximately $750/month and gives you a governed, audited, rate-limited gateway to your entire MCP estate for all developers — the cost of roughly one developer hour per day.

**— -**

**## The Registry Pattern: One Gateway for All MCP Servers**

The Fabric MCP connection is one spoke. The same APIM instance, the same policy pattern, the same auth and audit infrastructure extends to every MCP server your organization wants to expose:

plaintext

Enterprise APIM Gateway

→ /mcp/fabric → Fabric Core MCP Server

→ /mcp/powerbi → Power BI Remote MCP

→ /mcp/snowflake → Snowflake Cortex MCP

→ /mcp/databricks → Databricks Genie MCP




Each addition is one new backend and one new API operation. The governance layer — auth, audit, rate limiting, retry — is inherited automatically. New MCP servers don’t require new governance conversations. They require a backend entry and a subscription key.

That is the enterprise MCP registry. It’s not a new product or a new platform. It’s a new use of infrastructure most organizations already have, applied to a problem that’s only going to get more urgent as MCP adoption accelerates.

**— -**

**## The Honest Production Checklist**

Before calling this production-ready for a regulated environment:

- [] APIM managed identity has minimum required permissions on Fabric — Viewer only, not Contributor

- [] Subscription keys distributed via Key Vault — never email or Slack

- [] Application Insights connected and retention policy set to meet audit requirements

- [] Conditional access policy enforces MFA before Entra token issuance

- [] Rate limits tuned per team, not just per individual developer

- [] Private endpoint for APIM if PHI boundary requires no public ingress

- [] Subscription approval required — no self-service access

**— -**

**## Why This Matters Now**

MCP adoption is accelerating faster than enterprise governance is keeping up. Most organizations are currently in one of two states: blocking MCP entirely (the security team wins, developers lose), or allowing ungoverned direct connections (developers win, security loses).

The gateway pattern is the third option that neither side has articulated yet. The security team gets everything they actually need — identity enforcement, audit trail, access control, revocation. The developers get the capability they want — natural language access to enterprise data through the tools they already use.

The organizations that build this registry now, before MCP sprawl sets in, will have a meaningfully better operational posture when the number of MCP connections scales from two to twenty.

**— -**

_\*Kartik Anand — Cloud & AI Architect | Building agentic AI systems on Azure, Snowflake, and Microsoft Fabric\*_

_\*[LinkedIn](_https://linkedin.com/in/kartanand_) · [GitHub](_https://github.com/kartikanand73_) · [HealthIQ Multi-Agent Reference Architecture](_https://github.com/kartikanand73/fabriciq-multi-agent-reference-architecture_)\*_

From Manual Coordination to Prompt‑Driven Automation

Kartik Anand — Sat, 11 Apr 2026 02:38:43 +0000

How AI‑Driven Simulation in Microsoft Fabric Enables Scalable, Repeatable Performance Testing for Power BI Semantic Models Under Concurrent User Load

Introduction

Validating the performance of enterprise‑scale analytics platforms has traditionally depended on simulating realistic user behavior through manual coordination.

In environments where Power BI reports are expected to support concurrent access from multiple users — each interacting with dashboards using different filters, slicers, and navigation paths — performance testing typically involves assembling groups of participants to execute report interactions simultaneously while monitoring tools capture performance metrics.

This process is difficult to scale, difficult to reproduce consistently, and often introduces variability that obscures meaningful performance insights.

Recent advancements in AI‑assisted developer tooling, combined with automation capabilities available within Microsoft Fabric, are beginning to fundamentally reshape how this process can be executed.

The Traditional Model of Concurrent Testing

Historically, evaluating how a Power BI semantic model performs under load has required:

Coordinating multiple testers to access the same report at the same time
Instructing each participant to apply different filters or interaction paths
Attempting to replicate realistic user behavior manually
Capturing performance telemetry from client‑side or service‑side tools
Repeating these sessions multiple times to approximate statistical confidence

Beyond the logistical overhead, this approach introduces inconsistencies that make benchmarking difficult. Variations in how each user interacts with the report — whether through filter selections, page navigation, or query timing — can result in materially different performance characteristics from one test run to the next.

Manual testing also limits the ability to rapidly re‑test performance after iterative changes to the semantic model, data model, or report design.

Introducing Prompt‑Driven Simulation

By leveraging AI‑assisted developer tooling within Visual Studio Code — alongside extensibility capabilities available in Microsoft Fabric — it is now possible to simulate concurrent user interactions directly against Fabric‑hosted Power BI reports.

Instead of assembling test participants, performance testing scenarios can be defined using natural‑language prompts that instruct the system to:

Identify the report and workspace under test
Analyze available filters and slicers within the report
Assign distinct interaction patterns to simulated users
Execute report queries under concurrent load
Apply dynamic or randomized filter selections per user
Generate performance outputs for benchmarking analysis

This allows simulated users to behave differently from one another — interacting with visuals using different filters, combinations, or navigational paths — closely mirroring real‑world usage patterns.

Automating the Execution Layer

Once the testing intent is defined through prompt‑based interaction, the underlying tooling can generate executable scripts capable of simulating multiple concurrent sessions against the report environment.

These scripts initiate parallel connections — each representing a simulated user — allowing independent query execution paths to be evaluated simultaneously.

Because simulation logic is generated programmatically:

Testing scenarios become repeatable
Interaction patterns can be standardized or randomized
Concurrent user behavior can be scaled without manual coordination
Benchmark tests can be executed consistently across environments

This transforms performance testing from a manually orchestrated activity into a programmable validation mechanism that can be executed on demand.

Quantitative Impact on Testing Time

In a recent automated simulation using prompt‑driven performance testing, the system was able to interpret report structure, assign distinct filter behaviors to simulated users, and successfully execute concurrent testing within a few minutes.

By contrast, traditional manual concurrency testing typically requires:

Identifying available participants
Scheduling aligned execution windows
Coordinating test instructions
Executing report interactions simultaneously
Capturing and consolidating performance metrics

When automation reduces execution time to minutes, this introduces the potential to:

Perform repeated performance validation after each semantic model update
Benchmark optimization strategies across multiple test iterations
Re‑run concurrency simulations under different interaction scenarios

Benchmarking and Comparative Analysis

With prompt‑driven automation in place, performance testing transitions from a one‑time event into an iterative validation capability.

For example, a report can be evaluated under isolated capacity conditions to establish a baseline performance profile. Subsequent changes — whether to data modeling strategy, filter logic, or visual design — can then be tested against that baseline to determine their impact on:

Average page load times
Query execution latency
Tail‑latency metrics under concurrency
Filter‑driven query complexity
Cache effectiveness across interaction patterns

This enables teams to move beyond anecdotal performance feedback and toward quantifiable evidence of optimization impact.

Operational Implications

The shift from manually coordinated testing sessions to prompt‑driven automation introduces several practical advantages:

Testing scenarios can be executed without scheduling participant availability
Simulations can be scaled to arbitrary concurrency levels
Interaction patterns can be randomized or standardized as needed
Benchmark tests can be reproduced consistently over time
Performance regressions can be identified earlier in the development lifecycle

Performance testing can therefore become an integrated component of semantic model and report lifecycle management — rather than an isolated activity performed only at deployment milestones.

Conclusion

As enterprise analytics platforms continue to evolve toward real‑time and self‑service consumption models, the ability to validate report performance under realistic usage conditions becomes increasingly critical.

By combining AI‑assisted developer tooling with Microsoft Fabric’s extensibility model, it is now possible to simulate concurrent user behavior against Power BI reports through prompt‑driven automation — eliminating the need for manual coordination while enabling repeatable, benchmark‑based performance validation.

This represents a meaningful step forward in transforming performance testing from an operational burden into a scalable, developer‑driven capability.

From Fragile Pipelines to Autonomous Lakehouse — Lessons from My Databricks Journey

Kartik Anand — Tue, 02 Sep 2025 16:34:27 +0000

From Fragile Pipelines to Autonomous Lakehouse: My Databricks Journey

I recently earned the Databricks Data Engineer certification , and it’s reshaped how I think about modern data architectures. What once took hours of brittle cloud functions, redundant staging tables, and slow, preview-stage triggers can now be handled with elegance and speed.

Let me explain why this shift matters — and how it’s changing the way enterprises approach data engineering.

The Pain of Legacy ETL

I still remember a project where we had to write custom cloud functions just to move data between layers. Every schema change forced us to spin up temporary tables. The functions were slow, error-prone, and hard to maintain. It felt like duct-taping a data pipeline together.

In another engagement, a client maintained a massive Azure data lake — but accessing it was a political maze. Every data request turned into a marathon of approvals and delays. If Unity Catalog had been in place, we could’ve saved weeks of back-and-forth and accelerated delivery.

What Databricks Gets Right

Databricks isn’t just a platform — it’s a strategic enabler. It unifies data engineering, analytics, and machine learning under one roof:

Delta Lake : Atomic writes, schema enforcement, and ACID compliance
MLflow : End-to-end experiment tracking and model lifecycle management
Unity Catalog : Centralized governance, fine-grained access control, and full data lineage
Cloud Agnostic : No vendor lock-in across AWS, Azure, and GCP

With Unity Catalog, data provenance becomes transparent. You can trace a metrics report all the way back to its raw source — eliminating guesswork and political bottlenecks.

Speed to Market, Without the Bloat

At the end of the day, companies care about speed to market and cost efficiency. Legacy approaches often come with hidden expenses — multiple services, brittle integrations, and steep maintenance overhead.

Databricks simplifies this. The learning curve isn’t steep; it builds naturally on the data engineer’s existing skill set. And when enterprises embrace Databricks as part of their broader cloud migration, much of the setup cost is absorbed. Yes, there’s investment in training — but the ROI in agility, governance, and scalability is undeniable.

The Road Ahead

For data engineers architecting the future, the shift from fragile ETL pipelines to an autonomous Lakehouse isn’t just a technical upgrade — it’s a strategic leap. It elevates collaboration, accelerates time to insight, and unlocks new possibilities for AI-driven innovation.

If you’re still wrestling with legacy data stacks, it’s time to rethink your architecture. The Lakehouse isn’t just a buzzword — it’s a blueprint for intelligent orchestration.

Let’s connect if you’re exploring Databricks, agentic systems, or autonomous analytics. I’d love to exchange ideas and hear how others are navigating this transformation.

#Databricks #Lakehouse #DataEngineering #DeltaLake #UnityCatalog #CloudArchitecture #AgenticSystems #ThoughtLeadership #AnalyticsTransformation

Would you like help crafting a compelling headline image or Medium tags to boost visibility?

Orchestration Pattern Meets Serverless (Durable Functions)

Kartik Anand — Mon, 03 Aug 2020 20:25:45 +0000

In the current digital transformation/micro-service era, orchestration pattern is another useful pattern that is used by lot of organizations for calling various services and then waiting for all services to complete before next step.

Azure Durable Functions is a great service to implement orchestration pattern. The function orchestrates and chains-together calls to other functions. Those functions can be any or a combination (Functions/Logic Apps/Web Api/Microservices).The durable function is resilient to reboots of VMs/Applications.

In my example, I have a service that calls 2 micro-services and waits for the results before moving to next step. This all is accomplished via single durable function that will call 2 services and then wait till it receives results back from 2 services and then it makes a call to the next service. Alternatively, this could be accomplished by creating multiple functions and Queues to coordinate the flow of data. The alternative flow will introduce unnecessary services and increase the overall management of services.

Here are some key advantages:

·Low Overhead

·Reliability

·Scalability

·Serverless

·Cost Saving

Key Source Code

var tasks = new Task[2];

tasks[0] = context.CallActivityAsync(“ZipCodeAPI”, “LA2”);

tasks[1] = context.CallActivityAsync(“LogicApp1”, “LA2”);

await Task.WhenAll(tasks); //Ensures Function waits for all chain functions to complete before moving to next step

[FunctionName(“ZipCodeAPI”)]

public static string GetZipCode([ActivityTrigger] string name, ILogger log)

{

HttpWebRequest rqst = (HttpWebRequest)HttpWebRequest.Create(_url);

rqst.Method = “POST”;

rqst.ContentType = “application/json”;

byte[] byteData = Encoding.UTF8.GetBytes(pJSON);

}

[FunctionName(“CountryCode”)]

public static string GetCountryCode([ActivityTrigger] string name, ILogger log)

{

HttpWebRequest rqst = (HttpWebRequest)HttpWebRequest.Create(_url);

rqst.Method = “POST”;

rqst.ContentType = “application/json”;

byte[] byteData = Encoding.UTF8.GetBytes(pJSON);

}