Technical Overview: How MCP Works

Model Context Protocol (MCP) introduces a structured way for AI assistants to obtain context and perform actions through external systems. This page provides a detailed technical explanation of MCP's architecture, components, and implementation patterns.

Architecture and Components

MCP's architecture consists of two layers: a data/protocol layer and a transport layer. The system operates through clearly defined roles and communication patterns.

Core Participants

MCP Host

The AI application or agent that users interact with - like Claude Desktop, ChatGPT, or an AI-enhanced IDE. Contains multiple client connections and provides the user interface.

MCP Client

Connector component within the host that maintains individual connections to servers and handles protocol-level communication. Each client has a one-to-one connection with a specific server.

MCP Server

External program (local or cloud service) that exposes specific capabilities via MCP. Provides tools, data, or prompts by bridging between MCP protocol and external systems.

A single AI application can connect to multiple servers simultaneously by spinning up multiple client connections. For example, one server might provide database access while another offers email-sending capabilities.

Core Concepts and Primitives

MCP defines several key primitives that enable rich AI-system interactions:

Tools (AI Actions)

Tools are operations or actions that the AI can request via an MCP server. Each tool is defined with:

• Name and description: Human-readable identification
• JSON Schema: Defines expected input parameters and output format
• Execution model: User-governed with explicit approval required

Example tools: "send an email," "query a database," "schedule a calendar event," "run a web search"

Safety by Design

Tools are model-initiated but user-governed. MCP requires explicit user approval before any tool is executed, with clear prompts showing the intended action (e.g., "AI assistant wants to send an email to [XYZ]. Allow?").

Resources (Context Data)

Resources provide read-only data that AI can fetch as context. Key characteristics:

• URI identification: Each resource has a unique URI (like file://path/to/file.txt or custom schemes)
• MIME types: Indicate data type (text, JSON, image, etc.)
• No side effects: Resources only return data, never modify systems
• Streaming support: Can handle large datasets efficiently

Operations available:

• resources/list - Query available resources
• resources/read - Read resource content
• resources/subscribe - Subscribe to changes for real-time updates

Resource Templates enable parameterized queries, like travel://activities/{city}/{category} to retrieve activities by location and type.

Prompts (Interaction Templates)

Prompts in MCP are predefined, parameterized interaction templates that streamline complex workflows:

• Multi-step scripts: More than simple text hints - complete workflow orchestration
• User-controlled: Only activated when users explicitly choose them
• Parameterized: Can accept inputs to customize behavior
• Domain-specific: Servers provide "best practice" workflows for their domain

Example: A project management server might offer a "Draft weekly summary" prompt that guides the AI through pulling task data and formatting reports.

Advanced Capabilities

Sampling (Client-Side Model Inference)

Allows MCP servers to request the client to perform AI model completions:

• Delegation pattern: Servers don't need their own ML models
• User oversight: Requires user approval for model usage
• Isolated context: Model calls are separate from main conversation
• Example use: A database server using sampling to convert natural language to SQL

Elicitation (User Input Requests)

Enables servers to pause and request additional user input during workflows:

• Interactive workflows: Prevents AI from failing or guessing when information is missing
• Structured input: Uses JSON Schema for validated forms
• Security conscious: Guidelines forbid asking for sensitive secrets
• Example use: Travel booking server requesting final confirmation details

Roots (Filesystem Boundaries)

Security mechanism that restricts file access for filesystem-based MCP servers:

• Whitelisted paths: Clients set allowed directory boundaries
• User control: Users determine accessible file areas
• Dynamic updates: Roots can change when users open new workspaces
• Security barrier: Prevents AI tools from accessing entire drive

Communication Protocol

JSON-RPC 2.0 Foundation

MCP builds on JSON-RPC 2.0 for all client-server communication:

• Message types: Requests (method calls), responses, and notifications
• Human-readable: All messages are JSON text for easy debugging
• Established standard: Benefits from existing libraries and tooling
• Method structure: Standardized method names like tools/list, resources/read

Protocol Lifecycle

1. Initialization Handshake

• Client and server negotiate protocol version (current: 2025-11-25)
• Capability exchange (streaming support, authentication requirements)
• Backwards compatibility through version negotiation

2. Discovery Phase

• Client requests available capabilities: tools/list, resources/list, prompts/list
• Server advertises what it can provide
• Host can present available capabilities to users

3. Operation Phase

• AI queries trigger tool calls or resource reads
• Real-time notifications support streaming and updates
• Context maintained across multiple interactions

Transport Mechanisms

STDIO Transport (Local)

• Process communication: Server runs as local process using standard input/output
• Low latency: No network overhead
• Security: Process-level isolation
• Use case: Local tools, desktop applications
• Example: Claude Desktop launching filesystem MCP server

HTTP + SSE Transport (Remote)

• Network communication: JSON-RPC requests via HTTP POST
• Streaming: Server-Sent Events for real-time notifications
• Authentication: Standard web auth (OAuth, API keys, bearer tokens)
• Scalability: Can sit behind load balancers and web infrastructure
• Use case: Cloud services, enterprise deployments

Implementation Workflow

Typical Interaction Flow

1. User Query: "Summarize last week's sales and email the team"

2. AI Planning: Host determines needed capabilities:

   • Sales data (resource from database server)
   • Email sending (tool from email server)

3. Resource Retrieval:

   • Client calls resources/read on sales server
   • Server returns JSON/CSV data
   • AI model receives data for analysis

4. Tool Execution:

   • AI generates summary from data
   • Client calls tools/call for email tool with summary
   • User approves email sending
   • Server executes action and returns success

5. Result Integration: AI confirms completion to user

Discovery and Dynamic Usage

MCP's discovery mechanisms enable dynamic capability usage:

• Runtime discovery: Clients can query server capabilities at any time
• Schema-driven: JSON schemas describe tool inputs/outputs
• Model adaptation: AI models learn available tools through schema injection
• Autonomous selection: Models can choose relevant tools based on user requests

Security and Control Principles

MCP was designed with user safety and control as primary concerns:

User Authorization Model

• Explicit approval: All side-effect tools require user consent
• Transparent actions: Users see exactly what will be executed
• Granular control: Can approve/deny individual operations
• Audit trails: All actions can be logged for compliance

Isolation and Sandboxing

• Process isolation: Local servers run in separate processes
• Filesystem boundaries: Roots mechanism limits file access
• Context separation: Sampling calls isolated from main conversation
• Network security: HTTPS/TLS for remote connections

Emerging Security Considerations

• Prompt injection: Malicious documents could influence AI behavior
• Data exfiltration: Chain of tools could potentially leak information
• Community solutions: Open protocol enables transparent security research

Version Compatibility and Evolution

MCP uses a thoughtful approach to protocol evolution:

• Date-based versioning: Version identifiers use date stamps (2025-11-25)
• Backwards compatibility: Older clients can connect to newer servers
• Feature negotiation: Optional capabilities can be disabled if unsupported
• Gradual evolution: Minor additions don't require version bumps

Integration with AI Frameworks

MCP is designed to work with various AI frameworks:

• Model agnostic: Works with any language model
• Framework integration: Compatible with LangChain, Semantic Kernel, Azure OpenAI
• Prompt enhancement: Tool schemas injected into model prompts
• Standardized interface: Consistent across different AI platforms

---

Ready to see these concepts in practice? Explore real-world applications or check out learning resources to start building with MCP.