MCP servers per sviluppatori: costruire strumenti AI personalizzati per il workflow aziendale

Il momento in cui ho capito che il Model Context Protocol avrebbe cambiato il mio modo di lavorare è stato a maggio 2025, quando ho passato 35 minuti a copiare e incollare dati tra un gestionale ERP, un foglio di calcolo e la chat di Claude per fargli generare un report settimanale delle vendite per un cliente del settore distribuzione. Facevo questo ogni lunedì mattina: esportavo i dati dal gestionale, li formattavo in un CSV, li incollavo nel prompt, chiedevo a Claude di analizzarli e generare il report. Trentacinque minuti di lavoro manuale ripetitivo che un computer dovrebbe fare in 10 secondi - ma il problema era che Claude non poteva accedere direttamente al gestionale. Il Model Context Protocol (MCP) risolve esattamente questo problema: è un protocollo aperto che permette ai modelli AI di chiamare strumenti esterni con parametri tipizzati, ricevere risposte strutturate, e usare il risultato nel proprio ragionamento - senza copia-incolla, senza CSV intermedi, senza prompt engineering per spiegare al modello la struttura dei dati.

In sei mesi ho costruito tre MCP server per altrettanti clienti - uno che interroga il database del gestionale ERP tramite query predefinite e sicure, uno che gestisce il CMS con operazioni CRUD su articoli e pagine, e uno che interagisce con il sistema di ticketing per creare, assegnare e aggiornare task. Il tempo speso in task ripetitivi dai team che usano questi strumenti è sceso del 70% - non perché l'AI faccia il lavoro al posto loro, ma perché l'AI ha ora accesso diretto ai dati di cui ha bisogno per assistere nelle decisioni, senza che un umano faccia da intermediario manuale.

Come funziona il Model Context Protocol e perché è diverso da un'API tradizionale?

MCP non è un modo per chiamare API - è un protocollo che definisce come un'AI interagisce con il mondo esterno in modo sicuro e strutturato. La differenza fondamentale con le API tradizionali è il chi decide cosa fare: in un'integrazione API tradizionale, il programmatore scrive codice che chiama endpoint specifici in sequenza predefinita. In un'integrazione MCP, l'AI decide quali strumenti chiamare e in quale ordine in base alla richiesta dell'utente. Il programmatore definisce gli strumenti disponibili (con nome, descrizione e schema dei parametri), e l'AI ragiona su quali usare per soddisfare la richiesta.

Un esempio chiarisce la distinzione. Con un'API tradizionale, se l'utente chiede "Quali sono i 10 clienti con il fatturato più alto del trimestre?", il programmatore deve: scrivere un endpoint che faccia quella query specifica, integrarlo nel frontend, e gestire i parametri (quale trimestre? ordinamento? filtri?). Con un MCP server, il programmatore definisce uno strumento generico "query_fatturato" con parametri (periodo_inizio, periodo_fine, limite, ordinamento), e l'AI capisce da sola che per rispondere alla domanda dell'utente deve chiamare quello strumento con periodo_inizio: "2025-07-01", periodo_fine: "2025-09-30", limite: 10, ordinamento: "desc". Se l'utente chiede la stessa cosa per il semestre, l'AI cambia i parametri senza che il programmatore scriva una riga in più.

Nel mio profilo professionale trovi il dettaglio dell'infrastruttura MCP che ho costruito per la mia attività di consulenza - inclusi i server che gestiscono il CMS del blog, le query sul database dei clienti, e l'automazione delle sessioni di lavoro. L'esperienza di prima mano è fondamentale perché un MCP server mal progettato è peggio di nessun MCP server: se i tool hanno descrizioni ambigue o parametri non validati, l'AI li chiama in modo errato e produce risultati fuorvianti che il team prende per buoni.

Architettura di un MCP server in PHP: il pattern che uso

Un MCP server è un processo che comunica con il client AI (Claude Code, Claude Desktop, o qualsiasi client MCP-compatibile) attraverso lo standard JSON-RPC su stdio o su connessione HTTP/SSE. Il server dichiara i propri tool (strumenti) all'avvio, e il client li presenta all'AI come azioni disponibili.

La struttura di un MCP server PHP che espone query predefinite verso un database MySQL è questa:

// mcp-server/erp-tools.php
// Server MCP per query sicure verso il gestionale ERP

