1 What is MCP (Model Context Protocol)?
Imagine your phone, your laptop, your headphones, and your camera all used to need a different shaped plug. What a mess — a drawer full of tangled cables! Then someone invented USB-C: one little plug that fits everything. Now any device can talk to any other device with the same cable. MCP is USB-C, but for AI. It's one standard way for an AI to plug into any tool — a calculator, your email, a database — without needing a special custom cable for each one.
MCP (Model Context Protocol) is an open standard (introduced by Anthropic in late 2024 and now widely adopted across the industry) for connecting AI models and agents to external tools and data sources. Back in Session 3 you learned about tool calling (also called function calling): how a model can ask the program around it to run a function — fetch the weather, query a database, send an email. MCP takes that idea and answers a bigger question: how do we make tools shareable and reusable across every app and every model, instead of wiring each one by hand?
The problem MCP exists to solve: N×M integrations
Before MCP, every AI application had to write its own custom integration code for every tool it wanted to use. If you had N AI apps and M tools, you could end up writing up to N × M separate integrations — a combinatorial explosion.
Say 4 different AI apps (a chatbot, a coding assistant, a research agent, a support bot) each want to use 5 tools (GitHub, Slack, a Postgres database, Google Drive, Jira). Without a standard, someone has to build and maintain 4 × 5 = 20 bespoke integrations. Add one new tool and you now owe 4 more. Add one new app and you owe 5 more. It never ends.
With MCP, each tool is wrapped once as an MCP server (5 servers), and each app speaks MCP once (4 clients). Now it's 4 + 5 = 9 pieces, and any app instantly works with any tool. N×M became N+M.
MCP replaces a tangle of one-off, custom integrations with one common language. Build a tool as an MCP server once, and every MCP-compatible model or agent can use it. Teach your app to speak MCP once, and it can use every MCP tool ever made. That's the "USB-C for AI" promise.
Why this matters now
- Reusability — the community builds a library of ready-made servers (filesystem, GitHub, databases, Slack…) that anyone can drop in.
- Vendor-neutral — because it's an open standard, an MCP server works whether the model behind it is Claude, GPT, Gemini, or a local model. You're not locked in.
- Separation of concerns — the people who build a tool and the people who build an agent don't have to coordinate. They just both speak MCP.
Function calling (Session 3) is the model's ability to request a tool. MCP is the plumbing standard for where those tools live and how they're discovered and run. You can think of function calling as "the model can ask for a tool," and MCP as "here's the universal socket those tools plug into." MCP uses function-calling under the hood.
2 MCP architecture: host, client, and server
Think of a restaurant. You (the hungry person) are the host — you decide what you want. The waiter carries your order back and forth; that's the client. The kitchen actually cooks the food and hands it back; that's the server. You never walk into the kitchen yourself — the waiter handles all the talking. MCP works the same way: a tidy little chain of host → client → server.
MCP has three roles. Getting these straight makes everything else click.
| Role | What it is | Restaurant analogy |
|---|---|---|
| Host | The AI application the user interacts with (e.g. Claude Desktop, an IDE, your custom agent built on the Agent SDK from Session 7). It contains the LLM and decides what needs doing. | The diner who decides what to order. |
| Client | A connector that lives inside the host. The host spins up one client per server. The client speaks the MCP protocol and manages the connection. | The waiter assigned to one kitchen. |
| Server | A separate program that exposes tools, data, and prompts. It does the actual work (read a file, query GitHub) and returns results. | The kitchen that cooks the order. |
How the model discovers and calls a tool
The beautiful part is discovery: the host doesn't need to know in advance what a server offers. When it connects, it simply asks. This is what makes MCP plug-and-play.
Under the hood, MCP messages use JSON-RPC — a simple, standard format
for "call this function with these arguments, send back this result." The connection can run over
different transports: stdio (the server runs as a
local subprocess, talking over standard input/output) for local tools, or HTTP-based transports for
remote servers. You usually don't worry about the transport — the client handles it.
You ask your IDE agent that question. (1) The host already connected its client to a
filesystem MCP server. (2) At connect time the client discovered the server
offers a list_directory tool. (3) The model, seeing this tool exists,
decides to call list_directory("/my/project"). (4) The server reads the
folder and (5) returns the list of files. The model then phrases a friendly answer. You never saw
any of the plumbing.
A single host can connect to many MCP servers at once — one for files, one for GitHub, one for your database — each through its own client. The model sees the combined menu of all their tools and mixes and matches as needed. This is exactly the same model that powers an Agent SDK agent (Session 7) choosing among its available tools.
3 Tool servers: tools, resources & prompts
An MCP server is like a toolbox you hand the robot. But it doesn't only hold tools (things the robot can do, like a hammer). It also holds resources (things the robot can read, like a book) and prompts (little instruction cards that say "here's a good way to use me"). Three kinds of helpful stuff, all in one box.
An MCP server can expose three different kinds of capabilities. Knowing the difference helps you understand what a server is really offering.
| Capability | What it is | Who controls it | Example |
|---|---|---|---|
| Tools | Actions the model can perform — functions that do something, often with side effects. | Model-driven (the model decides to call it). | create_issue, run_query, send_message |
| Resources | Read-only data the model can load as context — like files or records, addressed by a URI. | App/host-driven (the app chooses what to pull in). | A file's contents, a row from a database, a webpage |
| Prompts | Reusable prompt templates the server suggests for common tasks — pre-written instructions. | User-driven (the user picks one, e.g. a slash command). | "Summarise this PR", "Write a SQL query for…" |
The key distinction: tools act (and the model triggers them), resources inform (the app feeds them in as context — more on this in Topic 4), and prompts guide (handy templates the user invokes).
Examples of real MCP servers
- Filesystem server — tools to read, write, list, and search files in a folder. Resources for file contents. The classic "hello world" of MCP.
- Database server (e.g. Postgres/SQLite) — a tool to run queries, plus resources exposing table schemas so the model knows what columns exist before writing SQL.
- GitHub server — tools to read repositories, open issues, create pull requests, and review code; resources for file contents and issue threads.
- Web/search servers — tools to fetch a URL or run a search, giving the model fresh information beyond its knowledge cutoff (recall the cutoff problem from Session 1).
- Communication servers — Slack, email, calendars — tools to read and send messages or schedule events.
You ask: "How many orders did we get yesterday?" The model can't guess — it needs your data. It
(1) reads the resource describing your orders table schema, so it
knows the column names; (2) writes a SQL query; (3) calls the server's run_query
tool; (4) gets back "1,284" and answers in plain English. The resource taught it the shape of
your data; the tool fetched the actual number.
A tool that can write files, run queries, or send messages can also cause real damage if misused or if the server is malicious. Only connect to MCP servers you trust, and prefer read-only or scoped permissions when you can. We'll come back to security in Topic 8.
4 Context management: feeding the model cleanly
Remember the AI has a small "desk" it can lay papers on (its memory for one conversation)? You can't dump the whole library on the desk — it won't fit and the robot gets confused. MCP is like a tidy assistant who fetches only the few pages you actually need, in a neat standard format, and places them on the desk at just the right moment.
Back in Session 1 we met the context window — the fixed-size "desk" of tokens the model can consider at once (your prompt plus its answer). External data has to be fed into that window to be useful. Doing this messily — dumping huge files, inconsistent formats, stale data — wastes tokens (which cost money, Session 1) and confuses the model. MCP standardises how external context gets fed in.
What "clean" context management means
- On-demand, not all-at-once — instead of stuffing everything into the prompt up front, the model pulls in a resource only when it's actually needed, keeping the window lean.
- Standard format — resources arrive in a consistent MCP shape (a URI, a content type, the data), so the host and model handle every source the same way.
- Fresh, not frozen — because resources are fetched live from the server, the model sees current data, sidestepping the knowledge-cutoff limit (Session 1).
- Addressable — every resource has a URI (like
file:///report.pdfordb://orders/schema), so it can be referenced precisely rather than copy-pasted.
MCP turns "context" from a messy copy-paste problem into a clean, structured fetch. The right data, in a known format, pulled in only when needed — so the limited context window is spent on what matters.
Messy way: to answer a question about a 200-page manual, you paste the entire manual into the prompt. It barely fits, costs a fortune in input tokens, and the answer might be about page 3 anyway.
MCP way: the manual is a resource on a server. The model fetches just the relevant section as context when it needs it. Far fewer tokens, cheaper, and the model isn't drowning in irrelevant text. (This pairs naturally with RAG retrieval — MCP is a clean pipe for delivering retrieved chunks.)
If every app invented its own way to inject files and data, you'd get inconsistent formats and duplicated effort everywhere. By standardising the shape of context, MCP lets any host feed any server's data to any model uniformly — the same plug-and-play benefit from Topic 1, applied to data instead of actions.
5 Agent-to-agent (A2A) communication
One smart helper is great. But sometimes a job is too big for one. So instead of one robot doing everything, you get a team of robots, each good at one thing — one researches, one writes, one checks the math — and they talk to each other to get the job done together. Like a group project where everyone has a role and they pass notes back and forth.
So far an agent has used tools (Session 3) and the Agent SDK (Session 7). Now we let agents treat each other as collaborators. Agent-to-agent (A2A) communication is the pattern where multiple specialised agents exchange messages and share context to accomplish a task no single agent would handle as well alone.
Why split work across many agents?
- Specialisation — each agent gets a focused role, a tailored system prompt, and only the tools it needs. A "researcher" agent and a "writer" agent each do their job better than one generalist juggling both.
- Smaller, cleaner context — each agent's context window (Session 1) holds only what's relevant to its narrow task, instead of one giant overloaded prompt.
- Modularity — you can improve, swap, or reuse one agent without rewriting the whole system.
- Parallelism — independent sub-tasks can run at the same time.
What actually gets exchanged
When agents communicate, they pass two things:
| Thing | What it carries |
|---|---|
| Messages | The request or result in natural language (or structured data) — e.g. "Research the top 3 competitors" or "Here are the findings: …" |
| Shared context | The relevant background the receiving agent needs to do its part — the goal, prior results, constraints. Without this, the receiver is working blind. |
Easy mix-up. MCP connects an agent to tools and data (vertical: agent → tool). A2A connects an agent to other agents (horizontal: agent ↔ agent). One is "how do I use a tool"; the other is "how do I delegate to a teammate." There's even an emerging open A2A protocol aiming to standardise agent-to-agent messaging the way MCP standardised tools.
You ask: "Write me a briefing on electric-vehicle market trends." A research agent gathers data (using MCP web/search tools from Topic 3), then sends a message with its findings — plus the shared goal — to a writer agent, which drafts the briefing, then passes it to an editor agent that polishes it. Three specialists, talking to each other, produce a better result than one agent trying to research, write, and edit in a single overloaded prompt.
6 Orchestrator patterns: the manager & the workers
On a building site there's one boss with the blueprint who tells each worker what to build, then checks the pieces fit together. The workers don't all shout at once — the boss keeps everyone organised. In agent-land, that boss is the orchestrator, and the workers are the worker agents.
Once you have many agents (Topic 5), someone has to coordinate them. The most common and reliable design is the orchestrator pattern (also called the supervisor or manager pattern): one lead agent breaks the goal into sub-tasks, delegates each to a worker agent, collects the results, and assembles the final answer.
The orchestrator is itself an LLM-powered agent — it reasons about how to divide the work, which worker fits each piece, and whether the results are good enough or need another pass. This is a direct extension of the orchestration ideas from Session 7; the workers are often just other Agent SDK agents, and the orchestrator may even invoke them as if they were tools.
A simple text picture of the pattern
┌──────────────────┐
User ──────▶ │ Orchestrator │ (plans, delegates, synthesises)
└───┬────┬─────┬───┘
┌────────┘ │ └────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Worker A │ │ Worker B │ │ Worker C │ (specialists)
│ research │ │ write │ │ verify │
└──────────┘ └──────────┘ └──────────┘
Workers report back up to the orchestrator, which keeps the big picture. Workers usually don't talk to each other directly in this pattern — the supervisor is the hub.
Goal: "Plan a 3-day Tokyo trip under $1,500." The orchestrator splits this into: (A) find flights, (B) find hotels, (C) build a daily itinerary. It sends each to a specialist worker (each using its own MCP tools), collects flight options, hotel options, and an itinerary, then synthesises a single coherent plan that respects the budget — re-delegating if, say, the flights came back too expensive.
More agents means more LLM calls — which means more cost and more latency (recall token economics, Session 1). Multi-agent orchestration shines on genuinely complex, parallelisable tasks; for a simple request, a single agent is cheaper and faster. Don't reach for a committee to answer "what's 2+2?"
7 Handoff protocols: passing the baton reliably
In a relay race, one runner passes the baton to the next. If they fumble the handoff, the whole team loses — even if everyone runs fast. When one agent passes a job to another, it has to hand over the "baton" cleanly: here's what we're doing, here's what I found, here's what you need to do next. A good handoff makes sure nothing gets dropped.
Back in Session 7 you met handoffs — when one agent passes control of a task to a more suitable agent (e.g. a triage agent routing a refund request to a billing agent). A handoff protocol is the agreed-upon way of doing that transfer reliably, so the receiving agent can pick up smoothly without the user repeating themselves or context getting lost.
What must transfer in a clean handoff
| What transfers | Why it's essential |
|---|---|
| Control / who's in charge | It must be unambiguous which agent now owns the task, so two agents don't both reply or both go silent. |
| The goal & current task | The receiver needs to know what the user ultimately wants and where things stand right now. |
| Conversation history / state | What's been said and done so far, so the user doesn't have to re-explain (the model is stateless — Session 1 — so this must be passed explicitly). |
| Collected data & results | Anything already gathered (search results, a partial draft) so work isn't repeated. |
| Constraints | Budget, deadlines, user preferences, policies — the rules the new agent must still obey. |
Because every LLM is stateless (Session 1), the receiving agent remembers nothing on its own. A handoff isn't just "you take over now" — it must carry the full relevant context along with the baton, or the new agent starts blind. The quality of a multi-agent system lives or dies on the quality of its handoffs.
Handoff vs orchestration
Two related but different shapes. In orchestration (Topic 6), the supervisor stays in charge and delegates pieces, always pulling control back. In a handoff, control actually moves to the new agent, which now drives the conversation. Many real systems blend both: an orchestrator that can also fully hand off to a specialist when appropriate.
A general triage agent chats with a customer and realises it's a billing dispute. It hands off to the billing agent, passing along: the customer's identity and account (state), the full chat so far (history), the specific complaint (current task), and the company's refund policy (constraints). The billing agent picks up seamlessly — "I see you were charged twice on June 3rd, let me fix that" — without the customer repeating a word. A bad handoff would make the billing agent ask "Hi, how can I help you?" all over again. Frustrating, and a sign the baton was dropped.
8 Building MCP tools & production infrastructure
Building a tool for the robot is like building a new attachment for a toy robot: you give it a name ("grabber"), say what it does, list what buttons it needs (inputs), and write the bit that actually makes it work. Then, before you let lots of people use your robot, you have to make sure it's safe — it can't grab things it shouldn't, and it won't break if a hundred kids play with it at once.
Authoring an MCP tool/server (the shape of it)
Thanks to MCP being a standard with official SDKs (in Python, TypeScript, and more), writing a server is mostly about declaring your tools. Each tool needs four things — the same anatomy as the function definitions from Session 3:
- A name — e.g.
get_weather. - A description — plain-English text telling the model when and why to use it. This is read by the model, so write it clearly; a vague description means the model won't know to call your tool.
- An input schema — the parameters and their types (usually JSON Schema), e.g.
city: string. This tells the model exactly what to provide. - A handler — the actual code that runs when the tool is called and returns a result.
tool: "get_weather"
description: "Get the current weather for a city.
Use when the user asks about weather or temperature."
input_schema: { city: string (required) }
handler: (city) => call weather API, return temperature
Register that with an MCP server, point a host at it, and every MCP-compatible agent can now check the weather — without anyone writing a custom integration. That's the payoff from Topic 1 made concrete.
What running this in production involves
A server on your laptop is a demo. Serving real users reliably is a different game — and exactly what Session 13 (Deployment, Scaling & Final Demos) dives into. The big concerns:
| Concern | What it means in production |
|---|---|
| Authentication & authorization | Verify who is calling (auth) and what they're allowed to do (authz). A remote server must not let just anyone run its tools. Tokens, OAuth, scoped permissions. |
| Security | Validate and sanitise all inputs; never expose secrets; beware prompt injection (a malicious resource trying to hijack the agent). Give tools the least privilege they need. |
| Scaling | Handle many concurrent connections and tool calls without falling over — load balancing, stateless servers where possible, queuing slow work. |
| Reliability | Timeouts, retries, and graceful errors so one slow tool doesn't hang the whole agent. Rate limiting to avoid runaway cost (token economics, Session 1). |
| Observability | Logging, tracing, and monitoring every tool call so you can debug what the agent did and why — vital when multiple agents are involved. |
An MCP tool can take real actions — delete files, spend money, send emails. Combine that with prompt injection (where untrusted text the agent reads tries to trick it into misusing a tool) and the stakes are high. Always scope permissions tightly, require confirmation for dangerous actions, and treat any data an agent ingests as potentially hostile.
Everything here — auth, security, scaling, monitoring — is the bridge to our final session, where we deploy these agents and servers as real, running systems and show them off in the final demos.
★ Putting it all together
You just learned how agents connect to the wider world and to each other. Here's the one-paragraph story that ties all 8 topics together:
MCP is the "USB-C for AI" — an open standard that kills the N×M integration mess by letting any model plug into any tool. Its architecture is a tidy chain of host → client → server, where the host discovers what a server offers and the model calls it. A server can expose tools (actions), resources (read-only data), and prompts (templates), and it gives us clean context management — feeding the right data into the limited context window on-demand. Beyond single agents, agent-to-agent (A2A) communication lets specialists exchange messages and shared context, usually coordinated by an orchestrator (supervisor) that plans, delegates to workers, and synthesises results. When control truly moves between agents, a reliable handoff protocol carries the goal, state, data, and constraints so nothing is dropped — crucial because every model is stateless. Finally, you author an MCP tool by declaring its name, description, schema, and handler, and taking it to production means handling auth, security, scaling, and monitoring — which is exactly where Session 13 picks up.
Quick self-check
Why is MCP called the "USB-C for AI," and what problem does it solve?
Like USB-C is one standard plug for many devices, MCP is one standard way for any model/agent to connect to any tool. It solves the N×M integration explosion: wrap a tool as a server once and teach an app MCP once, so N+M pieces replace N×M custom integrations.
Name the three MCP roles and what each does.
Host (the AI app containing the model, decides what's needed), client (one connector per server, lives in the host, speaks the protocol), and server (a separate program exposing tools, resources, and prompts, and doing the actual work).
What's the difference between MCP and A2A communication?
MCP connects an agent to tools and data (agent → tool, vertical). A2A connects an agent to other agents (agent ↔ agent, horizontal). One is about using a tool; the other is about delegating to a teammate.
Why must a handoff carry the conversation state, not just say "you take over"?
Because LLMs are stateless (Session 1) — the receiving agent remembers nothing on its own. If the goal, history, collected data, and constraints aren't passed along, the new agent starts blind and the user has to repeat themselves.
You're taking an MCP server to production. Name two infrastructure concerns beyond just "make it work."
Any two of: authentication/authorization (who can call it and what they may do), security (input validation, least privilege, prompt-injection defence), scaling (handle concurrent load), reliability (timeouts/retries/rate limits), and observability (logging and tracing tool calls). These all lead into Session 13.
📚 References & Further Reading
Class material
- 📄 Original course notes / handout (source sheet) — open the shared GenAI class material for this session.
- Class handout: "Model Context Protocol & Agent Communication".
Papers, docs & deep dives
- Model Context Protocol — official site — the open standard at the heart of this session.
- MCP introduction & specification — host/client/server architecture, tools, resources, and prompts.
- Anthropic's MCP announcement — the original "USB-C for AI" introduction.
- Google Agent2Agent (A2A) protocol — an emerging open standard for agent-to-agent communication.
- JSON-RPC 2.0 specification — the message format MCP uses under the hood.