Rays Cloud Blog

Azure MCP Server 2.0 – Self-Hosted Remote MCP für Enterprise Agentic Workflows

Ray Ünal

KI-Agenten, die Azure-Ressourcen steuern, sind kein Zukunftsszenario mehr. Sie provisionieren VMs, analysieren Logs, diagnostizieren Probleme und deployen Infrastruktur. Aber bisher fehlte ein entscheidender Baustein: ein sicherer, zentral verwalteter Server, der diese Interaktion in Enterprise-Umgebungen ermöglicht – ohne Governance-Lücken und ohne Netzwerk-Risiken.

Mit Azure MCP Server 2.0, veröffentlicht am 10. April 2026, liefert Microsoft genau das.

Was ist das Model Context Protocol?

Das Model Context Protocol (MCP) ist ein offener Standard, der definiert, wie KI-Modelle mit externen Tools kommunizieren. Statt dass jeder Agent seine eigene Integration für Azure Resource Management, Monitoring oder Diagnostics baut, stellt MCP eine standardisierte Schnittstelle bereit. Der Agent sagt „ich brauche eine Liste aller VMs in dieser Resource Group“ – der MCP Server übersetzt das in die entsprechenden Azure API-Aufrufe und liefert das Ergebnis zurück.

Azure MCP Server implementiert diesen Standard speziell für Azure-Services. Version 1.0 brachte 200+ Tools für lokale Entwicklungsumgebungen. Version 2.0 macht den Sprung in die Produktion.

Das Problem mit lokalen MCP Setups

In Version 1.0 lief der MCP Server ausschließlich lokal auf der Entwickler-Maschine. Das funktioniert für einen einzelnen Entwickler, der mit einem KI-Agenten experimentiert. In einer Organisation mit 30, 50 oder 100 Entwicklern entstehen aber schnell Probleme:

Jeder Entwickler hat seine eigene Server-Version, seine eigene Konfiguration und authentifiziert sich mit seinen persönlichen Credentials. Es gibt keine zentrale Kontrolle darüber, welche Azure-Subscriptions der Agent ansprechen darf, welche Operationen erlaubt sind oder welche Tool-Versionen im Einsatz sind. Für Compliance-Teams ist das ein blinder Fleck.

Dazu kommt das Netzwerk-Problem: Der lokale MCP Server kommuniziert von der Entwickler-Maschine direkt mit Azure APIs. In Umgebungen mit Netzwerk-Segmentierung, Private Endpoints oder VPN-Restriktionen ist das oft nicht gewünscht oder schlicht nicht möglich.

Was Azure MCP Server 2.0 anders macht

Die Kernneuerung von Version 2.0 ist der Self-Hosted Remote Server. Statt auf jeder Entwickler-Maschine läuft ein zentraler Server in eurer eigenen Infrastruktur – als Container App, auf AKS oder auf einer VM. Entwickler-Clients verbinden sich per HTTPS.

276 Tools über 57 Azure Services

Der Server stellt 276 MCP Tools bereit, die 57 Azure Services abdecken. Das Spektrum reicht von Resource Management (Erstellen, Lesen, Aktualisieren, Löschen von Ressourcen) über Monitoring (Metriken, Logs, Alerts) bis hin zu Diagnostics (Health Checks, Konfigurationsvalidierung). Ein Agent kann damit einen vollständigen Incident-Response-Workflow ausführen: Alert empfangen, betroffene Ressource identifizieren, Logs analysieren, Diagnose stellen – alles über MCP.

Authentifizierung auf Enterprise-Level

Version 2.0 unterstützt zwei Authentifizierungsmodelle, die für Enterprise-Umgebungen relevant sind:

Managed Identity – der Server authentifiziert sich mit einer Azure Managed Identity gegenüber den Azure APIs. Keine Secrets, keine Rotation, kein Credential Management. Funktioniert nahtlos, wenn der Server auf Azure Compute (Container Apps, AKS, VMs) läuft.

On-Behalf-Of (OBO) Flow – der Server agiert im Kontext des angemeldeten Benutzers. Der Entwickler authentifiziert sich per Entra ID, der MCP Server delegiert diese Identität an die Azure APIs weiter. Das bedeutet: Azure RBAC greift auf Benutzerebene. Ein Entwickler sieht über den MCP Server nur die Ressourcen, auf die er auch direkt Zugriff hätte.

