MCP: il protocollo che sta cambiando come i tuoi strumenti parlano con l'AI

Hai presente la sensazione di aprire la documentazione di un nuovo strumento AI e renderti conto, gia' alla seconda pagina, che l'integrazione che pensavi di fare nel pomeriggio ti portera' via tre giorni?

Non è esagerato. È la realtà quotidiana di chi lavora con l'AI nel 2026.

Ogni piattaforma ha le sue regole. Il suo formato di chiamata. La sua autenticazione. Il suo modo di passare il contesto.

Puoi costruire un'integrazione perfetta con uno strumento e poi scoprire che il tool usato dal tuo cliente non la riconosce.

Puoi ottimizzare per settimane un assistente AI su un sistema e poi dover ricominciare da capo perche' l'azienda ha cambiato provider.

Il problema non e' la tecnologia. Il problema e' che manca una lingua comune.

Immagina di aver costruito un ponte magnifico tra due citta', poi scoprire che le auto della citta' di destinazione hanno dimensioni diverse e non ci passano.

Questo è ciò che succede ogni giorno a chi cerca di connettere strumenti AI a sistemi reali senza uno standard condiviso.

Ma qualcosa e' cambiato.

Nel 2024 Anthropic ha pubblicato le specifiche di un protocollo aperto pensato esattamente per questo problema: un linguaggio comune che permette a qualsiasi strumento AI di parlare con qualsiasi servizio esterno, senza integrazioni proprietarie, senza riscritture continue.

Nel 2026 questo protocollo, chiamato Model Context Protocol (MCP), è gia' adottato da Claude, Cursor, GitHub Copilot e Windsurf, ed è diventato il modo in cui l'AI parla con il mondo.

Per chi sviluppa software professionale, questo cambia le carte in tavola.

Non perche' sia l'ennesimo framework da imparare. Ma perche' chi sa costruire integrazioni MCP oggi sta investendo in infrastrutture che rimarranno valide indipendentemente da quale modello AI useranno le aziende domani.

È la stessa differenza che c'era vent'anni fa tra chi sapeva progettare API standard e chi costruiva integrazioni punto-a-punto che smettevano di funzionare ad ogni cambiamento.

Il mercato si ricorda sempre di chi arriva per primo.

Cos'e' MCP e perche' sta diventando lo standard per l'AI degli agenti

Il Model Context Protocol è una specifica aperta che definisce come le applicazioni AI possono comunicare con fornitori di dati e strumenti esterni.

Anthropic ha pubblicato la specifica alla fine del 2024: in meno di un anno è già arrivata alla versione stabile 2024-11-05.

Il problema che risolve non è nuovo, ma la soluzione è elegante.

Prima di MCP, integrare un servizio con un assistente AI significava affrontare sempre lo stesso schema:

• Ricostruire integrazioni specifiche per ogni provider
• Mantenere piu' versioni dello stesso codice
• Riscrivere tutto a ogni cambio di tecnologia
• Accettare una dipendenza forte dal fornitore scelto

Ogni nuovo provider AI richiedeva un nuovo sforzo di integrazione da capo.

Con MCP, il contratto è standardizzato. Un server MCP espone le sue funzionalita' in un formato universale.

Qualsiasi client MCP-compatibile può connettersi, scoprire gli strumenti disponibili e invocarli. La logica del server non cambia indipendentemente da quale AI lo usa.

Il confronto con le REST API è utile: prima delle API standard, ogni integrazione era punto-a-punto.

Le REST API hanno standardizzato come i sistemi parlano tra loro su HTTP. MCP standardizza come i modelli AI parlano con gli strumenti.

Chi costruisce server MCP oggi investe in infrastruttura che vale su tutti i client AI attuali e futuri, senza riscritture.

Dal punto di vista del mercato italiano, l'impatto è concreto: le aziende che stanno costruendo suite di strumenti AI per i loro processi interni possono esporli una volta sola via MCP e renderli disponibili a qualsiasi assistente AI adotti il team, oggi Cursor, domani qualcos'altro.

Come funziona MCP: architettura client-server e modalita' di connessione

MCP segue un'architettura client-server con tre ruoli distinti. Capirli è il punto di partenza per tutto il resto.

