Not long ago we joked that a new codename‑mapping framework appeared every week; now the fatigue is so deep we half‑expect the next JVM‑based AI tool to spring out of the fridge. The pace is insane: every single morning Slack and X trumpet a brand-new SDK, plug‑in, or MCP server that didn’t even have an alpha tag the day before. Things got so out of hand that in recent weeks I just stopped covering it in my JVM Weekly - I realized starving the topic wasn’t really a solution.
Still, because every model keeps bending the conversation back to it, now feels like the perfect time for a quick roundup. I’ve pulled together the most significant releases from the past few months: first, the Model Context Protocol servers - often totally unexpected, sometimes downright bizarre. Next comes a look at agent frameworks outside the Spring ecosystem; third, Spring AI itself - because, let’s be honest, 80 % of you fire up Spring Boot in CI the moment the workday starts. And finally Kotlin, where so much is happening that it’s hard to keep up even with the conference keynotes.
I hope this little Hitchhiker’s Guide to the JVM‑agent universe helps you catch your breath and pick your own path through the jungle of shiny new toys.
Buckle up - here we go!
Stay tuned!
This is the first part in a four-part series. We will update this section, so you can jump between the parts as needed.
If the acronym MCP doesn’t set off sparks for anyone on your team, this article probably isn’t for you—because today we’re going deep, to the part of the ocean where READMEs open with a JSON manifest and finish with an SSE client.
MCP is turning into the Esperanto of agents (told you it would get nerdy 🤷): some folks invoke it from Rust, others from TypeScript, and we—true to form—are checking what’s new in the JVM neighborhood. In the last few weeks, repositories have multiplied faster than dependencies in the pom.xml of an over‑eager junior (whether the carbon‑based kind or a TUI‑powered bot), so let’s tour the most interesting ones.
Need a primer instead - What the heck is MCP and why is everyone talking about it?? There’s a piece that explains why MCP lit up the radar of every major vendor and helps untangle the buzz… while reminding us that, contrary to what some self‑styled “AI Experts” believe, the whole thing is being built on the shoulders of giants.
Let’s start with a rather unexpected pairing - MCP and application servers. But trust me, it makes perfect sense.
WildFly MCP begins where the traditional admin‑CLI of an application server ends. The JBoss authors asked: since WildFly already exposes every operation through its management model, why not let an LLM agent that understands natural language access them? That idea became a standalone Quarkus fat‑jar that publishes the WildFly “world” (threads, metrics, logs, CLI operations) as Model Context Protocol tools.
A chatbot opens the manifest, sees functions such as getWildFlyHealth or reloadServer, and can decide on its own when to invoke them to answer a human question like “Why is my application stuck in STARTING?”. The result is true ChatOps: instead of SSH plus greps, you type in Claude “show the most thread‑expensive transaction,” it analyzes the output, and gives you a diagnosis.
Under the hood, you get more than just a bridge to an LLM. The project ships ready‑made OpenShift containers, a gateway that converts streaming SSE to STDIO (handy when your chatbot only understands “functions v1”), and a tiny “Wait MCP Server” that lets an agent pause a workflow for a set time. The newest feature packs add experimental CDI annotations—one @McpTool lets you expose any Jakarta EE class as an MCP tool. In practice, any service in your EAR/WAR can become a “function” for the model, and WildFly MCP serves the manifest on the fly. The upshot? Dev and Ops converge in a single conversation, and the LLM becomes a first‑class operator of your cluster—with role‑based access control, event history, and dependencies managed via Maven Central.
Bruno Borges took the classic Java post‑mortem scalpels - jcmd, jstat, jps - and packed them into a single, self‑contained MCP server. The result hands those tools to a large‑language model the way a scrub nurse passes sterile instruments to a surgeon: an agent can fetch GC statistics, generate a thread dump, or even target a JVM process for termination, all from a simple chat command. The MCP manifest lists the commands as “tools” (monitorJstat, dumpThreads, runJcmd), so the LLM never has to remember the flag syntax—just what the user needs. Because it speaks plain STDIO, the server runs locally with no JMX tunnels or complicated SSH; setup is as easy as java -jar … or a single Docker command, and the repo already includes a ready‑made Claude Desktop configuration.
The project lands squarely on the pain point of on‑call nights: when an app starts gasping, humans typically rummage through diagnostic docs or try to recall ‑XX:+UnlockDiagnosticVMOptions. Here you simply ask the bot, “Why is my service using so much heap?” - the agent fires off jstat -gc, parses the output, and offers a hypothesis. The README does remind you it’s use‑at‑your‑own‑risk - an LLM with shell access cuts both ways - so the author suggests keeping the server on your own machine until MCP gains native HTTP with tokens. Even so, the tool is already shifting how we do diagnostics: it turns a linear terminal session into a conversation with a virtual SRE who knows every command, never gets tired, and never forgets a comma in a flag name.
Ghidra is an open‑source reverse‑engineering suite developed by the U.S. National Security Agency that provides advanced disassembly, decompilation, and debugging across dozens of architectures - all in Java. And now, with GhidraMCP, reverse engineering turns into a dialogue instead of a tedious series of Python scripts.
GhidraMCP is a plugin that brings Ghidra’s powerful reverse‑engineering engine into the world of LLM agents by spinning up a lightweight Model Context Protocol server on top of it. Once installed, the plugin publishes a manifest with commands like decompileFunction, listImports, renameSymbol, and generatePatch, so a chatbot can remotely break a binary apart, name anonymous functions, and diff code versions. All communication is streamed over STDIO or WebSocket, so the agent never has to know the Ghidra API—it just calls the tools listed in the manifest.
The real magic begins when you pair GhidraMCP with a local LLM via Ollama (assuming hefty enough workstation)I: you get a private malware analyst that can decompile firmware and hunt suspicious strings in minutes without sending a byte outside your machine.
It’s worth noting that alongside the already‑described GhidraMCP there is a second server - GhidrAssistMCP - whose authors chose a slightly different approach. Instead of relying on a Python‑plus‑HTTP bridge, this Java‑based plugin embeds the MCP SDK directly inside Ghidra and is installed as a single ZIP dropped into the Extensions folder.
At startup it exposes no fewer than 31 built‑in tools (functions, data, cross‑refs, and so on) and adds a lightweight GUI panel where you can toggle individual commands, watch logs in real time, and inspect exactly what is being sent to the LLM engine. Meanwhile, mentioned GhidraMCP, by contrast, sticks to a core set of operations (decompilation, auto‑rename, import/export lists) and serves them through a simple HTTP server with no extra UI‑level configuration.
The upshot: GhidrAssistMCP is better suited for workshops and team collaboration, where quick clicking and call‑history auditing matter, while GhidraMCP remains a slimmer, “fire‑and‑forget” option that integrates easily with scripts or CI pipelines without any GUI add‑ons.
An experimental MCP server, written in parallel in Scala 3 and Scala.js, takes all of modern Scala’s “candy” - dependent types, effectful I/O with ZIO or Cats Effect, FS2 streams - and proves that even a seemingly “imperative” protocol like MCP can sound functional. Tool manifests are expressed directly in types: Decompile[A] returns IO[Either[McpError, A]], and the compiler guarantees the model will never receive an empty result or call a non‑existent function.
Thanks to cross‑compilation with Scala.js, the very same code can run on Edge Functions or Cloudflare Workers, turning the manifest into a Script Module for a front‑end LLM that operates entirely in the browser without a cent spent on cloud resources.
Its second strength is reactive I/O: every tool invocation is pushed onto a stream, letting the agent “listen in” on progress by emitting dialogue token chunks - so when a model requests a long‑running task, such as Git repository indexing, it sees “10 %… 30 %…” updates instead of a silent console.
Still in alpha, the project already shows that the functional world can squeeze extra elegance out of MCP: zero‑cost asynchrony, uninterruptible streams, and a compiler that makes sure the agent can’t do anything silly.
The Scala MCP project proves that the functional Scala stack can host the protocol itself and run tools in a reactive, type‑safe style. Metals MCP, on the other hand, grafts MCP onto a collaborative Language Server Protocol instance. For years Metals has run a background Scala 3 compiler, publishing ASTs, semantic analyses, and hot‑reload builds so VS Code or IntelliJ can suggest types. We at VirtusLab (as we are creators of the tool 😁) took the next step: we exposed those same internal commands as MCP tools.
With Metals MCP you write almost nothing: open a project in VS Code and Metals automatically spins up an embedded server on the same port the LSP already uses. The manifest is generated on the fly and mirrors exactly the operations the LSP knows: “show compile errors,” “give me the type of this expression,” “generate a dependency diagram.” An LLM agent instantly gets access to the compiler and the project’s full semantic tree, while you just hit save.
That makes Metals MCP a strictly developer‑oriented tool - not an infrastructure server like Scala MCP, but a bridge that turns a model into a live pair‑programmer with no extra installation.
As you see - configuring an MCP server can be a real headache - choosing ports, deciding on the manifest format, picking a startup method, and then wrestling with token pasting and binary paths. The MCP Java generator turns that whole ritual into a minutes‑long “click‑through.”
On a single page you pick the server you’re interested in (anything from WildFly to Ghidra), the target client (Claude Desktop, VS Code, LangChain4j), and how you want to run it. Behind the scenes, an algorithm selects conflict‑free ports, suggests an OAuth2 or API‑Key scheme, and produces a ready‑to‑copy JBang command or NPM/UVX script. That means even someone who’s never compiled Java can spin up a local MCP endpoint in the time it takes to make coffee.
The tool’s real strength is its integration with the JBang catalog: every generated manifest launches with a single jbang mcp@java line, wiping out the multi‑page “install JDK, clone the repo, gradle build” instructions. For enterprises that translates to lightning‑fast POCs; for conference workshops, a room full of participants with a working server for agent experiments in five minutes. The project also serves as an incubator: new servers are added via pull requests to the catalog, so the ecosystem updates itself. The upshot? MCP stops being an exclusive club for DevOps ninjas and becomes the first tool in the box for anyone who wants to hear what their application sounds like in natural language.
And finally—stepping a bit outside the JVM and into Android - joining two big hypes of the yesteryear: MCP and Webassembly!
When the mcp.run team set out to bring its servlets to mobile, the breakthrough was Chicory, a pure‑Java WebAssembly runtime. Chicory lets MCP tools compiled to .wasm run directly on Android, inside the very process VM that hosts your app. A demo shows an APK that locally fetches a Google Maps module from the mcp.run registry, pairs it with Gemini, and plots a route to the nearest café - all offline, with not a single packet leaving the phone. In practice it’s click “fetch tool,” Chicory loads the Wasm into a sandbox, the agent speaks MCP over STDIO, and the answer returns to the chat—zero SSH tunnels, zero native dependencies, all handled by a Wasm VM embedded in the JVM.
The project’s second pillar is mcpx4j, a library that brings the same mechanism to any JVM app - Spring Boot, Quarkus, LangChain4j - just add the dependency and point to a tool profile on mcp.run. The authors emphasize that this is a key step toward truly private agents: as LLMs increasingly run on‑device (Gemini Nano, Llama‑on‑device), their tools must leave the cloud as well. Porting MCP to a Wasm engine in the user’s pocket isn’t a gimmick; it’s the foundation for the coming wave of edge agents that can query a local SQLite DB, read health sensors, or pull transaction history - and never let that data leave the device.
That’s all for today, but stay tuned for Part 2, where we’ll focus on the Spring ecosystem (with MCP), Part 3 on tools that help you write your own MCP in Java, and Part 4 showcasing MCP (and other LLM) highlights in the Kotlin ecosystem.
