Il test di Simon di Anthropic mette in luce gli attriti dietro le connessioni MCP personalizzate

L'osservatore di Anthropic Simon Willison ha collegato un server MCP personalizzato a Claude e ChatGPT, ma l'esperimento ha evidenziato due percorsi di configurazione molto diversi. Il suo test del 29 luglio ha mostrato che le interfacce chat standard possono utilizzare strumenti creati dagli sviluppatori, nonostante vincoli di prodotto, requisiti di hosting remoto e lavoro di autorizzazione.

L'esperimento di Simon di Anthropic è rilevante perché il Model Context Protocol sta andando oltre gli agenti di coding e i file di configurazione desktop. MCP, un protocollo aperto per collegare applicazioni AI a strumenti e dati esterni, sta raggiungendo le finestre chat di tutti i giorni. Questo ne amplia il pubblico, rendendo al tempo stesso più difficili da ignorare le restrizioni a livello di prodotto.

Claude presenta la connessione come un connettore personalizzato. ChatGPT colloca funzionalità analoghe dietro il proprio sistema di app e i controlli per sviluppatori. Entrambi possono raggiungere un server remoto, ma nessuno dei due trasforma quel server in un plug-in universalmente portabile. Il protocollo standardizza la comunicazione, mentre ogni host continua a controllare rilevamento, autorizzazioni, approvazioni e disponibilità.

Cosa ha effettivamente cambiato il test MCP di Simon Willison

Un server MCP personalizzato può ora servire sia Claude sia ChatGPT senza richiedere agli utenti di lasciare le loro normali conversazioni sul web.

Willison ha documentato il processo in un test MCP personalizzato pubblicato il 29 luglio 2026. Il risultato centrale era semplice. Uno sviluppatore può ospitare un server MCP, registrarlo presso entrambi i servizi ed esporne gli strumenti nelle loro normali interfacce chat.

Questo risultato distingue l'esperimento dalle precedenti dimostrazioni MCP incentrate su Claude Code, file di configurazione desktop o client orientati agli sviluppatori. Quegli ambienti rendevano già relativamente naturale il collegamento degli strumenti. I prodotti chat consumer standard applicano un ulteriore livello di regole dell'account e controlli dell'interfaccia.

Il server deve essere raggiungibile da remoto. Un processo locale che utilizza il trasporto standard di input e output non può semplicemente comparire in una sessione del browser. L'host necessita di un endpoint HTTP accessibile da Internet che implementi le parti di MCP previste da ciascun client.

L'accesso remoto cambia il modello di distribuzione. Uno sviluppatore non sta più configurando un'applicazione affinché avvii un processo fidato su un computer personale. Sta gestendo un servizio di rete che deve occuparsi di sicurezza del trasporto, identità, autorizzazione, disponibilità e potenzialmente di più utenti.

Claude descrive queste integrazioni come connettori personalizzati. Anthropic afferma che possono collegare Claude a strumenti e fonti di dati ospitati tramite server MCP remoti. Le sue attuali indicazioni sui connettori elencano il supporto di Claude e Claude Desktop per account individuali e aziendali idonei.

ChatGPT descrive la stessa capacità generale tramite app personalizzate e connettori MCP. L'interfaccia di OpenAI distingue inoltre tra creare un'app, testarla, approvarla e renderla disponibile all'interno di uno spazio di lavoro.

Questa differenza terminologica è più che cosmetica. “Connettore” suggerisce un ponte verso un servizio esistente. “App” suggerisce qualcosa di pacchettizzato, revisionato e distribuito tramite una superficie di prodotto controllata dall'host. MCP può supportare entrambi i modelli, ma le etichette plasmano le aspettative degli utenti.

Il server necessita inoltre di definizioni degli strumenti utili. Tali descrizioni indicano al modello cosa fa ciascuno strumento, quando dovrebbe essere chiamato e quali input accetta. Un endpoint tecnicamente valido può comunque avere prestazioni scarse quando i suoi strumenti si sovrappongono o usano descrizioni vaghe.

