d4rtht3ll3ctus' root vault

MCP Data Layer Handshake

4 min read

  1. Initialization (MCP Lifecycle Management) the client sends an initialize request to establish the connection and negotiate supported features.

    1. Protocol Version Negotiation: The protocolVersion field (e.g., “2025-06-18”) ensures both client and server are using compatible protocol versions. This prevents communication errors that could occur when different versions attempt to interact. If a mutually compatible version is not negotiated, the connection should be terminated.
    2. Capability Discovery: The capabilities object allows each party to declare what features they support, including which primitives they can handle (tools, resources, prompts) and whether they support features like notifications. This enables efficient communication by avoiding unsupported operations.
    3. Identity Exchange: The clientInfo and serverInfo objects provide identification and versioning information for debugging and compatibility purposes. During initialization, the AI application’s MCP client manager establishes connections to configured servers and stores their capabilities for later use. The application uses this information to determine which servers can provide specific types of functionality (tools, resources, prompts) and whether they support real-time updates

  2. Tool Discovery (MCP Primitives) Now that the connection is established, the client can discover available tools by sending a tools/list request. This request is fundamental to MCP’s tool discovery mechanism — it allows clients to understand what tools are available on the server before attempting to use them. Each tool object in the response includes several key fields:

  • name: A unique identifier for the tool within the server’s namespace. This serves as the primary key for tool execution and should follow a clear naming pattern (e.g., calculator_arithmetic rather than just calculate)
  • title: A human-readable display name for the tool that clients can show to users
  • description: Detailed explanation of what the tool does and when to use it
  • inputSchema: A JSON Schema that defines the expected input parameters, enabling type validation and providing clear documentation about required and optional parameters The AI application fetches available tools from all connected MCP servers and combines them into a unified tool registry that the language model can access. This allows the LLM to understand what actions it can perform and automatically generates the appropriate tool calls during conversations.
  1. Tool Execution (MCP Primitives) The client can now execute a tool using the tools/call method. This demonstrates how MCP primitives are used in practice: after discovering available tools, the client can invoke them with appropriate arguments. The request structure includes several important components:
    1. name: Must match exactly the tool name from the discovery response (weather_current). This ensures the server can correctly identify which tool to execute.
    2. arguments: Contains the input parameters as defined by the tool’s inputSchema. In this example:
    • location: “San Francisco” (required parameter)
    • units: “imperial” (optional parameter, defaults to “metric” if not specified)
    1. JSON-RPC Structure: Uses standard JSON-RPC 2.0 format with unique id for request-response correlation.

The response demonstrates MCP’s flexible content system:

1. content Array: Tool responses return an array of content objects, allowing for rich, multi-format responses (text, images, resources, etc.)
2. Content Types: Each content object has a `type` field. In this example, `"type": "text"` indicates plain text content, but MCP supports various content types for different use cases.
3. Structured Output: The response provides actionable information that the AI application can use as context for language model interactions.

4. Real-time Updates (MCP Notifications) When the server’s available tools change—such as when new functionality becomes available, existing tools are modified, or tools become temporarily unavailable—the server can proactively notify connected clients:

Key Features of MCP Notifications

  1. No Response Required: Notice there’s no id field in the notification. This follows JSON-RPC 2.0 notification semantics where no response is expected or sent.
  2. Capability-Based: This notification is only sent by servers that declared "listChanged": true in their tools capability during initialization (as shown in Step 1).
  3. Event-Driven: The server decides when to send notifications based on internal state changes, making MCP connections dynamic and responsive.

Graph View

Backlinks