Overview

• MCP (Model Context Protocol) functions as the "USB-C port of AI applications," enabling two-way integration between AI tools and platforms through three core primitives: tools (function calling), resources (contextual data), and prompts (user-initiated text).

• The protocol was designed with an AI-centric approach that challenges traditional API design, preferring to pass raw data directly to LLMs rather than pre-formatting it, while maintaining a developer focus that prevents application commoditization.

• While initially developed by Justin and David at Anthropic in July 2024, MCP has evolved into a community-driven project with contributions from multiple companies including Microsoft, JetBrains, and Pydantic, with governance focused on practical contributions.

• MCP enables composable AI systems where servers can also be clients, creating interconnected application graphs while maintaining client-side control over interactions, with specialized servers already emerging for memory management, file system access, and sequential thinking.

• The ecosystem is designed to be model-independent and future-focused, supporting potential multi-modal interactions beyond text and deliberately embracing statefulness to anticipate the evolution of AI applications.

Content

MCP Overview and Origin

* MCP (Model Context Protocol) is designed to extend and enhance AI application functionality, serving as the "USB-C port of AI applications." * The protocol focuses on AI applications rather than just models themselves, enabling two-way integration and connectivity between different tools and platforms. * Primarily developed by Justin and David at Anthropic around July 2024, not as part of a broader corporate strategy. * Justin had recently joined Anthropic, and his background in developer tooling was a key motivator. * The project originated from frustration with existing development tools and integration limitations.

Development Timeline and Process

* The project began with David pitching an initial idea to Justin, who quickly became excited. * Official announcement date was November 25th, though development started months earlier. * First few months involved laying groundwork for the communication protocol, which was initially "unrewarding." * Development responsibilities were divided: * David focused on proof-of-concept in an IDE * Justin handled the "heavy lifting" for initial integrations * An internal hackathon about a month before release generated excitement, with someone creating an MCP server that could control a 3D printer. * The first MCP IDE implementation was in Zed editor, available about 1.5 months before official release. * The project was initially named differently and developed openly as an open-source project.

Design Philosophy and Inspiration

* MCP was heavily inspired by Language Server Protocol (LSP), but with key differences. * The team deliberately chose to be "boring" about core infrastructure (like JSON-RPC). * Design focused on how features manifest rather than deep semantic differences. * The protocol aimed to be "presentation focused" in design. * Initial implementation supported three languages: TypeScript, Python, and Rust. * The team developed SDKs and client/server implementations while working on making local subprocess launching robust. * The project addressed the "M times N" problem of connecting multiple systems, a common infrastructure engineering challenge.

Core Primitives and Design Goals

* MCP includes three core primitives designed from an application developer's perspective: * Tools (function calling) * Resources (contextual data) * Prompts (user-initiated text/messages) * Key insights about these primitives: * Tool calling is necessary but insufficient for rich application experiences * Resources can be dynamically or manually added to model context * Prompts allow for user-driven macro-like text insertions * Developer-centric design goals include: * Preventing application commoditization * Enabling unique user experiences * Providing flexibility in how integrations are implemented * Current observations show tool calling dominates most implementations (95%+), with underutilized potential in resources and prompts.

Tools vs. Resources

* Tools are initiated by the model at its discretion (e.g., running SQL queries). * Resources are more flexible and: * Uniquely identified by a URI * Can be used for listing/accessing entities * Potentially useful for schemas, prompt libraries, and general-purpose transformations * Current client support for resources is limited. * Potential resource use cases include: * Allowing users to discuss specific database tables * Enabling AI agents to look up relevant schemas * Supporting interactions where users drop in a URI * Zeta used resources to populate a prompt library from an MCP server, requiring agreement on URI format and underlying data structure. * IDE attachment menus could naturally be modeled as resources.

AI-Centric Design Approach

* The team prefers passing raw, unstructured data directly to LLMs, trusting AI models to parse and extract relevant information. * Traditional software engineering approaches need to be reimagined for AI interactions. * There's a need to "unlearn" decades of previous API design practices. * AI's rapid advancement means focusing on external data interaction capabilities. * Future AI productivity depends on safely connecting models to external data sources. * The team recommends avoiding pre-formatting data and letting AI models handle formatting.

MCP vs. OpenAPI

