MCP Server: cosa sono e come funziona il Model Context Protocol

Un MCP Server è un programma che mette strumenti, dati e workflow a disposizione di un’applicazione di intelligenza artificiale attraverso il Model Context Protocol. Il punto importante è capire cosa significa davvero: il modello linguistico non si collega direttamente a database, API o file e MCP non sostituisce automaticamente queste tecnologie. Crea invece un’interfaccia standard attraverso cui un’applicazione AI può scoprire e utilizzare capacità esterne.

MCP, acronimo di Model Context Protocol, è stato introdotto da Anthropic nel novembre 2024 come standard aperto per collegare applicazioni AI a fonti di dati e strumenti. La presentazione originale del Model Context Protocol ne descriveva già l’obiettivo centrale: ridurre la frammentazione delle integrazioni costruite una per una.

Questo non significa che MCP trasformi automaticamente un chatbot in un agente. Se vuoi approfondire quella distinzione, nella guida Creativemotions dedicata agli agenti AI trovi il livello di orchestrazione e autonomia che sta sopra al semplice accesso agli strumenti.

Il protocollo, inoltre, è cambiato rapidamente. La specifica 2026-07-28, pubblicata il 28 luglio 2026, ha introdotto un core stateless, eliminato il precedente handshake initialize/initialized e Mcp-Session-Id, aggiunto server/discover e rivisto routing, caching, autorizzazione ed estensioni. Per questo alcune guide pubblicate anche pochi mesi prima descrivono già un’architettura precedente.

Per capire davvero gli MCP Server conviene quindi partire non dalla lista dei server disponibili, ma da ciò che accade realmente quando un’applicazione AI deve scoprire uno strumento, renderlo disponibile al modello ed eseguirlo.

Cos’è il Model Context Protocol e perché esiste

Il Model Context Protocol è uno standard per lo scambio di contesto e capacità tra applicazioni AI e sistemi esterni.

Definisce il modo in cui client e server comunicano, dichiarano le proprie capacità, scoprono strumenti e si scambiano richieste e risultati. La documentazione ufficiale dell’architettura MCP chiarisce però un confine fondamentale: MCP si occupa del protocollo di scambio del contesto, ma non decide come l’applicazione AI usa il modello linguistico o gestisce quel contesto.

Questa distinzione evita uno degli equivoci più comuni. MCP non è un nuovo modello AI, un sistema di ragionamento, un agente autonomo o un sostituto universale delle API. È uno strato di interoperabilità.

Il problema delle integrazioni tra AI, dati e strumenti

Immagina di sviluppare un assistente AI che deve lavorare con GitHub, Google Drive, PostgreSQL, WooCommerce, Slack e alcuni file locali.

Senza un’interfaccia comune, ogni collegamento richiede una propria integrazione: autenticazione, funzioni, parametri, conversione dei dati, gestione degli errori e codice necessario a presentare quelle capacità al modello.

Aggiungi una seconda applicazione AI e parte di quel lavoro deve potenzialmente essere ripetuta.

Il problema cresce quindi su due dimensioni: aumentano le applicazioni AI e aumentano i sistemi da integrare.

MCP introduce un contratto comune nel mezzo.

Un server GitHub può, per esempio, esporre strumenti per cercare issue o leggere un repository. Un host compatibile con MCP può scoprire quelle capacità senza conoscere in anticipo tutta l’implementazione interna del servizio.

Questo non elimina il lavoro di integrazione. Lo sposta dietro un’interfaccia standard e riutilizzabile.

Cosa standardizza MCP e cosa invece non decide

MCP standardizza elementi come:

• ruoli di host, client e server;
• formato dei messaggi;
• discovery di versioni e capability;
• discovery e invocazione dei Tools;
• accesso alle Resources;
• gestione dei Prompts;
• trasporti;
• notifiche;
• alcune componenti di autenticazione e autorizzazione.

Il data layer utilizza JSON-RPC 2.0 per strutturare richieste, risposte e notifiche.

Non decide invece:

• quale LLM usare;
• come il modello ragiona;
• se mostrare tutti i tool disponibili;
• quali operazioni richiedono conferma umana;
• quale API deve usare il server;
• dove devono risiedere le credenziali;
• quale business logic applicare.

Il modello mentale corretto è quindi:

MCP standardizza l’interfaccia. Il sistema sottostante esegue il lavoro. L’applicazione AI governa come quella capacità arriva al modello.

