Choose an Azure service for your MCP server

You can use several Azure services to host Model Context Protocol (MCP) servers. This guide helps you choose the right service based on your workload requirements, team expertise, and operational needs.

Note

This article compares multiple Azure services to help you make a hosting decision. For Container Apps-specific details, see MCP servers on Azure Container Apps.

Hosting options overview

Azure provides five ways to host an MCP server. Each option targets a different mix of flexibility, simplicity, and isolation.

Azure Container Apps (standalone)

Deploy any MCP server you build as a container with HTTP ingress. Container Apps gives you full control over the runtime, supports any language with an MCP SDK, and includes features like autoscaling with scale-to-zero, Dapr integration, and service-to-service networking.

Azure Container Apps dynamic sessions

Use platform-managed session pools with built-in MCP tooling for sandboxed code execution. You don't write or deploy MCP server code. The platform provides predefined tools for Python and shell environments, with Hyper-V isolation between sessions.

Azure App Service

Host an MCP server on App Service in one of two ways:

Build your own MCP server. Add the MCP SDK to a new or existing web app and mount the MCP endpoint alongside your existing routes. App Service supports code-based deployment without a Dockerfile and integrates with Microsoft Entra ID for authentication.
App Service built-in MCP (Preview). If your app already exposes a REST API with an OpenAPI 3.x specification, App Service can host an MCP server for you with no MCP code. The platform reads your spec, turns each operation into an MCP tool, and serves the MCP endpoint over streamable HTTP. Use this when you want to expose an existing API to MCP clients quickly without taking a code dependency on an MCP SDK.

Azure Functions

Map function triggers to MCP tools by using the Azure Functions MCP extension. Azure Functions is optimized for stateless, event-driven tool execution with per-invocation pricing.

Azure Kubernetes Service (AKS)

Deploy MCP servers as standard Kubernetes Deployments with HTTP ingress. AKS gives you full access to the Kubernetes API, so you can use Helm charts, custom networking (CNI, network policies), service mesh, GPU node pools, and KEDA-based autoscaling. Choose AKS when your team already manages a Kubernetes cluster or needs capabilities that go beyond what a managed container platform provides.

Note

Container Apps is built on Kubernetes and provides a managed experience with less operational overhead. If you need direct Kubernetes API access, custom operators, or have an existing AKS investment, use AKS directly. For a broader comparison between these services, see Comparing Container Apps with other Azure container options.

Compare hosting options

The following table summarizes the key differences between hosting options.

Consideration	Container Apps (standalone)	Container Apps (sessions)	App Service	Azure Functions	AKS
Custom tools	Yes	No (platform-defined only)	Yes (build your own; or every OpenAPI operation becomes a tool with built-in MCP)	Yes	Yes
Language support	Any (containerized)	Python and shell only	.NET, Python, Node.js, Java (built-in MCP: any language, since the platform forwards to your existing HTTP routes)	.NET, Python, Node.js, Java	Any (containerized)
MCP transport	Streamable HTTP	JSON-RPC over HTTP	Streamable HTTP	MCP extension or self-hosted	Streamable HTTP
Authentication	Built-in auth (Microsoft Entra ID) or custom	API key (`x-ms-apikey`)	App Service auth (Microsoft Entra ID); built-in MCP also publishes PRM	Function keys or Microsoft Entra ID	Microsoft Entra Workload Identity or custom
Isolation	Container-level	Hyper-V per session	App-level	Function-level	Pod and namespace-level
Scaling	Revision autoscale, scale-to-zero	Per-session, pool-managed	App Service Plan	Consumption or Premium plan	HPA, KEDA, Cluster Autoscaler
Cold start	Yes (mitigate with min replicas)	Subsecond (prewarmed pool)	Depends on plan	Yes (Consumption plan)	No (pods always running), or Yes with KEDA scale-to-zero
Microservices	Native (environments, Dapr)	No	Limited	Limited	Native (Kubernetes service discovery, service mesh)
Operational overhead	Medium (Dockerfile, registry)	Low (platform-managed)	Low (code deployment; built-in MCP is lowest — ARM property + OpenAPI spec, no MCP code)	Low (function deployment)	High (cluster management, upgrades, networking)
Pricing model	Per vCPU-second, per GiB-second	Per session (consumption)	App Service Plan	Per execution	Per node (VM cost) + managed cluster fee

Choose by scenario

Use the following guidance to narrow your decision based on common workload patterns.

Build a custom MCP server with Azure

Recommended: Azure Container Apps (standalone) or Azure App Service

