Ogni nuova chat inizia con un agente che ha dimenticato i tuoi documenti. Può rileggerli, a costo di tempo e contesto, oppure può consultare qualcosa che ricorda. GroupDocs.Search.Mcp mantiene un indice full‑text nominato su disco, localmente, che sopravvive tra le sessioni e i riavvii del container, così Claude Desktop, Cursor o Copilot avviano ogni sessione con i documenti del progetto già ricercabili e li aggiornano con una singola chiamata quando i file cambiano:

Ho modificato alcuni contratti. Aggiorna l’indice dei contratti, poi dimmi quali contratti menzionano una penale ora.

La versione passo‑passo con configurazione e risoluzione dei problemi è nella documentazione: Come mantenere aggiornato un indice di documenti quando i file cambiano.

Cosa significa “memoria” per un agente?

In pratica, due cose: uno stato che persiste al di fuori della conversazione e un modo economico per mantenere vero quello stato. La cronologia della chat fallisce in entrambi i casi: termina con la sessione e nulla la aggiorna quando un documento cambia. Un indice di ricerca è più adatto ai documenti. Vive su disco accanto a loro, risponde a “quali file dicono X” senza caricarli e può essere aggiornato in modo incrementale.

session 1    add_to_index --> index "contracts" --+
                                                 |  kept on disk in
session 2    search, get_text_fragments <--------+  /data/.groupdocs-search-
             (nothing is re-read)                    index/contracts
files edit   update_index --> re-reads changed, added, deleted files only
new project  create_index {"indexName":"legal-2026"} --> a separate index

Come funziona l’aggiornamento?

update_index confronta l’indice con i file su disco e rilegge solo ciò che è cambiato. Ecco cosa ha restituito il server nel nostro test, dopo che a un contratto è stata aggiunta una clausola di penale tra due chiamate:

-> get_index_info {"indexName":"contracts"}
<- { "documentCount": 5, "indexedPaths": [ "contracts" ],
     "documentsWithErrors": [], "status": "Ready" }

-> update_index {"indexName":"contracts"}
<- Index 'contracts' updated: 0 added, 1 updated, 0 removed;
   5 document(s) in the index.

-> search {"query":"penalty","indexName":"contracts"}
<- documentsFound 3, including the edited initech-nda.docx

I conteggi ti indicano cosa è successo: un file è stato riletto, nient’altro è stato modificato. I file eliminati scompaiono nella stessa chiamata.

Perché un indice per progetto?

Perché corpora separati meritano risposte separate. Una domanda sui contratti di quest’anno non dovrebbe far emergere le bozze dell’anno scorso, e i documenti di un cliente non dovrebbero mescolarsi con quelli di un altro cliente. I nomi degli indici sono economici:

-> create_index {"indexName":"legal-2026"}
<- Index 'legal-2026' created. Add documents with add_to_index
   (indexName: 'legal-2026').

Ogni indice è una cartella sotto /data/.groupdocs-search-index, e get_index_info senza nome li elenca tutti. Raramente è necessario usare esplicitamente create_index, perché add_to_index crea un indice al primo utilizzo, ma nominarli deliberatamente è ciò che trasforma “un indice” nella “memoria di questo progetto”.

L’unica regola sulla rimozione

La engine rimuove i percorsi che sono stati aggiunti, non i singoli file al loro interno. Il server lo dichiara apertamente quando provi:

-> remove_from_index {"documentPath":"contracts/hooli-supply-terms.txt",...}
<- Removal failed for 'contracts/hooli-supply-terms.txt':
   'contracts/hooli-supply-terms.txt' is inside the indexed folder
   'contracts'. GroupDocs.Search removes whole indexed paths only: ...

Quindi progetta di conseguenza: se prevedi di eliminare in seguito una parte di un corpus, come un anno, un cliente o le bozze, indicizza quelle parti come percorsi separati (contracts/2025, contracts/2026) e ciascuno può essere rimosso singolarmente. Eliminare un file su disco ed eseguire update_index lo rimuove anch’esso.

Mantenerlo aggiornato senza chiedere

create_index (optional)
      |
      v
add_to_index ---> search ---> get_text_fragments
      ^              ^
      |              |  get_index_info: counts, paths, status
update_index  (files changed on disk)
      |
remove_from_index  (only a path that was given to add_to_index)

Tre modi pratici per rendere l’aggiornamento automatico:

  1. Nelle istruzioni dell’agente. Una riga in CLAUDE.md o AGENTS.md, “chiama update_index per l’indice di questo progetto prima di rispondere se i file potrebbero essere cambiati”, fa sì che l’agente lo faccia all’inizio di una sessione.
  2. Su base programmata. Qualsiasi automazione compatibile con MCP può chiamare update_index ogni notte; quando poco è cambiato, la chiamata è veloce.
  3. Dopo una copia massiva. Una chiamata rileva ogni file aggiunto.

Gli indici sopravvivono anche agli aggiornamenti: gli indici creati da GroupDocs.Search 22.7 a 26.8 vengono convertiti al primo utilizzo, con un backup conservato accanto a loro.

Cosa decide l’agente e cosa fa l’indice

L’agente decide L’indice fa
a quale indice appartiene una domanda mantiene ogni indice nominato nella sua cartella
quando i file potrebbero essere cambiati rilegge solo i file cambiati, aggiunti e eliminati
quali parole cercare e quali varianti provare corrisponde a parole, frasi, intervalli; segnala i termini trovati
quanta contestualizzazione citare restituisce passaggi con il numero richiesto di parole intorno
cosa dirti nulla: restituisce conteggi, percorsi e testo, mai conclusioni

La divisione è deliberata. Il giudizio rimane al modello, e i fatti su cui ragiona provengono da uno strumento il cui output puoi ispezionare.

Limiti onesti

  • In modalità valutazione un indice contiene al massimo 100 documenti e una ricerca restituisce al massimo 10. Chiama get_license_status prima di fare affidamento su un indice come fonte di verità.
  • L’indice persiste solo se /data (o il volume dell’indice) è una cartella host montata; altrimenti scompare con il container.
  • L’indice contiene il testo dei documenti: proteggilo e smaltiscilo come i documenti.
  • Solo Docker; su Linux aggiungi --user "$(id -u):$(id -g)" affinché il container possa scrivere l’indice.

FAQ

L’agente ricorda i miei documenti tra le sessioni?
Con un indice persistente, sì: l’indice rimane su disco e la sessione successiva lo ricerca senza rileggerne nulla.

Devo ricostruire l’indice quando i file cambiano?
No. update_index rilegge solo i file cambiati, aggiunti e eliminati.

Posso tenere l’indice separato dai documenti in sola lettura?
Sì. Monta i documenti in sola lettura, monta una cartella scrivibile su /index e imposta GROUPDOCS_MCP_INDEX_PATH=/index.

Approfondisci