# OpenConnector: il gateway open source che collega gli agenti AI a più di mille software

_Oltre 11.000 azioni già pronte, credenziali custodite in un punto solo e licenza Apache 2.0. Cos'è il progetto di OOMOL Lab, come funziona e quando conviene a chi costruisce agenti._

Fonte: https://andreapirazzini.it/blog/openconnector-connettere-saas-agenti-ai · Andrea Pirazzini · 21 luglio 2026

## In breve

- OpenConnector è un gateway open source di OOMOL Lab, con licenza Apache 2.0: fa da ponte tra gli agenti AI e i software in cloud che l'azienda usa già.
- Il catalogo conta 1.127 servizi e 11.017 azioni pronte all'uso, da Gmail e GitHub fino a BigQuery e Airtable.
- Le chiavi d'accesso restano dentro il gateway: l'agente riceve i risultati e un'etichetta dell'account, mai le credenziali.
- Si installa sui propri server con Docker o Node, su Fly.io o su Cloudflare Workers, oppure si usa la versione gestita da OOMOL.

## Perché se ne parla

Un agente AI che sa solo chiacchierare serve a poco. Diventa utile quando può _fare_ le cose: leggere la posta, aprire una scheda nel CRM, aggiornare una tabella, pubblicare una modifica su GitHub. Per riuscirci deve entrare nei software che l'azienda usa ogni giorno, e ognuno di quei software ha la sua porta, la sua chiave e le sue regole.

OpenConnector nasce proprio per questo. È un progetto open source di **OOMOL Lab**, rilasciato con licenza **Apache 2.0**, che si mette in mezzo tra l'agente e i servizi in cloud: una specie di portineria che custodisce tutte le chiavi e apre la porta giusta quando l'agente la chiede. Il catalogo, al momento dell'annuncio, contava **1.127 servizi** e **11.017 azioni già pronte**.

Il progetto si presenta apertamente come alternativa a **Composio**, un servizio già noto a chi sviluppa agenti. La prima versione è uscita il 29 giugno 2026; la release 1.3.0, del 17 luglio 2026, ha reso stabile il kit di sviluppo.