* OpenAPI specifications are considered too granular for LLM interactions. * MCP is more focused on AI-specific concepts and application developer perspectives. * The speakers view MCP and OpenAPI as complementary, not competing technologies. * MCP is deliberately designed to be more stateful, anticipating future AI interactions will become increasingly stateful. * The protocol supports potential multi-modal interactions beyond text (video, audio). * Community has already created translation bridges between MCP and OpenAPI.

Getting Started with MCP

* Recommendations for getting started: * Choose a programming language and SDK * Build a simple server quickly (around 30 minutes) * Focus on creating a tool that personally interests you * Start with a basic description and experiment * Don't overthink initial implementation * AI can be used effectively to help with coding, including: * Dropping SDK code into an LLM's context window * Generating server code with minimal manual intervention * Creating servers with relatively few lines of code

MCP Server Development Approaches

* Two primary directions for MCP servers: 1. API adapters/connectors 2. Novel experiences with unique functionalities * Examples of innovative MCP servers: * Memory server: Allows LLMs to remember conversations * Sequential thinking server: Improves model reasoning capabilities * Many initial MCP servers will likely be API wrappers, with increasing potential for more complex, creative server experiences. * Improvements in client support will enable richer server functionalities.

Composability and Interaction

* MCP allows for building complex systems where servers can also be clients. * Enables creation of recursive, interconnected application graphs (DAGs). * Aims to be model-independent, allowing flexibility in LLM interactions. * Servers can request client-side LLM completions without needing to provide their own API keys. * Potential for chaining MCP servers to create rich, interconnected experiences. * Current limitations exist in SDK support for complex server/client interactions.

Practical Considerations for Tool Management

* No universal "maximum" number of servers exists; it depends on: * Model capabilities * Tool naming and description clarity * Potential filtering strategies * Hundreds of tools is currently a "safe bet" for models like Claude. * Potential filtering approaches include: * Client-side tool filtering * Using smaller LLM to filter relevant tools * Using an MCP server as a proxy to filter other servers * Tool overlap can increase model confusion. * Clear, unique tool descriptions help reduce errors. * Client applications/users should ultimately control the entire MCP interaction.

Server Ecosystem and Trust

* Client applications should have full control in the MCP paradigm. * The team anticipates multiple servers for similar domains (e.g., 25 GitHub servers, 25 Postgres servers). * They expect the ecosystem to naturally converge on widely-used implementations over time. * Company-specific MCPs (like Cloudflare) likely to become canonical for their products. * Open question: How to determine which MCP servers are safe and trustworthy. * Current trust mechanisms (download counts, reviews) are potentially brittle. * Suggested alternative: Use tools like MCP Inspector to examine server traffic.

Notable Special MCP Servers

* Memory Server: * Approximately 300 lines of code * Provides a simple memory implementation * Originated from an internal Anthropic hackathon * Allows easier prototyping and extension of Claude's capabilities * File System Server: * Highlights an "edit file" capability * Enables interaction between cloud and local machines * Emerged from direct user frustration and project needs * Considered a spiritual origin point of the protocol * Sequential Thinking Server: * Provides branching and expanded writing capabilities * Represents one of multiple strategies to make LLMs more thoughtful * Distinct from Anthropic's recent "think tool"

Technical Design Decisions

* The MCP team extensively discussed the trade-offs between stateful and stateless server architectures. * They believe the future of AI applications leans towards statefulness. * Developed a "streamable HTTP transport" that balances stateful capabilities with operational simplicity. * Working on authorization specifications using OAuth 2.1. * Current focus is on user-to-server authorization. * The protocol design philosophy aims to be minimal and solve practical problems. * The team prioritizes conservative design to avoid breaking backwards compatibility.

Governance and Community

* The project values practical contributions and work more than mere opinions. * Maintainers must manage high volumes of conversations and notifications. * Sometimes leaders must make difficult decisions that may not please everyone. * Open source allows for forking if community members disagree with project direction. * Currently, the project is steered by its creators, with long-term considerations including potential transition to a nonprofit/foundation model. * While initiated by Anthropic, they want the project to be accessible to multiple AI labs and companies. * Current project already involves multiple companies with commit and admin access, including Pydantic, Microsoft (C# SDK), JetBrains (Kotlin), and Spring AI (Java SDK).

Future Wishlist

* The team expressed desire for: * More sampling clients * Clients supporting the full specification * Potential AI integrations in specific domains like: * Game development (e.g., Godot engine) * Automated game playtesting * Content summarization (Reddit threads, game events)