MoEngage stellt interne API-Operationen über Amazon Bedrock AgentCore Gateway als Werkzeuge für interne KI-Agenten bereit. Ein gemeinsam von AWS und MoEngage verfasster Praxisbericht beschreibt, wie das Unternehmen dafür vorhandene OpenAPI-Spezifikationen registriert und daraus MCP-Werkzeuge erzeugt. Der Aufbau trennt Werkzeugdefinition, Zugriffsrechte und Netzwerkverbindung.

Wie aus APIs Agentenwerkzeuge werden

Teams ergänzen bestehende OpenAPI-Spezifikationen um die Annotation x-moe-mcp. Eine CI-Pipeline prüft die Ergänzung, registriert das API-Ziel am Gateway und wendet die zugehörige Cedar-Richtlinie an. AgentCore Gateway erzeugt aus den registrierten Spezifikationen MCP-Werkzeuge. MCP steht für Model Context Protocol, das Protokoll für die Bereitstellung und Nutzung solcher Werkzeuge.

Die Freigabe ist laut Bericht optional und kann für interne und externe Nutzung getrennt festgelegt werden. MoEngages AI-Platform-Team verantwortet demnach Protokoll-, Richtlinien- und Verbindungsschicht. Die Teams können ihre vorhandenen API-Spezifikationen in den Ablauf einbringen, statt für jede API einen eigenen MCP-Server aufzubauen.

Wie IAM und Cedar den Werkzeugzugriff steuern

Jeder interne Agent verwendet eine eigene Rolle in AWS Identity and Access Management (IAM). Die Agentendienste signieren ihre internen Gateway-Anfragen mit SigV4. Cedar-Richtlinien legen serverseitig fest, welche Werkzeuge ein Agent sehen und aufrufen darf. Nicht freigegebene Werkzeuge erscheinen laut Bericht gar nicht erst in der Werkzeugliste.

Ein Beispiel aus dem Bericht ist die Qualitätsprüfung von Kampagnen: Ein entsprechender Agent darf Werkzeuge zum Lesen von Kampagnendaten nutzen, aber keine Schreibaktionen ausführen. Die Richtlinie beschränkt damit nicht nur den eigentlichen Aufruf, sondern auch, welche Werkzeuge dem Agenten angeboten werden.

Mandanten-, Nutzer-, Rollen- und Datenbankkontext wird in MoEngage-spezifischen X-MOE-*-Headern übertragen, nicht als vom Modell bearbeitbares Werkzeugargument. Bei der Werkzeugauflistung und der semantischen Suche wird keine Mandantenidentität mitgegeben; der tatsächliche Werkzeugaufruf (tools/call) enthält sie.

Der private Netzwerkpfad

Der interne Agentendienst verbindet sich per HTTPS über einen VPC-Interface-Endpunkt mit privatem DNS mit dem Gateway. Für den Weg vom Gateway zu den internen APIs nutzt MoEngage verwalteten Egress über Amazon VPC Lattice. Der beschriebene interne Pfad hat keinen öffentlichen Endpunkt.

Die Anmeldung am internen Gateway ist von MoEngages separatem öffentlichen MCP-Dienst zu unterscheiden: Für diesen öffentlichen Dienst beschreibt der Bericht OIDC-JWTs auf AgentCore Runtime. Das sind zwei unterschiedliche Zugriffswege mit unterschiedlichen Authentifizierungsverfahren.

Wie Agenten passende Werkzeuge finden

Statt dem Modell den gesamten Werkzeugkatalog zu übergeben, stellt MoEngages Client-Bibliothek ein Meta-Werkzeug namens search_tools bereit. Der Agent kann damit eine Aufgabe beschreiben und erhält passende Werkzeugkandidaten über semantische Suche. Das soll vermeiden, dass die vollständige Liste der verfügbaren Werkzeuge in den Modellkontext geladen werden muss.

Der Ansatz verbindet also zwei Schritte: Die Richtlinie bestimmt, welche Werkzeuge ein Agent grundsätzlich sehen und aufrufen darf; die Suche hilft anschließend, aus den verfügbaren Kandidaten die zur Aufgabe passenden zu finden.

Umfang und gemeldeter Aufwand

MoEngage beschreibt ein internes Ökosystem von rund 400 REST-APIs, entwickelt von 25 Engineering-Teams und verteilt über sieben AWS-Regionen. Das Gateway stellt dem Bericht zufolge rund 400 registrierte API-Operationen für zehn interne Agenten bereit. APIs und Operationen sind dabei unterschiedliche Zähleinheiten.

MoEngage schätzt, durch den Aufbau etwa sechs Monate Plattform-Engineering-Aufwand eingespart zu haben. Für das Onboarding einer neuen API berichtet das Unternehmen von Stunden statt Tagen. Diese Zeitangabe bezieht sich auf das Einrichten neuer APIs, nicht auf die Antwortzeit einzelner Agentenaufrufe.