Model Context Protocol (MCP): a deep dive into the "USB-C port for AI" — architecture, primitives, and Sales Claw integration

"You keep seeing 'MCP' everywhere — Claude, ChatGPT, Cursor, VS Code, Gemini CLI — but what actually is it, why did it become a de facto standard, and how would you build it into AI-driven sales automation?" This article answers that head-on. We work from the official MCP spec (2025-11-25 revision) and Anthropic / OpenAI / Google primary docs, walking through architecture, primitives, implementation, and operational risk from a Sales Claw maintainer's perspective.

Model Context Protocol (MCP) was announced by Anthropic on 2024-11-25. Eighteen months later (May 2026), every major AI development tool — Claude Code, ChatGPT (Apps), Codex, Gemini CLI, Cursor, VS Code, Zed, Replit — has adopted it. The official site frames MCP as "a USB-C port for AI applications." That framing is good marketing, but the real story underneath is a stateful JSON-RPC 2.0 protocol with a clean Host / Client / Server three-tier separation, deeply inspired by the Language Server Protocol (LSP).

Primary sources: the modelcontextprotocol.io official spec (2025-11-25), the modelcontextprotocol/specification GitHub repo, the modelcontextprotocol/servers GitHub repo, Anthropic Newsroom (2024-11-25 launch), Claude Code MCP Docs (code.claude.com), OpenAI MCP Docs (developers.openai.com/api/docs/mcp), and Gemini CLI MCP Docs (geminicli.com). If you've read the Claude agents × Codex remote-control orchestration piece or the Claude Code slash commands guide, read this article as "the common protocol layer underneath both." The Sales Claw Quick start is also worth reading alongside the implementation section.

1. What MCP is — beyond the "USB-C port for AI" metaphor

The formal MCP definition from modelcontextprotocol.io:

Decomposed: there's "(a) the AI-application side" and "(b) the external-system side," with "(c) an open standard protocol" inserted between them. The USB-C metaphor is accurate in the sense that hardware connectors went from "every vendor invents their own port" to "one USB-C cable handles everything," and MCP brings that same answer to the AI × tools problem.

But if you stop at the metaphor, you miss the real design decision. The spec (modelcontextprotocol.io/specification) is explicit that MCP was inspired by the Language Server Protocol (LSP).

Microsoft designed LSP in 2016 for VS Code. Before LSP, "editor × language" was an N × M problem — every editor had to integrate every language. LSP collapsed it into "editor ← LSP → language server" — a 1:N abstraction. MCP is best understood as the same trick, applied to "LLM app × data sources / tools".

Holding the "LSP for AI" framing in mind makes the rest of the design click: capability negotiation and stateful sessions exist for reasons that LSP also encountered. Rather than each vendor inventing their own format (one for Claude, one for OpenAI, one for Google), Anthropic proposed: let's all speak the same protocol.

2. MCP's history and current spec (2024-11-25 → 2025-11-25)

The historical thread, from primary sources:

2024-11-25: Anthropic announces MCP

On 2024-11-25, Anthropic posted "Introducing the Model Context Protocol" on its Newsroom. Highlights:

• Designers: led by David Soria Parra and Justin Spahr-Summers at Anthropic.
• Motivation: AI models cut off from knowledge trapped behind information silos and legacy systems.
• Initial supporters: Block and Apollo as early-adopter companies; Zed, Replit, Codeium, and Sourcegraph as developer-tool companies.
• Released alongside: pre-built MCP servers for Google Drive, Slack, GitHub, PostgreSQL, and more.

2024-11 → 2025-11: a year of revisions

The modelcontextprotocol/specification repo's schema folder stacks TypeScript schemas by version. The lineage looks roughly like this (based on the repo's naming convention):

As of May 2026, reference the 2025-11-25 spec. The official spec page (modelcontextprotocol.io/specification) is organized in five sections: Architecture / Base Protocol / Server / Client / Contributing.

Seven official reference servers and the ecosystem

The modelcontextprotocol/servers repo provides seven official reference implementations. They are the canonical examples of how MCP should behave — the best place to study before writing your own server.

The README links to well over 150 community implementations, and Anthropic Directory (claude.ai/directory) lists officially reviewed remote MCP servers. Slack, Notion, Linear, Figma, Google Drive, PostgreSQL, Sentry, Datadog, Statsig, Cloudflare — almost every major SaaS now has an official or semi-official MCP server.

3. Architecture — Host / Client / Server three tiers, JSON-RPC 2.0

Summarizing the spec's architecture definition (modelcontextprotocol.io/specification/2025-11-25/architecture):

Host

