Day 1 D1-P2 MCP Architecture Deep Dive

How a Model Actually Calls a Tool

▶ Open slide deck Code bundles & resources

The Agentic Harness

Model Context Protocol — how a model actually calls a tool

Day 1 · Phase 2

The Question This Hour Answers

Last session we said: agents take actions.

But how?

The model runs in a data centre. Your files are on your laptop. What connects them?

That gap is exactly what MCP bridges.

What MCP Is (in one line)

A standard protocol that lets any model host talk to any tool server — no matter who built either one.

Before MCP: every tool needed custom glue for every app. After MCP: build the server once, any MCP host can use it.

Think "USB-C for AI tools" — one connector, many devices.

Why a Standard Matters

WHY — without a shared protocol, every tool integration is bespoke and brittle; N tools × M apps = chaos.

WHAT — MCP is the agreed contract for discovery, calling, and results.

HOW — a model host speaks MCP to a server; the server exposes capabilities in a shape the model can read.

The whole point: write the server once, plug it in anywhere.

The Four Layers

The architecture, left to right:

HOST → CLIENT → SERVER → TOOL

HOST — the app the user talks to (in our labs: Antigravity)
CLIENT — the MCP connector inside the host
SERVER — the program you build that exposes tools
TOOL — the actual function that touches the real world

Reasoning lives in the host. Real effects happen at the tool. MCP is the wiring between them.

Layer 1 — HOST

WHY — something has to run the model and decide when a tool is needed.

WHAT — the LLM application the user interacts with; it contains the client.

HOW — it surfaces available tools to the model, and injects tool results back into the context.

The host is the manager: it knows what tools exist, but delegates the actual work. (In our labs: Antigravity. The concept is host-agnostic.)

Layer 2 — CLIENT

WHY — the model can't speak a wire protocol on its own; something must translate.

WHAT — the MCP client embedded inside the host.

HOW — it discovers servers, serialises tool-call requests, and deserialises responses.

You don't build the client — the host ships with it. It's the translator between model intent and protocol messages.

Layer 3 — SERVER

WHY — capabilities have to live somewhere the model can reach safely.

WHAT — a separate process that exposes tools, resources, and prompts.

HOW — it listens for JSON-RPC requests and runs the matching function.

This is what you build in the lab. A server can run locally or across the internet — it's just a process that speaks MCP.

Layer 4 — TOOL

WHY — this is where intent finally becomes a real-world effect.

WHAT — the actual function: read a file, call an API, write to a store.

HOW — the server invokes your code; your code does the thing and returns a result.

This is the Action step of the agent loop, made concrete. Everything upstream exists to get here safely.

The Lifecycle — One Tool Call, Step by Step

What actually happens when the model calls a tool:

Model sees the prompt + available tool schemas → reasons
Model emits a structured tool_use (name + arguments)
Client intercepts it → wraps as a JSON-RPC request
Transport carries the message to the server
Server receives it → runs the real function
Server serialises the result → sends it back
Client injects the result into the model's context
Model reads the new context → reasons about the next step
Repeat until the task is done

The Lifecycle — The Punchline

Notice step 7 → step 8:

The tool's result re-enters the model's perception.

That's the agent loop closing — the thing we drew last session, now happening over a wire.

MCP isn't separate from the agent loop. It's how the loop's "Action" step actually reaches the world and comes back.

The Six MCP Primitives

The spec defines six capabilities — three the server offers, three the client offers:

Primitive	Side	What it is
Tools	server	functions the model calls (side-effects, data) — read & write
Resources	server	data the model can read, like a file it can browse
Prompts	server	reusable templates a user/model can fill in
Sampling	client	the server asks the host's model to generate text
Elicitation	client	the server asks the user for more input mid-task
Roots	client	the client tells the server which paths it may touch

In practice only Tools is broadly supported (~99% of clients); the rest sit at 4–34%. You only need Tools for the labs — but know the other five exist by name.

Tools vs. Resources — Don't Confuse Them

The single most common mix-up:

Resource = read-only. The model gets data but changes nothing. Tool = read/write. The model takes action with side effects.

The analogy that sticks:

A resource is giving the model a PDF to read. A tool is giving it a keyboard and mouse.

Transport — How Client and Server Talk

Two channels. Choosing wrong is a classic setup mistake.

stdio (Standard In/Out)

Host launches the server as a child process; they talk over stdin/stdout
Local only · fastest · no network exposure
Best for: local tools (our labs use this)

SSE / HTTP (Server-Sent Events)

Server runs as an HTTP service; host connects via URL
Can run anywhere · slight network overhead · must be secured
Best for: remote/shared tools

Local server? stdio. Remote, multi-user? HTTP.

What Makes a Tool Schema Work

The model reads three things about every tool: name, description, input schema.

The description is where reliability is won or lost:

Say what it does and where ("...in the StackLog store")
Say when to call it ("call this when the user wants to save a note...")
Say what it returns ("returns the new entry ID")
Encode constraints ("title: max 80 characters")
Mark required fields, or the model will omit them

A vague schema = unreliable agent. The schema is the interface between language and action.

Schema Quality — Why It Matters So Much

The model decides whether and how to call your tool based almost entirely on the description.

A good description prevents:

the model calling the wrong tool
empty or malformed arguments
runaway values (500-char titles, missing content)

You're not just documenting the tool — you're programming the model's behaviour with prose.

Where This Leaves Us

You now know how an action actually reaches the world:

The host runs the model and holds the client
The client speaks MCP to your server
Your server runs the tool
The result flows back into perception — loop closed

Next: we stop talking and connect a real server, then build our own. That server becomes StackLog's data layer.

Two Quick Framings to Carry Out

Three kinds of tool a model can use:

Function tools — you define them (what you'll build in Lab 2)
Built-in tools — baked into the model (e.g. native web search)
Agent-as-tool — another agent called as a tool (the Day-2 "personas are subagents" idea)

Two protocols, two jobs:

MCP connects an agent to tools. A2A (Agent-to-Agent) connects an agent to other agents. Today is all MCP; A2A is the same instinct, one level up.

Anchor This

MCP answers one question: how does a model call a tool?

Host holds the model · Client speaks the protocol · Server exposes the tools · Tool changes the world · and the result re-enters perception.

Build the server once. Plug it in anywhere.