Building with MCP and the Claude API: How the Model Context Protocol Connects LLMs to the World

Introduction: a quick briefing from Anthropic 🎬

I’m Alex Albert, and I lead Cloud Relations at Anthropic. Recently I sat down with two colleagues—Michael Cohen from the Claude API team and John Welsh from the Model Context Protocol (MCP) team—to unpack what MCP is, why we built it, and how developers can use it to make Claude (and other models) interact with systems beyond the model’s internal chat history.

This article summarizes that conversation, explains the design philosophy behind MCP, shares practical tips for developers, and highlights interesting MCP servers you can plug into right now. Whether you’re a product engineer building agentic workflows or a developer curious about what “models with arms and legs” looks like, you’ll find concrete guidance and examples here.

What is MCP? 🤖

MCP stands for the Model Context Protocol. At its core it's a standard for providing external context to language models. In a chat, the conversation history is the model’s context. MCP expands that context to include things outside the conversation: web pages, project management systems, code repositories, browsers, home automation devices—anything that can expose an API-like interface to a model.

Think of MCP as a universal connector or an adapter layer. Michael described it as "the universal connector between applications and the model," and that's a useful mental image: instead of hard-coding separate integrations for each model and each app, you expose a consistent set of tools via MCP and let the model (Claude) use them.

Why we built MCP and why we open sourced it 🌐

We built MCP because the need was obvious and recurring: every place we embedded Claude needed the same kinds of external interactions—web search, GitHub access, calendars, home devices. Repeatedly building those connectors for each surface leads to fragmentation and a poor developer and user experience.

So we asked: what if we wrote the connector once, standardized it, and made it available everywhere? The result: "build it once and configure everywhere." That principle guided MCP's design.

We also chose to open source MCP intentionally. John explained (paraphrasing here) that open standards let a wider network of engineers and companies build a shared ecosystem. If every vendor created a bespoke connector for their model, integrations would be an engineering nightmare for customers. By open sourcing MCP, we aimed to create a rising tide that benefits the whole ecosystem—vendors, developers, and users.

How MCP works today: registries, remote support, and real servers ⚙️

MCP started life as an internal protocol but quickly turned into a popular open-source standard. One big turning point was support for remote MCP servers. Early iterations required you to run everything locally, which made onboarding clunky. Remote hosted servers changed that: now vendors and projects can host robust MCP endpoints that users plug into via a single URL.

We now have a central registry of MCP servers that makes discovery trivial. Developers can find official endpoints like GitHub’s MCP at mcp.github.com (as an example) and plug those into Claude or a development environment like Cloud Code without trusting random third-party scripts. The registry model also supports extensibility: organizations can operate their own registries while interoperating with the broader ecosystem.

Standout MCPs: Context7 and Playwright 🔎

Not all MCP servers are the same. Some provide data-centric integrations, and others expose powerful tooling. Two favorites from our conversation were Context7 and a Playwright-based MCP server.

• Context7: LLMs have a knowledge cutoff, and that can be frustrating when you need the latest docs or package information. Context7 crawls and keeps documentation up-to-date (Next.js docs, API docs, etc.) and serves it to the model in an LLM-friendly format like LLMs.text. The effect: Claude can reason over the most current docs without hallucinating outdated instructions.
• Playwright MCP Server: Playwright allows remote browser driving. Plugging a Playwright MCP into Claude gives the model actual browser access: load pages, read HTML/CSS, take screenshots, and interact like a human tester. For web development workflows this enables closed-loop fixes—Claude can change HTML/CSS, reload the page, inspect the results, and iterate until the layout looks right.

Using MCP with the Claude API: developer experience 🧩

If you’re a developer wondering how to start, there are two primary ways to integrate MCP with Claude:

1. Install the MCP SDK and run your own orchestration loop. You manage the calls between model and MCP servers and handle authentication and tooling.
2. Use the native MCP connector feature in the Claude API. This is the simpler option: you provide the remote MCP endpoint (e.g., mcp.github.com) and the necessary authorization, and the API handles the calling loop for you—executing tools and feeding results back to the model.

Michael emphasized how many teams have been able to delete significant amounts of glue code by using the built-in MCP connector: pass a URL and credentials, and the API orchestrates the tool usage for the model.

Prompt engineering and tool design tips ✍️

One of the recurring lessons we discussed is that MCP servers are, fundamentally, prompts. The model reads tool names, descriptions, and parameter definitions as part of its prompt context and uses that information to decide what to call and how.

Practical tips:

