MCP Server: cos’è, come si collega e cosa serve davvero per usarlo in azienda

Un MCP Server è il componente che permette a un modello di intelligenza artificiale di leggere e agire sui sistemi che usi già: un database, un gestionale, un repository, un’API interna. Il Model Context Protocol che lo definisce nasce in Anthropic, è oggi adottato da OpenAI, Google e Microsoft, ed è governato dalla Linux Foundation. Il 28 luglio 2026 la specifica è cambiata in profondità: il protocollo è diventato stateless, e chi valuta un’integrazione oggi deve partire da lì.

In questo articolo trovi:

• Cos’è un server MCP e quale problema risolve davvero
• Come funziona l’architettura, e cosa è cambiato con la revisione stateless
• Le tre primitive: Tools, Resources e Prompts
• Server reali, funzionanti, che puoi collegare oggi
• Come costruirne uno in Python
• La sicurezza: gli attacchi noti e i requisiti obbligatori della specifica
• Cosa serve per collegarlo ai sistemi aziendali esistenti

Per un esempio di come la stessa primitiva venga implementata in un framework agentico open source, vedi la guida a programmare un Tool nel Cheshire Cat.

In questo articolo scoprirai:

• Che cos’è il Model Context Protocol
• Cos’è un MCP Server
• Come funziona l’architettura
• Server MCP reali da cui partire
• Perché interessa alle aziende

Che cos’è il Model Context Protocol

Il Model Context Protocol (MCP) è uno standard aperto, introdotto da Anthropic a novembre 2024 (annuncio ufficiale) e poi adottato anche da OpenAI, Google e Microsoft, che definisce un modo uniforme per collegare i modelli di intelligenza artificiale a strumenti, dati e servizi esterni. In pratica è un’interfaccia universale — l’equivalente di una porta USB-C per l’AI — che sostituisce le integrazioni su misura con un unico protocollo condiviso.

Il problema che risolve è concreto: per quanto capaci, i modelli restano isolati dai dati, chiusi dietro silos informativi e sistemi che non comunicano tra loro. Ogni nuova fonte da collegare richiedeva un’integrazione costruita su misura. MCP sostituisce queste connessioni frammentate con un unico standard condiviso, donato alla Linux Foundation a garanzia della sua neutralità.

La revisione corrente della specifica è datata 28 luglio 2026, e non è un aggiornamento minore: la specifica MCP diventata stateless ha eliminato l’handshake di inizializzazione e le sessioni a livello di protocollo. Se stai valutando un’integrazione adesso, è la revisione su cui contare.

Cos’è un MCP Server

Un MCP Server è un componente che espone strumenti, risorse e capacità a un’applicazione AI attraverso un’interfaccia standardizzata. In termini pratici, è il “ponte” che permette a un Large Language Model come Claude o ChatGPT di interagire con sistemi esterni in modo controllato.

In concreto può dare al modello l’accesso a un database, a un’API, al file system o a servizi come Slack, GitHub o Google Drive. Espone queste capacità in modo standardizzato, così che qualsiasi applicazione compatibile possa usarle senza un’integrazione dedicata. Più server possono lavorare in parallelo, ciascuno specializzato in un dominio diverso.

Il problema che risolve

Immagina di avere 5 diversi LLM (Claude, GPT, Gemini, Llama, Mistral) e di volerli connettere a 10 strumenti diversi (Slack, GitHub, database SQL, CRM, email). Senza uno standard comune, dovresti sviluppare 50 integrazioni separate, ognuna con la propria logica, autenticazione e manutenzione.

MCP riduce questa relazione a N+M connessioni: ogni LLM implementa il protocollo una volta, e ogni strumento espone un’interfaccia una volta. Invece di 50 integrazioni, ne servono 15.

Perché l’analogia con l’USB-C funziona

Prima dell’USB-C ogni dispositivo aveva il proprio connettore proprietario: cavi diversi per telefoni, tablet, laptop e periferiche. USB-C ha standardizzato tutto, permettendo a qualsiasi dispositivo di connettersi con qualsiasi altro attraverso un’unica interfaccia.

MCP fa lo stesso per l’AI. L’analogia ha però un limite da tenere presente: USB-C trasporta corrente e dati, non decisioni. Un server MCP espone azioni, e questo sposta il problema dal formato del cavo a chi è autorizzato a usarlo — motivo per cui la sezione sulla sicurezza, più sotto, non è un’appendice.

