Open Source MCP Plattformen: Warum Verzeichnisse jetzt an Bedeutung gewinnen

Open Source MCP Plattformen machen Integrationen zwischen KI-Agenten, Unternehmensdaten und Fachanwendungen auffindbar und wiederverwendbar. Ihre Bedeutung wächst, weil MCP vom Entwicklerexperiment zur produktiven Integrationsschicht wird und Unternehmen kontrollierte Bezugsquellen benötigen. Verzeichnisse liefern dafür Metadaten, Installationswege und erste Vertrauenssignale, ersetzen jedoch keine technische, rechtliche und organisatorische Freigabe.

Warum rücken Open Source MCP Plattformen in den Mittelpunkt?

Ein Sprachmodell allein kann Texte verfassen, Informationen einordnen und Vorschläge entwickeln. Für einen betrieblichen Ablauf reicht das selten aus. Ein KI-Agent muss auf aktuelle Daten zugreifen, Dokumente lesen, Datensätze suchen, Termine prüfen, Tickets anlegen, Entwicklungsumgebungen bedienen oder freigegebene Aktionen in einer Fachanwendung ausführen können.

Genau an dieser Stelle setzt das Model Context Protocol, kurz MCP, an. Das von Anthropic im November 2024 vorgestellte offene Protokoll standardisiert die Verbindung zwischen KI-Anwendungen und externen Datenquellen, Werkzeugen sowie Arbeitsabläufen. Statt für jedes Sprachmodell und jede Anwendung eine individuelle Schnittstelle zu entwickeln, kann ein Anbieter einen MCP-Server bereitstellen, den unterschiedliche kompatible Clients verwenden.

Aus einer technischen Schnittstelle ist inzwischen ein breites Ökosystem geworden. Anthropic übergab MCP im Dezember 2025 an die Agentic AI Foundation unter dem Dach der Linux Foundation. Die Stiftung berichtete zu diesem Zeitpunkt von mehr als 10.000 veröffentlichten MCP-Servern. Die neutrale Trägerschaft sowie die Unterstützung durch Unternehmen wie Microsoft, Google, AWS, OpenAI und Cloudflare verstärken den Charakter eines herstellerübergreifenden Standards.

Mit der Zahl der verfügbaren Server wächst jedoch ein neues Problem: Unternehmen müssen geeignete Integrationen überhaupt erst finden, ihre Herkunft nachvollziehen, Versionen unterscheiden und erkennen, ob ein Angebot gepflegt, installierbar und für den vorgesehenen Prozess geeignet ist. Eine Liste von GitHub-Links genügt dafür auf Dauer nicht. Benötigt werden Registries und Verzeichnisse, die technische Metadaten, Herausgeber, Pakete, Endpunkte und Aktualisierungen strukturiert erfassen.

Was macht ein MCP-Verzeichnis anders als einen gewöhnlichen Softwarekatalog?

Ein klassischer Softwarekatalog beschreibt Produkte, Preise und typische Einsatzgebiete. Ein MCP-Verzeichnis beschäftigt sich dagegen mit Komponenten, die einem KI-Agenten konkrete Fähigkeiten zur Verfügung stellen. Ein eingetragener Server kann Daten lesen, Suchabfragen durchführen oder Aktionen in verbundenen Systemen auslösen.

Diese Nähe zum tatsächlichen Prozess verändert die Anforderungen. Ein fehlerhafter Textgenerator erzeugt möglicherweise ein schlechtes Ergebnis. Ein ungeeigneter MCP-Server kann dagegen auf Dateisysteme zugreifen, Datensätze verändern, Nachrichten versenden oder Zugangsdaten verwenden. Die Auswahl einer Integration ist daher nicht nur eine Produktfrage, sondern auch eine Entscheidung über Berechtigungen, Datenflüsse und ausführbare Funktionen.

MCP-Server können lokal als Prozess laufen oder als entfernter Dienst angesprochen werden. Sie beschreiben gegenüber dem Client ihre verfügbaren Werkzeuge, Ressourcen und Eingabeparameter. Dadurch kann eine KI-Anwendung neue Funktionen nutzen, ohne dass das zugrunde liegende Modell dafür erneut trainiert werden muss.

Ein gutes Verzeichnis sollte deshalb mehr leisten als eine kategorisierte Linkliste. Relevant sind insbesondere eine überprüfbare Anbieteridentität, Repository und Paketquelle, Lizenz, Installationsweg, unterstützte Transportart, benötigte Zugangsdaten, Versionsstand, Änderungsverlauf und eine nachvollziehbare Beschreibung der verfügbaren Funktionen.

