Tool Calling vs MCP: differenze e quando usarli

Tool Calling è una funzione delle API dei modelli linguistici con cui il modello richiede la chiamata di una funzione e l’applicazione esegue il codice. Model Context Protocol (MCP) è uno standard JSON-RPC aperto che consente alle applicazioni di IA di individuare e invocare strumenti esposti da server esterni. MCP si basa su Tool Calling, anziché sostituirlo.

Chi sviluppa agenti IA o backend basati su LLM incontra spesso entrambi i termini nella documentazione dei fornitori. Per comprendere Tool Calling e MCP occorre distinguere il modo in cui un modello decide di eseguire una funzione da quello in cui un’applicazione si collega al sistema che la ospita.

Che cos’è Tool Calling nelle API degli LLM?

Tool Calling (detto anche function calling) è una funzione delle API dei modelli che trasforma un prompt in linguaggio naturale in un’invocazione strutturata di una funzione. Nella richiesta API si passano definizioni di funzioni con nome, descrizione e parametri JSON Schema; il modello decide se restituire una chiamata strutturata contenente il nome della funzione e gli argomenti.

Il modello non esegue la funzione direttamente. Tool Calling funziona invece come una conversazione in più passaggi tra applicazione e modello:

Inviare le dichiarazioni degli strumenti: l’applicazione interroga il modello includendo le definizioni JSON Schema degli strumenti che può chiamare.
Ricevere una chiamata strutturata: il modello risponde con una chiamata contenente il nome della funzione scelta e argomenti JSON (per esempio, Anthropic restituisce un motivo di arresto e un blocco tool_use).
Eseguire il codice lato applicazione: il backend convalida gli argomenti ed esegue la funzione locale o la richiesta API interna.
Restituire il risultato dello strumento: l’applicazione invia una seconda richiesta al modello con il risultato, per esempio un blocco tool_result.
Ricevere la risposta finale: il modello usa il risultato per rispondere all’utente oppure richiede altre chiamate agli strumenti.

Una definizione di funzione OpenAI usa i parameters di JSON Schema e supporta strict: true per imporre il rispetto dello schema:

{
  "type": "function",
  "name": "get_weather",
  "description": "Get the current weather for a given location.",
  "strict": true,
  "parameters": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string"
      }
    },
    "required": ["location"],
    "additionalProperties": false
  }
}

Le principali API dei modelli consentono un controllo dettagliato sulla selezione delle funzioni. Nelle API OpenAI e Google Gemini, tool_choice permette di lasciare la selezione su auto (predefinito), forzare una o più chiamate (required in OpenAI, any in Gemini), disabilitare gli strumenti (none), limitare il modello a un sottoinsieme con allowed_tools o usare la modalità validated di Gemini per garantire il rispetto dello schema della funzione. OpenAI e Gemini supportano entrambi chiamate parallele, così un modello può invocare più funzioni in un turno. OpenAI permette di impostare parallel_tool_calls su false per ottenere al massimo una chiamata per turno. Gemini supporta anche chiamate composizionali per esecuzioni sequenziali in più passaggi.

Anthropic distingue l’uso degli strumenti in base a dove viene eseguito il codice. Gli strumenti client (incluse le funzioni personalizzate e gli strumenti con schema Anthropic come bash e text_editor) vengono eseguiti nell’applicazione. Gli strumenti server (come web_search, web_fetch, code_execution e tool_search) vengono eseguiti direttamente sull’infrastruttura Anthropic.

Che cos’è Model Context Protocol (MCP)?

Model Context Protocol (MCP) è uno standard open source per collegare applicazioni di IA a sistemi esterni tramite JSON-RPC 2.0. Ispirata a Language Server Protocol, la specifica MCP (versione 2026-07-28) funziona come una porta USB-C per le applicazioni di IA, così una sola integrazione server può funzionare con ChatGPT, Claude, Visual Studio Code, Cursor e agenti personalizzati.

MCP divide le responsabilità tra tre ruoli:

Host (Hosts): applicazioni LLM, come un IDE o un’interfaccia di chat, che avviano le connessioni.
Client (Clients): connettori del protocollo eseguiti nell’applicazione host.
Server (Servers): servizi esterni che espongono funzionalità e contesto al client.

Nella specifica 2026-07-28 il protocollo di base usa richieste JSON-RPC 2.0 autonome e senza stato, con negoziazione delle capacità a ogni richiesta. MCP definisce due trasporti standard: stdio, che trasmette messaggi separati da nuove righe tramite input e output standard di un sottoprocesso avviato dal client, e Streamable HTTP, in cui ogni messaggio è una POST HTTP verso un singolo endpoint MCP. Gli sviluppatori possono anche implementare trasporti personalizzati.

