← All sessionsHomeSearch
AI Catalyst C3·Basecamp·2:41:33

Basecamp 5: MCP

Akhil Trainer/mentor — returning Catalyst mentor (taught earlier n8n bootcamp sessions); signature Socratic style ('yes, no, maybe', one-word-adjective check-ins) · Niharika Cohort manager (session open/close, CSAT poll)

Session map

FOUNDATIONSMCP COREHANDS-ONLLM = next-word predictorno memory, no handsModel + memory + tools= an agentTool callingname · description · inputsTool selectiondescriptions are everythingMCPopen standard by AnthropicHost · client · serverthe restaurantTools · resources · promptshands · librarian · templatesMCP vs DIY APIsvendor maintains, headlessClaude connectorsGmail · Calendar · filesMarketplace MCPsSmithery · ComposioChatGPT appsthe rival route
FoundationsMCP coreHands-on
click a node — its card pops up (drag it anywhere, × to close)
Concept

The map reads left to right — foundations flow into mcp core, then into hands-on. Click any node to open that idea here; every timestamp jumps into the recording.

The short version

  1. Ground-up build to MCP: LLM = 'world's best next word predictor' with no memory → apps add memory and tools → model + memory + tools = an AI agent (the n8n agent node, revisited).
  2. Tool calling demystified: models never read tool code — they read only name, description, and required inputs, then ask the app to run the script; walked through with the two-tool weather example and a stock-price example.
  3. MCP is Anthropic's open standard for connecting AI apps to external systems, explained via the restaurant analogy: host (Claude Desktop) → client (waiter) → server (chef); every MCP server ships tools ('a pair of hands'), resources ('a librarian'), and prompts (vendor-written templates with guardrails).
  4. Why MCP beats DIY API tooling: the vendor (Google, Microsoft) maintains the server on headless machines — API version churn, auth, and compute are offloaded; companies play along because LLM interfaces are where users now are.
  5. Hands-on hour: whole cohort connected Gmail/Calendar connectors in Claude Desktop (calendar-triage and deep-work-scheduling prompts), added a Google Sheets MCP from Smithery (via Composio) as a custom connector for a web-search-to-sheet iPhone price comparison, then did the same in ChatGPT's 'apps' with a Canva invitation build.

The concepts

01

LLMs don't remember — apps manage memory

0:15:10

The model you talk to every day has no memory at all — the app around it fakes it.

An LLM does exactly one thing: predict the next word, so fluently that it feels like thinking. It has no storage, no recall, no sense of "earlier in this conversation." If that were the whole system, every message would arrive to a total stranger.

So the companies wrap the model in an app that quietly re-feeds the conversation (and saved memories) back into the model on every single turn. What feels like "it remembered" is the app stuffing history into the prompt behind your back. Once you see that, features like context limits and 'memory full' warnings stop being mysterious — they're the size of the re-fed bundle.

Worked example · from the session

Ask 'What is the capital of India?' then 'Who is the PM of it?' — the model can resolve 'it' only because the app resent your first question along with the second. The bare model would have no idea what 'it' refers to.

Why it matters

Every limitation you'll hit — context windows, forgotten instructions, session resets — traces back to this one fact. Design your prompts and workflows knowing the model starts from zero every turn.

People get this wrong

The model remembers our conversation, so by now it knows me.

The app re-feeds history (and saved memories) into a stateless model every turn. Nothing inside the model persists between messages.

For your projects

This is the design rationale for the whole KB pipeline: because nothing persists in the model, the value lives in artifacts on disk — the YAML records, condensed transcripts, the coming SQLite index — that get re-fed as context. Every extraction sitting is memory-building for a system that has none.

  • A session context-pack generator: one command that emits map + concepts + open questions as a paste-ready block, so a fresh chat starts with the right re-fed history instead of a re-read.
  • Worth exploring: measure how little of a condensed transcript is needed to still answer that session's check-yourself questions — that ratio is the real compression target for the vector phase.
Go deeper

In one line: An LLM is the world's best next-word predictor, nothing more; it processes but cannot remember. Multi-turn coherence (capital of India → 'who is the PM of it') exists because companies like OpenAI and Anthropic manage a memory layer externally in the app.

Try it now

Start a fresh chat and ask a follow-up question with a dangling pronoun ('why is he famous?'). Watch it ask who you mean — that's the naked model without re-fed history.

▶ Watch this taught: 0:15:10

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

You ask 'What is the capital of India?' then 'Who is the PM of it?' — what actually makes the second question answerable?

The app re-sent the first question along with the second. The model stored nothing; multi-turn coherence is the app stuffing history back into the prompt every turn.

Why does a long conversation eventually start forgetting the beginning?

Because the re-fed bundle of history has to fit in the context window. When it overflows the oldest turns get trimmed — the app's memory management runs out, not the model's.

In one sentence, what does an LLM actually do?

Predicts the next word from a probability distribution — no storage, no recall, no awareness of 'earlier'.

02

Model + memory + tools = AI agent

0:19:15

An 'agent' isn't magic — it's just a model with two things bolted on: managed memory and tools.

Strip the buzzword: take the bare next-word predictor, add the memory layer (so it keeps context), and give it tools (so it can act). That triad is the entire definition of an agent. You've already seen it drawn: the n8n AI-agent node literally has three sockets — model, memory, tools.

The punchline is that ChatGPT and Claude, the apps, are themselves agents by this definition. You've never actually chatted with a bare LLM — you've been using a "super agent" all along. That reframe makes everything else in this session (tool calling, MCP) feel like opening the hood on something you already drive.

Worked example · from the session

The n8n AI-agent node from the previous sessions is the triad made visible: pick a chat model, attach a memory, wire in Gmail/Calendar tools. Claude Desktop is the same picture with a nicer interface.

Why it matters

When something misbehaves you can now ask which leg is failing: is the model weak, is memory missing context, or is a tool broken? That diagnosis skill is the whole game in agent-building.

People get this wrong

An AI agent is a fundamentally different, more advanced kind of AI.

It's the same next-word predictor with memory and tools attached. The intelligence didn't change; the wiring did.

For your projects