Both services let you build an MCP server with any official MCP SDK and expose it over streamable HTTP. Choose between them based on your deployment model and feature needs.

Container Apps: Prefer containers, need autoscaling with scale-to-zero, want Dapr integration, or are building a microservices architecture with multiple MCP servers. For interactive MCP clients (like GitHub Copilot), set a minimum replica count of 1 to avoid cold-start latency.
App Service: Prefer code-based deployment without a Dockerfile, have an existing App Service Plan, or want the simplicity of az webapp up.

Tutorials:

Run sandboxed code for an AI agent

Recommended: Azure Container Apps dynamic sessions

Session pools with MCP enabled provide Hyper-V-isolated environments for running untrusted or LLM-generated code. The platform manages the MCP server, so you don't write or deploy server code. The built-in tools cover code execution scenarios without custom development:

launchShell: Creates a new environment
runShellCommandInRemoteEnvironment: Executes shell commands
runPythonCodeInRemoteEnvironment: Executes Python code

Dynamic sessions maintain prewarmed instances, so you don't experience cold-start latency.

Tutorials:

Add MCP to an existing web app

Recommended: Azure App Service

If your app already runs on App Service, add the MCP SDK to your existing codebase, mount the MCP endpoint alongside your existing routes, and redeploy.

If your existing app runs on Container Apps, follow the standalone tutorials.

Expose an existing REST API as an MCP server with no code changes

Recommended: Azure App Service built-in MCP (Preview)

If your App Service app already exposes a REST API with an OpenAPI 3.x specification, the platform can host an MCP server for you. You publish the spec with your app, set the aiIntegration property on the site resource, and the platform serves a streamable HTTP MCP endpoint that maps each OpenAPI operation to an MCP tool. App Service Authentication enforces identity, and the platform publishes protected resource metadata so MCP clients can complete OAuth automatically.

Use built-in MCP when you don't want to take a code dependency on an MCP SDK, or when you want the platform to keep up with MCP protocol updates.

Configure App Service built-in MCP (Preview)

Create lightweight, event-driven tool endpoints

Recommended: Azure Functions

The Azure Functions MCP extension maps function triggers to MCP tools. Azure Functions is a good fit when:

Each tool is independent and stateless.
You want per-invocation pricing.
You're integrating with Foundry Agent Service.

For interactive MCP clients, use a Functions Premium plan to avoid cold-start latency on the Consumption plan.

Run multiple MCP servers with service-to-service communication

Recommended: Azure Container Apps (standalone)

Container Apps environments support internal service discovery, Dapr sidecars, and managed identities for service-to-service calls. Deploy multiple MCP servers as separate container apps within the same environment and let them communicate securely without exposing internal endpoints to the internet. Container Apps gives you full control over the runtime and dependencies for each server, but you manage a Dockerfile and container images for each one.

Host MCP servers on an existing AKS cluster

Recommended: Azure Kubernetes Service (AKS)

If your team already manages an AKS cluster, deploy MCP servers as Kubernetes Deployments with a Service and Ingress resource. AKS is a good fit when:

You already run AI workloads on AKS and want to colocate MCP servers on the same cluster.
You need GPU node pools for AI models running alongside your MCP servers.
You require custom Kubernetes networking, such as Azure CNI, network policies, or a service mesh.
You want KEDA-based autoscaling with fine-grained control over scaling triggers.

Use a standard Kubernetes Ingress controller (such as NGINX, Azure Application Gateway Ingress Controller, or Istio gateway) to expose your MCP server's streamable HTTP endpoint. Secure the endpoint with Microsoft Entra Workload Identity for service-to-service calls or custom authentication middleware.

For a hybrid scenario where you want the Container Apps managed experience on your own Kubernetes infrastructure, see Azure Container Apps on Azure Arc.

Quick decision guide

Use these questions to narrow your choice:

Do you need sandboxed code execution for untrusted or LLM-generated code? Use Azure Container Apps dynamic sessions.
Do you already have a web app running on App Service? Add the MCP SDK to your existing App Service app, or use App Service built-in MCP (Preview) if your app already exposes a REST API with an OpenAPI spec.
Do you need event-driven, per-invocation tool execution? Use Azure Functions.
Do you need full container control, custom languages, or a microservices architecture? Use Azure Container Apps (standalone).
Do you already run workloads on AKS and need full Kubernetes API access? Use Azure Kubernetes Service (AKS).
Not sure where to start? Begin with Azure Container Apps (standalone), which is the most flexible default.

Feedback

Was this page helpful?

Last updated on 2026-06-02