2.2 MCP Architecture, Transports & Registries

2.2 MCP Architecture, Transports & Registries

As artificial intelligence tools become deeply integrated into software engineering workflows, connecting AI assistants to diverse enterprise data sources, local development environments, and cloud APIs has traditionally suffered from fragmentation. Historically, every AI client (such as VS Code, GitHub Copilot, or standalone CLI agents) required custom, hardcoded integrations for every external tool (such as PostgreSQL databases, GitHub repository APIs, or Jira issue trackers).

To solve this N×M integration complexity, Anthropic and the open-source community created the Model Context Protocol (MCP). MCP is an open, standardized client-server protocol that decouples AI host applications from external context providers and execution tools. Understanding MCP architecture, transport protocols, protocol primitives, and registry discovery mechanisms is a fundamental requirement for building modern AI developer workflows.

---

MCP System Architecture & Entities

The Model Context Protocol operates under a flexible client-server architecture comprising three main components:

1. Host Application: The user-facing software application where the AI interaction takes place (e.g., GitHub Copilot CLI, VS Code, Claude Desktop, or an enterprise IDE).
2. MCP Client: A protocol implementation running inside the host application that maintains 1:1 stateful connections with one or more MCP servers. The client converts host requests into standardized MCP protocol messages.
3. MCP Server: A standalone process or remote web service that exposes data sources, prompt templates, or executable tools via the MCP specification.

By standardizing the protocol layer, an MCP server written for a PostgreSQL database or GitHub repository can be consumed instantly by any host application that supports the MCP standard without writing custom integration glue code.

---

Core MCP Primitives

The MCP specification structures all interactions around three fundamental primitives. Understanding the distinction between these primitives is vital for system design and security scoping:

1. Resources (Read-Only Context)

Resources represent passive, read-only data sources that can be attached to an AI model's context window. Resources are identified by standardized Uniform Resource Identifiers (URIs) such as file:///workspace/src/index.ts, postgres://db/users/schema, or github://repos/octocat/hello-world/issues/42.

• Data Types: Resources can contain text strings (source code, logs, markdown) or binary data encoded as base64 (images, compiled artifacts).
• Subscriptions: MCP supports real-time resource subscriptions. Clients can subscribe to a resource URI (resources/subscribe), allowing the MCP server to emit notifications/resources/updated notifications whenever underlying data changes.

2. Prompts (Reusable Templates)

Prompts represent pre-configured, parameterized prompt templates exposed by the server. They allow server authors to embed expert domain knowledge directly into the protocol.

• Dynamic Arguments: Prompts accept input arguments (e.g., a review_pull_request prompt accepting a pr_number argument).
• Client Execution: Clients request available prompts via prompts/list and render them via prompts/get, returning structured message lists ready for model inference.

3. Tools (Executable Actions with Side Effects)

Tools represent actionable functions that an AI model can execute to perform operations or modify state in external systems (e.g., executing a SQL query, creating a Git commit, or launching a CI pipeline).

• JSON Schema Specifications: Every tool exposed by an MCP server includes a name, description, and JSON Schema parameters object (tools/list).
• Invocation Protocol: When the model decides to invoke a tool, the client sends a tools/call request to the server containing argument values. The server executes the operation and returns a CallToolResult object.

---

Transport Layer Specifications: stdio vs SSE

MCP decouples high-level protocol messages from the underlying communication transport. The specification defines two primary transport mechanisms designed for distinct deployment scenarios:

Message Framing Standard (JSON-RPC 2.0)

Regardless of the underlying transport, all MCP communication relies on JSON-RPC 2.0 message framing. The protocol defines three structural message types:

• Requests: Contain jsonrpc: "2.0", an integer or string id, a method string, and an optional params object. Expects a matching response.
• Responses: Contain jsonrpc: "2.0", the matching id, and either a result object (on success) or an error object (on failure).
• Notifications: Contain jsonrpc: "2.0" and a method string without an id. Notifications are one-way messages that do not expect a response.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "fetch_git_commit",
    "arguments": {
      "hash": "a1b2c3d4e5f6"
    }
  }
}

---

Lifecycle Handshake & Capability Negotiation

When an MCP client connects to an MCP server, it executes a mandatory initialization sequence to establish protocol compatibility and capability boundaries:

1. Initialize Request: The client sends an initialize request containing its client protocol version, implementation metadata, and declared capabilities (roots, sampling).
2. Initialize Response: The server responds with its protocol version, server implementation details, and declared capabilities (tools, resources, prompts, logging).
3. Initialized Notification: The client validates the server response and sends an initialized notification. Only after this handshake completes may standard protocol requests occur.

sequenceDiagram
    participant Host as Host App / Client
    participant Server as MCP Server
    Host->>Server: initialize (protocolVersion, capabilities)
    Server-->>Host: initialize response (capabilities: tools, resources)
    Host->>Server: initialized notification
    Note over Host,Server: Session Active
    Host->>Server: tools/list
    Server-->>Host: tools/list response (tool schemas)
    Host->>Server: tools/call (name, arguments)
    Server-->>Host: tools/call response (isError, content)

---

MCP Server Configuration & Registries

Host applications locate and configure MCP servers using declarative JSON configuration files (typically mcp.json or .mcp/config.json).

Example Local Configuration (mcp.json)

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/developer/projects"],
      "env": {
        "LOG_LEVEL": "info"
      }
    },
    "github": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "GITHUB_TOKEN", "mcp/github"],
      "env": {
        "GITHUB_TOKEN": "${env:GITHUB_TOKEN}"
      }
    },
    "enterprise-db": {
      "url": "https://mcp.internal.company.com/sse",
      "headers": {
        "Authorization": "Bearer ${env:MCP_API_TOKEN}"
      }
    }
  }
}

Registry Discovery Protocols

Enterprises manage MCP server deployments using centralized MCP Registries. Registries serve as searchable catalogs publishing verified MCP server packages, version metadata, schema definitions, and health checks. Clients query registries over HTTPS to dynamically discover and launch authenticated MCP servers matching project requirements.