Chiamata API diretta nel codice
Decide: Lo sviluppatore, in un flusso fisso
Ideale per: Un prodotto che parla con un servizio in un flusso prevedibile. Limite: Ogni nuovo strumento è nuovo codice da scrivere.
Il Model Context Protocol (MCP) è uno standard aperto, introdotto da Anthropic, per collegare le applicazioni AI ai sistemi dove si lavora davvero: file, database, API e software interni. Invece di scrivere un'integrazione su misura per ogni coppia di app AI e strumento, scrivi un solo server MCP per lo strumento e qualsiasi applicazione compatibile può usarlo.
La scrive Paolo Antonio Rossi (luduvigo), che con Emiliano Fulli ha fondato Gorillia Milano nel 2025. Con Gorilli costruiamo agenti AI dall'inizio del 2025 — prima con il framework ElizaOS, poi con Kommander — ed è proprio il problema che MCP standardizza.
MCP mette d'accordo host, client e server. L'hostè l'applicazione AI in cui lavori (un assistente, un IDE). Il clientè la connessione che l'host apre verso un server. Il server è il programma che espone capacità al modello. Un server può esporre tre cose: strumenti (azioni che il modello può chiamare), risorse (dati che può leggere) e prompt (modelli riutilizzabili). Il punto che cambia tutto è che è il modello a decidere quale strumento chiamare, in base alla conversazione: nessuno ha scritto un flusso fisso. La specifica e gli SDK sono su modelcontextprotocol.io.
La domanda che si fa di solito è "quali sono le opzioni migliori?". MCP non è l'unica strada per far usare strumenti esterni a un modello: ecco il confronto che uso con il team.
Decide: Lo sviluppatore, in un flusso fisso
Ideale per: Un prodotto che parla con un servizio in un flusso prevedibile. Limite: Ogni nuovo strumento è nuovo codice da scrivere.
Decide: Il modello, tra gli strumenti definiti nella tua app
Ideale per: Un agente dentro un singolo prodotto. Limite: Le definizioni degli strumenti restano legate a quell'app e a quel provider.
Decide: Il modello, tra gli strumenti che qualsiasi client MCP può caricare
Ideale per: Una capacità da riusare tra più applicazioni AI o team. Limite: Superficie d'attacco più ampia e più parti in movimento.
La mia regola pratica: se il flusso è fisso non usare un agente, chiama l'API. Se serve un agente dentro un solo prodotto basta il function calling. MCP si merita la sua complessità quando la stessa capacità va riusata tra più client, o quando vuoi che gli utenti portino i propri strumenti nella tua applicazione AI. Il confronto completo, con la tabella, è nella guida in inglese su MCP.
MCP è uno standard aperto: non è un prodotto che un'azienda "vende", ma è già supportato da molti assistenti AI e strumenti per sviluppatori, a partire da Anthropic che lo ha introdotto. In Italia, da chi costruisce agenti AI in prima persona:
Per una mappa più ampia delle aziende AI italiane — chi fa cosa, con round e fonti — c'è la panoramica sulle aziende e startup AI a Milano e gli imprenditori italiani AI. Qui parlo solo di quello che conosco in prima persona.
MCP dà a un agente permessi reali. L'agente può essere convinto a usarli male da un testo che non hai scritto tu — una email, una pagina web, un ticket, l'output di un altro strumento (prompt injection). Con MCP una brutta risposta diventa una brutta azione. Prima di collegare un agente a un sistema vero:
La versione estesa, con fonti e il caso Web3, è nella guida su sicurezza dei server MCP. Cosa è già andato storto è raccontato in The Stack Nobody Checked.
Stai valutando MCP o colleghi agenti AI a sistemi reali e vuoi confrontarti? Scrivimi a paolo@luduvigo.com, su LinkedIn oppure prenota una call.