MCP Protocol Overview: Bridging AI Agents with the External World

Introduction

MCP (Model Context Protocol) is an open protocol released by Anthropic that standardizes communication between AI models and external tools/data sources. Through MCP, AI Agents can securely and consistently invoke external system capabilities.

This article provides a systematic introduction to MCP's core principles, interaction mechanisms, and deployment modes.

MCP Protocol Core Principles

Overall Architecture

The MCP protocol defines the communication specification between AI clients (Agents) and MCP Servers, with MCP Servers then interacting with actual business systems:

flowchart LR
    subgraph Client
        A[Agent]
    end
    
    subgraph MCP Layer
        B[MCP Server]
    end
    
    subgraph Business Layer
        C[Business System API]
    end
    
    A <-->|MCP Protocol<br/>JSON-RPC 2.0| B
    B <-->|HTTP/Other Protocols| C

Working Mechanism

The MCP protocol workflow includes the following key stages:

Stage	Description
Tool Registration	When MCP Server starts, it declares available tools, resources, and prompts to clients
Message Format	Uses JSON-RPC 2.0 protocol for communication
Invocation Flow	Agent identifies user intent → Selects appropriate MCP tool → Sends invocation request → MCP Server executes business logic → Returns result

Agent-MCP Interaction Mechanism

Capability Discovery Flow

Agents need to "know" what tools are available and their parameter definitions. This process is completed during the MCP protocol initialization and capability discovery phase:

sequenceDiagram
    participant Agent as Agent
    participant MCP as MCP Server
    participant Biz as Business System API

    rect rgb(240, 248, 255)
        Note over Agent, MCP: Phase 1: Initialization Handshake
        Agent->>MCP: initialize request<br/>(declare client capabilities)
        MCP-->>Agent: initialize response<br/>(declare server capabilities, protocol version)
        Agent->>MCP: initialized notification<br/>(confirm initialization complete)
    end

    rect rgb(255, 248, 240)
        Note over Agent, MCP: Phase 2: Tool Discovery
        Agent->>MCP: tools/list request
        MCP-->>Agent: Return tool list<br/>(name, description, parameter Schema)
    end

    rect rgb(240, 255, 240)
        Note over Agent, Biz: Phase 3: Actual Invocation
        Agent->>MCP: tools/call request<br/>(tool name + parameters)
        MCP->>Biz: HTTP request<br/>(call actual API)
        Biz-->>MCP: HTTP response
        MCP-->>Agent: Return execution result
    end

The entire flow can be divided into three phases:

Initialization Handshake: Agent and MCP Server establish connection, exchanging capability information and protocol version
Tool Discovery: Agent retrieves all tool information provided by MCP Server through tools/list request
Actual Invocation: Agent selects appropriate tools based on user intent and initiates invocation requests

tools/list Response Structure

When MCP Server responds to tools/list, the core fields returned are:

Field	Description
name	Unique tool identifier, e.g., `create_order`
description	Tool functionality description, used by LLM to determine when to invoke
inputSchema	Parameter definition in JSON Schema format (types, required fields, descriptions, etc.)

After obtaining this information, the Agent injects it into the LLM's context, enabling the LLM to:

Understand what tools are available
Comprehend each tool's purpose
Know what parameters to pass when invoking

Transport Protocols: stdio vs SSE

MCP Server and client support two transport layer protocols.

stdio (Standard Input/Output)

The stdio mode communicates through process standard input/output:

Feature	Description
Communication Method	Through process stdin and stdout
Deployment Location	Must run locally
Startup Method	Client directly starts MCP Server process
Connection Mode	One-to-one, each client starts an independent process
Typical Scenarios	Local development, desktop applications, private deployment

SSE (Server-Sent Events)

SSE mode is based on HTTP protocol and supports remote deployment:

Feature	Description
Communication Method	HTTP-based server push technology
Deployment Location	Can be on remote servers
Startup Method	Independently deployed as HTTP service
Connection Mode	One-to-many, can serve multiple clients
Typical Scenarios	Cloud deployment, SaaS services, public APIs

Architecture Design Options

Option 1: stdio Mode

Users deploy MCP Server locally, configure business system credentials for communication. The underlying transport is HTTP requests, and authentication depends on the business system's authentication mechanism.

flowchart TB
    subgraph local["User's Local Machine"]
        A[Agent]
        B["MCP Server<br/>(configured with credentials)"]
        A <-->|stdin/stdout| B
    end
    
    subgraph remote["Business System Server"]
        C["Business System API<br/>(authentication, business processing)"]
    end
    
    B -->|HTTP Request| C
    C -->|HTTP Response| B

Characteristics:

Users need to install MCP Server locally
Business credentials are configured on user's local machine
MCP Server internally uses HTTP to call business system APIs
Authentication is handled by the business system

Option 2: SSE Mode

Deploy MCP Server on the server side. A gateway can be added between client and MCP Server for API key authentication.

flowchart TB
    subgraph local["User's Local"]
        A[Agent]
    end
    
    subgraph server["Business System Server"]
        B["Gateway<br/>(API Key Auth)"]
        C[MCP Server]
        D[Business System API]
        
        B --> C
        C --> D
    end
    
    A <-->|"HTTP/SSE<br/>API Key Auth"| B