Module T4·F34Neill's Vibe · Tier 4 · Operating the Machine~8 min

The AI is brilliant. It's also blind to your stuff.

It can reason about anything — and it cannot see your database, your Notion, or your browser until you plug them in. MCP is the standard plug. One socket, many tools.

01 · the scene

"Check my Notion." It can't. It's standing in an empty room.

Early on, the operator kept hitting the same wall. He'd ask the AI a question that lived in a real system — "what's in my Notion tasks?", "query my database," "what's on this webpage?" — and the AI, fluent enough to write the query, simply could not reach the thing. It has no hands. It reasons in a sealed room; your Notion, your Postgres, your browser are all on the other side of a wall it can't touch. So it did the only thing it could: it guessed — and a confident guess about data it can't see is exactly the failure class the whole system was built to kill.

the AI, asked about a system it isn't plugged into
# you ask:
> what tasks are open in my Notion?
I don't have access to your Notion workspace. Based on a typical setup,
you probably have tasks like "follow up with client" and "review draft"...
# it INVENTED tasks. it has no connection to Notion -- so it filled the gap with a guess.
# brilliant at language, blind to your actual data. that gap is the whole problem.
Neill51% · the terrain

"It kept doing this thing where it would answer like it had looked — and it hadn't, because it couldn't. There was no wire from the AI to my actual tools. I didn't want it to write me a script to query Notion every time. I wanted it to just... reach Notion. Be able to open the drawer and look inside."

Claude49% · the execution

"Straight version: I'm a brain in a jar. I can reason about your database all day, but I can't open it unless you hand me a tool that does. The old fix was custom glue — you'd write a little adapter for Notion, another for Postgres, another for the browser, each one bespoke and brittle. MCP replaces all of that with one standard plug. You wire the socket once; I get hands."

02 · the why

MCP is a standard plug, not another integration.

Here's the concept, plain. MCP — the Model Context Protocol — is an open standard (published by Anthropic in late 2024) for connecting an AI to outside systems. Think of it as a USB port for tools. Before USB, every device had its own oddball connector; you needed a different cable and a different driver for each one. MCP is the USB-C of AI tools: one shape of plug that every tool can be built to fit. The piece you plug in is an MCP server — a small program that knows how to talk to one specific system (Notion has one, Postgres has one, a browser has one). Your AI tool — Claude Code, here — is the MCP client: the device with the socket. You list a server in one config file; the client connects, and now the AI can actually do things in that system instead of guessing about it. The win is arithmetic: without a standard, ten tools across three AI apps means you hand-build thirty bespoke connectors. With MCP it's ten servers plus three clients — built once, reused everywhere.

⊟

The client

your AI tool

Claude Code (or Claude Desktop, etc.) — the device with the socket. It reads your config, connects to each server you list, and gains the tools they expose.

⌁

The plug

MCP — the protocol

The one standard shape both sides agree on. Because it's a shared standard, any server fits any client. Build the connector once; every MCP app can use it.

▤

The server

one per system

A small program that speaks to one outside thing — your Notion, your database, a browser. It hands the AI a menu of actions: read this, query that, click here.

The model: the AI is a brilliant new appliance with one USB-C port. Out of the box it can't reach your printer, your drive, or your camera — not because it's weak, but because nothing's plugged in. An MCP server is a USB device for one of those: plug in the Notion one and the AI can read your tasks; plug in the Postgres one and it can run real queries; plug in the browser one and it can actually open a page. You don't rewire the appliance for each device — that's the old custom-glue nightmare. You snap a standard plug into a standard socket. One socket, many tools.

03 · predict it

You add the Notion server to your config. Predict what the AI can do next.

Coming up, you'll add three lines to a config file — listing the Notion MCP server — and restart your AI tool. Before, when you asked "what's in my Notion?", it guessed (you saw it invent tasks). After the server is wired and the client reconnects, you ask the exact same question. What happens?

Not quite. The server doesn't copy your data into the model (B) and it doesn't leave you pasting things by hand (D) — and it's not ignored (A): the client reads the config, connects, and the model is told what tools are now available. What does a wired-up server actually give the AI that it didn't have before? You'll watch this exact connection happen at the end of the module.
That's the prediction to hold. Listing the server in config tells the client to connect; the server then advertises a menu of real tools — search a page, query the database — and the AI calls them to pull your live Notion data instead of inventing it. Nothing is baked into the model; the data stays in Notion and is fetched on demand. Keep this in mind — at the end you'll run it and watch the tools show up.
04 · the walkthrough

