MCP protocol: come collegare agenti AI ai sistemi aziendali

Un assistente AI che non può leggere il tuo CRM è un chatbot. Lo stesso assistente, collegato al gestionale, all’ERP e al filesystem aziendale, diventa un collega. In mezzo, oggi, c’è quasi sempre lo stesso pezzo di infrastruttura: l’MCP protocol, il Model Context Protocol che Anthropic ha rilasciato come standard aperto il 25 novembre 2024 e che nel giro di due anni è diventato il modo predefinito di collegare un modello linguistico ai sistemi che contengono i dati veri di un’azienda.

Questa guida non si ferma alla definizione, quella la trovi già nell’AI Overview di Google. Serve a rispondere alle domande che vengono dopo: come è fatto il protocollo davvero, in cosa differisce dal function calling e dalle API REST che hai già, cosa significa in concreto scrivere un connettore per Salesforce o SAP, e perché il pezzo difficile non è il protocollo ma l’onboarding.

In questo articolo scoprirai:

• Che cos’è il protocollo MCP e a cosa serve in azienda
• Come funziona MCP: architettura host, client e server
• MCP, function calling e API REST: che differenza c’è davvero
• Se un sistema non ha API né server MCP: l’agente che usa il browser
• Cambiare modello senza rifare l’integrazione: quanto vale la portabilità
• Connettori MCP per CRM ed ERP: cosa succede quando tocchi i gestionali
• Scrivere un connettore MCP custom: cosa contiene un server aziendale fatto bene
• Sicurezza dei server MCP: i rischi che vengono con la comodità
• Configurazioni MCP esposte: cosa trova una scansione dei server pubblici
• Dal protocollo all’agente che serve: perché il connettore è solo metà del lavoro

Che cos’è il protocollo MCP e a cosa serve in azienda

Il Model Context Protocol è uno standard aperto che definisce come un’applicazione AI chiede contesto e azioni a un sistema esterno. L’analogia che ricorre nella documentazione ufficiale è quella della porta USB-C per l’intelligenza artificiale: una presa sola, uguale per tutti, al posto di un cavo diverso per ogni dispositivo. Anche IBM lo descrive come lo standard che uniforma il modo in cui le applicazioni forniscono contesto ai large language model.

Il problema che il protocollo MCP risolve: da N×M a N+M

Il problema che risolve ha un nome preciso in letteratura: Databricks lo chiama “N×M integration problem”. Senza uno standard comune, ogni applicazione AI deve integrarsi individualmente con ogni servizio esterno: cinque modelli e venti sistemi aziendali fanno cento connettori da scrivere e mantenere. MCP riduce le integrazioni totali da N×M a N+M, perché ogni client e ogni server implementano il protocollo una volta sola. È una differenza che non si vede il primo giorno e si vede moltissimo al secondo anno di manutenzione.

Chi ha adottato il protocollo MCP finora

Al lancio Anthropic ha pubblicato server MCP pronti per Google Drive, Slack, GitHub, Git, Postgres e Puppeteer, con Block e Apollo fra i primi ad adottarlo in produzione. Da lì in poi l’adozione ha smesso di essere una questione di ecosistema: OpenAI ha adottato MCP a marzo 2025, a partire dal supporto nativo nell’Agents SDK, e oggi il protocollo è supportato trasversalmente dai principali host AI. Se stai valutando dove collocarlo rispetto agli altri standard emergenti, abbiamo dedicato un pezzo al confronto fra MCP e A2A, i due protocolli che ridisegnano l’AI agentica: il primo collega un agente ai sistemi, il secondo gli agenti fra loro.

Una precisazione che conta per chi legge documentazione: MCP si occupa solo dello scambio di contesto. Non dice come l’applicazione debba usare il modello, né come gestire il contesto ricevuto. È un protocollo di trasporto semantico, non un framework di agenti.

Come funziona MCP: architettura host, client e server

L’architettura è client-server, ma con una terminologia che vale la pena fissare perché le tre parole vengono usate a sproposito ovunque. Secondo l’architecture overview della specifica ufficiale:

• MCP Host: l’applicazione AI che coordina tutto, Claude Desktop, Visual Studio Code, ChatGPT.
• MCP Client: il componente che mantiene la connessione verso un server. Relazione 1:1.
• MCP Server: il programma che espone dati e azioni, indipendentemente da dove gira.

