Model Context Protocol MCP: Connecting Claude to Your World

Model Context Protocol MCP is Anthropic’s answer to one of the most frustrating problems in practical AI development: the inability of language models to reach outside a conversation. For most of AI’s history, models lived in isolation — they could read your prompt and generate a response, but had no way to access your file system, query a live database, call an external API, or retrieve real-time data. Every time a developer wanted to add an extra capability to an AI assistant, they had to build a custom connector from scratch. And then build another one for the next system. And another after that.

The Model Context Protocol (MCP) was introduced by Anthropic in November 2024 to permanently solve this problem. MCP is an open standard — a universal, agreed-upon way for AI systems like Claude to connect to external tools, data sources, and services. Instead of writing one-off integrations, developers implement MCP once and gain access to an entire ecosystem of ready-made connectors. Think of it as USB-C for AI: one port, unlimited devices.

In this article, we will explain what MCP is, why it was needed, how it works under the hood, and — most importantly for this series — how you, as a Java developer, can build your own MCP server to connect Claude to your data and services.

• 1. The Problem MCP Solves
• 2. What Is MCP? A Clear Definition
• 3. The Architecture: Hosts, Clients, and Servers
• 4. The Three Primitives: Tools, Resources, and Prompts
• 5. How MCP Works Step by Step
• 6. MCP Transport: Local vs Remote Servers
• 7. Getting Started: Connecting Claude Desktop to an MCP Server
• 8. Calling MCP-Enabled Tools from Java via the Claude API
• 9. Building Your First MCP Server in Java
• 10. Integrating MCP Servers into Spring Boot
• 11. Conclusion

1. The Problem MCP Solves

Before MCP, every AI integration was a bespoke engineering project. If you wanted Claude to query your PostgreSQL database, you had to write a custom function-calling wrapper. If you then also wanted it to read files from your file system, that was a separate integration. If you wanted it to talk to your GitHub repository and your Slack workspace, that was two more. Every combination of AI model and external system demanded its own unique glue code.

This is known as the M×N integration problem. If you have M different AI applications and N different tools or data sources, you could end up building M times N separate integrations — most of them reinventing the same patterns. The result was duplicated effort, inconsistent quality, and a maintenance burden that grew with every new tool added to the stack.

MCP transforms the M×N problem into an M+N problem. Tool creators build one MCP server for their system. AI application developers build a single MCP client within their application. Once both sides implement the protocol, they connect automatically — regardless of which AI model or which tool is involved. The protocol handles the handshake, the capability discovery, and the message format for everyone.

Real-World Analogy: Before USB, every peripheral — keyboard, mouse, printer — needed its own port and its own driver. USB standardised everything: one port, one protocol, any device. MCP does the same for AI integrations. One protocol connects any AI model to any data source or tool, with no custom connectors needed for each combination.

2. What Is MCP? A Clear Definition

MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems. Using MCP, AI applications like Claude can connect to data sources such as local files and databases, tools such as search engines and calculators, and workflows such as specialized prompts — enabling them to access key information and perform actions in the world.

MCP was introduced by Anthropic in November 2024 and quickly became the de facto standard for AI tool integration. In March 2025, OpenAI adopted MCP and integrated it across its products, including the ChatGPT desktop app. Google DeepMind followed. By early 2026, thousands of community-built MCP servers existed on GitHub, covering everything from Google Drive and Notion to Kubernetes and Figma. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, ensuring it remains an open, vendor-neutral standard.

MCP is built on top of JSON-RPC 2.0 and reuses the design patterns of the Language Server Protocol (LSP) — the same technology that powers IntelliSense in VS Code. This means it was designed from day one to be bidirectional, stateful, and efficient — exactly the right foundations for AI agents that need to interact with complex, real-world systems.

3. The Architecture: Hosts, Clients, and Servers

MCP uses a clear client-server architecture with three distinct roles. Understanding these roles is essential before you start building.

3.1 Host