Il test di Willison ha quindi dimostrato interoperabilità a livello di protocollo, non un comportamento identico tra prodotti. Claude e ChatGPT possono rilevare le stesse capacità di base. Possono comunque selezionare strumenti in modo diverso, richiedere approvazioni differenti e presentare i risultati attraverso interfacce diverse.

Per gli sviluppatori, il fatto più memorabile non è che entrambe le aziende supportino MCP in qualche forma. Il cambiamento importante è che una singola implementazione ospitata può ora raggiungere gli utenti all'interno di entrambi i principali prodotti chat. Questo rende pratici i test cross-product senza mantenere due protocolli di integrazione completamente separati.

Perché il risultato di Simon di Anthropic mette sotto pressione entrambe le piattaforme AI

MCP sposta una parte della competizione dall'intelligenza del modello verso il controllo su strumenti, autorizzazioni e distribuzione.

Il risultato di Simon di Anthropic mette pressione su Anthropic perché ha creato MCP e promosso il protocollo come standard aperto. Claude deve restare un client di riferimento convincente. Se i server esterni funzionano in modo più prevedibile altrove, la paternità del protocollo non garantirà la preferenza della piattaforma.

OpenAI affronta la pressione opposta. Non ha originato MCP, ma ChatGPT svolge un ruolo enorme come piattaforma applicativa. Gli sviluppatori si aspetteranno che supporti integrazioni che già funzionano con Claude e altri client MCP.

Questo crea una chiara competizione tra portabilità del protocollo e controllo della piattaforma. Gli sviluppatori vogliono descrivere uno strumento una sola volta e collegarlo a prodotti compatibili. Gli operatori delle piattaforme vogliono decidere quali account possano connettere server, quali azioni siano consentite e come vengano valutate le chiamate rischiose.

Claude offre attualmente un concetto diretto di connettore personalizzato per diversi tipi di account. L'uso aziendale introduce controlli da amministratore perché un connettore può esporre dati aziendali o eseguire azioni. Un proprietario può configurarne la disponibilità, mentre i singoli utenti continuano ad autenticarsi in base ai propri permessi.

ChatGPT applica una struttura di distribuzione più esplicita. L'attuale guida alla modalità sviluppatore di OpenAI afferma che il supporto MCP completo è disponibile sul web per i clienti Business ed Enterprise o Edu. Descrive inoltre un accesso più limitato di lettura e recupero dati per gli utenti Pro.

La distinzione diventa importante quando un server espone operazioni di scrittura. Cercare in una raccolta di documenti comporta un profilo di rischio. Aggiornare record dei clienti, pubblicare contenuti o eliminare un progetto ne comporta un altro.

OpenAI afferma che le azioni di scrittura e modifica possono attivare una conferma, a seconda dell'autorizzazione, del contesto e del potenziale impatto. Alcune azioni particolarmente rischiose possono essere bloccate. Gli amministratori dello spazio di lavoro controllano inoltre se un'app passa dal test privato alla disponibilità approvata.

Anthropic invita analogamente gli utenti a ispezionare le richieste degli strumenti e ad abilitare solo quelli pertinenti a una conversazione. Il suo avvertimento riflette una limitazione di base delle interfacce agentiche. Una richiesta in linguaggio naturale non rivela sempre ogni azione esterna che un modello potrebbe ritenere necessaria.

Questi controlli indeboliscono la promessa più semplice di portabilità. Uno sviluppatore può riutilizzare il server, gli schemi e la base di autorizzazione. Non può presumere accesso, flussi utente, comportamenti di conferma o decisioni del modello equivalenti.

Questa frammentazione non è necessariamente un fallimento del protocollo. MCP definisce un linguaggio condiviso tra client e server. Non impone a ogni host di adottare le stesse politiche di prodotto.

