MCP protocol e Strava: cosa insegna alle PMI sull’integrazione AI

Il 1° giugno 2026 Strava ha fatto una cosa che, vista da fuori, sembra un dettaglio da appassionati di ciclismo: ha pubblicato un connettore MCP che permette di collegare il proprio storico allenamenti a Claude e farci domande in linguaggio naturale. Nessun export CSV, nessun copia-incolla, nessun tool di terze parti a cui regalare le credenziali. Tre clic in un menu e l’assistente legge i dati veri, aggiornati, con i permessi dell’utente che li possiede.

È un caso consumer, ma è la dimostrazione più pulita che esista di come funziona l’integrazione aziendale con il protocollo MCP: lo stesso identico meccanismo che porta i battiti cardiaci dentro una conversazione può portarci le commesse aperte del gestionale, lo scadenzario del CRM o le giacenze dell’ERP. La differenza non è tecnologica. È tutto quello che sta intorno al protocollo, permessi, governance, onboarding, e che in azienda decide se l’integrazione diventa uno strumento di lavoro o resta una demo che nessuno apre più dopo la prima settimana.

In questo articolo scoprirai:

• Cosa ha fatto davvero Strava con il connettore MCP per Claude
• Perché lo stesso protocollo funziona su ERP, CRM e gestionali
• MCP o API: che differenza c'è quando devi collegare il gestionale
• Dove si rompono le integrazioni MCP fatte in casa
• Governance dei permessi: chi può chiedere cosa all'agente aziendale
• L'onboarding degli utenti: il pezzo che nessuno mette a preventivo
• Quanto costa mantenere un'integrazione MCP nel tempo
• Costruire o comprare un server MCP: come decide una PMI

Cosa ha fatto davvero Strava con il connettore MCP per Claude

L’annuncio ufficiale è asciutto. Il comunicato di Strava parla di accesso ai dati stream secondo per secondo (frequenza cardiaca, passo), ai dati GPS, alla potenza per il ciclismo e alle informazioni su club ed eventi. Ryan Dixon, VP Partnerships & Developer Relations, motiva così la scelta: «Gli atleti ci stanno dicendo, in modi sempre più creativi, che vogliono più modi per analizzare i propri dati di allenamento».

La parte interessante per chi ragiona in ottica aziendale è nei vincoli, non nelle funzionalità. La documentazione di supporto chiarisce che l’accesso è in sola lettura: il connettore non può caricare né modificare attività. È vincolato all’account, revocabile in qualsiasi momento da Impostazioni → Le mie app, e soggetto a limiti di richieste al minuto e al giorno. Su Claude Code l’attivazione è una riga: claude mcp add --transport http strava-mcp https://mcp.strava.com/mcp.

Sola lettura, ambito ristretto, revoca in un clic, rate limit. Non è timidezza da parte di Strava: è il profilo di rischio minimo con cui si mette in produzione un’integrazione che espone dati personali a un modello linguistico. Ogni singola scelta di quel design è una decisione che una PMI dovrà rifare sul proprio gestionale, con la differenza che lì i dati non sono le uscite in bici ma i margini, i listini e i contatti commerciali. Se vuoi vedere il caso da vicino, l’abbiamo raccontato in questo articolo sul connettore e nella guida pratica all’attivazione.

Perché lo stesso protocollo funziona su ERP, CRM e gestionali

MCP nasce per risolvere un problema di aritmetica. Nell’annuncio originale Anthropic lo definisce «uno standard aperto che permette agli sviluppatori di costruire connessioni sicure e bidirezionali fra le proprie sorgenti dati e gli strumenti basati su AI», e individua il punto dolente: «Ogni nuova sorgente dati richiede la propria implementazione custom, il che rende difficile scalare sistemi davvero connessi». È il problema N×M: N assistenti moltiplicati per M sistemi aziendali producono un numero ingestibile di integrazioni su misura.

Il protocollo lo taglia trasversalmente. Un solo server MCP davanti al tuo gestionale parla con qualsiasi client conforme. E i client, oggi, non sono più solo Claude: secondo la ricognizione di WorkOS, il protocollo è supportato da Claude, ChatGPT, Gemini, Microsoft Copilot, GitHub Copilot, Cursor, Windsurf, VS Code e Zed, con server ufficiali pubblicati da Slack, Salesforce, Stripe, HubSpot, Shopify e Notion. Costruire un server MCP oggi significa non doverlo rifare quando l’azienda cambierà assistente fra due anni, ed è una garanzia che nessuna integrazione proprietaria può dare. Il quadro d’insieme su come si collega un agente ai sistemi interni è in MCP protocol: come collegare agenti AI ai sistemi aziendali.