Welche Plattform eignet sich für welchen Zweck?

Die Bezeichnung „Open Source MCP Plattformen“ umfasst unterschiedliche Angebote. Einige sind tatsächlich offene Registries mit einsehbarem Quellcode, andere sind gehostete Such- und Installationsdienste, redaktionelle Sammlungen oder ergänzende Modellplattformen. Auch wenn sie ähnliche Suchfelder anbieten, erfüllen sie nicht dieselbe Rolle.

Die Tabelle zeigt einen entscheidenden Unterschied: Eine Plattform kann beim Finden helfen, ohne eine verlässliche Bezugsquelle zu sein. Ebenso kann eine technisch gepflegte Registry einen Server korrekt katalogisieren, obwohl dieser für den Zugriff auf personenbezogene Daten, ERP-Systeme oder produktive Schreiboperationen nicht freigegeben werden sollte.

Warum bleiben Awesome Lists auf GitHub wichtig?

Awesome Lists sind ein typisches Instrument der Open-Source-Welt. Entwickler sammeln Projekte in einem öffentlich einsehbaren Repository, ordnen sie nach Themen und nehmen Ergänzungen über Pull Requests entgegen. Für neue Technologien entsteht dadurch oft schneller eine brauchbare Übersicht als durch formale Standardisierung.

Das Repository „awesome-mcp-servers“ von punkpeye verzeichnete zum Recherchezeitpunkt rund 90.800 GitHub-Sterne. Diese außergewöhnlich hohe Resonanz zeigt, wie stark der Bedarf nach einer zentralen Übersicht innerhalb kurzer Zeit gewachsen ist. Die Liste umfasst produktionsnahe und experimentelle Server für Datenbanken, Entwicklungswerkzeuge, Dateisysteme, Browser, Kommunikation und zahlreiche weitere Aufgaben.

Für die erste technische Recherche bleibt eine solche Sammlung wertvoll. Ein IT-Verantwortlicher gelangt direkt zum Quellcode, kann Commit-Historie, offene Fehler, Mitwirkende und Lizenz einsehen und erkennt oft schneller als in einem Marketingprofil, wie aktiv ein Projekt gepflegt wird.

Gleichzeitig ist die Aufnahme in eine Awesome List keine formale Zertifizierung. Die Pflege erfolgt gemeinschaftlich, Einträge verändern sich schnell, und die Qualität der einzelnen Projekte fällt unterschiedlich aus. Eine Liste dieser Art eignet sich daher gut für die Bildung einer Longlist, aber nicht als unternehmensweite Freigabeliste.

Warum wird die offizielle MCP Registry zum Referenzpunkt?

Die offizielle MCP Registry beschreibt sich selbst als eine Art App Store für MCP-Server. Entscheidend ist dabei weniger die Weboberfläche als die maschinenlesbare Infrastruktur dahinter. MCP-Clients, Entwicklungsumgebungen und unternehmensinterne Kataloge können Registry-Daten über eine standardisierte Schnittstelle abrufen.

Der Quellcode der Registry ist öffentlich verfügbar. Auch das übergeordnete Datenmodell und die API-Spezifikation sind offen angelegt, sodass Anbieter kompatible Unterverzeichnisse oder interne Registries betreiben können. Damit entsteht nicht nur eine zentrale Liste, sondern eine Grundlage für ein verteiltes Registry-Ökosystem.

Besonders relevant ist die Prüfung von Namespaces. Wer einen Server unter einem GitHub- oder Domain-Namensraum veröffentlicht, muss die Kontrolle über das zugehörige Konto beziehungsweise die Domain nachweisen. Die Registry unterstützt dafür unter anderem GitHub OAuth, GitHub OIDC sowie DNS- und HTTP-Prüfungen. Das erschwert es Dritten, sich ohne Weiteres als bekannter Anbieter auszugeben.

Diese Prüfung bestätigt die Zuordnung eines Namens, nicht die Sicherheit des Programmcodes. Für ein Unternehmen ist sie dennoch ein wichtiger Baustein der Lieferkette: Es macht einen erheblichen Unterschied, ob ein Connector tatsächlich vom angegebenen Hersteller stammt oder lediglich einen ähnlichen Namen verwendet.

Wie unterscheiden sich Smithery, PulseMCP und das Model Context Protocol Directory?

