Vespper lanza un servidor MCP para que los agentes editen .docx sin romper el formato
La startup, de la hornada YC F24, propone que el agente no toque nunca el XML de OOXML: escribe sobre una representación legible y un reconciliador aplica los cambios al .docx.
Vespper, startup de la hornada YC F24, ha publicado un servidor MCP pensado para que los agentes de IA editen archivos .docx. La propuesta es que el agente no toque jamás el XML subyacente: trabaja sobre una representación legible y un motor de reconciliación traduce esos cambios al documento Word real. Es la misma idea que hay detrás de Terraform, pero aplicada a contratos y plantillas de empresa.
El problema no es el texto, es el OOXML
Un .docx es un ZIP con una jerarquía de XML que sigue el estándar OOXML. Dentro conviven document.xml con el texto principal, styles.xml con los estilos reutilizables, numbering.xml con las listas, y luego ficheros aparte para encabezados, pies, notas, relaciones y metadatos. En document.xml un párrafo de cuatro o cinco frases se convierte en miles de tokens cuando entran estilos, formato, división de runs y el andamiaje del propio XML. El texto que el usuario ve en Word puede estar repartido por decenas de nodos.
Según Vespper, hoy hay tres formas de que un agente edite un Word. La primera es que escriba código contra SDKs de bajo nivel como python-docx, aspose u Open XML SDK: son intuitivos porque están en los datos de preentrenamiento, pero lentos y caros, y hasta poner un hipervínculo o un control de cambios obliga al agente a hacer cabriolas. La segunda es conectar un MCP como SuperDoc, Office CLI, safe-docx o Adeu: más rápidos y baratos, pero cada uno es un DSL nuevo que el modelo aprende sobre la marcha, y todos cubren el 80% común. La tercera es el ida y vuelta: convertir a Markdown o HTML, editar y volver a .docx.
Vespper apuesta por esta última, y ahí está el detalle. Las conversiones con pandoc o mammoth.js pierden información en un sentido y no se pueden deshacer en el otro; Markdown, en concreto, no sabe expresar las relaciones de estilo que un documento hereda de su plantilla. De ahí el reconciliador, que según la empresa permite ese ida y vuelta sin pérdida.
La compañía cita el caso de Harvey, que reconstruyó su sistema de edición de documentos al concluir que estaba pidiendo a un solo agente que fuera a la vez asistente legal y máquina de estados de Word. Leer las redlines de la contraparte, aplicar el playbook del despacho, comprobar que un término definido significa lo mismo en la cláusula 3 que en la 27 o detectar que el tope de indemnización contradice dos páginas más arriba ya consume la ventana de contexto; gestionar runs y referencias de numeración no debería competir con eso. La empresa asegura que habló con decenas de ingenieros, sobre todo en legal tech y salud, que dedican semanas o meses a afinar sus propios sistemas y acaban manteniendo soluciones internas complejas.
Qué queda por ver
El anuncio va sin cifras de rendimiento, sin comparativa medida contra las alternativas que critica y sin demo pública del reconciliador. Que la conversión sea de verdad sin pérdida en documentos complejos —plantillas con estilos anidados, control de cambios, numeración multinivel— es justo la parte que falta por demostrar, y es también donde se decide si esto ahorra contexto al agente o solo mueve el problema de sitio. El punto de arranque está en la documentación de Vespper.
