Skip to main content
The Model Context Protocol ecosystem is built on a client-server model. This modular structure allows AI applications to interact with tools, databases, APIs, and contextual resources efficiently. This module gives you a thorough understanding of every component.

Learning Objectives

By the end of this module, you will:
  • Understand the MCP client-server architecture
  • Identify roles and responsibilities of Hosts, Clients, and Servers
  • Analyze the core features that make MCP a flexible integration layer
  • Learn how information flows within the MCP ecosystem
  • Gain practical insights through code examples in .NET, Java, Python, and JavaScript

Architecture Overview

At its core, MCP follows a client-server architecture where a host application connects to multiple servers:
Your Computer
├── Host (VS Code, Claude Desktop, IDEs, AI Tools)
│   ├── MCP Client A  ←→  MCP Server A  ←→  Local Data Source A
│   ├── MCP Client B  ←→  MCP Server B  ←→  Local Data Source B
│   └── MCP Client C  ←→  MCP Server C  ←→  Remote Services (Internet)
The protocol version used in this curriculum is 2025-11-25 (the current stable release), following MCP’s date-based versioning format.

The Three Participants

Hosts

Hosts are AI applications that serve as the primary interface through which users interact with the protocol. The Host coordinates and manages connections to multiple MCP servers by creating dedicated MCP clients for each server connection. Examples of Hosts:
  • Claude Desktop, Visual Studio Code, Claude Code
  • IDEs and code editors with MCP integration
  • Custom-built AI agents and tools
What Hosts do:
  • Orchestrate AI models — execute or interact with LLMs to generate responses
  • Manage client connections — create and maintain one MCP client per server connection
  • Control user interface — handle conversation flow and response presentation
  • Enforce security — control permissions and authentication
  • Handle user consent — manage approval for data sharing and tool execution

Clients

Clients are essential connector components embedded within the Host. Each MCP client maintains a dedicated one-to-one connection with a specific MCP server. Multiple clients enable Hosts to connect to multiple servers simultaneously. What Clients do:
  • Send JSON-RPC 2.0 requests to servers with prompts and instructions
  • Negotiate supported features and protocol versions during initialization
  • Manage tool execution requests from models and process responses
  • Handle real-time notifications and updates from servers
  • Process and format server responses for the user interface

Servers

Servers are programs that provide context, tools, and capabilities to MCP clients. They can execute locally (same machine as the Host) or remotely (on external platforms). Anyone can build an MCP server to extend model capabilities with specialized functionality. What Servers do:
  • Register and expose available primitives (resources, prompts, tools) to clients
  • Receive and execute tool calls, resource requests, and prompt requests
  • Provide contextual information and data to enhance model responses
  • Maintain session state and handle stateful interactions when needed
  • Send notifications about capability changes to connected clients

Server Primitives

MCP servers expose three core primitives that define the building blocks for rich interactions:
Resources are data sources that provide contextual information to AI applications. They represent static or dynamic content that enhances model understanding and decision-making.Resources can be:
  • Document repositories, articles, and research papers
  • Files, databases, and local system information
  • API responses and remote system data
  • Real-time data that updates based on external conditions
Resources are identified by URIs and support discovery and retrieval:
file://documents/project-spec.md
database://production/users/schema
api://weather/current
Clients discover resources via resources/list and retrieve content via resources/read.

Client Primitives

Clients can also expose primitives, enabling servers to request capabilities from the host application:
Sampling allows servers to request language model completions from the client’s AI application. This lets servers access LLM capabilities without embedding their own model dependencies.Use cases:
  • Servers that need AI assistance for content processing
  • Complex scenarios requiring recursive LLM interactions
  • Dynamic content generation using the host’s model
  • Tool calling within sampling — servers can include tools and toolChoice parameters
Initiated via the sampling/complete method.
Roots provide a standardized way for clients to expose filesystem boundaries to servers, defining which directories and files a server has access to.
  • Use file:// URIs to identify accessible directories
  • Clients send notifications/roots/list_changed when roots change
  • Discovered via the roots/list method
This gives servers a clear scope of filesystem access without requiring hardcoded paths.
Elicitation enables servers to request additional information or confirmation from users through the client interface.Supports:
  • Requesting user input when it’s needed for tool execution
  • Confirmation dialogs before sensitive operations
  • Step-by-step interactive workflows
  • Dynamic parameter collection during tool execution
  • URL Mode — directing users to external web pages for authentication or data entry
Requests are made via the elicitation/request method.
Logging allows servers to send structured log messages to clients for debugging, monitoring, and operational visibility:
  • Detailed execution logs for troubleshooting
  • Status updates and performance metrics
  • Detailed error context and diagnostic information
  • Comprehensive audit trails of server operations

Information Flow in MCP

1

Host Initiates Connection

The host application establishes a connection to an MCP server via STDIO, Streamable HTTP, or another supported transport.
2

Capability Negotiation

The client and server exchange information about supported features, tools, resources, and protocol versions. Both sides now know what capabilities are available for the session.
3

User Request

The user interacts with the host (e.g., enters a prompt). The host passes this input to the client for processing.
4

Resource or Tool Use

The client may request additional context from the server (files, database entries, knowledge base articles) to enrich the model’s understanding. If the model needs a tool, the client sends a tools/call request with the tool name and parameters.
5

