Build vs buy server MCP: quando svilupparlo e quando comprarlo

Un server MCP è un processo backend che espone tool, risorse e prompt sul transport Streamable HTTP, in modo che un client AI come Claude, Cursor o ChatGPT possa chiamarli come capability di prima classe. La domanda build vs buy è se alzare quel backend da soli o lasciarlo gestire a un vendor. La risposta onesta nel 2026: comprare per l'80% delle integrazioni che sono commodity, costruire per il 20% in cui il server MCP è parte del prodotto o tocca dati che non puoi consegnare a terzi.

La decisione pesa perché il gap di costo è largo. I server MCP custom costano 50.000-150.000 dollari per integrazione l'anno una volta contati auth, governance e manutenzione. Un server gestito per la stessa integrazione costa tipicamente una frazione, col tradeoff di consegnare la tool surface a un vendor. La domanda non è "quale è meglio" in astratto. È "per questa integrazione, a questo stadio, quale insieme di tradeoff si adatta".

TL;DR: chi sceglie cosa

• Compra se ti connetti a un SaaS diffuso (Slack, Notion, GitHub, Google Drive, Stripe), ti servono OAuth e audit log dal giorno uno e vuoi i tuoi ingegneri sul prodotto invece che sul plumbing.
• Costruisci se il server MCP è il prodotto (vendi accesso AI a un sistema specifico), i dati sono regolati o proprietari, oppure nessun vendor gestito copre la surface che ti serve.
• Ibrido è lo stato stabile finale per la maggior parte dei team: compra le surface commodity, costruisci le due o tre che sono differenzianti o sensibili.

Cosa stai davvero comprando

Quando diciamo comprare, intendiamo puntare un client AI a un server MCP gestito da terzi. Le opzioni principali a inizio 2026:

• Cloudflare Agents. Server MCP remoti gestiti con OAuth via workers-oauth-provider, MCP Server Portals per il routing centralizzato e un catalogo di server first-party sulle API di Cloudflare.
• Truto, Composio, Kong MCP Gateway. Gateway multi-tenant che avvolgono centinaia di API SaaS dietro una integrazione registrata, con OAuth, rate limiting e permessi a livello di tool.
• Official MCP Registry su registry.modelcontextprotocol.io, che non ospita server ma pubblica un catalogo verificato che punta a pacchetti npm, PyPI o Docker.
• Server gestiti first-party di GitHub, Atlassian, Notion e altri, fatti girare dallo stesso vendor SaaS per la propria surface di prodotto.

Gartner stima che entro il 2026 il 75% dei vendor di API gateway e il 50% dei vendor iPaaS spediranno feature MCP. Comprare non è più una scommessa da early adopter.

Gli assi che decidono davvero

Tempo al primo tool funzionante

Comprare ti porta da zero a un tool MCP funzionante in ore. Costruire la stessa cosa prende 80-120 ore per un connector database semplice e 150-250 ore per un server di integrazione API, con 400-800 ore per orchestrazione multi-sistema. Se ti serve il tool in produzione questo trimestre, quel gap è l'intero argomento.

Autenticazione

Il primo muro che colpisce ogni team self-hosted è OAuth. La revisione della spec 2025-06-18 ha reso OAuth 2.1 obbligatorio per i server remoti. I server gestiti lo spediscono di default. Farlo in casa significa implementare dynamic client registration, schermate di consenso, token exchange, gestione refresh e enforcement degli scope. Librerie come l'OAuth provider di Cloudflare tagliano parecchio il lavoro, ma resta tua la parte di integrare gli identity provider (GitHub, Google, WorkOS, il tuo IdP).

Postura di sicurezza

I server MCP hanno una superficie d'attacco non banale. Nel 2025 e inizio 2026 sono stati divulgati CVE-2025-53818 (command injection nel GitHub Kanban MCP server), CVE-2025-53110 (sandbox escape nel filesystem server MCP di riferimento) e una falla nell'SDK MCP di Anthropic che ha coinvolto oltre 7.000 server pubblicamente accessibili. La prompt injection indiretta via output di tool resta una classe di rischio irrisolta, documentata da Microsoft, da Palo Alto Unit 42, e da Simon Willison. Un vendor gestito si prende patching, disclosure e il percorso forense. Un server self-hosted lascia quel lavoro al tuo team, a tempo indefinito.

Costo a scala

A un costo ingegneristico caricato di 100 dollari l'ora, un server MCP custom di media dimensione consuma 1.200-2.600 dollari al mese solo in tempo di manutenzione. Moltiplica per dieci integrazioni e hai due FTE a budget puramente sul plumbing MCP. Il pricing gestito arriva tipicamente come per-seat o per-call con un floor sotto i 1.000 dollari al mese per integrazione. Il break-even arriva prima di quanto la maggior parte dei team pensi, di solito entro i primi sei mesi dalla terza integrazione.

Residenza dati e compliance

Un server MCP gestito vede, come minimo, gli argomenti dei tool e i valori di ritorno che lo attraversano. Per dati regolati da HIPAA, GDPR, PCI o proprietari del cliente, è spesso non negoziabile senza DPA firmato, garanzia di deploy regionale e diritto di audit. Non tutti i vendor gestiti offrono tutti e tre. Costruire tiene i dati dentro la tua VPC e il control plane dentro il tuo SOC.

Velocità del protocollo

La spec MCP ha spedito tre revisioni maggiori dal tardo 2024: la release iniziale di novembre 2024, la revisione 2025-03-26 che ha introdotto Streamable HTTP e auth remota, e la revisione 2025-06-18 che ha reso OAuth 2.1 obbligatorio e aggiunto l'elicitation. La roadmap 2026 aggiunge operazioni asincrone, contenuto multi-modale e pattern agent-to-agent più robusti. I server gestiti assorbono il churn del protocollo. I self-hosted ti costringono a rileggere la spec ogni trimestre e spedire una migrazione del client a ogni breaking change.

