Skip to content

5.4 Lifecycle

The Model Context Protocol defines a lifecycle for client-server connections, as shown in figure 5.4-1, ensuring clear capability negotiation and consistent state management throughout the session.

  • Initialization: Negotiation of supported features and agreement on the protocol version

  • Operation: Standard communication according to the agreed protocol

  • Shutdown: Clean and orderly termination of the connection

The MCP protocol enables three different kinds of function calls:

  • Tools: MCP tools are server-side functions provided by MCP servers that allow LLMs to perform actions and operations on external systems which can modify states or trigger processes.

  • Resources: MCP resources provide a structured way for MCP servers to expose read-only data to LLMs. Typical use cases include requests like "Get customer details for account XYZ" or "Fetch the latest webcam image", receiving existing content without performing actions.

  • Prompts: MCP prompts are reusable instruction templates provided by MCP servers that guide LLMs to handle specific tasks with consistent expertise, combining these pre-defined instructions with user input to create complete, contextualized requests.

All server-side functions share the characteristic that the agent first requests a list of available functions and then selects and invokes the appropriate one.

Figure 5.4-1: Lifecycle phases

Figure 5.4-1: Lifecycle phases

5.4.1 Illustrative simple API wrapper scenario

A very simple scenario for the introduction of MCP is "basic API wrapping". In this case, more complex function calls, authentication and authorization, as well as security measures are not considered. The focus is on the core functionality, specifically the operational aspects of the MCP protocol.

Figure 5.4.1-1 illustrates a simple MCP call flow. In this case, a local weather station API is connected to an AI Agent using MCP. A user can interact with the AI Agent to discuss the current indoor climate, effectively serving as a local weather chatbot.

Note: For querying passive data such as temperature, MCP's 'resource' function could be utilized. However, this example uses the 'tools' function for simplicity and because tools are available on most MCP servers. The flow diagram illustrates only the successful execution path, omitting error or alternative paths.

Involved Services and Applications

  • AI App – provides a web interface that allows the user to send prompts to the AI Agent, for example, "How warm is it right now?".
  • AI Agent – receives user requests and responds using an LLM. In this process, the AI Agent may decide to use tools that connect it to other systems or services.
  • MCP Server – The MCP server manages the AI Agent’s requests, executes functions, and returns results. It implements a set of functions that call the underlying service APIs. These functions are additionally described with human-readable context for the LLM.
  • API – The service API of the local weather station.

Call Flow Description

  • The user asks via the AI App: "How warm is it right now?" using an HTTP POST request to the "/run" endpoint of the AI Agent.

  • The AI Agent receives the request and forwards it to its LLM for processing (not shown in diagram). The AI Agent's instructions for the LLM specify that it may use available tools and invoke them via MCP.

  • If the LLM decides to use MCP functions, the AI Agent requests a list of available tools from the MCP Server using an HTTP POST request to the "/message" endpoint along with a "session_id". Note: Session handling between AI Agent and MCP Server as well as between MCP Server and API is handled on HTTP-level.

  • The MCP Server responds to the request with "HTTP 202 Accepted".

  • The MCP Server sends the list of available tools along with a detailed description in human-readable text to the AI Agent in a server-sent event. The RPC message is shown in figure 5.4.1-2.

  • The AI Agent chooses with the help of its LLM the most appropriate tool from the list in order to fulfill the user request (not shown in diagram).

  • The AI Agent calls the selected tool on the MCP Server using an HTTP POST request. The RPC message contained within is shown in Figure 5.4.1-3.

  • The MCP Server responds to the request with "HTTP 202 Accepted".

  • The MCP Server calls the local weather station API with an HTTP GET request. The result contains a complete set of different local climate values.

  • The MCP Server sends the complete set of data to the AI Agent in a server-sent event.

  • The AI Agent processes the received data and, with the help of its LLM, formulates a textual response for the user (not shown in diagram).

  • The AI App receives the textual response from the AI Agent in HTTP 200 OK response.

Figure 5.4.1-1: Call flow example from AI Application to API

Figure 5.4.1-1: Call flow example from AI Application to API 

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "tools": [
      {
        "name": "get_climate",
        "description": "Returns the current climate data from a weather station with different sensors.\n\nSensor Data Structure Overview:\nThe data comes from a multi-zone environmental sensor system and is formatted as a nested dictionary (similar to JSON). Each top-level key represents a physical location or sensor module. The values are sub-dictionaries containing measurements and status information for that location.\n\n1. General Structure\n{\n  \"Location/Sensor\": {\n    \"Measurement1\": value1,\n    \"Measurement2\": value2,\n    ...\n  },\n  ...\n}\n\n2. Locations and Typical Measurements\nIndoor\nTypical keys:\n- Temperature data (Temperature, min_temp, max_temp, temp_trend)\n- Air quality (CO2)\n- Humidity (Humidity)\n- Noise level (Noise)\n- Pressure (Pressure, AbsolutePressure, pressure_trend)\n- Timestamps for temp extremes (date_max_temp, date_min_temp)\n- Wi-Fi status (wifi_status)\n- Timestamp of last update (When)\n\nBedroom\nTypical keys:\n- Temperature data (including trend and min/max)\n- Humidity\n- CO₂ concentration\n- Battery status (battery_vp, battery_percent)\n- Radio frequency connection status (rf_status)\n- Timestamp (When)\n\nBalcony\nTypical keys:\n- Temperature data (with trend and min/max)\n- Humidity\n- Battery and RF status\n- Timestamp\n\nRain\nTypical keys:\n- Rainfall (Rain, sum_rain_1, sum_rain_24)\n- Battery and RF status\n- Timestamp\n\n3. General Characteristics\n- Values are either numeric or categorical (e.g., 'temp_trend': 'up', 'pressure_trend': 'down').\n- Time values are Unix timestamps.\n- Sensors report both environmental data and system status (connectivity, power, etc.).\n- Trend indicators describe simple directional change over time (e.g., 'up', 'down', 'stable').",
        "inputSchema": {
          "properties": {},
          "title": "get_climateArguments",
          "type": "object"
        }
      }
    ]
  }
}

Figure 5.4.1-2: JSON-RPC message example sent from the MCP Server to the AI Agent listing available tools. In this example there is only one tool available.

{
  "jsonrpc": "2.0",
  "id": 8,
  "method": "tools/call",
  "params": {
    "name": "get_climate",
    "arguments": {}
  }
}

Figure 5.4.1-3: JSON-RPC message example sent from the AI Agent to the MCP Server to invoke a tool from the list.