EngineersofAI LogoCoursesBlogResearch LabAI LettersThe LabCode BankInteractive 3DKodrEarnestJobs
Skip to main content

What is MCP?

It is October 2024. A senior platform engineer at a software company is staring at a Jira board with 23 open tickets. Every ticket is a variant of the same request: "Add X to the AI assistant." Add Slack. Add GitHub. Add the internal wiki. Add the customer database. Add Datadog. Add PagerDuty. Add the deployment system. Each integration takes a week: write the tool definition in JSON schema, write the wrapper function that calls the API, handle authentication, handle pagination, handle errors, test it in the prompt, debug the edge cases, deploy it. Then do it again for the next system. And the next.

She does the mental math. Twenty-three integrations at a week each is six months of work. And they are not one-and-done - each integration needs to be maintained as the underlying APIs change, as authentication tokens rotate, as rate limits shift. The AI assistant is becoming a maintenance burden that grows linearly with every new tool added. Meanwhile, the competitors are moving faster. The board is asking why the AI assistant is not integrated with everything yet. The engineers are asking why they spend all their time writing JSON schemas and HTTP wrappers instead of building features.

What she does not know is that two thousand miles away, engineers at Anthropic are looking at the same problem from the other side. They are seeing it across hundreds of customer deployments. Every organization that builds anything serious with Claude ends up writing the same category of glue code, solving the same authentication problems, debugging the same edge cases. The ecosystem is fragmenting: each company has their own bespoke integration layer, incompatible with everyone else's. A tool built for Company A's Claude deployment cannot be reused by Company B without being completely rewritten.

The recognition arrives in the same form it always does: this is an infrastructure problem masquerading as an application problem. The solution is not to write better glue code. The solution is to standardize the interface so that the glue code only needs to be written once, by the tool provider, and can be reused by every AI application that speaks the protocol.

On November 25, 2024, Anthropic published the specification for the Model Context Protocol. It was released as an open standard - not proprietary to Anthropic, not requiring Claude. It is a protocol that any AI application can implement as a client and any tool provider can implement as a server. The first day of adoption included Claude Desktop, and within weeks, VS Code, Cursor, and Zed had added support. The ecosystem that had been fragmented began converging on a common standard.

Why This Exists​

The Integration Problem Before MCP​

Before MCP, connecting an AI application to tools worked like this: the application developer studied the target system's API, wrote a tool definition in JSON schema describing what the tool does and what parameters it accepts, wrote a wrapper function that translated the model's tool call into an actual API request, handled authentication (usually API keys stored in environment variables), handled errors and retried on transient failures, and tested the whole thing in context. Then they did it again for the next tool.

This approach had a fundamental structural problem that engineers recognized quickly but could not easily solve: it was the N×M problem.

The N×M Problem​

Suppose you have N AI applications (Claude Desktop, your internal chatbot, your IDE plugin, your CI/CD assistant, your customer support bot) and M tools they need to access (GitHub, Slack, Postgres, Google Drive, Jira, Datadog, your internal wiki, your deployment system).

In the world before MCP, each application needed its own integration with each tool. That is N×M integrations total.

Before MCP: N×M custom integrations

              GitHub  Slack  Postgres  Google Drive  Jira  ...
Claude Desk.    ✗       ✗       ✗          ✗           ✗
IDE Plugin      ✗       ✗       ✗          ✗           ✗
Support Bot     ✗       ✗       ✗          ✗           ✗
CI/CD Bot       ✗       ✗       ✗          ✗           ✗
...             ✗       ✗       ✗          ✗           ✗

Total integrations: N × M = 5 × 5 = 25
(And each one is different, incompatible with the others)

With N=20 applications and M=50 tools, that is 1,000 custom integrations. Each one:

  • Takes engineering time to build
  • Requires ongoing maintenance as APIs change
  • Uses a different format, authentication pattern, and error handling approach
  • Cannot be shared or reused between applications

This is not a hypothetical. This is the state of enterprise AI deployment in 2023–2024 for any serious organization.

MCP's Solution: N+M​

MCP solves this by defining a standard protocol that sits between AI applications and tools:

After MCP: N+M implementations

AI Applications implement MCP client once:
  Claude Desktop → MCP client ✓
  IDE Plugin     → MCP client ✓
  Support Bot    → MCP client ✓

