AnthropicWhy we built—and donated—the Model Context Protocol (MCP)
CHAPTERS
- 0:00 – 0:29
MCP and the Linux Foundation donation: what’s being transferred and why it matters
The conversation opens on the practical meaning of donating MCP to the Linux Foundation—especially transferring trademarks, licensing stewardship, and other legal control away from Anthropic. The core promise is long-term stability: organizations can adopt MCP without fear that ownership or terms will later change.
- •Donation moves trademarks and licensing administration to a neutral nonprofit
- •Reduces risk of license changes or “rug pulls” by any single company
- •Creates confidence for “big players” to invest in MCP integrations
- •Frames donation as ecosystem safety rather than a product move
- 0:29 – 1:24
What MCP is: connecting LLM apps to real-world tools and software
Stuart frames the central problem: LLMs produce text, but users want them to act in the real world by interfacing with software (and sometimes hardware). MCP is introduced as an open standard that enables these connections across many applications and integrations.
- •LLMs need connections to external systems to be useful beyond text
- •MCP is an open source standard for app↔integration connectivity
- •Positions MCP as a general bridge for AI applications
- •Sets up the announcement context: donation to the Linux Foundation
- 1:24 – 2:46
The problem MCP solves: “write the integration once” across apps and models
David explains the frustration of copy/paste workflows and “models trapped in a box.” MCP’s goal is to give the model “limbs” by enabling a single integration to work across multiple clients (e.g., Claude Desktop and IDEs) instead of rebuilding proprietary connectors repeatedly.
- •Avoids bespoke/proprietary connectors per model provider or per app
- •Supports multiple clients (Claude Desktop, VS Code, Zed, etc.)
- •Core value: build an integration once and reuse it broadly
- •Turns AI from passive chat into connected, tool-using workflows
- 2:46 – 3:45
The USB‑C analogy: one common connector instead of a tangle of adapters
Stuart proposes USB‑C as a metaphor for MCP: a shared interface that allows different devices to interoperate. David accepts the analogy as “good enough,” emphasizing the benefit of a common language that prevents a proliferation of incompatible connectors.
- •MCP functions like a shared “port” between apps and integrations
- •Reduces fragmentation (compared to many incompatible connectors)
- •Interoperability comes from a common language/protocol
- •Highlights the pain of the pre-standard era (many ports in the ’90s)
- 3:45 – 5:37
How MCP began: internal productivity need, whiteboard design, and early naming
David recounts how the project started from an internal mandate: help researchers and engineers use Claude more effectively day-to-day. The original concept (“Claude Connect,” then “Context Server Protocol”) quickly became “this should be a protocol,” sketched in a London conference room.
- •Originated as an internal enablement project for Anthropic staff
- •Initial idea: a sidecar app connecting Claude Desktop to other tools
- •Shifted quickly from app concept to protocol standardization
- •Early names (Claude Connect, CSP) reflect quick iteration and pragmatism
- 5:37 – 8:04
What made MCP different: open protocol + open-source governance + credibility of a major lab
David outlines why MCP stood out among many “connectors”: it was designed as a protocol in the middle (not tied to one model), run as a participatory open source project, and seeded with enough adoption because it came from a major player. The discussion draws an analogy to open science: transparency enables outside experts to improve the system (e.g., authentication).
- •Protocol is model/provider-agnostic by design
- •Operated like a “traditional” participatory open source project
- •Major-lab origin helped bootstrap early adoption
- •Open-source transparency invited domain experts to fix early assumptions (e.g., auth)
- 8:04 – 11:28
Adoption without mandates: becoming a de facto standard through use
They discuss how standards can emerge through community practice rather than formal standard bodies or regulatory mandates (unlike USB‑C in the EU). David notes the tension between standardization and innovation, and the coming “innovator’s dilemma” once a protocol has a large user base.
- •Early focus: practical usage over formal standardization processes
- •Community uptake is the true engine of standard formation
- •No one is forced to use MCP—adoption is voluntary
- •Future challenge: evolving the protocol without breaking the ecosystem
- 11:28 – 13:34
From internal hackathon to Hacker News: how MCP’s momentum started
David describes key milestones: an internal hackathon where many teams built MCP services (even controlling 3D printers), leadership support to “just go,” and a public open-source release that stayed atop Hacker News for days. Early community building then drew major client integrations like Cursor, accelerating network effects.
- •Internal hackathon validated demand and sparked creativity (e.g., 3D printer demos)
- •Leadership backing enabled rapid open-sourcing
- •Launch generated immediate attention and community server-building
- •Client adoption (e.g., Cursor) made MCP practically useful at scale
- 13:34 – 15:11
The open-source decision and early ecosystem growth across products and providers
They address whether open-sourcing was controversial inside a company and highlight strong internal sponsorship. David notes surprise—and gratitude—that other major model providers adopted MCP, shifting it from an Anthropic-led project to a broadly accepted industry standard.
- •Open-sourcing faced typical product/proprietary skepticism
- •Key leadership (e.g., CPO) supported the open ecosystem approach
- •Early adopters included IDE/tooling companies and platforms
- •Other model providers adopting MCP cemented its status as the standard
- 15:11 – 18:36
Donating MCP to the Linux Foundation and creating the Agentic AI Foundation
David explains what the Linux Foundation does for open source projects—especially acting as a neutral home for trademarks and governance assurances. They introduce the Agentic AI Foundation as a dedicated sub-foundation with major industry participants to support open agentic AI projects alongside MCP.
- •Linux Foundation provides neutral stewardship, funding pathways, and trademark holding
- •Donation reduces risk from changing licenses or ownership control
- •Agentic AI Foundation aggregates major stakeholders (Anthropic, Google, Microsoft, Amazon, etc.)
- •Goal: a community space for multiple open agentic AI projects to coexist and benefit
- 18:36 – 20:34
Governance and the MCP registry: day-to-day continuity, plus supply-chain realities
David stresses that day-to-day project operations remain similar—core maintainers and broader maintainers continue running the project—while the legal ownership changes. They discuss the open MCP registry (like PyPI/NPM), its benefits and risks, and the idea of sub-registries with additional filtering and security checks.
- •Technical governance largely unchanged; legal stewardship becomes neutral
- •Registry allows anyone to publish MCP servers (open participation)
- •Open registries create classic supply-chain and security challenges
- •Sub-registries can layer curation, safety checks, and organization-specific policies
- 20:34 – 23:01
Criticisms: security risks from tool ecosystems (prompt injection, data exfiltration)
They tackle a major criticism: MCP-enabled tool calling can expand the attack surface when tools are contributed by unknown sources. David argues the risk is not “the protocol itself” but the broader tool-ingestion model, requiring safeguards from model providers and app developers (with protocol hints like read/write distinctions).
- •Tool ecosystems enable prompt injection and malicious tool descriptions
- •Risk includes data exfiltration and unsafe actions via tool calls
- •Mitigations span protocol signals (e.g., read-only vs write tools) and model/app controls
- •Community review can help surface vulnerabilities, but balance is needed vs over-restriction
- 23:01 – 26:02
Criticisms: context bloat and how smarter clients reduce tool overhead
Another critique is “context bloat,” where clients dump long tool lists and tool-call traces into the model context window, wasting tokens. David points to improved patterns—tool search and programmatic tool calling—to load fewer tools and avoid logging intermediate values into context.
- •Many clients naively load all tools into the context window
- •Large tool inventories (and unused tools) inflate prompts and reduce capacity
- •Tool search helps models discover tools on demand rather than upfront
- •Programmatic tool calling reduces context pollution from intermediate tool results
- 26:02 – 28:21
Further concerns and lessons learned: CLI vs MCP, statefulness, and local-to-remote evolution
David addresses additional critiques: in some workflows CLI tools may be better than MCP; MCP is also inherently stateful, which can complicate scaling. He reflects on a key design regret—starting with local-only servers—and notes ongoing work to better support remote scenarios and scalable state handling.
- •MCP isn’t one-size-fits-all; CLI can be superior in some environments
- •Stateful sessions enable agentic behavior but raise scaling challenges
- •Active work with industry experts aims to improve statefulness/scaling balance
- •Early design favored local servers; remote-first design would have reduced awkwardness
- 28:21 – 30:57
What’s next: community growth, long-running Tasks, and richer MCP Apps UI
Looking ahead, David highlights community expansion (events, more clients/servers) as a key benefit of Linux Foundation support. On the protocol side, he’s excited about Tasks for long-running operations and agent-to-agent workflows, plus MCP Apps efforts enabling richer UIs inside chat/desktop clients (e.g., seat selection for ticket booking).
- •Linux Foundation can accelerate community building and ecosystem participation
- •Protocol roadmap includes better scaling approaches and refined state handling
- •Tasks enable long-running operations and deeper agentic workflows
- •MCP Apps aims to deliver richer interactive UI components through MCP
- 30:57 – 35:31
What people build with MCP and practical advice: make MCP invisible to end users
David shares favorite builds—from connecting a physical synthesizer to generating sound patches—to enterprise productivity deployments. His guidance: non-developers ideally never need to hear “MCP,” while developers should build, prioritize user experience, use smarter tool patterns, and engage with the community to improve the protocol.
- •Creative builds: hardware integrations like synthesizers; practical builds: enterprise tooling
- •Future value: UI-rich interactions for complex workflows (calendars, bookings, selection tasks)
- •For end users, MCP should be seamless and hidden behind “the model just works”
- •For developers: build clients/servers, use tool search/programmatic tool use, join community discussions
