What Is Model Context Protocol (MCP)? Complete Technical Introduction

What Is the Model Context Protocol?

The Model Context Protocol (MCP) is an open, standardized specification that governs how Large Language Model (LLM) applications and autonomous AI agents exchange context, read data, and execute operations across external tools, local operating systems, and enterprise services.

Often described as the USB-C of the AI ecosystem, MCP replaces fragmented, proprietary function-calling connectors with a unified protocol layer built upon JSON-RPC 2.0. By standardizing discovery, invocation, and security boundary isolation, MCP enables developers to build a single server adapter that connects seamlessly across Claude Desktop, Cursor, Windsurf, the OpenAI Codex CLI, and custom agent runtimes.

The N × M Integration Dilemma

Prior to MCP, connecting AI models to enterprise infrastructure suffered from an exponential scaling problem. Every AI client implemented custom schemas for tool calling, prompting, and context injection:

• ▸OpenAI Assistants API expected proprietary tool definition arrays.
• ▸Anthropic Tool Use required separate input JSON schemas.
• ▸LangChain / LlamaIndex wrapped integrations in internal abstraction wrappers that frequently drifted from underlying upstream APIs.

If an engineering team wanted to connect 10 internal systems (PostgreSQL, GitHub, Jira, Redis, AWS) to 4 different AI hosts (Claude Desktop, Cursor IDE, CLI agents, Slack bots), they were forced to maintain up to 40 distinct integration bridges.

graph LR
    subgraph Fragmented Function Calling (Before MCP)
        H1[Claude Desktop] --> C1[Custom Anthropic Bridge] --> DB[(PostgreSQL)]
        H2[Cursor IDE] --> C2[Custom VS Code Plugin] --> DB
        H3[Codex CLI] --> C3[Custom OpenAI Tool] --> DB
    end

MCP standardizes this into an 1 × M architecture. The data source or tool exposes an MCP Server once. Any MCP-compliant client or host application can immediately discover and interact with it over a standard communication channel without custom client-side code.

graph LR
    subgraph Standardized Architecture (With MCP)
        H1[Claude Desktop] --> MCP[JSON-RPC 2.0 Transport]
        H2[Cursor IDE] --> MCP
        H3[Codex CLI] --> MCP
        MCP --> Server[PostgreSQL MCP Server]
        Server --> DB[(Production DB)]
    end

Core Architecture: The Host-Client-Server Triad

MCP enforces clean separation of concerns through three distinct architectural roles:

1. ▸The MCP Host: The primary end-user application orchestrating LLM interactions, rendering the user interface, and managing execution permissions. Examples include Claude Desktop, Cursor, and the OpenAI Codex CLI.
2. ▸The MCP Client: A protocol-aware module embedded within the Host. The client opens bidirectional connections, initiates protocol handshakes, queries server capabilities, and routes model tool invocations to the target server.
3. ▸The MCP Server: A lightweight, decoupled process that exposes specialized capabilities. The server translates standardized JSON-RPC requests into domain actions—such as executing SQL queries, querying Git log history, or reading local file trees.

JSON-RPC 2.0 Protocol Wire Lifecycle

MCP uses standard JSON-RPC 2.0 for all message framing. Every communication session follows a strict, deterministic lifecycle consisting of initialization, capability exchange, execution, and shutdown.

1. The Initialization Handshake

When an MCP host launches a server, the client immediately transmits an initialize request to negotiate protocol versioning and declare supported features:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {}
    },
    "clientInfo": {
      "name": "ClaudeDesktop",
      "version": "1.0.8"
    }
  }
}

The MCP server validates the requested protocol version and returns its own capability manifest:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": { "subscribe": false }
    },
    "serverInfo": {
      "name": "postgresql-mcp-server",
      "version": "1.2.0"
    }
  }
}

Once the client acknowledges receipt by dispatching a notifications/initialized notification, the connection is officially open for tool queries and resource reads.

2. Tool Discovery (tools/list)

Before an LLM can invoke external functions, the client queries the server's registered tools:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list",
  "params": {}
}

