AI & MCP
MCP vs REST: due interfacce per due client diversi
MCP non sostituisce REST: uno parla a un programma con lo schema noto, l'altro a un modello che deve scoprirlo. Ecco quando vince ciascuno.
In sintesi
- REST presuppone uno schema noto; MCP lo pubblica a runtime con tools/list e JSON Schema.
- Il nostro backend ha 210 route handler REST e 9 strumenti MCP: superfici diverse per client diversi.
- MCP non offre cache HTTP né paginazione standard: un client macchina che legge molto resta su REST.
MCP non sostituisce REST: REST parla a un programma che conosce già lo schema, MCP a un modello che deve scoprirlo. Sono due interfacce per due client diversi, e il criterio di scelta è chi sta chiamando.
Cosa vede il chiamante
| Aspetto | REST | MCP |
|---|---|---|
| Chi chiama | un programma con lo schema già scritto | un modello che deve scoprire gli strumenti |
| Contratto | OpenAPI o documentazione, prima della chiamata | tools/list a runtime, con JSON Schema per ogni tool |
| Cache | ETag, Cache-Control, proxy condivisi | nessuna semantica HTTP standard |
| Errori | status HTTP più corpo JSON | codici JSON-RPC, per esempio -32001 su token non valido |
| Sessione | senza stato per richiesta | sessione con protocolVersion e capacità negoziate |
| Costo fisso per chiamata | header e URL | circa 900 token di schemi, 3.655 byte |
Lo stesso dato, due chiamate
curl -s https://ui.eneawork.it/api/stats
curl -s https://ui.eneawork.it/mcp \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'La prima chiamata restituisce un oggetto JSON che conosci in anticipo. La seconda restituisce la descrizione degli strumenti disponibili: nome, descrizione e schema di input. Un programma può leggere la prima; un modello ha bisogno della seconda per decidere se e come agire.
Il criterio di scelta
- Chiamante in codice: REST, perché lo schema è già nel codice e la cache HTTP fa metà del lavoro.
- Chiamante che è un modello: MCP, perché la scoperta avviene a runtime e il numero di strumenti resta piccolo.
- Lettura intensa: REST, per ETag, paginazione e proxy condivisi che MCP non definisce.
- Azione singola e ripetibile: MCP, con uno schema stretto che il modello può leggere in poche centinaia di token.
Perché 210 contro 9
Le due superfici non sono in concorrenza: 210 route handler coprono pagine, sitemap, registry, account e webhook, e nessun modello le leggerebbe tutte. I 9 strumenti MCP sono una selezione pensata per stare in contesto: search_components, get_component, search_blocks, get_block, get_design_system, list_design_systems, compose_page, list_categories e get_page, verificati il 1 novembre 2026.
La limitazione
MCP non ha cache HTTP, non ha una paginazione standard e non ha un modo condiviso per esprimere un costo per chiamata. Il nostro endpoint è in sola lettura e chiede un token OAuth per le quote, mentre /api/stats risponde in modo anonimo: due storie di autenticazione diverse sullo stesso catalogo. Un client macchina che legge migliaia di record deve restare su REST.
Dove continuare
Il protocollo è spiegato in che cos'è MCP, il disegno degli strumenti in progettare un tool MCP e il flusso di autorizzazione in OAuth per server MCP. Per il confronto tra due modi di esporre la stessa logica leggi Route Handlers vs Server Actions. Il catalogo dietro entrambe le interfacce è in 111.985 componenti e 1.556 blocchi; un record citabile è sidebar di shadcn.
Domande frequenti
MCP sostituirà le API REST?
No. MCP è un livello di scoperta e chiamata per un modello, e sotto può avere una API REST. Le due cose convivono: la stessa azienda espone REST ai programmi e MCP agli agenti.
Posso usare MCP senza HTTP?
Sì. Il trasporto stdio avvia un processo locale e non richiede autenticazione, mentre Streamable HTTP serve un endpoint remoto. Il protocollo resta JSON-RPC 2.0 in entrambi i casi.
Quanto costa in token uno schema MCP?
Nel nostro caso 3.655 byte per nove strumenti, cioè circa 900 token a quattro caratteri per token, misurati il 1 novembre 2026. Con cinquanta strumenti il costo fisso diventa il problema principale.
Perché il vostro MCP è in sola lettura?
Perché un catalogo non deve scrivere sul repository dell'utente da un endpoint remoto. Le scritture restano al client, che ha il codice in locale e può mostrare il diff prima di applicarlo.
Un agente può chiamare direttamente le route REST?
Può, se gli dai una lista di URL e un formato. Perde però la scoperta a runtime e il costo degli schemi ricade sul prompt, che è esattamente ciò che MCP sposta sul server.