La governance dello standard MCP dopo il passaggio alla Linux Foundation

C’è anche una ragione di governance per fidarsi dello standard. Il 9 dicembre 2025 Anthropic ha donato MCP alla Linux Foundation, dentro la neonata Agentic AI Foundation co-fondata con Block e OpenAI e sostenuta da Google, Microsoft, AWS, Cloudflare e Bloomberg. Per un’azienda che deve giustificare un investimento pluriennale, la differenza fra un formato controllato da un singolo vendor e uno gestito dalla fondazione che custodisce Linux e Kubernetes non è retorica: è la ragionevole certezza che quello che costruisci oggi sarà ancora leggibile fra cinque anni. Sul rapporto fra MCP e gli altri protocolli agentici abbiamo scritto un pezzo dedicato a MCP e A2A.

MCP o API: che differenza c’è quando devi collegare il gestionale

È la domanda ricorrente nelle SERP, ed è quasi sempre posta male. MCP non sostituisce le API: ci si appoggia sopra. Se il tuo gestionale non ha un’API, MCP non te la regala: il primo lavoro resta esporre in modo pulito i dati che vuoi rendere interrogabili.

Cosa aggiunge il protocollo MCP rispetto a una normale API REST

La documentazione ufficiale dell’architettura descrive tre primitive che un server può esporre, tools, resources e prompts, e le abbiamo spiegate una per una nella guida completa al MCP Server. Qui basta la differenza che conta: un’API REST espone endpoint per un programmatore, un server MCP espone capacità autodescrittive per un modello, con schema JSON dei parametri e descrizioni in linguaggio naturale del quando usarle.

Da cui la domanda pratica per chi ha già le API del gestionale: cosa cambia davvero. Le API non si rifanno, restano lì, e il server MCP ci si appoggia sopra. Il lavoro nuovo è di un altro tipo: decidere quale sottoinsieme di endpoint ha senso rendere interrogabile da un agente (quasi mai tutti), e scrivere per ciascuno la descrizione che dice al modello quando usarlo, che nella documentazione API non c’è perché il programmatore quel contesto ce l’ha già. Si aggiunge poi lo strato di trasporto e autenticazione: la versione di protocollo 2026-07-28 ha reso MCP stateless, ogni richiesta porta versione e capacità nel campo _meta, e i server si presentano tramite la chiamata server/discover, e per i server remoti serve Streamable HTTP, con OAuth esplicitamente raccomandato dalla specifica per ottenere i token. Quello che non va rifatto è la logica di business: se il gestionale sa già calcolare uno scadenzario, il server MCP non lo ricalcola, lo espone.

Cosa deve fare concretamente chi implementa

Tradotto in lavoro reale: scegliere quali operazioni del gestionale diventano tools (e quali no), scrivere gli schema di input, decidere cosa esporre come resource, gestire l’autenticazione, il rate limiting e la caching. La documentazione prevede anche l’elicitation, il meccanismo con cui il server può chiedere conferma all’utente prima di un’azione, la valvola di sicurezza che serve quando un agente sta per toccare qualcosa di irreversibile. Se il punto di partenza è un sistema legacy, il discorso si complica: lo abbiamo affrontato in Integrare agenti AI con ERP e CRM: la sfida dei sistemi legacy, mentre il percorso tipico di un’azienda che parte dal primo sistema collegato è nella guida all’integrazione di agenti AI con ERP e CRM per le PMI italiane.

Dove si rompono le integrazioni MCP fatte in casa

Qui sta il salto che divide la demo dal sistema. Un server MCP tirato su in un pomeriggio funziona benissimo, per una persona, su un laptop, senza vincoli di audit. La società di integrazione Frends lo sintetizza con una frase che vale la pena memorizzare: «MCP è un protocollo, non una piattaforma». Standardizza l’interfaccia fra AI e strumenti, ma non governa controllo degli accessi, residenza del dato, requisiti di audit o topologia di rete. È anche il motivo per cui conta chi lo costruisce: su cosa chiedere a un fornitore abbiamo scritto come scegliere un partner AI in Italia.

Il problema dei permessi troppo larghi

Lo stesso documento individua il guasto più frequente: senza toolbox definiti per ambito, un agente ottiene accesso a tutto ciò che è raggiungibile, «l’equivalente di dare a ogni dipendente una chiave universale». Nel mondo Strava questo è irrilevante, perché il connettore vede solo i dati di chi l’ha attivato. Nel mondo di un ERP, un agente che può leggere ogni tabella è un agente che può raccontare a un commerciale i margini di una linea che non gli compete. Il modello di permessi non è un dettaglio di implementazione: è il progetto. Vale per qualunque agente che operi su dati aziendali, come abbiamo spiegato nella guida agli agenti AI.

