MCP, explained the way it should have been the first time

The problem

Before MCP: the N×M integration tax

A useful model is a model with context. But every model vendor, every IDE and every assistant used to need its own private glue for every data source. Integrations multiply, and the multiplication is the whole problem.

The framing that makes it click

"AI is just a stack"

This is Eli's central teaching move, and it is the most useful sentence in the whole class: an LLM is one component of a stack, not the product. People say "AI" and mean the model. What actually ships is the model plus everything around it — and MCP is a piece of that "everything around it".

That is not a motivational aside — it is the selection criterion. MCP earns its place in the stack only if wiring a tool to a model solves someone's problem faster than not doing it.

Anatomy

Host, client, server — and why the middle one exists

Three roles. The confusing one is client, because it is not "the user" and it is not "the app" — it is a small connection object the app creates, one per server.

The three primitives

Tools, Resources, Prompts — and who is in charge of each

This is the table worth memorising. The distinguishing question is never "what data does it expose" but who decides when it gets used.

What a tool actually looks like on the wire

A tool is a name, a description and a JSON Schema. The model never sees your Python — it sees this.

{
  "name": "searchFlights",
  "description": "Search for available flights",
  "inputSchema": {
    "type": "object",
    "properties": {
      "origin":      { "type": "string", "description": "Departure city" },
      "destination": { "type": "string", "description": "Arrival city" },
      "date":        { "type": "string", "format": "date" }
    },
    "required": ["origin", "destination", "date"]
  }
}

That description string is doing more work than it looks like. It is the only thing the model reads when deciding whether to call your tool — which is why "tool poisoning" (see Security) is a real attack class, and why Eli's class spends time on rewriting descriptions when you swap models.

The conversation

What actually happens when you ask a question

Five messages, then an answer. The part beginners miss: the model does not call your tool. It asks the host to, and the host decides whether to obey.

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "tools/call",
  "params": {
    "name": "checkWeather",
    "arguments": { "city": "Paris" }
  }
}

Transports

Two pipes, one message format

The transport is how bytes get from client to server. It changes deployment, not semantics — the same JSON-RPC goes down either pipe.

The code

A server is a function with a docstring

The SDK's own words: you write no JSON Schema, no request parsing, no validation code, no protocol handling. Two type-hinted Python functions and a docstring. Everything below is lifted from Eli's class repository and the official SDK.

from datetime import datetime
from mcp.server.mcpserver import MCPServer

mcp = MCPServer("time-server")

@mcp.tool()
def get_time() -> str:
    """Return the current time (HH:MM:SS)."""
    return datetime.now().strftime("%H:%M:%S")

@mcp.tool()
def get_day_month_year() -> str:
    """Return the current day of the week."""
    return datetime.now().strftime("%A, %B, %Y")

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

from mcp.server.mcpserver import MCPServer

mcp = MCPServer("Business Hours Server")

@mcp.resource("hours://business")
def get_business_hours() -> str:
    """Provides the current hours of operation."""
    return (
        "Store Hours of Operation:\n"
        "Monday - Friday: 9:00 AM - 6:00 PM\n"
        "Saturday: 10:00 AM - 4:00 PM\n"
        "Sunday: Closed"
    )

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

And a tool that actually does something

From Eli's mcp-server-ping.py — the shape of every useful tool: validate the input, do the work, return a string. Here the agent gets network tools without ever holding a shell.

IPV4_PATTERN = re.compile(r"\b(?:\d{1,3}\.){3}\d{1,3}\b")

@mcp.tool()
def extract_ip(text: str) -> str:
    """Find and return the first valid IPv4 address in a block of text."""
    for candidate in IPV4_PATTERN.findall(text):
        try:
            ipaddress.IPv4Address(candidate)   # rejects things like 999.1.1.1
            return candidate
        except ValueError:
            continue
    return "Error: no valid IPv4 address found in the text."

That validation line is the whole argument for MCP over "just give the model a shell". You expose one bounded capability, not a terminal.

import asyncio
from mcp import Client

async def main() -> None:
    async with Client("http://localhost:8000/mcp") as client:
        result = await client.call_tool("add", {"a": 1, "b": 2})
        print(result.structured_content)   # {'result': 3}

asyncio.run(main())

The map is not the territory

Where the spec has moved since the class

An honest guide has to say this: the mental model you learn from a class filmed in October 2026 and the current specification are not the same document. The concepts below are stable; the wire has moved. Here is what changed, so a tutorial does not mislead you later.

Security

The part where you stop trusting the plumbing

MCP gives a model the ability to act. Everything interesting and everything dangerous follows from that. The official security guidance is not vague about this; here are the real named failures.

Four lenses, one subject

Ask the same protocol four different questions

A single explainer serves one reader. This is the same material interrogated from the perspectives that actually decide whether a thing gets adopted — learner, builder, security reviewer, architect.

Judgement

When MCP is the wrong answer

A guide that only argues for its subject is marketing. These are the cases where plain code wins, and saying so is the difference between a protocol and a religion.

Check yourself

Eight questions that prove you understood

Click a card to reveal the answer. If any of these surprise you, the section above it is worth a second read.

Provenance

Sources

Everything factual above traces to one of these. Quotations are verbatim from the transcript; diagrams are redrawn from the concepts, not copied.

1. Eli the Computer Guy — Intro to MCP: Model Context Protocol for AI Tool Use (published 17 Oct 2026, 31,806 views). youtube.com/watch?v=TXrZ0ymjbZs — the class this guide is built around. Transcript obtained via youtubetotranscript.com (YouTube blocks this host's IP range directly).
2. Silicon Dojo — class workbook and code samples, MCP - Model Context Protocol/. github.com/SiliconDojo/In-Person-Classes — the time server, ping tools and hours resource code above are his.
3. MCP documentation — What is the Model Context Protocol. modelcontextprotocol.io/docs/getting-started/intro — the USB-C analogy, and the list of clients that support MCP.
4. MCP documentation — Architecture overview. modelcontextprotocol.io/docs/learn/architecture — participants, the two layers, statelessness, primitives, subscriptions.
5. MCP documentation — Understanding MCP servers. modelcontextprotocol.io/docs/learn/server-concepts — the tools/resources/prompts table including "who controls it", and the protocol operations.
6. MCP documentation — Security best practices (protocol 2026-07-28). modelcontextprotocol.io/…/security_best_practices — confused deputy, token passthrough, consent and scope requirements.
7. MCP Python SDK (MIT). github.com/modelcontextprotocol/python-sdk — the 15-line server and 10-line client, and the "what you did not write" framing.
8. Anthropic — Introducing the Model Context Protocol. anthropic.com/news/model-context-protocol — the origin: open-sourced, created by David Soria Parra and Justin Spahr-Summers, early adopters Block and Apollo.