Dove costruire vince

Quando l'accesso MCP è il prodotto

Se vendi accesso AI a un sistema specifico che nessun altro possiede (un SaaS verticale, un dataset proprietario, un workflow di settore regolato), il server MCP non è plumbing, è la superficie che i tuoi clienti pagano. Costruirlo è un investimento di prodotto, non un cost center. Le economiche si ribaltano: le 400-800 ore che spenderesti sono anche le ore che già spendi sul design dell'API, e il carico di manutenzione è lo stesso che già porti sull'API pubblica.

Quando i dati non possono uscire dal perimetro

Documenti finanziari dei clienti, cartelle cliniche, discovery legale o ricerca proprietaria non possono passare per un gateway di terzi senza cambi contrattuali che la maggior parte dei buyer enterprise non firma. In quel caso l'unica domanda è su quale stack costruisci. Cloudflare Workers con l'Agents SDK è l'on-ramp più veloce. Un processo Node o Python dietro al tuo ingress esistente funziona anche, a patto che termini OAuth correttamente.

Quando nessun vendor gestito copre la surface che ti serve

L'ecosistema MCP è ampio ma disuguale. Le surface comuni (Slack, Notion, GitHub, Google Workspace, database principali) hanno tre o quattro opzioni gestite ciascuna. Le surface di nicchia (l'ERP interno dell'azienda, un'API di settore verticale, un servizio di inferenza custom) ne hanno zero. Se l'unico vendor che offre il tuo sistema è il vendor SaaS stesso, e il loro server non esprime i tool che ti servono davvero, costruire è il fallback.

Quando serve controllo a livello di tool oltre quello che il vendor espone

I server MCP gestiti espongono tipicamente un set curato di tool. Se ti servono tool che il vendor non ha costruito, se devi comporre tool attraverso sistemi che il vendor gestisce separatamente, o se ti serve logica di autorizzazione legata ai tuoi ruoli e ai tuoi diritti, li scrivi tu.

Dove comprare vince

Quando l'integrazione è commodity

Le integrazioni con le piattaforme SaaS principali sono quasi identiche da azienda ad azienda. Il flow OAuth è lo stesso. La lista di tool è la stessa. I rate limit sono gli stessi. Pagare un vendor perché lo mantenga una volta per tutti, e scaricare il costo sui clienti (o ammortizzarlo sul proprio prodotto) costa meno che reinventarlo in ogni team.

Quando ti serve in produzione questa settimana

La velocità pesa quando le feature AI sono una scommessa competitiva piuttosto che un investimento di piattaforma. Un team che spedisce un assistente AI in due settimane usando MCP gestito cattura il mercato che il team ancora a scrivere OAuth sul proprio server custom perde.

Quando il tuo team sicurezza è già tirato

MCP ha aggiunto circa 200.000 nuovi server pubblicamente accessibili alla superficie d'attacco nel 2025. Le disclosure di vulnerabilità sono state frequenti. Se il tuo team sicurezza non riesce già a tenere il passo con Dependabot, un server MCP self-hosted è una passività che il vendor gestito è pagato per portare.

Quando vuoi un unico pannello di governance

Cloudflare MCP Server Portals o Kong MCP Gateway ti danno un endpoint unico da monitorare, rate-limitare e auditare, anche se i server dietro sono molti. Costruire quello strato di governance da solo è un secondo progetto sopra ai server stessi.

Cosa facciamo in Studio

Il nostro default è il pattern ibrido. Per integrazioni SaaS che un cliente già usa (Slack, Notion, GitHub, Stripe), colleghiamo un server MCP gestito e spendiamo il nostro tempo sulla logica d'agente che lo chiama. Per l'accesso al database proprio del cliente, ai servizi interni o ai dati dei loro clienti, costruiamo un piccolo server MCP su Cloudflare Workers con l'Agents SDK, tipicamente 2-3 settimane incluse OAuth, audit log e deploy. Per un contesto più profondo su come è fatto quel build dentro un codebase esistente, vedi la nostra guida su come costruire un server MCP per un SaaS Next.js esistente, e l'inquadratura di prodotto in cos'è MCP e quando un SaaS ne ha bisogno.

Due regole che teniamo. Primo, nessun server MCP di produzione gira senza OAuth 2.1 e audit log, gestito o costruito che sia. Secondo, il server MCP non è mai il posto dove le feature nuove prototipano per prima. Prototipiamo in un server stdio in locale, poi promuoviamo a un server remoto con auth irrobustita quando la feature spedisce.

Come decidere sul tuo caso

Percorri gli assi in ordine, e fermati al primo che forza la risposta.

1. I dati possono uscire dal tuo perimetro legalmente? Se no, costruisci.
2. Il server MCP è un prodotto che vendi? Se sì, costruisci.
3. Un vendor gestito copre questo sistema con i tool che ti servono davvero? Se no, costruisci.
4. Il tuo team ha bisogno di un'integrazione funzionante entro due settimane? Se sì, compra.
5. Il tuo team sicurezza può possedere un nuovo servizio pubblicamente esposto a tempo indefinito? Se no, compra.
6. Questa è una delle tre integrazioni che rendono i tuoi agent diversi da quelli di tutti gli altri? Se sì, valuta costruire. Altrimenti, compra.

L'errore che vediamo più spesso è team che scelgono di default il build perché MCP sembra semplice in una demo da cinque minuti, poi scoprono sei mesi dopo di aver speso più sul plumbing MCP che sulle feature AI che doveva abilitare. Costruisci dove il costruire se lo merita, compra ovunque altro.