A useful lens on the Cowork sittings themselves: model is Fable, memory is the handoff docs plus this repo, tools are Desktop Commander and build_site.py. When a sitting goes wrong the diagnosis is almost always memory — a stale handoff — rather than model.

Go deeper

In one line: The n8n AI agent node's three components generalized: ChatGPT and Claude apps are effectively 'super agents' — an LLM wrapped with managed memory and tool access — not bare LLMs.

▶ Watch this taught: 0:19:15

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Name the three parts of an agent.

Model + memory + tools. The n8n AI-agent node draws it literally: three sockets.

Have you ever talked to a bare LLM?

Almost certainly not. ChatGPT and Claude are apps — model plus managed memory plus tools — so you have been using agents all along.

Your agent gives a stale answer. Which leg do you suspect first, and how would you tell?

Tools — check whether it called one at all. If it answered from training data instead of fetching, either no tool was available or its description didn't match. Memory failures look different: the agent contradicts something you said earlier.

03

Tool calling

0:21:20

The model never runs code and never reads code — it reads three lines about each tool and asks the app to do the work.

Old models asked about today's weather just made up a number, because a next-word predictor can't fetch reality. Tool calling is the fix: the app carries small scripts ("get today's date", "get weather"), and the model is configured so its first move on any request is to check what tools it has.

The clever economics: the model is never shown the tool's code — only its name, its description, and what inputs it needs. A 10,000-line script costs the model one sentence of reading. When the model decides a tool fits, it tells the app "run this, with these inputs," the app executes, and the real answer flows back into the conversation. The model then chains tools by reading descriptions: date-tool output plus your location become the weather-tool's inputs.

Worked example · from the session

'How many GM shares can I buy with $500?' — the model calls getStockPrice(GM), the app returns $43, and the model does the arithmetic in its reply: about 11 shares. Real data, model reasoning, one seamless answer.

Why it matters

This is the foundation under everything agentic — n8n nodes, Claude connectors, MCP. If you understand name/description/inputs, you understand why agents pick the right tool, and why they pick the wrong one when descriptions are sloppy.

People get this wrong

When an AI uses a tool, it runs the code itself.

The model never executes anything. It emits a structured request; the host app runs the script and hands the result back into the conversation.

You "weather in New York today?" Model checks its tools first App runs the script get_todays_date() → 16 May get_weather(date, place) → 33° real data flows back The model reads only three things per tool: name · description · required inputs never the code — a 10,000-line script costs one sentence The tool-calling loop: the model decides, the app executes, reality returns.
The tool-calling loop — model decides, app executes, reality returns
For your projects

Explains why the MCP servers in your Cowork sessions behave as they do — and why a badly-described custom tool gets ignored while a vaguely-named one gets over-used.

Go deeper

In one line: Anthropic's framework letting models use real-world capabilities: tools are scripts/functions/API calls; the model is configured to check its tools first, reads only each tool's name, description, and required inputs (never the code — reading a 10,000-line script would waste tokens), and instructs the app to execute.

Motivating history: pre-tool-calling models (Claude 3-era) hallucinated weather answers because they couldn't fetch real-world data (0:21:20)

Weather walkthrough: get-today's-date tool feeds its output plus location into get-weather; model chains tools by their descriptions (0:33:31)

Stock example: 'how many GM shares for $500' → getStockPrice(GM) → model does the arithmetic in the reply (0:37:37)

n8n abstraction: Gmail/Calendar nodes are prewritten scripts wrapping those APIs — n8n simplified tool calling before you knew its name (0:39:40)

Try it now

In Claude, ask 'what's the weather where I am right now?' and expand the tool-use trace in the reply — you'll see the tool call and its inputs spelled out.

▶ Watch this taught: 0:21:20

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What exactly does the model see about a tool?

Three things only: name, description, and required inputs. Never the code — reading a 10,000-line script would burn tokens for no benefit.

Walk the weather example end to end.

Model checks its available tools → calls get-today's-date → feeds that output plus your location into get-weather → the app executes and returns real data → the model writes the answer around it.

Who runs the code — the model or the app?

The app. The model only decides which tool and with what inputs, then instructs the app to execute and waits for the result.

04

How the model picks among similar tools

0:41:42

With ten similar tools available, the model chooses by reading their descriptions — nothing else.

There's no hidden intelligence in tool choice. The model compares your request against each tool's natural-language description and picks the best match. Two tools with overlapping, vague descriptions produce coin-flip behavior — exactly like an intern with Gmail, Outlook, and a calendar app but no guidance on which is for work and which is personal.

The fix is entirely in your hands: write descriptions that are concise, distinct, and uniquely selectable. Say when to use a tool and when not to. This is the session's most transferable lesson — it applies to n8n agents, Claude skills, and every agent framework you'll ever touch.

Worked example · from the session

The trainer's intern analogy: hand an intern three email apps with no instructions on which account is professional and which is personal, and watch the confusion. That confusion is precisely what a vague tool description creates in a model.

Why it matters

'Your AI agent is as good as the instructions you give.' When your agent picks the wrong tool, the bug is almost always in your descriptions, not the model.

People get this wrong

The model is smart enough to work out which tool I meant.

It compares your request against each description and picks the closest match. There is no other signal — ambiguity in, coin-flip out.

Your AI agent is as good as the instructions you give.0:43:43
For your projects

Directly applicable when you write skills or MCP wrappers for this KB: a 'rebuild the whole site' tool and a 'rebuild one session page' tool need descriptions that make the choice obvious, or the agent reaches for the wrong one at the wrong moment.

Go deeper

In one line: Selection runs on the natural-language descriptions; ambiguous or overlapping descriptions confuse the model exactly like vague instructions confuse an intern with three email apps. Corollaries: 'your AI agent is as good as your instructions' and tool descriptions must be concise and uniquely selectable.

Try it now

Open any n8n agent you've built and read each tool's description cold. If you couldn't pick correctly from the descriptions alone, neither can the model — rewrite them.

▶ Watch this taught: 0:41:42

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Your agent keeps picking the wrong tool. Where is the bug?