Giving the AI hands: plug one server into the socket.

pick the system to reach
step 1Name the one outside thing the AI is blind to right now — your Notion, your Postgres, a browser. One server reaches one system. Start with the one you ask about most.
find its MCP server
step 2Most popular tools already publish an MCP server — a ready-made program you point at. You don't build the connector; you reuse the standard one. (You can write your own later for a custom system.)
list it in the config
step 3Add the server to your MCP config — a small .mcp.json the client reads. You give it a name, the command that launches the server (usually npx — the tool that fetches and runs a small published program without you installing anything), and any secret it needs (an API key) via an env entry — never pasted in plain code.
restart + verify the tools
step 4Restart the client so it reads the new config and connects. Then check that the server's tools actually appear (/mcp in Claude Code). Tools listed = the plug seated. No tools = it didn't connect — fix it before you trust it.
05 · prove it · gate

Teach it back to unlock the payoff.

Same rule as always: answer it right, or the module isn't done.

Carry the idea to a new system. You want the AI to be able to run real queries against your Postgres database instead of guessing what's in it. Which move actually gives it that ability?
// apply the principle to an unseen system · one correct answer unlocks Module T4·F34
That's not it. Telling it in chat (A) changes nothing — there's still no wire to the database. Pasting the whole DB (B) doesn't scale and goes stale instantly. A bigger model (D) is still a brain in a jar — no model can reach your data without a plug, ability isn't the bottleneck, connection is. Which option actually wires the socket to the system?
That's the transfer. Same shape as the Notion server: you add a server for this system to the config, hand it its secret via env, restart so the client connects — and now the AI has a real "run query" tool to call instead of guessing. The plug is standardized; only the server changes per system. No smarter model and no giant paste reaches data that isn't plugged in. One socket, many tools. Module unlocked. ↓
the durable idea

The AI is brilliant and blind. The invented-Notion-tasks guess breaks the first law — never assert from memory, verify before you trust — and the only fix is a real connection. MCP is the standard plug. Add the server, restart the client, verify the tools appear. One socket, many tools.

06 · factory payoff
⊘ locked — pass the teach-back to claim this piece of the machine

A real MCP config — the socket, ready to plug into.

A working .mcp.json you drop into a project — the standard config file your AI tool reads to find its servers. It's valid, parseable JSON pre-wired with two real, ready-made servers: the filesystem server (the safe one to start with — it lets the AI read and write files in a folder you name, nothing more) and the Notion server, which shows the secret pattern done right: its token rides in an env entry that reads ${NOTION_TOKEN} from your environment — never a key pasted into the file, so the config is safe to commit. The companion .md carries paste-in blocks for the other big two — Postgres (real queries instead of guesses) and a browser (open a live page) — so the file itself stays parseable. One honest limit, stated plainly: a server is a real program that runs on your machine and acts on your behalf, so you only plug in servers you trust — an MCP server you wire up can read, query, and change whatever you point it at. WHAT-TO-PLUG-IN-FIRST.md ranks the first servers to add by payoff and walks the verify step (/mcp → tools listed = seated). You now own the socket the whole fleet plugs into — and this is exactly how a non-coder ran up the ~30-app portfolio shipped since the 2026-03-31 ban: the AI stopped being a brain in a jar the moment the standard plug let it reach the real systems. One socket, many tools.

▶ now seat the plug — don't trust it

Don't take "it's connected" on faith — that's the whole lesson. Make the tools appear with your own eyes. Drop the .mcp.json in a project, restart Claude Code, and ask it to list what's wired:

verify the plug seated — list the connected servers
# after dropping .mcp.json in the project and restarting, run:
/mcp
filesystem - connected - its file tools listed (read / write / list ...)
notion - connected - its tools listed (search / query database ...)
# both servers from the config show up. each connected one lists its tools -- that is the plug, seated.
# if you did NOT set NOTION_TOKEN you'll instead see:
notion - failed to connect - set NOTION_TOKEN and restart
# "failed to connect" / empty tools -> that server did NOT wire. fix it before you trust it.

See the server connected with its tools listed → the AI now has hands in that system. See an empty list or a connect error → it's still a brain in a jar, and trusting it would mean trusting a guess. The difference between blind and plugged-in is exactly this: you can watch the tools show up.

✓ Module T4·F34 complete