skip to content

What is the Model Context Protocol (MCP), and what do the spring-ai-starter-mcp-client and spring-ai-starter-mcp-server starters give you?

level: juniorimportance: should knowfreq 40%

answer

  1. open JSON-RPC standard, client/server
  2. tools + resources + prompts
  3. client starter = consume, server starter = publish
  4. remote tool -> Spring AI ToolCallback
  5. stdio and HTTP/SSE transports

basics

~20 s

MCP is an open protocol that standardizes how AI apps connect to external tools and data over a client-server link. The client starter lets your app call remote MCP servers; the server starter lets your app publish tools other MCP clients can use.

solid answer

~40 s

The Model Context Protocol (MCP) is an open, JSON-RPC-based standard for connecting LLM applications to external capabilities — tools, resources, and prompts — through a uniform client/server interface, so you don't write a bespoke integration per tool source. In Spring AI, spring-ai-starter-mcp-client auto-configures MCP client(s) and adapts each remote server's tools into Spring AI ToolCallback objects you can hand to a ChatClient. spring-ai-starter-mcp-server auto-configures an MCP server that exposes your app's ToolCallbackProvider beans (typically @Tool methods) to any MCP client. Both sit on the MCP Java SDK, negotiate capabilities on connect, and support stdio and HTTP/SSE transports. Configuration is property-driven under spring.ai.mcp.client.* and spring.ai.mcp.server.*.

go deeper

for a junior

Know MCP is an open client/server standard for connecting AI apps to external tools, and which starter consumes vs. publishes.

for a middle

Add the lifecycle: initialize handshake, capability negotiation, tools/list and tools/call, and the property-driven config.

for a senior

Explain that the client starter adapts remote tools into ToolCallback objects and the server publishes ToolCallbackProvider beans, plus transport choices.

for a principal

Weigh MCP interoperability against a network hop and auth burden; decide when in-process tools suffice versus a shared MCP surface.

## What MCP is The **Model Context Protocol (MCP)** is an open specification (originating from Anthropic) that standardizes the wire contract between an **AI/LLM host application** and **external sources of context and capability**. Instead of every app inventing its own way to plug in a database, a search API, or a filesystem, MCP defines a common **client-server** protocol over **JSON-RPC 2.0**. A host (e.g. your Spring app or an IDE/assistant) runs one or more **MCP clients**, each connected to an **MCP server** that advertises three kinds of things: **tools** (callable functions), **resources** (readable data/blobs), and **prompts** (reusable prompt templates). Spring AI's MCP integration today focuses mostly on **tools**. ## Connection lifecycle When a client connects it performs an `initialize` handshake and **capability negotiation** (which of tools/resources/prompts each side supports). The client can then call `tools/list` to discover tools and `tools/call` to invoke one. This discovery is dynamic: the server describes each tool's name, description, and JSON-schema input, so the LLM can decide when to call it. ## The two Spring Boot starters - **`spring-ai-starter-mcp-client`** — auto-configures MCP client(s) from properties under `spring.ai.mcp.client.*`. Crucially, it also registers a `ToolCallbackProvider` (a `SyncMcpToolCallbackProvider` or `AsyncMcpToolCallbackProvider`) that **wraps each remote tool as a Spring AI `ToolCallback`**, so a remote MCP tool becomes indistinguishable from a locally-defined tool when passed to a `ChatClient`. - **`spring-ai-starter-mcp-server`** — auto-configures an MCP **server**. It scans for your `ToolCallbackProvider` beans (commonly built from `@Tool`-annotated methods) and **publishes them as MCP tools** that any MCP client can discover and call. Server identity/behavior is configured under `spring.ai.mcp.server.*` (e.g. `name`, `version`, `type`). ## Transports MCP is transport-agnostic. Spring AI supports **stdio** (the server runs as a child process, communicating over standard in/out — common for local tools) and **HTTP with Server-Sent Events (SSE)** / streamable HTTP (for networked servers). The server side offers WebMVC and WebFlux SSE variants (`spring-ai-starter-mcp-server-webmvc` / `-webflux`). ## When to use it Reach for MCP when you want **interoperability** — to consume tools published by third parties (or other teams) without coding each integration, or to publish your own capabilities so any MCP-aware host can use them. If your tools are purely internal to one app, plain in-process Spring AI `@Tool` beans are simpler and avoid a network hop. ## Gotchas - The starters are **Boot auto-configuration** — nothing works without the property-level connection config. - MCP standardizes *transport and discovery*, not *auth*; you secure the transport yourself (e.g. HTTP filters, process isolation for stdio). - Sync vs async is a deliberate choice tied to your transport/threading model (see the dedicated question).

  • Does MCP only expose tools?
    No — the protocol defines tools, resources (readable data), and prompts (reusable templates). Spring AI's integration is most mature for tools, but the protocol itself is broader.
  • If my tools are only used inside one Spring app, do I need MCP?
    No. Plain in-process @Tool beans wired into ChatClient are simpler. MCP earns its keep when you cross a process/team/vendor boundary and want interoperable discovery.

saying these in an interview costs you the question

  • Thinking MCP is an Anthropic-only, closed API rather than an open protocol
  • Believing MCP only ever means tools and never resources or prompts
  • Assuming the starters auto-connect without any spring.ai.mcp.* configuration

context

resolving links…