Processes that drives MCP Servers
As per anthropic article, one statement for MCP can be :
Instead of maintaining separate connectors for each data source, developers can now build against a standard protocol. As the ecosystem matures, AI systems will maintain context as they move between different tools and datasets, replacing today’s fragmented integrations with a more sustainable architecture.
This article explains how a Model Context Protocol (MCP) server facilitates tool invocation between Large Language Models and external systems using JSON-RPC, from initial user prompt to final response generation.
Let’s get started :
1. Prompt Ingestion: How the LLM Interprets the User Prompt
When a user submits a prompt to an LLM, the model begins by breaking down the input text into smaller units called tokens, which represent meaningful components like words, subwords, or parts of words. These tokens are processed through multiple layers of neural networks that analyse the semantic meaning and intent behind the user’s request.
The model identifies the instruction type, any contextual information provided, and the expected output format.
For example: When a user asks “What’s the weather like in Pune?”, the LLM tokenise this into discrete units and processes them to understand that this is a query requesting current weather information for a specific location
Meanwhile, the model also evaluates whether the prompt contains requests that might require external tool assistance. The LLM analyses the query against its training data and identifies gaps in its knowledge that could be filled by external resources or real-time data.
2. Tool Selection: How the LLM Decides Whether to Invoke a Tool
The tool selection process represents a critical decision-making phase where the LLM determines if external functionality is needed and, if so, which specific tool to use. The model acts as a coordinator, understanding the user’s query and deciding whether an external function needs to be called.
In MCP implementations, the LLM receives information about available tools directly within its context window as part of the prompt. This information typically includes tool names, descriptions of their functions, and the parameters they accept. The prompt structure provides the model with a comprehensive list of available capabilities, allowing it to match user intent against tool descriptions.
The LLM employs its reasoning capabilities to analyse the query and compare its interpretation to the descriptions of available tools, looking for the best functional match.
For example: if a user asks about current weather conditions, the model would identify a weather API tool as the most appropriate option based on the tool’s description and the query’s requirements. This selection process involves evaluating multiple factors including the tool’s described functionality, required parameters, and expected output format.
Modern reasoning frameworks like ReAct (Reasoning and Action) enable models to think through problems step-by-step before selecting the appropriate tool.
3. Parameter Extraction and Formatting: Using OpenAPI Schema
Once the LLM selects a tool, it must determine the appropriate arguments using the OpenAPI schema that defines the tool’s parameter structure. Each tool includes a JSON schema that describes the input parameters, their data types, and validation requirements. This schema serves as a contract between the LLM and the tool, ensuring proper parameter formatting.
The OpenAPI specification supports various data types including strings, numbers, integers, booleans, arrays, and objects. The schema also defines required properties, default values, and enumerated options where applicable.
For example: A weather tool might require a “location” parameter as a string and optionally accept a “units” parameter with enumerated values like “celsius” or “fahrenheit”.
When the user asks “What’s the weather in Pune?”, the model extracts “Pune” as the location parameter value.
The LLM analyses the user’s input to extract relevant information that matches the schema requirements. It identifies specific values mentioned in the prompt and maps them to the appropriate parameter names.
The LLM formats the extracted parameters as a JSON object that conforms to the tool’s schema definition. This process includes type conversion, format validation, and ensuring that all required parameters are included.
4. Tool Invocation: JSON-RPC Communication via MCP Server
The tool invocation phase involves structured communication between the LLM client and the MCP server using JSON-RPC 2.0 protocol. MCP uses JSON-RPC as its wire format, with the transport layer responsible for converting MCP protocol messages into JSON-RPC format for transmission.
The JSON-RPC request structure includes several key components: a “jsonrpc” field set to “2.0”, a unique “id” for tracking responses, a “method” field specifying the tool to invoke, and a “params” object containing the extracted arguments.
For example, a weather tool invocation might look like:
{"jsonrpc": "2.0", "id": 1, "method": "get_weather", "params": {"location": "Pune"}}
MCP supports multiple transport mechanisms for delivering these JSON-RPC messages. The stdio transport uses standard input/output for communication, ideal for local processes, while the Streamable HTTP transport uses HTTP POST requests for client-to-server messages. All messages must be UTF-8 encoded and follow the JSON-RPC 2.0 specification.
The MCP client maintains a stateful connection with the server and handles the protocol-level details of message exchange. When the LLM decides to invoke a tool, the client constructs the appropriate JSON-RPC request and transmits it to the server. The client also manages error handling, timeout scenarios, and response correlation using the request ID.
5. Execution: MCP Server Processing and Business Logic
Upon receiving the JSON-RPC request, the MCP server processes the message and executes the corresponding business logic. The server first validates the incoming request format, ensuring it conforms to JSON-RPC 2.0 specifications and contains all required fields. It then identifies the requested method and extracts the parameters for processing.
The MCP server architecture typically includes request handling components, session orchestration, and context stores for managing tool execution. The server maps the method name to the appropriate tool implementation and validates parameters against the tool’s schema. This validation ensures that all required parameters are present and that data types match the expected format.
During execution, the server performs the actual business logic associated with the tool. This might involve querying external APIs, accessing databases, performing calculations, or interacting with other systems.
For example : For a weather tool, the server would make HTTP requests to weather service APIs, process the response data, and format it for return to the client.
The server also handles error conditions that may arise during execution. If the tool encounters problems such as invalid parameters, external service failures, or timeout conditions, the server generates appropriate JSON-RPC error responses with standardised error codes and descriptive messages.
Common error codes include -32602 for invalid parameters and -32603 for internal errors.
6. Response Handling: Returning Results to the LLM
After successful tool execution, the MCP server constructs a JSON-RPC response containing the results. The response message includes the same ID as the original request, ensuring proper correlation, along with a “result” field containing the tool’s output. For error conditions, the response includes an “error” object with code, message, and optional data fields.
The response format follows JSON-RPC 2.0 specifications and must be properly structured for the MCP client to process.
For example : A successful weather tool response might look like:
{"jsonrpc": "2.0", "id": 1, "result": {"temperature": 62, "conditions": "Partly cloudy"}}
The server ensures that response data is serialised correctly and transmitted back through the established transport mechanism. The MCP client receives the response and performs validation to ensure message integrity. It correlates the response with the original request using the ID field and handles any error conditions that may have occurred. The client then extracts the result data and makes it available to the LLM for incorporation into the final response.
Important : Error handling during this phase is crucial for maintaining system reliability. If the server returns an error response, the client processes the error information and may attempt retry logic or fallback mechanisms depending on the error type. The client also manages timeout scenarios where responses are not received within expected timeframes.
7. Final Response Generation: Merging Tool Results
The final phase involves the LLM incorporating the tool results into a coherent, user-facing response. The model receives the structured data returned by the tool and processes it alongside its original understanding of the user’s query. This integration process requires the LLM to synthesize external data with its internal knowledge to generate a comprehensive answer.
The LLM uses the tool results as additional context for response generation. Rather than simply returning the raw tool output, the model interprets the data and presents it in a natural, conversational format that addresses the user’s original question.
For example: Instead of returning raw JSON weather data, the model might say “The current weather in Pune is 62°F with partly cloudy conditions”.
This synthesis process demonstrates the LLM’s ability to act as an intelligent coordinator between users and external systems. The model maintains conversational context while incorporating real-time or external data, creating responses that feel natural and informative. The LLM may also provide additional context, explanations, or follow-up suggestions based on the tool results.
In short, the full flowchart is shown as below :
Thanks for reaching this far, forget now to subscribe to the below newsletters for more such amazing contents xD
Happy Learning :)
