We've built a Claude Cowork DOCX plugin in Ruby, Java, and TypeScript. Java is the winner for supporting zip files and XML in its runtime with no issues. However, TypeScript is chosen due to the possibility of MCPB support.
- We've built a Claude Cowork DOCX plugin in Ruby, Java, and TypeScript.
- Java is the winner for supporting zip files and XML in its runtime with no issues. However, TypeScript is chosen due to the possibility of future MCPB support without embedding the Node runtime.
- Codex's plugin mechanism is lagging behind Claude's. It doesn't support an equivalent of
CLAUDE_PLUGIN_ROOT
and seems impossible to execute a binary inside the plugin. - Bun has been chosen for building a single-executable binary. One gap is that I cannot figure out how to make its source maps work with PostHog.
Recently, we've implemented the same Cowork DOCX plugin 3 times. The first prototype was in Ruby. We reimplemented it in Java in order to make it a desktop app. Then, We reimplemented it in Typescripts (Node) in order to make it compatible with MCPB. Eventually, We've switched to Bun because Cowork plugin apparently doesn't support MCPB.
Since now I have direct experience in implementing the same app in 3 different languages within a span of a month, I've decided to write about it.
For context, a DOCX file is actually a zip file with a bunch of XMLs and other files in it. Therefore, our code must process zip files and XMLs.
[https://github.com/LegalRabbit-AI/legalrabbit-docx-claude-plugin](https://github.com/LegalRabbit-AI/legalrabbit-docx-claude-plugin?ref=tanin.nanakorn.com)
It works well with legal documents, and you can use it together with the
Claude for Legalplugin. The plugin is still in its nascent stage. I'd love for you to drop us an email at tanin@legalrabbit.ai, so we can help you and notify you when there's an update.
Ruby #
At first, I built a prototype in Ruby because my colleague knew Ruby well, and we wanted it to a server-side application. I wrote a lot of Ruby back in 2010s. I felt Ruby was a beautiful language. Unfortunately, I don't feel that anymore.
The biggest issue is no typing.
I worked at Stripe for 4.5 years, so I looked into integrating Sorbet; it was a bit too involved, so I didn't do it. I also looked at RBS but couldn't understand how to integrate it. Admittedly, I didn't spend too much time on this.
Here were some common errors that I encountered:
- Forgot
.each
innode.children.each do |x|
. The error showed up as "unexpected nil" at a random place. - Forgot
.children
innode.children[i]
. The error showed up as "unexpected nil" at a random place. - Using
assert_raises
in the test obscured a compilation error. Theassert_raises
would just complain the error doesn't match the expected error. I had to comment outassert_raises
to see the error stacktrace. - I used
ruby_llm-mcpwhere the doc mentionedtool.input_schema
but the latest version has renamed it totool.params_schema
(issue). It took me a while to figure out since there was no typing hint to help me with it. In terms of processing a zip file and XMLs, I used:
rubyzip: it hasan obscure bugwhere it produced a corrupted DOCX file. I've encountered this bug with a DOCX file from our customers. I can't share the confidential file to the rubyzip author. I tried to reproduce the file but failed to do so. Therefore, the bug cannot be solved.nokogiri: it also hasa non-blocking bugwhere it doesn't format XML correctly. The bug is actually from the native librarylibxml2
. Therefore, it's not exactly a bug for nokogiri to solve.
Java #
After some time, we've decided that we want a Claude Cowork plugin instead. A Claude plugin supports executing a binary locally, so I've chosen Java for it.
I have my fair share of building a Java desktop application and know jpackage
and alike very well (See: my Java electron framework). What surprised me was that Java supported processing zip files and XML from their standard runtime. I didn't encounter any issue with the zip and XML library at all. It works as expected.
The final single-executable binary is about 88MB. It is 88MB because a JDK is embedded inside.
I used AI to port the code. It took only 3 days to port thousands of lines of code.
TypeScript #
Later, I've discovered that Claude Desktop supports MCPB. The MCPB provides a Node runtime. Therefore, our application would only contain our code. This means the size of the application would be ~1MB.
With TypeScript, I have to use the following libraries for processing zip files and XML:
fflatefor processing zip files. It works as expected.xmldomfor processing XML. Because I need DOM API. It works as expected except that it doesn't support pretty-print XML. Its rationale is that pretty-print is out of scope because XML is used for transporting/serialization. Plus, there's no standard for pretty-printing XML. Seethis issue.
I used AI to port the code from Java to TypeScript. It only took 1.5 days to do.
MCPB is great. However, to operate our DOCX MCP, we need an accompanying skill. Claude Desktop supports this through Claude plugin where both skills and MCPs can be packaged together. However, Claude plugin doesn't support MCPB :S
Claude plugin only supports a single-executable binary. Node doesn't have this feature. Fortunately, Bun has, and it works as expected.
The only gap with Bun is that I cannot figure out how to upload the source map to PostHog because PostHog requires both the minimized JS file and the .js.map file.... but Bun only produces the binary and the .js.map file.
The final file size is ~70MB on Mac and ~120MB on Windows.
In the end, I've decided to stick with TypeScript because of the possibility of MCPB being supported in Claude/Codex plugin.
Thoughts on Codex
I was looking at making a Codex plugin but Codex is behind Claude Desktop in terms of the plugin mechanism.
Claude supports the environment variable: CLAUDE_PLUGIN_ROOT
, and that enables me to execute the single-executable binary as the stdio MCP server.
Codex doesn't have it. Their plugin structure has a folder for binaries but their doc doesn't mention how to execute the binary in that folder. I tried a couple possible paths but couldn't make it work.
Conclusion
Java is the winner for me. However, as I mentioned earlier, I've decided to stick with TypeScript due to the possibility of future MCPB support without embedding the Node runtime.
Ignoring the possibility of the embedded Node runtime, Java's strict typing makes it easier to code. The Java's built-in libraries for zip and XMLs work as expected.
The maturity of the Java runtimes on both Windows and Mac gives me more confident compared to Bun, which is quite new. To be fair, so far I haven't encountered any issue with Bun apart from being unable to upload source maps to PostHog. Our Bun-built Claude plugin seems to work well on both Mac and Windows.