Se VS Code si collega al server di Sentry e a quello del filesystem locale, istanzia due client distinti. Un host con dieci integrazioni ha dieci client. Questa è la struttura che rende il sistema componibile: aggiungere una fonte dati non tocca le altre. Per la parte implementativa vera e propria, SDK, configurazione, deploy, trovi tutto nella nostra guida completa al Model Context Protocol e agli MCP server.

I due layer del protocollo MCP: dati e trasporto

MCP è diviso in un data layer basato su JSON-RPC 2.0, che definisce messaggi e semantica, e un transport layer, che definisce il canale. I trasporti sono due: stdio, per processi locali sulla stessa macchina, senza overhead di rete; e Streamable HTTP, per i server remoti, con POST HTTP e Server-Sent Events opzionali per lo streaming. Sul trasporto remoto la specifica raccomanda OAuth per ottenere i token.

La distinzione locale/remoto non è un dettaglio operativo. Cloudflare, già a marzo 2025, la descriveva come «la transizione dal software desktop al software web»: i server locali restano roba da sviluppatori, quelli remoti raggiungono un pubblico enormemente più largo. Per un’azienda che vuole dare un agente a cinquanta persone, il server remoto non è un’opzione: è l’unica strada.

Le primitive: tools, resources e prompts

Un server MCP può esporre tre primitive. I tools sono funzioni eseguibili (query, scritture, chiamate API). Le resources sono fonti di dati che forniscono contesto senza eseguire azioni (uno schema di database, il contenuto di un file). I prompts sono template riutilizzabili di interazione. Ogni primitiva ha i suoi metodi di scoperta (*/list) e di esecuzione (tools/call).

Lato client, la specifica corrente, la 2026-07-28, mantiene l’elicitation, con cui il server può chiedere all’utente un’informazione mancante o la conferma di un’azione, e ha deprecato sampling e logging. Chi trova ancora tutorial che li presentano come funzionalità correnti sta leggendo materiale vecchio.

MCP, function calling e API REST: che differenza c’è davvero

È la domanda che compare in tutte le SERP inglesi («Come è diverso MCP da API?», «Can MCP replace REST API?») e a cui in italiano quasi nessuno risponde. Vale la pena farlo bene, perché è qui che si prendono le decisioni architetturali sbagliate.

MCP non sostituisce le API REST: le avvolge

La risposta corta è che MCP e REST non competono. Come sintetizza l’analisi di WorkOS, «gli MCP server usano internamente le API REST per fare il lavoro vero»: il server MCP sta sopra, gestisce discovery, sessione e autorizzazione; la tua API REST resta sotto e contiene la business logic. Continui a servire la web app con REST e affianchi un server MCP come nuovo strato di interfaccia per gli agenti.

Il criterio di scelta è il consumatore. REST quando il client è codice scritto da uno sviluppatore, deterministico, con throughput alto e caching HTTP. MCP quando il consumatore è un agente AI che deve scoprire a runtime cosa può fare, incatenare più passaggi e ricevere autorizzazioni granulari. Chi prova a esporre l’ERP direttamente al modello via REST scopre in fretta che manca tutto lo strato di descrizione semantica che l’LLM usa per decidere.

Rispetto al function calling: il tool esce dall’applicazione

La differenza con il function calling classico è più sottile ma più importante. Il function calling esiste da prima di MCP e funziona: descrivi una funzione al modello, il modello la invoca. Il problema è che quella descrizione vive dentro la tua applicazione e parla il dialetto di un fornitore. Come nota l’analisi tecnica di CodiLime, «senza un approccio standardizzato, ogni combinazione di modello e strumento richiede un adattatore unico».

MCP prende quella stessa idea e la sposta fuori dall’applicazione, dentro un server con un’interfaccia JSON-RPC uguale per tutti. Il guadagno concreto è triplice: lo stesso tool funziona con Claude, GPT e Gemini senza riscritture, l’autenticazione e le ACL si centralizzano nel server invece di stare sparse negli agenti, e team diversi possono contribuire nuove capacità senza reinventare l’integrazione. Il function calling è una feature del modello; MCP è un contratto fra sistemi.

Se un sistema non ha API né server MCP: l’agente che usa il browser

