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:

  1. Model sees the prompt + available tool schemas → reasons
  2. Model emits a structured tool_use (name + arguments)
  3. Client intercepts it → wraps as a JSON-RPC request
  4. Transport carries the message to the server
  5. Server receives it → runs the real function
  6. Server serialises the result → sends it back
  7. Client injects the result into the model's context
  8. Model reads the new context → reasons about the next step
  9. 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.