Smithery richtet sich stärker auf die praktische Entdeckung und Verbindung von MCP-Servern aus. Die Plattform zeigt Anwendungen nach Fähigkeiten, Herausgebern und Nutzungssignalen und bietet Wege, Server in Agentenumgebungen einzubinden. Für Entwickler und Pilotprojekte sinkt dadurch der Aufwand, Installationsanweisungen aus unterschiedlichen Repositories zusammenzutragen.

Für einen produktiven Unternehmenseinsatz muss geprüft werden, ob nur die Vermittlung und Konfiguration über Smithery erfolgt oder ob Daten, Zugangsdaten beziehungsweise Laufzeitbestandteile über gehostete Dienste verarbeitet werden. Außerdem ist zwischen der Plattform und dem jeweils gelisteten MCP-Server zu unterscheiden. Ein gut gestaltetes Smithery-Profil sagt noch nichts über die organisatorische Reife des eigentlichen Herausgebers aus.

PulseMCP verfolgt einen breiteren Informationsansatz. Neben Servern führt die Plattform Clients, Anwendungsfälle, Werkzeuge und redaktionelle Inhalte. Das Serververzeichnis wurde zum Recherchezeitpunkt mit mehr als 22.300 Einträgen ausgewiesen und nach Angaben der Plattform täglich aktualisiert. Für Marktbeobachtung und Longlists ist diese Breite nützlich, gleichzeitig steigt damit der Aufwand für Dublettenprüfung, Herkunftsbewertung und fachliche Eingrenzung.

Die Bezeichnung Model Context Protocol Directory wird von verschiedenen Community-Angeboten verwendet. Das unter https://directorymcp.com/ bekannte Angebot ist eher als ergänzende Suchoberfläche einzuordnen und nicht mit der offiziellen Registry gleichzusetzen. Bei der aktuellen Prüfung leitete die Adresse weiter, ohne eine vergleichbare offene Registry-Struktur auszuweisen. Für Beschaffungs- oder Freigabeprozesse sollte deshalb immer auf das Ursprungsrepository, den tatsächlichen Anbieter und nach Möglichkeit einen verifizierten Registry-Eintrag zurückgegangen werden.

Welche Rolle spielt OpenRouter im MCP-Stack?

OpenRouter wird häufig gemeinsam mit Agentenplattformen und MCP genannt, erfüllt aber eine andere Aufgabe. Die Plattform stellt einen einheitlichen API-Zugang zu Sprachmodellen verschiedener Anbieter bereit. Anwendungen können Modelle auswählen, Anbieter wechseln und Ausweichregeln für Verfügbarkeit, Preis oder Leistung definieren.

OpenRouter ist damit Teil der Modellschicht, während MCP die Verbindung zu Werkzeugen und Daten standardisiert. Ein Agent kann beispielsweise über OpenRouter ein geeignetes Sprachmodell beziehen und gleichzeitig über MCP auf ein CRM-System, eine Wissensbasis oder eine Entwicklungsplattform zugreifen.

Laut aktueller Preisübersicht bietet OpenRouter Zugang zu mehr als 400 Modellen. Diese Auswahl kann bei Tests und Modellwechseln nützlich sein, führt aber zu zusätzlichen Entscheidungen über Provider, Kosten, Datenverarbeitung und zulässige Modellfamilien.

Für mittelständische Unternehmen ist die Trennung der Ebenen wichtig. Das Sprachmodell entscheidet über Verarbeitungseigenschaften und Ergebnisqualität. Der MCP-Server entscheidet darüber, auf welche betrieblichen Informationen und Aktionen der Agent zugreifen kann. Beide Ebenen benötigen eigene Freigaben und können unabhängig voneinander ausgetauscht werden.

Warum werden Verzeichnisse zur Governance-Infrastruktur?

In der frühen Erprobungsphase kopiert ein Entwickler eine Konfiguration aus einem Repository und startet einen MCP-Server lokal. Sobald mehrere Teams, Clients und Fachbereiche beteiligt sind, wird dieses Vorgehen schwer steuerbar. Unterschiedliche Versionen, nicht dokumentierte Zugangsdaten und spontan installierte Server erzeugen eine neue Form von Schatten-IT.

Eine Registry kann dann zur Quelle für zugelassene Integrationen werden. Statt beliebige Server zu installieren, greifen Mitarbeiter und Entwicklungswerkzeuge nur auf einen kuratierten Unternehmenskatalog zu. Dieser kann freigegebene Versionen, verantwortliche Stellen, zulässige Einsatzbereiche und benötigte Genehmigungen enthalten.

