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

The starting point for Model Context Protocol (MCP) is that a model’s usefulness depends heavily on the context available to it. Earlier AI applications often required people to copy and paste information from other systems; more capable applications instead connect directly to relevant data and tools. MCP is presented as an open protocol for making those connections consistent across AI applications, agents, and external systems. 0:35

The design draws inspiration from Language Server Protocol (LSP): a language server can be implemented once and used by compatible development environments rather than rebuilt separately for every editor. MCP applies the same interoperability idea to AI applications. Without a shared interface, each application or internal team may invent its own prompting, tool integration, data access, and permission patterns, producing an expensive many-to-many integration problem. 1:41

In this architecture, an MCP client connects to an MCP server, which exposes access to systems such as databases, Salesforce, local files, and Git. Application builders gain a reusable integration surface, while tool and API providers can publish one server for multiple compatible clients. Within an enterprise, a team responsible for a vector database or retrieval system can maintain its own server while other teams build applications against that shared interface, creating a separation of responsibilities resembling microservices. 4:16

MCP organizes server capabilities into tools, resources, and prompts. Tools are model-controlled: the server describes available operations, and the model determines when an operation is appropriate. Those operations can retrieve information, update databases, write files, or take actions in external applications. Murag suggests tools are especially useful when the right moment to retrieve information is uncertain; if a database call should happen deterministically every time, the application can make that call directly instead. 2:59

Resources are application-controlled data such as files, images, text, or JSON. They can be static or generated dynamically using information from the user or client. Claude for Desktop presents resources as attachments that a person can select, while applications can also decide to attach relevant resources automatically. Resource subscriptions add another useful behavior: a server can notify a client when a resource changes so the application can refresh its state or inform the user. 10:43

Prompts are user-controlled templates for recurring interactions. Murag highlights Zed’s slash-command pattern, where a short command and pull-request identifier expand into a more complete instruction for the model. Teams can likewise encode preferred document-question-answering formats or transcript presentation rules as reusable server-provided prompts, leaving the user to decide when a particular workflow should run. 12:57

Although many capabilities could technically be represented as tools, the distinction is architectural: MCP is intended to coordinate the model, the application, and the user rather than route every decision through the model. Applications can invoke server functions deterministically without involving an LLM, and a tools-only agent may not need resources or prompts at all. Those additional primitives become more valuable when a user-facing interface needs to display plans, attach context, or offer explicit commands. 14:04

A practical demonstration combines GitHub and Asana through Claude for Desktop. Given a repository, the model selects a GitHub tool to list issues and summarizes or prioritizes them using other context available in the application. When asked to add high-priority issues to an Asana project, it discovers the relevant workspace and project before creating tasks. The important architectural point is that independently built servers can participate in one workflow while the client retains its own interaction design and contextual knowledge. 23:00

Murag describes an agent as an augmented LLM running in a loop. Retrieval, tools, and memory extend the model’s capabilities; the loop lets it pursue a goal, invoke an operation, inspect the result, and continue. MCP supplies a standardized connection to those capabilities, but it does not replace an agent framework’s responsibilities for orchestration, context management, memory, model selection, or the behavior of the loop itself. Existing frameworks can connect through adapters instead of requiring a complete redesign. 16:52

The MCP-Agent example, built around an open-source framework from Last Mile AI, divides a research task into a researcher, a fact-checker, and a report writer. The first two receive access to Brave, Fetch, and FileSystem servers, while the writer receives FileSystem and Fetch without the search capability. An orchestrator creates a plan, assigns steps to the appropriate sub-agents, and combines their work. This demonstrates capability assignment by role and lets the application developer concentrate on the task and coordination rather than implementing every underlying integration. 29:39

This separation does not eliminate practical design choices. Builders still decide which model fits a task, how to compress or summarize growing context, whether multiple agents run sequentially or in parallel, and how results reach the user. Tool catalogs also introduce context pressure: Murag describes practical limits in terms of dozens or hundreds of tools and proposes searching over tool descriptions or progressively exposing hierarchical tool groups instead of placing thousands of tools directly in the prompt. 36:32

Sampling reverses the usual direction of an AI application’s requests: an MCP server can ask its client to obtain an LLM completion instead of hosting a model or implementing its own model integration. The server may provide prompts and request preferences such as model size, temperature, or maximum tokens. The client still decides whether to honor the request, which preserves its control over model choice, privacy, cost, and suspicious or excessive inference requests. 53:01