Come funziona l’architettura

L’architettura si basa su tre componenti che lavorano insieme per abilitare la comunicazione tra applicazioni AI e sistemi esterni.

I tre componenti fondamentali

1. Host: l’applicazione AI o l’ambiente che contiene il modello. Può essere Claude Desktop, un IDE potenziato dall’AI, o qualsiasi applicazione che integra un LLM. Gestisce l’interazione con l’utente e coordina le richieste.

2. Client: situato all’interno dell’host, funziona da traduttore. Converte le richieste del modello nel formato MCP e trasforma le risposte dei server in un formato comprensibile. Ogni host può gestire più connessioni client simultaneamente.

3. Server: il servizio che fornisce contesto, dati o capacità. Può esporre accesso a database, API esterne, file system o qualsiasi altra risorsa. Più server possono essere attivi contemporaneamente, ciascuno specializzato in un dominio.

Il flusso di una richiesta, dopo la svolta stateless

Fino alla revisione 2025-11-25 il flusso iniziava con un handshake initialize e proseguiva dentro una sessione identificata dall’header Mcp-Session-Id. Dal 28 luglio 2026 non è più così: ogni richiesta è autosufficiente.

1. Dichiarazione: la richiesta porta con sé versione di protocollo e capacità del client nel campo _meta (io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientCapabilities). Su Streamable HTTP lo stesso valore viaggia anche nell’header MCP-Protocol-Version.
2. Negoziazione: il server accetta o rifiuta ogni richiesta in modo indipendente. Se non supporta la versione richiesta risponde con UnsupportedProtocolVersionError, elencando quelle che supporta.
3. Autorizzazione: il server verifica il token del chiamante e i suoi diritti di accesso.
4. Esecuzione: il server interroga la fonte — database, API, file storage — e applica le politiche di governance previste.
5. Risposta: il risultato torna con un campo obbligatorio resultType, che vale complete per un risultato ordinario e input_required quando al server servono altre informazioni.

Il client può chiamare server/discover prima di ogni altra cosa per scegliere la versione in anticipo: è un RPC che i server devono implementare, secondo le regole di versioning della specifica.

Cosa devi rifare se hai già un server in esercizio

Le rimozioni della revisione 2026-07-28 non sono cosmetiche:

• Niente header Mcp-Session-Id: gli endpoint di elenco (tools/list, resources/list, prompts/list) non variano più per connessione.
• Lo stato che attraversa più chiamate si gestisce con handle espliciti emessi dal server e restituiti come normali argomenti degli strumenti.
• resources/subscribe e l’endpoint HTTP GET lasciano il posto a subscriptions/listen, un unico stream a cui il client si iscrive per tipo di notifica.
• Spariscono ping e logging/setLevel. Sparisce anche la riprendibilità degli stream SSE: se una risposta si interrompe, la richiesta va rifatta con un nuovo ID.
• Roots, Sampling e Logging sono deprecati: restano funzionanti per almeno dodici mesi, ma le nuove implementazioni non dovrebbero adottarli.

La retrocompatibilità con i server basati su handshake è prevista, ma è un ponte, non una destinazione.

Le tre primitive

Tools (strumenti): funzioni che il modello può invocare con l’approvazione dell’utente — “invia_email”, “crea_ticket_jira”, “aggiorna_record_crm”. Sono il meccanismo con cui gli agenti AI compiono azioni nel mondo reale.

Resources (risorse): dati simili a file che i client possono leggere — risposte API, contenuti di file, risultati di query. Permettono al modello di accedere a informazioni aggiornate senza tenerle tutte nel contesto.

Prompts (template): modelli pre-scritti che aiutano a compiere compiti specifici. Utili per standardizzare interazioni complesse e garantire che il modello riceva sempre le istruzioni corrette.

Dalla revisione 2026-07-28 i risultati degli elenchi portano anche ttlMs e cacheScope: indicano per quanto tempo un client può mettere in cache la risposta e se un intermediario condiviso ha il diritto di farlo.

Server MCP reali da cui partire

Il modo più rapido per capire se MCP regge il tuo caso d’uso non è scrivere un server: è collegarne uno che esiste già.

I sette server di riferimento ufficiali