Autenticazione, shadow AI e costi nascosti

Kong quantifica l’onere in una formula spiacevolmente onesta: «Strumenti × Metodi di auth × Ambienti × Tipi di token × Varianti di client = Complessità esponenziale». Quindici tool con OAuth, API key, JWT e SAML su tre ambienti producono «potenzialmente centinaia di flussi di autenticazione da implementare, testare e mantenere». E quando le integrazioni nascono fuori dal perimetro ufficiale il conto arriva: secondo l’IBM Cost of a Data Breach Report 2025, ripreso da Kong, un’organizzazione su cinque ha dichiarato una violazione dovuta alla shadow AI, con un costo aggiuntivo associato di 670.000 dollari per incidente. Il numero è di IBM, non di Kong: chi vuole risalire alla metodologia deve cercare il report originale.

Da qui l’insistenza del mercato anglosassone sul gateway. Tyk lo definisce «un servizio centralizzato che gestisce la comunicazione MCP fra i modelli AI e i sistemi aziendali», con proxy identity-aware, OAuth 2.0 e scambio di token On-Behalf-Of, in modo che l’agente agisca solo entro i permessi dell’umano che lo delega. È anche il livello dove si difende da attacchi che l’IT tradizionale non ha mai visto: tool poisoning, confused deputy, ASCII smuggling. CData mappa i pattern architetturali possibili, centralizzato contro distribuito, embedded, semantic-layer-first, ibrido ETL, ciascuno con il proprio compromesso fra governance unica e complessità operativa.

Governance dei permessi: chi può chiedere cosa all’agente aziendale

Questo è il tema che le pagine italiane sull’argomento trattano poco, e per un’azienda è il primo che l’IT solleverà. La buona notizia è che il protocollo ha smesso di ignorarlo.

Enterprise-Managed Authorization: i permessi MCP dall’identity provider

L’estensione Enterprise-Managed Authorization permette all’organizzazione di provisionare centralmente l’accesso ai server MCP attraverso il proprio identity provider. La formula ufficiale è netta: «gli amministratori abilitano un server per l’organizzazione. Gli utenti lo ottengono automaticamente, limitato ai gruppi e ai ruoli» che possiedono. Tecnicamente, durante il single sign-on l’utente ottiene un Identity Assertion JWT Authorization Grant e lo scambia con i token di accesso dei server MCP. Nessuna schermata di consenso per singola applicazione, nessun flusso OAuth ripetuto da ogni dipendente per ogni sistema.

Le conseguenze operative sono tre, e sono esattamente quelle che un responsabile IT chiede prima di firmare. Primo: la policy si definisce una volta sola nella console dell’IdP, non applicazione per applicazione. Secondo: si ottiene un audit trail unico su tutta l’attività dei connettori. Terzo, e non è secondario in un’azienda dove la gente usa lo stesso browser per lavoro e per sé, si evita la mescolanza accidentale fra account personali e account aziendali.

Cosa la specifica MCP non copre ancora nell’integrazione aziendale

Resta però onesto dire cosa manca. WorkOS elenca i nodi ancora aperti nella specifica: assenza di audit trail standardizzati per la compliance, pattern di multi-tenancy non definiti, nessun rate limiting né attribuzione dei costi a livello di protocollo, e comportamento non specificato quando MCP gira dietro gateway e proxy aziendali. Chi vi racconta che MCP risolve da solo la conformità sta vendendo. Il protocollo dà il meccanismo di autorizzazione; il registro di chi ha chiesto cosa, e perché, ve lo dovete costruire, cosa che in Italia diventa rilevante quando si incrociano i requisiti di documentazione previsti dall’AI Act.

L’onboarding degli utenti: il pezzo che nessuno mette a preventivo

Torniamo a Strava per un secondo, perché la lezione più utile è nascosta nelle istruzioni. Per attivare il connettore l’utente deve: aprire claude.ai, espandere la sidebar, andare in Customize → Connectors, cliccare il +, cercare «Strava», autorizzare con il proprio account. Sono sei passaggi, su un prodotto consumer curatissimo, per una persona già motivata che vuole vedere i propri dati. E richiede un abbonamento Strava attivo.

Ora immaginate lo stesso percorso proposto a un magazziniere di 54 anni per interrogare le giacenze, o a un area manager che il CRM lo apre due volte a settimana. Il tasso di adozione di un’integrazione AI non lo determina la qualità del server MCP: lo determina il primo giorno d’uso. Un connettore tecnicamente perfetto che nessuno attiva produce esattamente zero valore, e produce anche la convinzione, difficile da smontare, che «l’AI in azienda non funziona».

