Slides

WEEK 05

# Can you beat a language model at Connect Four?

## First challenge a naive model, then your coding assistant

---

# Your arena

You play red. The computer plays yellow. Can you spot a winning move?

---

# Play first

## Launch the supplied game from your course folder

```bash
uv run scripts/update.py
uv sync --group examples --group gui --group mcp
uv run --group examples --group gui --group mcp python src/aiforlifescience/exercises/05_connect_four.py
```

Open **http://127.0.0.1:8055**. Start with **Direct LLM**, the default opponent.
It uses your course `.env`. Try to set a trap that the model misses.

1. **You are red.** Click a column of the board to drop your disc into its lowest empty space.
2. **Wait for yellow.** The computer replies automatically, then it is your turn again.
3. **Connect four red discs** horizontally, vertically or diagonally before the computer does.

Use **New game** to start again. **Local search** is an optional offline reference
that needs no API key. Later, your coding assistant will play yellow through MCP.

<aside class="notes">
All commands run from the folder containing pyproject.toml. The supplied app
is complete: students can play immediately and explore how the different
opponents choose their moves.
This independent case uses generated game states, with no CSV or Week 4 code.
If port 8055 is occupied, launch the app with --port 8056 and use port 8056 in
both the browser address and the MCP URL.
</aside>

---

# Four opponents, one referee

| Mode | Who chooses the computer's move? |
| --- | --- |
| Direct LLM | One chat request returns a structured move |
| Naive LLM (PydanticAI) | A model returns a typed move through PydanticAI, with no strategy tools |
| Decision API | A decision model selects among the legal columns |
| MCP + coding assistant | Your assistant reads the board and plays through MCP; it chooses how to reason |

**Python enforces the rules in every mode.** The model modes receive no strategy
tools. Local search is a separate, optional offline reference.

---

# Same move, different routes

Compare the system that selected the move with the code that accepted it.

---

# Structured output: make the answer usable

## A column is an integer, not a paragraph

```python
class Move(BaseModel):
    model_config = ConfigDict(extra="forbid")
    column: int = Field(strict=True, ge=0, le=6)
```

The direct request sends a JSON Schema using `response_format`.
The application parses and validates the reply, such as `{"column": 3}`.

A prompt saying “return JSON” alone does not enforce a schema.
Provider support must be checked; an unsupported request is a visible failure.

Reference: <a href="https://ai.pydantic.dev/output/">PydanticAI structured output and output modes</a>.

<aside class="notes">
This is a teaching excerpt; imports live in connect4_players.py. The direct
mode uses raw HTTP, no Agent and no tool loop. Native schema support depends on
the selected model/provider. Keep the raw format check and local validation
separate when explaining failures. Naive LLM (PydanticAI), whose internal mode
key is agent, uses PydanticAI's typed output mechanism, which can encode its
final result as an output tool call. This carries a structured answer; it does
not compute a strategy or give the model a board-analysis capability.
Reasoning tokens can consume the output token budget before the model emits
the move. A schema cannot prevent a truncated response. Distinguish an invalid
move object from a token-limit failure or a provider error when reading the trace.
</aside>

---

# Three different checks

| Check | Example | Who checks it? |
| --- | --- | --- |
| Format | `column` is an integer from 0 to 6 | Schema + local validator |
| Game rules | The column has space; the game is still running | Game engine |
| Move quality | This move blocks an immediate loss | Players observing the board |

`{"column": 3}` can pass the first check and fail either of the others.

**Correct structure does not establish correct judgment.**

---

# A framework does not supply a strategy

```text
board + rules → model → structured Move(column=...)
Python → validate against the current board → place disc
```

**Naive LLM (PydanticAI)** wraps the model with typed output and validation.
It receives no move-preview tool, search result, or recommended column.

The model chooses the move. Python checks whether the move is legal.
A valid answer can still lose the game.

Reference: <a href="https://ai.pydantic.dev/output/">PydanticAI structured output</a>.

---

# What can a coding assistant add?

## A model inside an application with workspace capabilities

Later, MCP will let your coding assistant read the board and submit a move.
We supply only these game interactions, with no strategy tools.

The assistant can reason about the board or decide to create its own helper
using its workspace. Watch which operations it chooses.

**Will it recognise that writing and testing code could help it win?**

---

# Can you outplay the naive models?

