Model Context Protocol (MCP): come dare strumenti reali a un modello AI

Un LLM, da solo, genera testo. Per leggere dati applicativi, interrogare servizi o eseguire operazioni ha bisogno di strumenti esterni. Model Context Protocol (MCP) affronta questo problema definendo un modo standardizzato con cui applicazioni AI e sistemi esterni possono comunicare.

Il problema: ogni integrazione diventa custom

Supponiamo di voler permettere a un assistente AI di cercare articoli, interrogare un CRM, generare un carosello o pubblicare un contenuto. Senza un livello comune, ogni client deve conoscere endpoint, payload, autenticazione e convenzioni specifiche di ciascun servizio.

MCP introduce un contratto tra il client che ospita il modello e il server che espone capacità e contesto. Il modello può così lavorare con strumenti descritti in maniera strutturata invece di conoscere l’implementazione interna del sistema.

Tools: funzioni che il modello può utilizzare

Un server MCP può esporre tool con nome, descrizione e schema degli argomenti. Un’applicazione editoriale, per esempio, potrebbe offrire strumenti come get_article, carousel_ensure o publish_article.

Quando l’utente scrive “genera il carosello dell’articolo 192”, il modello può associare l’intento al tool corretto, costruire gli argomenti richiesti e lasciare al backend l’esecuzione della logica reale.

Il modello non deve conoscere Laravel, SQL o la tua architettura

Questo disaccoppiamento è uno degli aspetti più interessanti. Il tool può internamente chiamare un service Laravel, interrogare PostgreSQL, accodare un job, utilizzare una REST API o parlare con un microservizio Java. Dal punto di vista del client AI, il contratto rimane lo stesso.

Si può quindi modificare l’implementazione senza trasformare ogni cambiamento interno in una nuova istruzione per il modello.

MCP non sostituisce le API

MCP e REST non risolvono esattamente lo stesso problema. Le API continuano a essere fondamentali per la comunicazione tra sistemi. Un server MCP può infatti utilizzare le API esistenti e presentare sopra di esse strumenti progettati per essere scoperti e invocati da applicazioni AI.

In questo senso MCP può diventare un adapter tra il mondo applicativo e quello degli agenti.

Un’architettura possibile

Il flusso può essere rappresentato così: utente → client AI → MCP server → application service → database/API/job. La risposta percorre il tragitto inverso e torna al modello, che può utilizzarla per decidere il passaggio successivo.

Attenzione a sicurezza e granularità

Esporre un tool significa creare una nuova superficie applicativa. Autorizzazione, validazione degli input, idempotenza, logging e separazione tra operazioni di lettura e scrittura restano responsabilità del backend.

È inoltre preferibile esporre operazioni semanticamente utili invece di trasformare ogni metodo interno in un tool. Un comando come publish_article esprime un’azione di dominio; concedere al modello primitive troppo generiche aumenta invece complessità e rischio.

Perché MCP è interessante per uno sviluppatore

La parte più promettente non è semplicemente poter chiamare una funzione da una chat. È poter progettare applicazioni in cui modelli diversi possono scoprire e utilizzare capacità applicative attraverso contratti coerenti.

Le API rimangono. La business logic rimane. MCP aggiunge un livello pensato per rendere quelle capacità accessibili alle applicazioni AI senza accoppiare il modello ai dettagli dell’infrastruttura.