Il repository modelcontextprotocol/servers mantiene sette server di riferimento, pensati per dimostrare le primitive del protocollo più che per l’uso in produzione:

everything è quello da cui partire in fase di debug: espone di proposito ogni primitiva, e serve a verificare che il tuo client si comporti come deve prima di puntarlo su dati veri.

Dove trovare gli altri: il registry ufficiale

Oltre ai server di riferimento esiste un registry ufficiale, interrogabile via API su registry.modelcontextprotocol.io, dove i manutentori pubblicano i propri server con nome, versione e tipo di trasporto. È il posto giusto per verificare se lo strumento che ti serve ha già un server prima di scriverne uno.

Un esempio di connettore pubblico e funzionante: a giugno 2026 Strava ha rilasciato il proprio connettore MCP, che porta lo storico degli allenamenti dentro Claude. È utile come dimostrazione perché mostra il caso normale — un servizio con la sua API e la sua autenticazione che espone un sottoinsieme controllato di dati a un modello: accesso OAuth in sola lettura, limitato al proprio account e revocabile dalle impostazioni, senza possibilità di scrivere o modificare nulla.

Perché interessa alle aziende

L’adozione sta accelerando nel mondo enterprise per motivi che vanno oltre la convenienza tecnica.

Meno allucinazioni, perché ci sono i dati veri

Una delle sfide principali nell’uso degli LLM in azienda è il fenomeno delle allucinazioni: risposte plausibili ma fattualmente errate. MCP mitiga il problema fornendo al modello accesso a dati accurati e aggiornati, invece di farlo basare solo sulla conoscenza acquisita in addestramento.

Quando un chatbot aziendale può interrogare direttamente il CRM, l’ERP o il database ordini, le sue risposte sono ancorate a dati reali invece che a inferenze probabilistiche. Resta vero che il modello può interpretare male un dato corretto: MCP riduce la superficie dell’errore, non lo elimina.

Un punto solo dove applicare le regole

L’accesso ai dati passa attraverso un punto centralizzato, dove possono essere applicati:

• Controlli di autenticazione e autorizzazione
• Mascheratura dinamica dei dati sensibili
• Tokenizzazione delle informazioni personali
• Audit logging di tutte le operazioni

È un requisito pratico per la conformità GDPR: avere un solo punto da cui passa tutto rende dimostrabile ciò che altrimenti andrebbe ricostruito da dieci integrazioni diverse.

Tempi di integrazione più corti

Invece di scrivere codice su misura per ogni integrazione, gli sviluppatori possono partire da server esistenti o crearne di nuovi seguendo uno standard consolidato. Il guadagno reale dipende da quanti dei sistemi che ti servono hanno già un server pubblicato: è la prima cosa da verificare sul registry, prima di stimare qualsiasi tempo.

Casi d’uso pratici

Federazione di dati enterprise

Scenario: un’azienda ha dati distribuiti su CRM (Salesforce), ERP (SAP), sistema HR (Workday) e più database legacy.
Soluzione: un server MCP centralizzato astrae la complessità dei silos, fornendo un’interfaccia unificata che permette agli agenti AI di interrogare tutte le fonti.
Risultato: i dipendenti possono chiedere “qual è lo stato dell’ordine #12345 e chi è il commerciale responsabile?” ottenendo una risposta aggregata invece di consultare tre sistemi.

Assistente allo sviluppo

Scenario: un team vuole integrare Claude o GPT nel proprio flusso di lavoro di sviluppo.
Soluzione: server MCP che espongono GitHub, Jira, documentazione interna e ambiente di test.
Risultato: l’AI può leggere il codice esistente, creare branch, aprire pull request, aggiornare ticket e consultare la documentazione tramite comandi in linguaggio naturale.

Assistenza clienti

Scenario: un e-commerce vuole un assistente AI per il customer service.
Soluzione: un server che connette il modello al catalogo prodotti, allo storico ordini, al ticketing e alla knowledge base.
Risultato: l’assistente risponde su ordini specifici, verifica la disponibilità in tempo reale ed effettua l’escalation dei casi complessi agli operatori.

Come costruire un server MCP

Costruirne uno è più accessibile di quanto sembri. La documentazione ufficiale e gli SDK mettono la creazione di un server alla portata di chi ha già esperienza con Python o TypeScript; per un percorso guidato esiste anche un corso DeepLearning.AI dedicato a MCP.

