用 Spring AI 在 Java 中构建 MCP 客户端与服务端

Model Context Protocol with Spring AI: Building MCP Clients and Servers in Java In the previous article, we explored how to build AI agents with Spring AI using: LLMs ↓ RAG ↓ Tool Calling ↓ Memory ↓ Agent Workflows Enter fullscreen mode Exit fullscreen mode Tool calling gives an AI application the ability to interact with external capabilities. But another problem appears as AI systems become larger. Imagine you have: Customer Service Agent ↓ Order APIs Payment APIs CRM APIs Knowledge Base Email Service Enter fullscreen mode Exit fullscreen mode And another application has: Sales Agent ↓ CRM Calendar Email Customer Database Enter fullscreen mode Exit fullscreen mode And another has: Developer Agent ↓ Git Repository Issue Tracker CI/CD Documentation Enter fullscreen mode Exit fullscreen mode If every AI application implements every integration differently, the architecture quickly becomes difficult to maintain. This is where Model Context Protocol (MCP) becomes interesting. MCP provides a standardized way for AI applications to interact with external tools and resources. Spring AI provides support for both building MCP servers and consuming MCP servers from Spring Boot applications. In this article, we'll build a mental model for MCP and explore how Java developers can use it with Spring AI. What Is MCP? MCP stands for: Model Context Protocol At a high level, MCP standardizes how an AI application communicates with external capabilities such as: Tools Resources Prompts Enter fullscreen mode Exit fullscreen mode Instead of every AI application inventing its own integration mechanism: AI Application ↓ Custom Tool Integration ↓ CRM Enter fullscreen mode Exit fullscreen mode we can have: AI Application ↓ MCP Client ↓ MCP Protocol ↓ MCP Server ↓ CRM Enter fullscreen mode Exit fullscreen mode The MCP server exposes capabilities through a standardized interface. The AI application doesn't need to understand every internal implementation detail of the external system. Why MCP Exists Suppose you build an AI assistant that needs access to: GitHub Slack PostgreSQL Google Calendar Internal APIs File Systems Enter fullscreen mode Exit fullscreen mode Without a standard protocol, your application might contain: GitHub Integration Slack Integration PostgreSQL Integration Calendar Integration Internal API Integration Enter fullscreen mode Exit fullscreen mode Each integration may have its own: Authentication Tool Schema Request Format Response Format Connection Management Error Handling Enter fullscreen mode Exit fullscreen mode Now imagine another AI application needs the same capabilities. You may end up rebuilding many of the same integrations. MCP addresses this by creating a common protocol for AI applications and external servers. Conceptually: AI Application │ MCP Client │ MCP Protocol │ ┌─────────────────┼─────────────────┐ ↓ ↓ ↓ MCP Server MCP Server MCP Server ↓ ↓ ↓ CRM GitHub Database Enter fullscreen mode Exit fullscreen mode This is one of the main ideas behind MCP. MCP Is Not an LLM This distinction is important. MCP is not: An AI model Enter fullscreen mode Exit fullscreen mode It is a protocol for connecting AI applications with capabilities. Think of the stack like this: LLM ↓ AI Application ↓ MCP Client ↓ MCP Protocol ↓ MCP Server ↓ Tools / Resources ↓ External System Enter fullscreen mode Exit fullscreen mode The LLM performs reasoning. The MCP layer provides standardized communication. The external system performs the actual operation. MCP Client vs MCP Server MCP introduces two important roles. MCP Client The MCP client lives inside the AI application. Its responsibility is to connect to MCP servers and interact with the capabilities they expose. For example: Spring Boot AI Application ↓ MCP Client ↓ Weather MCP Server Enter fullscreen mode Exit fullscreen mode The client can discover and use the server's available capabilities. MCP Server The MCP server exposes capabilities. For example: Weather MCP Server Tools: getWeather() getForecast() Resources: weather://cities Prompts: weather-analysis Enter fullscreen mode Exit fullscreen mode The server is responsible for implementing those capabilities. Spring AI provides Boot starters and APIs for both sides of this architecture. The Basic MCP Architecture A simplified architecture looks like: User ↓ Spring Boot ↓ ChatClient ↓ MCP Client ↓ MCP Protocol ↓ MCP Server ↓ Tool ↓ External API Enter fullscreen mode Exit fullscreen mode For example: User: What's the weather in Paris? Enter fullscreen mode Exit fullscreen mode The AI application can discover a weather tool exposed by an MCP server. The flow becomes: User ↓ LLM ↓ MCP Tool ↓ Weather MCP Server ↓ Weather API ↓ Tool Result ↓ LLM ↓ Final Answer Enter fullscreen mode Exit fullscreen mode MCP and Traditional Tool Calling At this point, you might ask: "Isn't this just tool calling?" There is an important distinction. Traditional Spring AI tool calling can expose application methods directly: @Tool public String getWeather(String city) { return weatherService.getWeather(city); } Enter fullscreen mode Exit fullscreen mode Your application owns the tool. With MCP: AI Application ↓ MCP Client ↓ Remote MCP Server ↓ Tool Enter fullscreen mode Exit fullscreen mode The tool can live outside the application. This creates a cleaner separation between: AI Application Enter fullscreen mode Exit fullscreen mode and: Capability Provider Enter fullscreen mode Exit fullscreen mode Spring AI integrates MCP tools into its tool-calling architecture, allowing applications to consume tools exposed by MCP servers. MCP Tools One of the most important MCP capabilities is the tool. A tool represents an action that an AI application can invoke. For example: getWeather() createTicket() searchCustomers() getOrder() sendEmail() Enter fullscreen mode Exit fullscreen mode A weather server might expose: getTemperature(city) Enter fullscreen mode Exit fullscreen mode A CRM server might expose: findCustomer(email) createLead(customer) updateLead(leadId) Enter fullscreen mode Exit fullscreen mode A developer server might expose: searchRepository(query) getBuildStatus() createIssue(title) Enter fullscreen mode Exit fullscreen mode The MCP client can discover these tools and make them available to the AI application. MCP Resources MCP is not limited to actions. It can also expose resources. A resource represents information that an MCP client can access. For example: customer://123 order://ORD-10291 file://README.md database://schema Enter fullscreen mode Exit fullscreen mode Think of the distinction as: Tool = Do something Resource = Access something Enter fullscreen mode Exit fullscreen mode For example: Tool: createTicket() Resource: customer://123 Enter fullscreen mode Exit fullscreen mode A server can expose both. MCP Prompts MCP also supports prompts. A server can provide reusable prompt templates for specific tasks. For example: Prompt: analyze-customer Input: customerId Enter fullscreen mode Exit fullscreen mode Or: Prompt: summarize-order Input: orderId Enter fullscreen mode Exit fullscreen mode This allows prompt templates to become part of the server-provided capabilities rather than being hardcoded independently in every client. Spring AI's MCP support includes annotations for tools, resources, and prompts. Building an MCP Server with Spring AI Let's build a simple MCP server. Imagine a weather service. Our application already has: @Service public class WeatherService { public String getTemperature(String city) { return "22°C"; } } Enter fullscreen mode Exit fullscreen mode We can expose this capability through an MCP tool. With Spring AI's annotation-based MCP support: @Service public class WeatherTools { @McpTool(description = "Get the current temperature for a city") public String getTemperature( @McpToolParam( description = "City name", required = true ) String city) { return weatherService.getTemperature(city); } } Enter fullscreen mode Exit fullscreen mode The MCP annotation model allows Spring services to expose capabilities as MCP operations. Creating the MCP Server For a Spring Boot application, Spring AI provides MCP server starters. For example: org.springframework.ai spring-ai-starter-mcp-server-webmvc Enter fullscreen mode Exit fullscreen mode You can configure the server to use Streamable HTTP: spring.ai.mcp.server.protocol=STREAMABLE Enter fullscreen mode Exit fullscreen mode Spring AI 2.x supports MCP server transports including Streamable HTTP, stateless Streamable HTTP, SSE, and STDIO. Streamable HTTP is the current recommended HTTP transport in Spring AI 2.x, while SSE is deprecated for this use case. What Happens Inside the MCP Server? Conceptually: Spring Boot ↓ MCP Server ↓ Tool Registry ↓ @McpTool ↓ WeatherService ↓ Weather API Enter fullscreen mode Exit fullscreen mode The server exposes the tool through the MCP protocol. The client doesn't need to know how the weather service works internally. It only needs to understand: Tool Name Description Input Schema Enter fullscreen mode Exit fullscreen mode Building an MCP Client Now let's create the other side. Suppose our AI application needs to consume the weather MCP server. Add the MCP client starter: org.springframework.ai spring-ai-starter-mcp-client Enter fullscreen mode Exit fullscreen mode Then configure the MCP server connection. For example, using Streamable HTTP: spring: ai: mcp: client: streamable-http: connections: weather-server: url: http://localhost:8080 Enter fullscreen mode Exit fullscreen mode Spring AI can connect to the configured MCP server and discover its tools. Connecting MCP Tools to ChatClient Once the MCP client discovers the server's tools, those tools can be integrated into Spring AI's tool-calling architecture. Conceptually: @Bean CommandLineRunner demo( ChatClient chatClient, ToolCallbackProvider mcpTools) { return args -> { String response = chatClient .prompt("What's the weather in Paris?") .tools(mcpTools) .call() .content(); System.out.println(response); }; } Enter fullscreen mode Exit fullscreen mode This is a powerful abstraction. The application doesn't need to manually implement every weather function. The MCP server provides the capability. The MCP client discovers it. Spring AI makes the discovered tools available to the model. The flow becomes: User ↓ ChatClient ↓ LLM ↓ MCP Tool ↓ MCP Client ↓ MCP Server ↓ Weather API ↓ Tool Result ↓ LLM ↓ Answer Enter fullscreen mode Exit fullscreen mode Spring AI's current MCP documentation demonstrates this client pattern using ToolCallbackProvider. MCP Tool Discovery One of the interesting capabilities of MCP is tool discovery. Instead of hardcoding: Tool A Tool B Tool C Enter fullscreen mode Exit fullscreen mode the client can connect to an MCP server and discover what capabilities it provides. For example: MCP Server ↓ tools/list ↓ getWeather() getForecast() searchAlerts() Enter fullscreen mode Exit fullscreen mode The AI application can then make these tools available to the model. This creates a more modular architecture. Multiple MCP Servers Now imagine our AI assistant needs multiple capabilities. We could have: AI Application │ ├── MCP Client │ ├── Weather Server │ ├── CRM Server │ ├── GitHub Server │ └── Internal API Server Enter fullscreen mode Exit fullscreen mode The architecture becomes: AI Agent │ MCP Client │ ┌──────────────┼──────────────┐ ↓ ↓ ↓ Weather MCP CRM MCP GitHub MCP ↓ ↓ ↓ Weather API CRM API GitHub API Enter fullscreen mode Exit fullscreen mode The AI application can consume tools from multiple MCP servers. This is one reason MCP becomes useful as an AI system grows. MCP + Spring AI Agents Now connect this to the previous article. We previously had: Agent ↓ Tools ↓ APIs Enter fullscreen mode Exit fullscreen mode With MCP, we can move the tools outside the application boundary: Agent ↓ MCP Client ↓ MCP Servers ├── CRM ├── Payments ├── Search └── Internal APIs Enter fullscreen mode Exit fullscreen mode The resulting architecture becomes: User ↓ Spring Boot ↓ ChatClient ↓ Agent ↓ MCP Client ↓ ┌─────────────┼─────────────┐ ↓ ↓ ↓ CRM MCP Payment MCP Search MCP ↓ ↓ ↓ CRM API Payment API Search API Enter fullscreen mode Exit fullscreen mode This creates a modular tool ecosystem. MCP vs Direct Tool Calling Let's compare the two approaches. Direct Spring AI Tool ChatClient ↓ @Tool ↓ Service ↓ Database Enter fullscreen mode Exit fullscreen mode Everything lives inside the application. MCP Tool ChatClient ↓ MCP Client ↓ MCP Server ↓ Service ↓ Database Enter fullscreen mode Exit fullscreen mode The capability provider can be separated from the AI application. This can be useful when: Multiple AI applications need the same capability Tools need independent deployment Teams own different integrations External systems need standardized AI access You want a reusable tool ecosystem MCP Server as a Capability Layer One useful architectural pattern is: Business System ↓ MCP Server ↓ AI Applications Enter fullscreen mode Exit fullscreen mode For example: CRM ↓ CRM MCP Server ↓ ├── Sales Agent ├── Support Agent └── Internal Assistant Enter fullscreen mode Exit fullscreen mode Instead of implementing CRM integration separately in every AI application, the MCP server becomes the standardized capability layer. MCP + RAG MCP doesn't replace RAG. They solve different problems. RAG: Retrieve relevant knowledge Enter fullscreen mode Exit fullscreen mode MCP: Connect AI applications to external capabilities Enter fullscreen mode Exit fullscreen mode You can combine them: Agent ↓ ┌───────────┼───────────┐ ↓ ↓ ↓ RAG MCP Tools Memory ↓ ↓ ↓ Vector DB External APIs Database Enter fullscreen mode Exit fullscreen mode For example: User: Can I refund order ORD-10291? Enter fullscreen mode Exit fullscreen mode The agent could: 1. MCP → Get order information 2. RAG → Retrieve refund policy 3. Agent → Compare the two 4. Return answer Enter fullscreen mode Exit fullscreen mode This gives the model both: Live Data + Business Knowledge Enter fullscreen mode Exit fullscreen mode MCP + Memory Memory can also coexist with MCP. For example: User: Use my preferred delivery address. Agent: Which address? User: The one I used last time. Enter fullscreen mode Exit fullscreen mode The application may use: Memory ↓ Previous Address Enter fullscreen mode Exit fullscreen mode while MCP provides: Order Service ↓ Update Delivery Address Enter fullscreen mode Exit fullscreen mode The complete flow becomes: Agent ├── Memory ├── RAG └── MCP ├── Orders ├── Payments └── CRM Enter fullscreen mode Exit fullscreen mode This is becoming a much more complete agent architecture. MCP Transports MCP supports multiple ways for clients and servers to communicate. Common options include: STDIO SSE Streamable HTTP Stateless Streamable HTTP Enter fullscreen mode Exit fullscreen mode For local process-based integrations: AI Application ↓ STDIO ↓ MCP Server Process Enter fullscreen mode Exit fullscreen mode For network-based applications: AI Application ↓ HTTP ↓ MCP Server Enter fullscreen mode Exit fullscreen mode In Spring AI 2.x, Streamable HTTP is the current HTTP-oriented approach, while SSE has been deprecated in favor of Streamable HTTP. STDIO vs HTTP A simple way to think about it: STDIO Application ↓ Local MCP Process Enter fullscreen mode Exit fullscreen mode Useful for local integrations and process-based communication. Streamable HTTP Application ↓ Network ↓ MCP Server Enter fullscreen mode Exit fullscreen mode Useful when the MCP server runs as an independent service. Stateless Streamable HTTP Client ↓ Request ↓ Server ↓ Response Enter fullscreen mode Exit fullscreen mode This can be useful for stateless, cloud-native service architectures. The right transport depends on deployment and communication requirements. MCP Security This is extremely important. An MCP server may expose powerful capabilities: readCustomer() createInvoice() refundPayment() deleteUser() Enter fullscreen mode Exit fullscreen mode Simply exposing those tools does not make them safe. Spring AI's MCP server starters do not automatically provide authentication or authorization for network-accessible MCP endpoints. The documentation specifically warns that HTTP-based MCP endpoints need a security boundary before being exposed beyond localhost. A production architecture should look like: Client ↓ Authentication ↓ Authorization ↓ MCP Server ↓ Tool ↓ Business Logic Enter fullscreen mode Exit fullscreen mode Not: Internet ↓ MCP Server ↓ Dangerous Tool Enter fullscreen mode Exit fullscreen mode MCP Tool Authorization Imagine an MCP server exposes: getCustomer() updateCustomer() deleteCustomer() Enter fullscreen mode Exit fullscreen mode Different users should have different capabilities. For example: READ ↓ getCustomer() WRITE ↓ updateCustomer() DESTRUCTIVE ↓ deleteCustomer() Enter fullscreen mode Exit fullscreen mode Your security layer should determine whether the caller is allowed to invoke each capability. The model should never be considered the authorization layer. The application must enforce it. MCP and Multi-Tenant Systems MCP becomes particularly interesting in SaaS environments. Suppose: Tenant A ↓ CRM MCP Server Enter fullscreen mode Exit fullscreen mode and: Tenant B ↓ CRM MCP Server Enter fullscreen mode Exit fullscreen mode The MCP layer must preserve tenant context. A request might carry: tenantId userId roles permissions Enter fullscreen mode Exit fullscreen mode The server can then enforce: Authentication ↓ Tenant Resolution ↓ Authorization ↓ Tool Execution ↓ Tenant-Scoped Data Enter fullscreen mode Exit fullscreen mode This is especially important for tools such as: searchCustomers() getInvoices() searchDocuments() createTicket() Enter fullscreen mode Exit fullscreen mode A model must never be able to use a tool to cross tenant boundaries. MCP Error Handling External tools can fail. For example: Agent ↓ MCP Tool ↓ CRM API ↓ Timeout Enter fullscreen mode Exit fullscreen mode Your application needs controlled failure behavior. For example: Tool Failure ↓ Capture Error ↓ Return Structured Result ↓ Agent ↓ Retry / Alternative Tool / Final Response Enter fullscreen mode Exit fullscreen mode The agent might decide: CRM unavailable. Try cached customer information. Enter fullscreen mode Exit fullscreen mode Or: Unable to retrieve the customer's order. Please try again later. Enter fullscreen mode Exit fullscreen mode The important part is that failures should be observable and controlled. MCP Observability When MCP is added to an agent architecture, your observability requirements increase. You may need to track: MCP Server MCP Client Tool Name Tool Arguments Request ID Latency Status Errors Retries Model Calls Token Usage Enter fullscreen mode Exit fullscreen mode A useful trace could look like: User Request ↓ LLM Call ↓ MCP Tool Discovery ↓ Tool Call ↓ CRM API ↓ Tool Result ↓ LLM Call ↓ Final Response Enter fullscreen mode Exit fullscreen mode Without tracing, debugging multi-server agent systems can become difficult. MCP Doesn't Replace Your Business Logic This is another important principle. Suppose you have: public RefundResult refundPayment( String orderId, BigDecimal amount) { ... } Enter fullscreen mode Exit fullscreen mode You shouldn't move all business logic into an MCP handler. Instead: MCP Tool ↓ Application Service ↓ Business Rules ↓ Repository ↓ Database Enter fullscreen mode Exit fullscreen mode For example: @McpTool(description = "Refund an eligible order") public RefundResult refundOrder(String orderId) { return refundService.refund(orderId); } Enter fullscreen mode Exit fullscreen mode The MCP layer becomes an interface. Your existing business service remains responsible for the actual business rules. This keeps the architecture clean. MCP as an Integration Boundary One of the strongest ways to think about MCP is as an integration boundary. Instead of: AI ↓ Everything Enter fullscreen mode Exit fullscreen mode use: AI ↓ MCP ↓ Controlled Capabilities Enter fullscreen mode Exit fullscreen mode The MCP layer becomes a contract between AI applications and external systems. For example: AI Application ↓ MCP ↓ CRM Enter fullscreen mode Exit fullscreen mode or: AI Application ↓ MCP ↓ Payment System Enter fullscreen mode Exit fullscreen mode or: AI Application ↓ MCP ↓ Internal Developer Platform Enter fullscreen mode Exit fullscreen mode A Complete Spring AI + MCP Architecture Now combine everything from this series: User ↓ Spring Boot API ↓ ChatClient ↓ Agent ↓ ┌──────────────────┼──────────────────┐ ↓ ↓ ↓ Memory RAG MCP Client ↓ ↓ ↓ PostgreSQL pgvector ┌─────┼─────┐ ↓ ↓ ↓ CRM GitHub Search MCP MCP MCP ↓ ↓ ↓ APIs APIs APIs Enter fullscreen mode Exit fullscreen mode Around the system: Authentication Authorization Tenant Isolation Observability Audit Logging Rate Limiting Guardrails Human Approval Enter fullscreen mode Exit fullscreen mode This is a strong foundation for production-oriented AI applications. When Should You Use MCP? MCP becomes particularly useful when you have: Multiple AI applications ↓ Shared tools ↓ Shared integrations Enter fullscreen mode Exit fullscreen mode For example: Sales Agent Support Agent Developer Agent Internal Assistant Enter fullscreen mode Exit fullscreen mode all need access to: CRM GitHub Internal APIs Documentation Enter fullscreen mode Exit fullscreen mode Instead of implementing each integration separately: Agent A → CRM Integration Agent B → CRM Integration Agent C → CRM Integration Enter fullscreen mode Exit fullscreen mode you can create: CRM MCP Server Enter fullscreen mode Exit fullscreen mode and allow multiple AI applications to consume it. When You Don't Need MCP MCP isn't automatically required for every AI application. If your application has: One Agent ↓ One Tool ↓ One Internal Service Enter fullscreen mode Exit fullscreen mode direct Spring AI tool calling may be simpler. For example: ChatClient ↓ @Tool ↓ OrderService Enter fullscreen mode Exit fullscreen mode Introducing an MCP server could add unnecessary infrastructure. A useful rule is: Use MCP when standardization, reuse, separation, or interoperability provides real value. Don't introduce another protocol simply because it is popular. Direct Tools vs MCP A simple comparison: Approach Best suited for Spring AI @Tool Local application capabilities MCP Shared/external capabilities RAG Knowledge retrieval Memory Conversation context Agent Dynamic decision-making They are not mutually exclusive. A production system may use all of them: Agent ├── Local Spring AI Tools ├── MCP Tools ├── RAG └── Memory Enter fullscreen mode Exit fullscreen mode The Bigger Picture Our AI architecture has evolved throughout this series. We started with: LLM ↓ Response Enter fullscreen mode Exit fullscreen mode Then: LLM ↓ RAG ↓ Knowledge Enter fullscreen mode Exit fullscreen mode Then: LLM ↓ Tools ↓ Actions Enter fullscreen mode Exit fullscreen mode Then: LLM ↓ Tools ↓ Memory ↓ Agent Enter fullscreen mode Exit fullscreen mode And now: Agent ↓ MCP ↓ External Capabilities Enter fullscreen mode Exit fullscreen mode The architecture is becoming increasingly modular. A Mental Model for MCP Remember it this way: LLM = Reason RAG = Retrieve Knowledge Memory = Remember Context Tool Calling = Invoke Capabilities MCP = Standardize Capability Access Spring Boot = Business Application Agent = Coordinate Decisions Enter fullscreen mode Exit fullscreen mode Together: LLM + RAG + Memory + Tools + MCP + Business Logic = Production AI Application Enter fullscreen mode Exit fullscreen mode Final Takeaways MCP gives AI applications a standardized way to interact with external tools and resources. The key ideas are: MCP Client connects an AI application to MCP servers. MCP Server exposes tools, resources, and prompts. Tools allow actions to be performed. Resources provide access to information. Prompts can provide reusable prompt templates. Spring AI supports MCP clients and servers through Boot starters and annotations. MCP tools integrate with Spring AI's existing tool-calling architecture. Streamable HTTP is the current HTTP-oriented transport in Spring AI 2.x. MCP does not replace your business logic. Authentication and authorization must be enforced before exposing network-accessible MCP servers. Multi-tenant applications must preserve tenant isolation across MCP calls. MCP is particularly useful when capabilities need to be shared across multiple AI applications. For simple local integrations, direct Spring AI tools may be sufficient. The architecture can now look like: User ↓ Agent ↓ ┌──────────────────┼──────────────────┐ ↓ ↓ ↓ Memory RAG MCP Client ↓ ↓ ↓ Conversation Vector DB MCP Servers ↓ ┌──────────────┼──────────────┐ ↓ ↓ ↓ CRM GitHub Internal APIs Enter fullscreen mode Exit fullscreen mode The important shift is this: Before: AI Application ↓ Custom Integrations ↓ External Systems Enter fullscreen mode Exit fullscreen mode With MCP: AI Application ↓ MCP Client ↓ Standardized Protocol ↓ MCP Servers ↓ External Capabilities Enter fullscreen mode Exit fullscreen mode MCP doesn't make your AI application automatically intelligent. It gives your AI application a standardized way to connect to capabilities. And when you combine MCP with Spring AI's: ChatClient + Tool Calling + RAG + Memory + Agents Enter fullscreen mode Exit fullscreen mode you get a powerful foundation for building modular AI applications in Java. What's Next? We've now connected our AI agent to external capabilities. But another challenge appears: One Agent ↓ Multiple MCP Servers ↓ Multiple Tools ↓ Multiple Decisions Enter fullscreen mode Exit fullscreen mode How do we control which tools an agent can access? How do we handle permissions? How do we observe agent behavior? How do we evaluate whether an agent is making the right decisions? And how do we build reliable AI workflows instead of simply hoping the model does the right thing? That takes us into the next stage of AI engineering: Building Production-Ready AI Agents with Spring AI — Guardrails, Evaluation, Observability, and Human-in-the-Loop Workflows.