Che cos'è esattamente un server MCP?

Un modello linguistico, da solo, non può leggere i suoi file, interrogare il suo database né ricordarsi di ieri. Produce testo. Tutto il resto — ogni azione, ogni consultazione — accade perché un programma esterno al modello è andato a farlo.

Prima del Model Context Protocol, ognuna di quelle connessioni era su misura. Per far leggere il suo Notion a Claude e il suo Notion a ChatGPT, bisognava scrivere due integrazioni contro due sistemi di plugin diversi, e nessuna sopravviveva alla versione successiva del fornitore. MCP è l'accordo che mette fine a questo: un server, qualsiasi client che parli il protocollo.

La forma generale

Ci sono tre parti. L'host è l'applicazione che lei usa davvero: un assistente desktop, un IDE, un'interfaccia di chat. Il client vive dentro l'host e gestisce una connessione. Il server è la cosa che lei, o qualcun altro, ha scritto, ed è lui a detenere la capacità: accesso a un filesystem, a un'istanza Postgres, a un calendario, a una memoria.

Parlano JSON-RPC 2.0. Non è un dettaglio su cui soffermarsi, ma vale la pena saperlo, perché significa che l'insieme è ispezionabile. Può leggere i messaggi. Non c'è alcuno strato magico in cui il modello «decide» qualcosa che lei non può vedere.

La sequenza è volontariamente scialba: il client si connette, le due parti si scambiano le capacità, il client chiede che cosa offre il server, e da lì in poi il modello può richiedere una di quelle cose per nome. Il server esegue. Il risultato torna come testo che il modello legge.

Le tre cose che un server può esporre

Quasi tutti i server che incontrerà usano la prima e ignorano le altre due. Tutte e tre meritano di essere capite, perché la differenza riguarda chi decide.

• Tools (strumenti) — funzioni che il modello può chiamare di propria iniziativa. `search_memory`, `create_issue`, `run_query`. Il modello legge la sua descrizione dello strumento e decide quando si applica. È qui che sta la potenza, ed è qui che sta il rischio.
• Resources (risorse) — dati che l'*host* legge e mette nel contesto. Un file, un record, un documento. Non è il modello a innescare, è l'applicazione. Meno autonomia, più prevedibilità.
• Prompts — modelli riutilizzabili che l'utente sceglie deliberatamente. L'equivalente più vicino a un comando slash.

Una conseguenza che si scopre tardi: la descrizione di uno strumento non è documentazione, sono istruzioni al modello. Se uno strumento non viene mai chiamato quando dovrebbe, la correzione di solito non sta nel codice — sta nel fatto che la descrizione non è riuscita a dire al modello a quale situazione appartiene. Abbiamo riscritto le nostre esattamente per questo motivo, e il tasso di chiamata è cambiato immediatamente.

Locale o remoto: la scelta che conta

Esistono due trasporti, e scegliere tra i due determina gran parte di come sarà la sua configurazione.

stdio avvia il server come processo figlio sulla sua macchina. L'host esegue un comando, gli parla tramite input e output standard, e lo termina all'uscita. Nulla esce dal dispositivo. È la risposta giusta per tutto ciò che tocca file locali, ed è il motivo per cui i server filesystem e git funzionano così. Il costo: esiste solo su quella macchina. Il suo portatile e il suo telefono non lo condividono, e il server è vivo solo finché lo è l'applicazione.

HTTP fa girare il server da qualche parte raggiungibile. L'host si connette via rete, autenticandosi di solito con OAuth 2.0. A quel punto ogni dispositivo vede lo stesso server, e un servizio ospitato può esserne uno. Il costo: si fida di chi lo gestisce, e dovrebbe sapere dove gira — che è l'argomento di un altro articolo qui.

Per la memoria in particolare, la scelta non è affatto stretta. Una memoria che esiste solo su un portatile è un quaderno. Tutto il senso della cosa è che l'assistente che apre su un altro dispositivo sappia già.

Che cosa un server può farle

Un server MCP è codice a cui ha concesso il diritto di agire. Lo tratti di conseguenza.

Un server locale gira con i permessi del suo utente — può leggere tutto ciò che può leggere lei. Uno remoto riceve tutto ciò che il modello gli manda, che col tempo è moltissimo su di lei. E la descrizione di uno strumento è testo rivolto al modello, quindi un server può orientare il comportamento dell'assistente, non solo rispondergli.

Quattro domande da porsi prima di installarne uno:

1. Posso leggere il codice sorgente, o è un binario fornito da uno sconosciuto?
2. Quali permessi detiene — una sola cartella, o tutta la mia home?
3. Se è remoto: chi lo gestisce, in quale paese, e posso cancellare i miei dati?
4. Scrive, o si limita a leggere? Un server in sola lettura ha un raggio d'impatto molto più piccolo.

L'ecosistema è giovane e costruito in maggioranza da individui in buona fede. Non è la stessa cosa che sottoposto ad audit. Il registry ufficiale e le liste della comunità sono strumenti di scoperta, non garanzie.

Quando dovrebbe scriverne uno

L'asticella è bassa: un server che espone due strumenti sta in un file breve, in Python o in TypeScript, e gli SDK gestiscono il protocollo. La vera domanda è se uno strumento sia la forma giusta per ciò che vuole.

Di solito lo è quando l'assistente deve *agire* su un sistema vivo, o recuperare qualcosa che cambia. Di solito non lo è quando le serve soltanto che il modello conosca un corpo di testo fisso: incollarlo, o esporlo come risorsa, è più semplice e più affidabile che insegnare al modello ad andare a chiederlo.

Se vuole i dettagli, la specifica è breve e leggibile, cosa rara e che dice qualcosa di buono sul progetto.

Pryzm è un server MCP remoto il cui unico mestiere è la memoria: archivia ciò che lei gli dice e ne recupera le parti pertinenti più tardi, in qualsiasi client che parli il protocollo. Se preferisce ospitarlo da sé, esistono diversi server di memoria gratuiti e auto-ospitabili, e li elenchiamo nel nostro confronto.