## Try Direct LLM, then Naive LLM (PydanticAI)

Play a few moves with the same chat model in both modes. Neither receives
strategy tools. Set a trap and see which opponent falls for it.

Watch the board as you play:

- Does yellow take an immediate win?
- Does it block your three-in-a-row before you win?
- Can you set up two threats so it cannot block both?

The game uses your course `.env`. Your coding assistant uses its own access.

<aside class="notes">
Students do not need a full match in every mode. Pause after a surprising move
and point out the missed win, missed block or developing trap on the board.
Use these observations to distinguish move quality from output formatting.
A few games do not establish that either interface improves the model's
strategic reasoning.
If the provider rejects native structured output, record that failure and use
the instructor-tested compatible model. Do not silently relabel prompted JSON
or a PydanticAI call as the direct structured mode.
</aside>

---

# Decision models: ask for a choice

## Give the model a state, a question and named alternatives

```text
state:       board, player to move, rules
question:    Which legal move should this player make?
alternatives: column_0, column_1, column_3, ...
answer:      selected alternative + distribution
```

Jev is one example of a model designed for bounded decisions.
PPQ exposes a separate **`POST /v1/decisions`** interface.

This interface does not imply that the model searches future game positions.

Sources: <a href="https://ppq.ai/api-docs">PPQ · Decisions</a>; <a href="https://docs.typesafe.ai/introduction">TypeSafe · Jev introduction</a>.

---

# The decision request

## The engine supplies only currently legal alternatives

```python
payload = {
    "model": "typesafe/jev-1.13",
    "state": board.as_dict(),
    "questions": {"move": {
        "type": "choice",
        "instructions": "Choose the strongest legal move.",
        "criteria": {f"column_{c}": f"Drop in column {c}."
                     for c in board.legal_columns()},
    }},
}
```

Read `answers.move.choice`, map it to a column, then validate again.
One legal move? Choose it locally. No legal move? The game has ended.

Contract: <a href="https://ppq.ai/api-docs">PPQ API documentation</a>. Choice requires at least two alternatives. This excerpt omits transport and error handling.

---

# Confidence is not a win probability

## A concentrated choice distribution can still select a losing move

The returned probabilities concern the **supplied alternatives**.
Jev's choice confidence is derived from that distribution.

Check a position with an immediate win, then one requiring a block.
The engine can determine whether the selected move passes either test.

Use `GET /v1/decisions/models` to discover supported models.
Different models may make very different choices from the same board.

Sources: <a href="https://docs.typesafe.ai/confidence">TypeSafe · Confidence</a>; <a href="https://api.ppq.ai/v1/decisions/models">PPQ decision model catalog</a>. Interface checked 7 October 2026.

---

# Can a decision model spot your trap?

Select **Decision API** and give it a game. The default is `typesafe/jev-1.13`.

Try leaving an obvious win, or threaten one of your own. Does it notice?
Can the same kind of trap that worked against a chat model fool this opponent?

The course PPQ key serves this mode too. You can switch the decision model with
`DECISION_MODEL` in `.env`, or keep playing offline with **Local search**.

---

# What problem does MCP solve?

## Let a separate application discover and call your game's tools

Without a shared protocol, each assistant integration needs custom connection
and message handling. MCP standardizes capability discovery and tool calls
between a client and a server.

Our server advertises `get_board` and `play_move`, including their argument
schemas. A compatible coding assistant can use that interface.

MCP supplies the connection. The engine still enforces the rules; the player
still needs a strategy.

Reference: <a href="https://modelcontextprotocol.io/docs/getting-started/intro">Model Context Protocol introduction</a>.

---

# Meet the cast: host, client, server

The host coordinates the experience. The client speaks MCP. The server provides capabilities.

Source: <a href="https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture">MCP architecture</a>. Tour checked against protocol 2026-07-28 on 7 October 2026.

<aside class="notes">
The model does not open the connection itself. The host presents available
capabilities to the model and mediates calls. Servers may wrap a local
program, an ordinary web API or a database; they need not contain an LLM.
Examples beyond Connect Four are illustrative.
</aside>

---

# MCP in practice: Blender

A community integration for a real 3D application. Generated Python runs inside Blender: review the code and inspect the resulting scene.

Example: <a href="https://github.com/ahujasid/mcp-for-blender">MCP for Blender · ahujasid</a>. Architecture checked 11 October 2026.