Almost always in the tool descriptions — overlapping or vague wording. Selection runs on natural language, so rewrite them to be concise, distinct, and to say when NOT to use each.

Why does the intern analogy land?

Hand someone Gmail, Outlook and a calendar app with no guidance on which account is work and which is personal, and they'll guess. A model with three fuzzy descriptions is in exactly that position.

05

MCP: an open standard for connecting AI apps to external systems

0:45:46

MCP is a plug standard: one agreed way for any AI app to connect to any outside system, the way USB let any device talk to any computer.

Before MCP, every app-to-service connection was custom wiring. Anthropic published the Model Context Protocol as an open standard: an AI app (Claude Desktop, an IDE, anything) can connect to any MCP-speaking service — databases, design tools, email, spreadsheets — without either side building custom integrations.

What it buys you: as a builder, one interface instead of ten open apps and less integration code; for the agent, a growing marketplace of ready-made capabilities; as a user, speed and real personalization, because the AI can finally touch *your* calendar, *your* files, *your* sheets. The possibility demos land the point: with a Figma MCP you design without opening Figma; with a Blender MCP you get 3D scenes from a chat prompt.

Worked example · from the session

Same conversation, before and after: Claude with no connectors couldn't say what was on the trainer's calendar. One Gmail connector later, it listed his latest Outskill emails — the model didn't change, the plumbing did.

Why it matters

MCP is where the industry landed — vendors from Google to Figma now ship servers. Learning it isn't optional trivia; it's the connective tissue of every agent workflow you'll build after this course.

For your projects

This is the layer Cowork already runs on — Desktop Commander, filesystem access, Chrome control are all MCP servers. The course is teaching the plumbing under the sittings you're already doing.

  • A small MCP server over the course corpus itself: expose search-concepts / get-session / list-tools so any AI app — not just this pipeline — can query the KB.
  • Could be worth exploring an MCP wrapper over the V: media archive, so a chat can answer 'do we have the recording for lesson X' without anyone opening the drive.
Go deeper

In one line: Model Context Protocol, developed by Anthropic: a bridge letting hosts (Claude Desktop, IDEs like Claude Code, other AI apps) talk to databases, dev tools, and productivity apps without touching their UIs.

Wins by audience: builders get reduced dev time/complexity in one interface; agents get a marketplace of tools; end users get speed + deep personalization (0:51:54)

Possibility demos cited: Figma MCP (design without opening Figma), Blender/AutoCAD MCPs (3D scenes from chat) (0:47:49)

▶ Watch this taught: 0:45:46

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What problem does MCP solve that custom integrations don't?

One agreed protocol replaces N×M custom wiring — any MCP-speaking app can talk to any MCP-speaking service without either side building a bespoke integration.

Who gets what out of it?

Builders: less integration code, one interface. Agents: a marketplace of ready capabilities. Users: speed and real personalization, because the AI can touch your calendar, your files, your sheets.

06

The layering story: system prompts → RAG → MCP

1:16:21

The whole bootcamp is one staircase: each layer hands the AI more of your context, and MCP is the top step.

Step back and the six Basecamp sessions form a single arc. A bare LLM knows the internet but nothing about you. System prompts (session 1) give it a persona and rules. RAG (session 1) lets it answer from your documents instead of its memory. And MCP (today) lets it act in your real systems — send the email, book the slot, fill the sheet.

Read the staircase as "how much of my world can the AI see and touch": persona → your documents → your live tools. Every AI product you'll evaluate from now on is some bundle of these three layers, and every workflow you design is you choosing how far up the staircase the task needs to go.

Worked example · from the session

A customer-support bot: system prompt sets the voice ('friendly, concise'), RAG grounds it in your help-center docs, MCP lets it actually open the refund ticket. Same model at every step — only the layers change.

Why it matters

This mental model turns a pile of buzzwords into one dial. When someone pitches an 'AI solution,' you can now ask: which layers does it actually use, and which does my problem actually need?

Bare LLM knows the internet, nothing about you + System prompts persona & rules — how it behaves + RAG answers from your documents + MCP acts in your real systems each layer hands the AI more of your context ↗ The bootcamp staircase: persona → your documents → your live tools. MCP is the top step.
The bootcamp staircase — each layer hands the AI more of your context
At every layer, we gave AI more and more access to your context. And MCP is the biggest layer — the deepest personalization that you can give it to act in real time.1:18:22
For your projects

Gives you a clean way to describe this KB to anyone: it's a RAG layer being built by hand, deliberately, ahead of the SQLite/vector phase — and the extraction quality is what makes the retrieval worth doing.

Go deeper

In one line: Bootcamp arc recap: bare LLM + custom system prompts (persona/rules) + RAG (retrieve relevant docs) + MCP (act in the real world). Each layer hands the AI more of your context; MCP is the biggest layer — real-time action with the deepest personalization.

▶ Watch this taught: 1:16:21

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Put the three layers in order of how much of your world the AI can reach.

System prompts (persona and rules) → RAG (your documents) → MCP (your live tools, with the power to act).

A support bot needs the company voice, accurate policy answers, and the ability to open a refund ticket. Which layer does each?

Voice = system prompt. Policy answers = RAG over the help centre. Refund ticket = MCP.

07

MCP architecture: host, client, server (restaurant analogy)

1:18:22

Three words carry all of MCP — host, client, server — and a restaurant explains all three.

You walk in and sit down: you're the customer, and your prompt is the order. Claude Desktop is the host — the restaurant you're sitting in. Inside it works the waiter (the MCP client): he takes your order, translates it for the kitchen, and coordinates everything, but he never cooks. The chefs are the MCP servers — each one a specialist. One makes pasta, one makes dessert; one server does Gmail, one does your filesystem.

The load-bearing insight is what the waiter doesn't need to know. He doesn't know the recipe — he only knows *which chef to call*. That's why MCP scales: the host app stays simple while the ecosystem of specialist servers grows underneath it. Your order to the kitchen is the tool-call request; the dish that comes back is the tool response.

Worked example · from the session

'What's on my calendar today?' — you (customer) tell Claude Desktop (host); its client (waiter) routes the request to the Google Calendar MCP server (chef); the server returns your events (the dish), and the waiter serves it back as a normal chat reply.