Tuttavia, l'attrito a livello di prodotto può determinare se la compatibilità del protocollo conti nella pratica. Una connessione nascosta dietro impostazioni amministrative raggiungerà meno utenti di una disponibile in una schermata delle impostazioni personali. Un'implementazione di sola lettura non può sostituire un concorrente che consente scritture attentamente approvate.

La qualità dell'invocazione degli strumenti aggiunge un'altra fonte di pressione. Il modello deve scegliere lo strumento corretto, produrre argomenti validi, interpretare gli errori e comunicare i risultati. Il supporto di un trasporto MCP non garantisce il completamento affidabile dell'attività dell'utente.

Gli sviluppatori dovrebbero quindi testare gli stessi prompt su entrambe le piattaforme. Un server potrebbe esporre strumenti identici producendo però schemi di chiamata diversi. Tali differenze possono rivelare se una descrizione è ambigua o se un host applica controlli più rigorosi.

La questione competitiva più ampia non è più se Claude o ChatGPT possano chiamare un'API. Entrambe le piattaforme possono farlo. Il problema è quale delle due renda le capacità esterne comprensibili, governabili e affidabili per gli utenti comuni.

Un solo protocollo produce comunque due esperienze di configurazione

MCP riduce il codice di integrazione duplicato, ma non elimina i passaggi operativi che circondano una connessione sicura.

Per Claude, il percorso di base passa da Settings e Connectors. Un utente aggiunge un connettore personalizzato, fornisce l'indirizzo del server remoto e completa l'autenticazione quando il server la richiede. I proprietari degli spazi di lavoro potrebbero dover prima abilitare o configurare il connettore.

La documentazione sui server di Anthropic indirizza gli sviluppatori verso la specifica di autorizzazione del protocollo e gli esempi SDK ufficiali. Segnala inoltre il supporto agli attuali modelli di autorizzazione remota.

Per ChatGPT, il percorso passa da Apps e dalle impostazioni avanzate. L'utente o l'amministratore abilita l'accesso per sviluppatori, crea un'app, inserisce l'URL MCP remoto, sceglie l'autenticazione e accetta l'avviso associato a un server personalizzato.

Gli amministratori degli spazi di lavoro Business possono creare e distribuire app per il proprio spazio di lavoro. Gli ambienti Enterprise ed Edu aggiungono controlli basati sui ruoli per sviluppatori e utenti. Queste regole rendono la connessione parte della governance organizzativa, non una semplice configurazione personale.

Il centro tecnico condiviso è un endpoint MCP remoto. I moderni server remoti usano comunemente Streamable HTTP, un trasporto che veicola messaggi MCP tramite richieste HTTP e risposte in streaming. Tale endpoint deve supportare gli scambi di inizializzazione e rilevamento degli strumenti previsti dai client compatibili.

I messaggi MCP utilizzano JSON-RPC 2.0, un formato strutturato per richieste, risultati, notifiche ed errori. Il protocollo definisce come un client rileva e invoca gli strumenti. Non definisce la logica di business sottostante a ciascuno strumento.

Si consideri un server di ricerca privato. Potrebbe offrire uno strumento per cercare documenti archiviati e un altro per recuperare un record completo. Claude e ChatGPT possono rilevare tali definizioni dallo stesso endpoint.

Lo sviluppatore deve comunque decidere chi può cercare in quali record. Tale decisione appartiene al server e al suo livello di autorizzazione. Nascondere uno strumento nell'interfaccia di un client non sostituisce l'applicazione dei controlli di accesso alla fonte dei dati.

OAuth diventa centrale quando il server gestisce dati specifici dell'utente. Il client guida l'utente attraverso un flusso di autorizzazione, riceve un token di accesso e presenta quel token quando chiama il server MCP protetto. Il server convalida quindi il token prima di restituire i dati.

