Elke nieuwe chat begint met een agent die je documenten is vergeten. Hij kan ze opnieuw lezen, tegen de kosten van tijd en context, of hij kan iets raadplegen dat zich herinnert. GroupDocs.Search.Mcp houdt een benoemde full‑text index op schijf, lokaal, die overleeft tussen sessies en container herstarts, zodat Claude Desktop, Cursor of Copilot elke sessie start met de documenten van het project al doorzoekbaar en ze met één oproep ververst wanneer bestanden veranderen:

Ik heb enkele contracten bewerkt. Vernieuw de contracten‑index, en vertel me vervolgens welke contracten nu een boete vermelden.

De stapsgewijze versie met configuratie en probleemoplossing staat in de documentatie: Hoe een documentindex actueel te houden terwijl bestanden veranderen.

Wat betekent “geheugen” voor een agent?

In de praktijk twee dingen: een toestand die buiten het gesprek blijft bestaan, en een goedkope manier om die toestand actueel te houden. Chatgeschiedenis faalt beide: hij eindigt met de sessie, en niets werkt het bij wanneer een document verandert. Een zoekindex past beter bij documenten. Hij bevindt zich op schijf naast hen, beantwoordt “welke bestanden zeggen X” zonder ze te laden, en kan incrementeel worden ververst.

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

Hoe werkt het verversen?

update_index vergelijkt de index met de bestanden op schijf en leest alleen wat veranderd is opnieuw. Hier is wat de server teruggaf in onze test, nadat één contract een boetebeding had toegevoegd tussen twee oproepen:

-> 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

De tellingen vertellen je wat er gebeurde: één bestand opnieuw gelezen, verder niets aangeraakt. Verwijderde bestanden verdwijnen bij dezelfde oproep.

Waarom één index per project?

Omdat afzonderlijke corpora afzonderlijke antwoorden verdienen. Een vraag over de contracten van dit jaar mag niet de concepten van vorig jaar naar voren brengen, en de documenten van een klant mogen niet vermengen met die van een andere klant. Indexnamen zijn goedkoop:

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

Elke index is een map onder /data/.groupdocs-search-index, en get_index_info zonder een naam geeft ze allemaal weer. Je hebt zelden create_index expliciet nodig, omdat add_to_index een index bij eerste gebruik maakt, maar ze bewust een naam geven is wat “een index” verandert in “het geheugen van dit project”.

De enige regel over verwijdering

De engine verwijdert paden die zijn toegevoegd, niet individuele bestanden erin. De server zegt dat duidelijk wanneer je het probeert:

-> 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: ...

Ontwerp dus hiermee: als je later een deel van een corpus wilt laten vallen, zoals een jaar, een klant of de concepten, indexeer die delen als afzonderlijke paden (contracts/2025, contracts/2026) en elk kan op zichzelf worden verwijderd. Het verwijderen van een bestand op schijf en het uitvoeren van update_index verwijdert het ook.

Het actueel houden zonder te vragen

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)

Drie praktische manieren om verversen automatisch te maken:

  1. In de instructies van de agent. Een regel in CLAUDE.md of AGENTS.md, “roep update_index aan voor de index van dit project voordat je antwoordt als bestanden mogelijk zijn veranderd”, laat de agent dit doen aan het begin van een sessie.
  2. Op een schema. Elke MCP‑capabele automatisering kan update_index ’s nachts aanroepen; wanneer er weinig is veranderd, is de oproep snel.
  3. Na een bulk‑kopie. Eén oproep pakt elk toegevoegd bestand op.

Indexen overleven ook upgrades: indexen gebouwd door GroupDocs.Search 22.7 tot 26.8 worden bij eerste gebruik geconverteerd, met een backup naast hen bewaard.

Wat de agent beslist, en wat de index doet

De agent beslist De index doet
bij welke index een vraag hoort houdt elke benoemde index in zijn eigen map
wanneer bestanden mogelijk zijn veranderd leest alleen gewijzigde, toegevoegde en verwijderde bestanden opnieuw
welke woorden te zoeken, en varianten om te proberen matcht woorden, zinnen, bereiken; rapporteert de gevonden termen
hoeveel context te citeren geeft passages terug met het gevraagde aantal woorden eromheen
wat je te vertellen niets: het geeft tellingen, paden en tekst terug, nooit conclusies

De scheiding is opzettelijk. Het oordeel blijft bij het model, en de feiten waaruit het redeneert komen van een tool waarvan je de output kunt inspecteren.

Eerlijke beperkingen

  • In evaluatiemodus bevat een index maximaal 100 documenten en geeft een zoekopdracht maximaal 10 resultaten. Roep get_license_status aan voordat je op een index vertrouwt als de bron van waarheid.
  • De index blijft alleen bestaan als /data (of het index‑volume) een aangekoppelde host‑map is; anders verdwijnt hij met de container.
  • De index bevat de tekst van de documenten: bescherm en verwijder het zoals de documenten.
  • Alleen Docker; op Linux voeg --user "$(id -u):$(id -g)" toe zodat de container de index kan schrijven.

Veelgestelde vragen

Herinnert de agent mijn documenten tussen sessies?
Met een persistente index, ja: de index blijft op schijf en de volgende sessie doorzoekt deze zonder iets opnieuw te lezen.

Moet ik de index opnieuw opbouwen wanneer bestanden veranderen?
Nee. update_index leest alleen gewijzigde, toegevoegde en verwijderde bestanden opnieuw.

Kan ik de index gescheiden houden van alleen-lezen documenten?
Ja. Koppel de documenten alleen-lezen, koppel een schrijfbare map op /index, en stel GROUPDOCS_MCP_INDEX_PATH=/index in.

Dieper duiken