Le decisioni di servizio che nessun protocollo MCP prende al posto vostro

Questo è il punto in cui l’integrazione smette di essere un problema di ingegneria e diventa un problema di servizio. Servono decisioni che nessun protocollo prende al posto vostro: quali tre domande deve saper rispondere l’agente nel primo mese (non trenta, tre); chi le valida; come si spiega a un utente non tecnico che l’agente può sbagliare e come si accorge che sta sbagliando; cosa succede quando qualcuno chiede un dato che non gli compete. È lo stesso motivo per cui, come abbiamo argomentato altrove, quando l’AI generativa non genera ROI il problema non è quasi mai la tecnologia. Sul metodo abbiamo raccolto l’esperienza in Onboarding agenti AI in azienda.

Quanto costa mantenere un’integrazione MCP nel tempo

Sui costi va detta una cosa scomoda: in rete circolano cifre molto diverse fra loro e quasi nessuna è verificabile. Non troverete qui un numero preso da un blog di vendor e spacciato per benchmark. Quello che si può descrivere con precisione è la struttura del costo, che è più utile di una cifra sbagliata.

Le tre voci che compongono il costo di un server MCP

La prima è la costruzione: esporre le operazioni, scrivere gli schema, gestire l’auth. La seconda è l’infrastruttura: hosting del server remoto, gateway, logging, monitoraggio, più il consumo di token, che ha una componente spesso ignorata, perché le definizioni dei tool vengono caricate in contesto a ogni sessione e più server collegate, più contesto pagate prima ancora di fare una domanda. Su questo fronte Tyk cita la progressive disclosure, cioè restituire solo i tool pertinenti, come leva concreta di riduzione.

La terza voce è la manutenzione, ed è quella che le PMI sottovalutano sistematicamente. Il protocollo si muove: Zuplo documenta il passaggio da stdio a HTTP/SSE a Streamable HTTP nel giro di pochi mesi, l’evoluzione dell’auth verso OAuth 2.1, e una vulnerabilità critica con esecuzione di codice remoto (CVE-2025-49596) che ha richiesto patch entro giugno 2025. Nello stesso periodo i server MCP censiti «in the wild» hanno superato quota 16.000. Un server MCP non è un progetto: è un componente che va tenuto in vita, come un’integrazione EDI o un connettore bancario.

Costruire o comprare un server MCP: come decide una PMI

Da qui la vera domanda di una PMI, che non è «MCP o API» ma «lo costruiamo o lo compriamo». La risposta dipende da quanto è specifico il vostro processo: se l’operazione che volete automatizzare esiste identica in mille aziende, esiste probabilmente già un server pronto; se dipende dal vostro modo di lavorare, va fatta su misura. È il ragionamento che abbiamo sviluppato in agenti AI custom contro SaaS generalisti.

In MIMIR lavoriamo esattamente su questa distanza: fra un protocollo che funziona e un’integrazione che le persone usano davvero. Non vendiamo solo l’agente, configuriamo i server MCP sui vostri sistemi, definiamo il modello di permessi con il vostro IT e seguiamo l’onboarding delle persone che dovranno usarlo, perché è lì che i progetti si giocano. Se avete un gestionale, un CRM o un ERP che vorreste rendere interrogabile e volete capire da dove si comincia, parliamone: una prima conversazione serve soprattutto a stabilire se ha senso farlo, e cosa aspettarsi da una consulenza sugli agenti AI lo abbiamo scritto nero su bianco.

Fonti:

• Strava — Strava launches MCP connector (comunicato stampa ufficiale)
• Strava Support — Strava MCP Connector: dati accessibili, limiti e revoca
• Anthropic — Introducing the Model Context Protocol
• WorkOS — Everything your team needs to know about MCP in 2026
• Anthropic — La donazione di MCP alla Linux Foundation e la nascita della Agentic AI Foundation
• Model Context Protocol — Architecture overview (documentazione ufficiale, versione 2026-07-28)
• Frends — MCP and enterprise integration: architecture, governance and hybrid patterns
• Kong — Build vs buy: MCP server infrastructure (riprende i dati IBM Cost of a Data Breach Report 2025 su shadow AI)
• Tyk — Enterprise MCP gateway: key considerations
• CData — Enterprise MCP architecture patterns for data integration
• MCP Blog — Enterprise-Managed Authorization
• Zuplo — One year of MCP: evoluzione dei transport, auth e vulnerabilità