Piccoli strumenti composabili per browser superano MCP in termini di efficienza dei token e controllo per gli sviluppatori.

Introduzione

Il dibattito su se gli sviluppatori abbiano bisogno di server MCP (Model‑Centric Programming) completi per le attività quotidiane degli agenti si è intensificato nei vari ambienti AI, su Twitter e nelle community di sviluppatori. La domanda centrale è semplice: strumenti leggeri e composabili che gli agenti già comprendono possono sostituire manifesti MCP ingombranti, risparmiando token e mantenendo la flessibilità? Questo articolo esamina un kit minimalista basato su Bash e piccoli script Node, lo confronta con le implementazioni MCP più diffuse e descrive flussi di lavoro pratici per sviluppatori singoli e piccoli team.

Efficienza dei Token: Il Vero Costo dei Manifesti MCP

Come l’MCP Consuma Token

I server MCP più popolari, come Playwright MCP e Chrome DevTools MCP, includono cataloghi di strumenti molto estesi. Per esempio:

• Playwright MCP – 21 strumenti, ~13 700 token (≈ 6,8 % della finestra di contesto di Claude)
• Chrome DevTools MCP – 26 strumenti, ~18 000 token (≈ 9 % della finestra di contesto)

Questi token vengono spesi prima che venga eseguito qualsiasi lavoro reale. Quando si combinano più server MCP, il sovraccarico di token si moltiplica e gli agenti devono analizzare descrizioni di strumenti verbose, generando confusione e riducendo la composabilità.

Il Vantaggio del Kit Minimalista

Un’alternativa leggera consiste in un README conciso (≈ 225 token) più una manciata di script Node che sfruttano Puppeteer Core. Poiché gli agenti comprendono già Bash e JavaScript, possono invocare direttamente questi script senza la necessità di lunghi cataloghi di skill. Il risultato è un’impronta di token due ordini di grandezza più piccola rispetto ai manifesti MCP tradizionali, in linea con la filosofia Unix classica di strumenti piccoli e composabili.

Dentro il Kit Browser Minimalista

Il kit comprende sei script, ognuno con uno scopo specifico e ben definito.

start.js

• Avvia Chrome con un profilo nuovo o clonato.
• Termina eventuali processi Chrome in esecuzione, crea una directory temporanea per i dati utente e avvia Chrome con il debug remoto sulla porta 9222.
• Tenta ripetutamente di connettersi tramite puppeteer.connect finché non riesce, quindi stampa un messaggio di successo.

Questo avvio deterministico elimina la necessità di schemi RPC complessi e fornisce un contratto semplice e affidabile per l’agente.

nav.js

• Sintassi: nav.js <URL> [new]
• Naviga nella scheda attiva (o apre una nuova scheda quando viene specificato new) e attende DOMContentLoaded.
• Restituisce un messaggio di stato pulito, ad esempio “opened” o “navigated”.

Lo script rispecchia il modo naturale in cui gli agenti pensano alle azioni su una pagina: “vai a questa pagina” senza una proliferazione di varianti click, hover o scroll.

evil.js

• Esegue JavaScript arbitrario nel contesto della pagina.
• Uso: evil.js "document.querySelectorAll('a').length"
• Costruisce una funzione async, valuta il codice e stampa i risultati come coppie chiave‑valore (per oggetti/array) o come valore scalare.

Permettendo agli agenti di scrivere codice DOM nativo, evil.js elimina il sovraccarico di token necessario a descrivere ogni possibile interazione e consente l’estrazione diretta dei dati senza dover trasmettere grandi risultati attraverso il prompt.

screenshot.js

• Cattura uno screenshot del viewport della pagina attiva.
• Salva l’immagine nella directory temporanea del sistema operativo con un nome file timestamped e stampa il percorso del file.
• L’agente può quindi leggere l’immagine e applicare modelli di visione secondo necessità.

Memorizzare le immagini come file anziché incorporarle nel prompt riduce drasticamente l’uso dei token.

pick.js

• Fornisce un selettore visivo interattivo.
• Visualizza un banner e un rettangolo di evidenziazione che segue il cursore; un click seleziona un elemento, Ctrl/Cmd+Click abilita la selezione multipla, Enter conferma, Esc annulla.
• Restituisce informazioni strutturate per ogni elemento selezionato, includendo tag, ID, classe, testo troncato, catena di selettori CSS e un frammento di HTML esterno.

Questo strumento collega l’intento umano al codice, permettendo agli agenti di generare selettori affidabili per scraper o script di automazione.

Script di Supporto

Utility aggiuntive (ad esempio un helper per i cookie) completano il kit, gestendo compiti comuni del browser senza aumentare il budget di token.

Costruire un Flusso di Lavoro Fluido

1. Crea una directory dedicata (es. ~/agent-tools).
2. Clona ogni repository di strumenti in questa cartella.
3. Aggiungi la directory al tuo PATH tramite un alias shell o una variabile d’ambiente, così l’agente può invocare direttamente gli script.
4. Fai riferimento al README nel contesto dell’agente solo quando necessario, mantenendo il prompt snello.
5. Imposta la directory degli strumenti come working directory per Claude o altre interfacce LLM, consentendo l’inclusione on‑demand delle definizioni degli strumenti.

Seguendo questi passaggi, gli agenti operano con un set di comandi minimo, evitano cambi di directory continui e non hanno più bisogno di manifesti di skill massicci.

Quando l’MCP Ha ancora Senso

Gli ambienti enterprise spesso limitano l’accesso diretto alle API o al filesystem. In tali casi, un server MCP può fungere da broker con guardrail, fornendo:

• Permessi basati sui ruoli
• Recupero dati auditabile
• Esposizione controllata dei servizi interni

Tuttavia, anche in questi scenari gli sviluppatori dovrebbero monitorare l’impronta di token delle descrizioni degli strumenti del server MCP. Un manifesto di 13–18 k token consuma comunque una parte notevole della finestra di contesto, perciò è buona pratica mantenere i descrittori concisi e delegare output voluminosi a file.

Conclusione

Il kit minimalista dimostra che script piccoli e composabili possono offrire la stessa — o addirittura una maggiore — funzionalità rispetto a server MCP ingombranti, riducendo drasticamente il consumo di token e aumentando il controllo dello sviluppatore. Per sviluppatori singoli e piccoli team, l’approccio consigliato è:

• Utilizzare start.js, nav.js, evil.js, screenshot.js, pick.js e gli helper di supporto.
• Tenere le definizioni degli strumenti in un README conciso e invocarli tramite Bash.
• Riservare i server MCP a contesti che richiedono governance rigorosa o esposizione API limitata.

Abbracciando la filosofia Unix di “fare una cosa e farla bene”, gli agenti rimangono veloci, economici e adattabili — le qualità esatte necessarie per lo sviluppo moderno potenziato dall’IA.