Google hat am 14. September Apigee Hybrid 1.17.0 veröffentlicht. Die neue Version unterstützt Model Context Protocol direkt in der Hybrid-Laufzeit. Bestehende APIs lassen sich damit als verwaltete MCP-Endpunkte für agentische Anwendungen bereitstellen, ohne dafür einen separaten MCP-Server betreiben zu müssen.
MCP-Unterstützung in Apigee selbst ist nicht neu. Google hatte MCP für Apigee X bereits im März allgemein verfügbar gemacht und im Juli den API Hub erweitert. Neu ist, dass dieselbe Richtung jetzt die Hybrid-Runtime erreicht, die Unternehmen in ihrer eigenen Infrastruktur betreiben können.
Der technische Kern ist deshalb weniger „Google unterstützt MCP“ als die Frage, wo MCP in einer bestehenden API-Architektur hingehört. Apigees Antwort lautet: in dieselbe Governance-Schicht wie normale API-Aufrufe.
Ein Tool Call wird zum verwalteten API-Aufruf
MCP gibt Agenten eine standardisierte Möglichkeit, verfügbare Tools zu entdecken und aufzurufen. Ein Unternehmen mit vorhandenen REST- oder anderen APIs könnte dafür eigene MCP-Server schreiben, die Tool-Schemas definieren, Requests übersetzen und Authentifizierung implementieren.
Apigee setzt davor beziehungsweise darum eine verwaltete Schicht. Google beschreibt, dass Apigee MCP-Tool-Aufrufe routet, autorisiert und absichert wie andere API-Aufrufe. Der Betreiber muss damit nicht für jede Agent-Integration einen eigenständigen MCP-Server als neue Infrastrukturkomponente pflegen.
Das ist für bestehende SaaS- und Enterprise-Systeme relevanter als ein weiterer MCP-Client. Viele Unternehmen besitzen bereits API-Gateways mit Quotas, Authentifizierung, Logging und Richtlinien. Wenn Agenten diese APIs über MCP erreichen sollen, entsteht sonst leicht ein zweiter Zugriffsweg neben der vorhandenen Governance.
Ein separater MCP-Server kann dann zwar funktional dieselben Backend-APIs aufrufen, aber andere Auth-Regeln, andere Logs oder eigene Rate Limits besitzen. Aus Sicht des Backends kommen beide Zugriffe am Ende auf dieselbe Ressource.
Hybrid bringt MCP näher an private APIs
Apigee Hybrid trennt die Management-Ebene von einer Runtime, die in der Infrastruktur des Kunden betrieben wird. Für APIs, die aus Netzwerk- oder Compliance-Gründen nicht einfach über eine öffentliche SaaS-Runtime laufen sollen, ist diese Architektur ein wesentlicher Teil des Produkts.
Mit Version 1.17.0 kann MCP nun in diesem Umfeld genutzt werden. Das ist vor allem für interne Agenten interessant, die auf private Unternehmens-APIs zugreifen sollen.
Ein Coding-Agent könnte beispielsweise ein internes Deployment-Tool aufrufen. Ein Support-Agent könnte Daten aus einem internen CRM abrufen. Ein Operations-Agent könnte eine vorhandene Verwaltungs-API verwenden. MCP standardisiert dabei die Tool-Schnittstelle zum Agenten; Apigee bleibt für den eigentlichen API-Zugriff zuständig.
Diese Trennung ist sinnvoll, weil MCP keine bestehende Autorisierungsarchitektur ersetzen sollte. Dass ein Agent ein Tool in tools/list sehen kann, beantwortet noch nicht die Frage, ob die konkrete Identität eine bestimmte Aktion ausführen darf.
OAuth, Quotas und Tool-Rechte bleiben wichtiger als das Schema
Die einfache Demo eines MCP-Servers konzentriert sich häufig auf zwei Dinge: ein Tool definieren und einen Handler dahinterlegen. In einem produktiven System kommen weitere Fragen dazu.
Wer darf das Tool sehen? Welche Identität wird beim Backend verwendet? Darf ein Agent nur lesen oder auch schreiben? Wie viele Aufrufe sind erlaubt? Welche Aktionen müssen protokolliert werden? Was passiert, wenn ein Tool Parameter enthält, die direkt eine geschäftliche Aktion auslösen?
Google hatte für den API Hub bereits granulare OAuth-Scopes wie apihub.readonly und apihub.readwrite sowie Model-Armor-Integration für MCP-Aufrufe eingeführt. Apigees bestehendes Policy-Modell zielt ebenfalls darauf, Authentifizierung und andere API-Regeln vor die eigentliche Backend-Operation zu setzen.
Für Agenten ist diese Ebene besonders relevant, weil ein Tool-Aufruf nicht zwingend unmittelbar von einem Menschen ausgelöst wird. Ein Modell kann in einem längeren Workflow selbst entscheiden, welches Tool es als Nächstes verwendet. Die Autorisierung darf deshalb nicht allein aus der Entscheidung des Modells folgen.
MCP wird Teil der API-Infrastruktur
Die Entwicklung bei Google Cloud zeigt eine klare technische Verschiebung. MCP wird nicht mehr ausschließlich als kleiner Adapter behandelt, den ein Entwickler neben seiner Anwendung startet. API Hub kann MCP-Endpunkte verwalten, Apigee X kann APIs als MCP-Tools exponieren und Apigee Hybrid zieht diese Fähigkeit nun in kundenseitig betriebene Runtimes.
Das ist kein Argument dafür, jeden bestehenden API-Endpunkt automatisch als Agent-Tool freizugeben. Im Gegenteil: Eine API, die für deterministische Anwendungen entworfen wurde, kann Schreiboperationen enthalten, deren Nutzung durch einen autonomen Agenten eine engere Policy benötigt.
Der Vorteil einer Gateway-Integration liegt darin, dass diese Entscheidung an einer bereits vorhandenen Kontrollstelle getroffen werden kann. Teams müssen nicht zwangsläufig eine parallele Sicherheitsarchitektur nur für MCP aufbauen.
Für kleinere SaaS-Systeme kann ein eigener MCP-Server weiterhin die einfachere Lösung sein. Apigee Hybrid adressiert eine andere Größenordnung: Organisationen mit bestehenden API-Landschaften, privaten Netzwerken und zentralen Governance-Regeln. Dort ist die relevante Neuerung nicht das MCP-Protokoll selbst, sondern dass Agent-Tool-Aufrufe in dieselben betrieblichen Grenzen gezogen werden wie die APIs, die sie am Ende ausführen.