C’è una terza risposta, ed è arrivata sul mercato dopo la prima stesura di questa guida. L’11 agosto 2026 xAI ha presentato Grok Bot, agenti sempre attivi che ricevono un proprio computer in cloud con browser, filesystem e terminale, fanno il login ai tool con le credenziali dell’utente e portano a termine lavori in più passaggi mentre la persona non c’è. La premessa del prodotto è dichiarata: i bot lavorano dentro le stesse app, caselle di posta e siti web che userebbe un dipendente umano, «comprese le piattaforme senza una API pulita o un’integrazione MCP». Più bot possono girare in parallelo e passarsi il lavoro in una chat di gruppo, che è il territorio di A2A più che di MCP.

Va preso sul serio, perché è il rovescio esatto dell’argomento di questa guida: dove MCP chiede che qualcuno scriva un server, l’agente che guida il computer non chiede il permesso a nessuno. Su un verticale del 1998 senza API, o su un portale della pubblica amministrazione, oggi è spesso l’unica strada praticabile.

Computer use o MCP: la differenza è di governance

I due approcci però non costano lo stesso, e la differenza è di governance più che di capacità. L’agente che naviga eredita i permessi della persona di cui usa le credenziali, non un perimetro che hai disegnato tu, e ciò che fa resta a log come attività di quell’utente: è l’opposto dello schema con token propri e ACL centralizzate che vedremo nella sezione sicurezza. Inoltre dipende dal fatto che l’interfaccia non cambi, mentre un tool MCP con inputSchema dichiarato si rompe in modo visibile e verificabile. Che xAI tenga l’accesso enterprise su lista d’attesa separata dice qualcosa su quanto quella differenza pesi in azienda. La regola pratica: computer use dove non esiste alternativa, MCP dove i dati contano e l’accesso va governato. Quando invece il server c’è, il lavoro cambia natura — è quello che un’integrazione MCP reale come quella di Strava insegna alle PMI.

Cambiare modello senza rifare l’integrazione: quanto vale la portabilità

Quando MCP è uscito, l’argomento della portabilità suonava come una promessa da architetti: elegante in teoria, difficile da mettere in un business case. Nel 2026 ha smesso di essere teorico, perché le aziende hanno cominciato a cambiare modello davvero, e in fretta.

Le imprese spostano la spesa in poche settimane

Il segnale più netto non arriva dai benchmark ma dai pagamenti. Secondo l’analisi di Ramp su 70.000 imprese, il modello di punta di Anthropic, Fable 5, si è fermato all’11,4% della spesa in dollari e al 6% dei token due mesi dopo il lancio, superato nella spesa aziendale dal più economico Opus 5 entro un mese dall’uscita di quest’ultimo: Fable 5 costa 10/50 dollari per milione di token, il doppio di Opus 5.

Va preso per quello che è, e conviene dirlo: è un dato di spesa raccolto da una piattaforma di pagamenti, non una misura di prestazioni, e non stabilisce quale modello sia migliore. Dice però una cosa che riguarda direttamente chi progetta integrazioni: la scelta del modello ha un’emivita di mesi, non di anni.

Qui il valore di MCP si vede in negativo, cioè da quanto costa non averlo. Se la descrizione dei tuoi tool vive dentro l’applicazione e parla il dialetto di un fornitore, ogni revisione di prezzi diventa un progetto di migrazione. Se vive in un server MCP, diventa una riga di configurazione nell’host. È la stessa ragione per cui conviene ragionare a livello di connettori aziendali che espongono i tool SaaS agli agenti una volta sola: il connettore è l’asset che sopravvive al modello, ed è il motivo per cui, in un’integrazione, il servizio conta più del modello scelto.

L’estate dei pesi aperti e l’agente che gira in casa tua

La seconda spinta arriva da dove un anno fa non arrivava. Quella che Martin Alderson ha chiamato «l’estate dei pesi aperti» è un’estate 2026 in cui almeno cinque laboratori fuori da OpenAI, Anthropic e Google — Z.AI, DeepSeek e Kimi, più Meta e Grok — hanno modelli a pesi aperti di qualità seria. Nella stessa direzione va la rassegna di Hugging Face sullo stato dei modelli aperti: DeepSeek V4 Flash è il primo modello a pesi aperti che i team hanno inserito in pipeline agentiche reali come sostituto plausibile di un modello di frontiera, e Kimi K3, uscito il 16 luglio 2026, arriva a 2,8 trilioni di parametri con una finestra da un milione di token.

