Hai un software as a service che funziona, clienti che lo usano ogni giorno e una roadmap già piena. Intanto quei clienti iniziano a lavorare con assistenti come ChatGPT, Claude, Copilot o Cursor e ti chiedono: "Posso fare questa cosa nel vostro software direttamente dall'AI?". Un server MCP per il tuo SaaS è il modo più diretto per rispondere di sì, senza riscrivere il prodotto.

In questo articolo vediamo cos'è il Model Context Protocol, cosa cambia per un SaaS che lo adotta, quali funzioni conviene esporre per prime e quali errori evitare.

Cos'è MCP, in poche parole

MCP (Model Context Protocol) è un protocollo aperto che definisce come un'applicazione AI si collega a strumenti, dati e software esterni. Lo ha presentato Anthropic e a dicembre 2025 è stato donato all'Agentic AI Foundation, un fondo della Linux Foundation creato insieme a Block e OpenAI e sostenuto, tra gli altri, da Google, Microsoft, AWS e Cloudflare.

Secondo l'annuncio della Linux Foundation, all'epoca esistevano oltre 10.000 server MCP pubblicati e il protocollo era supportato da Claude, ChatGPT, Gemini, Microsoft Copilot, Cursor e VS Code. In pratica è diventato il modo standard con cui un agente AI "vede" e usa un software.

Un server MCP espone al modello tre tipi di elementi:

  • Tool: azioni che l'agente può eseguire, per esempio "crea un preventivo" o "cerca un ordine".
  • Resource: dati che l'agente può leggere come contesto, come un documento o una scheda cliente.
  • Prompt: istruzioni predefinite che guidano l'utente nei flussi più comuni.

Se vuoi capire meglio come un agente decide quale strumento usare, trovi le basi nel nostro articolo su agenti, LLM e harness.

Perché un server MCP per il tuo SaaS conta già oggi

Finora l'integrazione di un SaaS passava da due strade: un'interfaccia web usata da persone e un'API REST usata da sviluppatori. MCP aggiunge un terzo canale: l'agente AI che lavora per conto dell'utente.

Questo cambia alcune cose concrete:

  • Il tuo prodotto entra nel flusso di lavoro dell'utente, anche quando l'utente non apre la tua interfaccia. Se il cliente organizza la giornata dentro un assistente AI, il tuo software diventa uno degli strumenti che quell'assistente può usare.
  • Un solo connettore, molti client. Invece di costruire un plugin diverso per ogni piattaforma AI, sviluppi un server che segue lo standard e funziona con tutti i client compatibili.
  • Operazioni a più passaggi diventano una richiesta. "Prendi gli ordini aperti di questo cliente, verifica le scadenze e preparami una bozza di sollecito" coinvolge più funzioni del tuo SaaS: l'agente le combina al posto dell'utente.
  • Un criterio di scelta in più per chi compra. Le aziende che stanno adottando agenti AI iniziano a chiedersi quali software si integrano con i loro assistenti. Un SaaS che non lo fa rischia di sembrare chiuso.

MCP non sostituisce la tua API

Un dubbio frequente: "Abbiamo già un'API pubblica, non basta?". L'API resta la base, ma è pensata per un programmatore che legge la documentazione e scrive codice. Un agente AI ragiona diversamente: ha bisogno di strumenti descritti in linguaggio chiaro, con parametri comprensibili e risposte sintetiche.

Nella maggior parte dei casi il server MCP è uno strato sottile sopra le API esistenti. Non duplica la logica di business: la traduce in azioni che un modello può scegliere e usare correttamente. Per questo, se le tue API sono ordinate e documentate, il lavoro è più contenuto. Se invece la logica è sparsa tra interfaccia e database, MCP diventa l'occasione per rimettere ordine, un tema che conosce bene chi si occupa di system integration.

Vuoi rendere il tuo SaaS utilizzabile dagli agenti AI? Partiamo dalle due o tre azioni che i tuoi clienti chiedono più spesso e le rendiamo disponibili in un server MCP da provare. Parliamone

Quali funzioni esporre per prime

