MCP-Infrastruktur selbst entwickeln oder kaufen: Ein Entscheidungshilfeleitfaden für SaaS-Teams
Abwägung eines internen MCP-Servers gegen eine verwaltete Plattform: tatsächliche Arbeitslast, Authentifizierung, Kontrollgrad, Eignungsgrenzen, ein hybrider Ansatz sowie fünf Fragen zur vorherigen Klärung.
Quellen: Build or Buy: How SaaS Teams Should Approach MCP Infrastructure
Für ein SaaS-Unternehmen kommt die erste Entscheidung bezüglich MCP in der Regel in Form einer technischen Frage: Soll das Team seinen eigenen MCP-Server entwickeln oder eine verwaltete Plattform mieten? Eine präzisere Formulierung lautet, welche Phasen des MCP-Lebenszyklus das Unternehmen selbst steuern möchte.
Durch die Eigenentwicklung des Servers hat das Team volle Kontrolle über den Code, sein Verhalten zur Laufzeit, die Bereitstellungsorte sowie die Sicherheitsmaßnahmen. Zudem entsteht eine anhaltende Verantwortung für die Entwicklung von Tools, die Handhabung der Authentifizierung, das Hosting, das Testen, das Monitoring, die Reaktion auf Vorfälle sowie das Tracking von API-Änderungen und das Versionieren. Eine verwaltete Plattform bedeutet zwar einen Verzicht auf Teile der Implementierungskontrolle, bringt aber eine schnellere Bereitstellung eines gehosteten Servers sowie geringere Anforderungen an die Infrastruktur mit sich.
Keine der Optionen ist standardmäßig richtig. Die Entscheidung hängt von der bereits vorhandenen API ab, von den zu offenerlegenden Funktionen, von der Art der Endpunkte, die die Clients erwarten, sowie davon, wie viel Entwicklungszeit nach dem Start noch verfügbar ist.
Was die Entscheidung tatsächlich umfasst
Ein MCP-Server ist mehr als nur eine Ansammlung von Handler-Funktionen. Es handelt sich um eine für KI zugängliche Schnittstelle, die in ein bestehendes Produkt integriert ist, und die umfassende Entscheidung kann Folgendes beinhalten:
- die Umwandlung von API-Operationen in Tools, Ressourcen oder Anfragen
- die Erstellung von Namen, Beschreibungen und Eingabeschemata
- die Weiterleitung von API-Schlüsseln, Bearer-Tokens oder OAuth-Zertifikaten während der Ausführung
- die Bereitstellung eines Endpunkts, den die Clients erreichen können
- das Testen der Erkennung, der Anrufe, fehlerhafter Eingaben sowie der Authentifizierung
- die Sammlung von Protokollen und Nutzungssignalen
- die Handhabung von Fehlern sowie Änderungen in der übergeordneten API
Ein Team, das nur die Erstellung eines ersten Servers bewertet, unterschätzt oft den Aufwand bei der Entwicklung. Ein Team, das nur den Komfort eines verwalteten Services berücksichtigt, vernachlässigt möglicherweise die Kontrolle sowie das Eigentumsrecht am Produkt, das es abtritt.
Inhouse-Entwicklung: volle Kontrolle, dauerhaftes Eigentum
Die eigene Entwicklung des Servers macht Sinn, wenn MCP zu einem zentralen Bestandteil der Plattformstrategie wird. Das Team entscheidet dann über:
- wie jede Funktionalität umgesetzt wird
- ob ein Tool einen einzigen API-Aufruf abwickelt oder mehrere Schritte koordiniert
- wie Identitäten und Berechtigungen durchgesetzt werden
- welchen Transport sowie welche Hosting-Lösung gewählt wird
- wie Fehler für die Kunden dargestellt werden
- was protokolliert wird und was geheim gehalten wird
- wie der Server in interne Bereitstellungs- und Sicherheitssysteme integriert wird
Diese Form der Kontrolle lohnt sich, wenn die MCP-Schicht Aufgaben erledigen muss, die eine fertige API-zu-MCP-Konvertierung nicht bewältigen kann. Sie eignet sich auch für Organisationen, die bereits ein Team haben, das sich um gemeinsame Laufzeiten, Überwachbarkeit, Konformität und Reaktionsmaßnahmen auf Vorfälle kümmert.
Die Verantwortung erstreckt sich jedoch weit über die erste Implementierung hinaus. Der Server muss so lange gewartet werden, wie sich das Produkt weiterentwickelt.
Die eigentliche Arbeitsbelastung eines internen Servers
Engineering
Zu den frühen Schritten gehören die Auswahl eines MCP-SDKs, das Zuordnen von API-Aufgaben, die Definition von Tool-Schemata, die Übersetzung von Anfragen sowie das Schreiben von Tests. Schwierigere Arbeitsabläufe beinhalten zudem benutzerdefinierte Orchestrierung, Zustandsverwaltung, Wiederholungsversuche, Paginierung und Formulierung der Antworten.
Die Aufwände steigen mit der Größe der API – und auch dann, wenn der für KI vorgesehene Workflow nicht gut mit einzelnen Endpunkten übereinstimmt. Ein einfacher Wrapper lässt sich schnell schreiben, während eine gut gestaltete Produktoberfläche deutlich länger zu entwickeln ist.
Hosting und Bereitstellung
Der Server muss an einem Ort laufen, den MCP-Client erreichen können. Das Team wählt einen Transportmechanismus aus, konfiguriert Bereitstellungs- und Umgebungsvariablen, kümmert sich um das Netzwerk, bewältigt Skalierungsprobleme und greift ein, wenn Verbindungen oder Aufrufe an externe Systeme fehlschlagen. Auch ein Release-Prozess ist wichtig. Ein Server, der nur auf dem Laptop eines einzigen Entwicklers funktioniert, ist ein Prototyp und keine zuverlässige Integration.
Authentifizierung und Datenverarbeitung
Zur Laufzeit muss die richtige API-Schlüssel, Bearer-Token oder OAuth-Zugangsdaten zur zugrunde liegenden API gelangen, und diese Geheimnisse erfordern sorgfältige Handhabung, Regelmäßige Erneuerung, definierte Berechtigungsrahmen sowie ein klares Vorgehen bei Fehlern. Zudem muss jemand entscheiden, welche Anfragedaten, Ergebnisse und Fehlerdetails in den Protokollen gespeichert werden, was sowohl das Sicherheitsmodell als auch die Betriebskosten beeinflusst.
Testing und Überwachbarkeit
Die Testsuite muss die Verbindungsfähigkeit, die Fähigkeit zur Erkennung von Ressourcen, Schemata, gültige und ungültige Eingaben, abgelehnte Autorisierungen, Fehler im upstream-System, Zeitüberschreitungen sowie die Handhabung der Antworten überprüfen. Nach dem Start sollten ausreichend Telemetriedaten vorhanden sein, um Fragen wie diese beantworten zu können:
- Welche Tools werden verwendet?
- Welche Operationen scheitern am häufigsten?
- Stammt die Verzögerung vom MCP-Server oder von der API?
- Senden die Clients fehlerhafte Eingaben?
- Hat ein API-Update das Verhalten eines bestehenden Tools verändert?
Entweder entwickelt das Team dies selbst oder es kombiniert mehrere bestehende Systeme miteinander.
Wartung und Versionierung
Die zugrunde liegende API wird sich weiterentwickeln. Parameter ändern sich, Operationen werden veraltet, Sicherheitsregeln verschärfen sich und die Antwortstrukturen erhalten oder verlieren Felder – die MCP-Konfiguration muss dem entsprechend angepasst werden. Eine ausgereifte Einrichtung erfordert Code-Reviews, Testumgebungen, versionierte Bereitstellungen, die Möglichkeit zum Rollback sowie die Gewohnheit, Toolbeschreibungen stets aktuell zu halten.
Inhouse-Entwicklung gewährleistet Kontrolle, doch der Preis dafür ist, die Verantwortung für alle diese Entscheidungen während der gesamten Laufzeit der Integration zu tragen.
Gemanagte Plattformen: weniger Infrastruktur zu verwalten
Eine gemanagte MCP-Plattform basiert auf einem anderen Ansatz. Das SaaS-Unternehmen verfügt bereits über eine API und möchte lediglich bestimmte Funktionen für MCP-Kunden zugänglich machen, ohne die gesamte Betriebsschicht selbst erstellen zu wollen. In der Regel verläuft der Arbeitsablauf durch folgende Schritte:
- Import einer API-Definition
- Erkennung der verfügbaren Operationen
- Auswahl der zu offenzlegenden Funktionen
- Konfiguration von Tools, Ressourcen und Anfragen
- Hosten des MCP-Endpunkts
- Testen der Schnittstelle
- Überwachung und Versionierung der Konfiguration
Die Plattform übernimmt das SaaS-Produkt nicht. Geschäftslogik, Benutzerrechte, Tenant-Grenzen, Paginierung und Rate Limits bleiben bei der ursprünglichen API. Was abnimmt, ist die Infrastrukturarbeit rund um die MCP-Schnittstelle.
Verantwortlichkeiten
- API-Kartierung. Intern schreibt das Team die Übersetzungsschicht und wartet sie. Auf einer Plattform importiert es die API-Definition und prüft die erkannten Operationen.
Daher handelt es sich bei dem Vergleich nicht um Code gegen keinen Code. Es geht vielmehr darum, ob das Team die Infrastruktur selbst besitzt oder ob diese von jemand anderem betrieben wird.
Ein Beispiel für einen verwalteten Weg: 0mcp
0mcp ist eine Plattform für SaaS-Teams mit einer bereits vorhandenen API-Definition, die einen gehosteten MCP-Server ohne Verwaltung des gesamten MCP-Stacks wünschen. Ihr Arbeitsablauf umfasst:
- Import einer unterstützten Swagger- oder OpenAPI-Definition sowie einer Postman-Kollektion
- Erkennung von Endpunkten und Operationen
- Auswahl der verfügbaren API-Funktionen
- Erstellung oder Anpassung von Tools, Ressourcen und Anleitungen
- Umformulierung von Funktionsnamen und Beschreibungen
- Testen des gehosteten Servers
- Übermittlung einer API-Schlüssel, eines Bearer-Tokens oder von OAuth-Zertifikaten an die ursprüngliche API
- Speichern von Konfigurationsversionen, Überprüfen von Änderungen und Wiederherstellen einer früheren Version
Der generierte Server wird über Streamable HTTP bereitgestellt und die Hosting-Funktionen werden selbst ausgeführt. Lokale stdio-MCP-Server werden derzeit nicht unterstützt. Dies eignet sich besser für Teams, die einen gehosteten Remote-Endpunkt benötigen, als für Teams, deren Hauptanforderung ein lokaler Prozess neben einer Desktop-Anwendung ist.
Welche Authentifizierungsverfahren eine Plattform ersetzen kann und welche nicht
Eine verwaltete Plattform sollte niemals das Autorisierungsmodell innerhalb der SaaS-API ersetzen. Die API entscheidet weiterhin, ob eine Anmeldeinformation gültig ist, welcher Mieter oder Benutzer sie besitzt, welche Datensätze er lesen darf und welche Aktionen er ausführen kann.
Mit 0mcp werden Anmeldeinformationen über den MCP-Client übermittelt und bei jeder Anfrage an die ursprüngliche API weitergeleitet; die Plattform speichert sie nicht. Das Team muss dennoch die Authentifizierung der API ordnungsgemäß konfigurieren, Anmeldeinformationen mit minimalem Berechtigungsgrad verwenden und abgelehnte Anfragen testen.
Kontrolle in unterschiedlichem Maße
Der übliche Einwand gegen eine verwaltete Plattform ist der Verlust der Kontrolle. Diese Sorge ist berechtigt, sollte aber konkretisiert werden. Bei einem selbst gebauten Server hat das Team die Kontrolle über die Implementierungsdetails. Bei einer Plattform wie dieser hat es hingegen die Kontrolle über die für die Nutzer sichtbaren Optionen, die die Plattform unterstützt:
- welche API-Operationen bereitgestellt werden
Es steuert keinen willkürlichen Laufzeitcode innerhalb der Plattform, und die Plattform ersetzt keine maßgeschneiderte Geschäftslogik. Ein Workflow, der eine spezielle Orchestrierung erfordert, die durch die vorhandenen API nicht abgebildet werden kann, wird möglicherweise besser intern entwickelt.
Die Trennung ist an sich nützlich. Von API unterstützte Funktionen können in einen verwalteten Service integriert werden, während maßgeschneiderter Code für die Teile des Produkts reserviert bleibt, die ihn tatsächlich benötigen.
Fälle, in denen eine eigene Entwicklung vorteilhaft ist
Entwickeln Sie intern, wenn mehrere der folgenden Bedingungen zutreffen:
- MCP ist eine strategische Funktion, die das Unternehmen tiefgehend beherrschen möchte.
- Die Tools müssen sich auf Weise verhalten, die über das Abgleichen bestehender API-Operationen hinausgeht.
- Eine lokale
stdio-Implementierung oder ein Transportmechanismus, den die Plattform nicht bietet, ist erforderlich. - Ein spezialisierter Laufzeitumfeld, eine interne Netzwerkstruktur oder eine angepasste Datenverarbeitung sind notwendig.
- Die technischen, sicherheitstechnischen und betrieblichen Kapazitäten zur Wartung existieren bereits.
- Die Unternehmensrichtlinien erfordern Kontrollmechanismen oder Bereitstellungssysteme, die eine Plattform nicht bieten kann.
- Der langfristige Nutzen von maßgeschneiderten Kontrollmechanismen überwiegt die Wartungskosten.
Die Eigenentwicklung macht das System nicht automatisch sicherer oder zuverlässiger. Sie ermöglicht es dem Team, diese Eigenschaften zu entwerfen, doch sie müssen dennoch konsequent implementiert und betrieben werden.
Fälle, in denen eine Plattform vorteilhaft ist
Eine verwaltete Plattform wie diese eignet sich praktisch, wenn:
- das Produkt bereits nützliche API-Funktionen bereitstellt
- das Team bald einen gehosteten MCP-Server haben möchte
- Die bestehende API sollte weiterhin die Quelle der Wahrheit für Geschäftsregeln und Autorisierungen bleiben
- Eine fokussierte Auswahl an Funktionen ist vorzuziehen statt jedes Tool selbst zu entwickeln
- Pass-through-Authentifizierung ist besser als ein separates Zertifizierungssystem
- Es werden gehostete Tests, Protokolle, Analysen sowie Versionsverwaltung benötigt
- Die vollständige Übernahme der Hosting- und Infrastruktur ist nicht gewünscht
Die Eignung nimmt ab, wenn ein lokaler stdio-Server, freiformiger Code auf dem Server oder eine andere Übertragungsmethode als der gehostete Streamable HTTP erforderlich ist. Teams mit formellen Infrastruktur-, Konformitäts- oder Verfügbarkeitsanforderungen sollten außerdem sorgfältig den aktuellen Anwendungsbereich des Produkts prüfen, da 0mcp weder eine formelle SLA noch eine formelle Sicherheitszertifizierung bietet. Solche Abgrenzungen sind Teil einer verantwortungsvollen Entscheidungsfindung. Eine Plattform sollte für die Aufgaben ausgewählt werden, die sie tatsächlich bewältigen kann, und nicht aufgrund von Fähigkeiten, die nie behauptet wurden.
Fünf Fragen, die zuerst beantwortet werden sollten
Ist die vorhandene API bereits die richtige Produktinterface? Klare Abläufe, Schemata, Authentifizierungsmethoden sowie nützliche Antworten bilden eine solide Ausgangsbasis für einen Workflow von API zu MCP. Wenn grundlegende Geschäftsprozesse in der API fehlen, wird ein Wechsel zur MCP-Schicht diese Lücke nicht schließen.
Wie viel individuelles Verhalten benötigt der KI-Arbeitsablauf? Wenn jede Funktionalität eindeutig auf eine API-Operation abgebildet werden kann, reduziert sich die Implementierungsarbeit einer Plattform. Komplexe Orchestrierung, neue Geschäftsregeln oder Datenerfassungen, die von der API nicht unterstützt werden, können eine individuelle Entwicklung erfordern.
Wer wird den Endpunkt in sechs Monaten betreiben? Benennen Sie einen Verantwortlichen für Incidents, Zugangsdaten, API-Änderungen, Tool-Qualität, Latenz und Rollbacks. Ohne einen klaren Verantwortlichen kann ein weiterer selbstverwalteter Service mehr Risiken als Vorteile mit sich bringen.
Welches Bereitstellungsmodell benötigen die Kunden? Wenn lokale stdio-Funktionen unerlässlich sind, sollte man inhouse entwickeln oder sich eine andere Plattform ansehen.
Was sollte hier durch Kontrollmechanismen abgedeckt werden? Es gibt mehrere Ebenen: die Geschäftsregeln, wer welche Daten einsehen darf, die Auswahl der bereitgestellten Funktionen, die zugrunde liegende Infrastruktur sowie eventuell vorhandener Code zur Laufzeit. Ein Team kann sich auf die ersten drei Ebenen konzentrieren und die anderen beiden auslagern.
Eine Mischlösung ist zulässig
Die Entscheidung muss weder dauerhaft noch absolut sein. Ein SaaS-Unternehmen kann einfache, über API gestützte Funktionen über eine Plattform bereitstellen und gleichzeitig maßgeschneiderte MCP-Dienste für Workflows mit spezieller Logik entwickeln. So kann es herausfinden, welche Tools die Nutzer tatsächlich benötigen, bevor es in eine größere interne Plattform investiert. Zudem kann es die ursprüngliche API sowie deren Autorisierungsmechanismen unverändert lassen, während es auf der KI-orientierten Seite neue Lösungen ausprobiert.
Wichtig ist eine klare Struktur: eine Liste der verwalteten Funktionen, eine Liste der benutzerdefinierten Funktionen, ein benannter Eigentümer für jede Laufzeitumgebung sowie eine vereinbarte Methode zur Überprüfung von Änderungen.
Die eigentliche Frage ist das Eigentumsverhältnis
Ob man MCP-Infrastruktur selbst entwickelt oder kauft, hängt vom Eigentumsverhältnis ab. Das Selbstschreiben des Servers ist gerechtfertigt, wenn ein benutzerdefiniertes Verhalten, strenge Kontrolle über die Bereitstellung oder ein strategisches Eigentum an der Plattform den Aufwand in Entwicklung und Betrieb wert sind. Wählt man eine verwaltete Plattform, so verfügt die bestehende API bereits über die Funktionen, die bereitgestellt werden sollen, und das Team möchte seine Energie lieber der Anpassung widmen als einer weiteren Infrastruktursschicht.