Sometimes I see things that make me reevaluate assumptions I make. I am all in on flexibility using LLMs and agentic coding harnesses: I hate feeling locked down to one platform.
Then I saw this in the article:
>> 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.
I don't know why this is so appealing to me but it is. I currently use Claude Code with a DeepSeek v4 Pro API backend. I will check out if Claude Code itself has MCPB support.
flossly 1 hours ago [-]
Nice to see Ruby vs Java. Must say that in this context Kotlin deserves a mention: my Kotlin code basically looks+feels like Ruby-with-types. Both Ruby and Kotlin are essentially OO, but with "lots of FP features where it makes sense".
On the side of the jpackage: I'm currently using GraalVM compile to native for a Kotlin CLI tool. I do the build in a build container so I use an older glib to ensure compatibility on a wide variety of Linuxes, AND because this way no-one needs to install all the GraalVM requirements by hand. The result is a 57MB binary, that start in a blink of the eye. The downside is long compile times (2 minutes for a simple CLI tool that uses AWS SDK). I think I prefer this of jpackage; but I'm not building a GUI tool.
martinald 1 hours ago [-]
How is it surprising to people that zip and XML are in stdlibs for a programming language?
Btw, you should have looked at dotnet for this as well. There is a very good library ( DocumentFormat.OpenXml) that can handle all docx/xlsx/pptx files. And dotnet can ship standalone binaries (though AOT probably won't work).
Just scroll down a little bit. They link what MCPB is.
> Later, I've discovered that Claude Desktop supports MCPB.
mike_hearn 2 hours ago [-]
There's Apache POI which is intended for working with Office documents, so directly using XML parsers might not be necessary.
The MCPB format seems to be able to run external processes, even if there's a Node in the middle. So you could also compile the Java version to a native binary with GraalVM and ship that as an MCPB.
dividendflow 39 minutes ago [-]
[dead]
Rendered at 13:53:02 GMT+0000 (Coordinated Universal Time) with Vercel.
Then I saw this in the article:
>> 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.
I don't know why this is so appealing to me but it is. I currently use Claude Code with a DeepSeek v4 Pro API backend. I will check out if Claude Code itself has MCPB support.
On the side of the jpackage: I'm currently using GraalVM compile to native for a Kotlin CLI tool. I do the build in a build container so I use an older glib to ensure compatibility on a wide variety of Linuxes, AND because this way no-one needs to install all the GraalVM requirements by hand. The result is a 57MB binary, that start in a blink of the eye. The downside is long compile times (2 minutes for a simple CLI tool that uses AWS SDK). I think I prefer this of jpackage; but I'm not building a GUI tool.
Btw, you should have looked at dotnet for this as well. There is a very good library ( DocumentFormat.OpenXml) that can handle all docx/xlsx/pptx files. And dotnet can ship standalone binaries (though AOT probably won't work).
It's annoying when acronyms are used without explanation. It's https://github.com/modelcontextprotocol/mcpb , which looks a kind of installation bundle for MCP servers.
> Later, I've discovered that Claude Desktop supports MCPB.
The MCPB format seems to be able to run external processes, even if there's a Node in the middle. So you could also compile the Java version to a native binary with GraalVM and ship that as an MCPB.