GitHub unterstützt für Copilot bereits eigene Registry-Quellen und durchsetzbare Allowlist-Regeln. Administratoren können festlegen, dass nur Server aus einem vorgegebenen Katalog genutzt werden dürfen. Damit wird das Verzeichnis von einer Suchhilfe zu einem technischen Kontrollpunkt.

Die MCP-Roadmap für 2026 nennt Enterprise Readiness ausdrücklich als Schwerpunkt. Im Mittelpunkt stehen unter anderem Audit Trails, SSO-gestützte Authentifizierung, Gateway-Verhalten und übertragbare Konfigurationen. Auch eine standardisierte, ohne aktive Verbindung abrufbare Beschreibung von Serverfähigkeiten ist vorgesehen. Genau solche Metadaten werden benötigt, damit Registries Server automatisiert erfassen und bewerten können.

Für den Mittelstand bedeutet das nicht, sofort eine eigene Registry-Plattform entwickeln zu müssen. Häufig genügt zunächst ein gepflegter interner Katalog, der nur freigegebene Server und Versionen enthält. Wichtig ist, dass die Liste mit technischen Richtlinien, Verantwortlichkeiten und einem nachvollziehbaren Änderungsprozess verbunden wird.

Welche Risiken bleiben trotz Open Source bestehen?

Offener Quellcode schafft Prüfbarkeit, aber keine automatische Sicherheit. Ein Repository kann veraltet sein, schädliche Abhängigkeiten enthalten oder bei der Installation zusätzliche Pakete laden. Ebenso ist möglich, dass der veröffentlichte Quellcode nicht exakt dem gehosteten Server oder dem tatsächlich ausgelieferten Paket entspricht.

Ein MCP-Server erhält je nach Konfiguration Zugriff auf sensible Informationen und ausführbare Funktionen. Die offizielle Spezifikation verlangt deshalb Eingabevalidierung, Zugriffskontrollen, Begrenzung von Aufrufen, Bereinigung von Ausgaben und Protokollierung. Bei sensiblen Aktionen sollten Nutzer die Parameter vor der Ausführung sehen und zustimmen können.

Weitere Risiken entstehen durch manipulierte Werkzeugbeschreibungen, indirekte Prompt-Injection, übermäßige Berechtigungen und unkontrollierte Weitergabe von Kontext. OWASP empfiehlt deshalb, externe MCP-Server wie Bestandteile der Softwarelieferkette zu behandeln und Herkunft, Berechtigungen, Code, Abhängigkeiten sowie Laufzeitverhalten zu untersuchen.

Auch ein Server aus einem bekannten Verzeichnis sollte zunächst in einer isolierten Umgebung getestet werden. Zugangsdaten gehören in eine geeignete Secret-Verwaltung, Schreiboperationen sollten begrenzt und besonders sensible Aktionen durch zusätzliche Freigaben abgesichert werden.

Wie bewertet ein Mittelständler einen MCP-Server?

Die Bewertung sollte beim Geschäftsprozess beginnen. Zunächst ist festzuhalten, welche Aufgabe der Agent übernehmen soll, auf welche Daten er dafür zugreifen muss und welche Aktionen tatsächlich erforderlich sind. Ein Server für die reine Suche in freigegebenen Produktinformationen benötigt andere Schutzmaßnahmen als ein Connector, der Kundenstammdaten ändert oder Bestellungen auslöst.

Danach wird die technische Herkunft geprüft. Dazu gehören Herausgeber, Registry-Namespace, Repository, Paketquelle, Lizenz, letzte Änderungen, offene Sicherheitsmeldungen und der Umgang mit Abhängigkeiten. Bei einem gehosteten Angebot kommen Betreiber, Serverstandort, Unterauftragnehmer, Vertragsbedingungen und Löschkonzept hinzu.

Anschließend sollte das Berechtigungsmodell betrachtet werden. Ein MCP-Server erhält nur die Rechte, die für den abgegrenzten Anwendungsfall notwendig sind. Lesender Zugriff ist gegenüber Schreibzugriff zu bevorzugen, sofern der Prozess damit auskommt. Benutzerbezogene Berechtigungen, Protokollierung und zeitlich begrenzte Zugangsdaten reduzieren den möglichen Schaden bei Fehlfunktionen.

