Claude Code ha introdotto il supporto per le MCP Tasks, l’estensione del Model Context Protocol (MCP) che permette a un server MCP di rispondere a una chiamata lunga con un task ID invece del risultato finale. In questo modo l’assistente continua a interagire con l’utente mentre il server esegue il lavoro in background, interrogando periodicamente lo stato del task.
Che cos’è il Model Context Protocol e perché le MCP Tasks sono importanti
MCP è il protocollo aperto sviluppato da Anthropic per collegare assistenti come Claude a strumenti e dati esterni tramite server dedicati. Un tools/call è sincrono per natura: l’assistente invia la richiesta e attende la risposta. Questo è adatto per operazioni rapide (lettura di un file) ma poco efficace per attività prolungate come l’esportazione di un rapporto di dieci minuti o il lancio di un build.
L’introduzione delle MCP Tasks risolve questo limite consentendo al server di accettare la missione, restituire immediatamente un taskId e proseguire il lavoro in modo indipendente. Claude Code mostra un contatore “1 MCP task” nella barra inferiore e, al completamento, inserisce nel transcript la riga MCP task <id> (server/tool) completed. Il risultato viene poi inviato all’assistente, non al transcript.
Storia recente e contesto aziendale
Il 24 ottobre Thariq Shihipar ha annunciato il suo abbandono da Anthropic dopo più di un anno di lavoro su Claude Code, segnando una transizione significativa nel team di sviluppo.
Come funziona un task MCP: il ciclo completo
Il meccanismo segue la specifica dell’estensione io.modelcontextprotocol/tasks e si articola in cinque fasi principali:
- Accettazione: Claude Code dichiara l’estensione nelle proprie capabilities. Il server decide, per ogni richiesta, se generare un task.
- Polling: Il server risponde a
tools/callcon un oggetto task contenentetaskId, lo statoworkinge l’intervallo di polling consigliato (pollIntervalMs). - Richiesta di input: Se il lavoro necessita di una decisione, lo stato passa a
input_requirede la richiesta viene inserita nella tabellainputRequests. - Aggiornamento: L’utente fornisce l’input tramite
tasks/update, che il server elabora. - Completamento: Lo stato diventa
completede il camporesultcontiene il risultato che normalmente sarebbe stato restituito in modalità sincrona. In caso di errore, lo stato èfailedcon il relativo campoerror.
Il diagramma di flusso interno (non mostrato) rappresenta queste interazioni tra Claude Code e il server MCP.
Stati dei task e comportamento di polling
I cinque stati possibili sono:
workinginput_requiredcompletedfailedcancelled
I tre ultimi sono terminali; una volta raggiunti, lo stato non cambia più. Il polling rimane il meccanismo di base, ma il server può anche inviare aggiornamenti proattivi tramite notifications/tasks.
Gestione delle richieste di input
Quando un task necessita di conferma, lo stato passa a input_required. Claude Code apre una finestra di elicitation che mostra la domanda strutturata al cliente. La risposta viene inviata al server con tasks/update. Se l’utente chiude la finestra o preme Esc, la risposta viene comunque considerata inviata; spetta al server decidere come procedere.
In sessioni non interattive, Claude Code non può richiedere input e quindi richiede al server di annullare il task, evitando l’esecuzione di hook di elicitation o callback onElicitation dell’Agent SDK. Questo evidenzia l’importanza di avere un operatore umano presente per le decisioni critiche, in linea con le statistiche di Anthropic che indicano che l’80 % del tempo di una sessione è dedicato all’attesa dell’intervento umano.
Cosa succede chiudendo la sessione
Il comportamento dipende dal tipo di server:
- Server remoto: il task continua a girare sul server anche se l’utente chiude Claude Code.
- Server stdio locale: il processo si interrompe insieme alla chiusura di Claude Code, terminando il job.
Comandi come /clear, /branch o /resume influenzano il tracciamento del task solo se Claude Code rimane attivo. Una nuova sessione avviata con --fork-session non segue i task già in corso.
Esempio di flusso con comandi CLI
Utilizzando la CLI, è possibile:
- Lanciare un task con
claude -p "<prompt>"(non genera task).
claude -p --continue, in modo da ricevere gli aggiornamenti del task.
Requisiti per utilizzare le MCP Tasks
Affinché un utente possa sfruttare le task, devono essere soddisfatte tutte le seguenti condizioni:
- Claude Code deve essere aggiornato alla versione 2.1.304 o successiva (CLI).
- Il server MCP deve supportare la revisione del protocollo 2026-07-28, la prima a includere ufficialmente le Tasks.
- Il server deve essere HTTP, stdio o un connettore
claude.ai(es. plugin portal), senza le variabiliMCPSDKGENERATION=v1néMCPPROTOCOLNEGOTIATION=legacy. - La sessione deve ricevere i feature flags; i fornitori terzi senza telemetria o flag attivi (es. Amazon Bedrock) sono esclusi.
- La chiamata deve avvenire nella conversazione principale; le sub‑agent o chiamate da IDE non generano task.
Attualmente la funzionalità è disponibile solo dalla CLI; l’estensione per VS Code e l’app desktop di Claude Code non la supportano ancora.
Guida rapida per gli sviluppatori di server MCP
Chi espone un servizio come server MCP (ad esempio il MCP Adapter per WordPress) deve decidere quali operazioni restituire come task. La risposta a tools/call deve includere un oggetto JSON con i seguenti campi:
{
"resultType": "task",
"taskId": "build-7f3a9c2e",
"status": "working",
"createdAt": "2026-10-26T12:34:56Z",
"pollIntervalMs": 2000
}
Successivamente, il server deve gestire le richieste di polling (tasks/get), aggiornare lo stato (passando a input_required se necessario) e, al termine, restituire completed con il risultato o failed con l’errore.
Best practice consigliate
- Fornire un
pollIntervalMsragionevole (es. 1000‑3000 ms) per evitare eccessivo carico di rete. - Gestire in modo esplicito gli stati terminali per garantire che il task non rimanga in limbo.
- Implementare meccanismi di timeout e cancellazione per consentire all’utente di abortire operazioni lunghe.
Conclusioni
L’introduzione delle MCP Tasks in Claude Code rappresenta un passo significativo verso una gestione più fluida delle operazioni di lunga durata, spostando il carico di lavoro dal client al server e permettendo all’assistente di rimanere reattivo. Con la versione 2.1.304 della CLI e server aggiornati alla revisione 2026‑07‑28, gli sviluppatori possono ora progettare workflow più complessi senza bloccare l’interfaccia utente. Resta però da vedere quando la funzionalità sarà estesa alle estensioni VS Code e all’app desktop, ma per gli utenti avanzati la combinazione di CLI e server remoto offre già un’esperienza potente e scalabile.
