Veel zakelijke kennis zit in e‑mail, en het deel dat je nodig hebt bevindt zich meestal in een bijlage: de offerte, de ondertekende wijziging, het herziene schema. GroupDocs.Search.Mcp, die lokaal in Docker draait, opent e‑mailbestanden en archieven (PST, OST, MSG, EML) en indexeert elk bericht en elke bijlage, zodat Claude Desktop, Cursor of Copilot een archief ter plekke kan doorzoeken en precies kan aangeven uit welke bijlage een overeenkomst afkomstig is:
Indexeer de mailmap. Welk bericht vermeldt een prijsverhoging, en wat zegt het precies?
De stapsgewijze versie met configuratie en probleemoplossing staat in de documentatie: Hoe e‑mailarchieven en bijlagen te doorzoeken met een AI‑agent, lokaal.
Waarom is e‑mail moeilijk voor een agent?
Omdat een archief een container van containers is. Een PST bevat mappen, mappen bevatten berichten, berichten bevatten bijlagen, en bijlagen zijn op zichzelf Word‑bestanden, PDF’s en spreadsheets. Een agent met bestands‑tools ziet één groot binair bestand. Het eerst exporteren van het archief naar losse bestanden werkt, maar het is traag, het dupliceert gevoelige gegevens op de schijf, en het moet opnieuw gebeuren wanneer het archief verandert. En een model kan een PST helemaal niet lezen.
De zoekmachine behandelt de nesting zelf. Elk bericht en elke bijlage wordt een doorzoekbaar item, en een resultaat registreert zowel waar de container zich bevindt als waar binnen die container de overeenkomst is gevonden.
Hoe ziet een overeenkomst binnen een bijlage eruit?
Hier is wat de server teruggaf in onze test met drie EML‑berichten. De uitdrukking “price increase” verschijnt alleen in de Word‑offerte die aan één van hen is bijgevoegd; de berichttekst zegt alleen “please find the updated quotation attached”.
-> add_to_index {"documentsPath":"mail","indexName":"mail"}
<- Indexed 'mail' into index 'mail': 3 document(s) added, 3 in the index.
-> search {"query":"\"price increase\"","indexName":"mail"}
<- { "documentsFound": 1, "documents": [
{ "filePath": "mail/2026-09-18-re-q3-pricing.eml",
"innerPath": "quotation-Q-2026-118.docx",
"occurrences": 1 } ] }
-> get_text_fragments {"query":"\"price increase\"","indexName":"mail"}
<- === mail/2026-09-18-re-q3-pricing.eml → quotation-Q-2026-118.docx
(1 occurrence(s)) ===
…Due to raw material costs we announce a price increase
of 6 percent from 2026-11-01.…
filePath is het bericht; innerPath is de bijlage. De agent kan antwoorden “het Re: Q3 pricing‑bericht van Contoso, in de bijgevoegde offerte Q-2026-118: een prijsstijging van 6 procent vanaf 1 november”, en elk deel van die zin is traceerbaar.
mail/2026-09-18-re-q3-pricing.eml <- filePath
|- body: "please find the updated quotation attached"
'- attachment: quotation-Q-2026-118.docx <- innerPath
"...we announce a price increase of 6 percent..."
Vragen die werken op mail
De gebruikelijke query‑taal is van toepassing, en een paar patronen zijn vooral nuttig voor correspondentie. Al deze zijn gecontroleerd tegen dezelfde test‑mailbox:
- “Welk bericht van Fabrikam vermeldt een leveringsvertraging?”:
fabrikam AND delay. Afzenderadressen worden geïndexeerd met het bericht, duscontosovond ook een factuur waarvan de tekst nooit het bedrijf noemt. - “Zoek elke e‑mail die order 77812 vermeldt”:
77812. Gehele getallen worden als woorden behandeld. - “Welke facturen vervallen in oktober?”:
invoice AND content: daterange(2026-10-01 ~~ 2026-10-31). Dat komt overeen met datums die in de berichttekst staan, hier “due on 2026-10-22”. Hetcontent:‑voorvoegsel is belangrijk: zonder dit komt een datumbereik ook overeen met de datums die de engine voor elk bestand registreert.
Waarom lokaal belangrijker is voor mail dan voor iets anders
E‑mail is waar het gevoelige materiaal zich bevindt: persoonsgegevens, onderhandelingen, HR‑threads, juridisch advies. Zoektools die de mailbox moeten uploaden of synchroniseren met een service zijn geen optie voor veel teams. Hier wordt het archief read‑only gemount in een container op de machine, daar geïndexeerd en daar doorzocht. De enige tekst die vertrekt, is wat de agent citeert in zijn antwoord, en met een lokaal gehost model zelfs dat niet.
Voor een strakkere opzet, mount het archief read‑only en geef de index een eigen volume:
docker run --rm -i \
-v /srv/mail:/data:ro \
-v /srv/mail-index:/index -e GROUPDOCS_MCP_INDEX_PATH=/index \
ghcr.io/groupdocs-search/search-net-mcp:latest
Een groot archief afbakenen
Een archief van tienduizenden berichten indexeert prima met een licentie, maar het loont om bewust te werk te gaan. Indexeer per map of per jaar als aparte paden (mail/2025, mail/2026), zodat een jaar apart kan worden verwijderd of opnieuw kan worden opgebouwd, omdat de engine hele geïndexeerde paden verwijdert in plaats van individuele bestanden. Houd mail in een eigen index, gescheiden van contracten of rapporten, zodat een vraag over correspondentie niet door al het andere heen hoeft te waden. En wanneer het archief groeit, pikt update_index nieuwe berichten op zonder de oude opnieuw te lezen.
Eerlijke beperkingen
- In evaluatiemodus bevat een index maximaal 100 documenten en een zoekopdracht geeft maximaal 10 resultaten, en elk bericht en elke bijlage telt, dus een echt archief heeft een licentie nodig. Roep eerst
get_license_statusaan. - Een grote PST kost tijd om te indexeren: elk bericht en elke bijlage wordt geopend. Indexeer één keer, daarna
update_index. - Gescannde bijlagen zonder tekstdlaag worden alleen op basis van hun bestandseigenschappen geïndexeerd; er is geen OCR.
- Alleen Docker; op Linux voeg
--user "$(id -u):$(id -g)"toe tenzij je de bovenstaande read‑only‑configuratie gebruikt.
FAQ
Kan ik een PST‑bestand doorzoeken met AI zonder Outlook?
Ja. De engine leest PST, OST, MSG en EML direct; Outlook is niet betrokken, en er wordt niets geëxporteerd.
Zoekt het binnen e‑mailbijlagen?
Ja. Bijlagen worden geïndexeerd als items van hun bericht, en een overeenkomst binnen een bijlage wordt teruggegeven met innerPath dat de bijlage benoemt.
Wordt mijn mailbox ergens geüpload?
Nee. Het wordt gelezen binnen een lokale container; alleen de passages die de agent citeert, bereiken je modelprovider.
Dieper duiken
- Documentatie, canonieke handleiding: Hoe e‑mailarchieven en bijlagen te doorzoeken met een AI‑agent, lokaal
- Documentatiehub: GroupDocs.Search MCP Server
- Begin hier: Heb je een vector‑database nodig om vragen te stellen over een map met documenten?
- Gerelateerd: Waarom een AI‑agent geen 300 contracten moet lezen om één vraag te beantwoorden
- Gerelateerd: Gefundeerde antwoorden uit je bestanden: citeer de passage, niet het geheugen van het model
- Gerelateerd: grep kan PDF niet lezen: geef je code‑agent een documentindex
- Gerelateerd: Projectgeheugen voor AI‑agents: één index per project, actueel gehouden
- On‑premise en beveiligingsmodel: 3 architecturen voor AI‑documentverwerking, en de architectuur die bestanden binnen je netwerk houdt
- Vragen: GroupDocs Search forum
- Bron: GroupDocs.Search.Mcp on GitHub