What is MCP and Why Java Developers Should Care

Every AI tutorial shows you how to build a chatbot. You give it a system prompt, connect it to an LLM, and it talks back. But the moment you need the AI to do something real, like check inventory or query a payment status, you're writing custom HTTP clients and glue code.

MCP (Model Context Protocol) fixes this. It's a standard protocol that lets AI agents discover and call external tools over HTTP. Think of it as USB for AI: one plug, any device. Any agent can connect to any MCP server and use its tools without custom integration code.

This series covers MCP from a Java developer's perspective. Not theory. I'm running 4 MCP servers in production across a microservices system, and I'll show the actual code.

The Problem MCP Solves

I have 5 microservices coordinated via Kafka in a saga pattern. I built an AI agent that needs to query data across all of them: order details from MongoDB, payment status from PostgreSQL, inventory levels from another PostgreSQL, product catalog from a fourth database.

Without MCP, the options are bad. I could write an HTTP client for each service. Four clients, four sets of DTOs, four error handling strategies. Every time a service adds a new query, I update the client. Tight coupling between the agent and every service it talks to.

Or I could use LangChain4j's @Tool annotation. But @Tool only works for methods in the same JVM. My agent lives in a separate service. The inventory data lives in another.

How MCP Works

MCP uses JSON-RPC over HTTP with Server-Sent Events (SSE) for the connection lifecycle. The flow has three phases.

Discovery. The client connects to the server's SSE endpoint. It sends an initialize request and a tools/list request. The server responds with all available tools, including their names, descriptions, and parameter schemas.

Invocation. When the agent decides it needs data, the LLM generates a tool call. The MCP client sends a tools/call request with the tool name and arguments. The server executes the tool and returns the result.

Statelessness. Each tool call is independent. The server doesn't maintain state between calls. The session exists only for the SSE connection lifecycle.

In concrete terms, it looks like this:

Agent → SSE connect to http://localhost:8092/sse → gets sessionId
Agent → POST /mcp/message?sessionId=xxx → {"method": "initialize", ...}
Agent → POST /mcp/message?sessionId=xxx → {"method": "tools/list", ...}
Server responds → ["getStockByProduct", "getLowStockAlert", "checkReservationExists"]
Agent → POST /mcp/message?sessionId=xxx → {"method": "tools/call", "params": {"name": "getStockByProduct", "arguments": {"productCode": "COMIC_BOOKS"}}}
Server responds → {"available": 600}

No SDK needed on the client side. It's HTTP requests with JSON bodies. You could test it with curl.

MCP vs REST APIs

If you squint, MCP looks like a REST API with extra steps. Both expose functionality over HTTP. Both use JSON. So why not just call the REST endpoint directly?

Three reasons.

Tool discovery. REST APIs require documentation. Someone reads the Swagger spec and writes a client. MCP servers advertise their capabilities at runtime. The agent connects and instantly knows what tools are available, what parameters they take, and when to use them (via the description field).

LLM integration. LangChain4j converts MCP tool schemas into functionDeclaration objects that the LLM understands. The LLM reads the tool description, decides when to use it, and generates the correct arguments. You don't write routing logic.

Decoupling. Adding a new tool to a REST API means updating the client. Adding a new tool to an MCP server means the agent sees it on next connection. Zero changes on the agent side.

The Protocol in Detail

MCP uses three JSON-RPC methods.

initialize establishes the connection and negotiates capabilities:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "clientInfo": { "name": "my-agent", "version": "1.0.0" },
    "capabilities": {}
  }
}

tools/list returns all available tools:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list",
  "params": {}
}

tools/call invokes a specific tool:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "getStockByProduct",
    "arguments": { "productCode": "COMIC_BOOKS" }
  }
}

The response always comes back as a CallToolResult with a content array of TextContent objects. Simple and predictable.

The Java Ecosystem

Two libraries handle MCP in Java.

Server side: io.modelcontextprotocol.sdk:mcp:1.1.0. This is the official MCP Java SDK. You create an McpSyncServer with transport, tools, and server info. It handles the JSON-RPC protocol and SSE lifecycle.

Client side: LangChain4j's langchain4j-mcp module. You create McpClient instances pointing to each server's SSE URL. Then you wrap them in an McpToolProvider and pass it to your agent builder.

Both are stable and production-ready in my experience. The server SDK is lightweight (one dependency). The client side is handled by LangChain4j, so if you're already using it for agents, there's nothing extra to install.

What's Next

In the next post, I'll show step by step how to turn a Spring Boot microservice into an MCP server. Real code from my payment-service: defining tools, setting up the transport, and testing it with curl before connecting any AI agent.

The repo: github.com/pedrop3/saga-orchestration

推荐订阅源

DEV Community