The host is the application that the user interacts with. Claude Desktop is the primary host application from Anthropic. Other hosts include Cursor, Windsurf, VS Code with extensions, and custom agents built by developers. The host is responsible for presenting the AI interface to the user and coordinating the connections to MCP servers. When you configure MCP servers in Claude Desktop, that configuration file tells the host which MCP servers to connect to on startup.

3.2 Client

The MCP client lives inside the host application and manages the connection to a single MCP server. There is a one-to-one relationship: one client per server. The client handles the connection lifecycle — connecting, discovering capabilities, sending requests, and receiving responses. You do not usually build or interact with the client directly. It is the plumbing inside the host that makes everything work.

3.3 Server

The MCP server is the program you build. It exposes your data, tools, and workflows to AI applications over the MCP protocol. Your server runs as a separate process and communicates with the host via either standard input/output (stdio) for local servers or HTTP for remote servers. When Claude needs to query your database, read a file, or call your API, it sends a request to your MCP server. Your server handles the request and returns the result. The official Java SDK from Anthropic, along with the community, makes it straightforward to build MCP servers, as we will see in Section 7.

Interview Insight: A common interview question is: ‘What is the difference between an MCP client and an MCP server?’ The simple answer is: the server exposes capabilities (tools, data, prompts), and the client connects to the server on behalf of the host application (like Claude Desktop). The host is the user-facing AI application. The server is what you build to connect your own systems to that host.

4. The Three Primitives: Tools, Resources, and Prompts

MCP organizes everything an AI can do through a server into three clean primitives. Each primitive serves a different purpose and is controlled by a different party in the system. Knowing which primitive to use for a given use case is a fundamental skill in MCP design.

4.1 Tools (Model-Controlled)

Tools are functions that the AI model can call to perform actions. The model decides when to call a tool based on the user’s request and its own reasoning. A tool might query a database, call an external API, read a file, or execute a calculation. Tools are the most powerful primitive because they allow the AI to take actions in the world — not just read information but do things.

Each tool is defined with a name, a human-readable description that helps the model decide when to use it, and a JSON Schema that specifies the input parameters. When the model calls a tool, the MCP server receives the call with the provided arguments and returns a result.

4.2 Resources (Application-Controlled)

Resources are data sources that the host application provides to the AI as context. Unlike tools, resources are not triggered by the model — they are provided by the application. Think of resources as read-only data that the AI can reference during a conversation. Examples include a file from your file system, a database document, or a configuration object. Resources have a URI, a MIME type, and content. They are similar to GET endpoints in a REST API — they provide data without performing significant side-effect operations.

4.3 Prompts (User-Controlled)

Prompts are pre-defined templates or workflows that users can invoke from the host application. They are the least commonly used primitives for beginners, but they become valuable in production systems. A prompt might encapsulate a multi-step workflow — for example, a prompt template called ‘generate-test-suite’ that automatically structures the conversation to produce a full test suite for a given piece of code. The user explicitly invokes a prompt; the model does not choose to use it on its own.

Primitive	Who Controls It / When to Use
Tools	Model-controlled. Use when the AI needs to take an action: query a DB, call an API, write a file, trigger a process.
Resources	Application-controlled. Use for read-only context the AI should be aware of: documents, configs, records.
Prompts	User-controlled. Use for reusable, structured workflows that users explicitly invoke from the host application.

5. How MCP Works Step by Step

Understanding the sequence of events in an MCP interaction demystifies the system as a whole. Here is what happens from the moment a user types a question to the moment Claude returns a final answer that drew on an external system.

Step 1 — Startup and Connection: When the host application (for example, Claude Desktop) starts, it reads the MCP configuration file and connects to each configured MCP server. The connection uses either stdio (for local processes) or HTTP with Server-Sent Events (for remote servers).

Step 2 — Capability Discovery: The client asks each server what it offers. Each server responds with a list of its tools, resources, and prompts. The host registers these capabilities and makes them available for the AI model to reference during the conversation.

