“MCP vs API” sembra una scelta tra due tecnologie concorrenti. In realtà, però, fanno parte dello stesso stack. Un’API espone le funzionalità di un sistema. Un server MCP può quindi rendere disponibili determinate funzionalità alle applicazioni IA, indipendentemente dal fatto che tali funzionalità provengano da un’API, da un database, da file locali o da un’altra fonte.
Il confronto, quindi, non verte sul fatto che l’MCP sostituirà le API o su come queste differiscano intrinsecamente. Si tratta piuttosto di capire cosa offre ciascun livello, dove ciascuno di essi aggiunge complessità e quando l’utilizzo di entrambi abbia più senso rispetto alla scelta di uno solo.
“MCP vs API” sembra una scelta tra due tecnologie concorrenti. In realtà, però, fanno parte dello stesso stack. Un’API espone le funzionalità di un sistema. Un server MCP può quindi rendere disponibili determinate funzionalità alle applicazioni IA, indipendentemente dal fatto che tali funzionalità provengano da un’API, da un database, da file locali o da un’altra fonte.
Il confronto, quindi, non verte sul fatto che l’MCP sostituirà le API o su come queste differiscano intrinsecamente. Riguarda piuttosto ciò che ciascun livello offre, dove ciascuno di essi aggiunge complessità e quando l’utilizzo di entrambi ha più senso rispetto alla scelta di uno solo.
TL;DR
La scelta tra MCP e API dipende da chi è il chiamante. Un’API è la soluzione più indicata quando è il codice a controllare il percorso, la sequenza è nota e si desiderano chiamate dirette e verificabili. L’MCP è la soluzione più indicata quando un sistema IA deve scegliere tra le azioni disponibili man mano che la richiesta cambia.
La maggior parte dei team che sviluppano prodotti basati sull’IA distribuiranno entrambe le soluzioni. L’API rimane l’interfaccia completa per gli sviluppatori. Il server MCP espone un sottoinsieme più ristretto e ben definito che gli agenti possono individuare e richiamare autonomamente. Nessuna delle due sostituisce l’altra; servono utenti diversi della stessa funzionalità.
Un aspetto da valutare prima di commit: MCP comporta un costo di token per ogni chiamata, indipendentemente dal fatto che venga utilizzato o meno uno strumento. I benchmark condotti su cinque famiglie di modelli mostrano che un server con 26 strumenti aggiunge circa 0,03 $ a ogni richiesta su Claude Opus, ma solo 0,003 $ su Gemini Flash, con un divario di 10 volte a seconda del modello. Tale overhead è recuperabile tramite la cache, ma ciò significa che il profilo di costo di MCP è una variabile di progettazione, non una costante.
MCP vs API: una panoramica
| Funzionalità/Funzione | API | MCP |
|---|---|---|
| Caso d'uso principale | Collegare i software tramite interfacce programmatiche definite | Collega le applicazioni di IA a strumenti, dati e sistemi esterni |
| Chi controlla il flusso | Di solito è la logica dell’applicazione a decidere cosa viene chiamato | Un host basato sull’IA può scegliere tra le funzionalità esposte in fase di esecuzione |
| Discovery | L’integrazione inizia solitamente con endpoint o schemi noti | Il client può chiedere al server quali funzionalità sono disponibili |
| Lavoro richiesto per l’integrazione | Spesso varia a seconda del provider, del modello di autenticazione, dello schema e dello stile dell’API | Utilizza un unico protocollo su server e client compatibili con MCP |
| Orchestrazione | Solitamente progettato e gestito nel codice dell’applicazione | Alcune decisioni possono essere trasferite all’host o all’agente IA |
| Determinismo | Più adatto a percorsi di chiamata fissi che devono essere facili da testare e riprodurre | La selezione dello strumento può variare quando un modello decide quale azione intraprendere |
| Prestazioni e costi | Le chiamate dirette evitano un'ulteriore inferenza del modello | L'uso agentico può aumentare il tempo di inferenza e il costo in token |
| Modello di sicurezza | Le autorizzazioni e i percorsi di chiamata vengono solitamente applicati nella logica dell’applicazione | Richiede gli stessi controlli, oltre a misure di sicurezza relative all’uso di strumenti basati su modelli |
| Possono svolgere il lavoro da soli? | Sì | Sì, anche se i server MCP spesso mettono a disposizione funzionalità supportate da API o sistemi esistenti |
| Dove si esaurisce | Le integrazioni tra diversi provider possono richiedere schemi, procedure di autenticazione e logiche di orchestrazione differenti | L'assistenza client varia, i cataloghi di strumenti di grandi dimensioni richiedono una gestione del contesto e la specifica è ancora in evoluzione |
Che cos’è l’MCP?
L’MCP, o Model Context Protocol, è uno standard aperto che offre alle applicazioni di IA un metodo condiviso per individuare e utilizzare strumenti, dati e servizi esterni.
Come funziona l’MCP
Anziché codificare in modo rigido ogni azione possibile, un client MCP può chiedere a un server in connessione quali servizi offre. Il server restituisce un catalogo di strumenti con nomi, descrizioni e schemi di input. Il modello di IA può quindi decidere quale strumento si adatta alla richiesta dell’utente.
Da notare: gli strumenti sono la parte di MCP che più si avvicina alle azioni delle API. Tuttavia, i server MCP possono anche esporre risorse, come file o record di database, e prompt, ovvero istruzioni o modelli riutilizzabili che un’applicazione di IA può richiedere.
Il rilevamento in fase di esecuzione è uno dei principali vantaggi dell’MCP. Anziché dover apprendere un modello di integrazione diverso per ogni servizio, il client dispone di un unico metodo standard per individuare le funzionalità offerte da un server e richiamarle quando necessario.
Anthropic ha introdotto l’MCP nel novembre 2024 e lo ha donato all’Agentic IA Foundation, facente parte della Linux Foundation, nel dicembre 2025.
Per cosa è più indicato l’MCP
L’MCP è la scelta più sensata quando un assistente o un agente IA deve accedere a diversi strumenti e deve decidere quale utilizzare in fase di esecuzione.
Destinatari: agenti IA, assistenti alla programmazione, copiloti interni e sistemi che devono operare su diversi strumenti in continua evoluzione.
Da ignorare se: la tua applicazione richiede solo un numero limitato di integrazioni fisse e il flusso di lavoro è già noto in anticipo.
Che cos’è un’API?
Un’API (Application Programming Interface) è un contratto pubblicato. Un provider si impegna a garantire una serie di operazioni, la forma di ciascuna richiesta e il risultato restituito. Il codice legge quel contratto una volta sola e lo richiama sempre nello stesso modo.
Come funzionano le API
In genere, uno sviluppatore legge la documentazione dell’API, sceglie un endpoint, definisce i parametri richiesti e scrive il codice che effettua la richiesta.
Ad esempio, un’applicazione potrebbe chiamare un endpoint per creare un’attività e un altro per recuperare la scheda di un cliente. L’applicazione sa già quale endpoint utilizzare perché tale logica è stata integrata nel software.
Da notare: il termine “API” comprende diversi stili incompatibili tra loro. REST organizza le operazioni attorno alle risorse e ai verbi HTTP. GraphQL espone un unico endpoint e consente al chiamante di specificare i campi desiderati. gRPC utilizza payload binari su HTTP/2 per le chiamate da servizio a servizio in cui la latenza è un fattore critico.
Ciò che più si avvicina a uno standard descrittivo condiviso è OpenAPI, che molti provider pubblicano e molti altri no. Ciò di cui le API dispongono sono circa due decenni di strumenti accumulati: gateway, test dei contratti, tracciamento distribuito, convenzioni di versioning e infrastrutture di limite di frequenza che la maggior parte dei team di ingegneri già utilizza. MCP sta ancora mettendo insieme il suo equivalente.
Quali sono le API più adatte per
Le API funzionano bene quando l’applicazione necessita di un accesso prevedibile a un servizio noto e gli sviluppatori desiderano avere il controllo diretto su cosa viene chiamato e quando.
Ideato per: integrazioni backend, pipeline di dati, app web e mobili e flussi di lavoro con azioni fisse.
Salta questo articolo se: stai sviluppando un sistema IA che deve individuare e scegliere dinamicamente tra numerosi strumenti.
MCP vs API: quali sono le principali differenze?
Sia un’API che un MCP espongono delle azioni, ma gestiscono la connessione in modo diverso. Le API partono da un’operazione nota. L’MCP parte da una domanda: cosa è disponibile? Da ciò derivano tre differenze, e nessuna di esse riguarda quale interfaccia sia migliore. Riguardano piuttosto quale interfaccia gestisca quale chiamante.
Le API partono da un’operazione nota
Con un’API, l’applicazione sa già di quale endpoint ha bisogno. Uno sviluppatore definisce la richiesta, imposta i parametri e scrive cosa succede con la risposta.
Ciò rende le API particolarmente adatte ai flussi di lavoro fissi. Una volta che un pagamento viene accreditato, il sistema crea una fattura. Il percorso della chiamata viene scritto una volta, testato e riutilizzato ogni volta.
Con MCP, il percorso rimane aperto. Un client in connessione verifica quali strumenti espone un server, quindi li rende disponibili al sistema di IA. L’azione successiva dipende dalla richiesta dell’utente, non da un flusso prestabilito.
Il livello di interfaccia funziona in modo diverso
Le API assumono forme diverse. Un provider utilizza REST, un altro GraphQL, mentre un altro ancora si affida a un SDK. Autenticazione, errori, impaginazione e formati delle richieste variano da un servizio all’altro.
L’MCP offre ai client IA un unico protocollo per effettuare la connessione ai server e leggere ciò che questi espongono. Ciò non rende tutti gli strumenti identici. Due server possono comunque denominare o progettare azioni simili in modo diverso. Tuttavia, il client non ha bisogno di un protocollo diverso per ciascuno di essi.
Il contesto dello strumento modifica il modo in cui il modello effettua la scelta
Esiste una descrizione dell’API per gli sviluppatori e il loro codice. L’applicazione sa cosa chiamare prima ancora che la richiesta abbia inizio.
Con MCP, i nomi degli strumenti, le descrizioni e gli schemi di input vengono passati nel contesto di lavoro del modello. Il modello legge tali informazioni, decide quale azione sia adeguata alla richiesta e inserisce gli argomenti.
Un ambito in cui questa differenza diventa visibile è quello dei flussi di lavoro degli agenti, dove il sistema potrebbe dover scegliere l’azione successiva in base alla richiesta piuttosto che seguire una sequenza fissa.
Come scegliere tra MCP e un'API
Scegliere tra MCP e un’API in base al modo in cui la funzionalità deve essere resa disponibile. Le API funzionano bene quando l’applicazione sa già quale servizio o operazione chiamare. L’MCP è utile quando un’applicazione IA necessita di un metodo standard per individuare e utilizzare le funzionalità su diversi sistemi in fase di esecuzione.
Scegliere un’API quando
- Il codice è il consumatore e nessun modello deve scegliere l’azione
- L’operazione segue un percorso fisso e controllato in cui il giudizio del modello aggiunge poco valore, come l’elaborazione dei pagamenti, la gestione delle buste paga o la presentazione di reportistica normativa
- Si stanno trasferendo grandi volumi di record attraverso una pipeline prevedibile, dove gli strumenti convenzionali di automazione dei processi rappresentano la soluzione più semplice
- Il fornitore espone una funzionalità tramite la propria API, ma non l’ha ancora resa disponibile nel proprio server MCP
Scegliere MCP quando
- L’assistente o l’agente IA è il chiamante, mentre gli utenti esprimono le attività in linguaggio naturale
- La sequenza delle azioni varia da una richiesta all’altra, come nei flussi di lavoro multi-agente
- Si desidera che un unico server funzioni con più client compatibili con MCP senza dover realizzare un’integrazione separata per ciascuno di essi
- Si desidera rendere disponibili gli strumenti tramite uno schema comune che più client di IA compatibili con MCP possano individuare e richiamare
Utilizzarle entrambe quando: sei un fornitore al servizio di sviluppatori e agenti IA. Mantieni l’API come interfaccia programmatica completa, quindi esponi un insieme più ristretto di funzionalità sicure per gli agenti tramite MCP.
I limiti delle API
Le API presentano dei limiti perché ogni integrazione è personalizzata, non sono in grado di adattarsi quando gli utenti richiedono qualcosa che lo sviluppatore non ha scritto nel codice, i flussi di lavoro multiservizio lasciano a te l’intero carico dell’orchestrazione e la qualità della documentazione varia da un provider all’altro.
- Ogni nuova integrazione è un lavoro personalizzato. Ogni API ha il proprio schema di autenticazione, la propria struttura di richiesta/risposta, il proprio formato di errore e i propri limiti di frequenza. Collegare dieci servizi significa scrivere e mantenere dieci integrazioni separate. Il rapporto “State of the API” di Postman, basato su un sondaggio condotto su oltre 5.700 sviluppatori e architetti, ha rilevato che il 69% dedica ora più di 10 ore alla settimana al lavoro con le API. Questo costo aumenta con ogni strumento che si aggiunge
- Nessuna flessibilità in fase di esecuzione. Un’integrazione API può fare solo ciò che uno sviluppatore ha già implementato. Se un utente richiede qualcosa che il codice non è in grado di gestire, la richiesta viene bloccata finché qualcuno non implementa una nuova logica. Per i prodotti basati sull’IA, in cui l’intento dell’utente varia a ogni richiesta, tale rigidità diventa un collo di bottiglia
- L'onere dell'orchestrazione ricade su di te. Quando un flusso di lavoro coinvolge più API, la tua applicazione deve comunque gestire l'ordine delle chiamate, trasferire i dati tra i servizi, gestire gli errori e i tentativi di ripristino e tenere traccia dello stato. I motori di flusso di lavoro e le piattaforme di integrazione possono ridurre parte di questo carico di lavoro, ma la logica di orchestrazione sottostante deve comunque essere progettata e mantenuta
- La qualità della documentazione varia enormemente. Alcune API sono accompagnate da documenti interattivi, log delle modifiche con versione e ambienti sandbox. Altre ti forniscono un PDF del 2019. La mancanza di uno standard universale di descrizione significa che ogni integrazione inizia con una fase di analisi.
Leggi anche: I migliori connettori Claude MCP per il marketing
I limiti dell’MCP
I principali limiti dell’MCP sono la complessità del debug, le descrizioni degli strumenti che possono non essere più in sincronia con il comportamento del server, la mancanza di un registro universale dei server e i modelli di credenziali che non sono stati standardizzati per l’uso nell’azienda.
- Il debug è più complesso. Quando una chiamata diretta all’API fallisce, si ottiene un codice di stato e un corpo dell’errore. Quando una chiamata a uno strumento MCP fallisce, l’errore potrebbe risiedere nel ragionamento del modello, nello schema dello strumento, nella risposta del server o nell’interpretazione che il client dà di tutti e tre questi elementi. Gli strumenti di osservabilità per le tracce specifiche dell’MCP sono limitati rispetto a quelli esistenti per REST
- Le descrizioni degli strumenti possono discostarsi dal comportamento effettivo senza causare alcun malfunzionamento. Un server MCP può rinominare un parametro, restringere un’enumerazione o ristrutturare una risposta, restituendo comunque un JSON valido. Il modello continua a chiamare lo strumento; la chiamata continua a “funzionare”, ma il risultato è errato. Uno studio condotto su 10.831 server MCP ha rilevato che il 73% presenta nomi di strumenti ripetuti e 3.093 non dispongono di descrizioni dei valori di ritorno, ampliando il divario nella selezione degli strumenti fino a 52 punti percentuali nei confronti diretti tra server ben descritti e server descritti in modo inadeguato
- Nessun registro universale. Non esiste un metodo standard per individuare i server MCP esistenti o per verificarne la qualità. Le directory della comunità sono in crescita, ma la verifica di un server di terze parti richiede ancora un’ispezione manuale dei metadati e delle autorizzazioni dello strumento.
- La gestione delle credenziali non segue un modello standard. La specifica supporta OAuth 2.1 per i server remoti, ma molti server della comunità richiedono ancora che le chiavi API vengano passate come variabili d’ambiente. Se si effettuano cinque connessioni a server MCP, si gestiscono cinque flussi di credenziali separati senza un vault condiviso, una politica di rotazione o una traccia di audit. Stanno emergendo strumenti aziendali dedicati a questo scopo, ma nulla è ancora standardizzato.
Nessuna di queste situazioni è definitiva. Le specifiche evolvono rapidamente e gli strumenti stanno recuperando terreno. Tuttavia, se state valutando l’utilizzo di MCP per un’implementazione in produzione oggi, progettate tenendo conto di questi vincoli, piuttosto che dare per scontato che scompariranno entro il lancio.
Chiamata allo strumento MCP vs. richiesta diretta all’API
Una richiesta API viene inviata direttamente a un endpoint noto con parametri fissi definiti in anticipo dal codice. Una chiamata tramite strumento MCP racchiude la stessa azione in un involucro JSON-RPC che un modello di IA seleziona in fase di esecuzione dopo aver letto il catalogo degli strumenti del server. Il server MCP esegue quindi la chiamata API sottostante per conto del modello.
Ecco come funziona la “creazione di un’attività in ClickUp” attraverso ogni livello.
Tramite l’API
La tua applicazione conosce già l’ID dell’elenco, l’assegnatario e l’endpoint esatto. Lo chiama direttamente.
La risposta viene restituita con l’oggetto dell’attività creata. Non è stato coinvolto alcun modello. Lo sviluppatore ha scritto la logica, ha scelto l’endpoint e ha gestito il risultato.
Tramite MCP
Un client AI si connette al server MCP di ClickUp e chiede quali strumenti siano disponibili:
Il modello legge lo schema, stabilisce che `create_task` corrisponde alla richiesta dell’utente e restituisce argomenti strutturati:
Viene creata la stessa attività. Il server MCP continua a richiamare l’API REST di ClickUp in background per eseguirla.
Cosa è effettivamente diverso
Il risultato è identico. Ciò che è cambiato è chi ha preso la decisione.
Con l’API, il codice conosceva l’endpoint prima dell’avvio della richiesta. Con l’MCP, il modello legge un catalogo di strumenti in fase di esecuzione e sceglie create_task tra oltre 40 strumenti disponibili in base a ciò che l’utente ha richiesto in linguaggio naturale.
Nessuno dei due approcci è migliore in termini assoluti. L’API è più veloce, più economica e deterministica. L’MCP è flessibile, facilmente individuabile e progettato per chi effettua le chiamate utilizzando il linguaggio naturale.
Leggi anche: Come scrivere la documentazione di un'API
L’MCP è con stato o senza stato?
A partire dalla specifica del 28 luglio 2026, il nucleo del protocollo MCP è stateless. La distinzione su cui si basavano i confronti precedenti (REST è stateless, MCP mantiene una sessione) descrive ora un protocollo di trasporto deprecato.
Il vecchio handshake “initialize” e l’intestazione “Mcp-Session-Id” sono stati eliminati. Ogni richiesta contiene la propria versione del protocollo, l’identità del client e le funzionalità. Qualsiasi chiamata può essere indirizzata a qualsiasi istanza di server dietro un semplice bilanciatore di carico round-robin. Nessun routing sticky, nessuna memorizzazione condivisa delle sessioni.
La specifica inserisce inoltre i nomi dei metodi e degli strumenti nelle intestazioni HTTP. I gateway, i limitatori di frequenza e i firewall per applicazioni web (WAF) possono ora instradare o misurare il traffico MCP senza dover prima analizzare il corpo JSON.
Quando sono ancora necessari più scambi, MCP offre due modelli. Le richieste Multi-Round-Trip gestiscono scambi leggeri all’interno di una singola chiamata. L’estensione Tasks gestisce le operazioni di lunga durata: il server restituisce un handle di attività persistente e, se ha bisogno di ulteriori informazioni durante l’esecuzione, si mette in pausa con lo stato “input_required” finché il client non fornisce l’input mancante. Il comportamento legacy con stato è in fase di migrazione, mentre Roots, Sampling e Logging (tre funzionalità/funzioni precedenti che consentono ai server di richiedere informazioni al client) sono state deprecate separatamente, con un periodo di almeno 12 mesi prima della loro rimozione.
Quindi la presenza o meno di uno stato non è più la linea di demarcazione. La differenza che rimane si colloca al di sopra del livello di trasporto: un’API si affida alla logica scritta dagli sviluppatori per determinare cosa viene chiamato. L’MCP consente al modello di IA di individuare e, nella maggior parte dei casi, scegliere autonomamente.
Qual è la differenza tra MCP e la chiamata di funzione?
La chiamata di funzioni è una funzionalità del modello. MCP è uno standard di individuazione e trasporto che la supporta. La chiamata di funzioni consente a un modello di emettere una richiesta strutturata per invocare una funzione definita nel proprio codice. MCP standardizza la provenienza di tali definizioni, il modo in cui un client le recupera da un server in fase di esecuzione e il funzionamento dell’autorizzazione. Un modello utilizza la chiamata di funzioni per agire sugli strumenti forniti da MCP.
La chiamata alle funzioni (nota anche come “uso degli strumenti”) è integrata nelle API dei modelli di OpenAI, Anthropic e Google. Si definisce un insieme di funzioni, se ne passano gli schemi al modello e quest’ultimo restituisce argomenti strutturati quando ritiene che uno di essi sia pertinente. Spetta comunque all’utente scegliere quali funzioni offrire, scrivere il codice di esecuzione e gestire la risposta. Il modello sceglie quale funzione chiamare. Il codice dell’utente si occupa del resto.
MCP opera a un livello superiore. Standardizza il modo in cui un client IA rileva quali funzioni sono disponibili, su più server, senza necessità di hardcoding da parte vostra. Il server pubblicizza i propri strumenti. Il client li legge in fase di esecuzione. Il modello utilizza quindi la chiamata di funzione per invocare quella che sceglie.
In parole semplici: la chiamata di funzione è il modo in cui un modello dice: «Voglio chiamare questo strumento con questi argomenti». L’MCP è ciò che indica al modello quali strumenti sono disponibili per la chiamata.
La maggior parte dei client compatibili con MCP esegue entrambi contemporaneamente. Essi recuperano gli schemi degli strumenti dal server MCP, li formattano come definizioni di funzione per il modello e reindirizzano l’output strutturato del modello attraverso MCP per l’esecuzione. I due costituiscono livelli dello stesso stack, quindi solitamente li vedrete operare in sequenza su una singola richiesta.
L’MCP è più lento o più costoso di un’API?
Sì, l’MCP è sia più lento che più costoso di una chiamata diretta all’API. L’MCP inserisce un modello di IA all’interno del ciclo di richiesta, il che comporta un ritardo aggiuntivo e costi relativi ai token. Le API dirette inviano le richieste direttamente a un endpoint, mentre l’MCP richiede un LLM per selezionare, eseguire e interpretare gli strumenti in modo dinamico.
Perché MCP è più lento
- Ritardo di inferenza: le chiamate API dirette vengono completate in pochi millisecondi. L’MCP costringe il modello ad analizzare un prompt, scegliere lo strumento giusto, eseguire la richiesta ed elaborare i risultati
- Cicli degli agenti: i cicli degli agenti a più passaggi moltiplicano questo ritardo di esecuzione su diversi passaggi sequenziali
Perché l’MCP è più costoso
- Overhead dello schema del prompt: MCP richiede l’aggiunta di descrizioni degli strumenti nel prompt di sistema. Ciò aggiunge migliaia di token a ogni richiesta
- Utilizzo dei token: le chiamate API dirette non consumano token di inferenza del modello, mentre MCP utilizza token a pagamento per la formattazione dei parametri e i riepiloghi/riassunti dei risultati
Utilizzate le API dirette per le attività prevedibili delle app che richiedono risposte rapide e costi contenuti.
Utilizzate MCP quando sviluppate agenti IA flessibili che devono scegliere le azioni in modo dinamico durante una conversazione.
L’MCP è meno sicuro di un’API?
Non di per sé. L’MCP presenta gli stessi requisiti di sicurezza di qualsiasi API: autenticazione, autorizzazione, autorizzazioni con ambito limitato e convalida degli input. La differenza sta in chi decide cosa viene chiamato.
| Area sicurezza | API | MCP |
|---|---|---|
| Autenticazione e autorizzazioni | Obbligatorio | Obbligatorio |
| Chi effettua la selezione dell’azione | Codice dell’applicazione | Potrebbe trattarsi di un modello IA |
| Inserimento del prompt | Non è una caratteristica intrinseca dell’API | Può influire sulla selezione degli strumenti e sull’esecuzione |
| Metadati dello strumento | Descrive l’interfaccia | Può influenzare il comportamento del modello |
| Rischio legato all’utilizzo di più strumenti | Limitato alle integrazioni programmate | Gli agenti possono combinare strumenti e origini dati in modo dinamico |
Vale la pena menzionare due rischi:
Avvelenamento dello strumento. Un server MCP malevolo restituisce istruzioni nascoste all’interno della risposta di uno strumento. Il modello considera tale risposta come contesto attendibile e segue le istruzioni incorporate. L’OWASP classifica questo fenomeno come iniezione indiretta di prompt contro agenti connessi tramite MCP. Funziona perché le descrizioni degli strumenti vengono verificate una sola volta al momento della connessione, mentre le risposte degli strumenti hanno un flusso diretto nel contesto del modello in fase di esecuzione senza alcun controllo equivalente.
La «tripletta letale». È una definizione di Simon Willison. Indica un agente con accesso a dati privati che consuma contenuti non attendibili ed è in grado di comunicare con l’esterno. Combinando tutti e tre questi elementi, l’iniezione di prompt diventa una via per l’esfiltrazione dei dati. MCP rende facile realizzare questa combinazione perché gli utenti collegano strumenti provenienti da più fonti.
La questione pratica non è se l’MCP sia “sicuro”. Si tratta piuttosto di capire se avete limitato ciò che il modello può vedere, scegliere ed eseguire, non solo ciò che il codice può richiamare.
Per le implementazioni MCP:
- Considerare i server di terze parti come input non attendibili, sia per quanto riguarda i metadati dei loro strumenti che per ogni risposta da essi restituita
- Limitare l’ambito di ciascuno strumento alle autorizzazioni minime necessarie
- Richiedere l’approvazione prima di azioni sensibili o irreversibili
- Non combinare mai dati privati, input non attendibili e accesso in uscita senza restrizioni in un unico agente
Come ClickUp utilizza sia MCP che le API
ClickUp è un esempio del modello «costruire entrambi» che abbiamo descritto finora.
L’API di ClickUp è l’interfaccia completa per gli sviluppatori. I team la utilizzano per creare connessioni personalizzate, effettuare la sincronizzazione dei dati tra i sistemi ed eseguire flussi di lavoro con controllo diretto su ogni richiesta.
Il server MCP di ClickUp rende disponibili molte di queste stesse azioni tramite MCP. I client basati sull’intelligenza artificiale come Claude Code, Cursor e ChatGPT possono connettersi, individuare gli strumenti ClickUp disponibili e richiamarli tramite prompt in linguaggio naturale. Ciò include la creazione di attività, la ricerca in un’area di lavoro, la gestione dei documenti, la pubblicazione di commenti e la registrazione del tempo lavorato.
Il livello di IA rivolto all’utente si trova al di sopra di tutto ciò. ClickUp Brain ricava il contesto dalle attività, dai documenti, dalla chat e da altre attività lavorative.
Inoltre, i Super Agent di ClickUp utilizzano tale contesto per prendere decisioni ed eseguire autonomamente flussi di lavoro in più passaggi. È possibile assegnare loro attività, inviare messaggi e consentire loro di agire all’interno di un’area di lavoro.
Questo conferisce a ClickUp tre livelli. L’API è destinata agli sviluppatori che desiderano un accesso completo. L’MCP offre ai client di IA esterni un modo standard per individuare e utilizzare gli strumenti di ClickUp. Brain e Super Agents integrano il ragionamento basato sull’IA nel prodotto stesso.
Naturalmente, ClickUp ti permette anche di effettuare la connessione agli altri tuoi strumenti tramite i propri server MCP. Non è necessario alcun lavoro sull’API.
I limiti: il server MCP è ancora in versione beta pubblica e non espone l’intera superficie API. Se lo strumento di cui avete bisogno non è disponibile, o se il vostro flusso di lavoro richiede il controllo diretto su ogni singola richiesta, l’API rappresenta la soluzione migliore.
Smettiamo di confrontare i protocolli di trasporto e iniziamo a confrontare gli utenti
MCP e API non sono standard concorrenti, e le differenze più citate sono proprio quelle che si sono superate più rapidamente.
Ciò che rimane è una vera e propria scelta architettonica. Un’API è un contratto per gli sviluppatori. Un server MCP è un contratto per i modelli, il che lo rende al tempo stesso un prompt, un token e una superficie di attacco.
Progettate di conseguenza. Mantenete l’API come vostra spina dorsale deterministica. Quindi decidete, strumento per strumento, cosa è consentito fare a un agente senza la presenza di un essere umano nella stanza, e pubblicate solo quello. Valutate quanto vi costa il catalogo nel contesto specifico e partite dal presupposto che ogni descrizione e ogni risposta dello strumento siano controllate da un aggressore fino a quando non avrete verificato il contrario.
Che tu scelga l’API o l’MCP, ClickUp funziona con entrambe. Inizia a utilizzare ClickUp gratis.
Domande frequenti su MCP e API
Il formato di trasmissione è JSON-RPC 2.0 su HTTP, volutamente semplice. Il valore risiede nel catalogo standardizzato delle funzionalità, negli schemi degli strumenti e nel modello di autorizzazione che vi si basano. In base alla specifica di luglio, ogni richiesta è autodescrittiva e stateless, con il nome del metodo e dello strumento trasportati nelle intestazioni HTTP in modo che i gateway possano instradare la richiesta senza analizzare il corpo del messaggio. Un’unica integrazione ora supporta Claude, ChatGPT, Cursor, Gemini e Copilot senza bisogno di soluzioni di integrazione personalizzate per ciascuno di essi.
ClickUp dispone sia di un'API che di un server MCP?
Sì. ClickUp offre un'API REST con una specifica OpenAPI per integrazioni deterministiche e basate sul codice, oltre a un server MCP separato (beta pubblica) che consente ad assistenti come Claude, ChatGPT e Cursor di interagire con i dati dell'area di lavoro utilizzando il linguaggio naturale. L'interfaccia MCP è un sottoinsieme deliberato dell'API, pertanto qualsiasi operazione al di fuori di essa utilizza comunque l'API REST. È disponibile su tutti i piani.
Claude Desktop, Claude Code, ChatGPT (piani a pagamento, inclusi Plus, Pro, Business ed Enterprise), Cursor, GitHub Copilot, VS Code (tramite l’estensione Copilot), Gemini, Windsurf e Microsoft Copilot Studio supportano tutti l’MCP a partire dalla metà del 2026. OpenAI, Google, Microsoft e diverse altre aziende hanno aderito all’Agentic AI Foundation della Linux Foundation, che ne governa le specifiche. Il supporto da parte dei client è ampio ma disomogeneo: non tutti i client supportano tutte le funzionalità MCP (ad esempio, le risorse e i prompt sono in ritardo rispetto alle chiamate agli strumenti).
Sì, e il wrapping di un’API esistente è l’approccio più comune. Il server esegue l’autenticazione presso l’API, mappa un insieme selezionato di endpoint agli strumenti e pubblica nomi, descrizioni e schemi JSON per ciascuno di essi. Evitate di mappare ogni singolo endpoint. Ogni descrizione dello strumento entra nel contesto del modello ad ogni turno, quindi un catalogo di grandi dimensioni comporta un costo in termini di token e amplia la superficie di iniezione dei prompt. Esponete solo le azioni che siete disposti a lasciare che un agente esegua in modo autonomo.
Solo quelli necessari al caso d’uso. Il team di ingegneri di Anthropic ha segnalato che le definizioni degli strumenti e i risultati combinati possono consumare oltre 50.000 token prima ancora che il modello legga la richiesta dell’utente. Le linee guida della comunità concordano su un limite massimo di 10-20 strumenti per server prima che diventino necessarie tecniche di gestione del contesto (divulgazione progressiva, ricerca degli strumenti). Se si superano i 50, è consigliabile suddividere il carico su più server dedicati a scopi specifici.
No, anche se la maggior parte delle implementazioni ne ha una. Un server MCP può esporre file locali, un database o logica in-process senza coinvolgere alcuna API HTTP, proprio come era stato progettato il trasporto stdio originale. Ciò di cui l’MCP ha sempre bisogno è qualcosa su cui eseguire lo strumento. Il wrapping di un’API esistente è semplicemente la via più veloce, poiché l’autenticazione, la convalida e la gestione degli errori sono già presenti.
Gli strumenti sono azioni richiamabili (creare un’attività, eseguire una query) e assomigliano molto agli endpoint delle API. Le risorse sono dati di sola lettura che il modello può integrare nel contesto (file, record di database, documenti in tempo reale). I prompt sono modelli di istruzioni riutilizzabili che il client IA può richiedere, come un flusso di lavoro del tipo “riepiloga/riassumi questo PR”. Gli strumenti ricevono la maggiore attenzione, ma sono le risorse e i prompt a distinguere MCP da un semplice elenco di chiamate di funzioni: consentono al server di plasmare il contesto del modello, non solo le sue azioni.