• Be precise in tool names and descriptions. A tool called generate_image with a field named "description" will elicit different behavior than a tool that specifies the exact model version, recommended prompt style, and expected outputs. Small changes in wording yield big improvements.
• Include examples in descriptions. Few-shot examples inside the tool description often guide models to produce format-correct, higher-quality calls.
• Consider parameter naming: the model will map its generation to the parameter schema you expose. Make parameters human-friendly and descriptive.

"If you give a tool a description that maybe takes some natural language ... the model is going to make some decisions and generate some text." — Michael Cohen

Managing context, tool bloat, and token budgets 🧠

One of the main practical challenges when connecting many MCP servers is "context pollution." Every additional tool and server you register adds function definitions and descriptions that consume token budget. Overloading a single request with dozens of tools confuses the model and increases cost.

Guidance we recommend:

• Keep MCP servers focused: Prefer one or two well-scoped tools per server instead of 15–20 granular endpoints. That helps the model pick the right action.
• Design higher-level tools: Rather than "get_users", "get_projects", "get_posts", consider a single "get_info" tool that accepts natural-language instructions. The model can use the description to fill in details, reducing the total number of tools.
• Bring only relevant tools to the current conversation: Dynamically attach servers pertinent to the user's current task instead of exposing everything at once.
• Watch token usage: Each tool description costs tokens. Be concise but descriptive; trim historical context that no longer helps the current turn.

There’s no single numeric limit that fits all cases—the “right” number of tools depends on context window size, the distinctness of tools, and your desired behavior. In practice, fewer well-described tools beat many overlapping ones.

Real-world uses: status updates, home automation, and emergent behavior 🏠

John and I shared a few real-world examples where MCP made everyday workflows better.

• Project status generation: I wire up MCP servers to Slack channels, docs, and code repositories, then ask Claude to synthesize recent updates into a status in my preferred format. The result? Much of my status writing becomes automated—Claude pulls from the latest sources and follows my prior examples to generate consistent updates.
• Home automation: John runs MCP servers on his home network to control devices. He can ask, "Did I leave my door unlocked this morning?" and Claude can check the home automation server and act (lock it) if requested.
• Knowledge graph and emergent behavior: We tried a tiny knowledge graph MCP with two tools: create_memory and connect_memory. Hooked to Claude, the model began operating like an investigative conversationalist—asking follow-ups, inferring preferences, and forming associations that felt surprisingly "aware." That's the emergent power of combining multiple MCP servers: your model can chain actions and data sources in ways you didn’t explicitly script.

Emergence is one of the key differentiators between MCP-driven interfaces and rigid, structured APIs. Because MCP tooling is interpreted through natural language prompts, you don’t have to worry about breaking API contracts when you iterate on tool descriptions and behavior. That flexibility accelerates experimentation.

Where MCP is headed: the next 6–12 months and beyond 🚀

What's next for MCP? We see three broad trends:

1. Registry growth and maturity: More vendors will publish official MCP servers and compete on the quality of their tool descriptions and capabilities. When I choose a vendor for log analytics, for example, I might favor the one with a better MCP server because it saves me engineering work.
2. Better tooling and evaluation: Right now MCP server quality is uneven. Expect tooling for testing, benchmarking, and iterating on MCP servers—think of metrics that evaluate how reliably an MCP server helps a model perform tasks.
3. Ubiquity and silent orchestration: Ideally MCP should be invisible to end users. When it works well, you won’t notice MCP under the hood—you’ll just interact with apps that have arms and legs, capable of fetching live facts, taking actions, and composing services on your behalf.

We’re still early in the "servers-as-prompts" era. As more teams publish and refine MCP servers, the ecosystem will move from experimental to production-grade, and developers will begin to evaluate vendors by the quality of their MCP integrations.

Final takeaways and how to get started ✅

Here are the practical next steps if you want to start building with MCP and Claude:

• Learn the spec: Read the MCP docs and the getting-started guides to understand how tools, parameters, and descriptions are modeled.
• Start small: Build a single MCP server with one or two focused tools. Make the descriptions explicit and include examples.
• Use the registry: Try plugging in an existing MCP server (Context7, Playwright, or GitHub’s MCP) to see how the model uses external context.
• Iterate on tool wording: Treat tool descriptions as prompts. Small edits often yield large improvements in behavior.
• Consider the Claude API connector: If you want quick integration, use the Claude API's native MCP connector to avoid writing orchestration code.

MCP is an exciting lever for making models useful in the real world. It shifts integration work away from brittle point-to-point adapters and toward a shared, prompt-driven ecosystem. As more registries and high-quality servers appear, expect faster build cycles, less glue code, and more creative emergent behaviors that help people get things done.

If you're ready to experiment: check out the Model Context Protocol docs, explore the registry, and try hooking a server into a Claude-powered surface. You might be surprised how quickly your model gains "arms and legs." — Alex Albert (Anthropic)