Tool providers implement MCP server once:
  GitHub   → MCP server ✓
  Slack    → MCP server ✓
  Postgres → MCP server ✓

Any client connects to any server.
Total implementations: N + M = 3 + 3 = 6
(And every combination works automatically)

The protocol is the interface. Implement it once on each side, and every combination works. The GitHub MCP server works with Claude Desktop, with your IDE plugin, with your support bot - without any additional integration work.

:::tip 🎮 Interactive Playground Visualize this concept: Try the MCP Architecture demo on the EngineersOfAI Playground - no code required. :::

Historical Context​

The Infrastructure Layer Problem​

The N×M problem is not new to software engineering. It appears whenever you have multiple producers and multiple consumers of a capability that lacks a standard interface.

The USB standard (1996) solved the N×M problem for hardware peripherals. Before USB, every peripheral - keyboard, mouse, printer, storage device - needed a different port and a different driver. Laptop manufacturers had to include ports for every combination. With USB, peripheral manufacturers implement one interface, and every computer supports it.

POSIX (1988) solved the N×M problem for operating systems. Before POSIX, software written for one Unix variant would not compile on another. With POSIX, software written to the standard runs on any compliant system.

HTTP (1991) solved the N×M problem for web communication. Before HTTP, different services used different protocols, different formats, different conventions. HTTP gave the web a common language.

MCP is the same pattern applied to AI-tool integration. The protocol defines the interface; tool providers implement the server; AI applications implement the client; any client talks to any server.

Why Anthropic in November 2024?​

Several conditions converged in late 2024:

Model capability threshold. By late 2024, frontier models had reached a capability level where tool use was reliable enough to build production systems on. The bottleneck was no longer the model - it was the integration layer.

Enterprise adoption at scale. Organizations deploying Claude at scale were all independently discovering the same integration fragmentation problem. The patterns had been clear for months; the time to standardize was now.

Open standard commitment. Anthropic released MCP as an open standard, not a proprietary API. The specification is on GitHub, the SDK implementations are open source (Python and TypeScript on release day), and any AI system - including those from competitors - can implement it. This was a deliberate choice to maximize ecosystem adoption over short-term competitive advantage.

First-mover timing. In infrastructure, the first good-enough standard often wins because the switching cost of changing protocol later is enormous. Anthropic moved early.

Real Adoption Timeline​

  • November 25, 2024: MCP specification published, Claude Desktop 1.0 ships with MCP client support. Official Anthropic MCP servers released: filesystem, GitHub, Google Drive, Slack, Postgres, Puppeteer.
  • December 2024: VS Code extension with MCP support. First wave of community MCP servers appear on GitHub.
  • January 2025: Cursor and Zed announce native MCP support. MCP server count exceeds 500 on community registries.
  • Early 2025: Enterprise adoption accelerates. Major SaaS vendors begin releasing official MCP servers. OpenAI announces support for MCP in their platform.

The USB-C Analogy​

The best way to understand MCP's role is through the USB-C analogy that Anthropic used in the protocol announcement.

Before USB-C, every laptop had a different charger. MacBooks used MagSafe. ThinkPads used barrel connectors. Different Dell models used different barrel connectors with different voltages. If you borrowed a colleague's charger, it probably did not fit. Charger compatibility was a solved problem you had to solve repeatedly for every device combination.

USB-C is a standard that says: this is the connector shape, this is how power negotiation works, this is how data transfer works, this is how video output works. Any charger that implements USB-C charges any laptop that implements USB-C. Any monitor with USB-C accepts any laptop with USB-C. The problem is solved once at the protocol level, not once per combination.

MCP is USB-C for AI tools. Any AI application that implements the MCP client protocol can use any tool that implements the MCP server protocol. The integration is solved once per tool, not once per tool-application combination.

How MCP Relates to Function Calling​

Function calling (tool use) is the mechanism by which a language model can request that the application execute a specific function with specific parameters. It is built into the model's inference process: the model produces a structured output that says "call this function with these arguments," the application executes it and returns the result, the model continues reasoning.

MCP sits at a different layer. Function calling defines the interface between the model and the application. MCP defines the interface between the application and the tools.