Cos’è un MCP Server e cosa fa realmente

Un MCP Server è un programma che espone capacità o contesto verso un MCP Client utilizzando il protocollo MCP.

La definizione ufficiale parla deliberatamente di programma. Il server può infatti essere un processo eseguito sulla stessa macchina dell’utente oppure un servizio remoto raggiungibile attraverso la rete.

Il termine “server” descrive quindi il ruolo nel protocollo, non necessariamente una macchina remota in un data center.

MCP Server e sistema sottostante: chi esegue davvero l’azione

Supponiamo di avere un MCP Server per WooCommerce con un tool:

get_orders

Il tool potrebbe accettare parametri come:

• data iniziale;
• data finale;
• stato dell’ordine.

Quando viene invocato, il server può utilizzare le REST API di WooCommerce per recuperare i dati reali.

Il percorso diventa:

applicazione AI → MCP Client → MCP Server → API WooCommerce → database

Il server MCP non ha sostituito l’API. L’ha resa accessibile all’applicazione AI attraverso un’interfaccia standard.

Il server può anche aggiungere logica propria: validare gli argomenti, filtrare dati, controllare permessi, combinare più endpoint o impedire determinate operazioni.

Per questo, in molti scenari, un MCP Server funziona come adattatore tra l’applicazione AI e API, database, filesystem, SDK o servizi già esistenti.

WordPress è un caso concreto di questa architettura. Con Abilities API e MCP Adapter, le funzionalità del CMS possono essere rese disponibili agli agenti attraverso MCP mantenendo controlli su permessi e capacità. Nella guida a WordPress MCP vediamo come funziona su WordPress.com e self-hosted e quali operazioni può realmente eseguire un agente AI.

Se invece vuoi capire come WordPress 7.1 sta facendo evolvere l’Abilities API e l’infrastruttura su cui possono appoggiarsi questi agenti, abbiamo analizzato cosa entra realmente nella release, quali Core Abilities sono rimaste nel plugin AI e perché permessi, discovery e auditing stanno diventando centrali.

Un MCP Server non deve essere necessariamente remoto

Un server locale può essere avviato dall’applicazione e comunicare tramite STDIO, cioè standard input e standard output.

È naturale quando deve lavorare con file, repository, strumenti CLI o altre risorse disponibili sulla macchina.

Un server remoto utilizza normalmente Streamable HTTP e introduce invece problemi tipici dei servizi di rete:

• autenticazione;
• TLS;
• autorizzazione;
• routing;
• monitoraggio;
• scalabilità;
• isolamento tra utenti.

La differenza non riguarda quindi soltanto dove gira il codice. Cambiano anche superficie di attacco, gestione delle credenziali e modello operativo.

MCP Host, MCP Client e MCP Server: chi fa cosa

Per capire MCP servono tre ruoli distinti:

Host → Client → Server

La documentazione corrente specifica che un MCP Host crea normalmente un MCP Client dedicato per ciascun MCP Server collegato.

MCP Host: dove vive l’applicazione AI

L’MCP Host è l’applicazione AI che coordina l’intero sistema.

Può essere un IDE, un’app desktop, un’applicazione conversazionale o un sistema agentico.

L’host può gestire:

• modello;
• conversazione;
• server configurati;
• policy;
• permessi;
• selezione degli strumenti;
• approvazioni;
• risultati da reinserire nel contesto.

Se colleghi tre server MCP, l’host può quindi mantenere tre client distinti.

MCP Client: il componente che parla MCP

L’MCP Client mantiene la relazione con uno specifico MCP Server.

Il client utilizza MCP per:

• scoprire capability;
• elencare Tools, Resources o Prompts;
• invocare strumenti;
• ricevere risultati;
• sottoscrivere eventuali notifiche.

Se l’host utilizza un server GitHub e uno per il database avremo concettualmente:

MCP Client GitHub → MCP Server GitHub

MCP Client Database → MCP Server Database

Il client conosce il protocollo. Non deve conoscere l’implementazione interna del sistema dietro al server.

MCP Server: il programma che espone capacità e contesto

Il server dichiara quali capacità offre e con quali schemi.

Può esporre Tools, Resources e Prompts.

Questo design incide direttamente sulla sicurezza.

Un database potrebbe permettere migliaia di query, ma non significa che il server debba fornire al modello:

execute_arbitrary_sql

Potrebbe essere molto più appropriato limitarsi a:

get_monthly_sales

find_customer

list_recent_orders

La qualità di un MCP Server dipende anche da quanto bene delimita ciò che il modello può chiedergli di fare.

Come funziona davvero un MCP Server

Questa è la parte centrale.

Il flusso corretto è:

server → discovery → applicazione → modello → tool call → applicazione → client → server → risultato → modello

L’LLM non apre autonomamente una connessione verso l’MCP Server.

Discovery: come il client scopre capacità e versione del server

Con MCP 2026-07-28 ogni richiesta porta informazioni come versione del protocollo e capability del client nel campo _meta.

Il server deve implementare:

server/discover

attraverso cui può dichiarare identità, versioni supportate e capability.

La chiamata server/discover è però opzionale lato client: il client può usarla preventivamente oppure inviare direttamente un’altra richiesta e gestire un eventuale errore di versione.

Questo sostituisce il modello precedente, nel quale la negoziazione avveniva tramite un handshake iniziale.

Come il client scopre i tool con tools/list

Sapere che il server supporta Tools non significa ancora conoscere quali strumenti possiede.

Il client può inviare:

tools/list

La risposta contiene una lista di tool con elementi come:

• name;
• title;
• description;
• inputSchema.

L’inputSchema descrive attraverso JSON Schema quali parametri accetta lo strumento.

Un tool:

get_order

potrebbe richiedere:

order_id: integer

Il client non riceve quindi soltanto un nome. Ottiene una descrizione strutturata della capacità.

La specifica 2026 permette inoltre di associare alla lista informazioni di caching come ttlMs e cacheScope, evitando di recuperare continuamente cataloghi che non sono cambiati.

Come i tool diventano disponibili al modello

Qui avviene il passaggio spesso trascurato.

La documentazione ufficiale descrive un’applicazione che recupera i tool dai diversi MCP Server e li combina in un registro unificato degli strumenti.

Concettualmente:

server A + server B + server C → tool registry dell’applicazione

L’host può quindi mettere una selezione di questi strumenti a disposizione del modello.

Il modello riceve informazioni come nome, descrizione e parametri e può utilizzarle per decidere se una capacità è pertinente alla richiesta dell’utente.

Questo significa che MCP non obbliga a esporre al modello ogni tool disponibile.

L’host può filtrare, limitare o rendere progressivamente disponibili gli strumenti.

Chi decide di usare un tool

Dire che “il modello chiama il server” è una semplificazione imprecisa.

Il modello riceve le definizioni degli strumenti e può produrre un output strutturato che indica:

tool = get_orders

arguments = {...}

Il protocollo MCP non stabilisce il processo interno con cui il modello prende quella decisione.

A questo punto entra in gioco l’applicazione.

L’host intercetta la tool call, individua quale MCP Client è associato allo strumento e invia al server:

tools/call

È esattamente il flusso descritto nell’esempio ufficiale dell’architettura MCP.

Cosa succede dopo tools/call

Il server riceve nome dello strumento e argomenti.

Esegue quindi la propria logica.

Può:

• interrogare un’API;
• leggere un file;
• interrogare un database;
• modificare un sistema esterno;
• combinare più servizi.

Il server restituisce un risultato strutturato.

L’host lo reinserisce nel flusso conversazionale e il modello può:

• formulare la risposta;
• chiamare un secondo tool;
• chiedere altri dati;
• combinare più risultati.

Il ciclo completo è quindi:

utente → host/modello → tool call → host/client → MCP Server → sistema esterno → host → modello → utente

Tools, Resources e Prompts: cosa cambia davvero

Un MCP Server può esporre tre primitive principali:

Tools, Resources e Prompts.

La documentazione ufficiale sui concetti server MCP distingue le tre categorie in base alla funzione che svolgono nell’applicazione.

Tools: azioni che il modello può richiedere

Un Tool è una funzione schema-defined che può eseguire un’operazione.

Esempi:

• recuperare un ordine;
• creare un ticket;
• inviare un messaggio;
• interrogare un database;
• cercare un repository;
• modificare un record.

Le due operazioni centrali sono:

tools/list

per la discovery e:

tools/call

per l’esecuzione.

Che un Tool possa essere richiesto dal modello non significa che debba essere eseguito senza controllo. L’host può applicare allowlist, policy, autorizzazioni o conferme.

