Free tool

REST API to MCP Server in Java

What it actually takes to expose a REST API as an MCP server in Java — the SDK, a working tool, and the part that decides whether an agent uses it correctly.

Official SDK modelcontextprotocol/java-sdk
Install
Maven: io.modelcontextprotocol.sdk:mcp
A working MCP tool in Java
McpServerFeatures.SyncToolSpecification getOrder =
    new McpServerFeatures.SyncToolSpecification(
        new McpSchema.Tool( "get_order",
            "Look up one order by its id and return its current status.",
            ORDER_INPUT_SCHEMA ),
        ( exchange, args ) -> new McpSchema.CallToolResult(
            List.of( new McpSchema.TextContent( fetchOrder( (String)args.get( "orderId" ) ) ) ),
            false ) );

McpSyncServer server = McpServer.sync( transportProvider )
        .serverInfo( "my-server", "1.0.0" )
        .tools( getOrder )
        .build();

It runs. Nobody else can see that.

A working server is where the effort ends and the selling starts. Point MCP Showcase at it and get a live playground your customers can try, with documentation generated for every tool.

How it works

link
Install the SDK

Shown above, along with whether it is officially maintained or a community project — which matters more in some languages than others.

play_circle
Wrap one endpoint

Start with a single tool, not your whole API. Tool definitions are sent to the model on every request, and selection accuracy falls as the list grows.

checklist
Test it before you connect an agent

Run the deployed URL through the MCP Inspector to confirm the handshake completes and the tools appear as you intended.

The Java SDK

Maven: io.modelcontextprotocol.sdk:mcpmodelcontextprotocol/java-sdk, officially maintained.

Sync and async clients are separate types

The Java SDK exposes McpSyncServer and McpAsyncServer as distinct types rather than one API with a mode flag, and the transport is chosen at build time. Pick the wrong one and you are rewriting the wiring, not flipping a setting. Spring AI wraps this if you are already in that ecosystem.

Wrapping a REST endpoint

An MCP server is a thin layer over code you already have. Each tool needs three things: a name, a description saying what it does and when to choose it, and an input schema. The Java SDK handles the protocol; what you write is the mapping from those arguments to your existing HTTP call.

Start with one endpoint rather than your whole API. Tool definitions are re-sent to the model on every single request, so each one is a permanent context cost, and the model's ability to pick correctly falls as the list grows. Eight well-described tools beat eighty.

The part that is not about Java

Whatever language you use, the descriptions decide whether the agent behaves. They are read by the model, not by your colleagues, and a tool described in three words gets called by guesswork. You can check yours with the MCP schema linter, and see what the list costs per request with the token calculator.

Related tools and guides

A working server is half the job

Once it runs, the remaining problem is that nobody can tell what it does. A prospect cannot read your Java source and will not install a client to find out. MCP Showcase points at the same URL and produces a live playground with generated documentation for every tool, so evaluating your server takes a click.

Frequently asked questions

Wrap each endpoint you want an agent to reach in a tool: a name, a one-sentence description of what it does and when to use it, and an input schema. The Java SDK handles the protocol; what you write is the mapping from tool arguments to your existing HTTP call.

No, and this is the most common mistake. Tool definitions are re-sent on every single request, so eighty endpoints is eighty descriptions in the context window of every turn — and the model's ability to pick the right one drops sharply as the list grows. Start with the few an agent genuinely needs.

The badge above the code says which. Where there is no official SDK, community options vary in how closely they track the spec — check when the library last followed a protocol revision, particularly around transports, before you build on it.

Streamable HTTP for anything deployed. Clients increasingly try it first and some no longer fall back to the older HTTP+SSE transport, which shows up as a client that simply cannot see your server rather than as an error.

You cannot tell by reading your own code, because you already know what the tools do. Run the server through the schema linter: it checks the descriptions and input schemas the way a model reads them and flags the ones that would make an agent guess.

More free MCP tools