Step 3 — User Request: The user sends a message. For example, ‘What is the status of order ORD-1042?’

Step 4 — Model Reasoning: Claude reads the user’s message and sees that it has access to a tool called get_order_status. Claude decides to call that tool with the argument orderId = ‘ORD-1042’.

Step 5 — Tool Call: The MCP client routes Claude’s tool call to the correct MCP server. The server receives the request, executes its logic (a database query, in this case), and returns the result.

Step 6 — Final Response: Claude receives the tool result and incorporates it into its final answer to the user. The user sees a clean, natural language response: ‘Order ORD-1042 is currently in SHIPPED status, expected delivery Friday.’

This entire flow happens in a fraction of a second. From the user’s perspective, Claude just answered their question. Under the hood, MCP enabled Claude to access a live database and retrieve real, up-to-date data.

6. MCP Transport: Local vs Remote Servers

MCP supports two transport modes. Understanding which to use in a given context is a practical design decision every developer building with MCP will face.

6.1 stdio Transport (Local Servers)

For local MCP servers, communication happens over standard input and output. The host application starts the MCP server as a child process and communicates with it by writing to stdin and reading from stdout. This is the simplest setup and works well for development, personal tools, and servers that run on the same machine as the host application. Claude Desktop uses stdio by default for local server configurations.

6.2 HTTP Transport (Remote Servers)

For remote MCP servers, communication happens over HTTP. The server exposes an endpoint, and the client connects over the network. This is the right approach for production deployments where the MCP server runs on a cloud instance, serves multiple users or applications, and needs authentication. Anthropic added first-class remote MCP support in early 2025. Remote servers are deployed behind OAuth for access control, and most major enterprise AI clients support remote servers by 2026.

Transport Type	When to Use It
stdio (local)	Development, personal tools, running server on same machine as host. Simple setup, no auth needed.
HTTP (remote)	Production, multi-user, cloud deployment. Served over HTTPS, secured with OAuth.

7. Getting Started: Connecting Claude Desktop to an MCP Server

Before we write Java code, let us understand the basic configuration. Claude Desktop is configured to connect to MCP servers through a JSON config file. On macOS, this file lives at ~/Library/Application Support/Claude/claude_desktop_config.json. On Windows, it is at %APPDATA%/Claude/claude_desktop_config.json.

Here is an example that connects Claude Desktop to two pre-built MCP servers: one for file system access and one for a local PostgreSQL database.

// MCP server defined in JSON config for Claude Desktop (mcp_config.json) 
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/your/project/folder"
      ]
    },
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://localhost/mydb"
      ]
    }
  }
}

// After saving this config, Claude Desktop connects to both MCP servers on startup. 
// Claude can now read files from your project folder and query your Postgres database.

After saving this configuration and restarting Claude Desktop, Claude will automatically connect to both servers on startup. You can then ask Claude to read a file from your project folder or query your database in natural language, and it will do so through the MCP protocol.

Anthropic provides several official pre-built MCP servers you can use immediately: file system access, PostgreSQL, Google Drive, Slack, GitHub, Git, and Puppeteer (for browser automation). These official servers are a great starting point before you build your own.

8. Calling MCP-Enabled Tools from Java via the Claude API

If you are building a Java application that uses the Anthropic Claude API — rather than Claude Desktop — MCP tools still work in essentially the same way. Claude receives the list of available tools in the API request (either defined inline or discovered from connected MCP servers), decides which tools to call based on the user’s query, and returns a multi-turn response that includes the tool call and the final answer.

The key insight here is that tool calling in the Anthropic API follows the same core pattern as MCP tool invocations. You define a tool with a name, description, and input schema. Claude calls it when relevant. Your application executes the tool and returns the result. This is the Claude API-level view of the same mechanism that MCP formalizes as a protocol.

// Conceptual Java code — calling an MCP-enabled tool via the Anthropic Claude API 
// In practice, MCP tool calls happen inside the conversation loop.  

