In the previous article, we explored how to build AI agents with Spring AI using:
\nLLMs\n ↓\nRAG\n ↓\nTool Calling\n ↓\nMemory\n ↓\nAgent WorkflowsTool calling gives an AI application the ability to interact with external capabilities.
\nBut another problem appears as AI systems become larger.
\nImagine you have:
\nCustomer Service Agent\n ↓\nOrder APIs\nPayment APIs\nCRM APIs\nKnowledge Base\nEmail ServiceAnd another application has:
\nSales Agent\n ↓\nCRM\nCalendar\nEmail\nCustomer DatabaseAnd another has:
\nDeveloper Agent\n ↓\nGit Repository\nIssue Tracker\nCI/CD\nDocumentationIf every AI application implements every integration differently, the architecture quickly becomes difficult to maintain.
\nThis is where Model Context Protocol (MCP) becomes interesting.
\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.
\nIn this article, we'll build a mental model for MCP and explore how Java developers can use it with Spring AI.
\nMCP stands for:
\nModel Context Protocol
\nAt a high level, MCP standardizes how an AI application communicates with external capabilities such as:
\nTools\nResources\nPromptsInstead of every AI application inventing its own integration mechanism:
\nAI Application\n ↓\nCustom Tool Integration\n ↓\nCRMwe can have:
\nAI Application\n ↓\nMCP Client\n ↓\nMCP Protocol\n ↓\nMCP Server\n ↓\nCRMThe MCP server exposes capabilities through a standardized interface.
\nThe AI application doesn't need to understand every internal implementation detail of the external system.
\nSuppose you build an AI assistant that needs access to:
\nGitHub\nSlack\nPostgreSQL\nGoogle Calendar\nInternal APIs\nFile SystemsWithout a standard protocol, your application might contain:
\nGitHub Integration\nSlack Integration\nPostgreSQL Integration\nCalendar Integration\nInternal API IntegrationEach integration may have its own:
\nAuthentication\nTool Schema\nRequest Format\nResponse Format\nConnection Management\nError HandlingNow imagine another AI application needs the same capabilities.
\nYou may end up rebuilding many of the same integrations.
\nMCP addresses this by creating a common protocol for AI applications and external servers.
\nConceptually:
\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 DatabaseThis is one of the main ideas behind MCP.
\nThis distinction is important.
\nMCP is not:
\nAn AI modelIt is a protocol for connecting AI applications with capabilities.
\nThink of the stack like this:
\nLLM\n ↓\nAI Application\n ↓\nMCP Client\n ↓\nMCP Protocol\n ↓\nMCP Server\n ↓\nTools / Resources\n ↓\nExternal SystemThe LLM performs reasoning.
\nThe MCP layer provides standardized communication.
\nThe external system performs the actual operation.
\nMCP introduces two important roles.
\nThe MCP client lives inside the AI application.
\nIts responsibility is to connect to MCP servers and interact with the capabilities they expose.
\nFor example:
\nSpring Boot AI Application\n ↓\nMCP Client\n ↓\nWeather MCP ServerThe client can discover and use the server's available capabilities.
\nThe MCP server exposes capabilities.
\nFor example:
\nWeather MCP Server\nTools:\ngetWeather()\ngetForecast()\nResources:\nweather://cities\nPrompts:\nweather-analysisThe server is responsible for implementing those capabilities.
\nSpring AI provides Boot starters and APIs for both sides of this architecture.
\nA simplified architecture looks like:
\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 APIFor example:
\nUser:\nWhat's the weather in Paris?The AI application can discover a weather tool exposed by an MCP server.
\nThe flow becomes:
\nUser\n ↓\nLLM\n ↓\nMCP Tool\n ↓\nWeather MCP Server\n ↓\nWeather API\n ↓\nTool Result\n ↓\nLLM\n ↓\nFinal AnswerAt this point, you might ask:
\n"Isn't this just tool calling?"
\nThere is an important distinction.
\nTraditional Spring AI tool calling can expose application methods directly:
\n@Tool\npublic String getWeather(String city) {\n return weatherService.getWeather(city);\n}Your application owns the tool.
\nWith MCP:
\nAI Application\n ↓\nMCP Client\n ↓\nRemote MCP Server\n ↓\nToolThe tool can live outside the application.
\nThis creates a cleaner separation between:
\nAI Applicationand:
\nCapability ProviderSpring AI integrates MCP tools into its tool-calling architecture, allowing applications to consume tools exposed by MCP servers.
\nOne of the most important MCP capabilities is the tool.
\nA tool represents an action that an AI application can invoke.
\nFor example:
\ngetWeather()\ncreateTicket()\nsearchCustomers()\ngetOrder()\nsendEmail()A weather server might expose:
\ngetTemperature(city)A CRM server might expose:
\nfindCustomer(email)\ncreateLead(customer)\nupdateLead(leadId)A developer server might expose:
\nsearchRepository(query)\ngetBuildStatus()\ncreateIssue(title)The MCP client can discover these tools and make them available to the AI application.
\nMCP is not limited to actions.
\nIt can also expose resources.
\nA resource represents information that an MCP client can access.
\nFor example:
\ncustomer://123\norder://ORD-10291\nfile://README.md\ndatabase://schemaThink of the distinction as:
\nTool\n=\nDo something\nResource\n=\nAccess somethingFor example:
\nTool:\ncreateTicket()\nResource:\ncustomer://123A server can expose both.
\nMCP also supports prompts.
\nA server can provide reusable prompt templates for specific tasks.
\nFor example:
\nPrompt:\nanalyze-customer\nInput:\ncustomerIdOr:
\nPrompt:\nsummarize-order\nInput:\norderIdThis allows prompt templates to become part of the server-provided capabilities rather than being hardcoded independently in every client.
\nSpring AI's MCP support includes annotations for tools, resources, and prompts.
\nLet's build a simple MCP server.
\nImagine a weather service.
\nOur application already has:
\n@Service\npublic class WeatherService {\n public String getTemperature(String city) {\n return "22°C";\n }\n}We can expose this capability through an MCP tool.
\nWith Spring AI's annotation-based MCP support:
\n@Service\npublic class WeatherTools {\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 return weatherService.getTemperature(city);\n }\n}The MCP annotation model allows Spring services to expose capabilities as MCP operations.
\nFor a Spring Boot application, Spring AI provides MCP server starters.
\nFor example:
\n<dependency>\n <groupId>org.springframework.ai</groupId>\n <artifactId>spring-ai-starter-mcp-server-webmvc</artifactId>\n</dependency>You can configure the server to use Streamable HTTP:
\nspring.ai.mcp.server.protocol=STREAMABLESpring 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.
\nConceptually:
\nSpring Boot\n ↓\nMCP Server\n ↓\nTool Registry\n ↓\n@McpTool\n ↓\nWeatherService\n ↓\nWeather APIThe server exposes the tool through the MCP protocol.
\nThe client doesn't need to know how the weather service works internally.
\nIt only needs to understand:
\nTool Name\nDescription\nInput SchemaNow let's create the other side.
\nSuppose our AI application needs to consume the weather MCP server.
\nAdd the MCP client starter:
\n<dependency>\n <groupId>org.springframework.ai</groupId>\n <artifactId>spring-ai-starter-mcp-client</artifactId>\n</dependency>Then configure the MCP server connection.
\nFor example, using Streamable HTTP:
\nspring:\n ai:\n mcp:\n client:\n streamable-http:\n connections:\n weather-server:\n url: http://localhost:8080Spring AI can connect to the configured MCP server and discover its tools.
\nOnce the MCP client discovers the server's tools, those tools can be integrated into Spring AI's tool-calling architecture.
\nConceptually:
\n@Bean\nCommandLineRunner demo(\n ChatClient chatClient,\n ToolCallbackProvider mcpTools) {\n return args -> {\n String response = chatClient\n .prompt("What's the weather in Paris?")\n .tools(mcpTools)\n .call()\n .content();\n System.out.println(response);\n };\n}This is a powerful abstraction.
\nThe application doesn't need to manually implement every weather function.
\nThe MCP server provides the capability.
\nThe MCP client discovers it.
\nSpring AI makes the discovered tools available to the model.
\nThe flow becomes:
\nUser\n ↓\nChatClient\n ↓\nLLM\n ↓\nMCP Tool\n ↓\nMCP Client\n ↓\nMCP Server\n ↓\nWeather API\n ↓\nTool Result\n ↓\nLLM\n ↓\nAnswerSpring AI's current MCP documentation demonstrates this client pattern using ToolCallbackProvider.
One of the interesting capabilities of MCP is tool discovery.
\nInstead of hardcoding:
\nTool A\nTool B\nTool Cthe client can connect to an MCP server and discover what capabilities it provides.
\nFor example:
\nMCP Server\n ↓\ntools/list\n ↓\ngetWeather()\ngetForecast()\nsearchAlerts()The AI application can then make these tools available to the model.
\nThis creates a more modular architecture.
\nNow imagine our AI assistant needs multiple capabilities.
\nWe could have:
\nAI Application\n │\n ├── MCP Client\n │\n ├── Weather Server\n │\n ├── CRM Server\n │\n ├── GitHub Server\n │\n └── Internal API ServerThe architecture becomes:
\n AI Agent\n │\n MCP Client\n │\n ┌──────────────┼──────────────┐\n ↓ ↓ ↓\n Weather MCP CRM MCP GitHub MCP\n ↓ ↓ ↓\n Weather API CRM API GitHub APIThe AI application can consume tools from multiple MCP servers.
\nThis is one reason MCP becomes useful as an AI system grows.
\nNow connect this to the previous article.
\nWe previously had:
\nAgent\n ↓\nTools\n ↓\nAPIsWith MCP, we can move the tools outside the application boundary:
\nAgent\n ↓\nMCP Client\n ↓\nMCP Servers\n ├── CRM\n ├── Payments\n ├── Search\n └── Internal APIsThe resulting architecture becomes:
\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 APIThis creates a modular tool ecosystem.
\nLet's compare the two approaches.
\nChatClient\n ↓\n@Tool\n ↓\nService\n ↓\nDatabaseEverything lives inside the application.
\nChatClient\n ↓\nMCP Client\n ↓\nMCP Server\n ↓\nService\n ↓\nDatabaseThe capability provider can be separated from the AI application.
\nThis can be useful when:
\nOne useful architectural pattern is:
\nBusiness System\n ↓\nMCP Server\n ↓\nAI ApplicationsFor example:
\nCRM\n ↓\nCRM MCP Server\n ↓\n ├── Sales Agent\n ├── Support Agent\n └── Internal AssistantInstead of implementing CRM integration separately in every AI application, the MCP server becomes the standardized capability layer.
\nMCP doesn't replace RAG.
\nThey solve different problems.
\nRAG:
\nRetrieve relevant knowledgeMCP:
\nConnect AI applications to external capabilitiesYou can combine them:
\n Agent\n ↓\n ┌───────────┼───────────┐\n ↓ ↓ ↓\n RAG MCP Tools Memory\n ↓ ↓ ↓\n Vector DB External APIs DatabaseFor example:
\nUser:\nCan I refund order ORD-10291?The agent could:
\n1. MCP → Get order information\n2. RAG → Retrieve refund policy\n3. Agent → Compare the two\n4. Return answerThis gives the model both:
\nLive Data\n+\nBusiness KnowledgeMemory can also coexist with MCP.
\nFor example:
\nUser:\nUse my preferred delivery address.\nAgent:\nWhich address?\nUser:\nThe one I used last time.The application may use:
\nMemory\n ↓\nPrevious Addresswhile MCP provides:
\nOrder Service\n ↓\nUpdate Delivery AddressThe complete flow becomes:
\nAgent\n ├── Memory\n ├── RAG\n └── MCP\n ├── Orders\n ├── Payments\n └── CRMThis is becoming a much more complete agent architecture.
\nMCP supports multiple ways for clients and servers to communicate.
\nCommon options include:
\nSTDIO\nSSE\nStreamable HTTP\nStateless Streamable HTTPFor local process-based integrations:
\nAI Application\n ↓\nSTDIO\n ↓\nMCP Server ProcessFor network-based applications:
\nAI Application\n ↓\nHTTP\n ↓\nMCP ServerIn Spring AI 2.x, Streamable HTTP is the current HTTP-oriented approach, while SSE has been deprecated in favor of Streamable HTTP.
\nA simple way to think about it:
\nApplication\n ↓\nLocal MCP ProcessUseful for local integrations and process-based communication.
\nApplication\n ↓\nNetwork\n ↓\nMCP ServerUseful when the MCP server runs as an independent service.
\nClient\n ↓\nRequest\n ↓\nServer\n ↓\nResponseThis can be useful for stateless, cloud-native service architectures.
\nThe right transport depends on deployment and communication requirements.
\nThis is extremely important.
\nAn MCP server may expose powerful capabilities:
\nreadCustomer()\ncreateInvoice()\nrefundPayment()\ndeleteUser()Simply exposing those tools does not make them safe.
\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.
\nA production architecture should look like:
\nClient\n ↓\nAuthentication\n ↓\nAuthorization\n ↓\nMCP Server\n ↓\nTool\n ↓\nBusiness LogicNot:
\nInternet\n ↓\nMCP Server\n ↓\nDangerous ToolImagine an MCP server exposes:
\ngetCustomer()\nupdateCustomer()\ndeleteCustomer()Different users should have different capabilities.
\nFor example:
\nREAD\n ↓\ngetCustomer()\nWRITE\n ↓\nupdateCustomer()\nDESTRUCTIVE\n ↓\ndeleteCustomer()Your security layer should determine whether the caller is allowed to invoke each capability.
\nThe model should never be considered the authorization layer.
\nThe application must enforce it.
\nMCP becomes particularly interesting in SaaS environments.
\nSuppose:
\nTenant A\n ↓\nCRM MCP Serverand:
\nTenant B\n ↓\nCRM MCP ServerThe MCP layer must preserve tenant context.
\nA request might carry:
\ntenantId\nuserId\nroles\npermissionsThe server can then enforce:
\nAuthentication\n ↓\nTenant Resolution\n ↓\nAuthorization\n ↓\nTool Execution\n ↓\nTenant-Scoped DataThis is especially important for tools such as:
\nsearchCustomers()\ngetInvoices()\nsearchDocuments()\ncreateTicket()A model must never be able to use a tool to cross tenant boundaries.
\nExternal tools can fail.
\nFor example:
\nAgent\n ↓\nMCP Tool\n ↓\nCRM API\n ↓\nTimeoutYour application needs controlled failure behavior.
\nFor example:
\nTool Failure\n ↓\nCapture Error\n ↓\nReturn Structured Result\n ↓\nAgent\n ↓\nRetry / Alternative Tool / Final ResponseThe agent might decide:
\nCRM unavailable.\nTry cached customer information.Or:
\nUnable to retrieve the customer's order.\nPlease try again later.The important part is that failures should be observable and controlled.
\nWhen MCP is added to an agent architecture, your observability requirements increase.
\nYou may need to track:
\nMCP Server\nMCP Client\nTool Name\nTool Arguments\nRequest ID\nLatency\nStatus\nErrors\nRetries\nModel Calls\nToken UsageA useful trace could look like:
\nUser Request\n ↓\nLLM Call\n ↓\nMCP Tool Discovery\n ↓\nTool Call\n ↓\nCRM API\n ↓\nTool Result\n ↓\nLLM Call\n ↓\nFinal ResponseWithout tracing, debugging multi-server agent systems can become difficult.
\nThis is another important principle.
\nSuppose you have:
\npublic RefundResult refundPayment(\n String orderId,\n BigDecimal amount) {\n ...\n}You shouldn't move all business logic into an MCP handler.
\nInstead:
\nMCP Tool\n ↓\nApplication Service\n ↓\nBusiness Rules\n ↓\nRepository\n ↓\nDatabaseFor example:
\n@McpTool(description = "Refund an eligible order")\npublic RefundResult refundOrder(String orderId) {\n return refundService.refund(orderId);\n}The MCP layer becomes an interface.
\nYour existing business service remains responsible for the actual business rules.
\nThis keeps the architecture clean.
\nOne of the strongest ways to think about MCP is as an integration boundary.
\nInstead of:
\nAI\n ↓\nEverythinguse:
\nAI\n ↓\nMCP\n ↓\nControlled CapabilitiesThe MCP layer becomes a contract between AI applications and external systems.
\nFor example:
\nAI Application\n ↓\nMCP\n ↓\nCRMor:
\nAI Application\n ↓\nMCP\n ↓\nPayment Systemor:
\nAI Application\n ↓\nMCP\n ↓\nInternal Developer PlatformNow combine everything from this series:
\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 APIsAround the system:
\nAuthentication\nAuthorization\nTenant Isolation\nObservability\nAudit Logging\nRate Limiting\nGuardrails\nHuman ApprovalThis is a strong foundation for production-oriented AI applications.
\nMCP becomes particularly useful when you have:
\nMultiple AI applications\n ↓\nShared tools\n ↓\nShared integrationsFor example:
\nSales Agent\nSupport Agent\nDeveloper Agent\nInternal Assistantall need access to:
\nCRM\nGitHub\nInternal APIs\nDocumentationInstead of implementing each integration separately:
\nAgent A → CRM Integration\nAgent B → CRM Integration\nAgent C → CRM Integrationyou can create:
\nCRM MCP Serverand allow multiple AI applications to consume it.
\nMCP isn't automatically required for every AI application.
\nIf your application has:
\nOne Agent\n ↓\nOne Tool\n ↓\nOne Internal Servicedirect Spring AI tool calling may be simpler.
\nFor example:
\nChatClient\n ↓\n@Tool\n ↓\nOrderServiceIntroducing an MCP server could add unnecessary infrastructure.
\nA useful rule is:
\nUse MCP when standardization, reuse, separation, or interoperability provides real value.
\nDon't introduce another protocol simply because it is popular.
\nA simple comparison:
\n| 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.
\nA production system may use all of them:
\nAgent\n ├── Local Spring AI Tools\n ├── MCP Tools\n ├── RAG\n └── MemoryOur AI architecture has evolved throughout this series.
\nWe started with:
\nLLM\n ↓\nResponseThen:
\nLLM\n ↓\nRAG\n ↓\nKnowledgeThen:
\nLLM\n ↓\nTools\n ↓\nActionsThen:
\nLLM\n ↓\nTools\n ↓\nMemory\n ↓\nAgentAnd now:
\nAgent\n ↓\nMCP\n ↓\nExternal CapabilitiesThe architecture is becoming increasingly modular.
\nRemember it this way:
\nLLM\n=\nReason\nRAG\n=\nRetrieve Knowledge\nMemory\n=\nRemember Context\nTool Calling\n=\nInvoke Capabilities\nMCP\n=\nStandardize Capability Access\nSpring Boot\n=\nBusiness Application\nAgent\n=\nCoordinate DecisionsTogether:
\nLLM\n+\nRAG\n+\nMemory\n+\nTools\n+\nMCP\n+\nBusiness Logic\n=\nProduction AI ApplicationMCP gives AI applications a standardized way to interact with external tools and resources.
\nThe key ideas are:
\nMCP Client connects an AI application to MCP servers.
\nMCP Server exposes tools, resources, and prompts.
\nTools allow actions to be performed.
\nResources provide access to information.
\nPrompts can provide reusable prompt templates.
\nThe architecture can now look like:
\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 APIsThe important shift is this:
\nBefore:\nAI Application\n ↓\nCustom Integrations\n ↓\nExternal SystemsWith MCP:
\nAI Application\n ↓\nMCP Client\n ↓\nStandardized Protocol\n ↓\nMCP Servers\n ↓\nExternal CapabilitiesMCP doesn't make your AI application automatically intelligent.
\nIt gives your AI application a standardized way to connect to capabilities.
\nAnd when you combine MCP with Spring AI's:
\nChatClient\n+\nTool Calling\n+\nRAG\n+\nMemory\n+\nAgentsyou get a powerful foundation for building modular AI applications in Java.
\nWe've now connected our AI agent to external capabilities.
\nBut another challenge appears:
\nOne Agent\n ↓\nMultiple MCP Servers\n ↓\nMultiple Tools\n ↓\nMultiple DecisionsHow do we control which tools an agent can access?
\nHow do we handle permissions?
\nHow do we observe agent behavior?
\nHow do we evaluate whether an agent is making the right decisions?
\nAnd how do we build reliable AI workflows instead of simply hoping the model does the right thing?
\nThat takes us into the next stage of AI engineering:
\nBuilding Production-Ready AI Agents with Spring AI — Guardrails, Evaluation, Observability, and Human-in-the-Loop Workflows.
","headings":[{"level":1,"text":"Model Context Protocol with Spring AI: Building MCP Clients and Servers in Java","id":"model-context-protocol-with-spring-ai-building-mcp-clients-and-s"},{"level":1,"text":"What Is MCP?","id":"what-is-mcp"},{"level":1,"text":"Why MCP Exists","id":"why-mcp-exists"},{"level":1,"text":"MCP Is Not an LLM","id":"mcp-is-not-an-llm"},{"level":1,"text":"MCP Client vs MCP Server","id":"mcp-client-vs-mcp-server"},{"level":2,"text":"MCP Client","id":"mcp-client"},{"level":2,"text":"MCP Server","id":"mcp-server"},{"level":1,"text":"The Basic MCP Architecture","id":"the-basic-mcp-architecture"},{"level":1,"text":"MCP and Traditional Tool Calling","id":"mcp-and-traditional-tool-calling"},{"level":1,"text":"MCP Tools","id":"mcp-tools"},{"level":1,"text":"MCP Resources","id":"mcp-resources"},{"level":1,"text":"MCP Prompts","id":"mcp-prompts"},{"level":1,"text":"Building an MCP Server with Spring AI","id":"building-an-mcp-server-with-spring-ai"},{"level":1,"text":"Creating the MCP Server","id":"creating-the-mcp-server"},{"level":1,"text":"What Happens Inside the MCP Server?","id":"what-happens-inside-the-mcp-server"},{"level":1,"text":"Building an MCP Client","id":"building-an-mcp-client"},{"level":1,"text":"Connecting MCP Tools to ChatClient","id":"connecting-mcp-tools-to-chatclient"},{"level":1,"text":"MCP Tool Discovery","id":"mcp-tool-discovery"},{"level":1,"text":"Multiple MCP Servers","id":"multiple-mcp-servers"},{"level":1,"text":"MCP + Spring AI Agents","id":"mcp-spring-ai-agents"},{"level":1,"text":"MCP vs Direct Tool Calling","id":"mcp-vs-direct-tool-calling"},{"level":2,"text":"Direct Spring AI Tool","id":"direct-spring-ai-tool"},{"level":2,"text":"MCP Tool","id":"mcp-tool"},{"level":1,"text":"MCP Server as a Capability Layer","id":"mcp-server-as-a-capability-layer"},{"level":1,"text":"MCP + RAG","id":"mcp-rag"},{"level":1,"text":"MCP + Memory","id":"mcp-memory"},{"level":1,"text":"MCP Transports","id":"mcp-transports"},{"level":1,"text":"STDIO vs HTTP","id":"stdio-vs-http"},{"level":3,"text":"STDIO","id":"stdio"},{"level":3,"text":"Streamable HTTP","id":"streamable-http"},{"level":3,"text":"Stateless Streamable HTTP","id":"stateless-streamable-http"},{"level":1,"text":"MCP Security","id":"mcp-security"},{"level":1,"text":"MCP Tool Authorization","id":"mcp-tool-authorization"},{"level":1,"text":"MCP and Multi-Tenant Systems","id":"mcp-and-multi-tenant-systems"},{"level":1,"text":"MCP Error Handling","id":"mcp-error-handling"},{"level":1,"text":"MCP Observability","id":"mcp-observability"},{"level":1,"text":"MCP Doesn't Replace Your Business Logic","id":"mcp-doesn-t-replace-your-business-logic"},{"level":1,"text":"MCP as an Integration Boundary","id":"mcp-as-an-integration-boundary"},{"level":1,"text":"A Complete Spring AI + MCP Architecture","id":"a-complete-spring-ai-mcp-architecture"},{"level":1,"text":"When Should You Use MCP?","id":"when-should-you-use-mcp"},{"level":1,"text":"When You Don't Need MCP","id":"when-you-don-t-need-mcp"},{"level":1,"text":"Direct Tools vs MCP","id":"direct-tools-vs-mcp"},{"level":1,"text":"The Bigger Picture","id":"the-bigger-picture"},{"level":1,"text":"A Mental Model for MCP","id":"a-mental-model-for-mcp"},{"level":1,"text":"Final Takeaways","id":"final-takeaways"},{"level":2,"text":"What's Next?","id":"what-s-next"}]}}