• L'Host è l'applicazione AI che vuole accedere a strumenti esterni: Claude Desktop, Cursor, un'applicazione custom costruita con Semantic Kernel. Sa come parlare con i modelli AI e sa che puo' fare chiamate a server MCP per estendere le sue capacita'.
• Il Client MCP è il componente dentro l'Host che gestisce la comunicazione con i server MCP: scoperta degli strumenti, invocazione, gestione degli errori, negoziazione della versione del protocollo. L'applicazione che costruisci non deve implementare questo livello: lo fanno gia' i client ufficiali.
• Il Server MCP è l'applicazione che costruisci tu.

Espone capacità al mondo AI: strumenti che possono essere invocati, risorse che possono essere lette, template di prompt.

Puo' essere un processo locale o un servizio remoto.

Come si connettono: stdio e HTTP

MCP supporta due modalità di connessione, ognuna adatta a scenari diversi:

        
            
                // Scegliere la modalita' di connessione in base allo scenario
            
                // Scenario 1: Strumento locale (Cursor, Claude Desktop)
                builder.Services
                    .AddMcpServer()
                    .WithStdioServerTransport()
                    .WithToolsFromAssembly();

                // Scenario 2: Server remoto su ASP.NET Core
                builder.Services
                    .AddMcpServer()
                    .WithHttpServerTransport()
                    .WithToolsFromAssembly();

                // In entrambi i casi il codice degli strumenti è identico:
                // la modalità di connessione e' trasparente all'implementazione
            
        

I tre tipi di funzionalita' MCP: strumenti, risorse e prompt

Un server MCP puo' esporre tre tipi di funzionalita', ognuna con uno scopo preciso. Capire quando usare una invece dell'altra e' la chiave per progettare buoni server MCP.

Strumenti: azioni che il modello puo' eseguire

Gli strumenti sono funzioni che il modello AI può invocare per fare qualcosa nel mondo reale.

• Cercare prodotti in un catalogo
• Creare o modificare un ordine
• Inviare e-mail o notifiche
• Eseguire query su database aziendali

La caratteristica distintiva è che hanno effetti: modificano dati, inviano informazioni, eseguono operazioni.

Ogni strumento ha un nome univoco, una descrizione in linguaggio naturale, fondamentale: è quello che il modello legge per decidere se e quando invocarlo, e uno schema che definisce i parametri richiesti.

Risorse: dati che il modello puo' leggere

Le risorse sono fonti di dati che il modello puo' consultare per arricchire il suo contesto prima di rispondere.

A differenza degli strumenti, le risorse sono in genere operazioni di sola lettura: il profilo di un cliente, un documento dalla knowledge base aziendale, i dati di configurazione di un sistema.

Il modello puo' richiedere di leggere una risorsa prima di rispondere, ottenendo dati aggiornati senza che questi debbano essere scritti manualmente nel prompt.

Prompt: template riutilizzabili

I prompt sono modelli parametrizzati che il server espone al client.

Permettono di standardizzare interazioni comuni all'interno di un'organizzazione: un server MCP per un CRM potrebbe esporre un template "genera_report_cliente" che accetta un ID cliente e restituisce un modello strutturato per analizzare il profilo.

Meno usati degli strumenti nelle integrazioni tipiche, ma utili per standardizzare flussi di lavoro AI complessi.

Chi sa progettare sistemi AI che combinano questi tre meccanismi padroneggia una competenza che, in Italia, e' ancora rarissima.

Non e' un dettaglio: è la differenza tra chi costruisce architetture AI solide e chi assembla proof of concept che non vanno mai in produzione.

Vuoi diventare il developer .NET che sa costruire questi sistemi? Scopri il nostro Corso Programmazione AI.

Creare un server MCP in .NET con il pacchetto ufficiale Microsoft

Microsoft ha rilasciato il pacchetto ufficiale ModelContextProtocol per .NET nel 2025.

Nel 2026 e' gia' alla versione 0.6.x con un'API stabile e ben documentata.

