Dare a Cursor una memoria che dura, con MCP

Apri una chat nuova in Cursor e l'agente riparte da zero. Il codice lo legge, ma non sa perché il mese scorso hai scelto quel database, quale cliente ha chiesto quel formato di data strano, o che la correzione più ovvia l'hai già provata e ha rotto la build. Glielo rispieghi, e la settimana dopo di nuovo.

Qui vediamo cosa tiene Cursor da una chat all'altra, dove si ferma e come dargli una memoria a lungo termine via MCP, che puoi leggere e correggere tu. Quello che diciamo su Cursor l'abbiamo controllato sulla sua documentazione e sul changelog il 26 ottobre 2026.

Cosa ricorda Cursor da solo

Meno di quanto si pensi, e soprattutto istruzioni più che memoria.

Cursor aveva una funzione chiamata Memories, che salvava fatti presi dalle chat. Lo staff di Cursor ha scritto sul forum ufficiale che è stata tolta con le versioni 2.1, e ha indicato un comando che esporta le vecchie memorie in un file di regole. La documentazione di oggi non la nomina più. Restano le regole, su più livelli:

• Le regole di progetto stanno in .cursor/rules dentro il repository, come file .mdc sotto controllo di versione. Ognuna può valere sempre, quando l'agente la giudica pertinente, quando un file corrisponde a uno schema, oppure solo quando la citi.
• Le regole utente sono le tue preferenze personali, si impostano in Customize → Rules e valgono in tutti i progetti.
• Le regole di team si gestiscono dalla dashboard di Cursor sui piani Team ed Enterprise, e gli admin possono renderne una obbligatoria per tutti. Se due regole si contraddicono vince quella di team, poi quella di progetto, poi quella utente.
• AGENTS.md è un file Markdown semplice nella radice del progetto, o nelle sottocartelle, che Cursor legge come alternativa più semplice a .cursor/rules. I file annidati si sommano a quelli delle cartelle sopra, e vince il più specifico.

Il consiglio di Cursor è tenere le regole sotto le 500 righe, dividere quelle grandi e aggiungerne una solo quando vedi l'agente ripetere lo stesso errore. Dice già a cosa servono: indicazioni brevi e stabili su come si lavora in quel codice.

C'è anche una novità. A settembre 2026 Cursor ha lanciato i Projects, in beta: un agente coordinatore che pianifica i lavori più grossi e li passa ad altri agenti, e gira su un computer suo nel cloud. Secondo il changelog ogni Project tiene dei file che si sincronizzano fra il cloud e le macchine locali usate dai suoi agenti, così chi arriva dopo riusa quello che hanno imparato quelli prima. È un contesto condiviso vero, ma appartiene a un Project, dentro Cursor.

Dove si ferma

Regole e AGENTS.md vanno benissimo per «usa pnpm, non npm» e «i test stanno accanto al file». Per il resto di quello che vorresti far ricordare a un assistente vanno meno bene.

Sono legate a un repository. Una decisione su un cliente, gli appunti di una call, il motivo per cui avete lasciato un fornitore: niente di questo c'entra col codice, e se ce lo metti finisce in ogni clone e in ogni pull request. La documentazione stessa consiglia di rimandare ai file invece di copiarli nelle regole, perché il contenuto copiato invecchia.

Sono istruzioni, non conoscenza. Una regola dice all'agente come comportarsi. Non è il posto per un registro che cresce di cosa è successo e perché. Se ci accumuli la storia arrivi presto alle 500 righe, e ogni regola sempre attiva occupa contesto in ogni chat.

Fuori da Cursor non le vede nessuno. Le tue regole non arrivano a Claude nel browser, a ChatGPT sul telefono, né a Claude Code e Codex nel terminale. Se progetti una funzione con un'AI e la costruisci in Cursor, il piano resta dove l'hai scritto. È lo stesso problema che abbiamo visto per altri strumenti in CLAUDE.md e AGENTS.md.

E l'agente non le aggiorna da solo. Da quando le Memories non ci sono più, in Cursor niente si segna quello che hai imparato in una chat, a meno che tu non modifichi una regola a mano o lo chieda all'agente.

MCP: la porta per una memoria vera