Resources: dati che l’applicazione recupera come contesto

Le Resources rappresentano invece fonti di informazione.

Possono essere:

• file;
• documentazione;
• record;
• schema di database;
• risposta API;
• knowledge base.

L’applicazione può scegliere quali risorse recuperare, filtrare e fornire al modello.

Sono quindi particolarmente adatte quando il problema è dare contesto, non eseguire un’azione.

Prompts: template riutilizzabili

I Prompts MCP sono template strutturati messi a disposizione dal server.

Possono avere parametri e combinare istruzioni, Resources o Tools per creare workflow riutilizzabili.

Un prompt potrebbe chiamarsi:

analizza_vendite

e richiedere:

• periodo;
• mercato;
• categoria.

Non va confuso con il normale messaggio scritto dall’utente nella chat.

Tool, Resource o Prompt? Un caso concreto

Supponiamo di costruire un server MCP per WooCommerce.

Una Resource potrebbe descrivere lo schema degli ordini.

Un Tool potrebbe recuperare gli ordini di una determinata giornata.

Un Prompt potrebbe offrire un template strutturato per analizzare anomalie nelle vendite.

Le tre primitive convivono perché risolvono tre problemi differenti:

informazione → azione → workflow.

MCP Server locali e remoti: STDIO o Streamable HTTP?

La specifica corrente prevede due trasporti principali:

STDIO e Streamable HTTP.

STDIO per processi locali

Con STDIO il client comunica con il processo server attraverso standard input e standard output.

È adatto a server locali perché:

• non richiede endpoint HTTP;
• elimina il normale overhead di rete;
• può essere avviato dall’applicazione;
• funziona bene con filesystem e tool CLI.

Ma locale non significa automaticamente sicuro.

Un server locale è comunque codice eseguito sul computer e può avere accesso alle risorse consentite dal sistema operativo.

Streamable HTTP per server remoti

Streamable HTTP utilizza HTTP POST per le richieste client→server e può utilizzare Server-Sent Events per lo streaming server→client.

È adatto a server remoti perché può integrarsi con:

• gateway;
• load balancer;
• sistemi di autenticazione;
• logging;
• infrastruttura HTTP esistente.

Dove entra SSE nella specifica corrente

La distinzione è importante perché molte guide descrivono ancora:

STDIO oppure SSE

come i due trasporti MCP.

Nella specifica corrente il modello è invece:

STDIO

oppure:

Streamable HTTP

Streamable HTTP può utilizzare SSE opzionalmente per lo streaming.

È il precedente trasporto HTTP+SSE come modalità separata a essere stato deprecato.

MCP 2026-07-28: cosa è cambiato rispetto alle vecchie guide

La specifica del 28 luglio 2026 rappresenta uno dei cambiamenti più profondi del protocollo dalla sua nascita.

Le differenze più importanti non sono cosmetiche: incidono sul modo in cui progetti server remoti e sul modello mentale con cui MCP va spiegato. Il changelog ufficiale della specifica 2026-07-28 documenta i cambiamenti principali.

MCP ora ha un core stateless

Ogni richiesta trasporta le informazioni necessarie per essere interpretata, compresi protocol version e capability pertinenti.

Questo rende MCP stateless a livello di core protocol.

Non significa che l’applicazione non possa mantenere stato.

Puoi continuare ad avere:

• database;
• job;
• workflow;
• code;
• dati utente;
• stato applicativo.

La differenza è che una normale richiesta MCP non deve dipendere da una sessione di protocollo precedentemente creata.

Perché handshake e sessione di protocollo sono scomparsi

Nelle versioni precedenti esistevano:

initialize → initialized

e, per Streamable HTTP:

Mcp-Session-Id

Con la specifica 2026-07-28 questi elementi sono stati rimossi dal core.

Versione, informazioni sul client e capability vengono trasportate nelle richieste tramite _meta.

La conseguenza pratica è importante soprattutto per i server remoti distribuiti.

Una richiesta può essere gestita da un’istanza disponibile dietro un normale load balancer senza richiedere necessariamente sticky session o uno storage condiviso per lo stato della sessione MCP.

server/discover, caching e routing

server/discover permette al client di recuperare identità del server, versioni supportate e capability.

Le risposte possono includere indicazioni di caching come:

ttlMs

e:

cacheScope

