MCP (Model Context Protocol)

Prima di uno standard simile, ogni applicazione che voleva dare a un modello accesso a un calendario, un database o un repository di codice doveva scrivere un proprio connettore. MCP divide il lavoro in due. Un server racchiude una capacità, come un file system o un sistema di ticket, e descrive ciò che offre. Un client dentro l’applicazione di IA scopre quella descrizione e la passa al modello, che può poi richiamare le capacità. I server possono offrire strumenti che compiono azioni, risorse che forniscono dati da leggere e prompt che confezionano istruzioni già pronte. Server tipici collegano calendario, app per appunti, bug tracker, foglio di calcolo, database, casella di posta, repository di codice o browser, ciascuno esposto nello stesso modo prevedibile. Le risorse possono essere file, righe di tabella, screenshot o log; i prompt, modelli come una checklist per la revisione del codice o un riassunto di riunione. Pensa a un cassetto di caricabatterie incompatibili sostituito da un’unica presa universale.

I server girano sulla tua macchina, parlando con l’applicazione tramite ingresso e uscita standard, oppure a distanza via HTTP. È un livello diverso dal tool calling. Il tool calling è il modo in cui un modello chiede una funzione in una richiesta; MCP è il modo in cui l’applicazione, a monte, trova e raggiunge molte di queste funzioni. L’applicazione di solito traduce gli strumenti MCP scoperti in normali definizioni di strumenti per il modello, quindi i due lavorano insieme, e il modello non si collega mai direttamente a un server. I server remoti pongono anche la questione dell’autenticazione, quindi scopri come un server dimostra chi lo chiama e dove finiscono le tue credenziali. Un aiuto locale si presta alla prima via, un servizio di team alla seconda.

La comodità porta rischi che meritano attenzione. Un server può leggere e modificare tutto ciò a cui gli dai accesso, e uno malevolo o trascurato può far trapelare dati o eseguire azioni dannose. Descrizioni e risultati che arrivano da un server sono testo che un modello leggerà, quindi possono nascondere istruzioni pensate per orientarlo. Installa server da fonti di cui ti fidi, concedi i permessi più stretti, controlla cosa fa ogni strumento e preferisci richieste di approvazione per tutto ciò che scrive, invia o cancella. Conviene leggere l’elenco degli strumenti annunciati da un server prima di attivarlo, come i permessi di un’app per telefono. La trappola più nota è l’iniezione di prompt, in cui un risultato avvelenato dice al modello di far trapelare un file.

Per essere precisi su ciò che esiste oggi: nelle Missioni, NeverNo può collegarsi a un server MCP remoto che aggiungi tu (il suo indirizzo e un token facoltativo), mentre l’API non ospita server MCP né vi si collega. Offre la chiamata di funzioni sui completamenti di chat, in cui il tuo codice definisce gli strumenti e li esegue, più un endpoint Messages compatibile con Anthropic. I modelli per cui capabilities.tools è true nell’elenco /models accettano strumenti.

Uno strumento che esegui tu e che parla MCP può comunque usare NeverNo come modello puntando il proprio URL di base su https://neverno.ai/api/v1, dato che gli endpoint seguono i formati di OpenAI e di Anthropic. Le connessioni MCP vivono allora in quello strumento, non presso NeverNo. DeepSeek V4 Flash, un modello privato gratuito con una finestra di contesto di 128.000 token, è uno dei modelli dell’elenco.