L'errore più comune è trasformare ogni endpoint in un tool. Un agente con cento strumenti simili sbaglia più spesso, consuma più contesto e restituisce risultati meno affidabili. Conviene partire in piccolo, con criteri chiari:

  1. Le richieste ricorrenti dei clienti. Guarda i ticket di assistenza e le domande al customer success: spesso emergono tre o quattro operazioni che gli utenti fanno sempre.
  2. Le letture prima delle scritture. Cercare, filtrare e riassumere dati ha un rischio basso e un valore immediato. Le azioni che modificano dati arrivano dopo.
  3. Le operazioni che attraversano più schermate. Se oggi un'attività richiede di aprire tre pagine e copiare dati da una all'altra, è un buon candidato.
  4. Strumenti con un'intenzione precisa. Meglio "riepilogo_fatture_scadute_cliente" che un generico "query_fatture" con venti parametri.

Per ogni tool cura il nome, la descrizione e i parametri come cureresti un'interfaccia: è letteralmente l'interfaccia che il modello legge.

Sicurezza, permessi e controllo

Aprire il tuo software a un agente significa permettere a un sistema automatico di agire per conto di un utente. È qui che si gioca la qualità dell'integrazione.

  • Autenticazione per utente. Per i server remoti la specifica MCP prevede un flusso di autorizzazione basato su OAuth: l'agente opera con le credenziali e i permessi di quel singolo utente, non con una chiave condivisa.
  • Permessi coerenti con il prodotto. Se un utente non può cancellare un cliente dall'interfaccia, non deve poterlo fare nemmeno tramite agente.
  • Conferma sulle azioni irreversibili. Invii, pagamenti e cancellazioni dovrebbero richiedere un passaggio esplicito di conferma o restare fuori dalla prima versione.
  • Log e limiti d'uso. Registra quali strumenti vengono chiamati, da chi e con quali parametri. Imposta limiti per evitare chiamate a raffica.
  • Attenzione ai contenuti non affidabili. Testi inseriti da terzi (email, note, commenti) possono contenere istruzioni che cercano di manipolare l'agente. Le azioni sensibili non devono dipendere solo da ciò che il modello ha letto.

Anche gli aspetti di privacy vanno valutati: quali dati escono dal tuo sistema verso il fornitore del modello e con quale base giuridica.

Errori comuni da evitare

  • Partire dalla tecnologia invece che dall'uso. "Facciamo MCP perché lo fanno tutti" porta a server che nessuno usa. Parti da cosa i clienti vogliono ottenere.
  • Risposte troppo lunghe. Restituire oggetti JSON completi con decine di campi riempie il contesto del modello. Restituisci solo ciò che serve alla decisione successiva.
  • Nessun test con agenti veri. Un tool può funzionare perfettamente via API e venire usato male da un modello perché la descrizione è ambigua. Va provato con i client che usano i tuoi clienti.
  • Dimenticare la manutenzione. Il protocollo evolve e i client aggiornano spesso il loro supporto. Il server va trattato come parte del prodotto, con versioni e monitoraggio.

Come lo affrontiamo in Mine Consulting

Quando lavoriamo su un SaaS esistente partiamo da un obiettivo condiviso: quali attività dei tuoi clienti vogliamo rendere possibili tramite agente e come capiremo se funzionano. Di solito sono poche, e sono quelle che emergono dall'assistenza e dalle richieste commerciali.

Poi costruiamo un primo risultato da provare: un server MCP con un insieme ridotto di strumenti, sopra le API che hai già, con autenticazione per utente e log. Lo testiamo con i client AI più usati dai tuoi clienti e correggiamo nomi, descrizioni e risposte in base a come il modello li usa davvero.

Da lì il percorso continua: nuovi strumenti, azioni in scrittura con conferma, eventuali interventi sulle API dove servono. È lo stesso approccio con cui facciamo evolvere piattaforme già in produzione, come nel progetto SOALM. Per lo sviluppo usiamo la metodologia Spec-Driven Development, che ci aiuta a definire in modo preciso cosa deve fare ogni strumento prima di scriverlo.

In sintesi

  • MCP è lo standard aperto con cui gli agenti AI si collegano ai software, oggi gestito da una fondazione della Linux Foundation e supportato dai principali assistenti.
  • Un server MCP per il tuo SaaS aggiunge un canale nuovo: l'agente che lavora per conto dell'utente.
  • Di solito è uno strato sopra le API esistenti, non una riscrittura del prodotto.
  • Conviene partire da poche azioni ricorrenti, privilegiando letture e strumenti con un'intenzione precisa.
  • Sicurezza e permessi vanno progettati fin dall'inizio: autenticazione per utente, conferme sulle azioni irreversibili, log.

Se stai valutando come rendere il tuo software utilizzabile dagli agenti AI, possiamo partire insieme dai casi d'uso dei tuoi clienti. Parliamone.