La specifica di autorizzazione di MCP richiede metadati della risorsa protetta per le implementazioni di autorizzazione HTTP conformi. Tali metadati indicano a un client dove sono collocati i servizi di autorizzazione. Supportano il rilevamento senza codificare rigidamente ogni abbinamento client-server.

È qui che una prova rapida diventa un vero progetto di ingegneria. Il server necessita di un indirizzo HTTPS stabile, metadati corretti, gestione dei reindirizzamenti, convalida dei token e ambiti appropriati. Necessita inoltre di messaggi di errore che i client possano interpretare quando l'autorizzazione fallisce.

La registrazione del client può creare un altro problema di compatibilità. Alcuni sistemi supportano la registrazione dinamica o documenti di metadati del client. Altri prevedono un identificatore client creato in anticipo. Un server progettato attorno a un'assunzione potrebbe richiedere adattamenti prima che entrambi i prodotti chat si autentichino correttamente.

Un’implementazione pratica dovrebbe iniziare con uno strumento ristretto e di sola lettura. Per esempio, un team potrebbe esporre le note di progetto approvate tramite un’unica funzione di ricerca. Gli utenti potrebbero chiedere a entrambi gli assistenti di trovare decisioni precedenti senza concedere diritti di aggiornamento o eliminazione.

Questo caso d’uso crea anche un collegamento naturale a una base di conoscenza personale o di team. MCP può fornire il livello di accesso, mentre il sistema sottostante resta responsabile di indicizzazione, autorizzazioni, conservazione e qualità delle fonti.

Dopo che il percorso di lettura funziona, gli sviluppatori possono aggiungere azioni più precise. Ogni strumento di scrittura dovrebbe avere uno scopo evidente e un ambito limitato. “Aggiornare lo stato di un’attività” è più facile da verificare rispetto a “eseguire un’operazione di progetto arbitraria”.

Le descrizioni degli strumenti meritano la stessa cura di un contratto API. Il modello vede tali descrizioni quando decide se chiamare una funzione. Nomi vaghi aumentano la probabilità di una selezione errata, chiamate ripetute o accesso non necessario ai dati.

Anche gli schemi di input dovrebbero rifiutare l’ambiguità. Uno strumento che modifica un account dovrebbe richiedere un identificatore stabile dell’account. Non dovrebbe basarsi soltanto sul nome di un cliente, che potrebbe corrispondere a più record.

Le risposte dovrebbero restituire informazioni strutturate sufficienti perché il modello possa spiegare cosa è accaduto. Uno strumento di scrittura può includere l’oggetto modificato, il suo stato precedente e quello nuovo. Questo aiuta l’host a presentare una conferma significativa.

I test devono coprire più delle sole chiamate riuscite. Gli sviluppatori dovrebbero testare token scaduti, autorizzazioni revocate, dipendenze non disponibili, input malformati e tentativi di accedere ai record di un altro utente. I due host potrebbero mostrare questi errori in modo diverso.

Questo spiega perché aggiungere un server personalizzato possa sembrare lungo nonostante un protocollo aperto. MCP elimina una categoria di duplicazione dell’integrazione. Non elimina distribuzione, identità, revisione della sicurezza, configurazione del prodotto o garanzia della qualità.

Il vero compromesso è tra portabilità e fiducia

La stessa apertura che consente a un server di raggiungere più assistenti conferisce a quel server una posizione privilegiata tra utenti, modelli e sistemi sensibili.

Un server MCP personalizzato può vedere gli input inviati tramite i suoi strumenti. Può restituire contenuti che il modello tratta come contesto. Se espone azioni, può anche modificare dati esterni usando l’identità dell’utente.

Questa combinazione crea diversi confini di fiducia. Gli utenti devono fidarsi del provider della chat, dell’operatore del server MCP, del servizio collegato e dell’implementazione dell’autorizzazione. Le organizzazioni devono inoltre fidarsi delle descrizioni che guidano il comportamento del modello.