Why it matters

These three words are the vocabulary of every MCP error message, settings screen, and marketplace listing you'll meet. When a connector breaks, knowing which of the three failed is the difference between a 30-second fix and an afternoon.

People get this wrong

The MCP client is the thing doing the work.

The client only coordinates and translates. All actual capability lives in the servers.

You the customer your prompt = the order Claude Desktop host + client — the waiter never cooks; only knows which chef to call Gmail MCP server chef — Google maintains it Calendar MCP server chef — a specialist Filesystem MCP server chef — runs locally Sheets MCP server marketplace add-on order out = tool-call request · dish back = tool response
The restaurant — customer, waiter, specialist chefs
Go deeper

In one line: You (customer/prompt) → host app (Claude Desktop) → MCP client (the waiter: coordinates, never cooks, only needs to know which chef to call) → MCP server (the specialist chef). Menu order = tool-call request; the dish served = tool response.

▶ Watch this taught: 1:18:22

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Map the restaurant onto real software.

You are the customer and your prompt is the order; host = Claude Desktop; client = the waiter who routes and never cooks; server = the specialist chef (Gmail, filesystem, Sheets).

Why doesn't the waiter need the recipe?

That's exactly what makes MCP scale — the host stays simple and only needs to know which server to call, while the ecosystem of specialist servers grows underneath it.

A connector stops working. Which of the three do you check first?

The server (authorized, reachable, vendor change?), then the client (did the host register it — did you restart the app), then the host itself.

08

Every MCP server ships tools, resources, prompts

1:26:31

Open any MCP server and you'll always find the same three things inside: hands, a librarian, and a script.

Tools are the hands — the actions the server can perform: send an email, run a search, create a file. Resources are the librarian — the server's way of handing over the material those actions need: your emails, events, files, handed to the model on request rather than dumped wholesale.

Prompts are the sleeper feature: vendor-written templates living inside the server. When you say "send an email" sloppily, the server's own send-email prompt shapes your request into a well-formed tool input — and carries guardrails the vendor baked in (don't read passwords, don't respond offensively). You never see these prompts, but they're a big part of why first-party MCPs behave better than duct-taped API scripts.

Worked example · from the session

The filesystem connector's tool list, read aloud in the session: read file, write file, edit file, create directory, list directories, search files, move files — a literal inventory of 'hands.' The files themselves arrive via resources.

Why it matters

When you evaluate or build an MCP server, this is the checklist: what can it do (tools), what can it access (resources), and what judgment is baked in (prompts). A server weak on any leg will feel broken in use.

People get this wrong

An MCP server is just a bundle of API endpoints.

Tools are the API-ish part, but resources (context delivery) and prompts (vendor-shaped instructions plus guardrails) are what make a server feel well-behaved rather than merely capable.

Inside every MCP server Tools "a pair of hands" send email · run search create file · book slot Resources "the librarian" hands over your emails, events, files on request Prompts vendor-written templates shape sloppy requests, carry built-in guardrails
Hands, librarian, templates — every server ships all three
Tools are more like giving AI a pair of hands. Resources are more like a librarian who will hand you the book.1:38:47
Go deeper

In one line: Tools give the AI 'a pair of hands' (send email, run search); resources are 'the librarian' handing over files/emails/events the tools need; prompts are vendor-written templates (e.g. a send-email prompt) that shape sloppy user requests into effective tool inputs and can embed guardrails (don't read passwords, don't respond offensively).

▶ Watch this taught: 1:26:31

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Name the three things every MCP server ships, with the session's analogy for each.

Tools = a pair of hands (actions). Resources = the librarian, handing over the files, emails and events those actions need. Prompts = vendor-written templates that shape sloppy requests and carry guardrails.

Which of the three do you never see, and why does it matter?

Prompts. They live inside the server and are a big part of why first-party MCPs behave better than duct-taped API scripts — the vendor's judgement and guardrails are baked in.

09

Why MCP over rolling your own API tools

1:28:34

The real product of MCP isn't capability — it's maintenance you no longer have to do.

You could wire your model to Gmail yourself with a custom script. It works — until Google changes their API from v1 to v2, and you rewrite it. Now imagine a hundred tools, each drifting on its own schedule, all running on your machine's CPU. That maintenance treadmill is what killed DIY tool collections.

An MCP server flips the ownership. Google runs the Gmail server on Google's headless machines (a server is "just a headless computer" — no monitor, 24/7 CPU executing scripts). When the API changes, Google updates their own server and you notice nothing. And the vendors aren't being charitable: users now live inside LLM chat, an Outlook MCP requires an Outlook subscription, so MCP is distribution and revenue. That aligned incentive is why the standard actually stuck.

Worked example · from the session

The session's thought experiment: your 100 hand-written tools all break over a year of API churn, each one your problem — versus 100 vendor MCPs where every fix ships silently upstream while you sleep.

Why it matters

This is the build-vs-connect decision you'll face constantly: write a custom tool only when no vendor server exists — and treat that custom tool as a maintenance liability you chose on purpose.

People get this wrong

MCP is mainly about giving the AI new capabilities.

Those capabilities were already possible with custom scripts. What MCP actually transfers is ownership of maintenance, auth and compute — to the vendor.

DIY API tools gmail-v1.py ⚠ calendar.py ⚠ sheets-old.py ⚠ …97 more scripts every API change is YOUR rewrite runs on YOUR machine's CPU auth & re-login: your problem MCP servers Google's headless machines run Google's Gmail server — 24/7 "a server is just a headless computer" API changes fixed upstream, silently their CPU, their auth, their problem vendor incentive: users live in LLM chat The product of MCP is maintenance you no longer do.
DIY maintenance treadmill vs the vendor's headless server
For your projects

The build-vs-connect call comes up constantly in the pipeline: every custom script here (fetch_transcripts, run_recordings, build_site) is a maintenance liability taken on knowingly, because no vendor server exists for Outskill's LMS.

Go deeper