• Definition: the container/coordinator that owns the LLM application process.
• Examples: Claude Desktop, Claude Code, ChatGPT, Cursor, VS Code, Zed, Gemini CLI.
• Responsibilities: spawning and managing multiple Clients, obtaining user consent, enforcing security policy, coordinating LLM sampling, aggregating context from multiple Servers.

Client

• Definition: a connector spawned by the Host that maintains a 1:1 session with a specific Server.
• Responsibilities: establishing the stateful session, protocol negotiation, bidirectional message routing, subscription / notification management, maintaining security boundaries between Servers.

Server

• Definition: an independent process or remote service that provides specialized context or capability.
• Examples: Filesystem server, Git server, Slack server, Postgres server, Sentry server — and eventually Sales Claw server.
• Responsibilities: expose Resources / Tools / Prompts, request sampling via Client, follow security constraints.

JSON-RPC 2.0 and transports

The messaging layer is JSON-RPC 2.0 — bidirectional request / response / notification between Client and Server. Three standardized transports:

Session lifecycle: initialize → negotiation → operate → close

An MCP session starts with an initialize request. The Client declares its own capabilities; the Server responds with its capabilities — this is capability negotiation. It fixes "does this Server support tools?" and "does this Client support sampling?" at session start.

// Client → Server: initialize
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "sampling": {},
      "roots": { "listChanged": true }
    },
    "clientInfo": { "name": "Claude Code", "version": "2.1.142" }
  }
}

// Server → Client: initialize result
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": { "subscribe": true },
      "prompts": {}
    },
    "serverInfo": { "name": "salesclaw-mcp", "version": "0.1.0" }
  }
}

After that the Client issues tools/list, resources/list, prompts/list and so on. The LLM calls tools as needed via tools/call. Servers can also send requests back to the Client — typical examples: sampling/createMessage ("please continue this with the LLM") and roots/list("which directories may I operate in?").

Sales Claw is built with MCP-server-ready, policy-controlled autonomous operation in mind.

無料・MIT ライセンス。インストールせずにライブデモも試せます。

無料でダウンロードライブデモを試すGitHub

4. Primitives — three server-side, three client-side

Every MCP capability decomposes into one of these six. The spec's server features table (modelcontextprotocol.io/specification/2025-11-25/server) splits them by who controls them:

Server features (three)

The three are fundamentally different by who triggers them. Resources are "the Host app attaches them to context via UI." Prompts are "the user explicitly fires them via slash command or menu." Tools are "the LLM decides on its own." The same "Server-exposed capability" comes with very different safety layers. A "delete file" Tool fires at the LLM's discretion — explicit user consent is mandatory every time. A "file list" Resource only loads when the user picks it in the UI.

Client features (three)

The reverse direction (Server → Client) has three primitives. These are callable from the Server only when the Client declares the matching capability.

Elicitation is a relatively new primitive added in the 2025-06-18 spec. Before that, the Server had no clean way to request user input — it had to guess or error. Cleanliness of design jumped significantly.

5. Major AI tool adoption + Sales Claw implementation sketch

Host adoption matrix

The key point: config formats differ, but the MCP server on the other end is the same binary. That's the value of MCP as an open protocol. An MCP server you wrote for Claude Code runs identically when called from Gemini CLI or Cursor.

Adding an MCP server to Claude Code

# Add a stdio (local process) server
claude mcp add salesclaw -- npx -y @salesclaw/mcp-server

# Add a Streamable HTTP (remote) server
claude mcp add --transport http salesclaw https://mcp.salesclaw.site

# Share via .mcp.json (one project config for the whole team)
cat > .mcp.json <<EOF
{
  "mcpServers": {
    "salesclaw": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@salesclaw/mcp-server"],
      "env": { "SALESCLAW_API_KEY": "${SALESCLAW_API_KEY}" }
    }
  }
}
EOF

Adding an MCP server to Gemini CLI

# Append to ~/.gemini/settings.json
cat >> ~/.gemini/settings.json <<EOF
{
  "mcpServers": {
    "salesclaw": {
      "command": "npx",
      "args": ["-y", "@salesclaw/mcp-server"],
      "env": {
        "SALESCLAW_API_KEY": "$SALESCLAW_API_KEY"
      }
    }
  }
}
EOF

Sales Claw as an MCP server — implementation sketch

Sales Claw is OSS designed to lower misfire and policy-violation risk through policy control, pre-send checks, do-not-contact detection, CAPTCHA-on-detect stop, rate limits, audit logging, and automatic stop conditions. Exposed as an MCP server, it becomes callable through the same interface from Claude / ChatGPT / Cursor / VS Code / Gemini CLI.

A draft of the primitives Sales Claw MCP would expose (design proposal — implementation staged):

