Tachyon Turns Java Methods Into an MCP Server on Netty

Another server-side option for Java

MCP has settled into the role of a shared contract between model clients and the systems they need to reach. The protocol describes how a server advertises tools, resources and prompts; it says little about which language you implement it in. Python and TypeScript arrived first. Java has been catching up through a mix of SDK work and framework integrations, which leaves teams with a recurring choice: assemble the pieces yourself or wait for someone to package them.

That gap was noticeable. Most early MCP servers were small Python or Node processes bolted onto an existing API. That works for prototypes and fits less comfortably inside a bank or a logistics platform where the business logic already lives in JVM services, behind authentication, audit logging and internal RPC. Reaching those services means either bridging out to another runtime or doing the protocol work in Java.

Tachyon takes the packaging route. The pitch is narrow: expose Java methods as an MCP server over Streamable HTTP. The network layer is Netty, a familiar name in Java shops, where a long list of middleware and RPC frameworks already sit on top of it. Connection handling, concurrency and backpressure are known quantities. For teams that expect to run an MCP endpoint in production, that means existing operational and tuning experience carries over instead of being relearned.

Spec coverage and two authoring styles

The project says it supports the current MCP specification along with the previous one. That matters more than it sounds. MCP swapped its remote transport from HTTP+SSE to Streamable HTTP in 2025, and old and new clients will coexist for a while. A server that supports only one revision pushes the choice onto its users; claiming both is a way of smoothing upgrades.

The feature list is broad: tools, resources, prompts, completions, extensions. It also names tasks and skills, tagged as SEP-2640. Those two sit in newer territory within MCP, where both the specification text and implementations are still moving. Listing them is one thing; whether their semantics have settled enough to build on is another, and that requires checking the project’s documentation against the relevant SEPs.

For authoring, there are two paths: a DSL and declarative Java annotations. The annotation approach will feel familiar to anyone who has written a Java web service — mark a method, let the framework handle registration and parameter mapping. The DSL suits cases where you want finer control over parameter descriptions, return shapes and metadata. Supporting both makes it easier to fit existing code, at the cost of doubling documentation and maintenance load, which is usually more than a young project can carry on both fronts at once.

Early days

The Hacker News submission sits at 2 points and no comments. That says nothing about code quality; it says the project has not entered the conversation yet. A practical way to judge it is to read the examples and tests on GitHub — how errors come back, how a streamed response is interrupted, how concurrent registration behaves — before wiring it into a real service. Projects at this stage tend to change shape quickly, and the ones that last are usually the ones whose authors keep pace with spec revisions rather than filling out feature checklists.

For companies already running many Java services, opening internal methods to AI clients forces a decision: let every service implement the protocol details, or extract a shared SDK layer. Tachyon answers with the second option, betting on Netty and annotations. It has company on that path. What decides the outcome is how fast the spec is tracked and how well the SDK meshes with existing Spring stacks; the length of the feature list matters less.