In one line: DIY tool scripts mean you maintain every API version change, auth, and re-login across potentially 100 tools, running on your machine's CPU/GPU. An MCP server is the vendor's headless machine running the vendor's tools — Google maintains the Gmail MCP, so API churn and compute are their problem.

A server is 'just a headless computer' — no monitor/keyboard, 24/7 CPU/RAM executing scripts (1:32:39)

Company incentive: users now live in LLM interfaces; an Outlook MCP requires an Outlook subscription — MCP is a distribution and revenue channel, which is why enterprises adopted the playbook (1:34:42)

Security posture: first-party MCPs (Google's Gmail, Anthropic's connectors) carry the vendor's credibility stake; configure granular directory/approval permissions, use allow-once (1:14:18)

▶ Watch this taught: 1:28:34

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Google moves the Gmail API from v1 to v2. What happens to your DIY tool script, and to the Gmail MCP?

Your script breaks and you rewrite it. The MCP server is Google's — they update it on their machines and you notice nothing.

Why did vendors adopt MCP instead of ignoring it?

Distribution and revenue. Users now live inside LLM chat interfaces, and an Outlook MCP still requires an Outlook subscription — being in the chat is being in the market.

When should you still write a custom tool?

When no vendor server exists — and you should treat it as a maintenance liability you took on deliberately.

10

Claude Desktop connectors, hands-on

how-to1:02:06

'Connectors' is just Claude's friendly word for MCPs — and wiring your first two takes five minutes.

The flow: new chat → plus icon → Connectors → pick from the directory (Gmail, Google Calendar, filesystem…) → sign in with the account you want Claude to see, checking every permission box during OAuth. Then the step everyone forgets: fully quit and relaunch the desktop app — connectors only register on a fresh start. This works on free accounts; pick Haiku as the model to stretch your free tokens.

Two operational lessons from the live demo. First, permissions are granular and yours: allow-once vs always-allow per action, per directory for the filesystem. Second, when the desktop-organizing demo failed because Claude was sandboxed away from the real desktop, that wasn't a bug — it was minimal privilege doing its job, and the fix ladder (update app → reinstall/reauth the connector → restart → worst case reinstall) resolves nearly everything.

Worked example · from the session

The cohort's exercise, run live: 'Look at my calendar for the next 5 days — what's my most intense day, and what should I defer or delegate to survive it?' followed by 'find 2 hours for deep work in the next 3 days and create the slots' — slots verified sitting in learners' calendars.

Do it in this order

GotchasSkipping the restart is the number-one 'it doesn't work'. A sandboxed failure — like the desktop-declutter demo — is minimal privilege working, not a bug. Troubleshooting ladder: update Claude → reinstall/reauth the connector → restart the app → worst case reinstall.

Why it matters

This is the fastest real personalization available today: fifteen minutes of setup and Claude can triage your actual week. It's also the pattern every other MCP host copies, so learn it once here.

Please note that if Claude is not working, that's not my problem. My rating shouldn't go down.2:35:17
For your projects

You already live this in Cowork with Desktop Commander pointed at the _CLASSES tree: same permission model, same 'restart before you panic' rule, same minimal-privilege trade-off between reach and safety.

Go deeper

In one line: 'Connectors' is Claude's word for MCPs. Baseline shown first (no calendar/email access), then Gmail + Google Calendar connected live — every new connector requires fully restarting the desktop app — followed by cohort-wide exercises on free accounts using Haiku to conserve tokens.

Exercise prompts: 'Look at my calendar for the next 5 days — what's my most intense day and what should I defer or delegate to survive it?' and 'Find 2 hours in the next 3 days for deep work and create the slots' (1:54:35–1:58:39)

Filesystem connector: tool list read aloud (read/write/edit/move/search files, create/list directories); desktop-organizing demo initially failed because Claude ran in a restricted sandbox — a teachable moment on minimal privilege (1:10:15–1:14:18)

Claude-deletes-files fears addressed: third-party connectors or non-Claude models are the usual culprit; first-party connector + Claude model is the safe pairing (1:16:21)

Troubleshooting ladder: update Claude → reinstall/reauth MCPs → restart app → worst case reinstall (2:21:05)

Desktop-vs-web reason: some tools need your local CPU/GPU and filesystem — hence desktop-only connectors (2:19:04)

Try it now

Connect Gmail and Calendar tonight, restart the app, and run the intense-day prompt on your real week. Then check whether its defer/delegate suggestions survive contact with reality.

▶ Watch this taught: 1:02:06

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

You connected Gmail and Claude still can't see your mail. First move?

Fully quit and relaunch the desktop app — connectors register only on a fresh start.

Why are connectors desktop-only rather than in the web app?

Some tools need your local machine — filesystem access, CPU/GPU — which a browser tab can't reach.

Whose fault is it when 'Claude deletes files'?

Usually a third-party connector or a non-Claude model driving the tooling. First-party connector plus Claude model is the safe pairing — and the granular permissions are yours to set.

11

External MCPs via marketplaces (Smithery, Composio)

how-to2:02:51

When the built-in directory doesn't have what you need, the open marketplace almost certainly does.