Mentre Tool Calling degli LLM gestisce solo funzioni, i server MCP possono esporre tre funzionalità principali:

Tools: funzioni eseguibili dal modello di IA.
Resources: contesto e dati leggibili dall’applicazione.
Prompts: modelli di messaggi e flussi di lavoro per gli utenti.

Sul lato client, MCP supporta Elicitation, che consente a un server di chiedere informazioni aggiuntive all’utente. La specifica 2026-07-28 include anche estensioni opzionali negoziate per Tasks (operazioni asincrone di lunga durata), Skills over MCP e MCP Apps (elementi interattivi dell’interfaccia visualizzati nel flusso).

Per eseguire gli strumenti, un client MCP individua quelli disponibili chiamando tools/list, che supporta paginazione e caching. I server che dichiarano la capacità listChanged possono notificare ai client le modifiche agli strumenti disponibili. Ogni definizione di strumento MCP include un name sensibile a maiuscole e minuscole (si consigliano da 1 a 128 caratteri), un title facoltativo, una description, icons facoltative, un inputSchema (JSON Schema 2020-12 per impostazione predefinita), un outputSchema facoltativo e annotazioni facoltative.

Quando il modello decide di usare uno strumento MCP, il client invia al server una richiesta JSON-RPC tools/call:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "San Francisco, CA"
    }
  }
}

Se l’esecuzione di uno strumento sul server fallisce, MCP restituisce l’errore nel risultato con isError: true, così il modello linguistico può leggere l’errore e correggersi.

Tool Calling vs MCP: confronto

Il confronto diretto tra Tool Calling degli LLM e MCP mostra che operano su livelli diversi dello stack. A novembre 2026, Tool Calling nativo e Model Context Protocol differiscono in sette aspetti architetturali:

Aspetto	Tool Calling (Function Calling)	Model Context Protocol (MCP)
Che cos’è	Funzione API del modello con cui un LLM produce argomenti strutturati per una funzione	Protocollo aperto JSON-RPC 2.0 che collega host e client IA a server esterni
Chi definisce gli strumenti	Il codice dell’applicazione (o gli strumenti server del fornitore) nella richiesta API del modello	Un server MCP che espone Tools, Resources e Prompts
Dove viene eseguito il codice	Il backend dell’applicazione (o il cloud del fornitore LLM per gli strumenti server)	Un sottoprocesso locale (`stdio`) o un servizio remoto (Streamable HTTP)
Individuazione	Statica per ogni richiesta API; il codice fissa o seleziona gli schemi prima di chiamare il modello	Dinamica in fase di esecuzione tramite `tools/list` e notifiche `listChanged`
Trasporto	API HTTPS del fornitore (OpenAI, Anthropic, Google Gemini)	`stdio`, Streamable HTTP o trasporti personalizzati
Portabilità tra client	Legata all’app e al formato dello schema dello specifico fornitore LLM	Portabile tra host compatibili con MCP (Claude, ChatGPT, VS Code, Cursor, app personalizzate)
Costi	Token di input per le definizioni, token di output per le chiamate e costi aggiuntivi per gli strumenti server del fornitore	Token di input per ogni schema di strumento caricato e infrastruttura per ospitare o eseguire il server MCP

MCP sostituisce Function Calling?

MCP non sostituisce Function Calling, perché il modello linguistico usa ancora Tool Calling per selezionare e invocare ogni strumento MCP. Tool Calling e MCP sono livelli complementari dello stesso ciclo di vita della richiesta.

Quando un’applicazione di IA si collega a un server MCP, il flusso combina entrambi i sistemi:

Individuazione tramite MCP: il client MCP dell’applicazione host invia una richiesta tools/list al server MCP e riceve nomi, descrizioni e oggetti inputSchema JSON Schema degli strumenti.
Formattazione per l’LLM: l’host traduce le definizioni degli strumenti MCP nell’array tools nativo del fornitore LLM e le invia insieme al prompt dell’utente.
Selezione tramite Tool Calling: il modello linguistico valuta il prompt ed emette una chiamata standard con il nome e gli argomenti dello strumento scelto.
Esecuzione tramite MCP: l’host intercetta la chiamata del modello, la associa a una richiesta MCP tools/call e la invia al server MCP tramite stdio o Streamable HTTP.
Completamento: il server MCP restituisce il risultato (con isError: true se l’esecuzione è fallita), l’host lo passa al modello come risultato dello strumento e il modello genera la risposta finale.

