📡 Model Context Protocol (MCP)

Model Context Protocol (MCP), designed by Anthropic, is an open-standard communication protocol that establishes a unified layer between LLMs and external data sources. MCP decouples tool implementation from the agent framework, allowing models to query databases, file systems, and SaaS platforms using a standard endpoint architecture.

For compatible clients, see:

• [Claude Code Reference Guide](../Claude Code.md)
• [Google Antigravity Reference Guide](../Google Antigravity.md)

---

🏗️ 1. MCP Client-Server Architecture

In traditional agent architectures, tools are hard-coded into specific frameworks (e.g. LangChain, CrewAI). If you switch frameworks, you must re-implement the tool wrappers. MCP solves this by creating a Client-Server separation:

A. Transport Protocols

MCP client-server pipelines communicate via two standardized transport mechanisms:

1. Stdio Transport: Employs standard input/output pipes (stdin/stdout). Typically used for local server processes running on the same developer machine.
2. SSE (Server-Sent Events) Transport: Employs persistent HTTP endpoints. Typically used for remote, containerized, or cloud-hosted tool gateways.

B. Core Resource Types

An MCP Server exposes three key capabilities to the client:

1. Resources: Read-only static data exposed as URI schemes (e.g., postgres://localhost/schema or file:///logs/app.log).
2. Prompts: Standardized templates that the client can pre-load and present to the user (e.g. system guidelines, debugging templates).
3. Tools: Actionable executable schemas (analogous to function calling tools) that the server runs on behalf of the client, returning stdout or JSON responses.

---

🔄 2. Protocol Lifecycle & JSON-RPC 2.0 Mechanics

The client and server communicate via standard JSON-RPC 2.0 specifications.

A. The Setup Handshake

1. Initialization: The client sends an initialize request containing its protocol version and client capabilities.
2. Capabilities Exchange: The server returns its name, version, and supported capabilities (Resources, Prompts, Tools).
3. Tool Listing: The client sends a tools/list request, and the server returns JSON schemas for all registered tools.

B. Execution Schema Example

When the LLM decides to execute a tool, the client maps the request to a tools/call JSON payload:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "check_workspace_files",
    "arguments": {
      "path": "~/AI_BOOTCAMP"
    }
  },
  "id": 1
}

The server runs the python script or database query, and replies with structured text data:

{
  "jsonrpc": "2.0",
  "result": {
    "content": [
      {
        "type": "text",
        "text": "- labs\n- GEMINI.md\n- docs"
      }
    ]
  },
  "id": 1
}

---

🛡️ 3. Security Isolation Boundaries

MCP establishes strict security boundaries to prevent LLM actions from compromising the host system:

• Credential Isolation: Server credentials (database passwords, API keys, SSH keys) are stored and processed strictly on the MCP Server. The LLM agent client never sees or handles them.
• Directory Sandboxing: The MCP Server can implement path restrictions (e.g., rejecting any file/read call outside of ~/AI_BOOTCAMP), blocking directory traversal attacks before they reach execution.
• Permission Gates: The client layer can intercept server requests and require explicit user consent (HITL) before allowing write or execution actions.

---

⚡ 4. Key Benefits of MCP

• Model Agnosticism: Once an MCP server is configured (e.g., for SQLite), any compatible LLM client can utilize those resources, bypassing model-specific API setups.
• Decoupled Security: Security restrictions (like write boundaries) can be implemented directly on the MCP server layer, isolating the workspace from direct client execution.
• Unified Developer Tooling: Developers can share, compose, and reuse standard MCP servers across different codebases and applications.