Cada nuevo chat comienza con un agente que ha olvidado tus documentos. Puede volver a leerlos, a costa de tiempo y contexto, o puede consultar algo que recuerda. GroupDocs.Search.Mcp mantiene un índice de texto completo con nombre en disco, localmente, que sobrevive entre sesiones y reinicios de contenedores, de modo que Claude Desktop, Cursor o Copilot inician cada sesión con los documentos del proyecto ya buscables y los actualizan con una sola llamada cuando los archivos cambian:

He editado algunos contratos. Actualiza el índice de contratos, luego dime qué contratos mencionan una penalidad ahora.

La versión paso a paso con configuración y solución de problemas está en la documentación: Cómo mantener actualizado un índice de documentos a medida que los archivos cambian.

Qué significa “memoria” para un agente?

En la práctica, dos cosas: un estado que persiste fuera de la conversación, y una forma económica de mantener ese estado verdadero. El historial de chat falla en ambos aspectos: termina con la sesión, y nada lo actualiza cuando un documento cambia. Un índice de búsqueda se adapta mejor a los documentos. Vive en el disco junto a ellos, responde “qué archivos dicen X” sin cargarlos, y puede actualizarse de forma incremental.

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

¿Cómo funciona la actualización?

update_index compara el índice con los archivos en disco y vuelve a leer solo lo que cambió. Aquí está lo que el servidor devolvió en nuestra prueba, después de que a un contrato se le añadió una cláusula de penalidad entre dos llamadas:

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

Los recuentos te indican lo que ocurrió: un archivo vuelto a leer, nada más tocado. Los archivos eliminados desaparecen en la misma llamada.

¿Por qué un índice por proyecto?

Porque corpora separados merecen respuestas separadas. Una pregunta sobre los contratos de este año no debería mostrar borradores del año pasado, y los documentos de un cliente no deberían mezclarse con los de otro cliente. Los nombres de índices son económicos:

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

Cada índice es una carpeta bajo /data/.groupdocs-search-index, y get_index_info sin un nombre los lista todos. Rara vez necesitas create_index explícitamente, porque add_to_index crea un índice en el primer uso, pero nombrarlos deliberadamente es lo que convierte “un índice” en “la memoria de este proyecto”.

La única regla sobre la eliminación

El motor elimina rutas que fueron añadidas, no archivos individuales dentro de ellas. El servidor lo dice claramente cuando lo intentas:

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

Así que diseña para ello: si esperas eliminar parte de un corpus más adelante, como un año, un cliente o los borradores, indexa esas partes como rutas separadas (contracts/2025, contracts/2026) y cada una puede eliminarse por sí sola. Eliminar un archivo en disco y ejecutar update_index también lo elimina.

Manteniéndolo actualizado sin preguntar

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)

Tres formas prácticas de automatizar la actualización:

  1. En las instrucciones del agente. Una línea en CLAUDE.md o AGENTS.md, “llama a update_index para el índice de este proyecto antes de responder si los archivos pueden haber cambiado”, hace que el agente lo haga al inicio de una sesión.
  2. Según un horario. Cualquier automatización compatible con MCP puede llamar a update_index cada noche; cuando hay pocos cambios, la llamada es rápida.
  3. Después de una copia masiva. Una llamada recoge cada archivo añadido.

Los índices también sobreviven a actualizaciones: los índices construidos por GroupDocs.Search 22.7 a 26.8 se convierten en el primer uso, con una copia de seguridad guardada junto a ellos.

Qué decide el agente y qué hace el índice

Decide el agente Hace el índice
a qué índice pertenece una pregunta mantiene cada índice con nombre en su propia carpeta
cuándo pueden haber cambiado los archivos vuelve a leer solo los archivos cambiados, añadidos y eliminados
qué palabras buscar y qué variantes probar coincide con palabras, frases, rangos; informa de los términos que encontró
cuánta contexto citar devuelve pasajes con el número solicitado de palabras alrededor
qué decirte nada: devuelve recuentos, rutas y texto, nunca conclusiones

La división es deliberada. El juicio permanece con el modelo, y los hechos de los que razona provienen de una herramienta cuyo output puedes inspeccionar.

Límites honestos

  • En modo de evaluación, un índice contiene como máximo 100 documentos y una búsqueda devuelve como máximo 10. Llama a get_license_status antes de confiar en un índice como fuente de verdad.
  • El índice persiste solo si /data (o el volumen del índice) es una carpeta de host montada; de lo contrario desaparece con el contenedor.
  • El índice contiene el texto de los documentos: protégelo y deséchalo como a los documentos.
  • Solo Docker; en Linux agrega --user "$(id -u):$(id -g)" para que el contenedor pueda escribir el índice.

Preguntas frecuentes

¿El agente recuerda mis documentos entre sesiones?
Con un índice persistente, sí: el índice permanece en disco y la siguiente sesión lo busca sin volver a leer nada.

¿Necesito reconstruir el índice cuando los archivos cambian?
No. update_index vuelve a leer solo los archivos cambiados, añadidos y eliminados.

¿Puedo mantener el índice separado de los documentos de solo lectura?
Sí. Monta los documentos como solo lectura, monta una carpeta escribible en /index, y establece GROUPDOCS_MCP_INDEX_PATH=/index.

Profundiza