Nel 2026, collegare un agente software a un vault Obsidian non è più un'idea esotica. È, probabilmente, la configurazione per la gestione della conoscenza più sottovalutata che esista oggi. Eppure, quasi tutti coloro che lo fanno si fermano al primo passo: puntare Claude Code su una cartella e lasciargli leggere e scrivere file Markdown. Funziona. Ma è solo l'inizio, e capire perché il passo successivo, MCP, sia importante richiede prima di comprendere cosa abbiamo già e dove arrivano i suoi limiti.
Cosa è già possibile senza MCP
Quando Claude Code punta direttamente a un vault, opera come qualsiasi agente con accesso al filesystem: legge la struttura delle cartelle, usa grep e glob per individuare i contenuti rilevanti, e scrive o modifica file Markdown rispettando le convenzioni che gli hai fornito (frontmatter YAML, wikilink, una gerarchia di cartelle per tipo di contenuto). Niente plugin, niente database, niente API: solo testo semplice e un agente che sa leggerlo e scriverlo con giudizio.
Il risultato, quando il sistema è ben progettato, è più potente di quanto sembri. Come riferimento reale, non ipotetico: un vault che seguo da vicino è passato, esattamente con questo metodo, da 78 fonti grezze (articoli, paper, documentazione) a 180 pagine wiki interconnesse (83 delle quali pagine concettuali, il resto strumenti, persone, confronti e riassunti di fonti), tutte con riferimenti incrociati che l'agente stesso mantiene aggiornati ogni volta che entra nuovo contenuto. Senza che nessuno abbia scritto una singola pagina a mano.
Il limite dell'accesso diretto ai file
Ma questo modello ha un limite strutturale, non solo una limitazione prestazionale. Claude Code deve sapere in anticipo come è organizzato il tuo vault: quale cartella è immutabile, qual è la convenzione per il frontmatter, dove risiedono i concetti rispetto agli strumenti. Ogni nuovo vault è, in pratica, un'integrazione diversa che deve essere spiegata da capo nel prompt di sistema.
Inoltre, l'agente non può chiedere a un vault "cosa sei in grado di fare?" Può solo leggere ciò che già esiste ed eseguire operazioni generiche sui file (leggi, scrivi, cerca per testo). Non c'è modo di esporgli un'operazione derivata (dammi il grafo dei backlink di questa nota, esegui questa query Dataview, dimmi quali pagine sono orfane) senza che l'agente stesso ricostruisca quella logica da zero ogni volta, sprecando contesto e margine di errore lungo il percorso.
Cosa risolve MCP, in dettaglio
MCP (Model Context Protocol) è lo standard aperto che Anthropic ha lanciato a novembre 2024 per risolvere esattamente questo problema: l'integrazione tra modelli AI e sistemi esterni. Prima di MCP, se N assistenti AI dovevano connettersi a M strumenti o fonti dati diversi, erano necessarie N×M integrazioni personalizzate: quando un'applicazione voleva supportare Notion, lo costruiva da zero; quando un'altra voleva fare lo stesso, lo ricostruiva da capo. MCP trasforma quel N×M in N+M: si costruiscono client generici (uno per applicazione) e server generici (uno per sistema), e qualsiasi client parla con qualsiasi server senza integrazione personalizzata.
L'analogia corretta è l'USB-C: prima, ogni periferica aveva il suo connettore; con l'USB-C, il dispositivo deve solo parlare il protocollo, senza preoccuparsi se è collegato a un Mac o a un PC.
L'architettura ha tre livelli. L'host è l'applicazione rivolta all'utente (Claude Code, Claude Desktop o un agente personalizzato) che interpreta ciò che viene richiesto e decide se ha bisogno di dati o strumenti esterni. Il client vive all'interno dell'host e gestisce una connessione 1:1 con ogni server, traducendo le richieste astratte in messaggi MCP concreti e gestendo il ciclo di vita della sessione. Il server collega il protocollo a un sistema reale, in questo caso un vault Obsidian, traducendo le richieste MCP in operazioni native.
Due proprietà rendono questo più di un semplice livello di astrazione estetico. La prima è la scoperta dinamica delle capacità: al momento della connessione, il client chiede al server cosa è in grado di fare, e il server risponde in tempo reale. Se il server aggiunge una nuova funzione domani, il client non ha bisogno di essere riprogrammato per usarla. La seconda è il disaccoppiamento tra intelligenza e dati: chi costruisce il server MCP per Obsidian non ha bisogno di sapere quale modello lo userà, e chi costruisce l'agente non deve ricostruire la propria integrazione ogni volta che cambia modello.
Un server MCP espone tre tipi di primitive. Le risorse sono dati che il modello può leggere ma non modificare: il contenuto di una nota, i risultati di una ricerca, il grafo dei backlink. Gli strumenti sono azioni che il modello può invocare attivamente: creare una nota, aggiornare un tag, eseguire una query strutturata. I prompt sono modelli di istruzioni riutilizzabili e parametrizzabili, ad esempio "riassumi questa fonte e genera la pagina wiki corrispondente" come operazione nominata, non come testo libero da riscrivere ogni volta.
Applicato a Obsidian, nello specifico
Esistono già server MCP costruiti specificamente per Obsidian all'interno del suo ecosistema open source, solitamente supportati dal plugin REST API locale di Obsidian stesso, che espongono operazioni come la ricerca semantica all'interno del vault, la creazione e modifica di note, la gestione di tag e metadati, o la lettura del grafo dei collegamenti, senza che l'agente debba conoscere in anticipo l'esatta struttura delle cartelle.
Ciò che cambia in pratica è sottile ma importante: senza MCP, Claude Code gestisce il tuo vault con regole che gli hai spiegato una per una. Con MCP, il tuo vault diventa uno strumento che Claude Code può utilizzare esattamente come utilizzerebbe un'API o un database, scoprendone le capacità al momento della connessione, non memorizzandole in anticipo. E quella stessa connessione funziona per qualsiasi altro client MCP, non solo Claude Code: lo stesso server potrebbe alimentare un agente diverso, in un'altra applicazione, senza toccare una riga di codice lato Obsidian.
Quadro pratico: tre livelli di maturità
Per capire a che punto è la tua configurazione, ecco il quadro che uso io:
Livello 0: copia e incolla manuale del contesto. Ogni conversazione parte da zero; l'utente incolla frammenti rilevanti delle proprie note nella chat. Funziona per compiti specifici, ma non scala.
Livello 1: agente con accesso diretto ai file. È qui che si trovano oggi la maggior parte delle configurazioni Claude Code + Obsidian, incluso l'esempio delle 78→180 pagine in questo articolo. L'agente legge e scrive il vault direttamente, seguendo le convenzioni spiegate in un file di istruzioni. È già sostanzialmente più potente del livello 0 e, per un singolo vault gestito da un singolo agente, potrebbe essere sufficiente per molto tempo.
Livello 2: agente connesso tramite MCP. Il vault è esposto come un server con capacità individuabili dinamicamente, riutilizzabile tra diversi modelli e applicazioni. Ha senso non appena entrano in gioco più di un agente, più di un vault, o la necessità di esporre operazioni che vanno oltre la lettura e scrittura file per file.
Non è necessario passare direttamente al livello 2 per sfruttare un vault gestito dall'AI. Il livello 1 è già un vero balzo in avanti rispetto a non avere alcun sistema. Ma capire cosa risolve MCP significa capire dove sta andando tutto questo: da "la mia AI può leggere i miei appunti" a "la mia conoscenza è un sistema che qualsiasi AI può utilizzare."
A che livello è la tua configurazione in questo momento? Raccontamelo nei commenti. Se c'è abbastanza interesse, il prossimo articolo sarà una guida passo passo su come configurare il tuo primo server MCP per Obsidian.
E se questo ti è stato utile, seguimi @chesny
Questo è solo il primo articolo di una serie sugli agenti che smettono di leggere i sistemi e iniziano a utilizzarli.
