Systems Design Meditation · Edition 2
Dopo le API
Perché MCP segnala un nuovo livello infrastrutturale
Edward Calderón
Architetto del Software
Le API hanno connesso il software. Gli agenti introducono software che deve decidere a quale software connettersi.
Un'integrazione convenzionale inizia dalla conoscenza: lo sviluppatore seleziona un endpoint, ne studia lo schema e scrive codice deterministico attorno ad esso. Il chiamante conosce il servizio e di solito conosce l'operazione. Il software agentico cambia questa premessa. Potrebbe dover scoprire capacità, comprenderne le descrizioni, scegliere tra di esse e trasportare il contesto oltre il confine.
Dall'invocazione alla scoperta
REST, RPC e i flussi di eventi restano essenziali. MCP non li rende obsoleti. Affronta un livello diverso: presentare strumenti, risorse e prompt a client guidati da modelli attraverso un'interfaccia condivisa. L'operazione sottostante può essere ancora una chiamata API, una query al database o un processo locale.
Questa distinzione conta. La scoperta non è semplicemente un SDK più gradevole. Una macchina che seleziona una capacità ha bisogno di nomi e descrizioni che supportino un ragionamento corretto, di schemi che vincolino gli input e di confini di sicurezza espliciti. Una descrizione ambigua di uno strumento è un difetto architetturale, perché modifica il comportamento di selezione.
La specifica di MCP definisce un'architettura client-host-server e una negoziazione delle capacità. Avverte inoltre gli implementatori di preservare il consenso, la privacy dei dati e la sicurezza degli strumenti. Questi sono indizi sul nuovo livello: lo scambio di contesto non può essere separato dall'autorità.
Ciò che mi interessa non è se MCP diventerà il protocollo definitivo. È che l'interazione tra agenti e sistemi è diventata abbastanza importante da richiedere un livello di protocollo. Il protocollo può cambiare. Il bisogno resterà.
Il piano di controllo attorno agli strumenti
Un utile ecosistema di strumenti per agenti ha bisogno di più di un catalogo. Ha bisogno di ciclo di vita e governance. Chi ha registrato uno strumento? Quale versione è attiva? Quale tenant può vederlo? La scoperta implica un permesso o solo una consapevolezza? Come vengono contrassegnati i risultati come non attendibili? Cosa succede quando un server scompare a metà di un flusso di lavoro?
Queste sono domande sui sistemi distribuiti. I servizi falliscono in modo indipendente. Gli schemi evolvono. I tentativi ripetuti possono duplicare gli effetti collaterali. L'agente può conservare un contesto obsoleto. Una chiamata a uno strumento che appare atomica al modello può estendersi su diverse operazioni non atomiche sottostanti.
Immaginate un agente operativo che sceglie tra strumenti per leggere la telemetria, creare un incidente e modificare la capacità. La scoperta dovrebbe esporre tutte e tre le capacità, ma l'autorizzazione non dovrebbe essere uniforme. La lettura può essere ampia. La creazione di un incidente dovrebbe essere idempotente. Le modifiche alla capacità dovrebbero richiedere policy più stringenti e includere un intervallo delimitato. Un protocollo condiviso aiuta a descrivere l'interfaccia; la piattaforma deve comunque far rispettare il confine.
I confini tra fornitori rendono tutto questo più importante. Le organizzazioni useranno più fornitori di modelli e centinaia di servizi interni ed esterni. Gli adattatori su misura creano accoppiamento in entrambe le direzioni. Un livello di protocollo può permettere a uno strumento di evolvere senza che ogni client debba imparare la sua integrazione privata, e permettere a un client di cambiare senza che ogni servizio venga riscritto.
Standardizzazione senza mitologia
Gli ecosistemi importanti spesso accelerano quando le interfacce diventano prevedibili. Ma le analogie possono nascondere più di quanto spieghino. MCP non è semplicemente «il nuovo HTTP». HTTP trasporta rappresentazioni tra componenti di rete. MCP definisce convenzioni per il contesto e le capacità rivolte ai modelli, usando comunemente trasporti esistenti al di sotto.
L'affermazione architetturale utile è più ristretta. Le interfacce standard riducono il numero di accordi bilaterali necessari affinché i componenti cooperino. Creano spazio per la strumentazione: registri, gateway, motori di policy, ambienti di test e osservabilità. Rendono inoltre i fallimenti confrontabili.
La standardizzazione non crea automaticamente interoperabilità. Due server possono implementare lo stesso protocollo usando semantiche incompatibili. Uno strumento chiamato `search` può cercare nei documenti di un cliente, nel web pubblico o in un database operativo. La qualità semantica, la provenienza e la fiducia restano questioni di sistema.
Questo suggerisce un design a strati. Usare i protocolli per la scoperta e lo scambio. Usare identità e policy per l'autorizzazione. Usare contratti di dominio per il significato. Usare tracciamento e registri di audit per la responsabilità. Usare API ordinarie e code per un'esecuzione affidabile. Nessun singolo strato dovrebbe fingere di risolvere gli altri.
Per chi costruisce, il valore immediato di MCP non è quindi una promessa di universalità. È una pressione pratica verso il disaccoppiamento dei client dei modelli dalle implementazioni degli strumenti. Ciò rende la sperimentazione meno costosa e la sostituzione più reversibile.
I protocolli contano perché permettono ai sistemi di evolvere in modo indipendente.