Prerequisiti

• Python 3.10+ o Node.js 16+, a seconda del linguaggio scelto
• Familiarità con API REST e JSON-RPC
• Comprensione di base di come funzionano gli LLM
• Claude Desktop o un altro client MCP per il testing

Un server meteo in Python, passo per passo

Vediamo un server che espone due strumenti: allerte meteo e previsioni per una località, usando l’API del National Weather Service.

Step 1: setup dell’ambiente

# Installa uv (package manager Python moderno)
curl -LsSf https://astral.sh/uv/install.sh | sh

# Crea il progetto
uv init weather
cd weather

# Crea virtual environment e installa dipendenze
uv venv
source .venv/bin/activate
uv add "mcp[cli]" httpx

# Crea il file del server
touch weather.py

Step 2: importa i pacchetti e inizializza

from typing import Any
import httpx
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")

NWS_API_BASE = "https://api.weather.gov"
USER_AGENT = "weather-app/1.0"

Step 3: definisci i tool con i decoratori

@mcp.tool()
async def get_alerts(state: str) -> str:
    """Get weather alerts for a US state.

    Args:
        state: Two-letter US state code (e.g. CA, NY)
    """
    url = f"{NWS_API_BASE}/alerts/active/area/{state}"
    # ... logica di fetch e formattazione
    return alerts_formatted

@mcp.tool()
async def get_forecast(latitude: float, longitude: float) -> str:
    """Get weather forecast for a location.

    Args:
        latitude: Latitude of the location
        longitude: Longitude of the location
    """
    # ... logica di fetch previsioni
    return forecast_formatted

Step 4: avvia il server

def main():
    mcp.run(transport="stdio")

if __name__ == "__main__":
    main()

FastMCP usa i type hint e le docstring per generare automaticamente le definizioni dei tool, il che riduce parecchio la manutenzione.

Collegarlo a Claude Desktop

Per testare il server, modifica il file claude_desktop_config.json:

{
  "mcpServers": {
    "weather": {
      "command": "uv",
      "args": [
        "--directory",
        "/percorso/assoluto/al/progetto/weather",
        "run",
        "weather.py"
      ]
    }
  }
}

Dopo aver salvato e riavviato, il server apparirà nel menu “Connectors” e potrai provarlo con domande come “qual è il meteo a New York?”.

Non scrivere su stdout

L’errore più comune nei server STDIO è scrivere su stdout, che corrompe i messaggi JSON-RPC. È anche la migrazione consigliata ora che la primitiva Logging è deprecata: si scrive su stderr, oppure si usa OpenTelemetry.

# ❌ Sbagliato (STDIO)
print("Processing request")

# ✅ Corretto (STDIO)
import logging
logging.info("Processing request")  # scrive su stderr

SDK disponibili

La sicurezza: cosa chiede il reparto IT prima di dire sì

La sicurezza è la prima obiezione che arriva quando si propone MCP in azienda, ed è legittima: un server MCP è per definizione un ponte fra un modello linguistico e sistemi che contengono dati veri. Le contromisure non sono lasciate al buon senso — la specifica dedica un documento intero agli attacchi noti e ai requisiti obbligatori.

Token passthrough: il divieto più importante

Il token passthrough è l’anti-pattern in cui un server accetta un token emesso per un altro servizio e lo inoltra all’API a valle senza verificare di esserne il destinatario. La specifica lo vieta senza sfumature: un server MCP non deve accettare token che non siano stati emessi per sé.

La validazione dell’audience è il confine su cui poggiano tutti gli altri controlli. Se salta, saltano rate limiting, validazione delle richieste e tracciabilità: i log del sistema a valle mostreranno richieste che sembrano arrivare da un’identità diversa, e in caso di incidente non sarà possibile ricostruire chi ha fatto cosa. Un token rubato trasforma il server in un proxy per l’esfiltrazione.

Prompt injection e strumenti che si combinano

Un server espone descrizioni di strumenti che finiscono nel contesto del modello: se quel testo può essere manipolato, può esserlo anche il comportamento dell’agente. Tre varianti da conoscere: input malevoli che riscrivono le istruzioni; strumenti innocui che combinati permettono l’esfiltrazione, perché uno legge e l’altro scrive verso l’esterno; server ostili che si mascherano da strumenti affidabili.