You can use function calling without MCP - the application handles tool execution itself, inline, without a separate server process. This is appropriate for simple single-application deployments where you do not need the reusability that MCP provides.

You can use MCP without thinking about function calling at all - MCP is an infrastructure protocol that abstracts away the model-to-tool communication. The MCP client translates model tool calls into MCP protocol messages.

MCP and function calling are complementary, not competing. Function calling is the model-level primitive. MCP is the infrastructure-level standard. The full stack uses both.

The Three Primitives​

MCP defines exactly three types of things a server can expose. Understanding these three primitives is fundamental to understanding what MCP is and what you can build with it.

Tools​

Tools are callable functions. A tool has a name, a description, an input schema (JSON Schema), and produces a result when called. When the model decides to use a tool, the MCP client sends a tools/call request to the MCP server, which executes the function and returns the result.

Tools are the MCP equivalent of function calling definitions - but they live on the server, not in the application. The same tool can be used by any MCP client without the client knowing the implementation details.

{
  "name": "search_github_issues",
  "description": "Search GitHub issues in a repository. Returns matching issues with title, number, state, and URL.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "repo": {"type": "string", "description": "Repository in owner/name format"},
      "query": {"type": "string", "description": "Search query"},
      "state": {"type": "string", "enum": ["open", "closed", "all"], "default": "open"}
    },
    "required": ["repo", "query"]
  }
}

Resources​

Resources are readable data sources. A resource has a URI, a name, a MIME type, and can be read to return its contents. Resources are not callable - they do not take parameters. They are data that the model can read, like files, database records, or API responses.

Resources are the MCP equivalent of the document retrieval step in a RAG pipeline - but standardized, discoverable, and accessible through a protocol rather than bespoke retrieval code.

{
  "uri": "github://repos/anthropics/anthropic-sdk-python/README.md",
  "name": "README.md",
  "mimeType": "text/markdown",
  "description": "Main README for the anthropic-sdk-python repository"
}

Prompts​

Prompts are reusable prompt templates with arguments. A prompt has a name, a description, an argument list, and produces rendered message content when called with arguments. Prompts let server developers define best-practice prompts for using their tools and expose them to any MCP client.

This is a less commonly used primitive in early deployments but powerful for organizations that want to standardize how AI systems interact with their tools.

{
  "name": "analyze_pr",
  "description": "Analyze a pull request for code quality, security issues, and test coverage",
  "arguments": [
    {"name": "repo", "description": "Repository in owner/name format", "required": true},
    {"name": "pr_number", "description": "Pull request number", "required": true},
    {"name": "focus", "description": "Specific aspect to focus on", "required": false}
  ]
}

Real Adoption: Who Uses MCP​

By early 2025, MCP had been adopted by:

AI Applications (MCP Clients):

  • Claude Desktop - Anthropic's desktop application for Claude, the reference MCP client implementation
  • VS Code - Microsoft's IDE, with MCP support allowing AI assistants to access workspace tools
  • Cursor - AI-first code editor with native MCP support for tool integrations
  • Zed - High-performance code editor with MCP integration for AI features
  • Continue - Open-source IDE extension with MCP client support
  • Cline (formerly Claude Dev) - AI coding assistant with full MCP support

Tool Servers (MCP Servers):

  • Official Anthropic: filesystem, GitHub, Google Drive, Slack, Postgres, Puppeteer, Brave Search
  • Community: AWS, Azure, Jira, Notion, Linear, Stripe, Twilio, and hundreds more
  • Enterprise: SAP, Salesforce, ServiceNow (in varying stages of adoption)

The adoption curve is following the pattern of other successful infrastructure standards: early adopters in the developer tools space, followed by enterprise and SaaS adoption as the standard matures.

Before/After: A Concrete Example​

Consider the task of connecting three AI applications to GitHub.

Before MCP:

Claude Desktop team:
  - Writes GitHub tool definitions (4 tools: list_repos, get_pr, create_issue, search_code)
  - Writes Python wrapper functions for each tool
  - Handles GitHub personal access token auth
  - Handles rate limiting and pagination
  - Ships in Claude Desktop codebase

VS Code Copilot team:
  - Writes GitHub tool definitions (4 tools, different schema format)
  - Writes TypeScript wrapper functions for each tool
  - Handles GitHub OAuth token auth (different from PAT)
  - Handles rate limiting and pagination
  - Ships in VS Code extension codebase