Anche le liste di tool possono essere cacheate.

La specifica introduce inoltre header come Mcp-Method e Mcp-Name, utili per routing, autorizzazione e osservabilità a livello infrastrutturale.

Multi Round-Trip Requests

Non tutte le operazioni possono essere risolte con una singola coppia:

request → response

Il server può aver bisogno di informazioni aggiuntive dall’utente.

Il pattern Multi Round-Trip Requests permette di gestire queste interazioni senza tornare al vecchio modello di stream bidirezionale costantemente aperto.

Un esempio è Elicitation, attraverso cui il server può chiedere al client di raccogliere ulteriori dati o una conferma.

Extensions, Tasks e MCP Apps

La revisione 2026 rende più netto il confine tra core ed estensioni.

Tasks permette di gestire operazioni lunghe restituendo un handle durevole che può essere interrogato successivamente.

MCP Apps porta invece interfacce interattive associate agli strumenti.

Il supporto effettivo dipende comunque dall’host. Essere parte dell’ecosistema MCP non significa che ogni client implementi automaticamente ogni estensione.

MCP vs API, function calling e RAG

MCP viene spesso confrontato con tecnologie che operano a livelli differenti.

La domanda utile non è quale le sostituirà, ma quale problema risolve ciascuna.

Tecnologia	Problema principale	Discovery standardizzata	Può eseguire azioni	Può fornire contesto
MCP	Interoperabilità tra applicazioni AI e capacità esterne	Sì	Sì, tramite Tools	Sì, tramite Resources
API	Comunicazione programmabile tra sistemi	Dipende dall’API	Sì	Sì
Function calling	Permettere al modello di richiedere una funzione	Dipende dal runtime	Serve un executor	Il risultato torna al modello
RAG	Recuperare informazioni pertinenti per la generazione	Non necessariamente	Normalmente no	Sì

MCP vs API: perché spesso il server MCP usa proprio un’API

Un’API definisce il contratto tra sistemi software.

MCP definisce il contratto con cui un’applicazione AI può scoprire e utilizzare capacità esposte da un server compatibile.

Un MCP Server per GitHub o WooCommerce può quindi continuare a utilizzare le normali API del servizio.

La relazione frequente è:

MCP → adapter → API

non:

MCP al posto dell’API

Se hai una sola applicazione e una singola integrazione deterministica, l’API diretta può essere la soluzione migliore.

MCP diventa più interessante quando la stessa capacità deve essere riutilizzabile da più host.

MCP vs function calling

Il function calling riguarda il rapporto tra modello e tool disponibili nel runtime.

MCP risponde a una domanda diversa:

da dove arrivano questi tool e come comunichiamo con il sistema che li offre?

Un sistema può quindi:

1. scoprire un tool tramite MCP;
2. mostrarlo al modello;
3. ricevere dal modello una tool call;
4. tradurla in tools/call;
5. ottenere il risultato dal server.

Le due tecnologie sono complementari.

MCP vs RAG

RAG, Retrieval-Augmented Generation, recupera informazioni pertinenti e le aggiunge al contesto del modello.

Il problema è:

quali informazioni servono per produrre una risposta migliore?

MCP è più generale.

Un Tool MCP può interrogare un sistema RAG. Una Resource può rappresentare una fonte utilizzata per il retrieval.

Ma MCP può anche permettere azioni completamente diverse, come creare un ticket o aggiornare un ordine.

RAG è un pattern di retrieval. MCP è un protocollo di interoperabilità.

Come possono convivere tutti nello stesso sistema

Immagina un assistente ecommerce.

Il modello usa tool calling.

I tool vengono scoperti da un MCP Server.

Il server interroga le API WooCommerce.

Un sistema RAG recupera parallelamente la documentazione aziendale sui resi.

Il modello combina dati dell’ordine e policy interne.

Non c’è contraddizione: ogni componente risolve uno strato differente dell’architettura.

Esempio completo: cosa succede quando l’AI interroga WooCommerce tramite MCP

Prendiamo uno scenario ipotetico:

“Controlla gli ordini di ieri e indicami quelli che potrebbero avere un problema.”

L’host possiede un MCP Client collegato a un server WooCommerce.

Il client recupera l’elenco dei tool disponibili.

Trova, per esempio:

list_orders

e:

get_order_details

Le definizioni vengono registrate tra gli strumenti disponibili al modello.