<aside class="notes">
Blender is a 3D creation application. This community project is independent of
the Blender Foundation. It supplies a Python MCP server and an add-on running
inside an open Blender application. The assistant's host launches the MCP
server and communicates over stdio; the server connects to the add-on through
a local TCP socket, by default localhost:9876. That second connection is the
project's own JSON command protocol, not another MCP transport.
The assistant can read the scene with get_scene_info, run Blender Python through
execute_blender_code, and inspect an image with look before requesting a revision.
The model proposes operations; Blender computes the scene and images. The return
arrow summarizes feedback, not the exact screenshot transfer implementation.
Python runs with Blender's local access; the narrow game bridge exposes much
less authority. The user still judges whether the result matches the request.
This is a theory example, not an additional installation task for students.
Follow with the live Idiap Café demonstration on the next slide.
</aside>

---

# Live demo: Idiap Café

A browser experience created by William Droz with help from Blender MCP tools. What did the assistant do, and how was the result checked?

Live demonstration: <a href="https://www.idiap.ch/~wdroz/idiap_cafe/" target="_blank" rel="noopener noreferrer">Open Idiap Café · A little coffee break.</a> Screenshot supplied by the instructor.

<aside class="notes">
Open the café before class and let its assets load. Use the on-screen play or
resume button, then demonstrate movement (WASD, ZQSD or arrow keys), mouse look,
F to interact or sit, E to drink and Esc to pause. Keep this screenshot as a
fallback if the live site is unavailable.

Point out one scene element developed with Blender MCP tools and explain the
actual workflow used. Prepare a saved assistant request, its tool call and a
before-and-after scene view if available. Compare the generated Python before
and after a correction; show how the result was inspected in Blender and tested
in the browser. Ask students which visual or interaction check would reveal a
mistake that a successful tool response could miss.

Distinguish the assistant's proposed code, Blender's computed scene and the
browser's rendering and interaction logic. The published experience illustrates
the result of development with MCP; it does not establish a live MCP connection
in the browser. The preceding diagram is an example integration, not a claim
about every tool used to build the café. Students observe this demonstration;
no Blender installation is required.
</aside>

---

# A server can offer three different things

Typical control: tools by the model, resources by the application, prompts by the user. The host chooses the interface.

Source: <a href="https://modelcontextprotocol.io/docs/2026-07-28/learn/server-concepts">MCP server concepts</a>.

<aside class="notes">
These control labels describe intended interaction patterns, not security
permissions or mandatory UI widgets. A host may show tools as buttons or make
resource selection automatic. game://rules and coach_me are proposed examples,
not features supplied by our bridge. get_board remains a tool even though it
only reads data.
</aside>

---

# From “what can you do?” to a real call

Discovery gives the assistant a menu. Calling a tool executes one operation from that menu.

Sources: <a href="https://modelcontextprotocol.io/specification/2026-07-28/server/discover">Discovery</a>; <a href="https://modelcontextprotocol.io/specification/2026-07-28/basic">message format and metadata</a>.

<aside class="notes">
In 2026-07-28, each request includes version and client capabilities in
params._meta; the SDK builds this envelope. server/discover is mandatory for
servers but optional for clients. The current course environment's mcp-types
2.1.1 supports this revision and older revisions. In 2025-11-25 and earlier,
initialize and notifications/initialized establish the protocol lifecycle.
Do not assume an arbitrary student client supports the newest revision.
The discovery and call arrows are protocol messages, not model chat messages.
</aside>

---

# The tool menu includes a contract

## A shortened declaration for our game

```json
{
  "name": "play_move",
  "inputSchema": {
    "type": "object",
    "properties": {
      "column": {"type": "integer", "minimum": 0, "maximum": 6},
      "revision": {"type": "integer", "minimum": 0}
    },
    "required": ["column", "revision"]
  }
}
```

Tools can return **text, images, audio, resource links or structured data**.
An optional `outputSchema` describes the structured result.

Source: <a href="https://modelcontextprotocol.io/specification/2026-07-28/server/tools">MCP tools</a>. Input schema excerpt from our bridge; descriptions and generated titles omitted.

