Launch HN：Vespper（YC F24）—— 最先进的 Docx MCP

Hey HN!We're Dudu and Topaz from Vespper ( https://vespper.com ).Vespper is an MCP that lets AI agents efficiently edit Word documents, powered by our fine-tuned model.It's currently 3× faster, 2× cheaper and more accurate than the closest alternative.Check out an overview of how the product works here: https://youtu.be/odKxsgPjzzw We came to work on this problem after spending a year building an AI document editor for pharma companies.Before that, Topaz(myself) was a senior SWE at Snyk, working on distributed systems, and Dudu was a deep learning engineer at Viz.ai, building computer vision models for stroke detection.Our editor helped pharma companies generate regulatory documents (e.g.

CSRs) to speed up their submissions.Initially, the output was Markdown, displayed in a WYSIWYG editor.However, users preferred working with their own Word templates.That's when the problems began.AI agents aren't great at editing Word documents.A Word document is a zip file of verbose XML files following the OOXML spec.Even "small" changes require backflips, for example: adding a numbered list requires creating an entry in numbering.xml with a fresh ID and linking it back in document.xml, bolding a sentence requires splitting it into 3+ run elements.The list goes on.

This makes editing the zip directly (unzip + grep + sed) a bad idea for agents because they burn a lot of time + tokens on these mechanics.In practice, today's tooling falls into roughly three categories.You can let the agent write code against low-level libraries like python-docx or the Open XML SDK, you can give it an MCP with opinionated editing tools (SuperDoc, Office CLI, Adeu, etc), or you can round-trip the file through Markdown/HTML with something like pandoc/mammoth.js.None of them really work.

The first two categories still burn the agent's context on Word mechanics instead of the task at hand (MCPs also introduce a new DSL to learn), and the third is very lossy (pandoc/mammoth.js/etc don't preserve enough fidelity).From firsthand experience, these problems hurt performance in downstream tasks.When we tried having our agent fill large documents, things broke quickly.The context window was already packed with customer data (files, user context, global rules, etc.), and the agent burned tokens + time on exploring the document and debugging failed edits.

Filling a single CSR (clinical study report) took ~50 minutes, and the result was bad (missed fields/sections, broken styling, etc.).Harvey.ai's team reached similar conclusions: https://www.harvey.ai/blog/building-an-agent-for-complex-doc...That's when we shifted our focus.We designed an MCP that lets agents edit Word docs as if they were editing HTML.The agent receives HTML, makes find-and-replace edits, and we reconcile those edits back into the original .docx file.We picked HTML over Markdown because it's structurally much closer to OOXML and because CSS associates styles with elements roughly the way OOXML does.W