> ./run_exploration.sh

@ahikmah/lab / research archive

Back to Research Log
AI Engineering

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.

Spring AIMCPJava 21Spring BootAI Architecture

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).

MCP Flow Overview

“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:

  1. Standard REST API: Continues to serve mobile/web CLI requests via HTTP.
  2. 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);
  1. User Request: Client sends JWT in Authorization header.
  2. Context Extraction: MCP Client extracts the sub (User ID).
  3. Tool Execution: When the LLM invokes a tool (e.g., get_deposit), the original JWT is forwarded in the MCP request headers.
  4. RLS Enforcement: The backend (Bank-Service) validates the token and enforces @PreAuthorize rules, ensuring the AI agent can only access data belonging to the authenticated user.

Component Architecture

ComponentTechnologyRole
MCP ClientSpring AI (Java 21)Router: Maintains conversation state, handles LLM context window, and routes tool calls.
MCP ServerSpring Boot 3.4+Toolbox: Stateless service exposing business logic as discovery-ready tools.
TransportSSE + JSON-RPCProtocol: 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:

MCP Transport Proof

2. End-to-End Execution Flow

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

MCP Architecture Sequence Diagram

3. Functional Proof (Evidence)

To validate the full loop, we executed a “Check Deposit” intent.

  1. Input: User asks about deposit status.
  2. Process: System identifies get_deposit tool -> Executes SQL query.
  3. Result: LLM formulates natural language response based on DB data.

End-to-End Execution

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: Data Before

State After: Data 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.