bash

# Managed Identity erstellen
az identity create \
  --name mi-mcp-server \
  --resource-group rg-platform-engineering \
  --location westeurope
# Reader-Rolle auf Ziel-Subscriptions zuweisen
MI_PRINCIPAL_ID=$(az identity show \
  --name mi-mcp-server \
  --resource-group rg-platform-engineering \
  --query principalId -o tsv)
az role assignment create \
  --assignee $MI_PRINCIPAL_ID \
  --role "Reader" \
  --scope /subscriptions/<subscription-id>
# Für Write-Operationen (Provisioning, Deployments):
az role assignment create \
  --assignee $MI_PRINCIPAL_ID \
  --role "Contributor" \
  --scope /subscriptions/<subscription-id>/resourceGroups/rg-dev-environment

Sovereign Cloud Support

Für Unternehmen in regulierten Branchen unterstützt Version 2.0 Azure US Government und Azure China (21Vianet). Die Cloud-Endpunkte werden in der Server-Konfiguration definiert – der Server kommuniziert ausschließlich mit den Endpunkten der konfigurierten Sovereign Cloud. Für DACH-Unternehmen mit strengen Data Residency Requirements aktuell weniger relevant, aber ein Indikator, dass Microsoft MCP Server für regulierte Umgebungen ernst nimmt.

Deployment: Self-Hosted MCP Server auf Azure Container Apps

Azure Container Apps ist die naheliegende Hosting-Option: Serverless Scaling, Built-in Ingress mit TLS, Managed Identity Support und VNet-Integration. Hier ein vollständiges Setup:

bash

# Environment mit VNet-Integration erstellen
az containerapp env create \
  --name mcp-server-env \
  --resource-group rg-platform-engineering \
  --location westeurope \
  --infrastructure-subnet-resource-id /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Network/virtualNetworks/<vnet>/subnets/<subnet>
# Managed Identity erstellen und konfigurieren
az identity create \
  --name mi-mcp-server \
  --resource-group rg-platform-engineering \
  --location westeurope
MI_ID=$(az identity show \
  --name mi-mcp-server \
  --resource-group rg-platform-engineering \
  --query id -o tsv)
MI_PRINCIPAL=$(az identity show \
  --name mi-mcp-server \
  --resource-group rg-platform-engineering \
  --query principalId -o tsv)
# RBAC: Reader auf relevante Subscriptions
az role assignment create \
  --assignee $MI_PRINCIPAL \
  --role "Reader" \
  --scope /subscriptions/<target-sub>
# Container App deployen
az containerapp create \
  --name mcp-server \
  --resource-group rg-platform-engineering \
  --environment mcp-server-env \
  --image ghcr.io/microsoft/azure-mcp-server:2.0 \
  --target-port 8080 \
  --ingress external \
  --transport http \
  --min-replicas 1 \
  --max-replicas 5 \
  --cpu 1.0 \
  --memory 2.0Gi \
  --user-assigned $MI_ID
# FQDN des Servers abfragen
az containerapp show \
  --name mcp-server \
  --resource-group rg-platform-engineering \
  --query properties.configuration.ingress.fqdn -o tsv

Die Ausgabe liefert die URL, die Entwickler in ihren MCP Clients konfigurieren. Für VS Code sieht die Konfiguration so aus:

json

{
  "mcp": {
    "servers": {
      "azure-remote": {
        "url": "https://mcp-server.<env>.<region>.azurecontainerapps.io/sse",
        "transport": "sse"
      }
    }
  }
}

Vergleich: Lokal vs. Self-Hosted Remote

AspektLokal (v1.x)Self-Hosted Remote (v2.0)
Setup-AufwandPro Entwickler (5 Min)Einmalig zentral (30 Min)
AuthentifizierungPersonal CredentialsManaged Identity / OBO
GovernanceKeine zentrale KontrollePolicies, Tool-Einschränkungen
NetzwerkEntwickler-MaschineVNet-isoliert, Private Endpoints
SkalierungSingle UserMulti-User, Auto-Scaling
Sovereign CloudManuelle KonfigurationBuilt-in Support
Tool-VersionenJeder Entwickler individuellEinmal zentral aktualisieren
Audit TrailLokale LogsZentrale Logs, Azure Monitor
KostenKeine (lokal)Container App Compute (~15-30 EUR/Monat)