Serve però una precisazione tecnica, perché il fraintendimento è comune: MCP non è una capacità dei pesi del modello, è una capacità dell’host. Un modello aperto non «supporta MCP»; lo supporta l’applicazione che lo esegue e che istanzia i client. La conseguenza pratica resta quella che interessa a un’azienda con dati sensibili nel gestionale: gli stessi server MCP scritti per il CRM continuano a funzionare se domani decidi di eseguire il modello sulla tua infrastruttura invece che su un’API di terzi. Per chi valuta quel percorso, la direzione della specifica conta più delle sigle dei modelli, ed è il tema della roadmap MCP 2026 fra sicurezza enterprise e trasporto HTTP-native.

Connettori MCP per CRM ed ERP: cosa succede quando tocchi i gestionali

Fin qui la teoria regge. Poi arrivi al gestionale e cambia tutto, perché i sistemi che contengono i dati che servono davvero, anagrafiche clienti, ordini, ciclo attivo, magazzino, non sono stati progettati per essere interrogati da un modello linguistico.

Il caso SAP: nessun connettore ufficiale, un server da costruire

Prendi SAP, che in Italia è ovunque nella manifattura. Non esiste un connettore ufficiale: la strada è esporre i servizi OData/REST tramite SAP Integration Suite, alzare un MCP server su BTP, proteggere l’endpoint con OAuth e registrarlo come connettore custom. E i limiti sono dichiarati: l’agente «tocca SAP solo dentro un’esecuzione che avvii tu», non reagisce autonomamente agli eventi del gestionale, e soprattutto non c’è nessun «connettore SAP supportato da OpenAI» su cui ripiegare se domani un’API cambia. La manutenzione è interamente a carico di chi l’ha costruito.

È lo scenario che abbiamo già raccontato parlando di come si integrano gli agenti AI con ERP e CRM in presenza di sistemi legacy, e che per le realtà più piccole cambia di scala ma non di natura: anche nella guida dedicata alle PMI italiane il collo di bottiglia resta lo stesso, non il protocollo, ma la mappatura fra i processi reali e ciò che il sistema espone.

Perché i vendor CRM stanno correndo

C’è un segnale di mercato che dice molto su quanto sia diventato serio. A dicembre 2025 Salesforce ha portato Agentforce dentro ChatGPT come app nativa, e la motivazione dichiarata dall’azienda, come riportato da Salesforce Devops, è la preoccupazione per gli MCP server che i clienti si costruiscono in casa e che finiscono per riversare dati verso OpenAI. Tradotto: i vendor temono che i connettori MCP custom aggirino i loro layer di governance, permessi e misurazione dei consumi. Dal lancio dell’SDK per le app in ChatGPT, a ottobre 2025, oltre 35 vendor hanno pubblicato integrazioni.

Per chi compra, la lettura è utile in due direzioni. Il connettore ufficiale del vendor ti dà governance e supporto, ma ti lega al suo perimetro e al suo modello di consumo. Il connettore custom ti dà esattamente i processi che ti servono, inclusi gli oggetti personalizzati e i workflow che nessun vendor ha previsto, al prezzo di doverlo mantenere tu.

Scrivere un connettore MCP custom: cosa contiene un server aziendale fatto bene

Il malinteso più diffuso è pensare che un server MCP sia un wrapper delle API. Tecnicamente lo è; utilmente non basta. Un server che espone cinquanta endpoint tradotti uno a uno produce un agente peggiore di uno che ne espone otto, perché il modello deve scegliere, e più opzioni indistinguibili gli dai, più sbaglia.

Progettare i tools intorno ai processi, non agli endpoint

Il lavoro di design consiste nel salire di livello: non getCustomerById più getOpenOrders più getPaymentStatus, ma situazione_cliente, che fa le tre chiamate e restituisce un oggetto già interpretabile. Il nome del tool, la sua description e il suo inputSchema sono a tutti gli effetti prompt engineering: sono l’unica cosa che il modello legge per decidere. La specifica stessa raccomanda nomi qualificati come calculator_arithmetic invece di calculate, proprio per ridurre l’ambiguità quando un host federa più server.

Le resources vanno usate per ciò che è contesto e non azione, lo schema del database, il listino, la tassonomia dei prodotti, e i prompts per incapsulare i casi d’uso ricorrenti. Databricks segnala un dettaglio che in azienda pesa: le risorse restituite includono metadati di provenienza come ID sorgente e timestamp, rendendo gli output tracciabili. È la differenza fra un agente che afferma e uno che si può verificare.

Il cambio che quasi nessuno ha ancora recepito: MCP è diventato stateless