<aside class="notes">
This is a tool definition, not a complete JSON-RPC request. The application
still checks whose turn it is and whether a column is full. Tool-produced
structuredContent is computed server output; it is distinct from constraining
a model's generated answer with a response schema.
</aside>

---

# Same protocol, two ways to connect

Our game serves Streamable HTTP at <code>http://127.0.0.1:8055/mcp/</code>. Starting the game also starts its MCP endpoint.

Sources: <a href="https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/stdio">stdio</a>; <a href="https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http">Streamable HTTP</a>.

<aside class="notes">
SSE means Server-Sent Events. It is a way to stream response events, not a
separate AI capability. The older HTTP+SSE transport was superseded by
Streamable HTTP. Current 2026-07-28 HTTP uses POST; older examples may show a
separate GET stream and sessions. With stdio, logging belongs on stderr so
stdout stays readable as protocol messages. Ending stdio closes the process
streams; it is separate from finishing one tool call.
</aside>

---

# Resources give context an address

## Imagine adding a small game library

| Resource | What the host could read |
| --- | --- |
| `game://rules` | The rules of Connect Four |
| `game://openings/center-first` | A saved opening |
| `game://matches/{match_id}` | A template for retrieving any saved match |

`resources/list` discovers fixed entries. `resources/templates/list`
discovers parameterized addresses. `resources/read` retrieves their contents.

The host decides which contents reach the model.

Source: <a href="https://modelcontextprotocol.io/specification/2026-07-28/server/resources">MCP resources</a>. Illustrative additions; our bridge exposes two tools.

<aside class="notes">
A resource URI identifies data; it need not be a public web URL or a local
file path. Resource contents may be text or binary, with a MIME type. Listing
a resource does not put its entire contents into the model context. A tool
can also return a resource link for the host to fetch later.
</aside>

---

# Prompts package a useful starting point

## Imagine a “coach me” option in the assistant

```text
User chooses:   coach_me(level="beginner")
Client fetches: prompts/get
Server returns: prepared messages about explaining the current position
Host presents:  those messages to the model
```

A prompt may include text and referenced context. It can guide a workflow
that later calls tools.

**Argument completion** can suggest values as you type:
`"beg"` → `"beginner"`.

Sources: <a href="https://modelcontextprotocol.io/docs/2026-07-28/learn/server-concepts">MCP prompts</a>; <a href="https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/completion">argument completion</a>. Illustrative addition.

<aside class="notes">
prompts/list discovers templates; prompts/get returns their prepared messages.
Fetching a prompt does not itself run a model or play a move. completion/complete
suggests arguments for prompts and resource templates; it is not an LLM text
completion endpoint. A particular host may expose prompts as slash commands,
a menu or another interface.
</aside>

---

# Elicitation: a tool asks you

Elicitation lets the server request missing input through the host, with the user choosing how to respond.

Sources: <a href="https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation">Elicitation</a>; <a href="https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr">multi round-trip requests</a>.

<aside class="notes">
This diagram uses the 2026-07-28 pattern: the server embeds an elicitation
request in an input_required result and the client retries with inputResponses.
Earlier revisions used server-initiated requests. Form mode must not collect
passwords, API keys or payment credentials. URL mode sends the user to an
external flow; accepting the URL does not establish that the flow completed.
URL elicitation for a third-party service is separate from authorizing access
to the MCP server itself.
</aside>

---

# Three features you may still meet

## Useful vocabulary when reading older MCP examples

| Feature | Original idea | Direction for new implementations |
| --- | --- | --- |
| **Sampling** | Server asks the host to run a model | Call a model provider API directly |
| **Roots** | Client shares relevant workspace paths | Pass paths in arguments, resource URIs or configuration |
| **Logging** | Server sends log messages to the client | Use stderr or observability tooling |

All three are **deprecated in protocol 2026-07-28**.
They remain in the specification for compatibility; client support varies.

Sources: <a href="https://modelcontextprotocol.io/specification/2026-07-28/deprecated">deprecation registry</a>; <a href="https://modelcontextprotocol.io/specification/2026-07-28/client/sampling">sampling</a>; <a href="https://modelcontextprotocol.io/specification/2026-07-28/client/roots">roots</a>; <a href="https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/logging">logging</a>.

