My Notes on Model Context Protocol Architecture: A Developer’s Dive

Hi there! I'm Shrijith Venkatrama, founder of Hexmos. Right now, I’m building LiveAPI, a tool that makes generating API docs from your code ridiculously easy. I’ve been poking around the Model Context Protocol (MCP) lately. It’s time to collect my thoughts into a post that’s dev-friendly and digestible. If you’re curious about wiring up AI apps with context and tools, stick around. MCP is a beast—sometimes a confusing one—so I’ll lean on the spec (updated March 2025), mix in my notes, and sprinkle some opinions where I feel they are warranted. Let’s dive in. What MCP Is Trying to Do MCP is about giving AI apps context and tools. Picture it as a set of connectors linking your AI to the world—data, user inputs, workflows, you name it. It runs on JSON-RPC, which you might recognize from remote procedure call setups. The goal? Make AI less of a generic black box and more of a context-aware system. It’s modeled after the Language Server Protocol (LSP)—think IDE autocompletion, but for AI capabilities. The spec lays out three key players: Hosts, Clients, and Servers. They team up to make things work, though the details can get messy fast. The Three Musketeers: Hosts, Clients, and Servers Meet the trio that powers MCP. Each has a distinct role in the architecture. Entity Role Analogy Host The LLM app that kicks things off and manages everything The brain Client Connectors inside the app that talk to servers The nervous system Server External services dishing out context and tools The outside world Hosts: Your AI app itself. It spins up clients, manages connections, and handles authorization. It also merges context and renders the UI. Clients: Middlemen created by the host. Each hooks up to one server, managing a stateful session and passing messages back and forth. Servers: External services feeding the AI with functions, resources, or workflows. Here’s a basic setup: 1 Host, 1 Client, 1 Server. Multiply that, and you’ve got MCP in motion. Check out the diagram below for a visual. Breaking Down Server Capabilities Servers are the core of MCP—they deliver three main things: functions, prompts, and resources. Let’s unpack them. 1. Functions Servers offer callable functions for the AI. Think of it like an API—need to grab data or crunch numbers? The server’s ready to help. 2. Prompts (Workflows) This part feels like Slack workflows got mashed in. Servers send templated messages and workflows—step-by-step guides for users. Each step breaks into three bits: Component What It Does Templated Message Pre-written text with placeholders Actions Buttons or triggers for user interaction Input Spots for users to add their own data Picture a workflow: “Upload a file [input], see a preview [message], hit confirm [action].” 3. Resources These are extras—text, images, whatever—to give the AI more context. Summarizing a doc? The server hands it over as a resource. Simple stuff. One head-scratcher: the spec calls client-server interactions “sampling.” Is that polling? Subscriptions? It’s unclear going just by the definitions, and that bugs me. I wish the writing was cleaner and tighter - given it is supposed to be authoritative. How Hosts and Clients Actually Work Now, let’s zoom into the host-client dynamic. This is where MCP gets tricky. Host: The Control Center The host runs the show. It spins up clients and keeps them in line. It decides who connects, for how long, and enforces security—like user consent or auth checks. It also merges context from clients so the AI stays coherent. Plus, it handles the UI or presentation. Think of it as a conductor juggling an orchestra. Client: The Messenger Clients are simpler but still fussy. Each connects to one server in a stateful session. They negotiate capabilities (“What can you do, server?”), route messages, and manage updates. They keep servers isolated for security too. Why stateful, though? That choice nags at me—more on that later. Here’s a typical exchange in action: Why MCP Feels Like a Puzzle With Missing Pieces Real talk: the MCP spec can be a bit tough to parse. The stateful design rubs me the wrong way. Why not go stateless with REST or WebSockets? Stateful means live connections, session tracking, and more headaches when things break. That “sampling” term? Still no clue. Maybe clients subscribe to server updates, but the spec doesn’t say. And the workflows feel tacked on—like someone said, “Let’s add Slack vibes!” without a clear why. Still, the LSP inspiration is clever. Standardizing AI context and tools could be huge. But right now, MCP still gives "in draft" vibe (which is OK given how recent it is). Where MCP Could Shine (and How to Use It) MCP’s got promise if you squint. Building a chatbot or content generator? Here’s where it might fit: Context Boost: Servers feed r

Apr 6, 2025 - 19:47

My Notes on Model Context Protocol Architecture: A Developer’s Dive

Hi there! I'm Shrijith Venkatrama, founder of Hexmos. Right now, I’m building LiveAPI, a tool that makes generating API docs from your code ridiculously easy.