Erst danach folgt die fachliche Prüfung. Ein realistischer Testfall zeigt, ob der Agent die richtigen Werkzeuge auswählt, Eingaben vollständig übergibt, Fehler behandelt und bei riskanten Aktionen eine Bestätigung anfordert. Ein positiver Funktionstest reicht nicht aus; auch ungültige Eingaben, fehlende Daten, Zeitüberschreitungen und nicht verfügbare Zielsysteme gehören zum Testumfang.

Wie sieht ein sinnvoller Einführungsweg aus?

Ein mittelständisches Unternehmen sollte nicht mit einem großen Katalog beginnen, sondern mit wenigen Prozessen, deren Nutzen und Risiko gut eingegrenzt werden können. Geeignet sind beispielsweise eine lesende Suche in technischer Dokumentation, die Abfrage eines Projektstatus oder das Erstellen eines Entwurfs, der vor der Übernahme von einem Mitarbeiter freigegeben wird.

Für jeden Pilot werden der verwendete Client, das Sprachmodell, der MCP-Server, die Datenquellen, Berechtigungen und verantwortlichen Stellen dokumentiert. Diese Trennung verhindert, dass ein erfolgreicher Test mit einem bestimmten Modell automatisch als Freigabe für sämtliche Modelle oder Datenbestände verstanden wird.

Bewährt sich der Ablauf, entsteht daraus ein interner MCP-Katalog. Dieser enthält nur geprüfte Kombinationen aus Server, Version, Zweck und Betriebsform. Öffentliche Verzeichnisse bleiben weiterhin wichtig, dienen dann aber vor allem der Marktbeobachtung und Kandidatensuche. Die tatsächliche Nutzung richtet sich nach dem internen Bestand.

Open Source MCP Plattformen gewinnen deshalb nicht nur an Bedeutung, weil mehr Server veröffentlicht werden. Sie bilden zunehmend die Schicht, über die Integrationen gefunden, bezogen, aktualisiert und im Unternehmen gesteuert werden. Wer diese Entwicklung früh in Architektur und Governance einbezieht, vermeidet später eine schwer wartbare Ansammlung einzelner Agentenverbindungen.

Welche Quellen belegen die verwendeten Kennzahlen?

Linux Foundation: Formation of the Agentic AI Foundation
Verwendete Kennzahl: mehr als 10.000 veröffentlichte MCP-Server.
https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation

GitHub: punkpeye/awesome-mcp-servers
Verwendete Kennzahl: rund 90.800 GitHub-Sterne zum Recherchezeitpunkt.
https://github.com/punkpeye/awesome-mcp-servers

PulseMCP: MCP Server Directory
Verwendete Kennzahl: mehr als 22.300 gelistete Server zum Recherchezeitpunkt.
https://www.pulsemcp.com/servers

OpenRouter: Pricing
Verwendete Kennzahl: Zugang zu mehr als 400 Sprachmodellen.
https://openrouter.ai/pricing

Welche interessanten Links vertiefen das Thema?

Model Context Protocol: Roadmap 2026
https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/

GitHub: MCP-Server finden, installieren und verwalten
https://github.blog/ai-and-ml/generative-ai/how-to-find-install-and-manage-mcp-servers-with-the-github-mcp-registry/

OWASP: Leitfaden für den sicheren Einsatz externer MCP-Server
https://genai.owasp.org/resource/cheatsheet-a-practical-guide-for-securely-using-third-party-mcp-servers-1-0/

FAQ zu Open Source MCP Plattformen

Was ist eine Open Source MCP Plattform?

Eine Open Source MCP Plattform unterstützt die Veröffentlichung, Suche oder Verwaltung von Servern für das Model Context Protocol. Je nach Angebot handelt es sich um eine offene Registry, eine Community-Liste oder einen Katalog mit Installationsinformationen. Nicht jede Plattform, die offene MCP-Server auflistet, stellt jedoch ihren eigenen Plattformcode als Open Source bereit.

Was ist der Unterschied zwischen einem MCP-Server und einer API?

Eine API stellt Funktionen oder Daten über definierte technische Endpunkte bereit. Ein MCP-Server beschreibt diese Fähigkeiten in einem standardisierten Format, das kompatible KI-Anwendungen dynamisch einlesen können. Häufig kapselt ein MCP-Server eine vorhandene API. Er ergänzt sie um Werkzeugbeschreibungen, Eingabeschemata und Protokollfunktionen für den Einsatz durch KI-Agenten.

Warum benötigen Unternehmen ein MCP-Verzeichnis?