Wann lokal, wann remote? Für Einzelentwickler und Prototyping bleibt der lokale Modus die richtige Wahl – schnell, unkompliziert, kostenlos. Sobald mehr als drei Entwickler MCP nutzen, ein Team standardisierte Workflows braucht oder Compliance-Anforderungen existieren, ist der Self-Hosted Remote Server die bessere Architektur.

Praxis-Szenarien

Szenario 1: Automated Incident Diagnostics

Ein KI-Agent empfängt einen Alert aus Azure Monitor, fragt über MCP den Health Status der betroffenen Ressource ab, sammelt die relevanten Logs und erstellt eine Zusammenfassung mit Handlungsempfehlung. Der gesamte Workflow läuft über den zentralen MCP Server – mit der Managed Identity des Servers, die nur Leserechte auf die Production-Subscription hat.

Szenario 2: Developer Self-Service Provisioning

Entwickler beschreiben in natürlicher Sprache, welche Infrastruktur sie brauchen. Der KI-Agent übersetzt das in Azure-Operationen, die über MCP ausgeführt werden. Der OBO Flow stellt sicher, dass nur Ressourcen in den Resource Groups erstellt werden, auf die der Entwickler RBAC-Zugriff hat.

Szenario 3: Compliance Audits

Ein Agent prüft regelmäßig die Konfiguration von Azure-Ressourcen gegen definierte Compliance-Policies. Fehlkonfigurationen werden geloggt und als Alerts an das Security-Team weitergeleitet. Der zentrale MCP Server ermöglicht ein einheitliches Audit Log über alle Agent-Operationen.

Einschränkungen und Stolperfallen

Die Self-Hosted-Variante bringt eigene Komplexität mit. Hier die wichtigsten Punkte:

Der OBO Flow erfordert eine Entra App Registration mit den richtigen API Permissions und Admin Consent. In Multi-Tenant-Szenarien wird die Konfiguration komplex. Testet den OBO Flow isoliert, bevor ihr ihn in die MCP-Server-Konfiguration integriert.

Write-Operationen (Resource Creation, Deployments) erfordern entsprechende RBAC-Rollen. Ein Server mit Reader-Rolle kann keine Ressourcen erstellen – das klingt offensichtlich, führt aber in der Praxis zu Verwirrung, wenn Agent-Workflows plötzlich fehlschlagen.

Die 276 Tools sind nicht alle gleich reif. Einige Services haben vollständige CRUD-Unterstützung, andere nur Read-Operationen. Prüft die Tool-Dokumentation für die Services, die ihr nutzen wollt, bevor ihr Workflows darauf aufbaut.

Container Image Sizes wurden in Version 2.0 reduziert, sind aber immer noch im mehrstelligen MB-Bereich. Für minimale Container-Umgebungen mit strengen Image-Size-Limits kann das relevant sein.

Fazit

Azure MCP Server 2.0 ist nicht revolutionär – er ist die logische Konsequenz aus der Erkenntnis, dass KI-Agenten Enterprise-Infrastruktur brauchen, genau wie jede andere Produktions-Workload. Der Self-Hosted-Ansatz ist pragmatisch: bestehende Azure-Konzepte (Managed Identity, VNet, RBAC) werden wiederverwendet, es gibt keine neue Lernkurve.

Für Platform-Engineering-Teams ist die Empfehlung klar: Einen zentralen MCP Server als „AI-Gateway für Azure-Operationen“ aufsetzen. Der Aufwand für das initiale Setup liegt bei unter einer Stunde. Der Gewinn ist ein standardisierter, sicherer und governeder Zugang zu Azure für alle KI-Agenten im Unternehmen.

Die spannende Frage ist nicht ob, sondern wie schnell MCP sich als Standard für Agent-Tool-Kommunikation durchsetzt. Mit Azure MCP Server 2.0 hat Microsoft ein starkes Signal gesetzt: Sie setzen auf MCP als Protokoll – und sie liefern die Enterprise-Infrastruktur dafür.

Quellen:

Hinterlasse einen Kommentar