Cursor team:
  - Writes GitHub tool definitions (4 tools, yet another schema)
  - Writes wrapper functions
  - Handles auth, rate limiting, pagination
  - Ships in Cursor codebase

Total work: 3 teams × 4 tools × integration work = 12 integration implementations
Reuse: zero. Cannot share code between teams.

After MCP:

GitHub team (or Anthropic):
  - Writes one MCP server with 4 tools
  - Handles auth, rate limiting, pagination once
  - Ships as open-source MCP server

Claude Desktop: connects to GitHub MCP server
VS Code: connects to GitHub MCP server
Cursor: connects to GitHub MCP server

Total work: 1 MCP server implementation
Reuse: any MCP client connects to any MCP server

This is the N×M to N+M reduction in practice.

What MCP Does Not Do​

Understanding the boundaries of MCP prevents misuse and misconfigured expectations.

MCP does not replace the model. The model still needs to reason about which tools to call and how to use their outputs. MCP provides better tools, not better reasoning.

MCP does not eliminate the need for prompt engineering. Tool descriptions in MCP servers must be carefully written - the model uses them to decide which tool to call. Poorly written descriptions lead to incorrect tool use.

MCP does not provide built-in authentication. The protocol defines how to pass authentication information, but the server is responsible for implementing auth. Security is not automatic.

MCP does not guarantee tool quality. A community MCP server might be badly implemented, insecure, or unmaintained. Evaluating server quality before use is your responsibility.

MCP does not handle model selection. Which model to use, how to configure it, what system prompt to use - all of this is handled by the AI application, not by MCP.

Production Engineering Notes​

Designing Tool Descriptions​

The single most impactful factor in MCP tool quality is the quality of tool descriptions. The model reads these descriptions to decide which tool to call and how to use it. Vague descriptions lead to incorrect tool use; precise descriptions lead to reliable tool use.

Good description: "Search GitHub issues in a repository. Returns a list of matching issues with title, issue number, state (open/closed), labels, assignee, and URL. Use this when you need to find existing issues related to a bug or feature."

Bad description: "Search GitHub." - too vague; model cannot determine what parameters to provide or what the tool returns.

MCP Server Versioning​

MCP servers should follow semantic versioning. Breaking changes in the tool API (parameter renames, type changes, removed tools) require a major version bump. The initialization handshake includes a protocol version negotiation - use it to gracefully handle version mismatches.

Local vs. Remote Servers​

stdio transport (local servers) is simpler to set up and inherently more secure - the server runs in a subprocess on the same machine, with the same file system permissions as the user. Use stdio for development and for tools that access local resources (filesystem, local databases).

HTTP+SSE transport (remote servers) is required for multi-user deployments, cloud-hosted tools, and tools that need to run on different machines from the AI application. Use HTTP+SSE for production deployments of shared tools.

:::warning Tool Description Quality Is a Security and Reliability Issue A tool with a description that says "deletes all files in the given directory" will be used correctly. A tool with a description that says "cleanup utility" might be called in contexts where deletion is not intended. Write descriptions as if they are user-facing documentation - because from the model's perspective, they are. :::

Interview Q&A​

Q1: What problem does MCP solve and why was it needed in late 2024?

MCP solves the N×M integration problem in AI tool use. Before MCP, connecting N AI applications to M tools required N×M custom integrations - each application had to write its own tool definitions, wrapper functions, authentication handling, and error handling for each tool. With N=10 applications and M=30 tools, that is 300 custom integrations, each needing ongoing maintenance. MCP introduces a standard protocol: tool providers implement a server once, AI applications implement a client once, and any client connects to any server. This reduces the integration count from N×M to N+M. The timing in late 2024 reflected that models had reached the capability threshold where tool use was reliable enough for production, enterprise adoption was scaling past what bespoke integrations could support, and Anthropic had enough insight from production deployments to design a practical protocol.

Q2: What are the three MCP primitives and when would you use each?