// Step 1: Define the user's query (Claude will decide which MCP tool to call) 
String userMessage = "Read the file project-notes.txt and summarise it in 3 bullet points."; 

// Step 2: Send the message to Claude — Claude will call the filesystem MCP tool internally 
// The tool result is returned as part of Claude's multi-turn conversation response. ClaudeResponse response = claudeClient.sendMessage(userMessage);  

// Step 3: The final text response contains the summarised output System.out.println(response.getText()); 

// Output: A 3-bullet summary of the contents of project-notes.txt

In a real Java application using the Anthropic Java SDK, you would define your tools in the API request, handle the tool_use content block in Claude’s response, execute the tool logic in your Java code, and send the tool result back in the next turn of the conversation. The official Anthropic Java SDK makes this pattern straightforward with typed response handling.

Interview Insight: Interviewers often ask: ‘How does MCP differ from traditional function calling?’ The key difference is protocol standardisation. Function calling is model-specific — you define tools in the format each model provider requires. MCP is a universal protocol — you define tools once in the MCP server, and any MCP-compatible AI client can discover and use them without changes to the tool definition.

9. Building Your First MCP Server in Java

Anthropic and the community maintain an official Java SDK for MCP. This makes building MCP servers in Java a first-class experience, which is excellent news for developers in the JVM ecosystem. Let us walk through the process of building a minimal MCP server that exposes a single tool: get_order_status.

The official Maven dependency is io.modelcontextprotocol:mcp. At the time of writing, the version is 0.10.0. Add it to your pom.xml, and you have everything you need.

// Minimal MCP server skeleton in Java using the official Anthropic Java SDK
// Reference: https://github.com/modelcontextprotocol/java-sdk

import io.modelcontextprotocol.server.McpServer;
import io.modelcontextprotocol.server.McpSyncServer;
import io.modelcontextprotocol.server.transport.StdioServerTransport;
import io.modelcontextprotocol.spec.McpSchema;

public class SimpleMcpServer {

    public static void main(String[] args) {

        // Step 1 — Create server info
        McpSchema.Implementation serverInfo =
            new McpSchema.Implementation("my-java-server", "1.0.0");

        // Step 2 — Define a simple tool: get_order_status
        McpSchema.Tool orderTool = new McpSchema.Tool(
            "get_order_status",
            "Looks up the current status of a customer order by order ID.",
            """
            {
              "type": "object",
              "properties": {
                "orderId": {
                  "type": "string",
                  "description": "The order ID to look up"
                }
              },
              "required": ["orderId"]
            }
            """
        );

        // Step 3 — Handle tool calls
        McpSyncServer server = McpServer.sync(new StdioServerTransport())
            .serverInfo(serverInfo)
            .tool(orderTool, (exchange, args2) -> {
                String orderId = (String) args2.get("orderId");
                // In real code: query a database here
                String status = "Order " + orderId + " is currently: SHIPPED";
                return new McpSchema.CallToolResult(
                    List.of(new McpSchema.TextContent(status)), false
                );
            })
            .build();

        server.connect(new StdioServerTransport());
    }
}

This is a fully working MCP server skeleton. When you run this Java program, it starts an MCP server on stdio. You can point Claude Desktop to this server by adding its configuration to your claude_desktop_config.json, and Claude will be able to call the get_order_status tool immediately. In a real system, you would replace the stub response with an actual database query.

10. Integrating MCP Servers into Spring Boot

For Java developers with existing Spring Boot applications, the most natural approach is to expose your service logic as MCP tools directly from within the Spring context. This lets you reuse your existing repositories, services, and beans without rewriting any business logic.

The spring-ai-mcp library, part of the Spring AI project, provides Spring-native abstractions for building MCP servers. You define your tools as Spring beans, and the library handles the server lifecycle, the transport, and the MCP protocol. Here is how to expose a customer lookup from a Spring Boot application as an MCP tool.