Le contromisure sono di progettazione, non di configurazione: validazione rigorosa degli input, principio del minimo privilegio sugli scope e approvazione esplicita dell’utente per ogni azione che scrive.

Il rischio nuovo: dirottamento degli handle di stato

Senza sessioni di protocollo, i server che hanno bisogno di stato fra una chiamata e l’altra emettono un handle esplicito — l’ID di un carrello, di un workflow — che il client restituisce come normale argomento di uno strumento. Il rischio è che qualcuno indovini o intercetti quell’handle e operi sullo stato di un altro utente.

La regola è netta: il possesso di un handle non è autenticazione. Gli handle vanno generati con un generatore di numeri casuali sicuro, fatti scadere, e legati lato server all’utente autenticato — per esempio indicizzando lo stato come <user_id>:<handle>, dove lo user ID è derivato dal token verificato e non fornito dal client.

Server locali: codice di terzi sulla tua macchina

Un server MCP locale è un binario che gira sulla macchina dell’utente con i suoi stessi privilegi. Il vettore d’attacco più banale è un comando di avvio malevolo dentro una configurazione condivisa: basta un npx verso un pacchetto ostile per esfiltrare chiavi SSH.

Per questo un client che offre la configurazione “con un clic” deve mostrare il comando esatto, senza troncarlo, e chiedere un’approvazione esplicita. Lato server, il trasporto stdio limita l’accesso al solo client MCP; se serve HTTP in locale, va protetto con un token di autorizzazione o con socket Unix. Il sandboxing dei processi non è un lusso.

SSRF: quando è il client a essere ingannato

Non tutti i rischi stanno sul server. Durante la scoperta dei metadati OAuth il client recupera URL forniti dal server: uno ostile può puntarli a http://169.254.169.254/, l’endpoint di metadati di AWS, GCP e Azure, e farsi restituire le credenziali dell’istanza.

Le mitigazioni: imporre HTTPS fuori dallo sviluppo locale, bloccare gli intervalli IP privati e link-local, applicare le stesse regole ai redirect e, per i deployment lato server, passare da un proxy di egress. La specifica avverte anche di non scrivere a mano la validazione degli indirizzi: codifiche ottali, esadecimali e IPv4-mapped IPv6 sono esattamente ciò che i parser artigianali si perdono.

Quando invece il server è privato e va esposto a un provider esterno, servono accorgimenti dedicati: vedi la guida alla connessione sicura MCP a OpenAI.

Chi cerca i bug, adesso, è un modello

C’è un fatto di contesto che cambia i tempi di questa checklist. Il 10 agosto 2026 OpenAI ha presentato GPT-5.6-Cyber, un modello specializzato nella ricerca di vulnerabilità e nella costruzione di exploit chain, distribuito solo ai difensori approvati del programma Daybreak: l’idea è arrivare ai difetti prima di chi attacca. È un’ottima notizia per chi ha un programma di sicurezza, ma la stessa classe di capacità non resta da una parte sola della barricata.

Un server MCP raggiungibile da internet è un bersaglio particolarmente comodo per un’analisi automatica: per costruzione pubblica un elenco di strumenti che si descrivono da soli, con nomi, scopi e schemi degli argomenti. La conseguenza pratica non è allarmarsi, è smettere di trattare l’audit come un evento singolo prima del rilascio. Se le due parti usano strumenti che analizzano codice e interfacce alla stessa velocità, la revisione dei permessi e degli scope va messa in calendario, non in backlog.

La checklist minima prima della produzione

• Il server valida l’audience di ogni token e rifiuta quelli emessi per altri servizi
• Gli handle di stato sono casuali, scadono e sono legati all’utente autenticato
• Gli scope partono minimi e si elevano su richiesta, senza cataloghi onnicomprensivi
• Ogni azione che scrive richiede approvazione esplicita
• Le operazioni sono tracciate in un audit log utilizzabile in caso di incidente
• I server di terze parti sono verificati prima dell’installazione, non dopo
• La revisione di scope e permessi ha una cadenza fissa, non solo una data di rilascio

Chi governa il protocollo

Nel dicembre 2025 Anthropic ha donato MCP all’Agentic AI Foundation, un fondo diretto sotto la Linux Foundation co-fondato da Anthropic, Block e OpenAI. L’adozione da parte di OpenAI, con il supporto nativo nell’Agents SDK e l’integrazione nell’app desktop di ChatGPT, ha consolidato il protocollo come standard di fatto per l’interoperabilità.