// Definizione dei tool disponibili
$tools = [
    [
        'name' => 'query_fatturato',
        'description' => 'Restituisce il fatturato aggregato per cliente in un periodo',
        'inputSchema' => [
            'type' => 'object',
            'properties' => [
                'data_inizio' => ['type' => 'string', 'description' => 'Data inizio (YYYY-MM-DD)'],
                'data_fine' => ['type' => 'string', 'description' => 'Data fine (YYYY-MM-DD)'],
                'limite' => ['type' => 'integer', 'description' => 'Numero massimo risultati', 'default' => 20],
            ],
            'required' => ['data_inizio', 'data_fine'],
        ],
    ],
    [
        'name' => 'dettaglio_cliente',
        'description' => 'Restituisce anagrafica e storico ordini di un cliente specifico',
        'inputSchema' => [
            'type' => 'object',
            'properties' => [
                'cliente_id' => ['type' => 'integer', 'description' => 'ID cliente nel gestionale'],
            ],
            'required' => ['cliente_id'],
        ],
    ],
];

// Handler per le chiamate ai tool
function handleToolCall(string $name, array $args, PDO $db): array
{
    return match ($name) {
        'query_fatturato' => queryFatturato($db, $args),
        'dettaglio_cliente' => dettaglioCliente($db, $args),
        default => ['error' => "Tool sconosciuto: {$name}"],
    };
}