Il modello interpreta la richiesta e produce una tool call verso:

list_orders

passando la data richiesta.

L’host intercetta la tool call e individua il client che possiede quello strumento.

Il client invia al server:

tools/call → list_orders

Il server valida gli argomenti e usa le credenziali necessarie per interrogare WooCommerce.

WooCommerce restituisce gli ordini.

Il server normalizza i dati e restituisce il risultato attraverso MCP.

L’host passa il risultato al modello.

Se le informazioni sono sufficienti, il modello produce l’analisi.

Se servono dettagli su un ordine specifico, può chiedere:

get_order_details(order_id=...)

e il ciclo continua.

Tre confini diventano così evidenti:

il modello non deve possedere direttamente le credenziali WooCommerce;

il modello non effettua direttamente la chiamata HTTP;

MCP non decide da solo quali ordini siano problematici.

Queste responsabilità appartengono a componenti diversi del sistema.

Casi d’uso concreti degli MCP Server

MCP tende ad avere più valore quando vuoi rendere le stesse capacità riutilizzabili da più applicazioni AI o quando devi integrare molti sistemi eterogenei.

Sviluppo, repository e strumenti tecnici

Lo sviluppo software è uno degli scenari più naturali.

Un server può esporre tool per:

• repository;
• issue;
• documentazione;
• monitoraggio;
• testing;
• filesystem;
• infrastruttura.

Il vantaggio non consiste soltanto nel permettere all’AI di usare GitHub. Consiste nel presentare sistemi differenti attraverso un modello di interazione comune.

Database, analytics e sistemi aziendali

Un MCP Server può fornire accesso controllato a dati aziendali.

“Accesso al database” non significa però necessariamente concedere SQL arbitrario.

Può essere molto più sicuro esporre strumenti come:

get_revenue_by_month

list_unpaid_invoices

find_customer

get_campaign_performance

La business logic rimane nel server.

Ecommerce, marketing e automazione

In ecommerce MCP può collegare:

• ordini;
• catalogo;
• analytics;
• CRM;
• ticketing;
• customer care.

Nel marketing può rendere utilizzabili da più workflow dati provenienti da analytics, advertising, CRM e project management.

Se invece stai semplicemente automatizzando una chiamata API all’interno di un workflow fisso, MCP può aggiungere complessità senza un vantaggio proporzionato.

MCP per SEO: dove può avere senso e dove rischia di essere hype

In ambito SEO MCP potrebbe rendere disponibili a diversi workflow AI capacità come:

• interrogare Search Console;
• leggere dataset Analytics;
• utilizzare un crawler;
• controllare URL;
• recuperare dati SEO interni.

Questo non significa che “MCP migliori la SEO”.

MCP non è un ranking factor, non aumenta automaticamente la visibilità nelle risposte AI e non rende un sito più comprensibile a Google.

È un protocollo attraverso cui un’applicazione AI può utilizzare strumenti.

Se vuoi approfondire l’uso dell’intelligenza artificiale nei processi digitali oltre MCP, può essere utile mantenere questo contenuto collegato al cluster AI già presente su Creativemotions, senza trasformare il protocollo in una nuova tecnica SEO.

Dove trovare e come scegliere un MCP Server

L’ecosistema è cresciuto rapidamente, ma la scelta di un server non dovrebbe ridursi a installare il primo progetto che compare in una ricerca.

Official MCP Registry: discovery, non certificazione

Esiste un Official MCP Registry dedicato alla discovery dei server pubblicati nell’ecosistema.

È utile per individuare server e relativi metadata.

Non va però interpretato automaticamente come certificazione di sicurezza.

Trovare un server e decidere se fidarsi di quel server sono due processi distinti.

Server ufficiale del vendor o community server?

Quando il vendor del servizio mantiene un proprio MCP Server, quello è normalmente il primo candidato da valutare.

Riduce almeno un passaggio nella catena di fiducia.

Un progetto community può comunque essere valido e offrire più flessibilità o funzionalità.

Ma introduce un’altra domanda:

chi mantiene questo codice e quali privilegi gli sto concedendo?

Cosa controllare prima di collegarlo

Controllerei almeno:

• maintainer;
• repository e provenienza;
• frequenza degli aggiornamenti;
• dipendenze;
• tool esposti;
• permessi richiesti;
• dati accessibili;
• capacità di scrittura;
• gestione delle credenziali;
• scope;
• autenticazione;
• logging;
• servizi esterni contattati;
• possibilità di disabilitare tool inutili.