Server Execution

The server executes the necessary operations — running a function, querying a database, calling an API — and returns structured results.
6

Response Generation

The client integrates the server’s responses into the model interaction. The model uses this information to generate a comprehensive, contextually relevant response.
7

Result Presentation

The host receives the final output and presents it to the user, including both the model’s generated text and any results from tool executions or resource lookups.

Protocol Architecture and Layers

MCP uses two distinct architectural layers:

Data Layer

Built on JSON-RPC 2.0, the data layer defines message structure, semantics, and interaction patterns:
  • JSON-RPC 2.0 Protocol — all communication uses standardized message formats for method calls, responses, and notifications
  • Lifecycle Management — handles connection initialization, capability negotiation, and session termination
  • Server Primitives — tools, resources, and prompts
  • Client Primitives — sampling, elicitation, roots, and logging
  • Real-time Notifications — asynchronous updates without polling
  • Date-based versioning — uses YYYY-MM-DD format (current: 2025-11-25)

Transport Layer

Manages communication channels between MCP participants:

STDIO Transport

Uses standard input/output streams for direct process communication. Optimal for local processes on the same machine. No network overhead. Commonly used for local MCP server implementations.

Streamable HTTP Transport

Uses HTTP POST for client-to-server messages. Supports optional Server-Sent Events (SSE) for server-to-client streaming. Enables remote server communication across networks. Supports OAuth for secure token-based authentication.
The transport layer abstracts communication details from the data layer, enabling the same JSON-RPC 2.0 message format across all transport mechanisms. You can switch between local and remote servers without changing your application logic.

Core Message Types

All MCP communication uses structured JSON-RPC 2.0 messages:
CategoryMethodPurpose
InitializationinitializeEstablish connection and negotiate protocol version
Initializationnotifications/initializedSignal session is ready
Discoverytools/listList available tools
Discoveryresources/listList available data sources
Discoveryprompts/listList available prompt templates
Executiontools/callExecute a specific tool
Executionresources/readRetrieve content from a resource
Executionprompts/getFetch a prompt template
Client Requestssampling/completeServer requests LLM completion from client
Client Requestselicitation/requestServer requests user input
Notificationsnotifications/tools/list_changedTool list updated
Notificationsnotifications/resources/list_changedResource list updated

Tasks (Experimental)

MCP includes an experimental Tasks feature that provides durable execution wrappers for long-running operations:
  • Long-Running Operations — track expensive computations, workflow automation, and batch processing
  • Deferred Results — poll for task status and retrieve results when operations complete
  • Status Tracking — monitor task progress through defined lifecycle states
  • Multi-Step Operations — support complex workflows spanning multiple interactions
Tasks wrap standard MCP requests to enable asynchronous execution for operations that cannot complete immediately.

Security Principles

MCP implementations must adhere to these core security principles:
Security is built into the MCP protocol — not bolted on afterward. All implementations must follow these principles from the start.
  • User Consent and Control — users must provide explicit consent before any data is accessed or operations are performed, with clear control over what is shared
  • Data Privacy — user data is only exposed with explicit consent and must be protected by appropriate access controls throughout the interaction lifecycle
  • Tool Safety — before invoking any tool, explicit user consent is required with clear understanding of the tool’s functionality and potential impact
  • Transport Layer Security — all communication channels must use appropriate encryption and authentication mechanisms
Implementation guidelines:
  • Implement fine-grained permission systems controlling which servers, tools, and resources are accessible
  • Use secure authentication methods (OAuth, API keys) with proper token management and expiration
  • Validate all parameters according to defined schemas to prevent injection attacks
  • Maintain comprehensive audit logs for all operations

Code Examples

Here are complete MCP server implementations with tools in four languages:
import asyncio
from fastmcp import FastMCP
from fastmcp.transports.stdio import serve_stdio

mcp = FastMCP(name="Weather MCP Server", version="1.0.0")

@mcp.tool()
def get_weather(location: str) -> dict:
    """Gets current weather for a location."""
    return {
        "temperature": 72.5,
        "conditions": "Sunny",
        "location": location
    }

if __name__ == "__main__":
    asyncio.run(serve_stdio(mcp))

Key Takeaways

  • MCP uses a client-server architecture where Hosts manage multiple Client connections to Servers
  • The ecosystem has three participants: Hosts (AI applications), Clients (protocol connectors), and Servers (capability providers)
  • Transport mechanisms: STDIO (local) and Streamable HTTP with optional SSE (remote)
  • Server primitives: Tools (functions), Resources (data), and Prompts (templates)
  • Client primitives: Sampling (LLM completions), Elicitation (user input), Roots (filesystem), and Logging
  • Experimental: Tasks provide durable execution wrappers for long-running operations
  • Built on JSON-RPC 2.0 with date-based versioning (current: 2025-11-25)
  • Security first: explicit user consent, data privacy, and secure transport are core requirements

Exercise

Design a simple MCP tool that would be useful in your domain. Define:
  1. What the tool would be named
  2. What parameters it would accept (and their types)
  3. What output it would return
  4. How a model might use this tool to solve user problems
  5. Whether it should carry a readOnlyHint or destructiveHint annotation

What’s Next

Continue to Module 2: Security in MCP to learn about the unique security challenges in MCP systems and how to protect your implementations.

Build docs developers (and LLMs) love