Il prompt injection è una preoccupazione rilevante. Un’istruzione dannosa può essere incorporata nei dati recuperati da uno strumento, come un documento, un ticket di assistenza o una pagina web. Il modello potrebbe interpretare quel contenuto come una direttiva anziché come materiale non attendibile.

Il rischio aumenta quando sono disponibili più strumenti. Il contenuto recuperato potrebbe cercare di persuadere il modello a chiamare un altro strumento con argomenti sensibili. Un’operazione di lettura può quindi diventare il primo passo di una sequenza di scrittura non intenzionale.

Sia Anthropic sia OpenAI avvertono gli utenti di connettere solo server affidabili. Questo consiglio è necessario, ma la fiducia non è un controllo di sicurezza completo. Anche un server benintenzionato può contenere errori di autorizzazione o azioni eccessivamente ampie.

Il server deve convalidare ogni richiesta in modo indipendente. Non dovrebbe mai presumere che una chiamata sia sicura perché è stata generata da Claude o ChatGPT. Le conferme dell’host possono aiutare gli utenti, ma non sostituiscono i controlli di accesso lato server.

La gestione dei token richiede particolare attenzione. La specifica MCP vieta il token passthrough, in cui un server inoltra a un altro servizio un token destinato a un servizio specifico. I token dovrebbero avere un pubblico definito e il server ricevente dovrebbe verificarlo.

Il principio del privilegio minimo offre il punto di partenza più chiaro. Un connettore di ricerca dovrebbe richiedere accesso in lettura prima di chiedere accesso in scrittura. Uno strumento per il calendario non dovrebbe richiedere diritti di eliminazione quando deve soltanto elencare le disponibilità.

Anche le operazioni di scrittura traggono vantaggio da una semantica ristretta. Uno strumento chiamato delete_everything è ovviamente pericoloso, ma funzioni amministrative ampie possono nascondere un’esposizione simile dietro nomi più rassicuranti. Ogni azione dovrebbe corrispondere a un intento utente verificabile.

Le operazioni ad alto impatto dovrebbero supportare l’idempotenza, che impedisce alle ripetizioni accidentali di produrre modifiche multiple. Un modello potrebbe ritentare dopo una risposta poco chiara. Senza protezioni, una singola attività richiesta potrebbe creare record o messaggi duplicati.

I registri di audit sono altrettanto importanti. Gli operatori devono sapere quale utente ha autorizzato una chiamata, quale strumento è stato eseguito, quale oggetto è cambiato e se l’host ha riportato una conferma. I log dovrebbero evitare di conservare contenuti di prompt o segreti non necessari.

Gli operatori dei server dovrebbero separare i dati destinati agli utenti dalle istruzioni di controllo. I risultati degli strumenti possono etichettare chiaramente il testo non attendibile e restituire campi strutturati quando possibile. I modelli restano vulnerabili alla manipolazione, ma una progettazione attenta dell’output riduce l’ambiguità.

Anche le piattaforme host affrontano questioni irrisolte. Le loro richieste di approvazione devono fornire informazioni sufficienti perché gli utenti comprendano un’azione. Una richiesta generica di “consentire l’accesso agli strumenti” offre poca protezione quando lo strumento può eseguire diverse operazioni.

Il comportamento degli strumenti può cambiare dopo la connessione. Anthropic osserva esplicitamente che gli sviluppatori di server possono modificare gli strumenti senza preavviso. Un utente che ha approvato un connettore di ricerca innocuo potrebbe in seguito incontrare capacità più ampie dallo stesso endpoint.

Versioning e revisione possono ridurre questo rischio. Le organizzazioni possono bloccare versioni delle distribuzioni, monitorare le modifiche agli schemi e richiedere un’altra revisione quando uno strumento ottiene accesso in scrittura. Gli operatori di server pubblici possono pubblicare changelog e mantenere stabili gli ambiti.

