Launch HN: Vespper (YC F24) – SOTA Docx MCP (vespper.com)

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 that helped generate regulatory documents. 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 CV models for stroke detection.

AI agents aren't great at editing Word documents. A Word doc is a zip file of XML files following the OOXML spec. Even small changes require backflips, for example: adding a 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, etc.

This makes editing the zip directly (unzip + grep + sed) a bad idea for agents because they burn time + tokens on these mechanics. In practice, today's tooling falls into three categories. You can let the agent write code against libraries like python-docx, you can connect it to an MCP (SuperDoc, Office CLI, Adeu, etc), or you can round-trip the file through Markdown/HTML with e.g. pandoc/mammoth.js. None of them is optimal though. The first two burn the agent's context on Word mechanics instead of the task, and the third is lossy (pandoc/mammoth.js/etc don't preserve enough fidelity).

These problems hurt performance in downstream tasks. When we tried having our agent fill large docs, things broke. The context window was already packed with customers’ data, and the agent burned tokens on exploring the document and debugging edits. Filling a single clinical study report took ~50 minutes, and the result was low quality. 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 .docx file. We picked HTML + CSS because it's structurally much closer to OOXML. We had to write our own DOCX→HTML converter, since pandoc/mammoth.js didn't preserve enough fidelity.

To be clear, our DOCX → HTML conversion is lossy too. That's fine though, because we never convert the HTML back to DOCX. The HTML is just a projection for the agent, so it only needs enough fidelity for the agent to understand the structure and styling of what it's editing. The original file stays the source of truth.

This also means the agent doesn't need to learn a new DSL. Editing a Word document feels just like editing a regular HTML file. A lot of DOCX MCPs hand agents dozens or even hundreds of tools. Our MCP exposes just three tools (read, search, edit). The Word document is completely abstracted.

After an agent sends an edit request, we reconcile it to the original .docx file. The reconciliation is done by our fine-tuned model. It takes the HTML diff as input along with the a localized OOXML block and emits the new block. We published a technical blog post that dives deeper.

Our internal benchmark shows it's more accurate than the DOCX skill and raw python-docx while being ~2x cheaper and ~3x faster. It takes 3 tool calls (p50) per task whereas e.g DOCX skill takes 10 and Office CLI takes 13. Things aren't perfect yet. We don't support manipulating images or comments at the moment. That said, we're already seeing people use our MCP in various ways: - Legal tech companies powering their live-editing flow in Office.js. - Govtech who need to draft policy memos. - A life sciences startup using long-running agents to complete regulatory forms.

We'd love to hear ...