Eigenen MCP-Server hinzufügen

Über die fertigen Integrationen hinaus können Sie einen eigenen entfernten MCP-Server verbinden. Seine Werkzeuge erscheinen dann wie jede andere Integration, im Chat und in den Desktop-Produkten.

Model Context Protocol ist der offene Standard, um einer KI Werkzeuge bereitzustellen. Bietet ein Dienst einen MCP-Endpunkt an, ist das der Weg, ihn anzuschließen, ohne dass vorher jemand eine Integration dafür bauen muss.

Hinzufügen

Authentifizierung

OAuth ist die Voreinstellung und meist die richtige Wahl. Es braucht nur Name und URL: Die Adresse des Autorisierungsservers wird aus der Server-URL abgeleitet, über den bekannten Pfad, den praktisch jeder MCP-Server nutzt. Jede Person, die die Integration nutzt, meldet sich selbst an. Niemand teilt Zugangsdaten, und der Zugriff folgt dem, was der Dienst ihr ohnehin erlaubt.

Beim API-Schlüssel geben Sie an, wohin der Schlüssel gehört: als Header oder als Query-Parameter, unter welchem Namen und mit welchem Präfix, wenn der Dienst eines erwartet, etwa Bearer .

Alles andere liegt in den eingeklappten Erweiterten Einstellungen: Transport, eine ausdrückliche Adresse des Autorisierungsservers, OAuth-Scopes, eigene Client-ID samt Geheimnis und Zusätzliche HTTP-Header. Zusätzliche Header werden mit jeder Anfrage gesendet, etwa ein Profil-Header, den der Anbieter verlangt. Nutzen Sie sie nur für Werte, die nicht geheim sind, denn alle, die den Server sehen, sehen auch die Header. Schlüssel und Tokens gehören in die Authentifizierung. Besteht dort ein Wert die Prüfung nicht, klappt der Abschnitt selbst auf, statt dass das Speichern wirkungslos erscheint.

Server mit Anmeldung über Microsoft Entra ID

Manche Server, etwa der Remote-MCP-Server von Azure DevOps, lassen die Anmeldung über Microsoft Entra ID laufen. Entra unterstützt keine automatische Client-Registrierung, deshalb brauchen Sie dafür eine eigene App-Registrierung in Ihrem Tenant:

Danach meldet sich jede Person beim Verbinden mit dem eigenen Microsoft-Konto an. Mit Keine als Authentifizierung lässt sich ein solcher Server nicht verbinden.

Transport

Standardmäßig wird HTTP (empfohlen) verwendet, also das moderne Streamable HTTP. Ältere Server, die nur HTTP mit Server-Sent Events sprechen, funktionieren ebenfalls: Wählen Sie dafür in den erweiterten Einstellungen Server-Sent Events. Scheitert ein Verbindungsversuch mit einem Transportfehler, probieren Sie das zuerst.

Ein Server im eigenen Netz

Die Verbindung zum MCP-Server baut unsere Infrastruktur auf, nicht das Gerät der Nutzerin oder des Nutzers. Daraus folgen zwei Dinge. Der Endpunkt muss über öffentliches HTTPS erreichbar sein, sonst wird die URL schon beim Speichern abgelehnt. Und es spielt keine Rolle, in welchem Netz die Geräte gerade sind oder ob sie das Netz wechseln: Laptops, die zwischen Büro, VPN und Mobilfunk wandern, brauchen dafür keine Konfiguration.

Für einen Server, der bisher nur intern läuft, haben sich zwei Wege bewährt:

• Reverse Proxy oder API-Gateway, das Sie ohnehin betreiben. Veröffentlichen Sie dort nur den MCP-Pfad unter einem öffentlichen DNS-Namen, terminieren Sie TLS mit einem öffentlich vertrauenswürdigen Zertifikat und legen Sie die Authentifizierung davor. Der interne Server selbst bleibt unverändert.
• Ausgehender Tunnel, etwa Cloudflare Tunnel oder ein vergleichbarer Dienst. Der Verbindungsaufbau geht von innen nach außen, Sie brauchen also keine eingehende Firewall-Regel, keine feste öffentliche IP und kein eigenes Zertifikat. Das ist meist der schnellere Weg, wenn mehrere Firewalls im Spiel sind.

Unabhängig vom Weg gilt: Veröffentlichen Sie nur den MCP-Endpunkt und nicht den ganzen Dienst, erzwingen Sie am Übergang eine Authentifizierung, und geben Sie dem MCP-Server intern nur die Rechte, die seine Werkzeuge wirklich brauchen. OAuth ist auch hier die beste Wahl, weil dann jede Person mit den eigenen Rechten arbeitet statt mit einem gemeinsamen Token.