Qui va segnalata una discrepanza reale nelle fonti. Buona parte della letteratura tecnica in circolazione, inclusi articoli autorevoli e recenti, descrive MCP come protocollo stateful, con sessioni che mantengono contesto fra le chiamate. Nella specifica 2026-07-28 non è più così: MCP è definito stateless, ogni richiesta porta versione di protocollo e capabilities nel campo _meta, i server annunciano ciò che supportano tramite la richiesta obbligatoria server/discover, e le notifiche di cambiamento sono opt-in via subscriptions/listen.

Non è un cavillo: cambia il modo in cui si scala un server remoto dietro un load balancer. Ne abbiamo scritto quando la specifica è uscita, in MCP si aggiorna: il protocollo diventa stateless e pronto per il cloud. Se stai valutando materiale formativo o una consulenza, è un buon test: chi ti descrive ancora le sessioni stateful come stato dell’arte non ha letto la spec corrente.

Sicurezza dei server MCP: i rischi che vengono con la comodità

Un server MCP è codice eseguibile con accesso ai tuoi sistemi. Questo basta a spostare la conversazione dall’entusiasmo alla due diligence, e i numeri disponibili non sono rassicuranti.

Cosa dicono i dati sulle implementazioni reali

Le valutazioni di sicurezza condotte da Equixly su server MCP diffusi riportano che il 43% dei server testati conteneva falle di command injection, il 30% era vulnerabile a SSRF e il 22% consentiva path traversal. Lo stesso lavoro cita uno studio su 2.562 applicazioni MCP reali, di cui 1.438 con API di rete e 1.237 con API di sistema consolidate. Il messaggio è che la maturità di sicurezza non ha tenuto il passo dell’adozione.

I controlli raccomandati, in ordine di utilità

Red Hat classifica i rischi in cinque famiglie, autenticazione e autorizzazione (il classico problema del confused deputy), prompt injection, tool injection (un server legittimo «modificato in un aggiornamento futuro» per raccogliere dati riservati), esecuzione non autorizzata di comandi e rischio supply chain, e raccomanda controlli concreti: firma digitale dei componenti, pinning delle versioni dei server, sanitizzazione dei dati prima dell’uso come argomento, sandboxing dei server locali, conferma esplicita dell’utente sulle azioni e logging centralizzato.

Sull’autenticazione, l’approccio che ha fatto scuola è quello descritto da Cloudflare: il server MCP emette token propri invece di inoltrare quello del provider upstream, così se il token consegnato al client viene compromesso «l’attaccante ottiene solo i permessi limitati che hai concesso esplicitamente». In azienda questo si traduce quasi sempre in un gateway davanti ai server, lo stesso schema che DoorDash ha adottato con il suo gateway centralizzato per l’accesso degli agenti agli strumenti, e in un impianto di regole che non è un dettaglio tecnico ma una scelta di governance degli agenti AI, con policy, ruoli e obblighi dell’AI Act.

Configurazioni MCP esposte: cosa trova una scansione dei server pubblici

Ai numeri sul codice dei server se ne sono aggiunti altri che riguardano il modo in cui i server vengono configurati — ed è la parte che puoi sistemare da solo in un pomeriggio. Il report State of MCP Security 2026 ha analizzato 2.303 configurazioni pubbliche di server MCP (un crawl GitHub più 1.641 server nella versione corrente del registro ufficiale MCP), con scansione al 26 luglio 2026, e trova che il 52,1% dichiara un server remoto senza alcuna autenticazione, che il 100% delle configurazioni con credenziali inline (424 su 424) scrive un segreto statico nel file, che il 19,5% esegue via npx/uvx pacchetti remoti con versione non fissata e che lo 0% espone la discovery dei metadati di risorsa protetta prevista dalla RFC 9728. Nel complesso il 52,8% porta almeno un rilievo critico.

Anche qui la precisazione serve, perché il dato è utile solo se si sa cosa misura: sono configurazioni pubbliche, quindi con dentro molto materiale dimostrativo e sperimentale, non un campione di installazioni aziendali in produzione; ed è un report pubblicato dagli autori di uno scanner open source, non da un terzo indipendente. Non dice quanto è sicuro il tuo impianto. Dice però che i default in circolazione — quelli che il tuo team copia da un README — partono scoperti, e che due delle raccomandazioni della sezione precedente, autenticazione vera e pinning delle versioni, sono proprio quelle che quasi nessuno applica.

Verifica i file di configurazione, non solo il codice

