Agree a good one this is needed but there are 4-5 semi functional Word MCP servers including one from the vendor. This one still isn't feature complete. This is going to sound rude, and I don't mean it that way, but how did you get accepted to YC for this? Was this some kind of pivot off your accepted idea and business plan?
Legit question :) so we've worked on a few ideas since we've been accepted to YC, one of them was the document editor for pharma.
After working on that for a while, we've decided to shift focus and work on the DOCX angle. We felt there's a big opportunity here since .docx is such a widely used format.
As to the feature complete point - I agree. We already cover the most common features today (paragraphs, lists, tables, tracked changes, header/footer) and we're working hard on implementing more. Our main focus right now is to be the most accurate, cheapest and fastest solution out there for common scenarios.
Have been doing https://rcarmo.github.io/projects/python-office-mcp-server/ for a year or so now, and have Go and TS libraries that use the same test fixtures. This is a non-trivial thing in terms of test coverage, but I’ll get there… don’t see a paying market for it though.
I actually think there's a very big market for it tbh. A lot of teams building agents are struggling with this today, especially in legal, finance, pharma and government. It's also a much deeper problem than most people realize, even for tool builders, and it really requires working backwards from the experience an agent should have.
Vespper is our take on what that should look like.
Either way, it's exciting to see more people building in this space. Agents definitely need better ways to work with Office docs.
The people who need this most are not going to want to use an external MCP server. This is a pretty unusual model for a narrowly scoped product offering like this. I was excited until I realized it’s not something I can run locally.
Fair point. For editing local files I'd want local too. Disclosure: I work on Elva, where hosting is deliberate because the use case is a team's own APIs. Agents call the same endpoints teammates test, with access governed in one place rather than on each laptop. It's a tradeoff, not a fit for everything. https://getelva.ai/
I think it's a valid point. A few reasons we went this way.
- The teams we're building for don't want to touch DOCX at all. They just want to plug in their agents and move on, so we went for a smooth hosted experience instead of an open-source lib they'd have to set up and tune themselves.
- We run a fine-tuned model under the hood, and it needs a GPU, so running it locally isn't really practical for most folks.
I agree privacy matters a lot. Because of that, we offer zero-data retention for teams, and there's also a self-hosted option if you want everything running in your own cloud.
I've built tools using the agent in https://github.com/eigenpal/docx-editor. I can use my existing AI and don't need to connect to an external service, plus it is open source. Why would I use your solution instead?
Where I think it can break (and we show some of that in the benchmark post, though not on EigenPal specifically) is on tricky document edits, like multi-turn track changes, implicit style understanding (respecting surrounding styles without being told to), advanced list manipulation, etc. We also saw these problems get amplified on long-horizon, challenging document workloads.
Eventually we realized no product out there truly handles the wide variety of cases agents run into, so we set out to build one.
So to answer your question, it depends. If your documents are simple and you're happy with the results, stick with what works. But if you have tricky documents and find yourself chasing the N-th edge case, I think delegating that to something like our product makes sense.
Preloading the DOCX skill hides a cost real runs pay. In the harness I use a skill is listed as a name plus one line, and the body only loads when invoked, so the 10-call skill baseline probably undercounts by a step.
Yep, a real run with DOCX skill would pay an extra tool call (e.g load_skill). We pre-loaded its context because we wanted to neutralize setup differences between tools and just focus on editing.
we need to fill templates that customers give us, we’ve already built an agent harness with python-docx. It’s not perfect but it ~works. Does Vespper completely replace that or can our harness be used alongside your MCP?
Good question. Vespper is meant to replace the python-docx work for your agent and simplify things. That said, it can definitely run alongside your agent (either as additional tools to your agent or as a subagent that uses our tools).
For example, you could keep python-docx for the easy stuff and fall back to a Vespper-based approach when your agent hits errors filling the document. However, the end goal is to completely free your agent from python-docx and low-level work, so it can just focus on what goes into the template.
Agree a good one this is needed but there are 4-5 semi functional Word MCP servers including one from the vendor. This one still isn't feature complete. This is going to sound rude, and I don't mean it that way, but how did you get accepted to YC for this? Was this some kind of pivot off your accepted idea and business plan?
Legit question :) so we've worked on a few ideas since we've been accepted to YC, one of them was the document editor for pharma.
After working on that for a while, we've decided to shift focus and work on the DOCX angle. We felt there's a big opportunity here since .docx is such a widely used format.
As to the feature complete point - I agree. We already cover the most common features today (paragraphs, lists, tables, tracked changes, header/footer) and we're working hard on implementing more. Our main focus right now is to be the most accurate, cheapest and fastest solution out there for common scenarios.
Have been doing https://rcarmo.github.io/projects/python-office-mcp-server/ for a year or so now, and have Go and TS libraries that use the same test fixtures. This is a non-trivial thing in terms of test coverage, but I’ll get there… don’t see a paying market for it though.
Thanks for sharing, I'll check it out!
I actually think there's a very big market for it tbh. A lot of teams building agents are struggling with this today, especially in legal, finance, pharma and government. It's also a much deeper problem than most people realize, even for tool builders, and it really requires working backwards from the experience an agent should have.
Vespper is our take on what that should look like.
Either way, it's exciting to see more people building in this space. Agents definitely need better ways to work with Office docs.
Agreed, id sooner burn tokens to make my own than pay for something else to have access to my docs
We're built for enterprise customers, not personal use.
Obviously, I'm not storing my personal docs in office lol
The people who need this most are not going to want to use an external MCP server. This is a pretty unusual model for a narrowly scoped product offering like this. I was excited until I realized it’s not something I can run locally.
Fair point. For editing local files I'd want local too. Disclosure: I work on Elva, where hosting is deliberate because the use case is a team's own APIs. Agents call the same endpoints teammates test, with access governed in one place rather than on each laptop. It's a tradeoff, not a fit for everything. https://getelva.ai/
I dont think someones launch post is an appropriate place to advertise your own services
I think it's a valid point. A few reasons we went this way. - The teams we're building for don't want to touch DOCX at all. They just want to plug in their agents and move on, so we went for a smooth hosted experience instead of an open-source lib they'd have to set up and tune themselves. - We run a fine-tuned model under the hood, and it needs a GPU, so running it locally isn't really practical for most folks.
I agree privacy matters a lot. Because of that, we offer zero-data retention for teams, and there's also a self-hosted option if you want everything running in your own cloud.
I've built tools using the agent in https://github.com/eigenpal/docx-editor. I can use my existing AI and don't need to connect to an external service, plus it is open source. Why would I use your solution instead?
EigenPal is great! I actually love their product.
Where I think it can break (and we show some of that in the benchmark post, though not on EigenPal specifically) is on tricky document edits, like multi-turn track changes, implicit style understanding (respecting surrounding styles without being told to), advanced list manipulation, etc. We also saw these problems get amplified on long-horizon, challenging document workloads.
Eventually we realized no product out there truly handles the wide variety of cases agents run into, so we set out to build one.
So to answer your question, it depends. If your documents are simple and you're happy with the results, stick with what works. But if you have tricky documents and find yourself chasing the N-th edge case, I think delegating that to something like our product makes sense.
Btw we open sourced a Word add-in project that shows how to build a Word add-in with Vespper MCP: https://github.com/vespperhq/examples/tree/main/word-add-in
Preloading the DOCX skill hides a cost real runs pay. In the harness I use a skill is listed as a name plus one line, and the body only loads when invoked, so the 10-call skill baseline probably undercounts by a step.
Yep, a real run with DOCX skill would pay an extra tool call (e.g load_skill). We pre-loaded its context because we wanted to neutralize setup differences between tools and just focus on editing.
we need to fill templates that customers give us, we’ve already built an agent harness with python-docx. It’s not perfect but it ~works. Does Vespper completely replace that or can our harness be used alongside your MCP?
Good question. Vespper is meant to replace the python-docx work for your agent and simplify things. That said, it can definitely run alongside your agent (either as additional tools to your agent or as a subagent that uses our tools).
For example, you could keep python-docx for the easy stuff and fall back to a Vespper-based approach when your agent hits errors filling the document. However, the end goal is to completely free your agent from python-docx and low-level work, so it can just focus on what goes into the template.
sign up for free to try: https://app.vespper.com/