Understanding MCP: A USB-Like AI Extension Protocol

In recent years, with the popularity of AI Agents and LLM applications, Model Context Protocol (MCP) has gradually become a universal extension protocol that allows AI applications to easily connect to external capabilities. Many people encountering MCP for the first time get confused by the three roles: Host, Client, Server. A more intuitive way to understand it is to think of MCP as the USB protocol for the AI world, which is also the analogy used in MCP’s official documentation.

Architecture and Roles

MCP adopts a “client-server” model and defines three types of participants:

Host: The host environment that supports and implements the MCP protocol (such as VS Code, Claude Desktop), responsible for establishing connections with MCP Servers and forwarding messages.
Client: The Agent/assistant running within the Host (such as Copilot, Claude), responsible for initiating requests and orchestrating calls; it calls one or more LLM models behind the scenes.
Server: Independent processes or remote services that expose specific capabilities (such as Playwright automation, database queries, file access, etc.).

In addition to the general roles, MCP often connects to the following resources:

Local data sources: File systems, databases, IDE internal tools.
Remote services: HTTP APIs, cloud services, external AI models, etc.

USB Analogy

Comparing MCP to the USB ecosystem on computers helps with quick understanding:

Host = Computer/USB Port: Only provides a unified interface, doesn’t directly have capabilities like cameras/microphones.
Server = Peripheral Devices: Only gain specific capabilities when plugged in; corresponds to Playwright MCP, Database MCP, Context7 MCP, etc.
Client = Agent/Assistant Software: Doesn’t directly control “peripherals”, but orchestrates capabilities through interfaces, equivalent to user interface (UI); Copilot, Claude (which calls LLM models behind the scenes).

Therefore, MCP naturally forms a “plug-and-play” extension ecosystem: Host provides interfaces, Server provides capabilities, Client handles orchestration and calls.

Example: VS Code + Playwright MCP

Below is a specific example illustrating the interaction process: configuring and calling Playwright MCP in VS Code for web testing.

Host: VS Code.
Client: Agent/assistant (such as Copilot/Claude; typing “help me test the static website” in the chat window).
Server: Playwright MCP (independent process, started by VS Code).

The interaction sequence is as follows:

The data flow process is as follows:

User inputs a prompt in VS Code’s Copilot.
Copilot (Agent/assistant) parses user input and understands the intent.
VS Code (Host/hosting environment) selects the appropriate MCP tool based on requirements.
VS Code constructs the request and prepares parameters.
VS Code sends the request to Playwright MCP Server through the transport layer (such as stdio, HTTP).
Playwright MCP Server executes specific operations and generates test results.
VS Code validates and receives data returned by Playwright MCP Server.
Claude converts results into readable content like text, code, or tables.
Finally displays to the user in VS Code’s UI.

Notes:

Request construction: Uses JSON-RPC 2.0, method=tools/call, params={name, arguments}.
Transport layer: Optional stdio, HTTP, SSE and other methods.
Result generation: May include content, structuredContent, resource_link and other composite content.
Conversion display: Client converts results into text, code, or tables for UI presentation.

Transport Layer Methods

MCP supports multiple transport layer protocols to ensure efficient communication between Host and Server. Common methods include:

Standard Input/Output (stdio): Data exchange through inter-process standard input/output streams, suitable for local integration and Dev Container scenarios, fast startup, easy debugging.
HTTP/HTTPS: Remote calls through RESTful API or JSON-RPC over HTTP, suitable for cloud services or distributed deployment, supports cross-network access and security authentication.
Server-Sent Events (SSE): Used for real-time message pushing, suitable for scenarios requiring continuous data streams or event notifications.
WebSocket (partial implementation): Supports bidirectional real-time communication, suitable for high-frequency interaction and low-latency requirements.
Custom protocols: Some MCP Servers can be extended to gRPC, Unix Socket and other protocols to meet special performance or security requirements.

Developers can choose appropriate transport layer methods based on actual deployment environment and requirements. For example, VS Code defaults to using stdio to start MCP Server, while cloud services recommend HTTP/SSE for remote access and extension.

The choice of transport layer directly affects MCP Server’s startup method, connection management, and security policies. It’s recommended to use stdio for local development and HTTP/SSE and other standard protocols for production environments or remote integration.

Key Protocol Message Examples

For practical implementation, here are common request/response format examples.

1) List Tools (Client → Server)

When Agent/Host needs to discover available tools, it sends tools/list:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": { "cursor": null }
}

Response (Server → Host) contains tool list and input schema:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "pw_run_test",
        "title": "Run Playwright test on a URL",
        "description": "Launch browser and run checks",
        "inputSchema": {
          "type": "object",
          "properties": {
            "url": { "type": "string", "description": "Target URL" },
            "assertions": {
              "type": "array",
              "items": { "type": "string" }
            }
          },
          "required": ["url"]
        }
      }
    ],
    "nextCursor": null
  }
}

The method names and structures of tools/list / tools/call follow the official MCP specification.

2) Call Tool (Client/Host → Server)

