Building Agents with Model Context Protocol - Full Workshop with Mahesh Murag of Anthropic

The control split is the most useful idea here, and many shorter explainers skip it. Asking who decides when something enters the context (the model, the app or the user) explains why resources and prompts exist at all, which an audience member challenges at 14:00. Murag's answer holds up: tools alone can move data, but they give the app and the user no say.

The enterprise vector database example is also well chosen. Most teams meet MCP as a way to plug public services into a chat app. The bigger payoff inside a company is ownership: one team maintains retrieval quality, chunking and access rules, and everyone else consumes a stable interface.

He is honest about open questions. On observability, retries and versioning he says best practices are still emerging, and he admits at 1:28:15 that Claude has no special MCP advantage beyond being good at tool use.

• Transports. At 1:32:02 he describes stdio for local servers and SSE for remote ones. Later spec revisions replaced the HTTP plus SSE transport with Streamable HTTP, so check the current spec before building a remote server.
• Who holds the token. The demo has the MCP server run the OAuth flow and hold the third party token. Later versions of the authorization spec moved toward treating the MCP server as a resource server, with a separate authorization server issuing tokens. The core concern raised at 1:17:01, whether servers should hold tokens, was a fair one.
• Roadmap items. Tool annotations such as read versus write (1:08:07), elicitation and the registry were plans at the time. Several have since shipped in some form, so treat this section as history, not documentation.
• Security. The talk says to be judicious about which servers you connect to, but it does not cover the specific risk that tool descriptions and tool results land in the model's context. A malicious server can steer the model through them. Composed agent trees make this worse, since every layer passes text upward.
• Tool count. "Good up to a couple hundred" tools is optimistic for most setups. Each tool description costs context, and selection gets less reliable as similar tools pile up. His own suggestions, tool search and progressive groups, are the better default.
• Sampling in practice. He calls sampling underused. That was true, and it is still uneven, because many clients did not implement it, so a server design that depends on it can fail on popular clients.

At 27:00 Murag draws the augmented LLM with three arrows: retrieval, tools and memory, and he says MCP is the layer under all three. That is the practical takeaway for knowledge work. If your notes, transcripts and documents sit behind one MCP server, every client you use reaches the same material, and you stop rebuilding context per app. See what an MCP memory server is for the general pattern.

The control split matters here too. Search over a knowledge base fits a model-controlled tool, because the model should decide when it lacks information, which is exactly his answer at 15:00 about vector databases. A fixed reference document fits a resource the app attaches. BrainTube follows the tool 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 how this differs from built-in chat memory, read persistent AI memory across tools.