MCP standardizes how AI applications connect to external tools, data, prompts, and resources.
2
MCP complements agent frameworks by providing a common context and tool layer, while frameworks manage loops, orchestration, and knowledge management.
3
Remote servers, authentication, registries, sampling, and composability could let agents discover and use capabilities that were not built into them initially.
Summary
Mahesh Murag introduces the Model Context Protocol as an open standard for connecting AI applications and agents to external systems. He explains MCP through three interfaces: tools, which the model can invoke; resources, which the application controls; and prompts, which the user invokes. Examples with Claude for Desktop, GitHub, Asana, Windsurf, and an MCP agent framework show how developers can reuse servers instead of writing separate integrations. Murag argues that MCP complements agent frameworks, since those frameworks still manage loops, orchestration, and context management. He then discusses sampling, where servers can request model inference through the client, and composability, where an application or agent can be both an MCP client and server. The final section covers remote servers, OAuth, registries, discovery, versioning, streaming, namespacing, and proactive server behavior. He is candid that governance, debugging, and other practices are still developing.
MCP standardizes the connection between AI applications and external systems
Murag starts from the idea that models are only as good as the context they receive. MCP provides an open protocol for connecting AI applications and agents to tools and data sources. He compares it with APIs, which standardize communication between web application components, and the Language Server Protocol, which lets compatible IDEs use language-specific tooling. MCP applies a similar pattern to AI applications. Its stated interfaces are prompts, tools, and resources. Before MCP, teams created separate implementations for prompt logic, tool access, data retrieval, and authorization. MCP aims to replace those repeated client-server integrations with a shared layer.
A single MCP client can connect to servers built by different providers
An MCP-compatible client can connect to any MCP server without additional integration work. A server can wrap a database, a CRM such as Salesforce, or local systems such as Git and version control. Murag describes this as flattening the N-times-M problem between application developers and tool or API providers. Application developers build the client once. A provider builds its MCP server once and can make it available across compatible applications. Inside an enterprise, one infrastructure team could maintain an MCP server for a vector database, while other teams use that shared interface instead of rebuilding retrieval and chunking logic.
Tools, resources, and prompts divide control between the model, application, and user
Tools are model-controlled. The server exposes their descriptions and schemas, and the language model chooses when to call them. They can retrieve data, write to systems, update databases, or modify local files. Resources are application-controlled. A server can expose static or dynamic files, JSON, images, or other data, and the client decides whether to attach them to the conversation or send them to the model. Prompts are user-controlled templates for recurring interactions. Murag uses Zed slash commands as an example, where a command such as a PR summary expands into a longer predefined prompt. The separation gives each layer more control.
MCP adds a context layer to agent frameworks instead of replacing them
Murag says MCP and agent frameworks complement each other. An adapter can let a LangGraph agent use MCP servers without changing the agent system itself. MCP handles a standard way to bring in tools, prompts, and resources. An agent framework can still manage the agentic loop, knowledge management, context compression, orchestration, and how the model responds to tool results. His example uses MCP Agent from Last Mile AI. An orchestrator coordinates a research agent, a fact-checking agent, and a report-writing agent. Each receives access to selected servers such as Brave search, fetch, and the filesystem.
MCP lets an agent builder focus on the task while reusing existing servers
The MCP Agent example is a small Python application for researching quantum computing's impact on cybersecurity. The research agent searches the internet and stores information, the fact-checker verifies it, and the report writer combines the results into a formatted file. Murag did not build the Brave, fetch, or filesystem servers used in the example. The framework declares the task, the agents, and the servers available to each agent. This leaves the builder focused on the agent loop and the work each sub-agent must perform. He also says MCP servers can run inside a company's VPC or on employees' systems for proprietary data.
Sampling lets servers request model inference through the client
Sampling allows an MCP server to request an inference call from the client instead of implementing its own model integration. A server might decide that it needs more information from the user or need help formulating a question. The client retains control of the model interaction, including model choice, privacy, cost, and request limits. A server can express model preferences and pass system and task prompts, along with settings such as temperature and maximum tokens, but the client can reject the request. Murag presents this as useful when a client has never seen the server before but the server still needs access to model intelligence.
Composable MCP clients and servers can form layered agent systems
MCP treats the client-server boundary as a logical separation rather than a physical one. An agent can be an MCP server to the application above it and an MCP client to the services below it. A research agent might call filesystem, fetch, and web search servers, then return its result to the requesting client. This supports layered systems where different agents specialize in different tasks. Murag says MCP provides richer interactions than simple HTTP data passing because servers can request information, perform asynchronous work, send notifications, and make decisions. Each layer still needs to inspect and structure incoming data before passing it onward.
Remote servers and registries are intended to reduce installation and discovery friction
MCP's OAuth 2.0 support and remote-server transport allow a server to live at a public URL instead of requiring local standard input and output setup. In the inspector demonstration, a Slack server handles the authentication flow, receives the OAuth token, and gives the client a session token for later interactions. Murag says remote hosting could make servers feel more like websites that users visit. He also describes an official MCP registry API for metadata, discovery, verification, transport details, and version history. Companies could host private registries, similar to an internal artifact repository, and control which servers agents can access.
Future MCP features aim to support self-evolving agents while keeping control with clients
Murag connects registries with agents that discover capabilities at runtime. His example is a coding agent that searches for an official Grafana server when asked to inspect logs, even though that server was not included when the agent was initialized. He says users will need controls such as private registries, allowlists, and verification. Other planned areas include short-lived or resumable connections, streaming, tool namespacing, and proactive server behavior. He also describes a combination of computer use and MCP, where an agent can call structured APIs when they exist and use a graphical interface for systems without APIs. These ideas were presented as areas still under development.
"The point is this is a really nice interaction because one of the design principles as we talked about is oftentimes these servers are going to be something where the client has never seen them before."55:56
Who should watch
You are building an AI application that needs access to databases, files, GitHub, CRMs, or other external systems and want to avoid separate integrations for each client.
You already use an agent framework and need a standard way to provide tools, prompts, or resources to its agents.
You are evaluating remote tool servers and need to think through authentication, discovery, private registries, verification, and tool growth.