Implementare il Model Context Protocol in C# è diventato un lavoro accessibile a qualsiasi developer .NET: il punto di partenza è installare i pacchetti e configurare il server in Program.cs.

        
            
                // Program.cs per un server MCP standalone (modalita' stdio)
                var builder = Host.CreateApplicationBuilder(args);

                // I servizi di dominio si registrano normalmente via DI
                builder.Services.AddScoped<IProductRepository, ProductRepository>();
                builder.Services.AddDbContext<AppDbContext>(options =>
                    options.UseSqlServer(builder.Configuration.GetConnectionString("Default")));

                // Configura il server MCP
                builder.Services
                    .AddMcpServer()
                    .WithStdioServerTransport()
                    .WithToolsFromAssembly(); // Scopre automaticamente tutti gli strumenti registrati

                await builder.Build().RunAsync();
            
        

Per un server con trasporto HTTP su ASP.NET Core, la struttura e' equivalente: si sostituisce WithStdioServerTransport() con WithHttpServerTransport(), si aggiunge il middleware di autenticazione e si mappa app.MapMcp().

Il codice degli strumenti non cambia di una riga.

Vale la pena sottolinearlo: un server MCP .NET è un'applicazione host normale, con dependency injection, configurazione, logging.

Non si impara un nuovo modello di programmazione, si estende quello che già si conosce.

Definire gli strumenti MCP: descrizioni, parametri e dependency injection

La qualità della descrizione di uno strumento è critica quanto la qualita' della sua implementazione.

I limiti del mio linguaggio sono i limiti del mio mondo.

Ludwig Wittgenstein — filosofo (1889 - 1951)