MCP exposes three types of capabilities. Tools are callable functions - you use them when the model needs to take an action or retrieve data that requires parameters and computation, like searching GitHub, querying a database, or sending a message. Resources are readable data sources identified by URI - you use them when the model needs to read relatively static data, like the contents of a file or a configuration record, without needing to parameterize the request. Prompts are reusable prompt templates with named arguments - you use them when you want to standardize how AI systems interact with your tools, encoding best-practice prompts that any MCP client can use. In practice, most MCP servers start with tools only, add resources for data that the model needs to read directly, and add prompts for common complex workflows.

Q3: How does MCP differ from function calling?

Function calling is the model-level interface - it defines how the language model communicates "call this function with these arguments" to the application. It operates between the model and the application. MCP is the infrastructure-level interface - it defines how the application communicates with external tool servers. It operates between the application and the tools. You can use function calling without MCP (the application handles tool execution itself). You can benefit from MCP without thinking about function calling (the MCP client handles that translation). In a full stack, function calling and MCP are complementary layers: the model uses function calling to request tool use, the application translates that into MCP protocol calls, the MCP server executes and returns results, the application feeds results back to the model.

Q4: Why did Anthropic release MCP as an open standard rather than a proprietary API?

Infrastructure standards succeed by maximizing adoption, not by maximizing short-term competitive advantage. A proprietary MCP would have limited the ecosystem to Claude deployments. An open standard means any AI application - including those using GPT-4, Gemini, or open-source models - can become an MCP client. This maximizes the pool of tool providers building MCP servers, which makes the standard more valuable for Claude users. It also reflects a genuine insight: the value in the ecosystem is in the model capabilities, not in the protocol. Owning the protocol while the ecosystem fragments around incompatible alternatives would have been worse for everyone, including Anthropic.

Q5: How would you evaluate whether an MCP server is safe to use in production?

Evaluating an MCP server before production use requires four checks. First, the transport and authentication: does the server use TLS for HTTP transport? How are credentials managed - environment variables, OAuth, or hardcoded in config? Second, the tool descriptions: are they precise enough that the model will call them correctly? Are side-effectful tools (those that write, delete, or send) clearly distinguished from read-only tools? Third, the implementation quality: is the server open source? When was it last updated? Does it handle errors gracefully, or will an API timeout silently corrupt the model's context? Fourth, the permission scope: does the server request only the permissions it needs? A GitHub MCP server that requests write access to all repositories when you only need read access to one is a red flag. For production deployments, always use official servers (Anthropic's or well-known vendors) when available, and review community servers thoroughly before deployment.

Using MCP with Claude: Quick Start​

Before diving into building MCP servers (covered in subsequent lessons), here is a minimal example of what connecting Claude to an MCP server looks like from the client side. The anthropic SDK handles the MCP client protocol - you provide the server configuration and the SDK manages the connection lifecycle.

import anthropic

client = anthropic.Anthropic()

# Connect to a locally running MCP server via stdio
# The server is a subprocess started by the SDK
response = client.beta.messages.create(
    model="claude-opus-4-5",
    max_tokens=4096,
    tools=[
        {
            "type": "computer_20241022",
            "name": "computer",
            "display_width_px": 1024,
            "display_height_px": 768,
        }
    ],
    messages=[
        {
            "role": "user",
            "content": "Search GitHub for open issues in the anthropic-sdk-python repository related to streaming."
        }
    ],
    betas=["computer-use-2024-10-22"]
)

For production Claude Desktop usage, MCP servers are configured in ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<your-token>"
      }
    },
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/yourname/projects"
      ]
    }
  }
}

Once configured, Claude Desktop automatically starts the MCP servers when launched, negotiates capabilities, and makes the tools available to Claude in every conversation. No additional prompt engineering is needed - the server's tool descriptions inform Claude when and how to use each tool.

Summary​

MCP solves the N×M integration problem that had fragmented enterprise AI deployments since 2023. By defining a standard protocol between AI applications (clients) and tools (servers), it reduces custom integrations from N×M to N+M. The three primitives - Tools, Resources, and Prompts - cover the full range of what an AI application needs from external systems. Released by Anthropic as an open standard in November 2024, MCP adoption accelerated through major IDE integrations and enterprise tool providers in 2025.

The next lesson covers the full MCP client-server architecture: the initialization handshake, the transport layers (stdio vs HTTP+SSE), the JSON-RPC 2.0 message format, and the session lifecycle that enables reliable tool use in production.

© 2026 EngineersOfAI. All rights reserved.