Where MCP Servers Belong in Your Landing Zone

There is a question that keeps coming up in architecture reviews lately, and it goes something like this: we are building an MCP server, where should we put it? The instinct from most teams is to drop it into the AI Hub subscription, right next to Azure AI Foundry, and move on. That instinct is wrong more often than it is right, and the reasons why are worth unpacking, because the placement decision shapes a lot of what comes after.

This post is for the architect who has to make the call, the engineer who has to build and run it, and the leader who has to fund and govern it. The good news is that the question has a clean answer once you understand what an MCP server actually is in the context of an enterprise landing zone. The less good news is that the clean answer is "it depends," and the rest of this post is about the dependencies that matter.

MCP servers are a new tier, not a new product

Before talking about placement, it helps to be clear on what we are placing. An MCP server is a piece of software that exposes a set of tools to AI agents using the Model Context Protocol. From a deployment perspective, it looks like any other container or function. From an architectural perspective, it sits in a place that does not quite map to anything we already had.

It is not platform infrastructure. Platform subscriptions hold connectivity, identity, and shared management capabilities, and they change slowly on purpose. MCP servers iterate weekly, sometimes daily, as teams add new tools and refine existing ones. Putting them in a platform subscription means dragging them through a change cadence that was designed for firewalls and DNS zones, and that does not end well.

It is also not quite a workload. A workload subscription holds an application that serves a specific business purpose. An MCP server exposes capabilities that may be used by many agents across many workloads, which means scoping it to a single workload subscription often leaves value on the table and creates awkward cross-subscription access patterns.

It is also not a gateway. The gateway is APIM. APIM sits in front of the MCP server, handles authentication, rate limiting, and routing, and gives you a place to enforce policy that does not belong inside the MCP server itself. The MCP server is what APIM is fronting, not the front itself.

What we are really talking about is a new tier in the application architecture. A tool tier. And tool tiers can have different scopes, which is where the placement question gets interesting.

Three placement patterns, and how to choose between them

In practice, MCP servers in an enterprise tend to fall into one of three scopes. Each one points to a different home in the landing zone.

The first is workload-scoped. The MCP server exposes tools that only one workload cares about — domain-specific operations against that workload's own data and resources. A claims processing application might stand up an MCP server that exposes claim lookups, status updates, and routing decisions. Nobody else needs those tools. In this case, the MCP server belongs in the workload's own subscription, alongside the application it serves. It shares the workload's identity model, its network exposure, and its lifecycle. This is the simplest case, and when it fits, it should be the default.

The second is domain-scoped. The MCP server exposes capabilities that several workloads in the same business domain use — things like a shared customer lookup, a shared document retrieval service, or a set of tools that wrap a domain-specific system of record. These do not belong in any single workload subscription, but they also do not belong in a platform subscription. The right home is a shared services subscription within the domain's landing zone group, sometimes called a domain platform or domain shared subscription. It sits at the right altitude — high enough to serve multiple workloads, low enough to iterate at workload speed.

The third is platform-scoped. The MCP server exposes tools that are genuinely cross-cutting and belong to the platform team's portfolio — things like an MCP server that wraps Azure diagnostic queries, or one that exposes incident management actions, or one that fronts a platform-wide knowledge base. These belong in a subscription within the AI platform domain, but not necessarily in the same subscription as Azure AI Foundry. A dedicated subscription for platform-owned MCP servers keeps their change cadence separate from Foundry's, gives them their own RBAC boundary, and lets the platform team operate them like the small applications they actually are.

The mistake to avoid is putting everything in the third bucket by default. Most MCP servers most teams build are workload-scoped or domain-scoped. Treating them all as platform capabilities centralizes work that does not need to be centralized, and slows down the experimentation that makes MCP valuable in the first place.

The decisions that follow from placement

Once you know the scope, the rest of the design starts to fall out naturally.

Identity follows scope. A workload-scoped MCP server runs under a user-assigned managed identity that has access only to that workload's resources. A domain-scoped server has a UAMI scoped to the shared resources of the domain. A platform-scoped server has a UAMI that may reach further, but should still be carefully bounded. The principle is the same in all three cases: the MCP server's identity should never have more access than the tools it exposes actually require, and that scoping should be reviewable.

Network exposure follows scope too. Workload-scoped MCP servers are reached over the workload's existing network paths, usually through private endpoints, with APIM in front handling external access if any is needed. Domain-scoped servers sit behind APIM in a way that lets multiple workload spokes reach them without requiring direct spoke-to-spoke connectivity. Platform-scoped servers are typically only reachable from inside the corporate network, with APIM fronting them and the AI hub providing the path.

Lifecycle ownership follows scope as well. Workload teams own their workload-scoped servers, full stop. Domain teams own their domain-scoped servers, with the platform team providing the deployment pattern and the guardrails. The platform team owns platform-scoped servers directly. Nobody owns an MCP server by accident, and nobody owns one because it happened to land in their subscription.

The pattern worth standardizing

Whatever the scope, the deployment pattern itself can and should be standardized. Azure Container Apps with a user-assigned managed identity, private networking, APIM in front, and diagnostic settings routed to the platform Log Analytics workspace is a reasonable default for most MCP servers in most enterprises. It is cheap to run, easy to scale, easy to govern, and easy to retire when the server is no longer useful. Standardizing the pattern means workload and domain teams do not have to reinvent the deployment story every time they want to expose a new set of tools, and the platform team gets a consistent operational surface to monitor.

The Takeaway

MCP servers are a new tier, and they need a home that fits their actual shape. That home is sometimes the workload subscription, sometimes a domain shared subscription, sometimes a dedicated platform subscription, but it is almost never the same subscription as Foundry by default. Scope the server to the audience it actually serves, place it accordingly, scope its identity and network exposure to match, and let the team that owns the tools own the server too.

The ownership piece is where most of these decisions quietly break down. Owning an MCP server is not just deploying the container. It is deciding which tools get added, reviewing the changes, responding when something unexpected happens, deprecating tools that nobody uses anymore, and renewing the certificates eighteen months from now. If the server lives in a subscription owned by a team that does not own the tools, every one of those becomes a handoff, and handoffs are where MCP estates rot.

Get this right early and the estate grows cleanly. New servers land where you would expect them, owned by the teams that built them, with identity and network scoping that matches the work. The directory stays legible, the audit trail makes sense, and new agents can find the right tools because the placement reflects the actual shape of the business.

Get it wrong and the failure mode is slow and mostly invisible until the estate is big enough to hurt. The AI Hub accumulates a pile of MCP servers that have nothing in common except a default placement decision. UAMIs end up with broader access than anyone intended because the easiest fix in the moment was to grant a permission. Logs scatter across whichever workspace was convenient. Nobody has a complete picture of which agents are calling which tools against which resources, and unwinding the pattern means re-IPing, re-fronting, re-permissioning, and managing a transition window for every server you want to move.

The path of least resistance six months in is to make the placement decision deliberately the first time. It costs maybe an extra hour of architecture conversation per server in the early days, and it saves a multi-quarter remediation effort later. That is one of the better trades available in this part of the stack right now, and it costs almost nothing to make.