Ein MCP-Verzeichnis macht verfügbare Integrationen auffindbar und liefert Informationen zu Herausgeber, Zweck, Version und Installation. Bei wachsender Zahl von Servern wird diese Struktur für Architektur und Betrieb wichtig. Unternehmen sollten öffentliche Verzeichnisse für die Recherche nutzen und daraus einen eigenen Katalog mit geprüften, zugelassenen Servern und Versionen ableiten.

Ist ein Eintrag in der offiziellen MCP Registry eine Sicherheitsfreigabe?

Nein. Die offizielle Registry prüft unter anderem, ob ein Herausgeber einen verwendeten GitHub- oder Domain-Namespace kontrolliert. Das verbessert die Zuordnung und reduziert bestimmte Formen der Namensnachahmung. Der Eintrag bestätigt jedoch weder fehlerfreien Code noch Datenschutz, sichere Konfiguration, regelmäßige Wartung oder die Eignung für einen bestimmten Unternehmensprozess.

Sind MCP-Server aus GitHub Awesome Lists vertrauenswürdig?

Eine Awesome List erleichtert den Einstieg und führt häufig direkt zu Quellcode, Lizenz und Projektaktivität. Die Aufnahme ist jedoch keine Zertifizierung. Vor einer Verwendung müssen Unternehmen Herausgeber, Abhängigkeiten, Berechtigungen, offene Sicherheitsmeldungen und Wartungsstatus prüfen. Besonders bei Schreibzugriffen oder sensiblen Daten ist ein isolierter technischer Test erforderlich.

Welche Rolle spielt Smithery bei MCP?

Smithery ist eine gehostete Plattform zum Suchen, Vergleichen und Einbinden von MCP-Servern. Sie kann den Installations- und Konfigurationsaufwand in Entwicklungs- und Testumgebungen reduzieren. Unternehmen müssen dennoch den einzelnen Server, seine Herkunft und das Betriebsmodell bewerten. Zusätzlich ist zu prüfen, welche Daten und Zugangsinformationen über gehostete Komponenten verarbeitet werden.

Wofür eignet sich PulseMCP?

PulseMCP eignet sich für eine breit angelegte Marktübersicht, die Beobachtung neuer Server und die Recherche nach Clients, Werkzeugen und Anwendungsfällen. Wegen des großen Umfangs sollte ein Treffer nicht unmittelbar installiert werden. Das Verzeichnis ist vor allem ein Ausgangspunkt für Longlists, denen anschließend eine technische, rechtliche und fachliche Prüfung folgt.

Ist OpenRouter eine MCP-Plattform?

OpenRouter ist kein MCP-Verzeichnis. Die Plattform bündelt den Zugang zu Sprachmodellen verschiedener Anbieter und übernimmt auf Wunsch Modell- und Provider-Routing. In einer Agentenarchitektur kann OpenRouter die Modellschicht bereitstellen, während MCP-Server Werkzeuge und Unternehmensdaten anbinden. Beide Komponenten erfüllen unterschiedliche Aufgaben und benötigen getrennte Freigaben.

Können MCP-Server lokal betrieben werden?

Viele MCP-Server lassen sich lokal als Prozess oder Container betreiben. Das kann bei sensiblen Daten und internen Systemen Vorteile bieten, beseitigt aber nicht alle Risiken. Auch lokale Server benötigen eingeschränkte Berechtigungen, eine kontrollierte Paketquelle, sichere Zugangsdaten und Protokollierung. Zudem muss geprüft werden, welche externen Dienste der Server selbst aufruft.

Welche MCP-Server eignen sich als erster Pilot?

Als erster Pilot eignen sich begrenzte, überwiegend lesende Anwendungsfälle. Beispiele sind die Suche in freigegebenen Dokumenten, der Abruf eines Projektstatus oder die Recherche in einer internen Wissensbasis. Prozesse mit Zahlungen, Löschvorgängen, Personalentscheidungen oder weitreichenden Schreibrechten sollten erst nach ausreichender Erfahrung und mit zusätzlichen Freigabemechanismen umgesetzt werden.

Wie verhindert ein Unternehmen Schatten-MCP?

Ein Unternehmen benötigt eine verbindliche Regelung für Installation, Freigabe und Betrieb von MCP-Servern. Hilfreich sind ein interner Katalog zugelassener Server, zentrale Secret-Verwaltung, technische Allowlisting-Regeln und regelmäßige Überprüfungen. Entwicklungs- und Fachbereiche sollten zugleich einen praktikablen Weg erhalten, neue Server für einen begrenzten Pilotbetrieb prüfen zu lassen.