Claude's connector directory is curated and small; the MCP ecosystem is enormous. Marketplaces like Smithery index thousands of community and vendor servers. The install pattern: find the server's page, copy its hosted URL (this session's Google Sheets server was hosted by Composio), then in Claude go Settings → Connectors → add custom connector → paste → authorize the underlying account.

Because these aren't first-party, trust-check before installing: the listing shows a reliability rating and a user count — the session's Sheets MCP showed a 74/100 best-practices score and ~40k users. Prefer heavily-used servers, read what permissions they request, and remember platform gaps exist (Control Chrome was Mac-only; Windows users route through Puppeteer/Playwright-style servers instead).

Worked example · from the session

The live capstone: web search enabled + Sheets MCP connected, one prompt — 'analyze all iPhone models, US vs India pricing with currency conversion, into a new sheet' — and a populated comparison spreadsheet appeared without leaving Claude. Competitor research in one sentence.

Do it in this order

GotchasThese aren't first-party: read what permissions they request and prefer heavily-used, well-rated servers. Platform gaps are real — Control Chrome was Mac-only, so Windows users route through Puppeteer/Playwright-style servers instead.

Why it matters

This unlocks the long tail: whatever niche tool your workflow needs, someone has probably wrapped it. The copy-URL-into-custom-connector skill is the same for all of them.

For your projects
  • A Sheets-MCP flow mirroring extraction progress — sessions done, concepts, tools met — into a spreadsheet you can glance at without opening the site.
  • Could be worth exploring a Smithery search for a WordPress or Elementor MCP; LWP content edits from chat would be the same pattern as the Sheets demo.
Go deeper

In one line: Beyond the built-in directory: browse Smithery's MCP pages, copy the hosted server URL (this Google Sheets MCP was served via Composio; rated, with usage counts), then Claude settings → connectors → add custom connector → paste URL → authorize.

Demo: web search + Google Sheets MCP → 'analyze all iPhone models, US vs India pricing with currency conversion, into a new sheet' — competitor research without leaving Claude (2:14:59)

Chrome control connector is Mac-only; Windows learners pointed to Puppeteer/Playwright-style MCP alternatives (2:00:50)

MCPs compose: email + calendar + sheets + drive tools can run parallel or sequentially in one conversation (2:19:04)

Try it now

Browse smithery.ai for a tool you actually use, check its rating and user count, and install it as a custom connector. Reproduce the sheet demo against a product you're genuinely shopping for.

▶ Watch this taught: 2:02:51

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Before installing a community MCP, which two numbers do you look at?

The reliability/best-practices rating and the user count — a well-used, well-rated server is the cheapest trust signal available.

What did the iPhone-pricing demo actually prove?

That MCPs compose: web search gathered US and India pricing, currency conversion happened in the reply, and the Sheets MCP wrote a populated comparison sheet — one prompt, without leaving Claude.

12

ChatGPT 'apps' — the rival connector model

2:23:07

OpenAI built the same idea a different way: browser-based 'apps' instead of desktop connectors — younger, and it shows.

Where Claude went desktop-local (so connectors can reach your machine's files and CPU), ChatGPT took the web route: Settings → Apps → add more, all in the browser. Connect Canva, Figma, Spotify — but notice what's missing: no Google apps, because rivals don't ship each other's integrations. Gemini, at session time, had no connectors at all.

The trainer's field score after daily use of both: Claude connectors work about 7 times in 10, ChatGPT apps about 4 — the feature was only months old. And there's a hard current limit: one tool per chat. The moment the demo selected image generation, the Canva connection dropped. Expect fast improvement, but know today's edges.

Worked example · from the session

Live in ChatGPT: Canva app connected, one prompt — 'an MCP master-class invitation, modern corporate, neon-green elements' — and finished invitation designs appeared in-chat, each openable in Canva for editing. Then the whole cohort ran the same prompt and every design came out different.

Why it matters

You'll work across both ecosystems, so knowing their trade-off — desktop reach and reliability vs browser convenience — tells you which assistant to hand a given task. The one-tool-per-chat limit alone rules ChatGPT apps out of multi-step workflows for now.

People get this wrong

ChatGPT apps and Claude connectors are the same feature with different names.

Same idea, opposite routes: desktop-local (reaches your machine, more reliable in the trainer's daily use) versus browser-based (convenient, newer, one tool per chat).

Go deeper

In one line: ChatGPT's MCP equivalent lives under Settings → Apps, browser-based rather than desktop-local (opposite route from Claude); recently launched and less reliable in the trainer's usage (~4/10 vs Claude's 7/10); no Google apps (rivals); Gemini has no connectors yet.

Canva app demo: 'MCP masterclass invitation, modern corporate, neon-green' generated in-chat, then opened in Canva for editing (2:29:12)

Current limit: one tool per chat — selecting image generation drops the Canva connector (2:33:16)

▶ Watch this taught: 2:23:07

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What's the architectural difference between Claude connectors and ChatGPT apps?

Claude went desktop-local, so connectors can reach your files and CPU. ChatGPT went browser-based — more convenient, but it can't touch your machine.

Why are there no Google apps in ChatGPT's catalog?

Rivals don't ship each other's integrations. It's a business boundary, not a technical one.

Which limit rules ChatGPT apps out of multi-step workflows right now?

One tool per chat — selecting image generation dropped the Canva connection mid-demo.

13

Same prompt, different outputs

2:35:17

Forty people ran the identical Canva prompt and got forty different designs — and that's not a bug you can file.

An LLM picks each next word from a probability distribution, not a lookup table. Run the same prompt twice and the sampling lands differently, so the outputs diverge — sometimes slightly, sometimes wildly. When the model then drives a tool like Canva, those divergent word choices become divergent instructions, and everyone's invitation looks different.

You can narrow the spread — tighter prompts, explicit constraints, examples of what you want — but you cannot close it. "Can we make it deterministic?" got the honest answer: no, that's not the nature of the technology. Design your workflows to embrace it: generate several, pick the best, or add a checking step where consistency actually matters.

Worked example · from the session

The closing minutes of the session: the cohort's Canva invitations, all from one shared prompt, filled the chat with visibly different layouts, colors, and copy — a live demonstration nobody planned.

Why it matters

This sets your expectations for every automation you'll build: outputs vary run to run. Anywhere you need repeatability — file formats, data extraction — you constrain hard and verify, rather than hoping the dice land the same way twice.

People get this wrong

If I get a bad output, the same prompt will reliably give the same bad output — so I can debug it like code.

Reruns diverge. Debugging a prompt means shifting the distribution — constraints, examples, explicit output format — not finding the one broken line.

For your projects

This is why the extraction protocol earns its length: the YAML schema, the approved exemplar and the handoff rules are constraints that narrow the distribution across sittings, so basecamp-05 and session-14 come out recognizably the same shape.

Go deeper

In one line: Closing Q&A: AI is a probabilistic next-word engine, not deterministic — the whole cohort ran identical Canva prompts and got different designs; you can constrain outputs but never make an LLM deterministic.

▶ Watch this taught: 2:35:17

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Can you make an LLM deterministic?

No. It samples each next word from a probability distribution — you can narrow the spread with tighter prompts, constraints and examples, but you cannot close it.

Forty people, one prompt, forty different Canva invitations. What's the design implication?

Build for variance: generate several and pick, or add a checking step wherever repeatability actually matters — file formats, data extraction, anything downstream code depends on.

Every concept, three clicks deep

The same concepts as a quick reference: the closed row is the glance, open is the study card, and every timestamp jumps into the recording.

01LLMs don't remember — apps manage memoryAn LLM is the world's best next-word predictor, nothing more;0:15:10

An LLM is the world's best next-word predictor, nothing more; it processes but cannot remember. Multi-turn coherence (capital of India → 'who is the PM of it') exists because companies like OpenAI and Anthropic manage a memory layer externally in the app.

02Model + memory + tools = AI agentThe n8n AI agent node's three components generalized: ChatGPT and Claude apps are effectively 'super agents…0:19:15

The n8n AI agent node's three components generalized: ChatGPT and Claude apps are effectively 'super agents' — an LLM wrapped with managed memory and tool access — not bare LLMs.

03Tool callingAnthropic's framework letting models use real-world capabilities: tools are scripts/functions/API calls;0:21:20

Anthropic's framework letting models use real-world capabilities: tools are scripts/functions/API calls; the model is configured to check its tools first, reads only each tool's name, description, and required inputs (never the code — reading a 10,000-line script would waste tokens), and instructs the app to execute.

Motivating history: pre-tool-calling models (Claude 3-era) hallucinated weather answers because they couldn't fetch real-world data (0:21:20)

Weather walkthrough: get-today's-date tool feeds its output plus location into get-weather; model chains tools by their descriptions (0:33:31)

Stock example: 'how many GM shares for $500' → getStockPrice(GM) → model does the arithmetic in the reply (0:37:37)

n8n abstraction: Gmail/Calendar nodes are prewritten scripts wrapping those APIs — n8n simplified tool calling before you knew its name (0:39:40)

04How the model picks among similar toolsSelection runs on the natural-language descriptions;0:41:42

Selection runs on the natural-language descriptions; ambiguous or overlapping descriptions confuse the model exactly like vague instructions confuse an intern with three email apps. Corollaries: 'your AI agent is as good as your instructions' and tool descriptions must be concise and uniquely selectable.

05MCP: an open standard for connecting AI apps to external systemsModel Context Protocol, developed by Anthropic: a bridge letting hosts (Claude Desktop, IDEs like Claude Co…0:45:46

Model Context Protocol, developed by Anthropic: a bridge letting hosts (Claude Desktop, IDEs like Claude Code, other AI apps) talk to databases, dev tools, and productivity apps without touching their UIs.

Wins by audience: builders get reduced dev time/complexity in one interface; agents get a marketplace of tools; end users get speed + deep personalization (0:51:54)

Possibility demos cited: Figma MCP (design without opening Figma), Blender/AutoCAD MCPs (3D scenes from chat) (0:47:49)

06The layering story: system prompts → RAG → MCPBootcamp arc recap: bare LLM + custom system prompts (persona/rules) + RAG (retrieve relevant docs) + MCP (…1:16:21

Bootcamp arc recap: bare LLM + custom system prompts (persona/rules) + RAG (retrieve relevant docs) + MCP (act in the real world). Each layer hands the AI more of your context; MCP is the biggest layer — real-time action with the deepest personalization.

07MCP architecture: host, client, server (restaurant analogy)You (customer/prompt) → host app (Claude Desktop) → MCP client (the waiter: coordinates, never cooks, only…1:18:22

You (customer/prompt) → host app (Claude Desktop) → MCP client (the waiter: coordinates, never cooks, only needs to know which chef to call) → MCP server (the specialist chef). Menu order = tool-call request; the dish served = tool response.

08Every MCP server ships tools, resources, promptsTools give the AI 'a pair of hands' (send email, run search);1:26:31

Tools give the AI 'a pair of hands' (send email, run search); resources are 'the librarian' handing over files/emails/events the tools need; prompts are vendor-written templates (e.g. a send-email prompt) that shape sloppy user requests into effective tool inputs and can embed guardrails (don't read passwords, don't respond offensively).

09Why MCP over rolling your own API toolsDIY tool scripts mean you maintain every API version change, auth, and re-login across potentially 100 tool…1:28:34

DIY tool scripts mean you maintain every API version change, auth, and re-login across potentially 100 tools, running on your machine's CPU/GPU. An MCP server is the vendor's headless machine running the vendor's tools — Google maintains the Gmail MCP, so API churn and compute are their problem.

A server is 'just a headless computer' — no monitor/keyboard, 24/7 CPU/RAM executing scripts (1:32:39)

Company incentive: users now live in LLM interfaces; an Outlook MCP requires an Outlook subscription — MCP is a distribution and revenue channel, which is why enterprises adopted the playbook (1:34:42)

Security posture: first-party MCPs (Google's Gmail, Anthropic's connectors) carry the vendor's credibility stake; configure granular directory/approval permissions, use allow-once (1:14:18)

10Claude Desktop connectors, hands-on'Connectors' is Claude's word for MCPs.1:02:06

'Connectors' is Claude's word for MCPs. Baseline shown first (no calendar/email access), then Gmail + Google Calendar connected live — every new connector requires fully restarting the desktop app — followed by cohort-wide exercises on free accounts using Haiku to conserve tokens.

Exercise prompts: 'Look at my calendar for the next 5 days — what's my most intense day and what should I defer or delegate to survive it?' and 'Find 2 hours in the next 3 days for deep work and create the slots' (1:54:35–1:58:39)

Filesystem connector: tool list read aloud (read/write/edit/move/search files, create/list directories); desktop-organizing demo initially failed because Claude ran in a restricted sandbox — a teachable moment on minimal privilege (1:10:15–1:14:18)

Claude-deletes-files fears addressed: third-party connectors or non-Claude models are the usual culprit; first-party connector + Claude model is the safe pairing (1:16:21)

Troubleshooting ladder: update Claude → reinstall/reauth MCPs → restart app → worst case reinstall (2:21:05)

Desktop-vs-web reason: some tools need your local CPU/GPU and filesystem — hence desktop-only connectors (2:19:04)

11External MCPs via marketplaces (Smithery, Composio)Beyond the built-in directory: browse Smithery's MCP pages, copy the hosted server URL (this Google Sheets…2:02:51

Beyond the built-in directory: browse Smithery's MCP pages, copy the hosted server URL (this Google Sheets MCP was served via Composio; rated, with usage counts), then Claude settings → connectors → add custom connector → paste URL → authorize.

Demo: web search + Google Sheets MCP → 'analyze all iPhone models, US vs India pricing with currency conversion, into a new sheet' — competitor research without leaving Claude (2:14:59)

Chrome control connector is Mac-only; Windows learners pointed to Puppeteer/Playwright-style MCP alternatives (2:00:50)

MCPs compose: email + calendar + sheets + drive tools can run parallel or sequentially in one conversation (2:19:04)

12ChatGPT 'apps' — the rival connector modelChatGPT's MCP equivalent lives under Settings → Apps, browser-based rather than desktop-local (opposite rou…2:23:07

ChatGPT's MCP equivalent lives under Settings → Apps, browser-based rather than desktop-local (opposite route from Claude); recently launched and less reliable in the trainer's usage (~4/10 vs Claude's 7/10); no Google apps (rivals); Gemini has no connectors yet.

Canva app demo: 'MCP masterclass invitation, modern corporate, neon-green' generated in-chat, then opened in Canva for editing (2:29:12)

Current limit: one tool per chat — selecting image generation drops the Canva connector (2:33:16)

13Same prompt, different outputsClosing Q&A: AI is a probabilistic next-word engine, not deterministic — the whole cohort ran identical Can…2:35:17

Closing Q&A: AI is a probabilistic next-word engine, not deterministic — the whole cohort ran identical Canva prompts and got different designs; you can constrain outputs but never make an LLM deterministic.

Tools referenced

ToolCoverageMomentContext
Claude Desktopdemonstrated1:02:06The host app throughout: connectors directory, custom connector URL entry, allow-once permission flow, app-restart requirement, Haiku model selection on free plan
Gmail connector (Claude)demonstrated1:04:08Connected live; 'latest 2 emails from Outskill' query showing the tool-call trace
Google Calendar connector (Claude)demonstrated1:52:23Cohort exercise: intense-day triage and deep-work slot creation, verified in learners' calendars
Filesystem connector (Claude)demonstrated1:08:13Anthropic-partner connector; tool inventory walkthrough; desktop-declutter demo hit the sandbox restriction — used to teach minimal privilege
Google Sheets MCP (via Smithery/Composio)demonstrated2:04:53Custom connector add; iPhone US-vs-India pricing sheet with web search; '74/100 best-practices rating, ~40k users' read off the listing
Smitherydemonstrated2:02:51MCP marketplace browsed live; per-MCP Claude install instructions with hosted URL
ChatGPT appsdemonstrated2:23:07Settings → Apps → add more; Canva connected and invitation designed in-chat; one-tool-per-chat limitation shown
Canva (ChatGPT app)demonstrated2:29:12Invitation cards generated from a single prompt, then opened in Canva for customization
Haiku (Claude model)demonstrated1:56:37Recommended over Sonnet 4.6 on free plans — faster, cheaper, more tokens; 'Haiku 4.5' cited for retries
ChatGPTdemonstrated2:23:07Rival connector ecosystem; apps feature ~5-6 months old per trainer, reliability ~4/10 vs Claude 7/10
n8nexplained0:19:15Callback anchor: the AI agent node (model/memory/tools) reframed as simplified tool calling; Gmail/Calendar nodes as prewritten API scripts
Figma MCPexplained0:47:49Possibility example: design/wireframe from Claude without opening Figma
Blender / AutoCAD MCPsmentioned0:51:543D home/game-character designs from chat as MCP possibilities
Control Chrome connectormentioned2:00:50Mac-only at session time; Windows learners steered to Puppeteer/Playwright MCP alternatives
Geminimentioned2:25:09No connectors yet at session time
Ollamamentioned1:16:21Cited as a source of file-deletion horror stories when open-source models drive Claude-style tooling

Session materials

Archived locally on V: — click to open. Companion pages link to the LMS.

Action items

Resources mentioned

Resources
  • docCalendar triage prompt ('most intense day… defer or delegate to survive it') — shared in chat 1:54:35
  • docDeep-work scheduling prompt ('find 2 hours in the next 3 days… create the slots') — shared in chat 1:58:39
  • docGoogle Sheets MCP hosted URL (Smithery listing, Composio-served) — shared in chat 2:08:56
  • dociPhone US-vs-India pricing comparison prompt — shared in chat 2:14:59
  • docCanva invitation prompt (MCP masterclass, neon-green theme) — shared in chat 2:29:12
  • docTrainer's socials/LinkedIn for follow-ups 2:39:30

Extraction notes

This page was built from an auto-generated transcript, which garbles product and people's names. Those were corrected silently in everything above and logged here for transparency. The warnings flag claims that were true on the recording day but change fast.

Transcript corrections applied

The transcript saysThe trainer actually means
ChargeGPT / Chargegbt / ChartGPT / chat JPT / ChargePointChatGPT
cloud / clod / plod / Lard / RCloud / claud / big Lord workspaceClaude (/ 'the Claude workspace')
MCB / MC / NCP / m serversMCP
n e 10 / n a 10 / n 8 10 / Anytime / any tenantn8n
drag / ragRAG
sandboardsandboxed
HYCU / HICO / AikoHaiku (Claude model)
Smithery / Smitheri / SmidariSmithery (smithery.ai)
codecsCodex (OpenAI)
Belleranda enginegarbled learner answer, likely 'next-word-prediction engine'
Plod or OpenAIClaude or OpenAI
sixteenth may16 May (example date in tool-calling walkthrough)
puppeteerPuppeteer (browser-automation MCP)
VM service (learner question)uncertain — unresolved in session
74 out of 1074 out of 100 (Smithery reliability rating as displayed)

True on recording day — verify before relying