MCP Architecture Explained: How the Protocol Actually Works Under the Hood

By /

MCP has three layers: Host (the AI app), Client (protocol handler), and Server (your tool). They communicate over a transport (stdio or HTTP) using JSON-RPC 2.0 messages. Here’s exactly how it works.

The Architecture

+------------------+     +------------------+     +------------------+
|      HOST        |     |     CLIENT       |     |     SERVER       |
|  (Claude, Cursor)|---->|  (MCP protocol)  |---->|   (Your tool)    |
|                  |     |                  |     |                  |
|  Manages AI      |     |  Handles JSON-RPC|     |  Exposes tools,  |
|  conversation    |     |  messages &       |     |  resources,      |
|                  |     |  transport        |     |  prompts         |
+------------------+     +------------------+     +------------------+

Key Concepts

1. Host

The AI application (Claude Desktop, Cursor, VS Code). It manages the conversation and decides WHEN to call tools. One host can connect to multiple servers simultaneously.

2. Client

The protocol layer inside the host. Handles connection lifecycle, capability negotiation, and message routing. You don’t build this – it’s built into the host.

3. Server

YOUR code. Exposes three types of capabilities:

  • Tools – Functions the AI can call (like API endpoints)
  • Resources – Data the AI can read (like files or database records)
  • Prompts – Pre-built prompt templates for common tasks

Message Flow (What Happens When AI Calls a Tool)

1. User: "Find hackathons about AI"
2. Host sends message to LLM
3. LLM decides to use search_hackathons tool
4. Host sends JSON-RPC request to server:
   {"method": "tools/call", "params": {"name": "search_hackathons", "arguments": {"query": "AI"}}}
5. Server executes the function
6. Server responds with results:
   {"result": {"content": [{"type": "text", "text": "[{name: 'Build with AI'...}]"}]}}
7. Host feeds result back to LLM
8. LLM generates human-readable response for user

Transports

stdio (Local)

Server runs as a child process. Communication over stdin/stdout. Best for local development and single-user tools.

Host spawns process -> pipes stdin/stdout -> JSON-RPC messages flow

Streamable HTTP (Remote)

Server runs on a URL. Communication over HTTP POST + Server-Sent Events. Best for shared/deployed servers.

Host connects to https://your-server.com/mcp -> HTTP messages flow

Capability Negotiation

When a client connects to a server, they exchange capabilities:

Client: "What can you do?"
Server: "I have 3 tools, 2 resources, 1 prompt template"
Client: "I support tool calling and resource reading"
Server: "Great, here are my tool definitions..."

This happens automatically. The AI knows what tools are available before the user asks anything.

Why This Architecture Wins

  • Decoupled – servers and clients evolve independently
  • Composable – one host connects to many servers simultaneously
  • Discoverable – AI learns available tools at runtime, not compile time
  • Secure – each server runs in its own process with its own permissions

Build MCP-powered apps at hackathons on Reskilll

Scroll to Top