La domanda migliore non è:

“Qual è il server MCP più famoso?”

ma:

“Qual è il minimo insieme di capacità necessario per il mio caso d’uso?”

Sicurezza MCP: il problema non è solo fidarsi del server

MCP aumenta ciò che un’applicazione AI può fare.

Aumenta quindi anche l’impatto potenziale di una configurazione sbagliata.

La guida ufficiale MCP alle best practice di sicurezza tratta problemi specifici come confused deputy, token passthrough, SSRF, server locali compromessi e gestione degli scope.

Permessi e principio del minimo privilegio

Un server che deve leggere gli ordini non dovrebbe necessariamente poterli cancellare.

Un server che legge un repository non deve automaticamente poter fare push.

Il principio del minimo privilegio va applicato a:

• credenziali;
• scope OAuth;
• tool esposti;
• tool permessi dall’host;
• filesystem;
• rete;
• utente finale.

Più livelli di controllo impediscono che un singolo errore trasformi una capacità innocua in un’azione distruttiva.

Credenziali, token e API sottostanti

La documentazione MCP considera il token passthrough un anti-pattern.

Un server non dovrebbe prendere qualsiasi token ricevuto dal client e inoltrarlo ciecamente verso un servizio downstream.

Occorre verificare destinatario, audience e confini di autorizzazione.

Le credenziali non sono quindi un dettaglio implementativo secondario. Sono parte dell’architettura di sicurezza.

Server locali e codice esterno

Un server STDIO viene normalmente eseguito sul computer dell’utente.

Se possiede accesso a una directory, alle variabili d’ambiente o a chiavi API, quelle risorse diventano parte della superficie di rischio.

Locale non equivale a fidato.

Un MCP Server locale va trattato come qualsiasi altro software eseguito sul sistema.

Prompt injection e tool privilegiati

Il rischio aumenta quando un modello legge contenuti non affidabili e dispone contemporaneamente di strumenti che possono modificare sistemi esterni.

Una pagina web malevola potrebbe contenere istruzioni progettate per influenzare il comportamento del modello.

OpenAI avverte esplicitamente che server MCP non affidabili possono aumentare l’esposizione a rischi come la prompt injection e raccomanda di valutare attentamente le app prima della distribuzione.

Le difese devono quindi combinare:

• server affidabili;
• tool allowlist;
• scope limitati;
• separazione dei contenuti non fidati;
• approvazioni;
• logging;
• validazione;
• policy applicative.

Human approval e azioni con side effect

Leggere un ordine e cancellarlo non hanno lo stesso rischio.

Per azioni che modificano lo stato, l’host può richiedere una conferma esplicita.

ChatGPT, per esempio, può richiedere conferma per determinate azioni di scrittura in base a permessi, contesto e impatto dell’operazione. Alcune azioni ad alto rischio possono essere bloccate invece di essere semplicemente sottoposte ad approvazione.

MCP funziona con ChatGPT, Claude e Gemini?

Sì. MCP non è limitato all’ecosistema Anthropic.

Il supporto concreto cambia però tra prodotto, API, piano e modello.

ChatGPT

Ad agosto 2026 OpenAI documenta supporto MCP completo, comprese azioni di modifica e scrittura, in beta per ChatGPT Business, Enterprise ed Edu sul web. I Pro possono utilizzare MCP in developer mode con permessi read/fetch, mentre il full MCP rimane attualmente limitato ai piani indicati. ChatGPT collega direttamente server remoti; per server privati o locali OpenAI documenta Secure MCP Tunnel.

Per il contesto generale sul prodotto puoi collegare questa sezione alla guida Creativemotions su ChatGPT 5.

Claude

Anthropic offre un connector MCP per la Messages API che permette di collegare server remoti e configurare allowlist o denylist dei singoli tool.

La documentazione corrente precisa però che il connector server-side supporta le chiamate ai Tools e richiede un server esposto tramite HTTP; i server STDIO locali non vengono collegati direttamente attraverso questo meccanismo.

Sul sito puoi approfondire anche Claude AI come prodotto separato dal protocollo.

Gemini

Google documenta Remote MCP nella Interactions API.