C’è anche una questione di privacy relativa allo spostamento dei dati. Un’azienda può consentire al proprio assistente di cercare nei record interni, vietando però che tali record raggiungano un altro responsabile del trattamento. La posizione di hosting del server MCP e la sua politica di conservazione diventano parte della decisione.

Una distribuzione sicura richiede quindi più di una connessione valida. I team dovrebbero documentare categorie di dati, azioni consentite, ambiti di autenticazione, regole di conservazione, contatti per gli incidenti e procedure di revoca. Dovrebbero inoltre testare come ogni host segnala l’uso degli strumenti.

La dimostrazione anthropic simon prova che la connettività multipiattaforma è possibile. Non dimostra che ogni server raggiungibile sia adatto alla produzione. La compatibilità è l’inizio della valutazione, non la fine.

Questa distinzione conta per i knowledge worker che desiderano che il loro assistente preferito acceda a note private o alla cronologia dei progetti. Un connettore può ridurre la copia tra strumenti. Può anche ampliare il percorso attraverso cui transita un contesto sensibile.

I team che valutano questo compromesso dovrebbero iniziare con informazioni che possono permettersi di esporre con accesso controllato. Una raccolta ricercabile di documentazione ingegneristica approvata è più sicura di un gateway senza restrizioni verso ogni sistema interno.

Possono quindi misurare se l’assistente trova le fonti corrette, rispetta le autorizzazioni e spiega chiaramente l’uso degli strumenti. L’espansione dovrebbe seguire le evidenze, non la mera disponibilità di un endpoint MCP.

Cosa osservare dopo l’esperimento Anthropic Simon

Il prossimo banco di prova per MCP è capire se i server multipiattaforma diventeranno prodotti ordinari anziché integrazioni per specialisti configurate tramite impostazioni avanzate.

Il primo segnale è la convergenza attorno all’autorizzazione remota. Claude e ChatGPT devono entrambi connettere gli utenti in modo sicuro senza lavoro di registrazione personalizzato per ogni abbinamento. L’adozione più ampia si rafforzerà se un’implementazione OAuth conforme agli standard funzionerà in modo affidabile su entrambi.

Se l’autorizzazione resterà piena di eccezioni specifiche per client, la promessa di portabilità si indebolirà. Gli sviluppatori riutilizzeranno comunque parti del server, ma dovranno mantenere istruzioni di configurazione, metadati e percorsi di risoluzione dei problemi separati.

L’evidenza più forte arriverà da servizi ordinari che pubblicheranno un endpoint remoto con istruzioni verificate per diversi assistenti. Tali servizi non dovrebbero richiedere agli utenti di incollare chiavi API di lunga durata nelle impostazioni della chat. Il consenso basato sul browser dovrebbe concedere ambiti ristretti e revocabili.

Il secondo segnale è il modo in cui OpenAI espande l’accesso MCP completo. La documentazione attuale distingue il supporto completo per gli account workplace gestiti da funzionalità Pro più limitate. Un percorso personale più ampio eserciterebbe pressione diretta sull’esperienza dei connettori personalizzati di Claude.

Un’enfasi continua sulla distribuzione da parte degli amministratori indicherebbe una strategia diversa. Le app ChatGPT funzionerebbero principalmente come software workplace governato, mentre Claude potrebbe mantenere un percorso più diretto per la sperimentazione individuale.

Nessuna delle due strade è automaticamente migliore. Le aziende hanno spesso bisogno di approvazione, verificabilità e controlli di ruolo. Gli sviluppatori indipendenti apprezzano un percorso breve da un server distribuito a una conversazione funzionante.

Il terzo segnale è il modo in cui entrambe le piattaforme gestiscono le azioni di scrittura. Ricerca e recupero dei dati offrono dimostrazioni utili, ma le azioni determinano se MCP diventa un vero livello applicativo. Creano anche i problemi più difficili di sicurezza e interfaccia.