I’ve been poking around the Model Context Protocol (MCP) lately.

It’s time to collect my thoughts into a post that’s dev-friendly and digestible.

If you’re curious about wiring up AI apps with context and tools, stick around.

MCP is a beast—sometimes a confusing one—so I’ll lean on the spec (updated March 2025), mix in my notes, and sprinkle some opinions where I feel they are warranted. Let’s dive in.

What MCP Is Trying to Do

MCP is about giving AI apps context and tools.

Picture it as a set of connectors linking your AI to the world—data, user inputs, workflows, you name it.

It runs on JSON-RPC, which you might recognize from remote procedure call setups.

The goal? Make AI less of a generic black box and more of a context-aware system.

It’s modeled after the Language Server Protocol (LSP)—think IDE autocompletion, but for AI capabilities.

The spec lays out three key players: Hosts, Clients, and Servers.

They team up to make things work, though the details can get messy fast.

The Three Musketeers: Hosts, Clients, and Servers

Meet the trio that powers MCP.

Each has a distinct role in the architecture.

Entity	Role	Analogy
Host	The LLM app that kicks things off and manages everything	The brain
Client	Connectors inside the app that talk to servers	The nervous system
Server	External services dishing out context and tools	The outside world

Hosts: Your AI app itself. It spins up clients, manages connections, and handles authorization. It also merges context and renders the UI.
Clients: Middlemen created by the host. Each hooks up to one server, managing a stateful session and passing messages back and forth.
Servers: External services feeding the AI with functions, resources, or workflows.

Here’s a basic setup: 1 Host, 1 Client, 1 Server. Multiply that, and you’ve got MCP in motion. Check out the diagram below for a visual.

Breaking Down Server Capabilities

Servers are the core of MCP—they deliver three main things: functions, prompts, and resources. Let’s unpack them.

1. Functions

Servers offer callable functions for the AI. Think of it like an API—need to grab data or crunch numbers? The server’s ready to help.

2. Prompts (Workflows)

This part feels like Slack workflows got mashed in. Servers send templated messages and workflows—step-by-step guides for users. Each step breaks into three bits:

Component	What It Does
Templated Message	Pre-written text with placeholders
Actions	Buttons or triggers for user interaction
Input	Spots for users to add their own data

Picture a workflow: “Upload a file [input], see a preview [message], hit confirm [action].”

3. Resources

These are extras—text, images, whatever—to give the AI more context.

Summarizing a doc? The server hands it over as a resource. Simple stuff.

One head-scratcher: the spec calls client-server interactions “sampling.” Is that polling? Subscriptions? It’s unclear going just by the definitions, and that bugs me. I wish the writing was cleaner and tighter - given it is supposed to be authoritative.

How Hosts and Clients Actually Work

Now, let’s zoom into the host-client dynamic. This is where MCP gets tricky.

Host: The Control Center

The host runs the show. It spins up clients and keeps them in line. It decides who connects, for how long, and enforces security—like user consent or auth checks.

It also merges context from clients so the AI stays coherent. Plus, it handles the UI or presentation. Think of it as a conductor juggling an orchestra.

Client: The Messenger

Clients are simpler but still fussy. Each connects to one server in a stateful session. They negotiate capabilities (“What can you do, server?”), route messages, and manage updates.

They keep servers isolated for security too. Why stateful, though? That choice nags at me—more on that later.

Here’s a typical exchange in action:

Why MCP Feels Like a Puzzle With Missing Pieces

Real talk: the MCP spec can be a bit tough to parse. The stateful design rubs me the wrong way. Why not go stateless with REST or WebSockets? Stateful means live connections, session tracking, and more headaches when things break.

That “sampling” term? Still no clue. Maybe clients subscribe to server updates, but the spec doesn’t say. And the workflows feel tacked on—like someone said, “Let’s add Slack vibes!” without a clear why.

Still, the LSP inspiration is clever. Standardizing AI context and tools could be huge. But right now, MCP still gives "in draft" vibe (which is OK given how recent it is).

Where MCP Could Shine (and How to Use It)

MCP’s got promise if you squint. Building a chatbot or content generator? Here’s where it might fit:

Context Boost: Servers feed real-time data or user history to your model.
User Flows: Workflows guide users through tasks—like file uploads or choices.
Modularity: Swap servers without rewriting everything.

Start small: one host, one client, one server. Play with JSON-RPC (refresh with this guide if needed). Test a server sending a resource or workflow. Let me know what your experiences with MCP are, in the comments!