osFoundry / Platform
Konnektoren
Ein Katalog jeder von der Plattform unterstützten Integration – Erstanbieter und Community.
Was es ist
Connectors ist der eine Katalog von osFoundry mit allen Integrationen, die der Arbeitsbereich erreichen kann, und er umfasst zwei Arten von Dingen: API-Connectors (eine externe HTTP-API hinter OAuth, API-Key, Bearer oder Basic Auth) und MCP-Server (Werkzeuge nach dem Model Context Protocol, die entweder lokal auf deinem Gerät laufen oder über HTTP gehostet werden). Statt Integrationen über getrennte Einstellungsseiten zu verstreuen, gruppiert der Browse-Bildschirm alles nach Kategorie: KI-Anbieter, Produktivität, Kommunikation, Entwickler-Tools, Speicher, Social und MCP, mit einer Live-Suche über Namen, Beschreibungen und Tags, damit du eine Fähigkeit so findest, wie du tatsächlich danach suchen würdest.
Innerhalb von osFoundry ist der Katalog keine statische Liste. Das Discover-Panel durchsucht die offizielle MCP Registry direkt in der App, sodass "was ich hinzufügen könnte" gleich neben "was ich schon habe" steht. Du kannst eine Suchanfrage eingeben oder die URL eines GitHub-Repositorys einfügen, und osFoundry löst sie zu einem strukturierten, installierbaren Server auf (Befehl, Argumente und benötigte Umgebungsvariablen), statt aus einer README zu raten. Da die Veröffentlichung in der Registry keine Freigabe erfordert, zeigt jedes Ergebnis seine Herkunft: ein Verified-Namespace-Badge sagt dir, dass der Herausgeber nachgewiesen hat, wer er ist (GitHub-OAuth für io.github.*-Namespaces oder DNS/HTTP-Nachweis für eine Domain), und genau dieses Signal brauchst du, um einen legitimen Server vor der Installation von einem Typosquat zu unterscheiden. Karten kennzeichnen, ob ein Server auf deinem Gerät läuft (stdio) oder gehostet ist (HTTP), und ob er bereits hinzugefügt wurde.
Das ist wichtig, weil osFoundry BYOK und local-first ist. Du verbindest deine eigenen Konten mit deinen eigenen Zugangsdaten, ohne Reseller-Aufschlag, und Geheimnisse liegen im Schlüsselbund des Betriebssystems, nie in der Connector-Definition oder im Kontext, der an ein Modell geht. Sobald ein Connector eingerichtet ist, nutzen Agenten und Workspace-Apps ihn über einen admin-kontrollierten, prüfbaren Proxy: Apps laufen ohne direkten Netzwerkzugriff und rufen connector.call() auf, sodass jede ausgehende Anfrage gegen das Manifest der App geprüft und protokolliert wird. Die Update-Erkennung meldet, wenn ein installierter Registry-Server eine neuere Version hat, und führt neuen Code nie stillschweigend erneut aus: ein geänderter Befehl oder eine geänderte Server-URL verlangt dieselbe ausdrückliche Zustimmung wie die Erstinstallation.
Wichtige Funktionen
- Alle Integrationen in einem Katalog durchsuchen: API-Connectors und MCP-Server, nach Kategorie gruppiert (KI-Anbieter, Produktivität, Kommunikation, Entwickler-Tools, Speicher und mehr), mit Suche über Namen, Beschreibungen und Tags
- Community-Server aus der offiziellen MCP Registry (registry.modelcontextprotocol.io) direkt in der App entdecken oder die URL eines GitHub-Repositorys einfügen, um sie zu einem installierbaren Server aufzulösen
- Vor der Installation sehen, wer einen Server veröffentlicht hat: ein Verifizierungs-Badge markiert in der Registry verifizierte Namespaces (GitHub-OAuth oder DNS/HTTP-Nachweis) und unterscheidet Eigenes von freizügigen Community-Einträgen
- Lokale Server (stdio auf dem Gerät) installieren, die als Kindprozess auf deiner eigenen Maschine laufen, oder gehostete (HTTP) Server, die über die Plattform vermittelt werden: Zugangsdaten bleiben im OS-Schlüsselbund, nie in der Connector-Definition
- Eigene Konten mit eigenen Schlüsseln verbinden (OAuth, API-Key, Bearer oder Basic), ohne Reseller-Aufschlag, und Agenten sowie Apps diese Werkzeuge über einen admin-kontrollierten, prüfbaren Connector-Proxy aufrufen lassen
Anwendungsfälle
- Workspace-Admin: richtet einen API-Connector für Twitter/X oder Salesforce einmal ein (Basis-URL, OAuth-Scopes), damit jede App und jeder Agent im Arbeitsbereich ihn über den Proxy aufrufen kann, ohne dass jeder Nutzer Zugangsdaten verdrahtet
- Entwickler oder Power-User: fügt die GitHub-URL eines MCP-Servers ein, sieht, dass es ein verifizierter io.github-Namespace ist, installiert ihn als lokalen stdio-Server und ruft seine Werkzeuge sofort aus dem Chat auf
- Datenschutzbewusstes Team: bewahrt API-Keys im OS-Schlüsselbund auf und betreibt gerätelokale MCP-Server, damit Daten und Zugangsdaten nie die Maschine verlassen, und durchsucht Community-Integrationen trotzdem in einem Katalog
Häufig gestellte Fragen
Was ist hier der Unterschied zwischen einem API-Connector und einem MCP-Server?
Ein API-Connector kapselt eine bestimmte externe HTTP-API hinter einer Auth-Methode (OAuth, API-Key, Bearer oder Basic) und wird üblicherweise einmal von einem Workspace-Admin erstellt, danach von Apps und Agenten über den Connector-Proxy aufgerufen. Ein MCP-Server stellt Werkzeuge über das Model Context Protocol bereit: er läuft entweder lokal als Kindprozess auf deinem Gerät (stdio) oder wird über HTTP erreicht (gehostet). Beide erscheinen im selben Katalog, mit API oder MCP getaggt, sodass du sie zusammen durchsuchst.
Woher kommen die Community-Connectors, und sind sie sicher?
Das Discover-Panel durchsucht die offizielle MCP Registry (registry.modelcontextprotocol.io), in der jeder veröffentlichen kann. osFoundry zeigt ein Verifizierungs-Badge, wenn der Namespace des Herausgebers verifiziert ist: GitHub-OAuth für io.github.*-Namen oder DNS/HTTP-Nachweis für eine Domain. Das belegt, wer einen Server veröffentlicht hat, nicht dass sein Code sicher ist, du solltest den Herausgeber also vor der Installation prüfen. Lokale Server laufen auf deiner eigenen Maschine, und ihre benötigten Umgebungsvariablen werden vorab angezeigt.
Wo werden meine Zugangsdaten gespeichert?
Geheimnisse werden nie in der Connector-Definition gehalten oder an das Modell gesendet: der Katalog trägt nur Namen von Variablen und Headern, nicht deren Werte. Bei lokalen MCP-Servern liegen die Zugangsdaten im Schlüsselbund des Betriebssystems. Zugangsdaten von API-Connectors werden nur serverseitig entschlüsselt, um Auth-Header zu bauen, wenn der Proxy im Namen einer App eine Anfrage stellt, und diese Anfrage wird gegen das Manifest der App geprüft und ist protokollierbar. Das passt dazu, dass osFoundry BYOK und local-first ist.