Osservate riepiloghi delle autorizzazioni, anteprime delle azioni, politiche di conferma e registri di audit più chiari. Un host che spiega bene gli effetti esterni può rendere gli strumenti di scrittura più utilizzabili senza fingere che siano privi di rischi.

Gli sviluppatori dovrebbero inoltre osservare se gli host espongono diagnostica migliore. I fallimenti di connessione spesso riducono diverse possibili cause a un unico errore. Il problema potrebbe riguardare la negoziazione del trasporto, i metadati di autorizzazione, la configurazione dei redirect, il pubblico del token o la convalida dello schema dello strumento.

Una diagnostica migliore accorcerebbe il percorso da un server locale funzionante a un’integrazione remota affidabile. Ridurrebbe inoltre la pressione sugli operatori dei server affinché decifrino tramite reverse engineering le diverse aspettative degli host.

I sistemi di registry e discovery rappresentano un altro livello importante. Un protocollo aperto non dice agli utenti quali server siano affidabili. Le directory curate possono aiutare, ma offrono anche ai proprietari delle piattaforme un ulteriore punto di controllo.

Un server elencato da un host può restare una connessione personalizzata manuale in un altro. Gli sviluppatori affrontano quindi un problema di distribuzione anche quando la loro implementazione è portabile. Le tempistiche di revisione e le regole di pubblicazione possono diventare elementi di differenziazione competitiva.

Gli utenti dovrebbero quindi distinguere la compatibilità del server dalla disponibilità del server. Un servizio può funzionare tecnicamente con Claude e ChatGPT pur restando difficile da trovare o limitato dalle policy del workspace.

La stessa distinzione si applica al supporto dell’interfaccia. MCP Apps possono restituire interfacce interattive negli host compatibili, mentre i server di strumenti di base scambiano principalmente dati strutturati e testo. Diversi livelli di supporto possono rendere un’integrazione più ricca pur usando lo stesso protocollo sottostante.

Per chi sviluppa, la strategia immediata è conservativa. Ospitate un server remoto conforme agli standard, iniziate con uno strumento di lettura ristretto e testate prompt identici in entrambi i prodotti. Registrate ogni differenza in autenticazione, discovery, invocazione e gestione degli errori.

Successivamente, introducete un’azione di scrittura limitata dietro un’autorizzazione esplicita. Verificate che i tentativi ripetuti non duplichino le modifiche e che la revoca funzioni. Esaminate esattamente ciò che ogni piattaforma mostra prima dell’esecuzione dell’azione.

Per le organizzazioni, la decisione dovrebbe iniziare dal flusso di lavoro anziché dall’entusiasmo per MCP. Identificate un’attività ripetuta in cui l’accesso basato sulla chat riduce il reale sforzo di passare da uno strumento all’altro o di cercare informazioni. Quindi definite l’ambito minimo di dati e azioni necessario per completarla.

Un buon candidato potrebbe cercare documenti tecnici approvati e restituire link alle fonti. Un altro potrebbe preparare una bozza di aggiornamento del progetto senza pubblicarla. Entrambi creano valore mantenendo le modifiche finali sotto controllo umano.

La frase di ricerca anthropic simon probabilmente porterà lettori interessati allo specifico esperimento di Simon Willison. Il suo valore duraturo va oltre la sequenza di configurazione. Il test rivela dove termina la standardizzazione del protocollo e dove iniziano le politiche della piattaforma.

MCP ha superato un confine importante entrando nelle interfacce standard di Claude e ChatGPT. La prossima domanda è se collegare un server affidabile diventerà un’operazione semplice, prevedibile e visibile agli utenti comuni.

Gli sviluppatori possono contribuire a rispondere a questa domanda già ora. Scegliete un flusso di lavoro a basso rischio, create un endpoint remoto con autorizzazioni limitate e confrontate entrambi gli host usando gli stessi prompt di test. Le differenze mostreranno se MCP sta offrendo una portabilità concreta o soltanto una base tecnica condivisa.