How MCP Standardizes AI Tool Calls with JSON‑RPC and Spring AI

1 Introduction

With the rapid development of AI, technologies such as Retrieval‑Augmented Generation (RAG) and function calling have enhanced large language model (LLM) conversational capabilities, but implementing function calling is complex because each system requires custom adapters.

MCP was created to provide a standardized, efficient, and reliable way for AI systems to call external tools.

2 Execution Flow

Before diving into details, it is useful to understand the typical user‑LLM interaction flow:

When a user asks "How is the weather in Beijing today?", the program packages the question and a pre‑identified tool list into a prompt for the LLM. The LLM, using function‑calling capabilities, selects the appropriate tool, returns a structured call, and the program invokes the tool, sending the result back to the LLM for the final answer.

Before MCP, each new system required developers to write custom adapters for tool calls, leading to duplicated effort. MCP decouples system and tool interaction, encapsulating call logic in MCP client and server components, with SDKs available for multiple languages.

3 MCP Architecture

3.1 Architecture Design

MCP follows a classic client‑server (C/S) model:

host : the AI agent that receives user requests and interacts with the LLM.

client : implements MCP rules and communicates with the MCP server.

server : implements tool logic and returns results to the client.

3.2 Core Functions

MCP standardizes three main elements of LLM interaction: resources, tools, and prompts. Important functions include:

Resource : data such as files or database entries that the client can read.

Tools : functions that the LLM can invoke.

Prompt : templates that guide the LLM to perform specific tasks.

Sampling : allows the server to request data from the LLM for sampling.

4 MCP Communication Principles

4.1 JSON‑RPC

MCP uses JSON‑RPC as its underlying protocol, a lightweight remote‑call format based on JSON.

Request structure

{
  jsonrpc: "2.0",
  id: number | string,
  method: string,
  params?: object
}

Response structure

{
  jsonrpc: "2.0",
  id: number | string,
  result?: object,
  error?: {
    code: number,
    message: string,
    data?: unknown
  }
}

Compared with HTTP, JSON‑RPC is more concise, enforces JSON format, and is suited for lightweight micro‑service or IoT scenarios.

4.2 Communication Modes

MCP supports several transport methods:

STDIO

Both client and server run as processes on the same machine, communicating via stdin/stdout. Advantages: no external dependencies, fast IPC, offline use. Disadvantages: synchronous, limited concurrency, no multi‑process support.

SSE

Server‑Sent Events provide a streaming, server‑to‑client channel while the client uses HTTP for requests. Typical flow:

Client sends an HTTP request to /sse to establish a connection.

Client requests tools/list to obtain the available tool list.

When invoking a tool, the client posts to tools/call with method and arguments; the server replies via the SSE channel.

Because SSE is asynchronous and non‑blocking, it improves throughput but can suffer from connection drops and context loss. A newer "streamable http" mode addresses these issues.

5 Lifecycle

After the client and server connect, the client immediately requests the tool list, demonstrating MCP's dynamic plug‑in capability. The following sections show a Spring AI demo of the client workflow.

5.1 Environment Setup

Define a tool on the server side:

/** Build a tool that gets weather by city */
@Tool(name = "getWeather", description = "Get weather by city")
public String getWeather(String city) {
    return new String(city.getBytes(), StandardCharsets.UTF_8) + " 天气为晴天 25℃";
}

Spring AI automatically registers methods annotated with @Tool into the ToolCallbackProvider. Configure the MCP server address in application.yml:

spring:
  ai:
    mcp:
      client:
        sse:
          connections:
            server1: # sse server
              url: http://127.0.0.1:8080

5.2 Retrieve Tool List

When the application starts, Spring injects McpClient and ToolCallbackProvider, which call tools/list via JSON‑RPC to obtain all available tools.

public Mono<McpSchema.ListToolsResult> listTools(String cursor) {
    return this.mcpSession.sendRequest(
        McpSchema.METHOD_TOOLS_LIST,
        new McpSchema.PaginatedRequest(cursor),
        LIST_TOOLS_RESULT_TYPE_REF);
}

5.3 Invoke Tool

When the user asks "How is the weather in Beijing?", the client sends the user input and tool list to the LLM. The LLM selects the getWeather tool, and the client calls tools/call:

public Mono<McpSchema.CallToolResult> callTool(McpSchema.CallToolRequest request) {
    return this.mcpSession.sendRequest(
        McpSchema.METHOD_TOOLS_CALL,
        request,
        CALL_TOOL_RESULT_TYPE_REF);
}

The LLM response contains a tool call payload such as:

{
  "assistantMessage": {
    "toolCalls": [{
      "id": "call_b4a9cb0f04a3495d941b71",
      "type": "function",
      "name": "spring_ai_mcp_client_server1_getWeather",
      "arguments": "{\"city\": \"北京\"}"
    }],
    "chatGenerationMetadata": {
      "finishReason": "TOOL_CALLS"
    }
  }
}

The client executes the tool, receives the result, and sends the combined context back to the LLM until a final answer is produced.

6 Conclusion

MCP provides a standardized interaction protocol for AI models, reducing integration effort and offering a clear path for future extensions. However, it introduces higher token consumption due to frequent LLM calls and lacks mature security measures against prompt injection.