Senza Tool Calling nell’API del modello, l’LLM non avrebbe un meccanismo per attivare uno strumento MCP. Senza MCP, l’applicazione deve collegare manualmente ogni schema e gestore di esecuzione degli strumenti.

Come supportano MCP direttamente OpenAI, Anthropic e Google?

OpenAI, Anthropic e Google permettono ora di passare server MCP remoti direttamente alle API dei loro modelli come tipo di strumento integrato. Anziché scrivere un ciclo client MCP per collegare tools/list e tools/call, l’API del fornitore del modello si collega al server MCP per conto dell’utente.

A novembre 2026 ogni fornitore implementa le connessioni dirette ai server MCP con capacità specifiche e limiti documentati:

OpenAI Responses API

In OpenAI Responses API si può collegare un server MCP specificando "type": "mcp" nell’array degli strumenti insieme a server_label e server_url. OpenAI include due controlli fondamentali per la produzione:

allowed_tools: importa solo un sottoinsieme specifico degli strumenti del server MCP, per non sovraccaricare il contesto del modello.
require_approval: configura se le invocazioni vengono eseguite automaticamente o attendono un’approvazione umana esplicita.

Per servizi locali o privati OpenAI offre Secure MCP Tunnel, che consente di collegare server MCP interni senza esporli su Internet.

Anthropic MCP Connector

Anthropic offre un MCP connector in beta nella Messages API (mcp_servers e mcp_toolset) che collega server MCP remoti senza richiedere un’implementazione client separata. Occorre ricordare quattro limitazioni documentate:

Solo strumenti: il connettore supporta solo le chiamate agli strumenti della specifica MCP, non Resources o Prompts MCP.
HTTP pubblico obbligatorio: il server MCP deve essere esposto pubblicamente tramite HTTP, con supporto per Streamable HTTP e SSE.
Nessun stdio locale diretto: i server stdio locali non possono collegarsi direttamente alla Messages API, ma gli SDK Anthropic offrono funzioni di supporto lato client per i server locali.
Esclusioni di conformità: il MCP connector beta non è idoneo per carichi di lavoro Zero Data Retention (ZDR) o HIPAA.

Google Gemini Interactions API

Gemini Interactions API di Google accetta server MCP esterni tramite la dichiarazione "type": "mcp_server", configurata con name, url, headers e allowed_tools. Google impone due regole rigorose per questa integrazione:

Solo Streamable HTTP: Gemini Interactions API supporta server Streamable HTTP e non supporta trasporti SSE.
Sintassi dei nomi: i nomi dei server devono usare snake_case e non possono contenere trattini.

Quando usare Tool Calling o MCP?

La scelta tra MCP e Tool Calling dipende da chi mantiene le integrazioni e da quante applicazioni devono condividerle. Considera i vincoli del progetto attraverso tre scenari comuni.

Quando basta Tool Calling semplice

Usa Tool Calling nativo dell’LLM quando gli strumenti si trovano nel backend di una sola applicazione e nessun client esterno deve chiamarli. Se sto creando un’app web con cinque query interne al database e un’azione di checkout Stripe, scrivere un server MCP aggiunge un passaggio di rete o un sottoprocesso superfluo.

Tool Calling semplice è più adatto quando:

Hai poche funzioni che interrogano il tuo database o microservizi interni.
Controlli l’intera base di codice e desideri bassa latenza e convalida diretta nello stesso processo.
Nessun altro assistente IA, IDE o team deve individuare o riutilizzare quelle funzioni.

Quando conviene un server MCP

Crea o adotta un server MCP quando gli stessi strumenti devono funzionare con più client IA o quando un altro team gestisce il sistema sottostante. Se la piattaforma di sviluppo espone il monitoraggio delle issue e i log di distribuzione tramite MCP, gli sviluppatori possono collegare lo stesso identico server a Claude, ChatGPT, Visual Studio Code, Cursor e all’agente interno senza riscrivere gli schemi.

MCP conviene quando:

Vuoi scrivere una volta e ottenere portabilità tra più host IA e IDE di sviluppo.
Un fornitore terzo o un altro team interno mantiene l’integrazione.
Il tuo agente dipende dall’individuazione dinamica degli strumenti (tools/list e listChanged) quando le capacità cambiano durante l’esecuzione.
Il flusso di lavoro richiede Resources MCP, modelli di prompt per gli utenti o richieste di informazioni agli utenti oltre all’esecuzione delle funzioni.

La configurazione ibrida