<aside class="notes">
Sampling uses the host's model access under host control; an MCP server is not
automatically an independent agent. Roots are informational workspace hints,
not an operating-system sandbox. Deprecation is not immediate removal. These
features are eligible for removal no earlier than a revision released on
2027-07-28. They are included to make the wider ecosystem intelligible, not
because our game bridge needs them.
</aside>

---

# MCP can keep the interface feeling alive

| Feature | What it adds |
| --- | --- |
| **Progress** | “800 of 2,000 positions explored” during a request |
| **Cancellation** | Ask an operation to stop when you no longer need it |
| **Change notifications** | Learn that the tool menu or a watched resource changed |
| **Pagination** | Browse a large catalog in manageable pages |

A request has an ID and expects a response.
A notification is a one-way update without a response.

Sources: <a href="https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/progress">progress</a>; <a href="https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/cancellation">cancellation</a>; <a href="https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http">notification streams</a>; <a href="https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/pagination">pagination</a>.

<aside class="notes">
Features need compatible support. A client can request progress using a
progressToken, but a server is not required to emit updates. In 2026-07-28,
change notifications use an opt-in subscriptions/listen stream. HTTP
cancellation closes the request's SSE stream; stdio sends notifications/cancelled.
Cancelling work does not undo an action already completed. Cursors page through
catalogs without imposing one universal page size.
</aside>

---

# Beyond a single tool reply

There are extensions for richer experiences, including skills discovery. Support depends on both the host and the server.

Sources: <a href="https://tasks.extensions.modelcontextprotocol.io/specification/2026-07-28/tasks">Tasks extension</a>; <a href="https://modelcontextprotocol.io/extensions/apps/overview">MCP Apps</a>; <a href="https://modelcontextprotocol.io/extensions/overview">extensions catalog</a>.

<aside class="notes">
Tasks is now an optional extension; it was an experimental core feature in
2025-11-25. A supported long-running tool may return a task handle, with polling
and a later result rather than one immediate final answer. These examples are
ideas, not implemented course features. An ordinary tool returning an image
does not become an MCP App: Apps adds a host-rendered interactive UI.
</aside>

---

# Connecting also means choosing access

Remote access can use OAuth. Our game's local HTTP MCP endpoint needs no authentication or token.

Sources: <a href="https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization">MCP authorization</a>; <a href="https://modelcontextprotocol.io/specification/2026-07-28/server/tools">tool permissions and annotations</a>.

<aside class="notes">
This diagram shows a protected remote service, not our local game's setup.
MCP's HTTP authorization framework uses OAuth 2.1; authorization itself is
optional. stdio does not use this OAuth flow: process permissions and any
configured credentials govern access. A tool's readOnlyHint is metadata from
its server, not an enforcement mechanism. Retrieved text remains source
material; it cannot grant new host permissions.
</aside>

---

# Your assistant joins the game

Yellow plays → you play red → the updated board returns to the assistant.

References: <a href="https://modelcontextprotocol.io/docs/learn/architecture">MCP architecture</a>; <a href="https://gofastmcp.com/integrations/fastapi">FastMCP mounting</a>. Local server supplied with this lab.

---

# Connect the harness

## Keep the game running; select MCP + coding assistant

Ask your coding assistant to configure its own connection:

> Add this course's Connect Four server to your MCP configuration using
> Streamable HTTP at `http://127.0.0.1:8055/mcp/`, named `connect4`.
> It runs locally and needs no authentication or token. Connect, then call get_board.

Your assistant should find **`get_board`** and **`play_move`**.
If its settings require a restart or reconnect, follow its instructions.
Starting the game already starts its MCP endpoint.

<aside class="notes">
Field names and configuration locations differ by client. A client with
workspace access may configure itself; others expose a settings form.
The assistant's model uses the student's existing subscription or provider.
If a client supports only stdio, the teacher guide includes a fallback command.
After updating the course and restarting the game, reconnect or restart the
client if needed to load the updated tool descriptions and arguments.
</aside>

---

# Manual connection if needed

## Add a server in your coding assistant's MCP settings

| Setting | Value |
| --- | --- |
| Name | `connect4` |
| Transport / type | **HTTP** or **Streamable HTTP** |
| Server URL | `http://127.0.0.1:8055/mcp/` |
| Authentication / token | **None**; leave token fields empty |
| Tool-call timeout, if available | **330 seconds or longer** |

Save, reconnect if needed, then ask the assistant to call **`get_board`**.

