Understanding MCP Architecture

The Model Context Protocol uses a three-tier architecture that connects AI applications with external data sources and tools through a standardized communication layer.

The Three-Tier Model

How components work together in MCP

🖥️

MCP Hosts

LLM applications that initiate connections

• Claude Desktop
• Cursor IDE
• Windsurf
• VS Code
• Zed, Trae, etc.

🔌

MCP Clients

Connectors within the host

• 1:1 with servers
• JSON-RPC 2.0 messages
• Lifecycle management
• Capability negotiation

⚡

MCP Servers

Services providing context & capabilities

• Databases
• APIs
• File systems
• Document stores
• Code repositories

Key Architectural Principle:

Each MCP client maintains a 1:1 relationship with exactly one MCP server. Hosts can run multiple clients to connect to multiple servers simultaneously.

Communication Protocol

JSON-RPC 2.0 Protocol

MCP uses JSON-RPC 2.0 for structured communication, establishing bidirectional, stateful connections between components.

🔄 Bidirectional

Both hosts and servers can initiate requests and send responses

📊 Stateful

Connections maintain context throughout sessions

🤝 Capability Negotiation

Clients and servers exchange supported features

🔍 Standardized

Consistent error handling and logging

Inspired by LSP:

MCP draws inspiration from the Language Server Protocol (LSP), applying similar standardization principles to AI application integrations.

Server-to-Client Features

MCP servers expose three primary types of capabilities to clients. These form the foundation of how AI systems access and interact with external resources.

Resources

Context and data accessible to users or AI models

📂 Structured Data Sources

• Code files and repositories
• Documents and wikis
• Database query results
• API responses

🔒 Access Control

• Application-controlled permissions
• Read-only information exchange
• Can be dynamic or static
• Provides factual context

Read-Only Pattern:

Resources follow a read-only pattern, providing information to AI models without allowing modification.

Client-to-Server Capabilities

MCP is bidirectional — clients don't just consume from servers, they can also provide capabilities back.

🧠

Sampling

Enables agentic AI behaviors by allowing servers to request LLM completions from the host

🌳

Roots

Provides filesystem or URI boundary information for context-aware operations

❓

Elicitation

Allows servers to request additional information from users when needed

Supporting Infrastructure

Beyond the core primitives, MCP includes essential utilities for production deployments:

⚙️ Configuration Management

Server setup, preferences, and runtime configuration

📊 Progress Monitoring

Track long-running operations with progress indicators

🛑 Operation Cancellation

User-controlled workflow termination for any operation

⚠️ Error Handling

Comprehensive error reporting and recovery mechanisms

📝 Structured Logging

Debugging and observability for development and production

Security and Trust Considerations

Security is Paramount:

MCP implementations must carefully address security and trust at every layer of the architecture.

✋ User Consent

Explicit authorization required for:

• Data access requests
• Tool execution
• Resource modifications
• External API calls

🔐 Data Privacy

Secure handling of sensitive information:

• Encrypted transmission
• Minimal data exposure
• Access control enforcement
• Audit logging

🛡️ Tool Safety

Validation and sandboxing:

• Input validation
• Execution sandboxing
• Rate limiting
• Permission boundaries

🎛️ LLM Sampling Controls

Governance over model invocations:

• Context boundaries
• Token limits
• Model selection controls
• Cost management

Ready to Implement?

Now that you understand the architecture, learn how to implement MCP in your own applications.

← Back to MCP Overview

Implementation Guide →

MCP Architecture Overview