osFoundry / Platform
Connecteurs
Un catalogue de chaque intégration supportée par la plateforme — first-party et communauté.
Présentation
Connecteurs est le catalogue unique d'osFoundry regroupant toutes les intégrations que l'espace de travail peut atteindre, et il couvre deux types d'objets : les connecteurs API (une API HTTP externe derrière OAuth, clé d'API, bearer ou authentification basique) et les serveurs MCP (des outils du Model Context Protocol qui s'exécutent en local sur votre appareil ou sont hébergés en HTTP). Plutôt que d'éparpiller les intégrations sur des pages de réglages séparées, l'écran de parcours regroupe tout par catégorie : fournisseurs d'IA, productivité, communication, outils de développement, stockage, réseaux sociaux et MCP, avec une recherche en direct sur les noms, les descriptions et les tags, pour que vous trouviez une capacité comme vous la chercheriez réellement.
Au sein d'osFoundry, le catalogue n'est pas une liste figée. Le panneau Découvrir interroge le MCP Registry officiel depuis l'application, si bien que "ce que je pourrais ajouter" se trouve juste à côté de "ce que j'ai déjà". Vous pouvez saisir une requête ou coller l'URL d'un dépôt GitHub, et osFoundry la résout en un serveur structuré et installable (commande, arguments et variables d'environnement requises), au lieu de deviner à partir d'un README. Comme la publication dans le registre ne demande aucune autorisation, chaque résultat affiche sa provenance : un badge de namespace vérifié indique que l'éditeur a prouvé son identité (OAuth GitHub pour les namespaces io.github.*, ou preuve DNS/HTTP pour un domaine), et c'est exactement le signal dont vous avez besoin pour distinguer un serveur légitime d'un typosquat avant de l'installer. Les cartes indiquent si un serveur s'exécute sur votre appareil (stdio) ou est hébergé (HTTP), et s'il est déjà ajouté.
Cela compte parce qu'osFoundry est BYOK et local-first. Vous connectez vos propres comptes avec vos propres identifiants, sans marge de revente, et les secrets vivent dans le trousseau du système d'exploitation, jamais dans la définition du connecteur ni dans le contexte envoyé à un modèle. Une fois un connecteur en place, les agents et les applications de l'espace de travail l'utilisent via un proxy auditable et contrôlé par l'administrateur : les applications s'exécutent sans accès réseau direct et appellent connector.call(), de sorte que chaque requête sortante est vérifiée par rapport au manifeste de l'application et journalisée. La détection de mises à jour signale lorsqu'un serveur du registre déjà installé dispose d'une version plus récente, et ne réexécute jamais de code nouveau en silence : une commande ou une URL de serveur modifiée redemande le même consentement explicite que la première installation.
Fonctionnalités clés
- Parcourez toutes les intégrations dans un seul catalogue : connecteurs API et serveurs MCP, regroupés par catégorie (fournisseurs d'IA, productivité, communication, outils de dev, stockage et plus), avec une recherche sur les noms, descriptions et tags
- Découvrez les serveurs communautaires du MCP Registry officiel (registry.modelcontextprotocol.io) directement dans l'application, ou collez l'URL d'un dépôt GitHub pour la résoudre en un serveur installable
- Voyez qui a publié un serveur avant de l'installer : un badge de vérification marque les namespaces vérifiés dans le registre (OAuth GitHub ou preuve DNS/HTTP) et distingue l'interne des entrées communautaires sans autorisation
- Installez des serveurs locaux (stdio sur l'appareil) qui s'exécutent en processus enfant sur votre propre machine, ou des serveurs hébergés (HTTP) médiés par la plateforme : les identifiants restent dans le trousseau du système, jamais dans la définition du connecteur
- Connectez vos propres comptes avec vos propres clés (OAuth, clé d'API, bearer ou basique), sans marge de revente, et laissez agents et applications appeler ces outils via un proxy de connecteurs auditable et contrôlé par l'administrateur
Cas d’usage
- Administrateur d'espace de travail : configure une fois un connecteur API Twitter/X ou Salesforce (URL de base, scopes OAuth) pour que chaque application et agent de l'espace puisse l'appeler via le proxy, sans que chaque utilisateur câble ses identifiants
- Développeur ou utilisateur avancé : colle l'URL GitHub d'un serveur MCP, voit qu'il s'agit d'un namespace io.github vérifié, l'installe comme serveur stdio local et appelle aussitôt ses outils depuis le chat
- Équipe soucieuse de la confidentialité : garde les clés d'API dans le trousseau du système et exécute des serveurs MCP locaux sur l'appareil pour que données et identifiants ne quittent jamais la machine, tout en parcourant les intégrations communautaires dans un seul catalogue
Questions fréquentes
Quelle est la différence entre un connecteur API et un serveur MCP ici ?
Un connecteur API enveloppe une API HTTP externe précise derrière une méthode d'authentification (OAuth, clé d'API, bearer ou basique) et est généralement créé une fois par un administrateur d'espace de travail, puis appelé par les applications et les agents via le proxy de connecteurs. Un serveur MCP expose des outils via le Model Context Protocol : il s'exécute soit en local comme processus enfant sur votre appareil (stdio), soit est joint en HTTP (hébergé). Les deux apparaissent dans le même catalogue, étiquetés API ou MCP, vous les parcourez donc ensemble.
D'où viennent les connecteurs communautaires, et sont-ils sûrs ?
Le panneau Découvrir interroge le MCP Registry officiel (registry.modelcontextprotocol.io), où n'importe qui peut publier. osFoundry affiche un badge de vérification lorsque le namespace de l'éditeur est vérifié : OAuth GitHub pour les noms io.github.* ou preuve DNS/HTTP pour un domaine. Cela prouve qui a publié un serveur, pas que son code est sûr, vous êtes donc censé vérifier l'éditeur avant d'installer. Les serveurs locaux s'exécutent sur votre propre machine et leurs variables d'environnement requises sont affichées d'emblée.
Où mes identifiants sont-ils stockés ?
Les secrets ne sont jamais conservés dans la définition du connecteur ni envoyés au modèle : le catalogue ne porte que les noms des variables et des en-têtes, pas leurs valeurs. Pour les serveurs MCP locaux, les identifiants vivent dans le trousseau du système d'exploitation. Les identifiants des connecteurs API ne sont déchiffrés que côté serveur, pour construire les en-têtes d'authentification lorsque le proxy fait une requête au nom d'une application, et cette requête est vérifiée par rapport au manifeste de l'application et auditable. Cela est cohérent avec le fait qu'osFoundry est BYOK et local-first.