Semplificare l’automazione: l’approccio MCP con codice

Introduzione

MCP con codice: usare un singolo tool che esegue codice (Python o JavaScript) cambia il modo in cui gli agenti interagiscono con l’ambiente. Questo approccio riduce la fragilità delle CLI, facilita la composizione di operazioni complesse e produce script riutilizzabili, pur introducendo questioni pratiche di sicurezza e controllo.

Contesto

Gli agenti moderni usano spesso molte utility a riga di comando; tuttavia le CLI tendono a essere dipendenti da piattaforma, versione e encoding, e spesso richiedono workaround complessi. Quando uno strumento non è nel training set del modello o presenta sintassi insolita (es. gestire caratteri non-ASCII o newline), l’affidabilità cala e aumentano i turni necessari per completare un task.

MCP con codice: approccio e vantaggi

Un’alternativa utile è esporre un unico “ubertool” che accetta codice come input e lo esegue in una sessione persistente. In pratica l’MCP diventa un interprete Python/JS con librerie utili già disponibili (es. pexpect, Playwright). Vantaggi pratici:

• Sessioni stateful: mantenimento di variabili e oggetti tra chiamate;
• Composizione naturale: loop, gestione errori e sincronizzazione diventano codice, non sequenze di tool;
• Script riutilizzabili: ciò che funziona in sessione può essere dumpato come playbook eseguibile indipendente;
• Superficie funzionale ampia: funzioni native del linguaggio (dir, globals, repr) aiutano esplorazione e introspezione.

Esempi pratici: pexpect e Playwright

Con pexpect l’MCP offre un ambiente Python con pexpect installato: l’agente invia uno script che usa pexpect.Spawn per lanciare e dialogare con processi interattivi (es. LLDB), gestire password o catturare output. Questo riduce decine di chiamate a poche esecuzioni di codice.

Con Playwright l’idea è analoga: un MCP che esegue JavaScript contro l’API Playwright (playwrightess) permette di ricevere console.log direttamente, mantenere stato tra pagine e aggregare dati senza ulteriore inference.

Il problema: limitazioni e frizioni delle CLI

Le CLI presentano problemi pratici: encoding, necessità di newline finali, sessioni stateful (tmux/ LLDB) che l’agente fatica a gestire, e preflight/security checks che rallentano l’esecuzione. Inoltre la composizione di comandi tramite bash è potente ma fragile: errori minimi fanno perdere lo stato e costringono a ripetizioni.

Soluzione / Approccio raccomandato

Esporre un interprete come singolo tool rende l’agente più efficace perché il linguaggio è noto e l’SDK associato è stato visto nel training. Raccomandazioni pratiche:

1. Preferire un ubertool che valuta codice in una VM o virtualenv con librerie utili;
2. Fornire timeout, logging strutturato e un canale per forwardare console/log di basso livello;
3. Dumps di sessione: permettere all’agente di generare script eseguibili riutilizzabili dopo la sessione esplorativa;
4. Limitare privilegi e usare sandboxing di sistema quando possibile (chroot, cgroups, syscall filtering).

Rischi e limiti di sicurezza

L’esecuzione di codice in eval() riduce la barriera tra attività automatizzata e comandi arbitrari: pexpect o Playwright possono lanciare processi shell. La sicurezza è complessa — proteggere ogni chiamata richiede un controllo su ogni system call o una policy di sandboxing molto rigorosa. In pratica le protezioni sono difficili da rendere invulnerabili; il design deve quindi bilanciare controllo, auditing e isolamento.

Quando usare un MCP con codice

Questo approccio è indicato quando:

• serve mantenere stato tra interazioni;
• le operazioni richiedono composizione complessa e riuso (debugging, scraping multi-pagina, test end-to-end);
• si vuole convertire rapidamente una sessione esplorativa in un playbook riutilizzabile.

Conclusione

Un MCP che espone un interprete per codice (Python/JS) offre vantaggi concreti rispetto a una collezione di CLI: meno fragilità, più riuso e migliori pattern di composizione. Rimangono però sfide significative di sicurezza e controllo operativo che richiedono un design attento del runtime e strumenti di isolamento.

FAQ

1. Quando conviene adottare un MCP con codice per il debugging di applicazioni C?

   Quando la sessione richiede stato persistente (es. LLDB interattivo) e la conversione in script riutilizzabili è un obiettivo; riduce i turni e aumenta affidabilità.

2. Quali sono i benefici pratici dell’MCP con codice rispetto a molte CLI separate?

   Meno chiamate strumentali, logging diretto, script riutilizzabili e gestione più semplice di sincronizzazione e error handling.

3. Come contenere i rischi di sicurezza quando l’MCP esegue Python/JS con eval?

   Usare sandboxing a livello di sistema, policy di syscall, limitare privilegi e applicare auditing e timeouts; comunque il rischio non è eliminabile del tutto.

4. Il codice generato in sessione può essere riusato senza MCP?

   Sì: uno dei punti di forza è che gli script prodotti sono spesso eseguibili come playbook indipendenti e richiedono poche modifiche manuali.

5. In quali casi l’approccio code-based MCP può fallire?

   Quando il modello non conosce la libreria target o il dominio è totalmente nuovo; la qualità dipende dall’esposizione dell’SDK e dalla capacità del modello di scrivere codice corretto.