C’è stato un momento, fino a non molto tempo fa, in cui installare e configurare un MCP, un Model Context Protocol, sembrava la risposta definitiva alla frammentazione degli strumenti AI. Connettere tutto, orchestrare agenti, far lavorare i tool in autonomia. Una sorta di USB universale per l’intelligenza artificiale. L’idea era seducente, quasi inevitabile. Accendi, colleghi, e l’agente lavora.
Ah, chiariamo una cosa: non sto parlando di otto anni fa, ma di otto mesi fa. Giusto per dire.
Poi inizi a usarlo davvero.
Ed è lì che il racconto cambia. Non in modo drammatico, ma in modo più sottile, più insidioso.
Oddio, non voglio dire che un MCP è una supercazzola prematurata con scappellamento a destra. Anzi.
Io sono a favore delle innovazioni.
I connettori funzionano, ma non sempre. Gli agenti rispondono, ma non sempre come ti aspetti. I tool sono disponibili, ma non sempre vengono richiamati nel momento giusto. Nulla si rompe davvero eppure tutto sembra leggermente instabile.
È una sensazione difficile da descrivere. Non è un bug evidente. È piuttosto una frizione continua. Un sistema che promette fluidità e invece introduce un nuovo livello di mediazione tra il modello e il mondo operativo. Ogni server MCP diventa un piccolo interprete, ogni tool una possibilità in più, ogni possibilità una deviazione potenziale. Ed è lì che si annidano le magagne.
Il risultato è che la semplicità promessa si trasforma in complessità emergente. Non perché il protocollo sia sbagliato, ma perché aggiunge un layer (uno strato) in cui il modello deve decidere cosa usare, quando usarlo e come usarlo. E questa decisione, per definizione, non è mai completamente deterministica.
A quel punto ti accorgi che stai passando più tempo a capire perché l’agente ha scelto un tool invece di un altro, piuttosto che lavorare sul problema originale.
Non è un fallimento, è una deriva. È come una nave senza chiglia che si fa sballottare nel mare magnum delle connessioni AI.
Il sistema continua a funzionare, ma richiede sempre più attenzione. Sempre più controllo. Sempre più contesto.
E qui inizia a emergere il primo vero cambio di prospettiva: più connettori non significano necessariamente più efficienza. Anzi, spesso introducono rumore decisionale. Il modello ha più possibilità, ma anche più ambiguità. Più strumenti, ma meno chiarezza.
Il plug and play, in questo contesto, non scompare. Semplicemente si sposta. Non è più nel momento della configurazione, ma nel momento della comprensione. E quel momento arriva sempre dopo, quando il sistema è già in funzione e tu stai cercando di capire perché tutto sembra corretto, ma nulla è davvero stabile.
È in quel passaggio che l’MCP smette di essere una scorciatoia e diventa un’architettura. E l’architettura, per sua natura, non è mai plug and play.
Ah, e non dimentichiamo che nel mentre stai cercando di lavorare su altre cose.
Il marasma è a un passo da dove ti trovi. Dici, “mollo tutto”. Poi, mi “viene da piangere”, perché ti accorgi che hai lasciato i task a metà e quando li riprendi sotto mano non ti raccapezzi più. Magari succede solo a me.
Quando la tokenizzazione diventa il vero problema
All’inizio non te ne accorgi. Tutto sembra funzionare. I connettori rispondono, gli agenti si muovono, i tool vengono richiamati. Il sistema non si pianta, non genera errori evidenti. Anzi, dal punto di vista operativo, l’MCP sembra fare esattamente ciò per cui è stato pensato.
Poi inizi a guardare i token.
E lì cambia la prospettiva. Perché ogni server MCP attivo porta con sé una lista di tool, capabilities, descrizioni e schemi che vengono caricati nel contesto. Non solo quando servono, ma spesso in modo persistente. Il modello deve sapere cosa può usare, e per saperlo deve tenerlo nel contesto. È una conseguenza logica del meccanismo.
Il problema è che il contesto non è infinito. E soprattutto: non è gratuito.
Ogni tool esposto è un frammento di contesto in più. Ogni connettore attivo è una porzione di context window occupata prima ancora di iniziare a lavorare. Quando i server MCP diventano più di uno, il contesto si riempie lentamente, quasi senza farsi notare. Non c’è un momento preciso in cui tutto esplode. È una crescita progressiva, silenziosa.
Il sistema continua a funzionare, ma diventa più ricolmo. Più incerto. Oltreché più costoso.
È qui che entra in gioco quella che potremmo chiamare token economy. Non nel senso astratto del termine, ma in quello molto concreto della fattura a fine mese. Ogni chiamata al modello contiene più contesto, più tool, più possibilità. E ogni possibilità ha un costo. Non solo computazionale, ma economico.
Il paradosso è che il sistema non si rompe. Continua a lavorare, continua a produrre risultati. Ogni tanto ti gasi al punto di pensare di essere diventato un figo da paura. Poi però torni sulla terra, perché il sistema lo fa occupando sempre più spazio, come un’applicazione che non ha latenze evidenti, eppure consuma progressivamente tutta la RAM disponibile. La differenza è che qui la RAM è il contesto e il contesto è pagato a token.
A quel punto ti accorgi che il vero problema non è quando l’MCP si pianta. È quando continua a funzionare mentre i token salgono.
La complessità non è più solo architetturale, diventa anche economica. Più connettori, più tool, più contesto. Più contesto, più token. Più token, più costo. Ci sono stati dei mesi, che avevo paura a ricevere la fattura delle API che usavo e ci sono stati dei mesi che mi veniva da piangere, perché non mi ero accorto di quanto mi venivano a costare i miei “esperimenti”. E tutto questo senza un reale aumento proporzionale dell’efficacia.
A un certo momento mi sono fermato, ho puntato i piedi e mi sono messo alla finestra ad aspettare l’evoluzione. E adesso sono a questo punto del mio percorso.
Sia chiaro, non è un errore del protocollo.
È una conseguenza del suo funzionamento. L’MCP è progettato per rendere disponibili gli strumenti al modello. Ma rendere disponibili gli strumenti significa anche caricarli nel contesto, e caricarli nel contesto significa consumare spazio prima ancora di usarli.
È qui che il plug and play inizia a mostrare il suo lato meno evidente. Non si paga in complessità di configurazione, ma in complessità latente. Non si paga subito, ma si paga nel tempo. Non si paga in errori, ma in consumo.
Diciamocela tutta: siamo tornati al celeberrimo “Plug & Pray” di metà anni Novanta, solo coniugato in maniera differente.
E quando inizi a disattivare connettori non necessari, ridurre i tool esposti, filtrare le capability, ti rendi conto che stai facendo qualcosa di diverso. Non stai più configurando un sistema plug and play. Stai progettando un’architettura di contesto.
Troppi connettori, troppo rumore
Quando inizi ad aggiungere connettori, la sensazione iniziale è di potenza. Più strumenti, più possibilità, più automazione. L’agente può leggere file, interrogare API, scrivere codice, navigare, orchestrare task. Tutto sembra convergere verso un sistema più intelligente.
Poi accade qualcosa di meno evidente. Il modello non diventa più preciso. Diventa più indeciso.
Ogni tool disponibile è una strada alternativa. Ogni strada alternativa introduce una scelta. E ogni scelta aumenta la possibilità che il modello imbocchi quella meno efficiente o semplicemente quella non prevista. Non è un errore, è una conseguenza naturale di un sistema che deve ragionare sulle opzioni.
Quando i connettori diventano molti, il routing si fa ambiguo. Due tool possono fare cose simili. Tre possono sovrapporsi. Alcuni possono essere tecnicamente più corretti, altri semanticamente più vicini alla richiesta. Il modello deve decidere. E la decisione non è sempre quella che avresti preso tu.
Nasce così una forma di incasinamento architetturale. Non è un rumore evidente, non produce crash. Produce deviazioni. L’agente chiama un tool invece di un altro. Recupera dati da una fonte meno adatta. Esegue un passaggio intermedio non necessario. Ogni singola scelta è plausibile, ma l’insieme diventa come minimo meno lineare.
Il paradosso è che più integrazione porta meno controllo. Non perché il sistema sia progettato male, ma perché il modello deve gestire una quantità crescente di possibilità operative. E la gestione delle possibilità ha un costo cognitivo, anche per un LLM.
A quel punto emergono comportamenti curiosi. L’agente usa tool diversi per task simili. Alterna strategie. Introduce fallback non richiesti. A volte aggira un connettore per usarne un altro. Nulla è davvero sbagliato, ma tutto è leggermente incoerente.
È il momento in cui capisci che non stai più orchestrando strumenti, ma stai orchestrando decisioni. E le decisioni, quando aumentano, tendono a produrre rumore. Non perché siano errate, ma perché non sono più univoche.
A quel punto la domanda cambia. Non è più “quali tool posso aggiungere”, ma quali tool devo togliere. Non è più un problema di integrazione, ma di selezione. Non si tratta di aumentare le possibilità, ma di ridurre il rumore. Finalmente si arriva a questo e ci sono arrivato anche io, che adesso mi trovo in questa fase.
Ed è proprio in questa fase che il plug and play perde definitivamente la sua natura. Perché selezionare significa decidere. Decidere significa progettare. E progettare, inevitabilmente, significa rinunciare a qualcosa.
La CLI non è la soluzione definitiva
A questo punto, la reazione più naturale è cercare controllo. Ridurre i connettori, eliminare il rumore, tornare a qualcosa di più deterministico. Ed è qui che emerge la risposta più immediata: usare CLI e API dirette. Meno layer, meno ambiguità, più prevedibilità.
Poi, di mattina presto mi sono ritrovato a leggere il “solito” articolo “MCP is dead” e allora mi son detto: “Olé, ora voglio dire la mia”. Senza pretese di dire la cosa giusta, anzi. Ho un sacco di dubbi, ma questo pattern che ci dice “la tal cosa è morta” ha anche un pelino rotto le scatole.
Quindi, si diceva la CLI.
Insomma, come dicevamo noi Generation X: “Back To Basics”, torniamo alle origini.
In effetti, il passaggio funziona. Con chiamate dirette, sai cosa viene eseguito, quando viene eseguito e con quali parametri. Il comportamento diventa lineare. Il routing sparisce. Il modello non deve più scegliere tra più tool simili, perché il tool è uno solo. La sensazione è quella di aver ripreso il controllo.
Ma è una stabilità parziale.
La CLI riduce l’ambiguità, ma introduce un’altra forma di rigidità. Ogni integrazione deve essere definita a mano. Ogni flusso deve essere progettato. Ogni orchestrazione deve essere pensata prima. Non c’è più il rumore dei connettori, ma c’è il peso della gestione manuale.
Funziona bene finché i flussi sono pochi. Funziona meno quando gli scenari crescono. Ogni nuova capacità richiede una nuova chiamata, una nuova definizione, una nuova logica di gestione. L’autonomia del modello si riduce, ma cresce la responsabilità architetturale di chi configura il sistema.
È una forma diversa di complessità. Più controllata, ma comunque presente.
La CLI, in questo senso, non sostituisce l’MCP. Lo semplifica. Riduce i livelli, ma non risolve il problema di fondo: come orchestrare l’interazione tra modello e ambiente operativo. Perché alla fine, che sia via MCP o via CLI, il nodo resta lo stesso. Il modello deve usare strumenti esterni in modo coerente.
Con la CLI lo fa in modo più deterministico, ma meno flessibile. Con l’MCP lo fa in modo più flessibile, ma meno controllato. Nessuna delle due soluzioni è definitiva. Sono due punti su uno spettro.
Ed è proprio osservando questo spettro che emerge un’altra direzione. Non tanto scegliere tra connettori intelligenti e chiamate dirette, ma cambiare livello di astrazione. Non decidere quale tool usare, ma come strutturare l’ambiente in cui il modello opera.
Quando inizi a vedere la CLI come un passaggio intermedio, cambia anche la prospettiva. Non è la soluzione finale, ma una fase di transizione. Serve a ridurre il rumore, a capire i flussi, a ristabilire il controllo. Ma non scala davvero, perché resta ancorata a un’interazione ancora troppo manuale.
È una stabilità temporanea. Utile, necessaria, ma non definitiva.
Non vale:
MCP → caos → CLI → controllo
Sarebbe troppo facile. E anche riduttivo.
Occorre arrivare a:
MCP → rumore → agent runtime → orchestrazione
È un salto di livello.
La CLI funziona bene quando:
hai flussi lineari
pochi tool
poche decisioni
niente autonomia vera
Ma appena entri in scenari tipo:
multi-step planning
tool chaining
decision routing
environment control
la CLI diventa troppo procedurale. L’agente deve poter decidere, non eseguire solo comandi.
Lo shift verso l’interazione agentica avanzata
Quando inizi a ridurre i connettori e abbandonare anche la CLI, succede qualcosa di interessante. Non stai più cercando lo strumento giusto. Stai cercando un modo diverso di far lavorare il modello.
Il punto non è più quale tool usare, ma come orchestrare l’interazione. Non più singole chiamate, ma sequenze. Non più esecuzione, ma pianificazione. È qui che entra in gioco quello che oggi viene definito, non sempre con precisione, interazione agentica avanzata.
In questo contesto, il modello non si limita a scegliere uno strumento. Definisce un percorso. Decide i passaggi intermedi, valuta quando fermarsi, quando cambiare strategia, quando usare un tool e quando ignorarlo. Non è una differenza puramente tecnica. È un cambio di paradigma.
Con MCP il problema era l’eccesso di possibilità (e spesso non capisci più nemmeno a che punto ti trovi 😊). Con CLI, il problema diventa l’eccesso di rigidità. Con un approccio agentico, il focus si sposta sull’orchestrazione del comportamento.
Non significa lasciare tutto all’autonomia del modello. Al contrario. Significa definire un ambiente in cui il modello possa muoversi con vincoli chiari, ma senza dover scegliere ogni volta tra decine di connettori o seguire flussi completamente manuali. È una via intermedia, ma a un livello più alto.
Qui cambia anche il ruolo dei tool. Non sono più oggetti indipendenti da selezionare, ma capacità integrate in un contesto operativo. Il modello non decide solo cosa usare, ma perché usarlo, in quale ordine e con quale obiettivo. Il comportamento diventa più coerente, non perché i tool siano meno, ma perché l’interazione è progettata.
È in questo passaggio che la CLI inizia a perdere centralità. Non perché non funzioni, ma perché resta legata a una logica ancora troppo lineare. Ogni comando è esplicito, ogni passaggio è definito. L’interazione agentica, invece, introduce una dimensione più fluida, in cui il modello può pianificare senza essere vincolato a una sequenza predefinita.
Questo non elimina la complessità. La sposta. Non è più nella scelta tra connettori, ma nella progettazione del comportamento. Non si tratta più di integrare strumenti, ma di definire un runtime operativo. Un ambiente in cui il modello possa agire, piuttosto che limitarsi a chiamare funzioni.
Ed è proprio osservando questa evoluzione che diventa chiaro come il dibattito MCP contro CLI sia, in fondo, già superato. Entrambi appartengono a una fase in cui il modello interagisce con strumenti esterni. L’interazione agentica avanzata inizia a suggerire qualcosa di diverso: il modello non usa più strumenti isolati, ma opera all’interno di un contesto controllato.
Non è una soluzione definitiva. È uno scenario che sta emergendo. Ma è sufficiente per cambiare il modo in cui guardiamo al problema. Non più quale connettore usare, ma quale ambiente costruire.
Non è MCP contro CLI, è il passaggio agli agenti operativi
A questo punto il confronto tra MCP e CLI inizia a perdere significato. Non perché uno dei due sia sbagliato, ma perché entrambi appartengono a un modello ormai in transizione. In entrambi i casi, il paradigma resta lo stesso: il modello usa strumenti esterni. Cambia il modo, non cambia la logica.
Quello che sta emergendo, invece, è un passaggio diverso. Non più tool separati, ma ambienti operativi controllati. Non più integrazione di connettori, ma capacità di agire direttamente su un contesto. È una differenza sottile, ma profonda.
Quando il modello lavora attraverso tool, ogni azione è mediata. Deve scegliere uno strumento, inviare parametri, attendere una risposta, interpretarla, decidere il passo successivo. È un ciclo continuo di traduzione tra intenzione e operazione. Con un ambiente operativo, questo ciclo si accorcia. Il modello non interroga solo strumenti, ma interagisce con uno spazio di lavoro.
È qui che iniziano a comparire esperienze come la modalità “Computer” introdotta in alcuni ambienti AI (Perplexity, ti ho sempre amato! 😊). Non è più una semplice lista di tool. È un contesto in cui il modello può leggere file, aprire documenti, navigare, scrivere, modificare. Non si tratta più di chiamare funzioni, ma di operare direttamente.
Questo cambia anche la percezione della complessità. I connettori diventano meno centrali, perché molte capacità sono già integrate nell’ambiente. La CLI perde importanza, perché l’interazione non è più sequenziale. Il modello non deve più passare da uno strumento all’altro, ma muoversi all’interno di un sistema coerente.
Non è necessariamente più semplice. Ma è più naturale. L’agente non deve più decidere quale tool usare per leggere un file, perché leggere file è una capacità implicita dell’ambiente. Non deve più scegliere tra più connettori per navigare, perché la navigazione è già parte del processo.
È un cambio di livello. Non più integrazione di strumenti, ma costruzione di contesti operativi. Non più orchestrazione di chiamate, ma orchestrazione di azioni. La differenza è sottile, ma diventa evidente quando osservi il comportamento complessivo: meno deviazioni, meno routing ambiguo, meno rumore.
In questo scenario, MCP e CLI diventano tecnologie di transizione. Utili, spesso necessarie, ma non definitive. Servono a collegare il modello al mondo esterno. Gli agenti operativi, invece, iniziano a portare il mondo esterno dentro il modello, sotto forma di ambiente controllato.
Non è ancora uno standard. Non è ancora stabile. Ma è sufficiente per intuire la direzione. Non stiamo più costruendo sistemi che collegano tool, ma sistemi che definiscono spazi di azione. E quando il modello agisce dentro uno spazio, la scelta del singolo connettore diventa meno rilevante.
5 Concetti che devi capire per non impazzire con la AI operativa
Quando inizi a lavorare con MCP, CLI e interazione agentica, ti accorgi che il problema non è tanto tecnico quanto concettuale. Le difficoltà nascono spesso perché stiamo usando categorie vecchie per descrivere sistemi nuovi. E senza un cambio di lessico, diventa difficile anche progettare.
Ci sono almeno cinque concetti che iniziano a emergere con chiarezza. Non sono definizioni accademiche, ma strumenti mentali per orientarsi.
Il primo è MCP, che non è tanto un protocollo quanto un livello di mediazione. Serve a rendere disponibili capacità al modello. Ma ogni capacità esposta diventa anche contesto e quindi consumo. L’MCP non aggiunge solo integrazione, aggiunge complessità latente. Funziona bene quando i tool sono pochi, diventa rumoroso quando crescono. Insomma, alle volte ti perdi e o molli o ti metti a piangere (succede solo a me?).
Il secondo è la context window. Non come limite tecnico, ma come spazio cognitivo. Tutto ciò che il modello deve sapere per operare occupa questo spazio. Tool, istruzioni, descrizioni, output intermedi. Quando il contesto si riempie, il comportamento cambia. Non si rompe, ma diventa più incerto. La context window non è solo memoria, è anche qualità decisionale.
Il terzo è la token economy. È il punto in cui l’architettura incontra il costo. Ogni capacità caricata nel contesto ha un peso. Ogni passaggio intermedio ha un prezzo. Non è immediatamente visibile, perché il sistema continua a funzionare. Ma nel tempo, la differenza tra un’architettura pulita e una rumorosa diventa concreta. Non solo in performance, ma in fatturazione.
Il quarto è l’interazione agentica. Qui il modello non esegue semplicemente comandi, ma pianifica. Decide sequenze, valuta alternative, modifica il percorso. Non è autonomia totale, ma comportamento strutturato. È il passaggio da un modello che usa tool a un modello che costruisce azioni. Cambia il modo in cui pensiamo all’orchestrazione.
Il quinto è il runtime operativo. Non più tool isolati, ma ambiente. Il modello lavora dentro uno spazio che integra capacità di base: file, navigazione, scrittura, modifica. Le azioni non passano più da chiamate esterne, ma avvengono dentro il contesto operativo. Questo riduce la necessità di connettori e sposta l’attenzione sulla progettazione dell’ambiente.
Questi cinque concetti non offrono una soluzione. Offrono una mappa. Servono a capire perché alcune configurazioni funzionano meglio, perché altre diventano instabili, perché i costi crescono senza un apparente motivo. Non risolvono la complessità, ma permettono di leggerla.
Ed è spesso sufficiente. Perché quando la complessità diventa leggibile, smette di sembrare casuale.
Chiosa: meno magia, più architettura
L’idea che la AI stia diventando sempre più semplice è rassicurante, ma probabilmente fuorviante. Ogni nuovo livello di integrazione promette di ridurre la complessità e ogni volta la complessità si sposta altrove. Prima nei prompt, poi nei tool, poi nei connettori, ora negli ambienti operativi.
L’MCP nasce per collegare strumenti. La CLI per riprendere il controllo. L’interazione agentica per orchestrare comportamenti. Gli agenti operativi per integrare tutto in un contesto unico. Non è una sequenza lineare, ma una stratificazione. Ogni livello non sostituisce il precedente, lo assorbe.
In questo scenario, cercare una soluzione definitiva diventa quasi un errore prospettico. Non esiste un punto di arrivo stabile. Esiste una direzione. E la direzione sembra spostarsi dalla connessione degli strumenti alla progettazione dell’ambiente.
È un cambiamento silenzioso. Non si annuncia con nuove API o protocolli, ma con modalità operative diverse. Il modello non chiede più quale tool usare, ma agisce. Non seleziona, ma si muove. Non integra, ma opera. E quando il comportamento cambia, cambiano anche le domande che dobbiamo farci.
Non più “quale connettore aggiungere”, ma quale rumore eliminare. Non più “quale tool esporre”, ma quale contesto costruire. Non più “come automatizzare”, ma come orchestrare.
L’MCP, in questo senso, non è morto. È semplicemente diventato visibile. Ha reso evidente il costo della mediazione, il peso del contesto, l’ambiguità delle scelte. Ha mostrato che l’integrazione, da sola, non basta. Serve un’architettura.
Forse è questo il passaggio più interessante. La AI non sta diventando plug and play. Sta diventando architetturale. Richiede scelte, rinunce, progettazione. Non per limitare la potenza, ma per renderla leggibile.
E mentre iniziano a comparire agenti che operano direttamente su ambienti completi, la domanda torna a essere quella iniziale, ma con un significato diverso. Non più come collegare tutto, ma come far lavorare bene ciò che resta.
Non è una soluzione. È uno scenario. E, almeno per ora, sembra sufficiente.
Fabrizio Gabrielli – Chi sono – scrivo di tecnologia, cultura digitale e architetture del presente con uno sguardo laterale, tecnico e non addomesticato. Su fabri.news la AI non è una scorciatoia narrativa, ma un territorio da osservare con precisione, dubbio e senso della misura.
Altri percorsi nerd da fabri.news
Quattro articoli tra AI, scrittura digitale, prompt e lavoro autonomo ragionato.
Markdown for Agents, SEO e AI Visibility — Un approfondimento sul Markdown come formato chiaro, portabile e leggibile anche per agenti AI e sistemi di retrieval.
