Integrazione AI nei sistemi web: cosa cambia con l'arrivo dell'MCP come standard

L'MCP è il modo standard con cui un sistema AI si collega ai tuoi strumenti aziendali e nel 2026 ha smesso di essere un'opzione tecnica per diventare la richiesta che ti farà il prossimo cliente. Per le agenzie che fanno integrazione AI nei sistemi web significa una cosa precisa: il modo in cui consegni quelle integrazioni sta cambiando, e chi non si adegua finirà a costruire ogni volta da zero quello che gli altri stanno standardizzando.

Cosa cambia quando un cliente ti chiede di "collegare l'AI ai loro sistemi"?

Fino a sei mesi fa la risposta era una pipeline custom: webhook, API wrapper, un agente che parla solo al tuo specifico setup. Ogni progetto era un'integrazione nuova. Ogni cliente un costo di setup.

Oggi la stessa richiesta si risolve con un MCP server. Tu pubblichi un endpoint che descrive le risorse del cliente (un Notion, un CRM, un database interno) e i tool che si possono usare sopra. Da quel momento Claude, ChatGPT, Cursor e qualunque agent che parli MCP si collegano senza che tu debba scrivere una riga di codice client-side per ognuno.

Forrester prevede che il 30% degli enterprise app vendor lancerà un proprio MCP server entro il 2026, il 75% degli API gateway vendor avrà funzionalità MCP, e il 50% degli iPaaS vendor le integrerà nativamente. Quando una quota così larga del mercato decide la stessa cosa nello stesso trimestre, non è una moda. È un'infrastruttura che sta scendendo di livello.

Perché un MCP server costa meno di dieci integrazioni custom?

Perché l'investimento è una sola volta, dal lato del sistema del cliente, e si ammortizza su N consumatori AI.

Esempio concreto. Cliente con un Notion interno dove stanno specifiche tecniche, contratti, deliverable. Vuole che il team possa chiedere "trovami tutti i progetti aperti con cliente X scaduti la settimana scorsa". Senza MCP: o costruisci un chatbot custom su Notion (che parla solo a Claude o solo a ChatGPT), o scrivi N integrazioni separate, una per ogni client AI che il team userà nei primi due anni.

Con MCP: costruisci un MCP server che espone tre tool search_projects, read_doc, list_clients. Da quel momento il team può cambiare AI client senza che tu rimetta mano al backend. Quando tra un anno il cliente vorrà usare Claude su mobile, ChatGPT nel browser e un agente custom su un workflow interno, sono tre client che parlano alla stessa interfaccia. Non tre integrazioni da rifare.

Il calcolo che ti chiederà il cliente non è "quanto costa un MCP server". È "quanto costa farsi trovare pronti quando arriva il prossimo AI client che vorrò provare". L'MCP è la risposta a quella domanda.

Cosa devi mettere a posto prima di pubblicare un MCP server?

Quattro cose che non sono opzionali, e che fanno la differenza tra un MCP server da demo e uno che il cliente lascia acceso in produzione.

Autenticazione. La specifica MCP standardizza OAuth 2.1 con PKCE. Per i clienti enterprise serve già pensare a SAML/OIDC. Non puoi pubblicare un endpoint che si collega a dati aziendali senza un'identità verificata che entra in ogni chiamata.

Audit. Ogni volta che un AI client esegue un tool sul tuo server, da qualche parte deve restare traccia: chi ha chiamato cosa, con quali parametri, con quale risultato. Se il cliente è in un settore regolato, questo non è negoziabile. Se non lo è, lo sarà tra due quarter.

Rate limit e cost control. Un AI client che gira da solo può chiamare il tuo server cento volte in trenta secondi. Se quel server attiva chiamate LLM o query a pagamento, il costo lievita prima che tu te ne accorga. Serve un limitatore lato server, non solo lato client.

Versioning del contratto. I tool che esponi cambieranno: aggiungerai parametri, rinominerai campi, deprecherai endpoint. L'AI client deve poter capire quale versione del contratto sta parlando. Senza versioning, un cambio lato tuo rompe le integrazioni di chiunque stia consumando.

Quando NON serve costruire un MCP server?

Tre casi in cui un MCP server è overhead.

Quando il progetto è una pipeline unica, single-AI, single-tool, e non ha bisogno di crescere. Uno script Python che chiama Claude una volta al giorno e scrive su un database non ha bisogno di MCP. Stai introducendo un protocollo per un caso che non sfrutta nessuna delle sue proprietà.

Quando il volume è basso e il setup è una tantum. Se il cliente vuole una sola integrazione fra Claude e un singolo strumento, e non c'è la prospettiva di moltiplicare gli AI client, una integrazione diretta è più semplice da consegnare e mantenere.

Quando l'integrazione è temporanea. Per un proof-of-concept di due settimane non serve un protocollo standard. Serve qualcosa che funzioni il tempo della demo e che si possa buttare via.

L'MCP risolve un problema di scala: tanti AI client, tanti strumenti aziendali, integrazione che deve durare. Se non hai quel problema, non hai bisogno di quella soluzione.

Tra due quarter il cliente non ti chiederà se sai costruire un MCP server. Ti chiederà perché il tuo sistema non ne espone già uno.