The Model Context Protocol (MCP) enables seamless communication between AI applications (clients) and external data sources or tools (servers).

MCP Client - Server interactions

Here’s a simple sequence diagram showing how MCP servers work:

sequenceDiagram
  participant User as User
  participant Host as VScode / Claude / ChatGPT Desktop
  participant Client as MCP Client
  participant Server as MCP Server
  participant Resource as External Service
  User ->> Host: Open application
  Host ->> Client: Initialize client
  Client ->> Server: initialize request with capabilities
  Server ->> Client: initialize response with capabilities
  Client ->> Server: initialized notification
  User ->> Host: Make a request
  Host ->> Client: Forward request
  alt Resource Request (Application-controlled)
    Note right of Client: A Resource is context data from the server<br/>Examples: file contents, code history, database schemas<br/>Resources help LLMs understand context
    Client ->> Server: resources/list or resources/read
    Server ->> Resource: Fetch data (e.g., read files, query DB)
    Resource ->> Server: Return data
    Server ->> Client: Resource content
    Client ->> Host: Add context to LLM prompt
  else Tool Execution (Model-controlled)
    Note right of Client: A Tool is a function the LLM can call<br/>Examples: web search, file writing, API calls<br/>Tools let LLMs take actions
    Client ->> Server: tools/call
    Server ->> Resource: Execute operation
    Resource ->> Server: Return result
    Server ->> Client: Tool result
    Client ->> Host: Show result to LLM
  else Sampling Request (Server-initiated)
    Note right of Server: Sampling lets servers request LLM generations<br/>Examples: analyzing data, making decisions<br/>Enables agentic/recursive workflows
    Server ->> Client: sampling/createMessage
    Client ->> Host: Request LLM generation
    Host ->> User: Request approval (optional)
    User ->> Host: Approve request
    Host ->> Client: Return generation
    Client ->> Server: Generation result
  end
  Client ->> Host: Return response
  Host ->> User: Display result
  User ->> Host: Close application
  Host ->> Client: Terminate
  Client ->> Server: Disconnect

      sequenceDiagram
      participant User as User
      participant Host as VScode / Claude / ChatGPT Desktop
      participant Client as MCP Client
      participant Server as MCP Server
      participant Resource as External Service
      User ->> Host: Open application
      Host ->> Client: Initialize client
      Client ->> Server: initialize request with capabilities
      Server ->> Client: initialize response with capabilities
      Client ->> Server: initialized notification
      User ->> Host: Make a request
      Host ->> Client: Forward request
      alt Resource Request (Application-controlled)
         Note right of Client: A Resource is context data from the server
Examples: file contents, code history, database schemas
Resources help LLMs understand context
         Client ->> Server: resources/list or resources/read
         Server ->> Resource: Fetch data (e.g., read files, query DB)
         Resource ->> Server: Return data
         Server ->> Client: Resource content
         Client ->> Host: Add context to LLM prompt
      else Tool Execution (Model-controlled)
         Note right of Client: A Tool is a function the LLM can call
Examples: web search, file writing, API calls
Tools let LLMs take actions
         Client ->> Server: tools/call
         Server ->> Resource: Execute operation
         Resource ->> Server: Return result
         Server ->> Client: Tool result
         Client ->> Host: Show result to LLM
      else Sampling Request (Server-initiated)
         Note right of Server: Sampling lets servers request LLM generations
Examples: analyzing data, making decisions
Enables agentic/recursive workflows
         Server ->> Client: sampling/createMessage
         Client ->> Host: Request LLM generation
         Host ->> User: Request approval (optional)
         User ->> Host: Approve request
         Host ->> Client: Return generation
         Client ->> Server: Generation result
      end
      Client ->> Host: Return response
      Host ->> User: Display result
      User ->> Host: Close application
      Host ->> Client: Terminate
      Client ->> Server: Disconnect
   

Why are MCP servers needed?

Separation of concerns

The client-server architecture in MCP follows a key design principle: separation of concerns.

graph TD
    subgraph "Host Application"
        Host[Host Process]
        Client1[MCP Client 1]
        Client2[MCP Client 2]
        Client3[MCP Client 3]
        Host --> Client1
        Host --> Client2
        Host --> Client3
    end

    subgraph "External Processes"
        Server1[MCP Server 1<br>Files & Git]
        Server2[MCP Server 2<br>Database]
        Server3[MCP Server 3<br>External APIs]
    end

    Client1 <--> Server1
    Client2 <--> Server2
    Client3 <--> Server3

Why Not Have the Client Do Everything?

1. Security Boundaries:
   • Servers maintain security isolation between different systems
   • Each server has limited access to only what it needs
   • The client doesn’t need credentials for every possible system
2. Simplicity and Maintainability:
   • Each server can focus on one specific domain (files, databases, etc.)
   • Easier to build, test, and maintain focused servers
   • Modular approach allows servers to be developed independently
3. Domain Specialization:
   • Servers can be built by domain experts (database specialists, etc.)
   • Each server can implement specialized functionality for its domain
   • Optimized implementations for different use cases
4. Distribution and Scaling:
   • Servers can run locally or remotely, wherever makes most sense
   • Some servers might run close to data sources for performance
   • Allows scaling different components independently
5. Adaptability:
   • New servers can be added without changing client implementation
   • Existing servers can be improved independently
   • Encourages ecosystem growth and specialization
6. User Control:
   • Users can choose which servers to connect to
   • Different security policies can be applied to different servers
   • Enables granular permission management

How do I start?

Grab the SDK for your favourite programming language: https://github.com/modelcontextprotocol and start building!

My short explanation of the sequence diagram

@glich.stream How MCP clients/servers work. This is a sequence diagram breaking down the types of exchanges that occur between an mcp client, server and external service allowing the large language models to control the behaviour of that service or fetch / store information from it