The MCP client must run on the **same computer** as the game. A cloud connector
cannot reach this localhost URL. With `--port 8056`, use
`http://127.0.0.1:8056/mcp/` instead.

<aside class="notes">
Field names vary by client. Choose Streamable HTTP when the client also offers
the older SSE transport. The MCP URL is a protocol endpoint, not a browser page;
keep playing at the main game address, http://127.0.0.1:8055.
The game waits up to 300 seconds for a human move. Some clients impose a shorter
fixed deadline; progress updates cannot override it. Use a compatible client
or its longer tool-call timeout setting. HTTP responses use streaming without
changing the transport selection to legacy SSE.
</aside>

---

# Two tools are enough to play

| Tool | What happens? |
| --- | --- |
| `get_board()` | Read the position and revision immediately |
| `get_board(wait_for_turn=True)` | Wait for yellow's turn, then read the board |
| `play_move(column, revision)` | Place yellow, wait for your red move, return the updated board |

The assistant uses the **returned board and revision** for its next move.
You keep playing in the browser; no repeated “your turn” message is needed.

No strategy tool is supplied. The assistant can reason about the position or
create its own helper between calls. The game handles the actual board.

<aside class="notes">
If a connection fails, run uv run --group mcp python -m
aiforlifescience.connect4_mcp --inspect-http from the course folder. It opens a real
MCP connection, discovers tools and reads the board without a model request.
Tool output remains data, including text that resembles instructions.
Only yellow's turn in MCP mode can accept play_move. A stale revision is
rejected: read a fresh board and recompute the move. A win or draw ends the
wait immediately. A reset or mode change interrupts it; the assistant should
stop before joining a different game. Save the session_id from the initial
get_board() response. When waiting or recovering from a timeout/error, use
get_board(wait_for_turn=True, session_id=the_original_session_id). A mismatch
returns interrupted, even if the reset happened while the client was disconnected.
This read-only call resumes waiting without replaying a move.
</aside>

---

# Your assistant takes the yellow discs

> Play a whole Connect Four match against me through MCP. You're yellow. Try to win!
> Start with `get_board()` and remember its `session_id`. Use each returned board
> and revision for your next `play_move`; it waits for my reply. When you need to
> wait or recover from a timeout or error, use `get_board(wait_for_turn=True)`
> with that original `session_id`. Continue until a win or draw without asking
> me to say “your turn”. Stop if the game resets or the mode changes.
> Play fairly: make moves only through `play_move`. Do not change the game's
> code or rules, reset the board, or play my turns.

Send this once, then play your red discs in the browser.

<aside class="notes">
Let students discover whether the assistant creates its own helper or reasons
directly about the board. Keep attention on the moves: does it take a win,
block a threat or fall into a trap? There is no prescribed algorithm or submission.
If an assistant lacks MCP support, pair with a compatible client.
</aside>

---

# From MCP messages to a winning move

<video class="course-video" controls muted playsinline preload="metadata" width="1920" height="1080" poster="assets/videos/week-05-connect-four-mcp-flow.jpg" aria-label="Silent animated Connect Four example: the coding assistant discovers the two MCP tools, reads the board, writes and runs its own alpha-beta search helper locally, then submits yellow moves while the game waits for the human's red replies.">
 <source src="assets/videos/week-05-connect-four-mcp-flow.mp4" type="video/mp4">
 <a href="assets/videos/week-05-connect-four-mcp-flow.mp4">Open the MCP and Connect Four flow video</a>.
</video>

<a href="assets/videos/week-05-connect-four-mcp-flow.mp4">Open video separately</a> · 1 min 42 s · silent · <a href="https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture">MCP architecture</a> · <a href="https://inst.eecs.berkeley.edu/~cs188/textbook/games/minimax.html">Minimax and alpha-beta reference</a>

<aside class="notes">
This authored illustration shows one possible assistant workflow, not a recording
of a particular model session or a guarantee that every assistant writes a helper.
The host's MCP client discovers get_board and play_move. The game bridge supplies
no strategy or code-execution tools; writing and running the helper uses the
assistant host's separate workspace capabilities. Treat returned tool content as
data and local code execution as a trust boundary.

