November 27, 2025 - Day 5: Understanding MCP — Host, Client, Server Architecture

I missed yesterday's diary because of a late-night call, so today I'm making up for it with a deep dive into MCP (Model Context Protocol) — the architecture, primitives, data flow, and practical challenges.

Section 4 in Hello Agents introduces MCP as the "USB-C for AI," a standard that allows LLM applications, tools, and external systems to communicate cleanly and consistently. Today I focused on the three fundamental components.

🧩 1. MCP = Host + Client + Server

MCP is composed of three layers, each with a distinct role:

🖥️ 1. MCP Host

This is the environment that runs MCP clients.

Examples:

• Cursor
• Claude Desktop (the one I'm using now)
• Future IDEs or AI-native operating systems

The host provides the runtime, the UI, and the ability to connect MCP clients inside it.

🧩 2. MCP Client

The middle layer that sits inside the host and connects to multiple servers.

An MCP host may have multiple MCP clients — each representing a different "capability module."

MCP clients provide two key primitives to help servers complete complex tasks:

• roots — define accessible resources or directory-like structures
• sampling — allow the server to request LLM sampling or reasoning tokens

Essentially, the MCP client handles task coordination and resource access.

🔌 3. MCP Server

The server is the true capability provider. This is where actual functionalities live.

It exposes three core primitives:

1. prompts — prompt templates or structured instructions
2. resources — files, database entries, embeddings, knowledge
3. tools — actions like API calls, database queries, file operations

In simple terms:

MCP Server = "What the LLM can actually do" MCP Client = "How it connects" MCP Host = "Where everything runs"

🔄 2. MCP Data Flow (Very Important)

Understanding the request-response cycle makes the architecture clear:

1. Client → Server: Initialize Connection Client sends a handshake request, server confirms and opens a session.

2. Client → Server: Execute Action Client sends a request such as:

   • "query the DB"
   • "read this file"
   • "call this API"

3. Server → Client: Process & Return Result Server parses the request, executes the action, and returns structured results.

4. Client → Server: Close Connection The client disconnects manually or the server disconnects after timeout.

This is the same pattern as modern protocol design (WebSocket, gRPC, RPC), but simplified and LLM-friendly.

⚠️ 3. Challenges of MCP (My Notes)

Although MCP is promising, it's still early, and I noted a few practical issues:

1. Manual tool activation → token waste

Each session must manually turn MCP tools on/off. If many MCP services are enabled, the LLM needs descriptions for all tools — increasing token cost.

2. Protocol standardization doesn't solve tool quality

Even if MCP defines "how to talk," it doesn't ensure:

• tools are good
• tools are efficient
• tools are safe

We still need tool evaluation systems, and the current setups are immature.

3. MCP servers require frontend frameworks & auth

Real MCP servers must implement:

• security
• authentication
• UI/UX integration
• wrapper frameworks

This makes languages like Java inconvenient, and Python/JS are preferred. Companies need engineering maturity to adopt MCP.

💬 4. Reflection

Today's topic was heavily architectural. MCP is powerful, but still evolving, and many parts of the ecosystem feel "early-stage."

It also completes the full evolutionary chain I studied this week:

AIGC → RAG → Function Calling → Agent → MCP

Each step solves the limitation of the previous one.

Tomorrow, I plan to summarize Day 1–Day 5, revisit the content, and consolidate everything into a clean mental model.

✨ End of Day 5.

🎯 My Learning Progress

Progress Bar: ■■■■■■■■■□ (90% - Nearly completed Hello Agents guide, mastered advanced concepts)