When Agent decides to execute Playwright testing, Host sends tools/call on its behalf:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "pw_run_test",
    "arguments": {
      "url": "http://localhost:1313",
      "assertions": ["h1 contains 'Docs'", "no console errors"]
    }
  }
}

Response (Server → Host) may include multiple forms:

Plain text (logs/summary)
Structured results (structuredContent, recommended with outputSchema)
Resources (such as screenshot resource_link or embedded resources)

Example (structured + text + resource link):

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      { "type": "text", "text": "All checks passed (2 assertions). See screenshot." },
      {
        "type": "resource_link",
        "uri": "file:///tmp/playwright/snapshots/home.png",
        "name": "home.png",
        "mimeType": "image/png"
      }
    ],
    "structuredContent": {
      "url": "http://localhost:1313",
      "assertions": [
        { "name": "h1 contains 'Docs'", "passed": true },
        { "name": "no console errors", "passed": true }
      ],
      "durationMs": 1842
    },
    "isError": false
  }
}

Tool results can mix text, images, audio, resource links, embedded resources, and structured JSON. Server can also declare output schema for Host/Client validation.

#ToolName Routing in VS Code

In VS Code Chat, you can either explicitly call a specific MCP tool by typing #playwright ... or directly check install and enable MCP Server in the Agent tool list. For example, Copilot MCP supports one-click installation of Playwright MCP in the tool panel without manual configuration of Dev Container or command line parameters. Simply select the needed Server in VS Code’s MCP tool management interface, and the system will automatically complete installation and integration, suitable for most developers’ daily use scenarios.

If you need custom startup methods (such as local debugging or special environments), you can refer to Dev Container configuration snippets and specify MCP Server’s startup commands and parameters through the customizations.vscode.mcp.servers field. However, in general cases, it’s recommended to directly check install in the Copilot MCP tool panel for simpler operation and smoother integration.

The following diagram shows a full MCP request chain from a sequence perspective, helping you understand when messages are sent by whom.

From the sequence diagram, we can see how the MCP protocol’s request/response flow is passed between different components, with JSON-RPC as the communication protocol ensuring structured and consistent messaging.

JSON-RPC Introduction

In the MCP protocol, JSON-RPC is the core communication format. It’s a lightweight remote procedure call protocol that uses JSON as the data carrier, facilitating data exchange between different languages and platforms. JSON-RPC mainly includes the following fields:

jsonrpc: Protocol version number (usually "2.0").
method: Method name to call (such as tools/list, tools/call).
params: Method parameters, type can be object or array.
id: Unique request identifier for matching responses.
result: Response result (returned on success).
error: Error information (returned on failure).

The advantage of JSON-RPC is its simple format, easy parsing, and support for bidirectional asynchronous communication. MCP implements standardized message passing between Host, Client, and Server through JSON-RPC, ensuring efficient and reliable processes for tool discovery, capability calls, and result returns.

Common JSON-RPC message examples:

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

Response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {}
}

In case of error:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "Method not found"
  }
}

By adopting JSON-RPC, MCP can achieve cross-platform, cross-language capability extension, reducing integration barriers and improving development efficiency.

Errors and Retries

In actual implementation, errors are usually categorized as follows:

Protocol errors (JSON-RPC layer: method doesn’t exist, invalid parameters): Returned through error.code / message.
Business errors (tool execution failure): result.isError = true, with reasons given in content.
VS Code side: Shows trust/permission prompts and call confirmation dialogs, can retry or modify parameters when necessary.

Configuring MCP Server in VS Code

To configure MCP Server in VS Code and use built-in MCP Server (using Playwright as an example), follow these steps:

Enable MCP Server integration functionality by setting chat.mcp.enabled to true.
Configure MCP Server discovery method by setting chat.mcp.discovery.enabled to true (optional, enable auto-discovery as needed).
Control MCP Server auto-start behavior by setting chat.mcp.autostart to newAndOutdated (recommended to auto-start new and outdated MCP Servers).
Use the MCP: Add Server… command to add Playwright MCP Server.
Use the MCP: Show Installed Servers command to view installed MCP Servers.
Use the MCP: Browse Servers command to browse available MCP Servers.
In Playwright projects, ensure MCP Server is correctly installed and running, VS Code will automatically detect and integrate.

Summary

Understanding MCP as the “USB protocol” of the AI world helps grasp its value:

Host (VS Code/Claude Desktop) provides unified “slots”, responsible for process management, permissions, and transport.
Server (such as Playwright MCP) acts like peripherals, receiving parameters according to schema and producing text/screenshots/structured results.
Client (such as Copilot/Claude, not the model itself) serves as the user interface, responsible for selecting and orchestrating peripherals, and converting results into readable output; it calls LLM models behind the scenes to generate natural language and structured output.

This decoupled design allows AI Agents to gain more capabilities in a “plug-and-play” manner, leading to rapid ecosystem development. In upcoming blog posts, I will introduce how to develop a simple MCP Server and debug and test it in VS Code. Stay tuned.