Building with MCP and the Claude API

A discussion with Anthropic engineers Alex Albert, John Welsh, and Michael Cohen about the Model Context Protocol (MCP). They cover its origins as an open standard, best practices for tool design and prompt engineering, and the future of the ecosystem where high-quality MCP servers will become a key competitive advantage.

October 9, 2025 5 min read

Building with MCP and the Claude API — source: https://www.youtube.com/watch?v=aZLr962R6Ag

What is the Model Context Protocol (MCP)?

The Model Context Protocol (MCP) is an open standard designed to provide external context to large language models. While a model’s conversational history serves as its immediate context, MCP allows it to access and interact with systems “outside of its box.” It acts as a universal connector, enabling a model like Claude to connect to the internet, interact with a travel agency’s API to book a flight, or access other external data sources and tools. This protocol provides the arms and legs for the model to take actions in the world on a user’s behalf.

The Origin and Value of an Open Standard

MCP originated from an internal need at Anthropic to standardize how models access external capabilities. The team found they were repeatedly re-implementing the same functionalities, such as web search, for different applications like the coding assistant and the main claude.ai interface. The goal was to create a unified protocol to “build it once and configure everywhere,” ensuring the same web search functionality could be used across all services.

The decision to open-source MCP was driven by several factors:

Ecosystem Growth: Open standards foster a wide network of engineers, companies, and individuals who can build a rich ecosystem around the protocol.
Developer Experience: A proprietary connector would create a poor experience for developers and companies (e.g., Asana), forcing them to implement separate, bespoke connectors for every model (Claude, OpenAI, Gemini, etc.).
Universal Benefit: The team recognized that giving models access to external context is a “rising tide that floats all boats,” benefiting the entire AI industry.

This approach was incredibly successful, leading to “stratospheric growth” and making MCP one of the fastest-growing open-source protocols in history. It has since been moved into a proper open-source foundation to ensure its longevity and collaborative development with other providers.

The Evolution of the MCP Ecosystem

The MCP ecosystem has matured significantly since its initial release.

Remote MCP Support: A major step-change was the introduction of first-class support for remote-hosted MCP servers. Initially, users had to run servers themselves, which was a clunky setup process. Remote support allows providers like GitHub or Asana to host their own official MCP endpoints (e.g., mcp.github.com), drastically simplifying the integration process for end-users.
Central Registry: An official, central registry for MCP servers has been established. In keeping with the open-source ethos, the standard also allows other organizations to extend this registry. This makes it easy for developers to discover and securely connect to official MCP servers.
Noteworthy Implementations:
- Context7: This server addresses the knowledge cutoff limitation of LLMs. It pulls the latest documentation from sources like Next.js or API websites, ensuring Claude has access to up-to-date information, which is particularly useful for software developers.
- Playwright: This server allows Claude to interact with a web browser as a user would—clicking, scrolling, and viewing the page. This enables powerful self-improvement loops; for example, Claude can be asked to fix a CSS alignment issue, make code changes, reload the page, and then visually inspect a screenshot of the result to verify the fix or try a different approach.

Developer Best Practices for MCP

Using the Native Claude API Connector

While developers can use the MCP SDK to build their own tool-calling loops, the Claude API now offers a native MCP connector feature. This simplifies the process immensely. Developers can just specify the remote MCP server URLs and provide authorization information, and the API handles the entire execution loop of calling tools and feeding the results back to the model. This has allowed developers to “delete tons of code” by abstracting away the complex back-and-forth orchestration.

MCP as Prompt Engineering

A crucial insight for developers is that MCP servers and tools are fundamentally prompts. The model’s performance is highly sensitive to the language used.

“MCP servers and tools are really at its core prompts… it’s really important to be careful and precise about the language that you use when you’re prompting the model. This extends to everything about defining your MCP server, like defining your tool names appropriately, giving them descriptions.”

For instance, an image generation tool with a generic description will produce generic results. However, if the description is enhanced to specify the underlying diffusion model and the optimal prompting style (e.g., “This tool calls the XXX diffusion model, version Y and should be prompted in this style for best results”), the model will adapt its behavior and generate a much more detailed and effective prompt, leading to superior images.

Managing Context and Tool Design

Avoid Overstuffing: A common anti-pattern is to include too many tools or MCP servers in a single request. This is not only expensive due to increased token count but also confuses the model. For example, providing tools for both Asana and Linear with a similar function like get_project_status creates ambiguity.
Be Deterministic: Developers should be selective, providing only the subset of tools relevant to the current task.
Abstract, Don’t Replicate: MCP tool design differs from traditional API design. Instead of creating a one-to-one mapping with 15 granular API endpoints, it’s often better to design one or two more abstract tools. A single get_info tool that accepts natural language parameters can be more effective, as the LLM can intelligently fill in the details based on the tool’s description. This reduces the number of tools the model has to reason about.

Emergent Behaviors and the Future of MCP

Connecting Claude to MCP servers can lead to surprising “emergent” properties. An early experiment with a simple knowledge graph server (with just create_memory and connect_memory tools) caused Claude to adopt an “investigative journalist mode,” actively asking follow-up questions to build connections between pieces of information. This “fuzziness” and the ability for the model to creatively combine tools (e.g., a Gmail server and a home automation server) to solve novel problems is a core advantage over rigid, traditional APIs.

Looking ahead, the goal is for MCP to become a ubiquitous, invisible layer of the AI stack. The focus in the ecosystem is expected to shift from simply providing an MCP server to competing on its quality. A well-designed, powerful MCP server that enables seamless interaction with a service will become a significant competitive advantage and a key selling point for vendors.