Before writing a single line of code, you need the right mental model. Today you build the unshakeable foundation that every advanced MCP concept rests on — the architecture, the three primitives, and the exact problem MCP was designed to solve.
Imagine every USB device needing its own unique port shape — your mouse uses a triangle, your keyboard a hexagon, your monitor a star. That's exactly what AI integrations looked like before MCP. MCP is the USB-C moment for AI — one universal connector that works with everything, everywhere, all at once.
The Integration Nightmare That Broke Engineering Teams
Picture yourself as a senior engineer at a startup in early 2023. Your team has just decided to add AI capabilities to your product — and it's immediately painful.
You want your AI model to be able to search your company Notion, query your Postgres database, create GitHub issues, and send Slack messages. Sounds straightforward. Here's what actually happens:
~60%
Engineering time on glue code
4×
Integrations = 4× maintenance burden
0
Code reuse between AI tools
∞
One-off bespoke connectors
💀
The Real Pain
Before MCP, every AI provider had a different "function calling" format. A connector built for Claude was completely incompatible with GPT-4. You wrote the same GitHub integration three times for three different AI models. That's not engineering — that's punishment.
Each integration was a fragile, bespoke snowflake. The GitHub integration for Claude handled authentication differently than the GitHub integration for GPT-4. When the GitHub API changed, you had to update every single connector separately. When you hired a new engineer, they needed weeks to understand the custom wiring.
Now multiply this across an enterprise with 50 internal tools. This is what the AI industry was dealing with — and it was crushing productivity at exactly the moment when AI adoption was supposed to be accelerating.
🖥️
Deep Analogy: The Pre-USB World
In the early 1990s, every peripheral device had its own port. Your printer used a parallel port. Your mouse used PS/2. Your modem used a serial COM port. Your joystick used a game port. Adding a new device meant researching which port it used, whether your computer had an open slot, and whether the drivers were compatible. Sound familiar?
Then USB arrived in 1996. One port, one protocol, universal compatibility. You just plugged things in and they worked. Device manufacturers converged on one standard. The ecosystem exploded.
MCP is USB for AI integrations. Instead of every AI tool having its own custom connector format, MCP provides one universal protocol that any AI model can use to connect to any data source or capability.
Old World
Custom connector per AI × per tool
→
MCP World
One protocol. Any AI. Any tool.
😰
❌ Before MCP
Custom function format per AI provider
No code reuse between integrations
Auth logic duplicated in every connector
API change = update all connectors
Vendor lock-in baked into every integration
No standard for streaming or notifications
Security model inconsistent everywhere
🚀
✅ With MCP
One JSON-RPC 2.0 wire format, always
Build once, use with any MCP-compatible AI
Standardised capability negotiation
Ecosystem of reusable server implementations
Vendor-neutral, open specification
Built-in streaming via SSE / Streamable HTTP
Security model defined in the spec
02 — Definition
So, What Exactly is MCP?
The Model Context Protocol (MCP) is an open standard — created by Anthropic in November 2024 — that defines a universal communication protocol between AI models (like Claude, GPT-4, Gemini) and external tools, data sources, and services.
In one sentence: MCP is a standardized way for AI models to talk to the outside world.
🔑 The Key Insight: MCP doesn't change what AI models can think. It changes what they can do and see. It's the difference between a brilliant person locked in a room versus that same brilliant person connected to the internet, a phone, and a filing cabinet.
MCP is built on top of JSON-RPC 2.0 — a simple, battle-tested remote procedure call protocol. Every MCP message is a JSON object. Every MCP interaction follows the same predictable request-response (or notification) pattern. There are no proprietary binary formats, no vendor-specific quirks to memorise.
The spec defines three things an MCP server can expose — and that's it. Three primitives. Everything you'll ever build in MCP is a variation of these three concepts. We'll meet them formally in Section 4.
Nov
2024 — Public release
3
Primitives (Tools, Resources, Prompts)
JSON
RPC 2.0 wire format
MIT
Open source licence
💡
Why "Context" Protocol?
The word "context" is deliberate. The entire challenge with AI models is giving them the right context to be useful — what data exists, what actions are available, what instructions to follow. MCP is the protocol for managing and delivering that context in a structured, safe, and standard way.
🍽️
Analogy: MCP is the Restaurant System
Imagine a world-class restaurant. The AI model is the chef — brilliant, capable, but locked in the kitchen. The chef can only cook with what's brought to them.
Without MCP: customers scream orders through the kitchen wall. Dishes get delivered by whoever happens to be nearby. There's no standardisation. The chef never knows what's in the pantry unless someone physically walks in and tells them.
With MCP: a waiter system exists. The maître d' (Host Application) manages the overall dining experience. Waiters (MCP Clients) take orders and relay them perfectly. The kitchen (MCP Server) receives structured requests and sends back precisely formatted responses. The pantry, wine cellar, and supplier (external data sources) are all connected through standardised interfaces.
Restaurant Role
Maître d' → Waiter → Kitchen → Pantry
≡
MCP Role
Host → Client → Server → Data
03 — Architecture
The Three-Tier Architecture
MCP has a precisely defined three-tier architecture. Every interaction — no matter how complex — involves exactly these three roles. Understanding each one deeply is the most important thing you'll do on Day 1.
MCP Architecture — Full Stack View
🖥️
HOST APPLICATION
The outer shell — the app that the user actually interacts with. It owns the AI model instance and manages the overall conversation lifecycle.
Claude DesktopVS Code + CopilotYour Custom AppCursor IDE
🔌
MCP CLIENT
Lives inside the Host. One client per server connection. Handles the MCP protocol handshake, routes tool calls, and translates between AI requests and MCP messages.
The capability provider. Exposes Tools, Resources, and Prompts. Can run locally as a subprocess or remotely over HTTP. This is what you'll build in this course.
GitHub ServerPostgres ServerFilesystem ServerYour Custom Server
Host → ClientInternal API callIn-process, direct
Client ↔ ServerMCP ProtocolJSON-RPC 2.0 over Stdio or HTTP
Server → DataNative APIsREST, SQL, SDK, filesystem
🗄️Databases
🌐Web APIs
📁Filesystems
💬Messaging
☁️Cloud Services
Let's walk through each tier carefully, because confusing these roles is the #1 source of confusion for MCP beginners.
🖥️
The HOST — "The Manager"
The Host is the application the end user runs — Claude Desktop, your custom AI chat app, Cursor IDE. It owns the AI model (or connects to it via API), manages the conversation, and decides how many MCP servers to connect. One Host can connect to multiple MCP servers simultaneously through separate Client instances. The Host never talks directly to MCP Servers — it always goes through its Clients.
🔌
The CLIENT — "The Translator"
The Client lives inside the Host process. You create exactly one Client per Server connection. The Client's job is to speak fluent MCP — it handles the initialisation handshake (capability negotiation), serialises outgoing requests into JSON-RPC, deserialises incoming responses, and manages the connection lifecycle. Think of it as a bilingual secretary who converts the boss's vague requests into precise formal communications.
⚙️
The SERVER — "The Specialist"
The Server is the capability provider — and this is what you'll build throughout this course. It's a standalone process (or remote service) that exposes a specific set of capabilities: Tools the AI can call, Resources the AI can read, and Prompt templates the AI can use. Servers are intentionally narrow and focused. A GitHub Server handles GitHub. A Postgres Server handles Postgres. This makes them composable, testable, and reusable.
⚠️
Critical Distinction: Servers Don't Talk to Each Other
MCP Servers are isolated. Server A cannot call Server B. All orchestration happens at the Host/Client layer. This is a deliberate security and simplicity decision. You'll see why this matters in the advanced section when we build multi-server orchestration.
sequenceDiagram
participant U as 👤 User
participant H as 🖥️ Host (Claude Desktop)
participant C as 🔌 MCP Client
participant S as ⚙️ MCP Server
participant D as 🗄️ External Data
U->>H: "Search for open bugs in my repo"
H->>H: AI model decides to call search_github tool
H->>C: invoke tool: search_github(query="open bugs")
C->>S: JSON-RPC → tools/call {name:"search_github"}
S->>D: GitHub REST API call
D-->>S: Returns issue list (JSON)
S-->>C: JSON-RPC response {content:[{type:"text"...}]}
C-->>H: Structured tool result
H->>H: AI model reads result, forms response
H-->>U: "You have 7 open bug issues. The oldest is..."
This sequence is the heartbeat of every MCP interaction. Commit it to memory. Whether you're building a simple file reader or a complex multi-agent orchestration system, this same flow repeats thousands of times.
04 — Primitives
The Three Primitives — Everything MCP Is Built On
This is arguably the most important conceptual framework in all of MCP. Once you truly understand what Tools, Resources, and Prompts are — and more importantly what they are not — you'll be able to design any MCP server correctly.
Every MCP server you build for the next 89 days will expose some combination of these three, and only these three, primitive types.
🔧
Tools
Model-controlled · Action · Side-effects allowed
Functions the AI can call to take action or retrieve computed data. The AI decides when to call a Tool based on its reasoning. Tools can have side effects — writing files, sending messages, running code.
Application-controlled · Read-only · Contextual data
Structured data the Host application can read and include in the AI's context. Resources are URI-addressed (like file:///docs/readme.md). They're read-only — no side effects allowed.
Think of them as: The AI's eyes.
Identified by unique URIs
Controlled by the Host, not the AI
Text or binary content
No side effects — read only
Examples: database schema, file content, API docs, config
Pre-built, parameterised prompt templates that users can invoke. They standardise how the AI approaches common tasks. Prompts are user-triggered — they appear as slash commands or templates in the Host UI.
Tools are model-controlled (the AI decides when to call them). Resources are application-controlled (the Host decides what to expose). Prompts are user-controlled (the human picks which template to use). This separation of control is not arbitrary — it's a deliberate security and UX design decision baked into the MCP specification.
Here's a concrete example to make this concrete. Imagine you're building an MCP server for a code repository:
Primitive
Example in a Code Repo Server
Who triggers it
Side effects?
🔧 Tool
create_pull_request(title, body, branch)
AI model
Yes — writes to GitHub
🔧 Tool
run_tests(path)
AI model
Yes — executes processes
📂 Resource
repo://project/README.md
Host application
No — read only
📂 Resource
repo://project/schema.sql
Host application
No — read only
💬 Prompt
code_review(pr_number)
User (slash command)
No — generates instructions
💬 Prompt
write_tests(function_name)
User (slash command)
No — generates instructions
05 — Message Flow
Anatomy of a Message — From Thought to Action
Let's trace exactly what happens when a user asks their AI assistant to "search GitHub for open issues tagged 'bug'." This walk-through covers every layer of the MCP stack in real detail.
1
User speaks to the Host
The user types their request into Claude Desktop (the Host). The Host sends this message to the AI model (Claude) along with the current conversation history and a list of available tools — which it learned about during the MCP handshake.
// User message enters the Host context window "Find all open GitHub issues labelled 'bug' in my repo"
// Host prepends available tool schema to the system prompt: tools: [{ name: "search_issues", description: "...", inputSchema: { query: "string", label: "string" } }]
2
AI model decides to call a Tool
Claude processes the user's message, reasons about which tool to use, and generates a structured tool-call response instead of a text response. The AI doesn't execute the tool — it just requests the tool be called.
// Claude's internal reasoning (simplified): // "User wants GitHub issues. I have search_issues tool." // "I should call it with query=bug, label=bug"
The Host receives the tool-call response from the AI and routes it to the appropriate MCP Client. The Client serialises the request into a JSON-RPC 2.0 message — the exact wire format the MCP spec defines.
The Server receives the JSON-RPC message over Stdio (or HTTP). It validates the input schema, executes the handler function — which calls the real GitHub REST API — and formats the response into the MCP content structure.
The Server sends back a JSON-RPC response. The Client passes it to the Host. The Host feeds the tool result back into the AI's context. Claude then reads the result, reasons about it, and generates the final natural-language response for the user.
// Claude's final reply to user: "Found 7 open bugs. The most critical is #123..."
🔍
What is JSON-RPC 2.0? (30-second explanation)
JSON-RPC 2.0 is a stateless, lightweight remote procedure call protocol. Every message is a JSON object. Requests have: jsonrpc: "2.0", an id (string or number), a method (string), and optional params. Responses echo the same id and contain either a result or an error. That's the entire spec. MCP builds its entire communication layer on top of this simple foundation.
06 — Real World
Three Scenarios, One Protocol
Abstract concepts click when you see them applied to real problems. Here are three concrete scenarios showing how MCP works in practice — ranging from a solo developer to a Fortune 500 enterprise.
🧑💻 Scenario A: The Solo Developer
Priya is a freelance developer who uses Claude Desktop daily. She sets up a Filesystem MCP Server and a GitHub MCP Server. Now she can say:
"Read my project's README, look at the open issues, and write me a prioritised task list for this week."
1Host reads README via the Filesystem Resource URI
2Claude calls list_issues Tool on the GitHub Server
3Claude synthesises both into a Markdown task plan
4Priya accepts — Claude calls create_issue to track the plan
Total setup time: 20 minutes. Zero custom code. Two MCP servers from the community ecosystem.
👥 Scenario B: The Engineering Team
A 15-person startup builds a custom Postgres MCP Server that exposes their database schema as Resources and safe query functions as Tools. Every engineer gets access via their IDE.
"Show me the 5 customers with the highest churn risk based on last-30-day usage data."
1Claude reads the DB schema Resource to understand table structure
2Claude calls the execute_query Tool with a generated SQL statement
3Server validates the query (read-only, parameterised) and executes
4Results returned — Claude formats as a ranked list with reasoning
The same Postgres Server works for Claude, GPT-4, and Gemini. Write it once. Use everywhere.
🏢 Scenario C: The Enterprise
A global bank deploys an MCP ecosystem with 12 internal servers: compliance docs, CRM data, code repositories, incident management, and HR systems. All accessed through a secure custom Host application with audit logging.
"Draft a compliance report for Q3, pulling data from the CRM and cross-referencing our regulatory policy documents."
1Host loads regulatory policy PDFs as Resources from the Document Server
2Claude calls get_crm_summary Tool (with OAuth 2.0 auth) on the CRM Server
3Claude calls get_q3_transactions Tool on the Finance Data Server
4Claude synthesises a compliant report draft — every action logged via MCP audit middleware
All 12 servers are isolated, independently deployable, and each owned by a different team. MCP makes them compose perfectly.
07 — Comparison
MCP vs. Old Integration Patterns
You may have heard of OpenAI Function Calling or LangChain Tools. It's worth understanding exactly where MCP differs — because the distinction determines which approach to use when.
Feature
OpenAI Functions
LangChain Tools
MCP
Vendor neutral
❌ OpenAI only
❌ Framework-tied
✅ Any LLM
Wire protocol
Proprietary JSON
Python objects
JSON-RPC 2.0 (open standard)
Language agnostic
❌
❌ Python/JS only
✅ Any language
Resources (read-only data)
❌ Not a concept
❌ Workarounds only
✅ First-class primitive
Reusable ecosystem
❌ Per-app
⚠️ Limited
✅ 100s of community servers
Streaming support
⚠️ Limited
⚠️ Limited
✅ SSE + Streamable HTTP
Multi-server orchestration
❌
⚠️ Manual
✅ Native in spec
Prompt templates
❌
⚠️ Limited
✅ First-class primitive
🧭
When should you NOT use MCP?
MCP adds protocol overhead. For a quick, single-purpose chatbot with 2 static tools, raw function calling is simpler. MCP shines when you need: reusability across AI providers, a team of servers, Resources as first-class data, or a standardised ecosystem. If you're building anything meant to scale or share — use MCP.
📝 Knowledge Check
5 questions — verify you've nailed the Day 1 foundations. Click an option, then hit Check Answers.
Question 1 of 5
In the MCP architecture, which component is responsible for managing the JSON-RPC 2.0 connection to a Server?
A The Host Application
B The MCP Client
C The MCP Server
D The AI model directly
✅ The MCP Client (B) manages the protocol connection. The Host owns Clients — one per Server connection. The Client handles the handshake, serialises requests, and routes responses. The Host and AI model never touch the raw JSON-RPC layer directly.
Question 2 of 5
A developer wants to let the AI model read a database schema for context — but never modify it. Which MCP primitive is the correct choice?
A Tool — because it retrieves data
B Prompt — because it provides context
C Resource — because it's read-only structured data
D Either Tool or Resource
✅ Resource (C) is correct. Resources are specifically designed for read-only, application-controlled data that provides context. They have no side effects. A Tool could retrieve data, but using a Resource signals to the Host that this data is safe to include without executing anything.
Question 3 of 5
Which statement about MCP Servers is TRUE according to the specification?
A Servers can call other Servers directly
B Servers are isolated — they cannot call each other
C Servers own and manage the AI model instance
D One Client manages all Servers in the system
✅ Servers are isolated (B). This is a critical security and architectural rule. No Server-to-Server communication exists. All orchestration between multiple servers happens at the Host/Client layer. One Client per Server connection — not one Client for all.
Question 4 of 5
MCP is built on top of which underlying communication protocol?
A GraphQL
B gRPC / Protocol Buffers
C REST over OpenAPI
D JSON-RPC 2.0
✅ JSON-RPC 2.0 (D). All MCP messages — requests, responses, notifications — are JSON-RPC 2.0 objects. This gives MCP a simple, language-agnostic, human-readable wire format. Every message has jsonrpc: "2.0", an id, a method, and optional params or result.
Question 5 of 5
Which primitive is controlled by the USER (not the AI model or the Host application)?
A Tools — the user decides which to activate
B Resources — the user fetches them on demand
C Prompts — the user selects which template to invoke
D None — all three are controlled by the AI
✅ Prompts (C). The MCP control model is: Tools = model-controlled, Resources = application-controlled, Prompts = user-controlled. Prompts appear as slash commands or template pickers in the UI. The human explicitly chooses which playbook to activate.
Coming Up · Day 2
JSON-RPC 2.0 Deep Dive — The Wire That Carries Everything
Dissect every field of a real MCP message. Build a mock server by hand. Understand request IDs, error codes, and notification patterns.