function queryFatturato(PDO $db, array $args): array
{
    // Query con prepared statement - MAI concatenazione di stringhe
    $stmt = $db->prepare("
        SELECT c.ragione_sociale, SUM(f.importo_totale) as fatturato
        FROM fatture f
        JOIN clienti c ON c.id = f.cliente_id
        WHERE f.data_emissione BETWEEN :inizio AND :fine
        GROUP BY c.id, c.ragione_sociale
        ORDER BY fatturato DESC
        LIMIT :limite
    ");

    $stmt->execute([
        ':inizio' => $args['data_inizio'],
        ':fine' => $args['data_fine'],
        ':limite' => min($args['limite'] ?? 20, 100),
    ]);

    return $stmt->fetchAll(PDO::FETCH_ASSOC);
}

Il punto critico di sicurezza è che il MCP server non espone il database direttamente. L'AI non può eseguire query SQL arbitrarie - può solo chiamare i tool predefiniti con i parametri dichiarati nello schema. Questo è fondamentalmente diverso dal dare all'AI una connessione database diretta (un antipattern che ho visto in troppi tutorial): i tool agiscono come un layer di autorizzazione che limita ciò che l'AI può fare al set di operazioni che il programmatore ha esplicitamente definito e validato. Se l'AI prova a chiamare un tool che non esiste o passa parametri fuori schema, il server rifiuta la richiesta. Questa architettura segue il principio del privilegio minimo - l'AI ha accesso solo a ciò di cui ha bisogno, niente di più.

Il pattern dei tre MCP server in produzione

Nei sei mesi di utilizzo, ho standardizzato tre categorie di MCP server che coprono i casi d'uso più frequenti nelle PMI italiane:

Server 1: Query ERP read-only. Espone 8-12 query predefinite verso il gestionale - fatturato per periodo, dettaglio cliente, stato ordini, giacenze magazzino, scadenze pagamenti. Tutte read-only, tutte con prepared statement, tutte con limiti sui risultati. Questo server trasforma Claude in un analista che può rispondere istantaneamente a domande come "Quali clienti hanno ordinato più di 10.000 euro nell'ultimo trimestre ma non hanno ancora pagato?" senza che l'utente debba aprire il gestionale, costruire un filtro complesso, ed esportare i dati.

Server 2: CMS content management. Espone tool per creare, aggiornare e pubblicare contenuti - articoli, pagine, tag, immagini. L'AI può generare un articolo, formattarlo secondo le regole del CMS, e pubblicarlo con un singolo comando vocale o testuale dell'utente. Per il mio blog, questo server gestisce l'intera pipeline editoriale: generazione, validazione, import e gestione delle immagini.

Server 3: Task e ticketing. Espone tool per interagire con il sistema di project management - creare ticket, assegnare priorità, aggiornare stati, generare report di sprint. L'AI può trasformare una richiesta informale ("c'è un bug nel checkout quando il coupon è scaduto") in un ticket strutturato con titolo, descrizione, priorità e assegnatario in 5 secondi.

La chiave del successo di questi server non è la complessità tecnica - è la qualità delle descrizioni dei tool. Un tool con descrizione "Interroga il database" è inutile perché l'AI non sa quando usarlo. Un tool con descrizione "Restituisce il fatturato aggregato per cliente in un periodo specificato, ordinato per importo decrescente. Usare quando l'utente chiede informazioni su vendite, fatturato, o classifiche clienti per periodo" è preciso e l'AI lo usa correttamente nel 95% dei casi. Ho documentato un approccio complementare all'integrazione AI nella mia esperienza con Kafka per architetture event-driven, dove il pattern è lo stesso: l'automazione funziona quando i contratti tra i componenti sono espliciti e ben definiti.

Sicurezza e governance: chi controlla cosa può fare l'AI

La domanda che ogni CIO o responsabile IT pone quando presento i MCP server è: "Ma allora l'AI può accedere a tutti i nostri dati?" La risposta è: solo ai dati che tu decidi esplicitamente di esporre, attraverso tool che tu definisci, con permessi che tu configuri. L'architettura MCP è opt-in per definizione - l'AI non scopre autonomamente quali strumenti sono disponibili, e non può accedere a risorse non dichiarate nel server.

Questo significa che la governance dell'accesso AI ai dati aziendali si riduce alla governance dei tool esposti nel MCP server. Per ogni tool, devo decidere: chi può invocarlo (quali utenti o quali sessioni AI), quali parametri accetta (e quali vincoli hanno quei parametri - ad esempio un limite massimo di 100 risultati per evitare dump massivi), e quali dati restituisce (mai dati sensibili come password hash, token di sessione o PII non necessarie).

Nel server ERP del cliente, ho implementato tre livelli di accesso: i tool di lettura aggregata (fatturato per periodo, classifiche clienti) sono disponibili a tutti gli utenti autorizzati, i tool di lettura dettaglio (anagrafica cliente con dati fiscali, storico ordini con importi) sono disponibili solo ai ruoli commerciale e amministrazione, e i tool di scrittura (creare ordini, aggiornare anagrafiche) non esistono nel server di produzione - le operazioni di modifica passano sempre attraverso l'interfaccia del gestionale con la supervisione umana. Questa scelta è intenzionale: l'AI che legge dati e produce analisi è un acceleratore. L'AI che scrive dati nel gestionale senza supervisione è un rischio che non sono disposto a prendermi per nessun cliente, indipendentemente dal livello di validazione dei parametri.

Un altro aspetto che i tutorial non coprono è il logging delle chiamate MCP. Ogni invocazione di tool da parte dell'AI viene loggata con timestamp, parametri, utente che ha avviato la sessione AI, e dimensione della risposta. Questo audit trail serve a due scopi: primo, permette di capire come l'AI usa gli strumenti e di ottimizzare le descrizioni dei tool basandosi sull'uso reale (se l'AI chiama sistematicamente query_fatturato con parametri che producono risultati vuoti, la descrizione del tool è probabilmente ambigua); secondo, fornisce evidenza di compliance per dimostrare che l'accesso AI ai dati aziendali è controllato, limitato e tracciabile - un requisito che diventa sempre più rilevante con la normativa GDPR e le linee guida dell'AI Act europeo.

Il Model Context Protocol è la tecnologia che nel 2025-2026 sta trasformando il modo in cui gli sviluppatori costruiscono integrazioni AI - non più prompt engineering artigianale, ma chiamate a strumenti tipizzati con garanzie di sicurezza. Se vuoi costruire MCP server personalizzati per i tuoi strumenti aziendali - gestionale, CRM, sistema di ticketing, database - o se vuoi capire come Claude Code può diventare un assistente operativo che accede direttamente ai tuoi dati senza intermediari manuali, contattami per una sessione di progettazione: in una giornata di lavoro definiamo i tool, implementiamo il server e lo integriamo nel tuo workflow quotidiano. L'investimento iniziale per un MCP server custom è tipicamente una giornata di lavoro - e il risparmio in ore di lavoro manuale ripetitivo si ripaga nel primo mese di utilizzo, con un miglioramento nella qualità dei dati e nella velocità di accesso alle informazioni che il team nota immediatamente.