Connect an MCP client

What the runtime serves

• An MCP server on the same HTTP port as your application, over the Server-Sent Events transport.
• The SSE endpoint is http://<host>:<port>/sse. The session's message endpoint is issued to the client as the first SSE event, at /mcp/message?sessionId=...
• One MCP tool per capability. Each tool calls the real service method the capability is bound to.

Verified end to end

This path is verified two ways, so the promise is not just asserted.

• In process, on every build. An integration test boots a real Spring context and a genuine MCP server and drives initialize, tools/list, and tools/call against the real bean.
• Out of process, over the network. The example app was launched as a normal jar and an external client ran the full handshake. The result, recorded verbatim:

SSE endpoint event: /mcp/message?sessionId=e843ec10-...
initialize: ok   serverInfo: {"name":"tibyaan","version":"0.1.0"}
tools/list: ['getProduct']
tools/call getProduct(5): {"content":[{"type":"text","text":"{\"id\":5,\"name\":\"Wireless Mouse\",\"price\":29.99}"}],"isError":false}

What is not mechanically verified is the configuration of any one specific desktop client, because that is a GUI step on your machine. The protocol and the network path are verified; the per-client wiring below is the standard approach, to confirm against your client's current version.

Confirm it yourself

A one-line smoke test

With the app running, open the SSE stream. The server should immediately send an endpoint event naming the session's message URL, which proves the MCP server is live and speaking the protocol. Press Ctrl-C to stop; the stream stays open by design.

curl -N http://localhost:8080/sse
# event: endpoint
# data: /mcp/message?sessionId=...

A full handshake

The repository ships scripts/verify-mcp-sse.py, which drives the whole flow using only the Python standard library: open the stream, read the endpoint, initialize, tools/list, and one tools/call. Point it at your own app by editing the BASE URL, and change the final call to one of your discovered tools.

python scripts/verify-mcp-sse.py

Claude Code (direct SSE)

Claude Code connects to an SSE server directly. With your app running, register it once:

claude mcp add --transport sse my-legacy-app http://localhost:8080/sse
claude mcp list

Inside a session, /mcp shows the connected servers, and each capability appears as a tool named mcp__my-legacy-app__<capability>. You do not call that name by hand: ask in plain language, and the agent calls the tool. For the example app, "get product 5" makes the agent call getProduct with id 5 and read back the real row. To scope the server to one project, add it to a project .mcp.json instead of your user config.

Claude Desktop and other stdio-only clients

Clients that speak only the stdio transport reach a remote SSE server through a bridge. The common one is mcp-remote, launched over stdio:

{
  "mcpServers": {
    "my-legacy-app": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://localhost:8080/sse"]
    }
  }
}

Confirm the exact command names and config format against your client's current documentation; client configuration formats change faster than this project does.

Transport caveat

The runtime serves the HTTP and SSE transport. The MCP ecosystem has been moving toward the newer Streamable HTTP transport. If your client supports only Streamable HTTP, you need a bridge like the one above. Adding Streamable HTTP to the runtime is a candidate follow-up, not built in v1.

Before you expose it