Il collegamento avviene verso server MCP remoti Streamable HTTP. La documentazione corrente specifica inoltre che i server SSE legacy non sono supportati in questa integrazione.

Per il quadro generale dell’ecosistema Google AI puoi mantenere il collegamento interno alla guida su Google Gemini.

Il punto da ricordare è questo:

MCP è uno standard comune, ma ogni host decide quali parti implementare e con quali limiti.

Prima di progettare un’integrazione bisogna quindi controllare la documentazione corrente del prodotto scelto.

Quando MCP conviene e quando complica inutilmente il progetto

MCP ha senso quando risolve un problema reale di interoperabilità.

Non è una tecnologia obbligatoria semplicemente perché nel progetto è presente un LLM.

Quando MCP è una buona scelta

Lo valuterei quando:

• la stessa integrazione deve essere riutilizzata da più applicazioni AI;
• vuoi poter cambiare host mantenendo i server;
• devi combinare molti sistemi;
• vuoi discovery standardizzata;
• vuoi separare orchestrazione AI e connettori;
• costruisci una capacità destinata a più client MCP;
• l’architettura deve essere modulare.

Quando una API diretta basta

MCP può invece essere superfluo se hai:

• una sola applicazione;
• una sola API;
• workflow deterministico;
• nessuna discovery;
• nessuna necessità di riuso.

Se il flusso è semplicemente:

evento → API → risultato

un’integrazione diretta può essere più leggibile e più semplice da mantenere.

Matrice decisionale: MCP, API, function calling o RAG?

Se il problema è…	Tecnologia da valutare per prima	Perché
Collegare direttamente due sistemi conosciuti	API	È il contratto più diretto
Permettere al modello di scegliere una funzione	Function calling	Gestisce il tool use lato modello/runtime
Recuperare documenti pertinenti	RAG	È progettato per retrieval + context
Riutilizzare tool tra più applicazioni AI	MCP	Standardizza discovery e interoperabilità
Usare un’API esistente da più host AI	MCP + API	MCP espone, l’API esegue
Esporre retrieval attraverso un server comune	MCP + RAG	MCP rende riutilizzabile la capacità
Usare tool MCP scelti dal modello	MCP + tool/function calling	Sono due livelli complementari

La scelta dipende quindi da dove si trova la complessità reale del sistema.

Domande frequenti sugli MCP Server

Un MCP Server contiene un modello AI?

Non necessariamente.

Di norma espone capacità e dati. Il modello vive nell’host o nel servizio AI utilizzato dall’applicazione.

Un MCP Server è un normale server web?

Non necessariamente.

Un server remoto può usare HTTP, ma un MCP Server può essere anche un processo locale STDIO.

MCP funziona senza Internet?

Sì, se host, server, modello e risorse funzionano localmente.

Se il modello utilizza API cloud o il server deve contattare servizi online, servirà naturalmente una connessione.

Un MCP Server può modificare dati?

Sì, se espone Tool che hanno quella capacità e possiede i relativi permessi.

Per questo bisogna distinguere attentamente strumenti read-only e strumenti con side effect.

MCP sostituirà le API?

Probabilmente non è questo il suo ruolo.

Molti MCP Server continuano a utilizzare API come sistema sottostante.

MCP risolve soprattutto il problema di rendere quelle capacità scopribili e interoperabili tra applicazioni AI.

MCP Server: lo standard conta meno dei confini che definisci

MCP rende più semplice costruire applicazioni AI capaci di utilizzare strumenti e dati differenti attraverso un contratto comune.

Ma standardizzare l’accesso non rende automaticamente sicuro ciò a cui stai accedendo.

Un buon MCP Server espone capacità precise, input comprensibili e privilegi limitati.

Un server progettato male può invece trasformare una comoda integrazione in una superficie di rischio molto ampia.

La domanda decisiva non è quindi:

“Quanti MCP Server posso collegare?”

ma:

“Quali capacità deve davvero avere questa applicazione AI per svolgere il proprio lavoro?”

Se devi riutilizzare strumenti tra molti host, combinare diversi sistemi e mantenere separato il livello AI dalle integrazioni, MCP può ridurre significativamente la frammentazione.

Se devi fare una singola chiamata deterministica verso una sola API, probabilmente non ti serve.

Il valore del Model Context Protocol sta proprio qui: non nel concedere più potere possibile al modello, ma nel creare un modo standard e governabile per concedergli solo quello necessario.