Un approccio comune per i team che portano agenti IA dalla sperimentazione alla produzione combina entrambi i metodi. Un’applicazione tipica definisce nel codice alcuni strumenti di funzioni native sensibili alla latenza e collega uno o due server MCP esterni per integrazioni SaaS di terze parti, usando allowed_tools per escludere endpoint non necessari.

Compromessi tra sicurezza, latenza e costo dei token

Aggiungere strumenti a un’applicazione LLM, tramite dichiarazioni native o server MCP, comporta costi in token, considerazioni sul caching e confini di sicurezza da gestire con attenzione.

Costi dei token di input e caching dei prompt

Ogni definizione di strumento passata a un’API di modello viene conteggiata tra i token di input. Anthropic documenta che le definizioni nel parametro tools contano come token di input; OpenAI osserva che alcuni server MCP espongono decine di strumenti contemporaneamente e che esporne molti può aumentare costi e latenza.

Per mantenere prevedibili i costi dei token:

Filtra gli strumenti importati: OpenAI e Google usano allowed_tools, mentre il MCP connector di Anthropic consente di permettere, bloccare o configurare singoli strumenti in mcp_toolset.
Mantieni deterministico l’ordine dell’elenco degli strumenti. La specifica MCP osserva che un ordine deterministico in tools/list aiuta i client a memorizzare l’elenco nella cache e migliora la percentuale di successi del caching dei prompt dell’LLM quando le definizioni sono nel contesto del modello.

Confini di fiducia e approvazione umana

Gli strumenti comportano l’esecuzione di codice arbitrario, un problema ancora più rilevante se distribuisci anche agenti IA che usano il computer e interagiscono con interi sistemi operativi. Collegando un server MCP di terze parti si attraversa un confine di fiducia: descrizioni degli strumenti o risposte del server non attendibili possono essere un vettore di prompt injection.

La specifica MCP avverte esplicitamente che le annotazioni degli strumenti devono essere considerate non attendibili, a meno che provengano da un server affidabile. Poiché MCP non può imporre la sicurezza al livello del protocollo di comunicazione, la specifica afferma che le applicazioni host devono ottenere il consenso esplicito dell’utente prima di invocare qualsiasi strumento e dovrebbero sempre coinvolgere una persona capace di negare le invocazioni. Con integrazioni API dirette come Responses API di OpenAI, abilita require_approval sugli strumenti sensibili affinché una persona possa esaminare gli argomenti prima dell’esecuzione.

FAQ

MCP è uguale a Function Calling?

No. Function Calling (Tool Calling) è il meccanismo API del modello con cui un LLM emette una richiesta JSON strutturata per eseguire una funzione identificata per nome. Model Context Protocol (MCP) è uno standard di comunicazione aperto che consente alle applicazioni IA di individuare e invocare Tools, Resources e Prompts ospitati su server esterni.

Si può usare MCP senza Tool Calling?

Puoi usare Resources e modelli di prompt MCP senza Tool Calling del modello, poiché queste funzioni vengono lette o attivate dall’applicazione host o dall’utente. Tuttavia, quando un modello IA invoca autonomamente uno strumento MCP tramite tools/call, usa la propria capacità nativa di Tool Calling per selezionarlo.

MCP costa più token di Tool Calling nativo?

Una singola definizione di strumento costa lo stesso numero di token di input sia che l’app la carichi da codice locale sia da un server MCP. In pratica le configurazioni MCP consumano spesso più token perché un singolo server MCP può esporre decine di strumenti contemporaneamente, a meno di filtrare l’elenco con allowed_tools.

Quali fornitori LLM supportano server MCP in modo nativo nelle API?

A novembre 2026 OpenAI, Anthropic e Google accettano tutti server MCP remoti direttamente nelle loro API. OpenAI supporta "type": "mcp" nella Responses API, Anthropic offre il MCP connector beta (mcp_servers e mcp_toolset) nella Messages API e Google supporta "type": "mcp_server" nella Gemini Interactions API.

L’API di Anthropic può collegarsi direttamente a un server MCP stdio locale?

No. Il MCP connector beta di Anthropic nella Messages API si collega solo a server MCP remoti esposti pubblicamente tramite HTTP (Streamable HTTP e SSE). Per usare un server MCP stdio locale con Claude, occorre eseguire la connessione lato client con le funzioni di supporto dell’SDK Anthropic.

Tool Calling vs MCP: differenze e quando usarli

Che cos’è Tool Calling nelle API degli LLM?

Che cos’è Model Context Protocol (MCP)?

Tool Calling vs MCP: confronto

MCP sostituisce Function Calling?