The design choice that matters: preflight_check and submit_form are intentionally split. Even if the LLM (Claude / ChatGPT) tries to call submit_form directly, the Sales Claw server enforces "only accept if preflight_check has passed." That gives you a second defense layer that runs independently of the Host's --permission-mode— the answer at the design level to the spec's "tools = arbitrary code execution" assumption.

Internal validation at Sales Claw (around 300 contact-form submissions observed under autonomous looping + parallel batches + Hooks-driven event-loop monitoring) found that even when Sales Claw runs as an MCP server, these five conditions must all be enforced on the server side: (1) AND of goal / volume cap / elapsed-time cap as termination conditions; (2) awaiting_approval state preservation on CAPTCHA detection; (3) automatic compliance footer append; (4) per-subagent audit-log traceability; (5) immediate stop on do-not-contact detection. For enterprise deployment, per-tenant Resources isolation is also required.

# Local dev / debug with MCP Inspector
npx -y @modelcontextprotocol/inspector npx -y @salesclaw/mcp-server

# Call from Claude Code
claude mcp add salesclaw -- npx -y @salesclaw/mcp-server
# In Claude Code: "Run @salesclaw preflight_check, then @salesclaw submit_form."

Build-cost estimate for a custom MCP server

Expect ±30–50% variance. Security review and per-tool permission design swing 2–3× by organizational maturity.

6. Safety and risk in MCP — tool safety, sampling consent, data boundaries

MCP is a protocol where Hosts and Servers exchange "tools equivalent to arbitrary code execution." The security chapter of the spec is explicit that MCP cannot enforce these guarantees at the protocol level alone — it leaves responsibility with the implementers (both Host and Server). Whether you expose Sales Claw as an MCP server or just run it standalone, the risks below need to be reduced through automated checks.

Tool safety

• Don't trust Tool descriptions: the spec says clearly "Tool description annotations should be considered untrusted." Calling a tool based on its name and description alone is unsafe.
• Get user consent: Hosts must confirm with the user before tools with side effects (send, write, delete). Claude Code's --permission-mode default / ask exists for this.
• Two-stage server-side check: "the Host approved it" isn't sufficient. Implement order enforcement (like preflight_check → submit_form) on the server too.

Sampling consent

• Prevent server-driven runaway: Sampling lets the Server ask the Client "please continue with the LLM." The spec mandates that "users must explicitly approve" these.
• Control prompt visibility: "protocol intentionally limits server visibility into prompts" — the design keeps the Server from seeing the whole conversation.

Data boundaries and privacy

• No undeclared transfer: the spec says "Hosts must not transmit resource data elsewhere without user consent."
• Server-side silos: Clients hold 1:1 sessions with Servers, so Server A's context doesn't leak to Server B (unless the Host explicitly hands it over).
• Audit log: expose submission history as Resources (as Sales Claw does), enabling after-the-fact audit.

Residual risks

Even with protocol design and server implementation done well, these remain structurally:

• Malicious third-party MCP servers: Cursor / Claude Desktop let users add arbitrary servers — a "keylogger disguised as an image-generator MCP server" is technically feasible. Prefer reviewed directories like Anthropic Directory.
• Tool-description prompt injection: Server-side tool descriptions crafted to manipulate the LLM. Mitigate by surfacing the description to the user in the Host UI.
• Streamable HTTP authorization gaps: not implementing OAuth 2.0 and instead embedding API keys in URLs.
• Sampling-driven cost explosion: Servers recursively triggering sampling can blow up API costs. Host-side rate limits are essential.

7. Pre-production checklist

Run through this before putting your own MCP server into production, or before adding a third-party MCP server to your Host.

8. Bottom line — MCP as foundation tech, and what to take from it

MCP gets sold as "a USB-C port for AI" for accessibility, but the real essence is LSP applied to AI — a protocol abstraction that re-organizes the LLM-app × external-system N × M problem into 1:N. Three tiers (Host / Client / Server), JSON-RPC 2.0, six primitives (Resources / Tools / Prompts / Sampling / Roots / Elicitation), and the strong premise that tools equal arbitrary code execution — all stable in the 2025-11-25 spec.

From a Sales Claw maintainer's perspective, MCP is significant because Sales Claw can be both called (Server) and caller (Client inside a Host). Designing "pre-send checks enforced at the protocol level" via MCP tool-order control means Sales Claw's safety design works identically no matter which Host (Claude, ChatGPT, Cursor) invokes it.

Next action: if you're building one MCP server, read the Everything server in modelcontextprotocol/servers first. It demonstrates the minimum implementation of Resources / Prompts / Tools, and teaches the SDK along the way. For Sales Claw operational integration, start with the Quick start and study the preflight_check logic.

MCP is foundation tech. You only internalize it by running it.

無料・MIT ライセンス。インストールせずにライブデモも試せます。

無料でダウンロードライブデモを試すGitHub