La revisione 2026-07-28 ha aggiunto qualcosa che conta più della governance formale: una politica di ciclo di vita delle funzionalità, con stati Attivo, Deprecato e Rimosso e una finestra minima di dodici mesi prima che una funzionalità deprecata possa sparire. È la differenza fra uno standard su cui pianificare e uno che ti cambia sotto i piedi.

Vantaggi e limiti

Cosa guadagni

Cosa ti costa

Il protocollo si muove. La revisione di luglio 2026 ha rimosso sessioni, handshake e riprendibilità degli stream: chi aveva un server in produzione ha dovuto rimetterci mano. La politica di deprecazione a dodici mesi riduce il problema, non lo annulla.

Gli scenari complessi restano complessi. I casi d’uso semplici sono ben coperti; le integrazioni enterprise articolate richiedono comunque personalizzazioni significative.

Dipendi dall’ecosistema. La disponibilità di server per strumenti specifici dipende dalla community: i tool di nicchia potrebbero non averne uno, e allora il lavoro te lo fai tu.

Dal protocollo all’integrazione con i sistemi esistenti

Un protocollo risolve il problema del come, non quello del cosa. Nel momento in cui il server funziona, la domanda vera diventa un’altra: quali sistemi aziendali vale la pena esporre, con quali permessi e in quale ordine.

Quali sistemi esporre a un MCP Server, e in quale ordine

Qui il lavoro smette di essere di protocollo e diventa di integrazione. I gestionali che contano — ERP, CRM, ticketing — hanno anagrafiche che non coincidono, permessi che non si mappano uno a uno e API che non sono state pensate per essere interrogate da un modello. Abbiamo raccolto il metodo nella guida a integrare gli agenti con ERP e CRM, con i vincoli tipici delle realtà italiane.

Se invece ti interessa il livello sopra — come i protocolli agentici dialogano fra loro — vale la pena leggere MCP e A2A, i protocolli dell’AI agentica.

MCP Server e piattaforme di orchestrazione

Soluzioni come Mimir AI Agent lavorano su questo strato: connettere i modelli ai sistemi, governare accessi e permessi, orchestrare workflow e ridurre la frammentazione delle integrazioni.

Scopri come Mimir AI Agent può trasformare il tuo stack applicativo in un’infrastruttura AI-ready.

Risorse correlate

• Guida completa a Claude AI
• Guida completa a ChatGPT di OpenAI
• Agenti AI: cosa sono e perché sono indispensabili
• RAG: cos’è e come funziona
• Introduzione ai Large Language Model

Fonti

1. Anthropic. (2024). Introducing the Model Context Protocol. anthropic.com/news/model-context-protocol
2. Model Context Protocol. (2026). Specification 2026-07-28 — Key Changes. modelcontextprotocol.io/specification/2026-07-28/changelog
3. Model Context Protocol. (2026). Versioning. modelcontextprotocol.io/specification/versioning
4. Model Context Protocol. (2026). Security Best Practices. modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices
5. Model Context Protocol. (2026). Feature Lifecycle and Deprecation Policy. modelcontextprotocol.io/community/feature-lifecycle
6. Model Context Protocol. (2026). Official MCP Registry. registry.modelcontextprotocol.io
7. Model Context Protocol. (2026). Build an MCP Server. modelcontextprotocol.io/docs/develop/build-server
8. Model Context Protocol. (2026). Reference Servers (repository). github.com/modelcontextprotocol/servers
9. OpenAI. (2025). Model Context Protocol – OpenAI Agents SDK. openai.github.io/openai-agents-python/mcp
10. Strava. (2026). Strava Launches MCP Connector, Allowing Athletes to Sync Training History to Claude. press.strava.com/articles/strava-launches-mcp-connector
11. SecurityWeek. (2026). OpenAI Unveils New Cybersecurity Model GPT-5.6-Cyber. securityweek.com/openai-unveils-new-cybersecurity-model-gpt-5-6-cyber
12. DeepLearning.AI. MCP: Build Rich-Context AI Apps with Anthropic. learn.deeplearning.ai/courses/mcp-build-rich-context-ai-apps-with-anthropic