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:
➕ Source code for the sequence diagram
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
Files & Git] Server2[MCP Server 2
Database] Server3[MCP Server 3
External APIs] end Client1 <--> Server1 Client2 <--> Server2 Client3 <--> Server3
Why Not Have the Client Do Everything?
- 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
- 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
- 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
- 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
- Adaptability:
- New servers can be added without changing client implementation
- Existing servers can be improved independently
- Encourages ecosystem growth and specialization
- 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!