MCP Protocol Specification - Deep Dive

Overview

The Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. It uses JSON-RPC 2.0 as the base messaging format.

Inspired by: Language Server Protocol (LSP) - which standardizes language support across development tools

Goal: Standardize how to integrate additional context and tools into AI application ecosystem

Protocol Version

Current Version: 2025-11-25

Versioning Format: YYYY-MM-DD (last date of backwards-incompatible changes)

Revisions:

Architecture

Communication Model

┌─────────────────────────────────────────────────────────┐
│                  MCP Protocol                    │
│              (JSON-RPC 2.0)                   │
├─────────────────────────────────────────────────────────┤
│                                                  │
│  ┌──────────────┐              ┌────────────┐   │
│  │     Host      │  ←───────→   │  Server    │   │
│  │ (LLM App)   │              │ (Context/  │   │
│  │              │              │   Tools)   │   │
│  └──────────────┘              └────────────┘   │
│                                                  │
│  Host initiates connection                         │
│  Server provides context/tools/prompts                │
│  Bidirectional JSON-RPC messages                  │
│                                                  │
└─────────────────────────────────────────────────────────┘

Roles

Components

┌─────────────────────────────────────────────────────────┐
│              MCP Protocol Layers                  │
├─────────────────────────────────────────────────────────┤
│                                                  │
│  1. Base Protocol                     │
│     └─ JSON-RPC 2.0 message format             │
│                                                  │
│  2. Lifecycle Management              │
│     └─ Initialization, capability negotiation,       │
│        session control                             │
│                                                  │
│  3. Authorization (HTTP-based)               │
│     └─ Auth framework for HTTP transports          │
│                                                  │
│  4. Server Features (MAY implement)          │
│     ├─ Resources: Context and data                 │
│     ├─ Prompts: Template messages                 │
│     └─ Tools: Functions to execute                 │
│                                                  │
│  5. Client Features (MAY implement)          │
│     ├─ Sampling: Server-initiated LLM interactions  │
│     ├─ Roots: Filesystem/URI boundaries          │
│     └─ Elicitation: User prompts from server       │
│                                                  │
│  6. Utilities                               │
│     ├─ Configuration                              │
│     ├─ Progress tracking                         │
│     ├─ Cancellation                              │
│     ├─ Error reporting                           │
│     └─ Logging                                  │
│                                                  │
└─────────────────────────────────────────────────────────┘

Message Types

1. Requests

Direction: Client → Server OR Server → Client

Structure:

{
  "jsonrpc": "2.0",
  "id": "string | number",
  "method": "string",
  "params": {
    "[key: string]": "unknown"
  }
}

Requirements:

2. Responses

Direction: Server → Client OR Client → Server

Result Response (success):

{
  "jsonrpc": "2.0",
  "id": "string | number",
  "result": {
    "[key: string]": "unknown"
  }
}

Requirements:

Error Response (failure):

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

Requirements:

3. Notifications

Direction: Client → Server OR Server → Client (one-way)

Structure:

{
  "jsonrpc": "2.0",
  "method": "string",
  "params": {
    "[key: string]": "unknown"
  }
}

Requirements:

Server Features

Resources

Purpose: Provide context and data for user or AI model

URI Scheme: protocol://path format

Examples:

Methods:

Content Types:

Prompts

Purpose: Templated messages and workflows for users

Template Format:

Example:

{
  "name": "analyze_dashboard",
  "description": "Navigate to dashboard, capture screenshot, extract metrics",
  "arguments": [
    {"name": "dashboard_url", "required": true}
  ],
  "template": [
    "Navigate to {{dashboard_url}}",
    "Take screenshot",
    "Extract metrics via OCR",
    "Return formatted report"
  ]
}

Methods:

Tools

Purpose: Functions for AI model to execute

Tool Schema:

{
  "name": "tool_name",
  "description": "What this tool does",
  "inputSchema": {
    "type": "object",
    "properties": {
      "param1": {
        "type": "string",
        "description": "Parameter description"
      }
    },
    "required": ["param1"]
  }
}

Methods:

My Implementation:

Client Features

Sampling

Purpose: Server-initiated agentic behaviors and recursive LLM interactions

Allows server to:

Example Use Case:

Roots

Purpose: Define URI or filesystem boundaries for operations

Examples:

Prevents:

Elicitation

Purpose: Server-initiated requests for additional information from users

Use Cases:

JSON Schema Usage

Supported Dialects

Default Dialect: JSON Schema 2020-12 (when no $schema field)

Explicit Dialect: Any valid JSON Schema dialect via $schema field

Supported (at least):

Example Schema

Default dialect (2020-12):

{
  "type": "object",
  "properties": {
    "name": {"type": "string"},
    "age": {"type": "integer", "minimum": 0}
  },
  "required": ["name"]
}

Explicit dialect (draft-07):

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "name": {"type": "string"},
    "age": {"type": "integer", "minimum": 0}
  },
  "required": ["name"]
}

Validation Requirements

Metadata

`_meta` Property

Purpose: Reserved field for additional metadata in interactions

Format: {prefix/name}

Prefix Rules:

Reserved Prefixes:

NOT Reserved (examples):

`icons` Property

Purpose: Standardized visual identifiers for resources, tools, prompts

Icon Object:

{
  "src": "URI (required)",
  "mimeType": "optional MIME type",
  "sizes": ["48x48", "96x96"],
  "theme": "light | dark"
}

Allowed `src` types:

Supported MIME Types (MUST support):

Should Also Support:

Icon Security:

Security & Trust

Key Principles

1. User Consent and Control

2. Data Privacy

3. Tool Safety

4. LLM Sampling Controls

Implementation Guidelines

Implementors SHOULD:

Version Negotiation

Process

Failure Handling

My Implementation Alignment

✅ What I Implemented Correctly

⚠️ Areas for Improvement

Transport Layers

STDIO (Standard I/O)

Use Case: Local communication via stdin/stdout

Auth: Retrieve from environment

Authorization: NOT required (no HTTP)

HTTP

Use Case: Remote communication over HTTP/HTTPS

Auth: MCP Authorization Framework

Authorization: REQUIRED for non-public servers

Negotiation

Multiple Versions: Clients and servers MAY support multiple protocol versions simultaneously

Agreement: MUST agree on single version for session

Official SDKs

Key Insights

1. Protocol Flexibility

MCP is modular - components are optional:

This allows implementations to support exactly what they need.

2. Bidirectional Communication

Unlike pure client-server protocols, MCP is bidirectional:

This enables agentic behaviors where servers can drive workflows.

3. Open but Structured

Protocol is open source (Linux Foundation) with:

This balances openness with structure.

4. Extensible

_meta property allows custom metadata without breaking protocol:

Reserved prefixes prevent conflicts:

Next Steps for My Implementation

1. Add Missing Methods

2. Add Client Features

3. Improve Security

4. Add Metadata

Status: Deep dive complete

Protocol Version: 2025-11-25

Key Insight: MCP is flexible, bidirectional, extensible protocol for AI integrations

Next: Add missing features to my implementation

Date: 2026-02-04