The server returns an array of callable tools, each annotated with a JSON Schema describing its expected input parameters:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "query_database",
        "description": "Execute a read-only SQL query against the connected PostgreSQL database",
        "inputSchema": {
          "type": "object",
          "properties": {
            "sql": {
              "type": "string",
              "description": "The SELECT query string to execute"
            }
          },
          "required": ["sql"]
        }
      }
    ]
  }
}

3. Tool Invocation (tools/call)

When the LLM determines that external data is required to fulfill a prompt, the client translates the model's structured choice into a tools/call message:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": {
      "sql": "SELECT id, email, created_at FROM users WHERE status = 'active' LIMIT 5;"
    }
  }
}

The server executes the operation inside its local context and returns standardized content blocks:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "[{\"id\":101,\"email\":\"dev@example.com\",\"created_at\":\"2026-01-15T08:30:00Z\"}]"
      }
    ],
    "isError": false
  }
}

The Three Fundamental MCP Primitives

MCP formalizes capabilities into three core primitives, each tailored to a specific modality of agent-computer interaction:

Transport Layers: Stdio vs. SSE

MCP supports two primary transport mechanisms designed for different execution environments:

1. Standard Input/Output (stdio)

• ▸How it works: The host application spawns the MCP server as a local child process (using child_process.spawn in Node.js or subprocess.Popen in Python). Messages are framed as newline-delimited JSON over stdin and stdout.
• ▸Best for: Local developer environments, CLI tools, database inspectors, desktop IDEs.
• ▸Security: Highest security level. The server runs locally under user process boundaries; no open TCP network ports or public IP exposure required.
• ▸Crucial Implementation Rule: Servers must never write debug statements (console.log() or print()) to standard output (stdout), as unformatted strings immediately corrupt the JSON-RPC framing. All server telemetry must be directed strictly to standard error (stderr).

2. Server-Sent Events with HTTP POST (SSE)

• ▸How it works: The client initiates an HTTP GET request with an Accept: text/event-stream header. The server streams real-time JSON-RPC notifications and server messages down the SSE connection. Client-to-server requests are transmitted via standard HTTP POST requests to an endpoint designated during initialization.
• ▸Best for: Remote web services, centralized enterprise MCP gateways, cloud-hosted microservices.
• ▸Security: Requires transport security (HTTPS/TLS), bearer token authentication, and strict CORS configuration to prevent unauthorized browser-based cross-origin calls.

Security Architecture & Defense-in-Depth

Granting autonomous AI agents access to operational infrastructure demands strict isolation controls. MCP incorporates explicit defensive boundaries by design:

1. ▸Human-in-the-Loop Verification: MCP clients (such as Claude Desktop and Cursor) display confirmation dialogues before executing potentially destructive tools.
2. ▸Path & Scope Sandboxing: MCP servers like @modelcontextprotocol/server-filesystem enforce directory sandboxes, denying directory traversal attacks (../../etc/passwd) and ignoring unmapped symlinks.
3. ▸Principle of Least Privilege: Database adapters should be configured with read-only credentials (SELECT only, no DROP, UPDATE, or TRUNCATE rights) and restricted schemas.
4. ▸Zero Ambient Authority: Servers do not automatically inherit network-wide administrative credentials. All API tokens, session keys, and database passwords must be explicitly declared in client configuration files.

Using with OpenAI Codex

Add this server to the OpenAI Codex CLI:

codex mcp add --name what-is-model-context-protocol --command "npx" --args "-y @modelcontextprotocol/server-filesystem@2026.8.31"

The version above is pinned to the release this guide was verified against. Check for a newer one before upgrading:

npm view @modelcontextprotocol/server-filesystem version

Reference: Configuring MCP servers with OpenAI Codex.

Summary & Next Steps

By unifying agent interfaces under JSON-RPC 2.0, the Model Context Protocol replaces proprietary vendor bridges with a standardized client-server specification. LLMs and autonomous agents can safely interrogate databases, manipulate repositories, and execute operational workflows through auditable tool boundaries.

To explore real-world implementations, inspect our verified guides:

• ▸How to Connect PostgreSQL to AI Agents
• ▸How to Build a Custom MCP Server from Scratch
• ▸MCP Security Best Practices & Sandboxing