- **1.127** servizi nel catalogo (da Gmail e GitHub a BigQuery)
- **11.017** azioni già pronte da far usare agli agenti
- **3.041** stelle su GitHub (e 231 fork al giorno dell'annuncio)
- **4** modi di installarlo (dal proprio server al servizio gestito)

_Fonte: OOMOL Lab, repository GitHub, luglio 2026_

## La scheda del progetto

| Voce | Dato |
| --- | --- |
| Chi lo sviluppa | OOMOL Lab |
| Repository | oomol-lab/open-connector su GitHub |
| Linguaggio | TypeScript |
| Licenza | Apache 2.0 |
| Servizi nel catalogo | 1.127 |
| Azioni pronte | 11.017 |
| Stelle su GitHub | 3.041 |
| Fork | 231 |
| Prima versione | 29 giugno 2026 |
| Ultima versione | 1.3.0, del 17 luglio 2026 |
| Si propone come alternativa a | Composio |

> **Nota:** Stelle e fork sono una fotografia del giorno dell'annuncio. Per un progetto nato da tre settimane sono numeri che dicono interesse, non ancora maturità.

## Il problema: ogni software ha la sua serratura

Prendete un agente che deve preparare un riepilogo settimanale: legge le email in Gmail, controlla le attività su Notion, recupera i numeri da BigQuery e manda il risultato su Slack. Sono quattro servizi, e ognuno chiede di essere trattato in modo diverso.

### Senza un gateway

Chi costruisce l'agente deve occuparsi di tutto da sé, servizio per servizio:

- ottenere e conservare le credenziali;
- gestire l'**OAuth**, cioè la schermata "Consenti a questa app di accedere al tuo account" che conoscete da quando usate "Accedi con Google";
- rinnovare i _refresh token_, i permessi a scadenza che vanno aggiornati periodicamente perché l'accesso non si interrompa;
- chiamare direttamente le API di ciascun fornitore, ognuna con il suo formato.

Moltiplicate per ogni servizio e per ogni agente, e il lavoro di "idraulica" supera quello sull'agente vero e proprio. Peggio ancora, le chiavi finiscono sparse in troppi posti.

### Con OpenConnector

Il gateway raccoglie tutto in un unico strato. In concreto offre cinque cose:

1. **Un catalogo di servizi**: più di 1.100, tra cui Salesforce, Gmail, Supabase, GitHub, Airtable, Slack, Notion e BigQuery.
2. **La gestione delle credenziali** per ogni tipo di accesso: chiavi API, OAuth2, credenziali personalizzate e anche servizi che non richiedono autenticazione.
3. **Contratti delle azioni leggibili**: per ogni azione si può vedere cosa riceve, cosa restituisce, quali permessi servono e il codice dell'esecutore, che si carica solo quando serve.
4. **Controlli mentre l'agente lavora**: identità della connessione, ambiti di accesso, token temporanei, regole che permettono o bloccano singole azioni, file di appoggio e registri delle esecuzioni con i dati sensibili oscurati.
5. **Diverse opzioni di installazione**, dal computer dello sviluppatore fino al servizio gestito (le vediamo più sotto).

Un'**azione**, per capirci, è un'operazione già scritta e collaudata: "crea una pagina", "cerca tra le email", "aggiungi una riga alla tabella". L'agente non deve sapere come parlare con Notion o con Airtable: chiede l'azione e il gateway la esegue.

## Come funziona, passo per passo

L'architettura è a strati, e il percorso di una richiesta è lineare:

1. L'agente, o l'applicazione che lo contiene, chiama il gateway attraverso una delle sue interfacce (kit di sviluppo, riga di comando, MCP o HTTP).
2. Il gateway verifica l'autenticazione e, se serve, gestisce il passaggio OAuth con il servizio esterno.
3. Consulta il catalogo per sapere come si esegue l'azione richiesta.
4. La esegue tramite gli esecutori, anch'essi open source.
5. Applica le regole su token, ambiti e liste di azioni consentite o bloccate.
6. Restituisce il risultato e scrive un registro dell'esecuzione.

Il punto più importante per un'azienda è un altro: **i segreti dei fornitori non attraversano mai il confine del gateway**. L'agente riceve solo metadati, un'etichetta sicura che identifica l'account e l'esito dell'operazione. La password di Gmail o la chiave di Salesforce restano chiuse dentro.

> **Consiglio:** È la stessa logica che si usa con le persone: il nuovo collaboratore non riceve le password di tutti i sistemi, ma un accesso limitato a ciò che gli serve. Con un gateway del genere si può applicare lo stesso principio agli agenti, e decidere azione per azione cosa possono fare.

OOMOL mostra anche una **console web di amministrazione**, da cui si gestiscono connessioni e regole senza passare dal codice.

![Schermata della console di OpenConnector: a sinistra il menu con servizi, azioni, esecuzioni e chiave API; al centro lo stato del runtime, i contatori di servizi, azioni ed errori recenti, il grafico delle chiamate agli strumenti e le ultime chiamate](https://xfzvzyxtnexwldhdjrdj.supabase.co/storage/v1/object/public/blog-media/posts/ae396f3d-9c47-48bc-b897-ac0f756cf71a/8ae68c2b-7e45-4452-8eb1-abcfd4958f5f.webp)
*La console di amministrazione in esecuzione locale: in una sola pagina si vede quali servizi sono collegati, quante azioni sono pronte e come sono andate le ultime esecuzioni. Immagine: OOMOL Lab.*

## Quattro modi per collegarlo

OpenConnector si aggancia a quasi qualsiasi progetto perché offre quattro interfacce diverse. La scelta dipende da come è costruito l'agente.

| Interfaccia | A cosa serve |
| --- | --- |
| Connector SDK | Libreria TypeScript che parla con il gateway via HTTP. La classe OpenConnector serve per i runtime installati in proprio; Connector e ProjectConnector per le connessioni ospitate da OOMOL. |
| oo CLI | Un ponte locale per gli agenti, da riga di comando: il comando oo connector cerca, esamina ed esegue le azioni, sia sul servizio OOMOL sia su un'installazione propria. |
| MCP | Rende disponibili le azioni a qualunque programma compatibile con il Model Context Protocol, all'indirizzo locale http://localhost:3000/mcp. |
| HTTP e OpenAPI | Chiamate dirette agli indirizzi /v1/actions/*, oppure lettura del documento /openapi.json generato in automatico. |

L'**MCP** merita due parole: è lo standard, ormai adottato da molti strumenti, con cui un assistente AI scopre quali "attrezzi" ha a disposizione e li usa. Grazie a questa interfaccia, programmi come Claude Code o Cursor possono chiamare le azioni del catalogo senza integrazioni scritte apposta.

## Dove installarlo: quattro strade

| Opzione | Adatta a | Cosa comprende |
| --- | --- | --- |
| Installazione propria, open source | Chi vuole il controllo completo | Docker in locale o Node, database SQLite, MCP, HTTP, OpenAPI e console web |
| Fly.io, gestita in proprio | Chi vuole un runtime Docker in hosting | Node in Docker, SQLite su un volume Fly, TLS e controlli di salute del servizio |
| Cloudflare Workers | Chi vuole un runtime ospitato e leggero | Workers, stato su D1, file di passaggio su R2, console servita come Static Assets |
| OOMOL hosted | Chi è fermo in attesa delle approvazioni OAuth o ha scadenze strette | Autenticazione e runtime gestiti da OOMOL, con gli stessi servizi e contratti delle azioni |

L'ultima riga tocca un problema concreto. Per usare l'OAuth di molti servizi bisogna registrare la propria applicazione e, spesso, aspettare che il fornitore la approvi. Con la versione ospitata da OOMOL si parte subito usando le loro autorizzazioni, e in un secondo momento si può passare a un'installazione propria senza riscrivere le integrazioni.

## Per chi è pensato

Gli sviluppatori del progetto indicano tre situazioni tipiche:

- **prodotti basati su agenti** che hanno bisogno di un accesso riutilizzabile a strumenti di lavoro, piattaforme di sviluppo, sistemi di dati e servizi AI;
- **prodotti esistenti che aggiungono funzioni agentiche** e vogliono contratti stabili e controllabili per entrare nelle applicazioni dei propri utenti;
- **team che vogliono partire in fretta** con l'autenticazione ospitata, tenendosi la possibilità di spostarsi su un runtime proprio.

## Cosa porta la versione 1.3.0

La release del 17 luglio 2026 aggiunge tre cose:

- il **Connector SDK** dichiarato stabile;
- il supporto a **Cloudflare Workers**, con D1 per lo stato e R2 per i file;
- la **console web** per gestire connessioni e regole.

Per chi vuole provare la strada Cloudflare, il team ha pubblicato su YouTube un tutorial di avvio rapido che mostra la configurazione in pochi minuti.

[Video: Il tutorial ufficiale di OOMOL: OpenConnector installato su Cloudflare Workers, con D1, R2 e la console web.](https://www.youtube.com/watch?v=R0V1ZdCuTgc)

Attorno a OpenConnector, OOMOL Lab mantiene anche la **oo CLI** e il **Connector SDK** come progetti a sé, più la piattaforma ospitata su oomol.com, che fornisce runtime e autenticazione gestiti.

## Cosa significa per un'azienda

Se in azienda qualcuno sta costruendo agenti (un fornitore, un reparto interno, un consulente), OpenConnector cambia i conti su tre fronti.

- **Tempo di sviluppo.** Con 11.017 azioni già pronte, anche un progetto che deve toccare solo cinque o sei software risparmia subito il lavoro più noioso: autenticazioni, rinnovi, formati delle API.
- **Libertà commerciale.** La licenza Apache 2.0 permette di usarlo, modificarlo e inserirlo in prodotti a pagamento senza vincoli.
- **Controllo su dati e chiavi.** Con l'installazione propria, credenziali e registri restano sui vostri server o sul vostro account cloud.

In più, grazie a MCP, al kit TypeScript e alla riga di comando, si inserisce nella maggior parte degli stack moderni: dagli agenti che lavorano con Claude Code, Codex o Cursor fino alle piattaforme costruite su misura. Se volete capire meglio cosa può fare un agente in pratica, trovate esempi concreti nella guida su [cosa sono gli agenti AI](https://andreapirazzini.it/guide/agenti-ai-cosa-sono-esempi).

*Animazione: Un gateway come OpenConnector fa questo lavoro per gli agenti: sposta dati e comandi tra i software, con le chiavi custodite in un punto solo.*

## OpenConnector o Composio?

OpenConnector si propone come alternativa completa e interamente open source a Composio. Le differenze dichiarate sono due:

- **la licenza**: OpenConnector è tutto Apache 2.0, mentre Composio include componenti a codice chiuso;
- **l'ecosistema**: attorno a OpenConnector ci sono il kit di sviluppo, la riga di comando e la piattaforma ospitata di OOMOL, tutte opzioni in più e non obblighi.

Un confronto su prestazioni, affidabilità e qualità dei singoli connettori, però, non fa parte dell'annuncio: chi deve scegliere tra i due farà bene a provarli entrambi sui servizi che gli interessano davvero.

## Cosa resta da capire

> **Attenzione:** Il progetto è giovane e alcune domande, al momento dell'annuncio, non hanno ancora risposta:
> 
> - come si comporta il gateway installato in proprio quando deve reggere molte richieste contemporanee e va distribuito su più macchine;
> - quanto è buona la documentazione per i servizi meno diffusi del catalogo;
> - ogni quanto verrà aggiornato il catalogo e quanto in fretta il team risponderà alle richieste di nuovi connettori;
> - se il ritmo di rilascio resterà così alto anche dopo la fase di lancio.

## Il mio parere

Tra i progetti open source usciti quest'anno per chi costruisce agenti, OpenConnector è uno dei più pratici. Mi piace soprattutto che non inventi un protocollo nuovo: si appoggia a quello che c'è già (MCP, OpenAPI, TypeScript) e si concentra su un problema noioso ma reale, cioè far entrare un agente nei software aziendali senza spargere password ovunque.

Per chi sviluppa agenti per clienti business, valutarlo come strato di integrazione può voler dire risparmiare settimane di lavoro su OAuth e API. La cautela è quella di ogni progetto con tre settimane di vita: prima di affidargli dati importanti proverei i connettori che servono davvero, controllerei i registri e le regole di blocco, e partirei con permessi stretti.

Se state pensando di collegare un agente ai vostri gestionali e volete capire da dove partire e con quali regole, è il tipo di lavoro che faccio nei progetti di [automazione e integrazione](https://andreapirazzini.it/servizi/automazioni).

[Prenota una call](https://andreapirazzini.it/prenota)

## Domande frequenti

**OpenConnector è gratuito?**

Il codice sì: è open source con licenza Apache 2.0 e l'installazione sui propri server non costa nulla. La piattaforma ospitata da OOMOL prevede piani a pagamento, i cui dettagli non erano ancora pubblici al momento dell'annuncio.

**Quali servizi supporta?**

Al lancio erano 1.127, tra cui Gmail, Notion, GitHub, Slack, Airtable, Supabase, BigQuery e Google Analytics. L'elenco completo si consulta all'indirizzo connector.oomol.com/v1/catalog.

**Si può installare su un computer o un server proprio?**

Sì, con Docker oppure direttamente con Node.js. Il repository contiene le guide per l'installazione in locale, su Fly.io e su Cloudflare Workers.

**Funziona con Claude Code o Cursor?**

Sì, attraverso l'interfaccia MCP esposta su localhost:3000/mcp. Qualsiasi agente compatibile con MCP può chiamare le azioni del catalogo.

**In cosa si distingue da Composio?**

Soprattutto nella licenza: OpenConnector è interamente Apache 2.0, mentre Composio ha parti a codice chiuso. In più OOMOL affianca un kit di sviluppo, una riga di comando e una piattaforma ospitata, da usare solo se servono.