Spring AI & MCP Architecture: Technical Feasibility Study
A technical feasibility study of MCP in a Java Spring backend, with separate LLM reasoning, tool execution, and authorization context.
Problem
This entry examines the feasibility of integrating Model Context Protocol (MCP) into a Java Spring Boot backend. The technical objective is to separate LLM reasoning from backend tool execution while preserving authorization context across the request path.
The artifact is a proof of concept. It demonstrates an architectural pattern and selected execution traces; it does not establish production suitability, compliance approval, or security completeness.
Core Validation Outcomes
- Feasibility signal: A functional PoC was implemented using Spring AI 1.1.0 with MCP support.
- Authorization experiment: The token-forwarding path preserves the user context used by downstream authorization checks in the PoC.
- Integration pattern: Existing backend services can expose selected capabilities through REST and MCP paths in the same architecture.
Architectural Strategy
High-Level Flow
The architecture introduces an MCP Client (router) that sits between the LLM and the backend services (MCP Servers).

“Dual-Mode” Server Strategy
A critical finding from this study is the ability to leverage existing microservices without significant refactoring. The backend operates in two simultaneous modes:
- Standard REST API: Continues to serve mobile/web CLI requests via HTTP.
- MCP Server: Exposes selected service methods as “tools” to the AI Agent via MCP protocol.
Impact: This eliminates the need to build a separate “AI Backend” layer, significantly reducing infrastructure duplicated effort.
Security Implementation
The Authentication Challenge
Standard MCP implementations often assume a trusted local environment (e.g., Claude Desktop). For enterprise deployment, we needed to propagate user identity from the client app through the AI agent to the backend.
Token Forwarding Solution
We implemented a Token Forwarding pattern where the JWT is passed along the chain:
// Logic on MCP Client (Agri-Service) to forward token
var tools = toolService.discoverTools(transport, authToken);
- User Request: Client sends JWT in
Authorizationheader. - Context Extraction: MCP Client extracts the
sub(User ID). - Tool Execution: When the LLM invokes a tool (e.g.,
get_deposit), the original JWT is forwarded in the MCP request headers. - RLS Enforcement: The backend (Bank-Service) validates the token and enforces
@PreAuthorizerules, ensuring the AI agent can only access data belonging to the authenticated user.
Component Architecture
| Component | Technology | Role |
|---|---|---|
| MCP Client | Spring AI (Java 21) | Router: Maintains conversation state, handles LLM context window, and routes tool calls. |
| MCP Server | Spring Boot 3.4+ | Toolbox: Stateless service exposing business logic as discovery-ready tools. |
| Transport | SSE + JSON-RPC | Protocol: Standardized communication channel for tool discovery and execution. |
Technical Validation
1. Transport Layer Verification
We verified the Server-Sent Events (SSE) handshake which establishes the persistent connection required for the MCP protocol. The trace below shows the JSON-RPC initialization:

2. End-to-End Execution Flow
The sequence diagram below details the verified flow: User Request → Tool Discovery → LLM Reasoning → Secure Tool Execution → Response.

3. Functional Proof (Evidence)
To validate the full loop, we executed a “Check Deposit” intent.
- Input: User asks about deposit status.
- Process: System identifies
get_deposittool -> Executes SQL query. - Result: LLM formulates natural language response based on DB data.

4. Data Consistency Check
Database state before and after execution proves the tool actually interacted with the persistence layer (H2 In-Memory DB for PoC).
State Before:

State After:

Conclusion
This experiment provides a feasibility signal for using Spring AI’s MCP implementation to separate tool execution from LLM interaction in Java. The traces show the intended request path and authorization context for the PoC. The product value is a reusable boundary: existing business services can remain responsible for business rules while the MCP layer exposes selected operations to an agent. Further work is required for production security review, failure testing, and operational validation.