Composability means the distinction between client and server is logical rather than physical: one component can serve an upstream application while acting as a client of downstream services. A research agent, for example, can appear as a server to Claude for Desktop and then call separate file, fetching, or web-search servers. Combining composability with sampling suggests a hierarchy in which specialized agents delegate work while inference requests flow back toward the application controlling the model. Murag explicitly presents the more elaborate hierarchical arrangement as a future possibility rather than an already established deployment pattern. 55:34

These richer interactions go beyond a simple request for data because protocol features can support server-to-client communication, resource notifications, and multistep exchanges. However, composability does not solve compounding errors: each intermediate component must validate, structure, and consolidate downstream results before passing them onward. Requests for user input may need to travel back through the chain, and network leadership or decision-making is left to the application architecture rather than prescribed by MCP. 58:09

The protocol also does not guarantee visibility into every downstream service. An upstream server may function as a black box, and observability depends on what builders choose to expose through logs or metadata. Murag points to Inspector as a way to inspect connections and logs, but acknowledges that debugging conventions and broader best practices are still developing. Likewise, direct server-to-server data transfer that avoids routing large payloads back through the client is not described as a first-class supported capability. 1:03:42

The workshop distinguishes local integrations using standard IO from remote integrations demonstrated over SSE, while emphasizing that MCP itself is transport-agnostic. In the remote Slack example, Inspector connects to a server URL, the server coordinates an OAuth 2.0 authorization flow, the user approves access in a browser, and the server holds the upstream OAuth token while providing the client with a session token. The goal is to let the application and model run separately from the infrastructure exposing the external service. 1:12:57

This arrangement deliberately places substantial responsibility on the server because it is closest to the protected application and can regulate access to that application’s data. Murag argues that authentication, authorization, and potentially service-specific retry or logging behavior often belong near the server, particularly when a client has never encountered that server before. He also acknowledges that the allocation of retry logic and related infrastructure responsibilities remains unsettled and may depend on what server builders and agent frameworks choose to own. 44:37

The security implications are not abstract. Because servers may hold sensitive tokens and expose write operations, users must be selective about which servers they trust. The initial authorization approach discussed does not support permission elevation out of the box, and Murag says practices for least privilege and broader data governance are still emerging. Proposed tool annotations, such as whether an operation is read-only or can write, could help clients distinguish riskier actions, but are presented as an area under consideration rather than a completed guarantee. 1:08:17

Operational stability also remains an application responsibility. Existing package versions can help pin server behavior, but changes to tools, descriptions, prompts, or resources can still disrupt established workflows even when client and server continue to follow the protocol. Murag recommends treating new server versions as inputs to the same tool-use evaluations already needed for agents: test whether the model selects the appropriate tool, handles responses correctly, and behaves consistently across versions. 51:12

Murag describes an MCP registry as a proposed hosted metadata service developed in the open. Its purpose is to organize a fragmented ecosystem by describing where servers live, which transport they use, who created them, whether they are verified, and how their capabilities change across versions. The registry is intended to sit above existing distribution mechanisms such as npm and pypi, while also accommodating remotely hosted endpoints, private registries, Docker-based packaging, and application-specific marketplaces. At the time described in the talk, this registry is under development rather than an already available system. 1:21:42

For agents, discovery introduces the possibility of dynamically acquiring capabilities. Murag imagines a coding agent asked to investigate Grafana logs even though it was not originally configured with a Grafana integration: the agent could search a registry, identify an appropriate verified server, connect to it, and continue the task. This is presented as a forward-looking example of agents discovering tools during execution, not evidence that the complete workflow already exists or is safe by default. 1:35:39

Dynamic installation creates a corresponding governance problem because an agent might otherwise execute arbitrary server code or obtain excessive access. Suggested controls include privately hosted registries, approved-server lists, intermediary discovery tools that filter available integrations, and verification of official publishers. Murag distinguishes confidence in a model’s ability to choose relevant tools from confidence in the trustworthiness of unfamiliar servers, and says the latter depends on infrastructure and practices that are not yet fully established. 1:37:24

A complementary discovery idea uses .well-known metadata on a service’s own domain to advertise an MCP endpoint, available capabilities, and authentication requirements. Murag presents a hypothetical Shopify example, explicitly noting that the displayed URL is not real. He also sketches a hybrid agent that uses structured MCP interfaces when available and computer-use interactions for interfaces without suitable APIs. Other open roadmap questions include short-lived versus stateful connections, streaming, tool-name collisions, logical tool grouping, and proactive server behavior. 1:38:57