Cos’è MCP - e quando una piccola impresa ne ha davvero bisogno

Ora si dice «ci serve MCP» come due anni fa si diceva «ci serve un chatbot». Le lettere stanno per Model Context Protocol. La frase utile è più corta: è il modo in cui un agente può toccare i vostri strumenti senza inventare l’API da un post del 2024.

Un chatbot produce testo. Un agente sceglie uno strumento e lo esegue. MCP è la spina tra i due - nomi, schemi degli argomenti, risultati. Ho già scritto perché non dovete consegnare la cassa al modello. Qui manca la spina: quando quell’elenco di strumenti deve parlare MCP, e quando basta una funzione tipizzata sul vostro server.

1. USB, non una personalità

Non si «installa MCP» come si installa ChatGPT. Si espongono strumenti attraverso una presa standard. Qualsiasi agente compatibile - Cursor, Claude, un bot nella vostra app Next.js - può elencare quegli strumenti e chiamarli.

Tutto il trucco sta qui. Prima ogni fornitore aveva un modo suo per dare una funzione a un modello. Ora la presa è condivisa. Le prese condivise crescono ecosistemi: registry, comandi di install e un’ondata di prodotti che vi vendono un «gateway» prima che abbiate un solo strumento che valga la pena di innestare.

2. Cosa succede davvero in una chiamata

Tre passi. Poi potete smettere di leggere i diagrammi dei vendor.

• L’agente chiede al server quali strumenti esistono. Riceve nomi e schemi JSON. Esempio: create_invoice, con importo, valuta, id cliente.
• Chiama uno strumento con argomenti che stanno nello schema. Non un paragrafo. Non SQL inventato.
• Il server esegue il vostro codice. Il modello non vede mai la chiave Stripe. Il risultato torna come dati che l’interfaccia può mostrare.

Se sembra un’API

È un’API, scritta per un modello a cui non si affida una shell. Il protocollo è idraulica. La sicurezza sta ancora in quali strumenti esponete e quali aspettano una persona. Mettere MCP su un server non rende il prodotto sicuro. Quella riga sugli agenti l’ho già scritta questo mese. Qui vale senza una religione nuova.

3. Perché a agosto si sente tanto

Next.js 16.3 è uscito in stabile il 3 agosto 2026, con un endpoint MCP sul server di sviluppo. Un agente di codice può leggere errori, route e log in diretta invece di indovinare il vostro App Router dalla doc dell’anno scorso. Figma espone file, componenti e variabili come strumenti - quella è la riga «Figma-to-code via MCP» sul mio sito, non uno screenshot e una preghiera. I registry trattano ormai i server MCP come pacchetti. I vendor vendono gateway: un posto per autenticare, fare audit e poliziare un’intera «flotta» di agenti.

In un’azienda di dieci persone gran parte di quella flotta non esiste. La parte utile del rumore è la presa. Quella cara è comprare governance per persone che non avete assunto.

4. Quando vi serve davvero questo mese

Collegate MCP quando l’agente deve vedere un sistema vivo che avete già, e un prompt non è un sostituto.

• Un agente di codice su un sito Next.js: deve leggere la doc di questa versione e gli errori di questo processo, non inventare API di cache del 2024. Cosa farei su un sito esistente dopo 16.3 l’ho già scritto.
• Da Figma all’UI in produzione: il file è la fonte. L’agente deve interrogare il file, non un PNG del file.
• Più strumenti, un agente di prodotto: prenotazioni, CRM, FAQ con retrieval. Uno schema per strumento batte un nuovo adattatore per ogni vendor di chat.
• Avete già una lista bianca e un pulsante di conferma. MCP non li sostituisce. Impedisce al modello di inventare i nomi delle funzioni.

5. Quando non dovete

Un bot FAQ con retrieval non ha bisogno di MCP. Una server action che crea una prenotazione da un form non ha bisogno di MCP. «La keynote ha detto che ogni prodotto sarà agent-native» non è una spec.

Non comprate un gateway, un registry e un browser per agenti perché un roundup l’ha chiamato il momento npm. Vi serve un gateway quando avete molti agenti, molte persone e un auditor che chiederà chi ha chiamato refund alle 02:14. Fino ad allora il server che tiene le chiavi è il gateway.

Non sostituite un form che funziona con un agente che parla MCP. I soldi devono ancora passare da un form. L’agente lo tengo su bozza ed estratto. Una persona preme invia.

6. Come lo collegherei

Tre prese, non una piattaforma.

• MCP di Figma nel repo per cui sono stata assunta. Il diff lo leggo comunque. Il pixel-perfect è uno standard umano. Il protocollo impedisce solo al modello di inventare gli spazi da uno screenshot.
• next-devtools-mcp contro l’app Next.js in esecuzione, così l’agente vede route vere ed errori veri. AGENTS.md punta alla doc in node_modules. Quel rilascio l’ho già coperto.
• Nel prodotto: un elenco corto di strumenti come funzioni server tipizzate. MCP davanti se chi chiama è un agente esterno - Cursor, un’app desktop, un secondo modello. Una funzione semplice se chi chiama è la vostra route Next.js. Stessa lista bianca, stessa conferma, stesso registro di audit in entrambi i casi.

Le chiavi restano sul server

Il modello non tiene mai Stripe. Chiavi di idempotenza su addebito e prenotazione. Un registro che un non ingegnere può leggere: chi ha chiesto, quale strumento, quale id, chi ha confermato. MCP non scrive quel registro per voi. Lo scrivete voi.

Conclusione: prendete la presa, saltate la flotta

MCP è una presa. È diventato rumoroso perché le prese crescono ecosistemi, e gli ecosistemi crescono fatture. A una piccola impresa serve quando un agente deve parlare con Figma, con un’app Next.js viva o con un elenco corto dei vostri strumenti senza inventare l’API. Non serve come personalità, come upgrade del chatbot o come gateway per una flotta di uno.

Collego la presa dove fa risparmiare una settimana e la salto dove un form già funziona. Scrivete dal modulo quale sistema l’agente deve vedere - Figma, il sito in esecuzione, il calendario delle prenotazioni - e quale azione non deve mai girare senza una persona. Non partiremo comprandovi un gateway. :)