La conseguenza operativa è noiosa e costa poco. I file che dichiarano quali server un host può istanziare, e che spesso contengono URL, argomenti di avvio e token, vanno trattati come artefatti di sicurezza: revisionati in code review, tenuti fuori dai repository pubblici, riletti a intervalli regolari invece di essere scritti una volta e dimenticati. È il tipo di controllo che nessuno programma perché non assomiglia a un incidente, finché non lo diventa.

Le domande da farsi su ogni voce sono sempre le stesse quattro: ogni server remoto ha un’autenticazione? Ci sono credenziali statiche nel file invece che in un secret manager o in una variabile d’ambiente iniettata a runtime? Le versioni dei pacchetti eseguiti sono fissate, o il comando scarica l’ultima release a ogni avvio? I permessi concessi al server sono i minimi che servono al processo che deve supportare, o è il token amministrativo che qualcuno aveva sottomano? Stanno nascendo scanner che fanno questa verifica in locale, senza far uscire la configurazione dalla macchina, ma l’utilità sta nella domanda più che nello strumento: mezz’ora di rilettura trova più rischio di molte discussioni sull’architettura.

Dal protocollo all’agente che serve: perché il connettore è solo metà del lavoro

Se sei arrivato fin qui hai capito la parte facile. Il protocollo è documentato, gli SDK esistono, un server MCP che legge il CRM si scrive in pochi giorni.

Cosa il protocollo MCP non decide al posto tuo

La parte difficile viene dopo, e non è tecnica: è capire quali processi valga la pena esporre, con quali permessi, per quali persone, e come far sì che quelle persone li usino davvero. Un connettore perfetto su un processo che nessuno aveva chiesto è un costo, non un agente. È esattamente il punto per cui, negli agenti AI applicati ai processi aziendali, la differenza fra un progetto che gira e uno che muore in pilota non sta quasi mai nel modello scelto.

Dopo il connettore MCP: l’affiancamento sui processi reali

È la ragione per cui in MIMIR trattiamo l’integrazione come un servizio, non come un prodotto da consegnare chiavi in mano. Scrivere il connettore MCP custom sul gestionale è il primo passo; quello che lo rende utile è l’affiancamento: mappare i processi con chi li esegue ogni giorno, decidere cosa l’agente può leggere e cosa può scrivere, mettere in piedi i controlli e le conferme sulle azioni sensibili, e restare accanto al team nelle prime settimane, quando emergono i casi che nessuna analisi aveva previsto. Abbiamo raccolto il metodo nella nostra guida pratica all’onboarding degli agenti AI in azienda.

Il protocollo MCP ha reso banale la connessione tecnica fra un LLM e i tuoi sistemi. Ha reso più visibile, non meno, il lavoro che resta: decidere cosa quell’agente deve fare e portarlo dentro il modo in cui l’azienda lavora già. Se hai un gestionale, un CRM o un ERP che vorresti rendere interrogabile da un agente e vuoi capire se ha senso, e da dove partire, parlane con noi di MIMIR: valutiamo insieme i processi, i vincoli di sicurezza e cosa è realistico ottenere. Anche solo per scoprire che nel tuo caso conviene aspettare.

Fonti:

• Anthropic — Introducing the Model Context Protocol (25 novembre 2024)
• Model Context Protocol — Architecture overview, specifica 2026-07-28
• IBM Think — What is the Model Context Protocol
• Databricks — What is the Model Context Protocol e il problema N×M
• OpenAI — Model Context Protocol nell’Agents SDK (supporto annunciato a marzo 2025)
• Cloudflare — Remote Model Context Protocol servers
• WorkOS — MCP vs REST API
• CodiLime — Model Context Protocol explained
• Carly — ChatGPT at work: l’integrazione con SAP
• Salesforce Devops — Agentforce in ChatGPT e gli MCP server fatti in casa
• Equixly — Come i server MCP sfidano i modelli di sicurezza API tradizionali
• Red Hat — MCP: rischi di sicurezza e controlli
• AgentAuditKit — State of MCP Security 2026: 2.303 configurazioni pubbliche analizzate, scansione del 26 luglio 2026
• Unite.AI — xAI lancia Grok Bot, agenti sempre attivi con un computer in cloud (11 agosto 2026)
• Implicator.ai — Opus 5 supera Fable 5 nella spesa aziendale (dati Ramp su 70.000 imprese, agosto 2026)
• Martin Alderson — The summer of open weights (estate 2026)
• Hugging Face — State of Open Models: Summer 2026