Model Context Protocol (MCP): Building Universal Connectivity for LLMs in Production
anthropic · Tech · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)
Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.
Problem
Domain: Production LLM tool connectivity and MCP operations
Production Claude applications needed a reusable way to connect models to external context, tools, services, documentation, browsers, project systems, and user environments without rebuilding the same integration logic for every application.
Constraints:
- Conversation history alone is insufficient when Claude must access external systems or act on a user's behalf.
- Before MCP standardization, teams repeatedly reimplemented web search and other capabilities across Claude Code, claude.ai, and other services.
- Early local MCP setup required users to install and trust code from arbitrary developers on their own machines.
- Every MCP server and tool definition consumes context tokens and can confuse the model when tools overlap.
- MCP server definitions behave like prompts, so names, descriptions, and parameters directly affect model behavior.
Architecture
Anthropic open-sourced MCP as a universal protocol for connecting Claude and other LLM applications to external context and actions. The production architecture evolved from local MCP servers toward remote hosted endpoints, a central registry, and native MCP connector support in the Claude API. Developers can specify remote MCP endpoint URLs and authorization information, while Anthropic handles the server-side tool execution loop. The ecosystem includes official servers such as GitHub, documentation servers such as Context7, browser-control servers such as Playwright, home automation servers, and knowledge-graph memory servers. Production guidance centers on prompt-quality tool descriptions, selective context/tool inclusion, smaller higher-level tool surfaces, and evaluation of MCP server behavior.
Diagram confidence: reconstructed (reconstructed from prose).
flowchart LR App["Claude application"] --> Connector["MCP connector"] API["Claude API"] --> Connector Connector --> Remote["Remote MCP servers"] App --> Local["Local MCP servers"] Remote --> Registry["MCP registry"] Remote --> External["External services"] Local --> External Remote --> Context7["Context7 documentation server"] Local --> Playwright["Playwright browser server"] Connector --> Model["Claude model"] App --> Model
Components
| Component | Role | Interacts with |
|---|---|---|
Claude application |
Claude Code, claude.ai, or another AI application that consumes MCP servers and coordinates model interaction. | MCP connector, Claude model, Remote MCP servers, Local MCP servers |
Claude API |
API surface that can accept MCP endpoint URLs and authorization information directly. | MCP connector, Claude model |
MCP connector |
Native connector feature that handles MCP tool execution loops and feeds results back to the model. | Claude application, Claude API, Remote MCP servers, Claude model |
Remote MCP servers |
Hosted endpoints such as GitHub, Asana, Context7, or vendor-provided services. | MCP connector, MCP registry, External services |
Local MCP servers |
User-run servers on a local machine or home network, such as home automation or custom development tools. | Claude application, External services |
MCP registry |
Central and extensible registry of approved MCP servers and metadata. | Remote MCP servers |
Claude model |
LLM that reads tool definitions, chooses tools, processes external results, and composes actions. | Claude application, Claude API, MCP connector |
Context7 documentation server |
MCP server that pulls current docs from project and API documentation so Claude can use fresh information. | Remote MCP servers, External services |
Playwright browser server |
MCP server that lets Claude load webpages, click around, take screenshots, and inspect rendered layouts. | Local MCP servers, External services |
External services |
Slack, docs, codebases, GitHub, Asana, websites, browsers, home hardware, and other systems exposed through MCP. | Remote MCP servers, Local MCP servers |
Data flow
An application or API request configures MCP endpoints such as GitHub, Context7, Playwright, Slack, docs, codebase, or home-automation servers. The MCP server definitions and tool descriptions are inserted into Claude's prompt context. Claude chooses relevant tools, sends calls through the MCP connector or developer-managed loop, receives results, and continues reasoning or acting. For browser and coding workflows, Claude can modify files, reload the page, inspect screenshots, and iterate; for status reports, it gathers recent Slack/docs/codebase context and emits formatted updates.
3 supporting quotes
Why this architecture
The team chose an open protocol because every model provider and application otherwise would require separate connectors, creating poor experiences for vendors and users. Remote servers and a registry reduce setup friction and avoid running untrusted local code. Native Claude API connector support removes developer glue code. The protocol still depends on careful prompt-like server definitions and context selection because those definitions are part of the model prompt.
3 supporting quotes
Models used: Claude · large language models · diffusion image generation model · Claude Code
Scale
- The discussion happened almost a year after MCP was first announced.“It's been I guess almost a year, a little under a year since we first announced it.”transcript, stated
- The speakers describe MCP as the fastest-growing open-source protocol in history.“I think it was the fastest-growing open source protocol, in history.”transcript, stated
- The ecosystem includes major hosted servers such as GitHub and Asana.“we've seen massive growth of MCP, GitHub MCP, Asana MCP, a lot of companies are building and deploying these endpoints.”transcript, stated
- The production context limit is bounded by the model context window and every server's function definitions.“If your context window is X tokens, each server is gonna pull in a number of function definitions.”transcript, stated
- The team recommends one or two tools per MCP server where possible rather than 15 or 20.“if you can have one or two tools in your server versus having 15 or 20 tools, it'll help the model a lot.”transcript, stated
Alternatives considered (roads not taken)
Build provider-specific app connectors
Rejected because: Separate Claude, OpenAI, Grok, and Gemini connectors would fragment the ecosystem and create a bad experience for integration providers.
Require each user to run local MCP servers
Rejected because: Local setup was clunky and required users to trust random Node.js installs from connector developers.
Make developers implement every MCP tool loop themselves
Rejected because: The native Claude API connector can execute tools and feed results back to the model, letting developers delete glue code.
Expose many granular API endpoints as tools
Rejected because: For LLMs, fewer higher-level tools can reduce prompt load and help the model select the right capability.
Patterns
tool-use-orchestration (architecture)
MCP gives Claude access to external tools and actions through reusable server endpoints and a connector-managed tool loop.
context-engineering (context)
The team treats server/tool names, descriptions, parameters, and conversation pruning as prompt/context design choices that determine model behavior.
rag-retrieval (retrieval)
Context7 connects Claude to current documentation so development tasks can retrieve up-to-date package and API information beyond the model cutoff.
eval-driven-development (operations)
The speakers argue that MCP server quality should be evaluated and improved, and that vendors may compete on how well their MCP servers help Claude solve real tasks.
agent-memory (memory)
A knowledge-graph MCP server gives Claude create-memory and connect-memory tools so it can build relationship graphs during conversation.
observability-tracing (feedback)
Playwright MCP creates a visual feedback loop where Claude can change page code, reload, screenshot, and judge the rendered result.
Tradeoffs
Open-source MCP as a universal standard.
Chose Open protocol and ecosystem over Anthropic-only Claude app connector.
Rationale: External context access benefits all models and reduces integration burden for vendors who otherwise would implement separate connectors for each provider.
Move from local-only servers to remote hosted endpoints.
Chose Remote hosted MCP servers plus registry over User-managed local processes for every integration.
Rationale: Remote endpoints reduce setup friction and let service providers host official integrations.
Use fewer higher-level MCP tools.
Chose One or two broad intent-oriented tools when possible over Many REST-like granular tools.
Rationale: LLM-oriented tool interfaces can use natural-language parameters and reduce context load and ambiguity.
Use native API connector support for common MCP loops.
Chose Anthropic-managed MCP tool execution in the Claude API over Every developer writing the orchestration loop.
Rationale: The native connector reduces glue code and lets developers specify endpoints and auth rather than managing tool-call back-and-forth themselves.
Gotchas (what bit them)
MCP tool definitions are prompt text, not neutral metadata.
Root cause: Tool names, descriptions, examples, and parameter names are inserted into the model prompt and shape Claude's behavior.
Resolution: Treat MCP server definitions as prompt engineering: use precise names, examples, model-specific guidance, and descriptions that tell Claude how to use the tool.
Stuffing too many MCP servers into a request raises cost and confuses the model.
Root cause: Every server contributes function definitions to the context, and overlapping tools such as Linear and Asana project-status tools create ambiguity.
Resolution: Select MCP servers and tools deterministically for the current task and prune irrelevant conversation history.
Local server installation made security and onboarding worse.
Root cause: Users had to locate community connectors and run untrusted local Node.js installs.
Resolution: Move toward official remote hosted MCP servers, approved registries, and endpoint-based configuration.
MCP's fuzzy composition can produce novel behavior that developers did not explicitly design.
Root cause: When multiple servers are connected, Claude's general reasoning can bridge capabilities across services.
Resolution: Monitor production behavior, evaluate server quality, and constrain available tools to the user's current intent.
Evaluation
The team evaluates MCP integrations through tool description quality, server relevance to current context, context-window cost, model confusion, concrete task success, vendor integration quality, and production feedback from examples such as status generation, browser self-improvement, and documentation retrieval.
Metrics: tool-description quality · number of tools per server · context tokens consumed · model confusion from overlapping tools · status-update success rate · A/B-style or task-specific eval results · vendor MCP server quality · freshness of retrieved documentation
3 supporting quotes
Outcomes
- MCP became a fast-growing open standard for connecting LLM applications to external context and actions.
- Remote MCP support and the central registry reduced setup friction compared with local-only servers.
- Native Claude API connector support let developers remove custom MCP orchestration glue code.
- Production and near-production examples include Claude-generated status reports, GitHub integration, Context7 documentation retrieval, Playwright browser self-improvement loops, and home automation.
This is a protocol/ecosystem case rather than a single application. Its production scale comes from official hosted endpoints, a central registry, native Claude API connector support, and the growing number of vendor and community MCP servers.