Eigenen MCP-Server hinzufügen
Einen beliebigen entfernten MCP-Server verbinden, damit seine Werkzeuge im Chat, in Code und in Cowork bereitstehen
Ü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.
Sie brauchen die Berechtigungen MCP-Server nutzen und MCP-Server anlegen. Sehen Sie unter Integrationen kein MCP-Server erstellen, enthält Ihre Rolle diese Berechtigungen nicht. Wenden Sie sich dann an die Administration.
Hinzufügen
Öffnen Sie Integrationen: im Browser unter Einstellungen, in der Desktop-App mit
Cmd/Strg+Shift+E.
Der Dialog MCP-Server hinzufügen listet fertige Server. Finden Sie einen über MCP-Server suchen… oder grenzen Sie die Liste mit Filter ein. Dokumentation öffnet die Dokumentation des Anbieters. Steht Ihr Server nicht in der Liste, wählen Sie unten Eigenen Server hinzufügen.
Bei einem eigenen Server tragen Sie einen Namen, die Server-URL und bei Bedarf eine Beschreibung (optional) ein. Den Namen sehen Sie und Ihre Kolleginnen und Kollegen in der Liste. Benennen Sie den Server also nach dem Dienst und nicht nach dem Protokoll.
Speichern Sie. Der Server wird kontaktiert, und seine Werkzeuge erscheinen auf seiner Detailseite.
Authentifizierung
| Verfahren | Wann es passt |
|---|---|
| OAuth (automatisch, empfohlen für bekannte Server) | Der Server unterstützt OAuth. Jede Person meldet sich selbst an, mit eigenen Berechtigungen |
| API-Schlüssel (eigener Header oder Query-Parameter) | Der Server erwartet einen Schlüssel in einem Header oder Query-Parameter |
| Bearer-Token (Authorization-Header) | Der Server erwartet ein festes Token im Authorization-Header |
| Keine: öffentlicher oder lokaler Server | Ein öffentlicher Server ohne Zugangsdaten |
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.
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 und wird in der Desktop-App eingerichtet, nicht hier. 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:
| Was Sie teilen | Was die Empfänger bekommen | Wo |
|---|---|---|
| Den Server (Definition) | Er erscheint in ihrer Liste, und sie verbinden ihn mit eigenen Zugangsdaten | Das Menü an der Integration in der Übersicht |
| Die Zugangsdaten (API-Schlüssel) | Sie nutzen Ihren Schlüssel, ohne ihn je zu sehen | Das Menü auf der Detailseite der Integration |
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.
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.
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.
Ein MCP-Server ist Code, den jemand anderes betreibt, und seine Werkzeuge können in Ihrem Namen handeln. Fügen Sie nur Server hinzu, denen Sie vertrauen, und nehmen Sie vorzugsweise OAuth, damit er mit Ihren eigenen Berechtigungen handelt statt mit einem geteilten Schlüssel.
Was Administratoren steuern
Administratoren können MCP-Server unter Organisation → 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: Der Server hat seine Werkzeugliste geändert. Öffnen Sie die Detailseite der Integration, um sie neu zu laden.
- 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.
- 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.netoder 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.