All video notes
Video notes · MCP

How Model Context Protocol (MCP) actually works

Video by Google Cloud Tech on YouTube · 8 min · uploaded June 2026

Notes and analysis by BrainTube, written from the video. Not affiliated with Google Cloud Tech. Watch on YouTube

In short

This Google Cloud Tech explainer teaches the basic shape of the Model Context Protocol: servers advertise tools, resources and prompts, clients discover and call them, and MCP sits on top of existing APIs rather than replacing them. That framing is right and clearly explained. It gets two details wrong (the model is not the client, and "context" is not a separate primitive) and leaves out transports, authentication and security risks entirely.

The argument

The video's argument is that APIs were built for programs that already know exactly what to request, while language models work probabilistically and need to explore before acting. MCP closes that gap with one consistent interface. A server describes its capabilities, each with metadata about inputs and outputs, and any compliant model can discover and use them without custom integration code. Under the hood the server may still call REST or GraphQL APIs, but the model only sees the MCP schema. The presenter compares this to how HTTP unified the web and argues every serious AI developer will soon need to make their systems MCP aware.

Key ideas, with timestamps

  1. 0:04

    The problem MCP targets

    The opening names three pains: every API behaves differently, every integration needs custom code, and connections break when the model changes. MCP is introduced as the fix, an open standard first released by Anthropic and now adopted more widely.

  2. 1:33

    Why APIs are a poor fit for models

    APIs assume a caller that forms precise, deterministic requests. A model reasons about uncertain inputs and often needs to explore first. MCP gives it a structured way to see what functions, datasets, documents and prompts are available, use them and chain several together.

  3. 2:33

    Clients and servers

    The protocol has two sides. The video describes the client as the model or agent (Claude, Gemini, or an agent built on OpenAI or Google frameworks) and the server as whatever exposes resources: a database, a file system, internal tools or a document search engine.

  4. 3:05

    Servers advertise, they do not just answer

    On connection, the server describes its capabilities, available resources, possible actions and required inputs. The client sends requests such as listing resources or calling an action, and the server replies with structured JSON. This discovery step is the core idea of the video.

  5. 3:52

    The building blocks

    Tools are actions such as searching a database, sending email or analysing a file. Resources are data like a document, a database row or an image. Prompts are reusable task templates. The video adds a fourth type, context, covering chat history, company data and user preferences.

  6. 5:06

    An abstraction above APIs

    MCP does not replace APIs. A server can wrap existing REST or GraphQL endpoints, and the model only sees the uniform schema that handles discovery, validation and execution. That is what lets one system be exposed to any compliant model.

  7. 6:00

    Worked example: a personal assistant

    Without MCP, an assistant that checks a calendar, pulls meeting notes and drafts follow-ups needs custom code for Google Calendar, Notion and Gmail, plus long system prompts. With MCP, three servers advertise tools like list events, get meeting summary and send email, and the model decides the order.

What it gets right

Discovery is the point. The most important idea in MCP is that a server describes itself at runtime, so a client does not need to be built against each integration. The video makes that the centre of its explanation, which many explainers miss.

MCP wraps APIs, it does not replace them. The 5:06 section is the clearest answer to the common "MCP vs API" confusion. Your existing endpoints stay. An MCP server is a thin, model-facing layer on top that you write once and every compliant client can use.

The assistant example is realistic. Calendar, notes and email is a fair test case, and it shows the real benefit: the integration work moves from each app into reusable servers.

What it gets wrong or skips

The model is not the client. In the MCP specification, a host application (such as Claude Desktop, an IDE or an agent runtime) creates one client per server connection. The model sits inside the host and chooses tools; the client handles the protocol. The difference matters when you debug, because the host, not the model, decides which servers are connected and what is allowed.

"Context" is not a primitive. The server-side building blocks in the spec are tools, resources and prompts. Chat history and user preferences come into a conversation through those, mainly resources, or through the host. Listing context as a fourth type will confuse anyone who then reads the spec.

No mention of the wire format. MCP messages are JSON-RPC 2.0, sent over standard input and output for local servers or over HTTP for remote ones, with method names like tools/list and tools/call. Knowing this makes the protocol far less mysterious.

Glue code moves, it does not vanish. Someone still writes each server, handles authentication and rate limits, and keeps it working. The gain is reuse across clients, not zero work.

Security is reduced to the word "safe". The video calls MCP safe and standardised but never covers how remote servers authenticate users, the risk of prompt injection through tool results, or untrusted servers with misleading tool descriptions. Anyone installing third-party servers needs to know about these. Every connected tool's description also takes up context, so many servers can crowd the model's window.

How this applies to memory across AI tools

The property the video describes, one server usable by any compliant client, is what makes shared memory across assistants possible. If your notes or saved sources sit behind an MCP server, the same store is reachable from several assistants instead of being locked into one app's built-in memory.

BrainTube is one example of that pattern: it saves YouTube videos with their transcripts, articles, PDFs and podcasts into one compiled knowledge base and exposes it as an MCP server, so Claude, ChatGPT, Cursor and other MCP clients can search it.

For a fuller primer, see what MCP is and what an MCP memory server is.

Who should watch it

Watch it if you have heard of MCP but never understood why it exists alongside APIs. At under eight minutes it can be watched in full; the most useful parts are 2:33 to 3:48 (clients, servers and discovery) and 5:06 to 7:01 (MCP above APIs and the assistant example). Skip it if you already build MCP servers, since there is no code, no transport detail and no security guidance. Pair it with the official specification if you plan to build one.

Frequently asked

What is the difference between MCP and an API?
An API is an interface a program calls with exact requests. MCP is a protocol that sits on top, letting an AI application discover what a server offers and call it in a uniform way. An MCP server often wraps existing APIs, so the two work together.
What are tools, resources and prompts in MCP?
They are the three things an MCP server can offer. Tools are actions the model can run, such as a search or sending an email. Resources are data the application can read, such as files or records. Prompts are reusable templates for common tasks.
Is the AI model the MCP client?
Not exactly. The host application, such as a desktop chat app or an IDE, runs an MCP client for each connected server. The model inside the host decides which tools to use, and the client carries those requests to the server.

Keep videos like this one searchable

BrainTube saves YouTube videos with their transcripts into one compiled knowledge base that Claude, ChatGPT, Cursor and other MCP clients can search.

Start free

Go deeper

More video notes

Are you the creator and want this page changed or removed? Contact us and we will act within 48 hours.