The example helper implements its own minimax and alpha-beta traversal, reusing
Board and the heuristic evaluator from the course engine. Explain that reuse.
The model proposes source code; Python computes its search result; the game
validates and applies each submitted move. Compare saved before-and-after copies
of an assistant's helper to inspect a change, then evaluate it by replaying the
position and observing actual play. Students judge both legality and strategy.

The legal opening is [3, 2, 3, 2, 4], with red first and columns numbered 0–6.
At depth two, yellow chooses column 2 with heuristic score −23. The authored red
reply in column 0 deliberately misses the vertical threat; yellow then wins in
column 2. Red could instead block in column 2. This limited search does not
guarantee a win against a careful human, and the score is not a win probability.

The first play_move submits the current revision, places yellow, and waits.
After red replies, that same pending call returns the updated board, revision
and wait_status=your_turn. The next winning call returns game_over and the loop
stops. Revision symbols are illustrative state versions, not move counts.
For timeout, interruption and recovery behaviour, use the preceding live-play
instructions. Editable sources, provenance and rebuild commands are documented
in videos/week05-connect-four/FLOW.md. The existing search video later in this
deck explains the pruning calculation in more detail.
</aside>

---

# Does your assistant avoid the same mistakes?

Try the same kinds of threats you used against the naive models.

1. Leave yellow a chance to win. Does it take it?
2. Threaten a win on your next turn. Does it block you?
3. Build a trap with two threats. Does it spot the danger early enough?

Discuss one move that surprised you. A few games reveal examples of strengths
and limitations; they do not establish which opponent is best.

<aside class="notes">
If the assistant uses a helper, briefly distinguish its computed result from
the model's own reasoning and the board state returned by MCP. Students
evaluate the resulting play by watching the board.
</aside>

---

# Why might it build a search helper?

## Minimax: choose a move assuming the opponent responds well

Search alternates between our moves and the opponent's replies.
Score wins, losses and draws exactly; estimate positions at the depth limit.

**Alpha-beta pruning** skips branches that cannot change the current choice.
With the same depth and evaluation, it preserves minimax's result.

Depth 4 means four future disc placements, not four full rounds.
A limited-depth search can miss a tactic beyond its horizon.

Reference: <a href="https://inst.eecs.berkeley.edu/~cs188/textbook/games/minimax.html">UC Berkeley CS188 · Minimax and alpha-beta pruning</a>.

---

# Watch the search choose a move

<video class="course-video" controls muted playsinline preload="metadata" width="1920" height="1080" poster="assets/videos/week-05-connect-four-search.jpg" aria-label="Silent animated explanation of Connect Four minimax and alpha-beta pruning: legal disc drops, red's worst replies, scores moving up a search tree, and six replies skipped after a bound proves they cannot change yellow's choice.">
 <source src="assets/videos/week-05-connect-four-search.mp4" type="video/mp4">
 <a href="assets/videos/week-05-connect-four-search.mp4">Open the Connect Four search video</a>.
</video>

<a href="assets/videos/week-05-connect-four-search.mp4">Open video separately</a> · 73 seconds · silent · <a href="https://inst.eecs.berkeley.edu/~cs188/textbook/games/minimax.html">UC Berkeley CS188: algorithm reference</a>

<aside class="notes">
Made with Manim Community and fframes; editable sources and rebuild commands
are in videos/week05-connect-four/. William's existing thinking and presenting
avatars are reused. All values come from the supplied Connect Four engine.
The reachable opening uses zero-based columns [3, 2, 3, 2, 4]; yellow moves next.
At depth two, yellow chooses column 2 with heuristic score −23. These estimates
are not probabilities or proven game outcomes. Alpha-beta gives the same move
and score while evaluating 19 leaves rather than 49 in this example.
Pause before the cutoff: can any unseen red reply make that MIN branch better
than yellow's already available −23? The current beta is −58, so no.
The closing card summarises minimax and alpha-beta without lab instructions.
Keep depth, evaluation and move order fixed for the comparison. The production
engine uses negamax, an equivalent formulation of the MAX/MIN view shown here.
</aside>

---

# What would you connect next?

Today, two tools let your assistant play a game.

Imagine connecting your notes, a simulation, or an application you use every day.
What could the assistant read? What could it do?

**Which connection would make you want to try it right now?**

---

# Week 5: course navigation

[Course overview](presentation.html) · [14-week course map](course_map.html)

[Previous: Week 4](week_04.html) · Next: Week 6 (not yet released)