// Connecting an MCP server to a Spring Boot application
// Dependency (Maven): io.modelcontextprotocol:mcp:0.10.0

@SpringBootApplication
public class McpSpringApp {

    public static void main(String[] args) {
        SpringApplication.run(McpSpringApp.class, args);
    }

    // Expose an MCP tool as a Spring bean
    @Bean
    public McpSyncServerFeatures.SyncToolSpecification customerLookupTool(
            CustomerRepository customerRepo) {

        McpSchema.Tool tool = new McpSchema.Tool(
            "get_customer_by_email",
            "Retrieves customer details from the database by email address.",
            """
            {
              "type": "object",
              "properties": {
                "email": {
                  "type": "string",
                  "description": "Customer email address"
                }
              },
              "required": ["email"]
            }
            """
        );

        return new McpSyncServerFeatures.SyncToolSpecification(tool, (exchange, args) -> {
            String email = (String) args.get("email");
            Customer customer = customerRepo.findByEmail(email)
                .orElseThrow(() -> new RuntimeException("Customer not found"));
            String result = "Name: " + customer.getName() + ", Plan: " + customer.getPlan();
            return new McpSchema.CallToolResult(
                List.of(new McpSchema.TextContent(result)), false
            );
        });
    }
}

With this setup, your Spring Boot application doubles as an MCP server. Any MCP-compatible AI host — Claude Desktop, a custom agent, or another application — can connect to it and use the get_customer_by_email tool. This is a powerful pattern for enterprises that want to give Claude access to their internal business data without exposing raw database connections.

10.1 Exposing Resources from a Java MCP Server

Beyond tools, MCP servers can also expose resources — read-only data that the host application can inject into Claude’s context. A common use case is exposing internal documentation or configuration files so Claude always has the latest reference material available during a conversation.

// MCP Resources example — exposing a file as a resource from a Java MCP server
// Resources are read-only data the host app injects into Claude's context.

McpSyncServer server = McpServer.sync(new StdioServerTransport())
    .serverInfo(new McpSchema.Implementation("docs-server", "1.0.0"))
    .resource(
        new McpSchema.Resource(
            "file:///docs/api-reference.md",          // URI for this resource
            "API Reference",                           // Human-readable name
            "text/markdown",                           // MIME type
            "The full internal API reference documentation."
        ),
        (exchange, request) -> {
            // Read the file content from disk
            String content = Files.readString(Path.of("/docs/api-reference.md"));
            return new McpSchema.ReadResourceResult(
                List.of(new McpSchema.TextResourceContents(
                    "file:///docs/api-reference.md",
                    "text/markdown",
                    content
                ))
            );
        }
    )
    .build();

With this resource defined, Claude Desktop can make the contents of api-reference.md available as context in any conversation where it is connected to this server. The host controls when to inject the resource — it does not require Claude to call a tool.

11. Conclusion

The Model Context Protocol (MCP) is one of the most important developments in practical AI engineering since the introduction of function calling. It solves a real and painful problem — the fragmentation of AI integrations — with a clean, well-designed, vendor-neutral standard that the entire industry has adopted.

In this article, we covered why the M×N integration problem demanded a universal protocol, what MCP is and how it works at the architecture level, the three primitives — tools, resources, and prompts — and when to use each, the step-by-step flow of an MCP interaction from user request to final response, the two transport modes (stdio for local, HTTP for remote), how to connect Claude Desktop to pre-built MCP servers, and how to build your own MCP server in Java and Spring Boot.

For Java developers, MCP is particularly exciting because a first-class Java SDK exists and integrates naturally with Spring Boot. You do not need to switch to Python or TypeScript to build production MCP servers. Your existing repositories, services, and business logic can be exposed as MCP tools with remarkably little new code.

As AI moves from chatbots to fully agentic systems that take real-world actions, MCP is the protocol that makes those actions safe, predictable, and maintainable. Understanding it deeply is a genuine career differentiator in 2026.