Il modello AI decide quando invocare uno strumento basandosi esclusivamente sulla descrizione: una descrizione vaga porta a invocazioni errate o mancati. Una descrizione precisa porta a un'integrazione che "funziona da sola" dal punto di vista dell'utente.

      
            
                [McpServerToolType]
                public static class CatalogoTools
                {
                    [McpServerTool]
                    [Description("Cerca prodotti nel catalogo per nome, categoria o codice SKU. " +
                                 "Restituisce nome, codice, prezzo e giacenza. " +
                                 "Usa questo strumento quando l'
                                 utente chiede di prodotti, stock o disponibilita'.")]
                    public static async Task<string> SearchProdotti(
                        [Description("Termine di ricerca: nome, categoria o SKU parziale")] string query,
                        [Description("Numero massimo di risultati. Default: 10, max: 50")] int limit = 10,
                        IProductRepository repository = null!)
                    {
                        var prodotti = await repository.SearchAsync(query, limit);
                    
                        if (!prodotti.Any())
                            return $"Nessun prodotto trovato per '{query}'.";
                    
                        var righe = prodotti.Select(p =>
                            $"- {p.Nome} | SKU: {p.Sku} | Prezzo: {p.Prezzo:C} | Stock: {p.Giacenza} pz");
                    
                        return $"Trovati {prodotti.Count} prodotti:\n{string.Join("\n", righe)}";
                    }
                }
            
        

Dependency injection negli strumenti

I parametri con tipi registrati nel contenitore DI vengono risolti automaticamente, senza configurazione aggiuntiva.

I parametri con l'attributo [Description] vengono invece esposti come parametri dello strumento nel protocollo MCP. Il framework distingue i due casi senza ambiguita'.

Il risultato pratico: uno strumento MCP puo' ricevere repository, servizi e contesti di database esattamente come qualsiasi altro componente dell'applicazione.

La logica di business non si duplica, si riusa.

La qualita' della descrizione di uno strumento MCP è direttamente proporzionale alla qualita' dell'integrazione.

Ho visto server con codice eccellente fallire perche' il modello non capiva quando invocare gli strumenti. E server con codice semplice funzionare perfettamente perche' le descrizioni erano precise e contestualizzate.

Esporre risorse: file, database e dati strutturati via MCP

Le risorse permettono al modello AI di accedere a dati in modo esplicito, separato dagli strumenti che eseguono azioni.

La distinzione è concettualmente importante: leggere il profilo di un cliente e' una risorsa, aggiornarlo e' uno strumento.

Per esporre risorse dinamiche si implementa l'interfaccia IResourceProvider: un metodo che elenca le risorse disponibili, usato per la scoperta, e un metodo che restituisce il contenuto di una risorsa specifica dato il suo identificatore.

Le risorse possono restituire testo, JSON o dati binari.

Un pattern comune nel contesto .NET è esporre documenti dalla knowledge base aziendale come risorse: policy aziendali, manuali tecnici, documentazione di prodotto.

Il modello può consultarli prima di rispondere a domande specifiche, senza che il contenuto debba essere copiato manualmente in ogni prompt.

Un'altra applicazione frequente è esporre i record piu' recenti di un sistema operativo, ordini, clienti, ticket, come risorse navigabili, permettendo al modello di leggere dati aggiornati in tempo reale.

La scelta tra strumento e risorsa segue una regola semplice: se l'operazione legge dati senza modificare nulla, probabilmente è una risorsa.

Se ha effetti collaterali o richiede parametri di ricerca complessi, è piu' adatta come strumento.

Vuoi progettare architetture AI-ready che integrino strumenti e modelli in modo scalabile?

Autenticazione e sicurezza in un server MCP di produzione

Un server MCP che espone dati aziendali o esegue operazioni con effetti collaterali ha bisogno di autenticazione robusta.

In concreto, significa proteggere tre aspetti fondamentali:

• Chi può accedere al server
• Cosa può fare una volta autenticato
• Quali operazioni devono essere tracciate

La strategia dipende dalla modalità di connessione scelta.

Modalita' stdio: sicurezza tramite isolamento del processo

Con stdio, la sicurezza deriva dall'isolamento del processo: il server viene avviato dall'utente locale e gira con i suoi permessi di sistema.

Non serve autenticazione aggiuntiva per accedere al server, ma è buona pratica aggiungere verifica delle autorizzazioni a livello di singolo strumento per operazioni sensibili, controllando che l'utente corrente abbia il ruolo corretto prima di eseguire operazioni distruttive o di lettura di dati riservati.

Modalita' HTTP: autenticazione standard ASP.NET Core

Con il trasporto HTTP si usa il middleware di autenticazione standard di ASP.NET Core, esattamente come in qualsiasi altra API web.

Il client MCP include il token di autenticazione nelle richieste come header Authorization: Bearer {token}.

Si può usare JWT, API key, OAuth 2.0 o qualsiasi schema gia' in uso nell'infrastruttura dell'organizzazione. L'endpoint MCP si protegge con una riga: app.MapMcp().RequireAuthorization("NomePolicy").

Cosa non dimenticare per gli strumenti con effetti collaterali

Registra ogni operazione di scrittura in un log auditabile: chi ha invocato lo strumento, quando, con quali parametri e qual e' stato l'esito.

Proteggi le operazioni distruttive con un meccanismo di conferma a due fasi: il primo strumento mostra un riepilogo e restituisce un token temporaneo, il secondo esegue l'operazione solo se riceve quel token.

Applica una limitazione della frequenza per gli strumenti sensibili, per prevenire abusi accidentali o intenzionali.

Valida e sanifica tutti i parametri in ingresso, specialmente quelli che finiscono in query SQL o comandi di sistema.

Test e debugging di un server MCP con il MCP Inspector

Il MCP Inspector è uno strumento ufficiale del progetto MCP per testare interattivamente un server senza dover configurare un client AI completo.

È un'interfaccia web che si connette al tuo server e ti permette di invocare strumenti, leggere risorse e verificare il comportamento in tempo reale durante lo sviluppo.

Avvia il MCP Inspector puntandolo al tuo server:

npx @modelcontextprotocol/inspector

dotnet run --project ./MioServerMcp

Per i test automatizzati, l'SDK .NET per MCP espone il client in modo programmatico: puoi avviare il server in-process, connetterti via client MCP e invocare gli strumenti esattamente come faresti con un qualsiasi test di integrazione ASP.NET Core.

Il pattern è lo stesso: host di test, client, assert sulle risposte.

Un consiglio pratico nello sviluppo di un MCP server: imposta un livello di log alto, Debug o Trace.

Il protocollo è dettagliato nei suoi messaggi e i log mostrano esattamente cosa succede durante ogni invocazione: i parametri ricevuti, il routing allo strumento corretto, la risposta restituita.

È il modo piu' rapido per capire perche' un'integrazione non funziona come previsto.

Collegare il server MCP a Cursor, Claude Desktop e altri client

Hai costruito il server, ora devi collegarlo ai client.

Il concetto è: fornire al client il comando per avviare il server, stdio, o l'URL del server, HTTP.

La configurazione varia per client, ma una volta capita la logica si replica in minuti.

Integrazione MCP con Claude Desktop in .NET

Modifica il file claude_desktop_config.json, su Windows: %APPDATA%\Claude\claude_desktop_config.json:

        
            
            {
            "mcpServers": {
                "catalogo-prodotti": {
                    "command": "dotnet",
                    "args": ["run", "--project", "C:/progetti/CatalogMcpServer", 
                    "--no-build"],
                    "env": {
                        "ConnectionStrings__Default": "Server=localhost;Database=Catalogo;Integrated Security=true"
                    }
                }
            }
        }
            
        

Cursor e altri IDE

In Cursor, apri le impostazioni, Ctrl+Shift+P, poi "Cursor Settings", vai alla sezione "MCP Servers" e aggiungi la configurazione con lo stesso formato JSON.

Il principio è identico in tutti i client che supportano MCP: si dichiara il comando di avvio per i server locali, o l'URL per i server remoti, e il client gestisce il resto.

Integrazione con Semantic Kernel

Per chi lavora nello sviluppo di agenti AI in .NET con Semantic Kernel, il pacchetto ufficiale espone un adapter MCP che traduce automaticamente gli strumenti del server in funzioni Semantic Kernel.

In poche righe di configurazione, il tuo server MCP diventa una fonte di strumenti per qualsiasi agente costruito con SK, indipendentemente dal modello AI sottostante.

MCP vs function calling OpenAI: quando usare uno, quando l'altro

La domanda è legittima: se usi gia' le funzioni di richiamo di OpenAI nei tuoi sistemi, vale la pena migrare a MCP? Non necessariamente. La scelta dipende dal contesto.

La differenza reale non è tecnica, ma strategica:

Se il tuo sistema è vincolato a OpenAI, o Azure OpenAI, e non hai intenzione di cambiare modello, le funzioni di richiamo sono piu' semplici da integrare.

Non hai bisogno di un server separato, tutto vive nell'applicazione che chiama l'API. Per casi d'uso semplici con pochi strumenti e un singolo provider, e' il percorso a minor attrito.

Il limite principale: le funzioni di richiamo non sono portabili.

Se domani vuoi usare Claude, Gemini o un modello open source, devi riscrivere l'integrazione degli strumenti da zero, o mantenere due implementazioni parallele in eterno.

MCP ha senso quando una o piu' di queste condizioni sono vere:

Vuoi che i tuoi strumenti funzionino con piu' client AI, Cursor, Claude Desktop, GitHub Copilot, applicazioni custom.

Stai costruendo strumenti aziendali condivisi che diversi team useranno con diversi assistenti AI.

Vuoi evitare il vincolo su un singolo provider e poter cambiare modello senza toccare l'implementazione degli strumenti.

Stai costruendo un'integrazione che altri sviluppatori del tuo team o della tua azienda potrebbero riusare.

Il tuo caso d'uso richiede risultati in streaming o notifiche asincrone, che MCP gestisce nativamente.

La domanda giusta non è "MCP o function calling?" ma "voglio che questo set di strumenti sia disponibile a un singolo provider o all'ecosistema AI nel suo complesso?".

Se la risposta è l'ecosistema, MCP è la scelta.

Per approfondire come Semantic Kernel si integra con MCP e come costruire agenti AI complessi in .NET, leggi il nostro articolo su Semantic Kernel e il suo ecosistema.

Per capire come questi strumenti cambiano il modo di fare software, ti consiglio anche cosa cambia davvero per chi fa software nell'era dell'AI agentica.

Hai capito il perché. Ora manca il come.

Scegliere MCP è la decisione corretta, ma costruire l'intera architettura .NET, gestire sicurezza, deployment e coordinamento tra agenti è ciò che separa un prototipo da un sistema reale in produzione.

Se vuoi arrivare fin lì, il Corso Programmazione AI è la via giusta.

MCP e il futuro dell'AI agentica: cosa aspettarsi

MCP non è solo un protocollo tecnico: è l'infrastruttura su cui si sta costruendo l'ecosistema degli agenti AI.

Nel 2026, l'adozione ha superato le aspettative iniziali.

Il modo migliore per prevedere il futuro è inventarlo.

Alan Kay — informatico e pioniere della programmazione orientata agli oggetti (1940 - vivente)

GitHub ha annunciato il supporto MCP nativo in GitHub Copilot. JetBrains lo sta integrando in tutti gli IDE. Microsoft lo sta adottando in Copilot Studio per Teams.

Le evoluzioni in corso della specifica includono:

• Sampling API: permette al server MCP di fare richieste al modello AI del client, aprendo la strada a pattern di AI collaborativa dove il server puo' chiedere al modello di interpretare dati prima di restituirli.
• OAuth 2.0 nativo: integrazione diretta con il framework di autorizzazione standard per server MCP remoti, senza dover implementare autenticazione personalizzata.
• MCP Registry: un catalogo pubblico di server MCP verificati, simile a NuGet per i pacchetti .NET, dove le aziende possono pubblicare i propri server con schema verificato.

Per chi costruisce software professionale in Italia, il messaggio è chiaro: l'integrazione AI non è piu' una funzionalita' opzionale, e' diventata un'aspettativa di base.

Le aziende che cercano consulenza su agenti AI trovano ancora un mercato in gran parte scoperto: chi costruisce queste competenze oggi si posiziona come punto di riferimento nel momento in cui la domanda esplode.

I team che oggi imparano a costruire server MCP hanno un vantaggio significativo nell'adottare gli strumenti AI aziendali del futuro.

Se vuoi approfondire il lato architetturale di questi sistemi, il nostro articolo sugli agenti AI con .NET e Semantic Kernel mostra come MCP si inserisce in architetture piu' complesse.

Nel 2026 il mercato sta selezionando. Chi ha queste competenze lavora su progetti interessanti, con clienti seri, a tariffe che riflettono il valore reale.

Chi aspetta trova uno scenario già occupato.

Non serve aspettare che succeda: nel Corso Programmazione AI puoi acquisire oggi il vantaggio che domani sarà difficile colmare.

L'ecosistema MCP: server pronti all'uso per database, SaaS e strumenti di sviluppo

Costruire il proprio server MCP non è sempre la prima mossa giusta.

Prima di mettere mano al codice, vale la pena sapere cosa esiste gia'.

L'ecosistema MCP ha visto una crescita rapida di server open source e commerciali che coprono le integrazioni piu' comuni.

Il punto di riferimento principale è il repository ufficiale modelcontextprotocol/servers su GitHub, mantenuto da Anthropic e dalla community.

Contiene implementazioni di riferimento per le integrazioni piu' richieste. Molti sono gia' in produzione, usati da migliaia di sviluppatori ogni giorno.

Prima di costruire un'integrazione personalizzata, controlla se esiste gia' un server di riferimento che copre il tuo caso d'uso.

Server MCP per database: SQL Server, PostgreSQL, SQLite

I server MCP per database sono tra i piu' richiesti. Il pattern comune è esporre strumenti per eseguire query, ispezionare lo schema e leggere dati.

Per SQL Server nel contesto .NET, la soluzione più comune è costruire un server personalizzato, perche' permette di controllare esattamente quali operazioni sono permesse.

Lasciare un server MCP con accesso SQL illimitato in produzione è un rischio di sicurezza: il pattern corretto è esporre solo procedure memorizzate e viste predefinite come strumenti MCP, impedendo al modello AI di costruire query arbitrarie sull'intero schema del database.

Server MCP per servizi SaaS: GitHub, Jira, Slack, Google Drive

Anthropic e la community mantengono server MCP di riferimento per i servizi piu' diffusi nel mondo dello sviluppo software.

Il server MCP per GitHub permette a Claude Desktop di leggere issue, aprire pull request, commentare e cercare nel codice di un repository. Il server per Jira permette di consultare ticket, cambiare stato e aggiungere commenti.

Per il mercato italiano, i servizi piu' rilevanti per cui esistono gia' server pronti o in sviluppo attivo includono Google Drive, Notion, Linear, Figma e Confluence.

Prima di costruire qualsiasi integrazione, cerca su GitHub con il termine "mcp-server" seguito dal nome del servizio.

Come valutare un server MCP di terze parti

Non tutti i server MCP disponibili sono pronti per la produzione.

Quando valuti un server di terze parti, controlla: il numero di stelle su GitHub come indicatore di adozione reale, la presenza di test automatici, e la documentazione chiara sui permessi richiesti e sui dati che il server trasmette.

Per dati aziendali sensibili, valuta sempre di costruire il server internamente anche se esiste gia' una soluzione open source: hai pieno controllo su cosa viene esposto e come.

Comporre piu' server MCP in un'unica integrazione

Un aspetto potente dell'architettura MCP è la possibilità di collegare piu' server allo stesso client.

Claude Desktop può avere configurati contemporaneamente un server per il database aziendale, uno per GitHub, uno per Google Drive e uno personalizzato per l'ERP.

Il modello AI ha accesso a tutti gli strumenti di tutti i server e puo' comporli per rispondere a domande complesse che attraversano piu' sistemi.

Un esempio concreto: "Crea un ticket Jira con il riassunto delle ultime cinque anomalie nel log di produzione di ieri".

Questa singola istruzione in linguaggio naturale puo' invocare lo strumento di lettura log del server database, elaborare i risultati, e poi invocare lo strumento di creazione ticket del server Jira, senza che l'utente debba fare nulla di piu' che scrivere quella frase.

Questa è l'AI degli agenti in pratica: non un singolo strumento, ma una composizione gestita di strumenti eterogenei.

Server MCP in produzione: deployment, osservabilita' e scaling

Passare da un server MCP che funziona in locale a uno pronto per la produzione richiede attenzione su aspetti che durante lo sviluppo si tendono a ignorare: containerizzazione, monitoraggio, limitazione della frequenza e gestione sicura delle credenziali.

Containerizzare un server MCP ASP.NET Core

Un server MCP con trasporto HTTP si containerizza esattamente come qualsiasi altra applicazione ASP.NET Core: il Dockerfile standard funziona senza modifiche.

L'unica considerazione specifica MCP riguarda il reverse proxy.

Le connessioni SSE sono connessioni HTTP di lunga durata e non devono essere interrotte prima della loro chiusura naturale: assicurati che il timeout del proxy sia configurato di conseguenza, indipendentemente dal provider scelto tra nginx, Traefik o Azure Application Gateway.

Deploy su Azure Container Apps

Azure Container Apps è la scelta naturale per server MCP nel contesto Azure: gestisce lo scaling automatico, il networking e i certificati SSL.

Una configurazione critica da non dimenticare: mantieni almeno una replica minima sempre attiva.

Le connessioni SSE sono di lunga durata e se il container va a zero repliche e deve fare cold start mentre il client è in attesa, la connessione fallisce.

Le credenziali sensibili, come connection string e chiavi API, vanno sempre in Azure Key Vault, mai nelle variabili d'ambiente del container in chiaro.

Monitorare le invocazioni degli strumenti

Il valore del monitoraggio per un server MCP è maggiore rispetto a una REST API tradizionale, perche' le invocazioni degli strumenti sono generate da un modello AI e non direttamente da un utente.

Devi poter rispondere a domande come: quale strumento viene invocato piu' spesso? Quali invocazioni producono errori? I parametri passati dal modello sono quelli attesi?

Questo tipo di analisi richiede logging strutturato sistematico per ogni invocazione, con il nome dello strumento, i parametri ricevuti, il tempo di risposta e l'esito.

Con OpenTelemetry e ASP.NET Core puoi costruire queste metriche con pochi minuti di configurazione.

L'obiettivo è avere una dashboard che mostri distribuzione dei tempi di risposta, errori per tipo e carico complessivo: la differenza tra un server di prova e uno pronto per un ambiente enterprise.

Gestione dei segreti e rotazione delle credenziali

Un server MCP che accede a sistemi aziendali accumula inevitabilmente credenziali sensibili: connection string, chiavi API, token OAuth.

Non incorporare mai nel codice o nei Dockerfile le credenziali. Usa sempre un sistema esterno di gestione segreti: Azure Key Vault in ambiente Azure, AWS Secrets Manager in ambiente AWS, HashiCorp Vault per deployment on-premise.

La rotazione automatica delle credenziali è particolarmente importante per i server MCP, perche' spesso girano come servizi di lunga durata.

Il pattern consigliato e' configurare il ricaricamento periodico dei segreti senza riavviare il container: ASP.NET Core si integra nativamente con Azure Key Vault tramite il pacchetto dedicato e gestisce il refresh automatico quando le credenziali vengono ruotate.

Progettare strumenti MCP per agenti AI: pattern e anti-pattern

Costruire strumenti MCP che funzionano in isolamento è una cosa.

Progettarli perché funzionino bene quando un agente AI li coordina in sequenze complesse è un'altra.

Un sistema complesso che funziona è invariabilmente nato da un sistema semplice che funzionava.

John Gall — medico e scrittore (1925 - 2014)

Il tool use via MCP da parte degli agenti AI segue dinamiche diverse rispetto all'invocazione diretta: il modello decide autonomamente sequenza, parametri e combinazione degli strumenti.

Ci sono pattern che rendono i tuoi strumenti robusti in questi scenari:

• Restituiscono sempre informazioni utili, anche in caso di errore
• Guidano il modello verso il passo successivo
• Evitano ambiguità nei parametri
• Rendono le operazioni prevedibili e controllabili

E anti-pattern che portano a comportamenti imprevedibili.

Il principio della risposta informativa

Gli strumenti MCP non devono restituire solo il risultato dell'operazione, ma abbastanza contesto perche' il modello AI possa decidere il passo successivo in modo corretto.

Se uno strumento di ricerca non trova risultati, non restituire solo una stringa vuota: restituisci un messaggio che suggerisce azioni alternative.

Se uno strumento di scrittura fallisce per validazione, restituisci esattamente quale campo ha fallito e perche', non un generico "operazione fallita".

Il modello usa queste informazioni per correggere l'invocazione o informare l'utente in modo utile, senza interrompere il flusso.

Uno strumento che restituisce messaggi di errore ricchi di contesto e' uno strumento che un agente AI sa usare autonomamente: uno che restituisce errori generici richiede sempre un intervento umano.

Idempotenza e operazioni distruttive

Gli strumenti che modificano dati devono essere progettati con attenzione alla ripetibilita'.

Un agente AI può invocare lo stesso strumento piu' volte se non è sicuro che la prima invocazione sia andata a buon fine.

Le operazioni di creazione devono verificare se la risorsa esiste gia'. Le operazioni di aggiornamento devono essere idempotenti quando possibile.

Le operazioni distruttive, cancellazione, reset, invio irreversibile, meritano un trattamento speciale: il pattern consigliato è la conferma a due fasi.

Il primo strumento restituisce un riepilogo dell'operazione e un token di conferma temporaneo. Il secondo strumento esegue l'operazione solo se riceve quel token.

Questo impedisce che un agente AI esegua accidentalmente operazioni irreversibili senza che l'utente abbia avuto modo di valutarle.

Per approfondire come questi pattern si inseriscono in architetture di agenti AI piu' complesse, leggi il nostro articolo su come costruire agenti AI in .NET con Semantic Kernel.

Hai letto fin qui.

Sai cos’è MCP, come funziona, dove sta andando il mercato. La domanda non è più "vale la pena impararlo?": la risposta è gia' evidente.

La vera domanda e' un'altra: lo farai adesso, mentre il vantaggio competitivo e' ancora reale, oppure aspetterai che lo facciano tutti e poi cercherai di recuperare?

In Italia, le aziende che costruiscono sistemi AI seri su .NET sono ancora poche.

I developer che sanno progettare queste architetture sono ancora meno. Chi entra in questo spazio oggi non compete: domina.

Il Corso Programmazione AI è pensato esattamente per questo: formarti sui fondamentali e sui pattern avanzati con un approccio pratico, finche' non sapri fare quello che la maggioranza non sapra' mai fare.

uoi saperne di più? Prenota il tuo posto, ma fai in fretta. Per garantire la qualità, limito il numero di persone per ogni classe e non apro un nuovo ciclo finché chi sta dentro non è pronto a lavorare in autonomia.

Nessun impegno: compila il form.

I posti sono limitati.