osFoundry / Platform
Connettori
Un catalogo di tutte le integrazioni supportate dalla piattaforma — first-party e community.
Che cos’è
Connettori è l'unico catalogo di osFoundry con tutte le integrazioni che l'area di lavoro può raggiungere, e comprende due tipi di cose: i connettori API (un'API HTTP esterna dietro OAuth, chiave API, bearer o autenticazione basic) e i server MCP (strumenti del Model Context Protocol che girano in locale sul tuo dispositivo o sono ospitati su HTTP). Invece di disperdere le integrazioni su pagine di impostazioni separate, la schermata di esplorazione raggruppa tutto per categoria: fornitori di IA, produttività, comunicazione, strumenti per sviluppatori, storage, social e MCP, con una ricerca in tempo reale su nomi, descrizioni e tag, così trovi una capacità nel modo in cui la cercheresti davvero.
Dentro osFoundry il catalogo non è un elenco statico. Il pannello Scopri interroga il MCP Registry ufficiale dall'interno dell'app, così "cosa potrei aggiungere" sta proprio accanto a "cosa ho già". Puoi digitare una query o incollare l'URL di un repository GitHub, e osFoundry lo risolve in un server strutturato e installabile (comando, argomenti e variabili d'ambiente necessarie), anziché tirare a indovinare da un README. Poiché la pubblicazione nel registro non richiede autorizzazioni, ogni risultato mostra la propria provenienza: un badge di namespace verificato ti dice che l'editore ha dimostrato chi è (OAuth GitHub per i namespace io.github.*, oppure prova DNS/HTTP per un dominio), ed è esattamente il segnale che ti serve per distinguere un server legittimo da un typosquat prima di installarlo. Le schede indicano se un server gira sul tuo dispositivo (stdio) o è ospitato (HTTP), e se è già stato aggiunto.
Questo conta perché osFoundry è BYOK e local-first. Colleghi i tuoi account con le tue credenziali, senza ricarico da rivenditore, e i segreti vivono nel portachiavi del sistema operativo, mai dentro la definizione del connettore né nel contesto inviato a un modello. Una volta pronto un connettore, agenti e app dell'area di lavoro lo usano tramite un proxy controllato dall'amministratore e verificabile: le app girano senza accesso diretto alla rete e chiamano connector.call(), così ogni richiesta in uscita viene verificata rispetto al manifest dell'app e registrata. Il rilevamento degli aggiornamenti segnala quando un server del registro già installato ha una versione più recente, e non riesegue mai codice nuovo in silenzio: un comando o un URL di server modificato richiede lo stesso consenso esplicito della prima installazione.
Funzionalità principali
- Esplora tutte le integrazioni in un unico catalogo: connettori API e server MCP, raggruppati per categoria (fornitori di IA, produttività, comunicazione, strumenti di sviluppo, storage e altro) con ricerca su nomi, descrizioni e tag
- Scopri i server della community dal MCP Registry ufficiale (registry.modelcontextprotocol.io) direttamente nell'app, oppure incolla l'URL di un repository GitHub per risolverlo in un server installabile
- Vedi chi ha pubblicato un server prima di installarlo: un badge di verifica segna i namespace verificati nel registro (OAuth GitHub o prova DNS/HTTP) e distingue i server propri dalle voci della community senza autorizzazione
- Installa server locali (stdio sul dispositivo) che girano come processo figlio sulla tua macchina, oppure server ospitati (HTTP) mediati dalla piattaforma: le credenziali restano nel portachiavi del sistema, mai nella definizione del connettore
- Collega i tuoi account con le tue chiavi (OAuth, chiave API, bearer o basic), senza ricarico da rivenditore, e lascia che agenti e app chiamino quegli strumenti tramite un proxy di connettori controllato dall'amministratore e verificabile
Casi d’uso
- Amministratore dell'area di lavoro: configura una volta un connettore API per Twitter/X o Salesforce (URL base, scope OAuth) così che ogni app e agente dell'area possa chiamarlo tramite il proxy senza che ciascun utente colleghi le credenziali
- Sviluppatore o utente esperto: incolla l'URL GitHub di un server MCP, vede che è un namespace io.github verificato, lo installa come server stdio locale e ne chiama subito gli strumenti dalla chat
- Team attento alla privacy: tiene le chiavi API nel portachiavi del sistema ed esegue server MCP locali sul dispositivo, così dati e credenziali non lasciano mai la macchina, pur continuando a esplorare le integrazioni della community in un unico catalogo
Domande frequenti
Qui qual è la differenza tra un connettore API e un server MCP?
Un connettore API avvolge una specifica API HTTP esterna dietro un metodo di autenticazione (OAuth, chiave API, bearer o basic) e di solito viene creato una volta da un amministratore dell'area di lavoro, poi chiamato da app e agenti tramite il proxy dei connettori. Un server MCP espone strumenti tramite il Model Context Protocol: gira in locale come processo figlio sul tuo dispositivo (stdio) oppure viene raggiunto via HTTP (ospitato). Entrambi compaiono nello stesso catalogo, etichettati come API o MCP, così li esplori insieme.
Da dove arrivano i connettori della community e sono sicuri?
Il pannello Scopri interroga il MCP Registry ufficiale (registry.modelcontextprotocol.io), dove chiunque può pubblicare. osFoundry mostra un badge di verifica quando il namespace dell'editore è verificato: OAuth GitHub per i nomi io.github.* o prova DNS/HTTP per un dominio. Questo dimostra chi ha pubblicato un server, non che il suo codice sia sicuro, quindi ci si aspetta che tu controlli l'editore prima di installare. I server locali girano sulla tua macchina e le variabili d'ambiente richieste vengono mostrate in anticipo.
Dove sono conservate le mie credenziali?
I segreti non vengono mai tenuti nella definizione del connettore né inviati al modello: il catalogo porta solo i nomi di variabili e header, non i loro valori. Per i server MCP locali le credenziali vivono nel portachiavi del sistema operativo. Le credenziali dei connettori API vengono decifrate solo lato server per costruire gli header di autenticazione quando il proxy effettua una richiesta per conto di un'app, e quella richiesta viene verificata rispetto al manifest dell'app ed è verificabile. Questo è coerente col fatto che osFoundry è BYOK e local-first.