Cursor supporta il Model Context Protocol, lo standard aperto con cui un'app di AI parla con strumenti esterni. Secondo la documentazione:

• i server si configurano in mcp.json: .cursor/mcp.json dentro un progetto, oppure ~/.cursor/mcp.json nella tua cartella home per tutti i progetti;
• i server locali girano via stdio, quelli remoti via SSE o Streamable HTTP;
• i server remoti possono farti entrare con OAuth, senza chiavi da incollare in un file;
• l'agente usa da solo gli strumenti MCP quando servono, e di base ti chiede il permesso prima di lanciarne uno;
• un server si spegne da Customize, e a quel punto non si carica proprio.

Quindi un server di memoria è un server MCP come gli altri. L'agente può cercarci dentro all'inizio di un lavoro, leggere le note che contano e segnare una decisione prima che la chat finisca. E siccome il server sta fuori da Cursor, le stesse note possono raggiungerle anche altre AI. Che tipi di server di memoria esistono, locali o remoti, e come conservano le cose, lo trovi in Cos'è un server MCP per la memoria.

Cosa guardare in una memoria per Cursor

Poche domande fanno già una bella scrematura.

La puoi leggere? Se la memoria è testo semplice che apri, correggi riga per riga ed esporti, il controllo resta tuo. Un database vettoriale che interroghi solo passando dall'AI è più difficile da verificare.

Ti segue fuori dall'editor? Quasi nessun lavoro è solo codice. Se le stesse note ci sono anche quando parli con Claude o ChatGPT, smetti di riscrivere il contesto.

Chi ha scritto cosa? Quando scrive l'agente vuoi vedere che è stato lui, da quale strumento, e poter tornare alla versione di prima.

Ne puoi condividere un pezzo? A un collega o a un cliente può servire una cartella, non tutto.

E quanto costa in contesto? Gli strumenti entrano nel contesto dell'agente. Un buon server restituisce le poche note che servono, non tutto quello che ha.

Dove si colloca Cobrain

Cobrain è una memoria condivisa costruita su questa idea. Le note sono file Markdown in cartelle, dietro un indirizzo MCP remoto. Per Cursor c'è un plugin di Cobrain su cursor.directory: aggiunge il connettore e una skill che dice all'agente quando caricare il contesto e come salvare senza sovrascrivere quello che c'è già. Lo installi, consenti l'accesso nel browser e gli strumenti compaiono nelle impostazioni MCP di Cursor. La guida per Cursor ti accompagna in un paio di minuti.

Le regole continuano a fare il loro lavoro, la parte breve su come si scrive il codice. Cobrain tiene il resto, per esempio le decisioni sui clienti e le strade già provate. Ogni nota dice chi l'ha scritta, tu o una delle tue AI, e le versioni precedenti si recuperano. Le stesse note le raggiungono Claude, ChatGPT, Claude Code, Codex e Antigravity, che è proprio la parte che un file di regole non può fare. Come funziona fra strumenti diversi lo trovi in Cobrain tra AI diverse.

Domande rapide

Cursor ricorda le chat precedenti? Non come memoria generale. La funzione Memories è stata tolta con le versioni 2.1, secondo lo staff di Cursor sul forum. Restano le regole (di progetto, utente e di team) e AGENTS.md, più il contesto condiviso di un Project se usi i Projects.

Dove stanno le regole di Cursor? Le regole di progetto sono file .mdc in .cursor/rules dentro il repository. Le regole utente si impostano in Customize → Rules. Quelle di team si gestiscono dalla dashboard di Cursor sui piani Team ed Enterprise.

Cursor legge AGENTS.md? Sì. Cursor legge AGENTS.md nella radice del progetto e nelle sottocartelle, e vince il file più specifico.

Come si aggiunge un server MCP a Cursor? Lo metti in .cursor/mcp.json per un progetto o in ~/.cursor/mcp.json per tutti, oppure lo installi dal marketplace o con un plugin. I server remoti possono farti entrare con OAuth.

Cursor e Claude possono condividere la stessa memoria? Non attraverso le regole di Cursor, che restano nel repository e in Cursor. Possono condividere note tenute dietro un server MCP collegato a entrambi.