The Creators of Model Context Protocol

Alessio and Swix introduce Justin Sparr-Somers and David Soria-Parrer from Anthropic, co-creators of the Model Context Protocol (MCP). Justin explains that MCP enhances AI applications by integrating them into a plugin ecosystem, likening it to a universal connector. David clarifies that MCP targets AI applications rather than just models, addressing a common misconception. The development of MCP stemmed from Justin's frustrations with existing tools lacking integration capabilities, leading to a collaborative effort with David to build the protocol.

Justin highlights an internal hackathon that preceded MCP's official release, where team members created various applications, including an MCP server for a 3D printer. Early implementations of MCP were integrated into the Zed editor, praised for its low latency and effective AI integration. The design of MCP draws inspiration from the Language Server Protocol (LSP), addressing challenges of supporting multiple IDEs and languages. They emphasize the benefits of LSP for language server implementations and apply similar principles to MCP for AI applications.

MCP adopts JSON RPC and focuses on feature manifestation rather than semantics, with significant design work dedicated to defining its primitives and concepts. Initial support for TypeScript, Python, and Rust aimed to create a robust internal ecosystem. The creators diverged from LSP's unique approach to JSON RPC while maintaining its inspirational elements, stressing the importance of innovation in specific areas.

The conversation centers on the challenges developers face with tooling and the need for composability in both remote and local tools. Core primitives identified include tools that can be directly added to the model, function calling for data or context, and user-initiated prompts. Differentiation is crucial to avoid commoditization in the AI application space. The discussion also touches on the potential of resource bits in MCP servers, which could expose documents and databases as resources.

Clarification is provided on the distinction between tools and resources, with tools being model-initiated and resources offering more flexibility. An ideal scenario would see full ecosystem support for resources, allowing users to interact with specific database schemas. The conversation considers existing application features that could be integrated into MCP servers, emphasizing the importance of prompts in AI and the significance of multi-step prompting for effective model performance.

Concerns are raised about server implementations, particularly regarding data return for tool calls. The rapid advancement of AI may create bottlenecks in model interactions with external data sources, emphasizing the importance of safety and control in these interactions. The conversation highlights the need for a higher-level approach compared to OpenAPI specifications, advocating for MCP as a more suitable framework for application developers.

Building MCP servers is acknowledged as a crucial yet under-discussed topic. Developers are encouraged to start with simple, functional servers, focusing on practicality over perfection. The potential for innovative MCP servers, such as those that enhance memory and reasoning capabilities, is also discussed. The future of MCP servers is considered, with possibilities of building on existing APIs or creating new experiences.

The topic of composability arises, with discussions on integrating different MCPs and the recursive property that allows for complex interactions within the MCP ecosystem. The definition of an agent is clarified, emphasizing the distinction between an MCP server acting as a client and a true agent. The conversation highlights the complex relationship between MCP and agents, with trade-offs regarding whether MCP should prioritize AI applications or agents.

Discussion on MCP implementation capacity reveals inquiries about the maximum number of implementations a system can support. Recommendations for the number of MCP servers depend on the model used and the clarity of tool naming and descriptions. User control is emphasized, allowing users to select feature sets based on context while ensuring not all features are visible or active.

Trust and vetting of MCP servers are crucial, with a need for reliable systems to establish reputation and vetting criteria. The conversation also touches on the absence of an official Ruby SDK from Anthropic or OpenAI. Concerns about registries are raised, noting that while they offer features like download counts and reviews, they can be brittle and trust systems may be compromised.

The discussion includes special servers in the official repository, such as memory and sequential thinking servers, which are easier to interact with than traditional APIs. The server development for MCP emerged from frustrations with existing systems, serving as a foundational point for the protocol. Recent updates to MCP include a shift from stateful to stateless servers, utilizing SSE as the launch protocol.

The current draft of the authorization protocol includes user-to-server authorization via OAuth 2.1, aiming to eliminate the reliance on API keys. The need for more granular scopes in authorization is acknowledged, particularly in use cases like email access. There is a desire for more user-driven examples and solutions in the authorization discussion, emphasizing the importance of practical end-to-end user scenarios.

The high volume of conversations surrounding MCP highlights the necessity for scalable structures to manage community engagement effectively. The conversation reassures that MCP is a community-driven effort, with contributions from various companies, including Shopify, Microsoft, and JetBrains. A wrap-up question about desired features for MCP servers or clients leads to discussions about the need for more sampling clients and specific functionalities, such as summarizing Reddit threads or EVE Online events.