{"slug": "model-context-protocol-with-spring-ai-building-mcp-clients-and-servers-in-java", "title": "Model Context Protocol with Spring AI, Building MCP Clients and Servers in Java", "summary": "A developer demonstrated how Java developers can build Model Context Protocol (MCP) clients and servers using Spring AI, which provides Boot starters and APIs for both sides of the architecture. The writeup explains how MCP standardizes AI application communication with external tools, resources, and prompts, replacing bespoke per-service integrations with a common protocol layer. The author frames MCP as a protocol rather than a model, positioning it between the LLM and external systems.", "body_md": "In the previous article, we explored how to build AI agents with **Spring AI** using:\n\n```\nLLMs\n ↓\nRAG\n ↓\nTool Calling\n ↓\nMemory\n ↓\nAgent Workflows\n```\n\nTool calling gives an AI application the ability to interact with external capabilities.\n\nBut another problem appears as AI systems become larger.\n\nImagine you have:\n\n```\nCustomer Service Agent\n        ↓\nOrder APIs\nPayment APIs\nCRM APIs\nKnowledge Base\nEmail Service\n```\n\nAnd another application has:\n\n```\nSales Agent\n        ↓\nCRM\nCalendar\nEmail\nCustomer Database\n```\n\nAnd another has:\n\n```\nDeveloper Agent\n        ↓\nGit Repository\nIssue Tracker\nCI/CD\nDocumentation\n```\n\nIf every AI application implements every integration differently, the architecture quickly becomes difficult to maintain.\n\nThis is where **Model Context Protocol (MCP)** becomes interesting.\n\nMCP 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.\n\nIn this article, we'll build a mental model for MCP and explore how Java developers can use it with Spring AI.\n\nMCP stands for:\n\n**Model Context Protocol**\n\nAt a high level, MCP standardizes how an AI application communicates with external capabilities such as:\n\n```\nTools\nResources\nPrompts\n```\n\nInstead of every AI application inventing its own integration mechanism:\n\n```\nAI Application\n ↓\nCustom Tool Integration\n ↓\nCRM\n```\n\nwe can have:\n\n```\nAI Application\n ↓\nMCP Client\n ↓\nMCP Protocol\n ↓\nMCP Server\n ↓\nCRM\n```\n\nThe MCP server exposes capabilities through a standardized interface.\n\nThe AI application doesn't need to understand every internal implementation detail of the external system.\n\nSuppose you build an AI assistant that needs access to:\n\n```\nGitHub\nSlack\nPostgreSQL\nGoogle Calendar\nInternal APIs\nFile Systems\n```\n\nWithout a standard protocol, your application might contain:\n\n```\nGitHub Integration\nSlack Integration\nPostgreSQL Integration\nCalendar Integration\nInternal API Integration\n```\n\nEach integration may have its own:\n\n```\nAuthentication\nTool Schema\nRequest Format\nResponse Format\nConnection Management\nError Handling\n```\n\nNow imagine another AI application needs the same capabilities.\n\nYou may end up rebuilding many of the same integrations.\n\nMCP addresses this by creating a common protocol for AI applications and external servers.\n\nConceptually:\n\n```\n                    AI Application\n                         │\n                    MCP Client\n                         │\n                MCP Protocol\n                         │\n       ┌─────────────────┼─────────────────┐\n       ↓                 ↓                 ↓\n  MCP Server         MCP Server         MCP Server\n       ↓                 ↓                 ↓\n     CRM              GitHub            Database\n```\n\nThis is one of the main ideas behind MCP.\n\nThis distinction is important.\n\nMCP is not:\n\n```\nAn AI model\n```\n\nIt is a protocol for connecting AI applications with capabilities.\n\nThink of the stack like this:\n\n```\nLLM\n ↓\nAI Application\n ↓\nMCP Client\n ↓\nMCP Protocol\n ↓\nMCP Server\n ↓\nTools / Resources\n ↓\nExternal System\n```\n\nThe LLM performs reasoning.\n\nThe MCP layer provides standardized communication.\n\nThe external system performs the actual operation.\n\nMCP introduces two important roles.\n\nThe MCP client lives inside the AI application.\n\nIts responsibility is to connect to MCP servers and interact with the capabilities they expose.\n\nFor example:\n\n```\nSpring Boot AI Application\n        ↓\nMCP Client\n        ↓\nWeather MCP Server\n```\n\nThe client can discover and use the server's available capabilities.\n\nThe MCP server exposes capabilities.\n\n```\nWeather MCP Server\n\nTools:\ngetWeather()\ngetForecast()\n\nResources:\nweather://cities\n\nPrompts:\nweather-analysis\n```\n\nThe server is responsible for implementing those capabilities.\n\nSpring AI provides Boot starters and APIs for both sides of this architecture.\n\nA simplified architecture looks like:\n\n```\n                    User\n                     ↓\n                 Spring Boot\n                     ↓\n                  ChatClient\n                     ↓\n                  MCP Client\n                     ↓\n                MCP Protocol\n                     ↓\n                MCP Server\n                     ↓\n                   Tool\n                     ↓\n                External API\nUser:\nWhat's the weather in Paris?\n```\n\nThe AI application can discover a weather tool exposed by an MCP server.\n\nThe flow becomes:\n\n```\nUser\n ↓\nLLM\n ↓\nMCP Tool\n ↓\nWeather MCP Server\n ↓\nWeather API\n ↓\nTool Result\n ↓\nLLM\n ↓\nFinal Answer\n```\n\nAt this point, you might ask:\n\n\"Isn't this just tool calling?\"\n\nThere is an important distinction.\n\nTraditional Spring AI tool calling can expose application methods directly:\n\n```\n@Tool\npublic String getWeather(String city) {\n    return weatherService.getWeather(city);\n}\n```\n\nYour application owns the tool.\n\nWith MCP:\n\n```\nAI Application\n      ↓\nMCP Client\n      ↓\nRemote MCP Server\n      ↓\nTool\n```\n\nThe tool can live outside the application.\n\nThis creates a cleaner separation between:\n\n```\nAI Application\n```\n\nand:\n\n```\nCapability Provider\n```\n\nSpring AI integrates MCP tools into its tool-calling architecture, allowing applications to consume tools exposed by MCP servers.\n\nOne of the most important MCP capabilities is the **tool**.\n\nA tool represents an action that an AI application can invoke.\n\n```\ngetWeather()\ncreateTicket()\nsearchCustomers()\ngetOrder()\nsendEmail()\n```\n\nA weather server might expose:\n\n```\ngetTemperature(city)\n```\n\nA CRM server might expose:\n\n```\nfindCustomer(email)\ncreateLead(customer)\nupdateLead(leadId)\n```\n\nA developer server might expose:\n\n```\nsearchRepository(query)\ngetBuildStatus()\ncreateIssue(title)\n```\n\nThe MCP client can discover these tools and make them available to the AI application.\n\nMCP is not limited to actions.\n\nIt can also expose **resources**.\n\nA resource represents information that an MCP client can access.\n\n```\ncustomer://123\norder://ORD-10291\nfile://README.md\ndatabase://schema\n```\n\nThink of the distinction as:\n\n```\nTool\n=\nDo something\n\nResource\n=\nAccess something\nTool:\ncreateTicket()\n\nResource:\ncustomer://123\n```\n\nA server can expose both.\n\nMCP also supports prompts.\n\nA server can provide reusable prompt templates for specific tasks.\n\n```\nPrompt:\nanalyze-customer\n\nInput:\ncustomerId\n```\n\nOr:\n\n```\nPrompt:\nsummarize-order\n\nInput:\norderId\n```\n\nThis allows prompt templates to become part of the server-provided capabilities rather than being hardcoded independently in every client.\n\nSpring AI's MCP support includes annotations for tools, resources, and prompts.\n\nLet's build a simple MCP server.\n\nImagine a weather service.\n\nOur application already has:\n\n```\n@Service\npublic class WeatherService {\n\n    public String getTemperature(String city) {\n        return \"22°C\";\n    }\n}\n```\n\nWe can expose this capability through an MCP tool.\n\nWith Spring AI's annotation-based MCP support:\n\n```\n@Service\npublic class WeatherTools {\n\n    @McpTool(description = \"Get the current temperature for a city\")\n    public String getTemperature(\n            @McpToolParam(\n                description = \"City name\",\n                required = true\n            )\n            String city) {\n\n        return weatherService.getTemperature(city);\n    }\n}\n```\n\nThe MCP annotation model allows Spring services to expose capabilities as MCP operations.\n\nFor a Spring Boot application, Spring AI provides MCP server starters.\n\n```\n<dependency>\n    <groupId>org.springframework.ai</groupId>\n    <artifactId>spring-ai-starter-mcp-server-webmvc</artifactId>\n</dependency>\n```\n\nYou can configure the server to use Streamable HTTP:\n\n```\nspring.ai.mcp.server.protocol=STREAMABLE\n```\n\nSpring 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.\n\n```\nSpring Boot\n     ↓\nMCP Server\n     ↓\nTool Registry\n     ↓\n@McpTool\n     ↓\nWeatherService\n     ↓\nWeather API\n```\n\nThe server exposes the tool through the MCP protocol.\n\nThe client doesn't need to know how the weather service works internally.\n\nIt only needs to understand:\n\n```\nTool Name\nDescription\nInput Schema\n```\n\nNow let's create the other side.\n\nSuppose our AI application needs to consume the weather MCP server.\n\nAdd the MCP client starter:\n\n```\n<dependency>\n    <groupId>org.springframework.ai</groupId>\n    <artifactId>spring-ai-starter-mcp-client</artifactId>\n</dependency>\n```\n\nThen configure the MCP server connection.\n\nFor example, using Streamable HTTP:\n\n```\nspring:\n  ai:\n    mcp:\n      client:\n        streamable-http:\n          connections:\n            weather-server:\n              url: http://localhost:8080\n```\n\nSpring AI can connect to the configured MCP server and discover its tools.\n\nOnce the MCP client discovers the server's tools, those tools can be integrated into Spring AI's tool-calling architecture.\n\n```\n@Bean\nCommandLineRunner demo(\n        ChatClient chatClient,\n        ToolCallbackProvider mcpTools) {\n\n    return args -> {\n\n        String response = chatClient\n                .prompt(\"What's the weather in Paris?\")\n                .tools(mcpTools)\n                .call()\n                .content();\n\n        System.out.println(response);\n    };\n}\n```\n\nThis is a powerful abstraction.\n\nThe application doesn't need to manually implement every weather function.\n\nThe MCP server provides the capability.\n\nThe MCP client discovers it.\n\nSpring AI makes the discovered tools available to the model.\n\n```\nUser\n ↓\nChatClient\n ↓\nLLM\n ↓\nMCP Tool\n ↓\nMCP Client\n ↓\nMCP Server\n ↓\nWeather API\n ↓\nTool Result\n ↓\nLLM\n ↓\nAnswer\n```\n\nSpring AI's current MCP documentation demonstrates this client pattern using `ToolCallbackProvider`.\n\nOne of the interesting capabilities of MCP is tool discovery.\n\nInstead of hardcoding:\n\n```\nTool A\nTool B\nTool C\n```\n\nthe client can connect to an MCP server and discover what capabilities it provides.\n\n```\nMCP Server\n ↓\ntools/list\n ↓\ngetWeather()\ngetForecast()\nsearchAlerts()\n```\n\nThe AI application can then make these tools available to the model.\n\nThis creates a more modular architecture.\n\nNow imagine our AI assistant needs multiple capabilities.\n\nWe could have:\n\n```\nAI Application\n      │\n      ├── MCP Client\n      │\n      ├── Weather Server\n      │\n      ├── CRM Server\n      │\n      ├── GitHub Server\n      │\n      └── Internal API Server\n```\n\nThe architecture becomes:\n\n```\n                         AI Agent\n                            │\n                        MCP Client\n                            │\n             ┌──────────────┼──────────────┐\n             ↓              ↓              ↓\n        Weather MCP      CRM MCP       GitHub MCP\n             ↓              ↓              ↓\n        Weather API       CRM API      GitHub API\n```\n\nThe AI application can consume tools from multiple MCP servers.\n\nThis is one reason MCP becomes useful as an AI system grows.\n\nNow connect this to the previous article.\n\nWe previously had:\n\n```\nAgent\n ↓\nTools\n ↓\nAPIs\n```\n\nWith MCP, we can move the tools outside the application boundary:\n\n```\nAgent\n ↓\nMCP Client\n ↓\nMCP Servers\n ├── CRM\n ├── Payments\n ├── Search\n └── Internal APIs\n```\n\nThe resulting architecture becomes:\n\n```\n                         User\n                           ↓\n                       Spring Boot\n                           ↓\n                        ChatClient\n                           ↓\n                         Agent\n                           ↓\n                       MCP Client\n                           ↓\n             ┌─────────────┼─────────────┐\n             ↓             ↓             ↓\n          CRM MCP      Payment MCP    Search MCP\n             ↓             ↓             ↓\n           CRM API     Payment API   Search API\n```\n\nThis creates a modular tool ecosystem.\n\nLet's compare the two approaches.\n\n```\nChatClient\n    ↓\n@Tool\n    ↓\nService\n    ↓\nDatabase\n```\n\nEverything lives inside the application.\n\n```\nChatClient\n    ↓\nMCP Client\n    ↓\nMCP Server\n    ↓\nService\n    ↓\nDatabase\n```\n\nThe capability provider can be separated from the AI application.\n\nThis can be useful when:\n\nOne useful architectural pattern is:\n\n```\nBusiness System\n       ↓\nMCP Server\n       ↓\nAI Applications\nCRM\n ↓\nCRM MCP Server\n ↓\n ├── Sales Agent\n ├── Support Agent\n └── Internal Assistant\n```\n\nInstead of implementing CRM integration separately in every AI application, the MCP server becomes the standardized capability layer.\n\nMCP doesn't replace RAG.\n\nThey solve different problems.\n\nRAG:\n\n```\nRetrieve relevant knowledge\n```\n\nMCP:\n\n```\nConnect AI applications to external capabilities\n```\n\nYou can combine them:\n\n```\n                       Agent\n                         ↓\n             ┌───────────┼───────────┐\n             ↓           ↓           ↓\n            RAG        MCP Tools    Memory\n             ↓           ↓           ↓\n        Vector DB    External APIs  Database\nUser:\nCan I refund order ORD-10291?\n```\n\nThe agent could:\n\n```\n1. MCP → Get order information\n2. RAG → Retrieve refund policy\n3. Agent → Compare the two\n4. Return answer\n```\n\nThis gives the model both:\n\n```\nLive Data\n+\nBusiness Knowledge\n```\n\nMemory can also coexist with MCP.\n\n```\nUser:\nUse my preferred delivery address.\n\nAgent:\nWhich address?\n\nUser:\nThe one I used last time.\n```\n\nThe application may use:\n\n```\nMemory\n ↓\nPrevious Address\n```\n\nwhile MCP provides:\n\n```\nOrder Service\n ↓\nUpdate Delivery Address\n```\n\nThe complete flow becomes:\n\n```\nAgent\n ├── Memory\n ├── RAG\n └── MCP\n       ├── Orders\n       ├── Payments\n       └── CRM\n```\n\nThis is becoming a much more complete agent architecture.\n\nMCP supports multiple ways for clients and servers to communicate.\n\nCommon options include:\n\n```\nSTDIO\nSSE\nStreamable HTTP\nStateless Streamable HTTP\n```\n\nFor local process-based integrations:\n\n```\nAI Application\n ↓\nSTDIO\n ↓\nMCP Server Process\n```\n\nFor network-based applications:\n\n```\nAI Application\n ↓\nHTTP\n ↓\nMCP Server\n```\n\nIn Spring AI 2.x, Streamable HTTP is the current HTTP-oriented approach, while SSE has been deprecated in favor of Streamable HTTP.\n\nA simple way to think about it:\n\n```\nApplication\n ↓\nLocal MCP Process\n```\n\nUseful for local integrations and process-based communication.\n\n```\nApplication\n ↓\nNetwork\n ↓\nMCP Server\n```\n\nUseful when the MCP server runs as an independent service.\n\n```\nClient\n ↓\nRequest\n ↓\nServer\n ↓\nResponse\n```\n\nThis can be useful for stateless, cloud-native service architectures.\n\nThe right transport depends on deployment and communication requirements.\n\nThis is extremely important.\n\nAn MCP server may expose powerful capabilities:\n\n```\nreadCustomer()\ncreateInvoice()\nrefundPayment()\ndeleteUser()\n```\n\nSimply exposing those tools does not make them safe.\n\nSpring 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.\n\nA production architecture should look like:\n\n```\nClient\n ↓\nAuthentication\n ↓\nAuthorization\n ↓\nMCP Server\n ↓\nTool\n ↓\nBusiness Logic\n```\n\nNot:\n\n```\nInternet\n ↓\nMCP Server\n ↓\nDangerous Tool\n```\n\nImagine an MCP server exposes:\n\n```\ngetCustomer()\nupdateCustomer()\ndeleteCustomer()\n```\n\nDifferent users should have different capabilities.\n\n```\nREAD\n ↓\ngetCustomer()\n\nWRITE\n ↓\nupdateCustomer()\n\nDESTRUCTIVE\n ↓\ndeleteCustomer()\n```\n\nYour security layer should determine whether the caller is allowed to invoke each capability.\n\nThe model should never be considered the authorization layer.\n\nThe application must enforce it.\n\nMCP becomes particularly interesting in SaaS environments.\n\nSuppose:\n\n```\nTenant A\n ↓\nCRM MCP Server\nTenant B\n ↓\nCRM MCP Server\n```\n\nThe MCP layer must preserve tenant context.\n\nA request might carry:\n\n```\ntenantId\nuserId\nroles\npermissions\n```\n\nThe server can then enforce:\n\n```\nAuthentication\n ↓\nTenant Resolution\n ↓\nAuthorization\n ↓\nTool Execution\n ↓\nTenant-Scoped Data\n```\n\nThis is especially important for tools such as:\n\n```\nsearchCustomers()\ngetInvoices()\nsearchDocuments()\ncreateTicket()\n```\n\nA model must never be able to use a tool to cross tenant boundaries.\n\nExternal tools can fail.\n\n```\nAgent\n ↓\nMCP Tool\n ↓\nCRM API\n ↓\nTimeout\n```\n\nYour application needs controlled failure behavior.\n\n```\nTool Failure\n ↓\nCapture Error\n ↓\nReturn Structured Result\n ↓\nAgent\n ↓\nRetry / Alternative Tool / Final Response\n```\n\nThe agent might decide:\n\n```\nCRM unavailable.\n\nTry cached customer information.\nUnable to retrieve the customer's order.\nPlease try again later.\n```\n\nThe important part is that failures should be observable and controlled.\n\nWhen MCP is added to an agent architecture, your observability requirements increase.\n\nYou may need to track:\n\n```\nMCP Server\nMCP Client\nTool Name\nTool Arguments\nRequest ID\nLatency\nStatus\nErrors\nRetries\nModel Calls\nToken Usage\n```\n\nA useful trace could look like:\n\n```\nUser Request\n    ↓\nLLM Call\n    ↓\nMCP Tool Discovery\n    ↓\nTool Call\n    ↓\nCRM API\n    ↓\nTool Result\n    ↓\nLLM Call\n    ↓\nFinal Response\n```\n\nWithout tracing, debugging multi-server agent systems can become difficult.\n\nThis is another important principle.\n\nSuppose you have:\n\n```\npublic RefundResult refundPayment(\n        String orderId,\n        BigDecimal amount) {\n    ...\n}\n```\n\nYou shouldn't move all business logic into an MCP handler.\n\nInstead:\n\n```\nMCP Tool\n ↓\nApplication Service\n ↓\nBusiness Rules\n ↓\nRepository\n ↓\nDatabase\n@McpTool(description = \"Refund an eligible order\")\npublic RefundResult refundOrder(String orderId) {\n\n    return refundService.refund(orderId);\n}\n```\n\nThe MCP layer becomes an interface.\n\nYour existing business service remains responsible for the actual business rules.\n\nThis keeps the architecture clean.\n\nOne of the strongest ways to think about MCP is as an integration boundary.\n\nInstead of:\n\n```\nAI\n ↓\nEverything\n```\n\nuse:\n\n```\nAI\n ↓\nMCP\n ↓\nControlled Capabilities\n```\n\nThe MCP layer becomes a contract between AI applications and external systems.\n\n```\nAI Application\n      ↓\nMCP\n      ↓\nCRM\n```\n\nor:\n\n```\nAI Application\n      ↓\nMCP\n      ↓\nPayment System\nAI Application\n      ↓\nMCP\n      ↓\nInternal Developer Platform\n```\n\nNow combine everything from this series:\n\n```\n                              User\n                                ↓\n                         Spring Boot API\n                                ↓\n                           ChatClient\n                                ↓\n                              Agent\n                                ↓\n             ┌──────────────────┼──────────────────┐\n             ↓                  ↓                  ↓\n           Memory              RAG              MCP Client\n             ↓                  ↓                  ↓\n         PostgreSQL          pgvector        ┌─────┼─────┐\n                                             ↓     ↓     ↓\n                                           CRM  GitHub  Search\n                                           MCP    MCP     MCP\n                                             ↓     ↓     ↓\n                                           APIs  APIs   APIs\n```\n\nAround the system:\n\n```\nAuthentication\nAuthorization\nTenant Isolation\nObservability\nAudit Logging\nRate Limiting\nGuardrails\nHuman Approval\n```\n\nThis is a strong foundation for production-oriented AI applications.\n\nMCP becomes particularly useful when you have:\n\n```\nMultiple AI applications\n        ↓\nShared tools\n        ↓\nShared integrations\nSales Agent\nSupport Agent\nDeveloper Agent\nInternal Assistant\n```\n\nall need access to:\n\n```\nCRM\nGitHub\nInternal APIs\nDocumentation\n```\n\nInstead of implementing each integration separately:\n\n```\nAgent A → CRM Integration\nAgent B → CRM Integration\nAgent C → CRM Integration\n```\n\nyou can create:\n\n```\nCRM MCP Server\n```\n\nand allow multiple AI applications to consume it.\n\nMCP isn't automatically required for every AI application.\n\nIf your application has:\n\n```\nOne Agent\n ↓\nOne Tool\n ↓\nOne Internal Service\n```\n\ndirect Spring AI tool calling may be simpler.\n\n```\nChatClient\n ↓\n@Tool\n ↓\nOrderService\n```\n\nIntroducing an MCP server could add unnecessary infrastructure.\n\nA useful rule is:\n\nUse MCP when standardization, reuse, separation, or interoperability provides real value.\n\nDon't introduce another protocol simply because it is popular.\n\nA simple comparison:\n\n| Approach | Best suited for | \n|---|---|\n| Spring AI `@Tool` | Local application capabilities | \n| MCP | Shared/external capabilities | \n| RAG | Knowledge retrieval | \n| Memory | Conversation context | \n| Agent | Dynamic decision-making | \n\nThey are not mutually exclusive.\n\nA production system may use all of them:\n\n```\nAgent\n ├── Local Spring AI Tools\n ├── MCP Tools\n ├── RAG\n └── Memory\n```\n\nOur AI architecture has evolved throughout this series.\n\nWe started with:\n\n```\nLLM\n ↓\nResponse\n```\n\nThen:\n\n```\nLLM\n ↓\nRAG\n ↓\nKnowledge\nLLM\n ↓\nTools\n ↓\nActions\nLLM\n ↓\nTools\n ↓\nMemory\n ↓\nAgent\n```\n\nAnd now:\n\n```\nAgent\n ↓\nMCP\n ↓\nExternal Capabilities\n```\n\nThe architecture is becoming increasingly modular.\n\nRemember it this way:\n\n```\nLLM\n=\nReason\n\nRAG\n=\nRetrieve Knowledge\n\nMemory\n=\nRemember Context\n\nTool Calling\n=\nInvoke Capabilities\n\nMCP\n=\nStandardize Capability Access\n\nSpring Boot\n=\nBusiness Application\n\nAgent\n=\nCoordinate Decisions\n```\n\nTogether:\n\n```\nLLM\n+\nRAG\n+\nMemory\n+\nTools\n+\nMCP\n+\nBusiness Logic\n=\nProduction AI Application\n```\n\nMCP gives AI applications a standardized way to interact with external tools and resources.\n\nThe key ideas are:\n\nThe architecture can now look like:\n\n```\n                         User\n                           ↓\n                        Agent\n                           ↓\n        ┌──────────────────┼──────────────────┐\n        ↓                  ↓                  ↓\n      Memory              RAG             MCP Client\n        ↓                  ↓                  ↓\n    Conversation       Vector DB       MCP Servers\n                                             ↓\n                              ┌──────────────┼──────────────┐\n                              ↓              ↓              ↓\n                             CRM          GitHub         Internal APIs\n```\n\nThe important shift is this:\n\n```\nBefore:\n\nAI Application\n ↓\nCustom Integrations\n ↓\nExternal Systems\nAI Application\n ↓\nMCP Client\n ↓\nStandardized Protocol\n ↓\nMCP Servers\n ↓\nExternal Capabilities\n```\n\nMCP doesn't make your AI application automatically intelligent.\n\nIt gives your AI application a **standardized way to connect to capabilities**.\n\nAnd when you combine MCP with Spring AI's:\n\n```\nChatClient\n+\nTool Calling\n+\nRAG\n+\nMemory\n+\nAgents\n```\n\nyou get a powerful foundation for building modular AI applications in Java.\n\nWe've now connected our AI agent to external capabilities.\n\nBut another challenge appears:\n\n```\nOne Agent\n      ↓\nMultiple MCP Servers\n      ↓\nMultiple Tools\n      ↓\nMultiple Decisions\n```\n\nHow do we control which tools an agent can access?\n\nHow do we handle permissions?\n\nHow do we observe agent behavior?\n\nHow do we evaluate whether an agent is making the right decisions?\n\nAnd how do we build reliable AI workflows instead of simply hoping the model does the right thing?\n\nThat takes us into the next stage of AI engineering:\n\n**Building Production-Ready AI Agents with Spring AI — Guardrails, Evaluation, Observability, and Human-in-the-Loop Workflows.**", "url": "https://wpnews.pro/news/model-context-protocol-with-spring-ai-building-mcp-clients-and-servers-in-java", "canonical_source": "https://dev.to/ayshriv/model-context-protocol-with-spring-ai-building-mcp-clients-and-servers-in-java-2146", "published_at": "2026-09-19 07:37:01+00:00", "updated_at": "2026-09-19 07:54:27.280139+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "developer-tools", "ai-tools", "ai-infrastructure"], "entities": ["Model Context Protocol", "Spring AI", "Spring Boot", "Java", "GitHub", "Slack", "PostgreSQL", "Google Calendar"], "alternates": {"html": "https://wpnews.pro/news/model-context-protocol-with-spring-ai-building-mcp-clients-and-servers-in-java", "markdown": "https://wpnews.pro/news/model-context-protocol-with-spring-ai-building-mcp-clients-and-servers-in-java.md", "text": "https://wpnews.pro/news/model-context-protocol-with-spring-ai-building-mcp-clients-and-servers-in-java.txt", "jsonld": "https://wpnews.pro/news/model-context-protocol-with-spring-ai-building-mcp-clients-and-servers-in-java.jsonld"}}