Tool calling: come un agente IA chiama strumenti esterni

Senza tool calling, un modello linguistico sa fare solo una cosa: produrre testo a partire da testo. Non può né consultare una base di dati aggiornata, né inviare un messaggio, né attivare un'azione in un software terzo. Il tool calling è il ponte che collega un modello a un sistema esterno. È ciò che trasforma un modello che conversa in un agente IA capace di agire, il mattone di base dietro ogni agente autonomo.

Definizione dettagliata

Il tool calling, detto anche function calling, indica la capacità di un modello linguistico di rispondere a una richiesta non solo con del testo, ma con una richiesta strutturata di eseguire una funzione precisa, con argomenti compilati secondo uno schema definito in anticipo. La documentazione di Anthropic descrive il principio così: il modello determina se deve chiamare uno strumento in base alla richiesta e alla descrizione dello strumento, poi restituisce una chiamata strutturata che l'applicazione esegue (lato client) o che il fornitore esegue esso stesso (lato server, per alcuni strumenti integrati). La documentazione di OpenAI, che ha reso popolare il termine function calling nel 2023, descrive un meccanismo identico: il modello risponde con una chiamata di funzione leggibile da una macchina invece che con testo libero, spettando poi all'applicazione eseguirla.

I due fornitori di riferimento convergono sulla definizione di fondo: una funzione è descritta da un nome, una descrizione in linguaggio naturale, e uno schema JSON che elenca i parametri attesi. Il modello si basa unicamente su questi tre elementi per decidere se chiamare lo strumento e come compilarne gli argomenti. Non esiste una divergenza significativa tra i due approcci su questo principio di base; le differenze si trovano nei dettagli di implementazione (formati di chiamata parallela, strumenti forniti nativamente dal fornitore, gestione degli errori).

Il tool calling è ciò che distingue un semplice chatbot da un sistema capace di agire sul mondo reale: consultare una base di dati, cercare sul web, scrivere in un file, inviare un messaggio, attivare un pagamento. È anche il mattone di base che rende possibile il protocollo MCP, pensato per standardizzare il modo in cui gli strumenti vengono descritti ed esposti a un modello.

Come funziona

Il percorso di una chiamata di strumento segue sempre lo stesso schema in più passaggi. Prima di tutto, l'applicazione definisce un elenco di strumenti disponibili per il modello, ciascuno con il proprio nome, la propria descrizione e il proprio schema di argomenti. Poi, il modello riceve la richiesta dell'utente accompagnata da questo elenco di strumenti, e decide, in base al contesto, se rispondere direttamente in testo o richiedere l'esecuzione di uno strumento.

Se sceglie di chiamare uno strumento, il modello restituisce una risposta strutturata che contiene il nome dello strumento e i valori dei suoi argomenti, senza eseguire nulla da solo. È l'applicazione a ricevere questa richiesta, a eseguire realmente l'azione (chiamare un'API, leggere una base, scrivere un file), poi a restituire il risultato al modello in una forma che questo può leggere. Il modello prosegue quindi la propria risposta appoggiandosi a questo risultato, e può concatenare più chiamate di strumenti successive se l'attività lo richiede.

Questa suddivisione è importante per la sicurezza: il modello non esegue mai codice da solo, si limita a proporre una chiamata. È l'applicazione a mantenere il controllo su ciò che viene realmente eseguito, e può rifiutare una chiamata se le condizioni non sono riunite.

Esempio concreto con Atako

In Atako, il tool calling è al centro del funzionamento di un agente. Ogni integrazione collegata (Slack, Notion, GitHub, HubSpot, e una quarantina di altre) espone un insieme di azioni precise, come post_message su Slack o create_issue su GitHub, che l'agente può chiamare quando ritiene che l'attività lo richieda.

Ma in Atako, una chiamata a uno strumento non si esegue mai direttamente. Passa prima attraverso un controllo di permesso: la piattaforma verifica che esista un «grant» per quell'agente e quella connessione precisa, che l'azione richiesta figuri effettivamente nell'elenco di azioni autorizzate di quel grant, e che l'ambito concesso (sola lettura o lettura-scrittura) copra effettivamente l'azione in questione. Se una di queste condizioni non è soddisfatta, la chiamata viene rifiutata e il fallimento viene registrato. Questo percorso decisionale, agente che propone una chiamata poi piattaforma che verifica prima di eseguire, è esattamente la logica di sicurezza che il tool calling permette di mettere in atto: il modello propone, l'infrastruttura decide.

Errori frequenti

Un errore comune consiste nel credere che il modello esegua da sé lo strumento che chiama. Non è mai il caso: il modello produce una richiesta strutturata, è sempre un'applicazione o una piattaforma a eseguire realmente l'azione e a poterla rifiutare in qualsiasi momento.

Secondo errore: pensare che dare accesso a uno strumento a un modello equivalga a dargli un accesso totale e illimitato a quel servizio. Un sistema di tool calling ben progettato limita con precisione le azioni disponibili, con permessi per azione e per ambito, invece di un accesso generico «tutto o niente».

Terzo errore: sottovalutare l'importanza della descrizione dello strumento. Il modello dispone solo del nome, della descrizione e dello schema di argomenti per decidere quando e come chiamare uno strumento. Una descrizione vaga o ambigua produce chiamate mal scelte o argomenti scorretti, anche con un modello performante.

Infine, alcuni confondono tool calling e MCP. Il tool calling è il meccanismo di base, presente dal 2023 presso i grandi fornitori di modelli. MCP è un protocollo più recente che standardizza il modo in cui gli strumenti vengono descritti e collegati a un modello, per evitare di risviluppare un'integrazione diversa per ogni strumento e ogni fornitore.