All video notes
Video notes · MCP

Why MCP really is a big deal | Model Context Protocol with Tim Berglund

Video by Confluent Developer on YouTube · 11 min · uploaded May 2025

Notes and analysis by BrainTube, written from the video. Not affiliated with Confluent Developer. Watch on YouTube

In short

Tim Berglund argues that MCP matters less for desktop chat apps than as a way to build pluggable, discoverable and composable agents inside a company. His whiteboard walkthrough of host, client and server, and of who actually executes a tool call, is one of the clearest short explanations available. A few technical details were already out of date or wrong at the May 2025 upload, notably the description of RESTful endpoints and HTTP with Server-Sent Events as the remote transport.

The argument

Berglund's case is that a model on its own produces words, while agents need two extra things: the ability to act through tools, and access to data the base model does not have, such as files, databases or a stream of events. You could hard-code every integration into one agent, but then nobody else can reuse it. MCP moves those integrations into servers that describe their own tools, resources and prompts, so any host application can discover and plug them in, and servers can themselves be clients of other servers. That combination of pluggability, discoverability and composability is why he thinks MCP is a gateway to agentic AI in professional settings, not a desktop novelty.

Key ideas, with timestamps

  1. 0:23

    Drop the USB-C analogy

    He opens by rejecting the popular line that MCP is the USB-C of AI apps, saying it did not help him understand anything. Instead he builds up from how a model works from the outside: prompt in, words out. It sets the tone for an explanation based on mechanics rather than slogans.

  2. 0:45

    Two gaps: action and fresh data

    A response made of words is fine until you need an effect in the world, which requires tools. The model also lacks current or private information. At 1:22 he defends retrieval-augmented generation as a perfectly good enterprise pattern, then lists other sources an agent might need: files, binaries, databases and Kafka topics.

  3. 2:19

    Host, client, server

    The agent you build is just a microservice, which MCP calls the host application. It uses the MCP client library to create a client. The server exposes tools, resources and prompts, and at 3:22 a capabilities list that tells the client which of those exist.

  4. 3:39

    Two transports, JSON-RPC messages

    Client and server can talk over standard IO when both run on one machine, as with Claude Desktop examples, or over a network. He sets local pipes aside as not the point for enterprise work, names HTTP with Server-Sent Events as the remote option, and notes messages are JSON-RPC, choices he says have raised some eyebrows.

  5. 4:42

    An appointment-booking example

    The worked example is a service that books coffee, breakfast or dinner with someone. It needs calendar access to find free time, possibly the other person's calendar, a list of nearby places, perhaps from Yelp, and the ability to make reservations. At 5:25 he sorts these: knowing about places and free time fits as resources, while creating the appointment is a tool.

  6. 6:04

    The two-pass resource flow

    For the prompt about having coffee with Peter next week, the host first asks the server what it offers, then lists its resources with their descriptions. At 7:06 it asks the model which resources the request needs, the model picks the coffee-shop list, the client fetches it, and a second prompt combines the request with that data. He stresses that good resource descriptions are the server author's job.

  7. 8:27

    The model recommends, the client acts

    Tool descriptions and parameter schemas go into the model API call as structured data, and the reply says which tool to call with which arguments. At 9:13 he makes the key point: ChatGPT, Claude or Gemini do not call anything inside your network. Your client code decides whether to run the call, with or without asking the user.

  8. 9:57

    Servers can be clients

    Composability is his closing argument. A server that needs data from a Kafka topic can act as a client of another MCP server, such as Confluent's, rather than embedding Kafka code. Pluggable, discoverable and composable is his summary of why this is a big deal.

What it gets right

Who executes a tool call is the most misunderstood part of MCP, and he nails it. The model only proposes a call. The host runs it, so permissions, approval prompts and logging all belong in your code, not in the model. Anyone designing an agent for a company should start from that fact.

Tools versus resources is explained with a usable rule of thumb: things the agent reads go in resources, things that change the world are tools. Few short explainers cover resources at all.

The enterprise framing is a useful corrective. In 2025 most MCP content was about plugging servers into desktop apps. Treating the host as an ordinary microservice and MCP servers as shared, reusable integration points is closer to how teams actually adopt it.

Composability is real. Servers calling other servers lets a team reuse one well-maintained integration, such as a Kafka connector, instead of each agent carrying its own copy.

What it gets wrong or leaves out

MCP is not a set of RESTful endpoints. At 3:13 he describes the server as implementing well-known RESTful endpoints. MCP is a JSON-RPC protocol: capabilities, tool lists and calls are JSON-RPC methods over one connection, not separate REST routes. The distinction matters when you debug traffic or put a gateway in front of a server.

The transport was already changing. The March 2025 revision of the spec introduced Streamable HTTP to replace the original HTTP with Server-Sent Events transport. By this May 2025 upload, new remote servers were moving to the newer transport, so treat the SSE detail as historical.

The resource flow is one pattern, not the rule. In the spec, resources are meant to be controlled by the application. Many clients let the user attach a resource rather than asking the model in a first pass. His two-pass approach works, but it costs an extra model call per request.

Tool definitions do not carry a URL. At 8:48 he lists the tool's URL among what goes into the API call. In practice the model sees a name, description and input schema; the host knows which server to route the call to.

Security and auth are missing. For an enterprise pitch, there is nothing on authenticating clients, scoping what a server may do, or prompt injection through resource content. The spec added an authorization framework in 2025, and it deserves at least a mention. He also promises to return to server notifications and never does.

How this applies to memory across AI tools

His tools-versus-resources split is a good lens for memory. Reading past knowledge is resource-like or a search tool; saving new facts is a tool with side effects. Putting that memory behind an MCP server makes it pluggable and discoverable in exactly his sense: any host can find it and use it, instead of each assistant keeping its own silo. The MCP memory server explainer goes further.

BrainTube applies the pattern to research material: it saves YouTube videos with their transcripts, articles, PDFs and podcasts into one compiled knowledge base and exposes it as an MCP server that Claude, ChatGPT, Cursor and other MCP clients can search. For how retrieval fits alongside this, see RAG explained.

Who should watch it

Watch it if you are an engineer or architect who wants a precise mental model of MCP in eleven minutes, especially if you plan to build agents as services rather than use desktop apps. The architecture from 2:19 to 4:30 and the request walkthrough from 6:04 to 9:40 are the core; 9:13 is the single most important point. Skip it if you want code or setup steps, as it is whiteboard only. Read the transport details against the current spec, since the HTTP and Server-Sent Events option he describes has since been superseded.

Frequently asked

What is the difference between MCP tools and resources?
Resources are data a server makes available for reading, such as files, records or a list of nearby places. Tools are actions with effects, such as creating a calendar event or making a booking. In the spec, tools are meant to be called by the model, while resources are usually selected by the application or user.
Does the LLM call MCP tools directly?
No. The model only returns a suggested tool call with arguments. The host application's MCP client decides whether to run it, optionally after asking the user, and sends it to the right server. That is where permissions and approvals should be enforced.
What transports does MCP use?
MCP messages use JSON-RPC. Locally, client and server can communicate over standard input and output. For remote servers, the current spec uses Streamable HTTP, which replaced the earlier HTTP with Server-Sent Events transport in the March 2025 revision.

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.