Einen Tunnel über die Desktop-App oder ein Relay über den Windows-Client gibt es nicht, und eine Freigabe auf IP-Ebene ersetzt die Authentifizierung nicht.

Davon getrennt kann die Desktop-App MCP-Server auch lokal auf Ihrem Rechner betreiben und Code und Cowork deren Werkzeuge nutzen lassen, sofern Ihre Organisation das erlaubt. Ein solcher Server ist ein Programm auf Ihrem Gerät. Sie richten ihn in der Desktop-App unter Integrationen ein, über Hinzufügen und Lokaler MCP-Server. Dort erscheint er im Bereich Auf diesem Gerät, und nur Code und Cowork können ihn nutzen. Mehr unter Lokale MCP-Server.

Im Team teilen

Es gibt zwei unabhängige Dinge zum Teilen, und sie zu verwechseln ist die häufigste Verwirrung:

Eine häufige Kombination: Sie legen den Server an und teilen die Definition, damit das Team ihn sieht, und teilen zusätzlich den Schlüssel, damit alle die Zugangsdaten der Organisation nutzen, ohne sie lesen zu können. Beide Freigaben werden getrennt verwaltet und lassen sich jederzeit widerrufen. Zum Teilen brauchen Sie die Berechtigung Eigene MCP-Server teilen.

Nutzen

Einmal verbunden, stehen die Werkzeuge des Servers im Chat, in Code und in Cowork bereit, über denselben serverseitigen Verteiler wie jede andere Integration. In einem Workflow rufen Sie ein Werkzeug mit dem Knoten MCP-Tool als festen Schritt auf, oder Sie geben es dem KI-Agenten als Tool, der dann selbst entscheidet, wann er es nutzt. Der Workflow-Assistent kennt Ihre Server und kann beides für Sie anlegen.

Jede Aktion, die im verbundenen Dienst etwas ändert, braucht Ihre Freigabe, getrennt von Dateiänderungen. In den Desktop-Produkten lässt Verbindungen automatisch genehmigen diese Aktionen ohne Nachfrage laufen, wenn Sie nicht jede einzeln bestätigen wollen.

In einem Workflow fragt niemand nach: Dass Sie ein Werkzeug im KI-Agenten oder im Knoten MCP-Tool auswählen, ist die Freigabe. Ein Werkzeug, das die Person mit der Verbindung unter Berechtigungen auf Nie erlauben gestellt hat, hält den Workflow-Lauf mit einer Fehlermeldung an. Dasselbe gilt, wenn ihr die Berechtigung MCP-Server nutzen fehlt oder die Organisation den Server für sie abgeschaltet hat.

Auf der Detailseite des Servers lässt Lesende Werkzeuge ohne Nachfrage Werkzeuge, die der Server als nur lesend deklariert, ohne Genehmigungsanfrage laufen. Diese Angabe stammt vom Server selbst und lässt sich nicht überprüfen. Schalten Sie die Option deshalb nur für Server ein, denen Sie vertrauen.

Was Administratoren steuern

Administratoren können MCP-Server unter Organisationseinstellungen → Werkzeuge & Integrationen → Integrationen in der Kategorie MCP-Server für die ganze Organisation ein- oder ausschalten und Ausnahmen für Gruppen oder einzelne Mitglieder festlegen.

Wenn es nicht mehr geht

• Ein Werkzeug ist verschwunden oder ein neues fehlt: Der Server hat seine Werkzeugliste geändert. Neu verbinden müssen Sie nicht: Ist die gespeicherte Werkzeugliste älter als eine Stunde, lädt der Chat sie im Hintergrund neu, und die nächste Nachricht sieht die Änderung. Um sie sofort zu sehen, öffnen Sie die Detailseite der Integration und laden sie damit neu.
• Authentifizierungsfehler: Bei OAuth löschen Sie die Verbindung und verbinden neu, das startet eine frische Anmeldung. Bei einem API-Schlüssel prüfen Sie, ob er gewechselt wurde.
• Der Server ist nicht erreichbar: Er muss über öffentliches HTTPS erreichbar sein. Ein Server in einem privaten Netz ist von unserer Infrastruktur aus nicht erreichbar und wird zudem absichtlich blockiert. Das gilt auch für eine öffentliche URL, die auf eine Adresse in einem privaten Netz weiterleitet: Der Weiterleitung wird nicht gefolgt.
• Die URL wird beim Speichern abgelehnt: Der Name muss im öffentlichen DNS auflösbar sein. Ein Name, den es nur innerhalb eines VPN oder Overlay-Netzes gibt, etwa ein Tailscale-Name unter *.ts.net oder eine interne DNS-Zone, löst auf Ihren eigenen Geräten auf, von außen aber nicht. Es liegt nie an der Endung der Domain, keine Top-Level-Domain ist gesperrt. Die Fehlermeldung sagt, welcher der beiden Fälle vorliegt.