MCP Protocol Primer: Why AI Agents Need a Unified Tool-Calling Standard

In 2025, AI Agent developers face an uncomfortable reality:

You want Claude Desktop to connect to GitHub, Slack, and a Postgres database. What do you do? Write custom integration code for each service — GitHub via REST API, Slack via WebSocket, Postgres via a database driver. Each tool has different authentication, different data formats, different error handling.

Worse, if you switch AI applications (say from Claude Desktop to Cursor), you have to rewrite all the integration code.

This isn't any single developer's oversight. It's systemic fragmentation across the entire AI tool-calling ecosystem.

And MCP (Model Context Protocol) was created precisely to solve this problem.

Understand MCP Instantly Through the LSP Analogy

Before diving into MCP, let's look at a standard you already benefit from: LSP (Language Server Protocol).

From 1980 to around 2015, the code editor world looked like this: every editor had to implement code completion, go-to-definition, and diagnostics for every language — independently. VS Code wrote a Python plugin, Vim wrote one, Sublime wrote another. N editors × M languages = N×M implementations.

In 2016, Microsoft released LSP. The core idea was simple: write one Language Server per language, and every editor connects to it through a unified protocol.

LSP revolutionized the editor ecosystem. Today, the intelligent Python completions you enjoy come from the same Pyright Server — whether you're coding in VS Code, Vim, or Zed.

MCP does the same thing for AI tool calling. With MCP, you write one MCP Server for GitHub, and Claude Desktop, Cursor, Continue, Zed — any AI app with an MCP Client — can plug into it instantly.

The Architecture Triangle: Host → Client → Server

MCP's architecture consists of three roles — understand this triangle, and you understand MCP's entire structure:

Host

The Host is the AI application the end user sees. Think Claude Desktop, Cursor IDE, or a custom chat interface. The Host is responsible for:

• Receiving user input
• Passing context (conversation history, file contents, etc.) to the LLM via the Client
• Displaying the final response to the user

The Host never communicates directly with MCP Servers. All protocol operations go through the embedded Client.

Client (Protocol Client)

The Client is the MCP protocol implementation layer embedded inside the Host. It handles:

• Establishing and maintaining connections to MCP Servers (stdio or HTTP)
• Sending protocol requests — discover available tools (tools/list), read resources (resources/read), fetch prompt templates (prompts/get)
• Forwarding the LLM's tool-call instructions to the Server and returning results to the LLM

The Client is the critical bridge in MCP architecture — it connects the LLM to external tools, translating between both sides.

Server (Tool Provider)

The Server is the program that actually executes tools. An MCP Server exposes a set of capabilities:

• Tools: Functions the LLM can actively invoke (check weather, send messages, query databases)
• Resources: Contextual data the Client can read (file contents, API responses)
• Prompts: Predefined prompt templates (letting users quickly choose common interaction patterns)

A Server can provide all three capability types, or just a subset.

A Minimal Call Flow

Here's one complete MCP invocation chain, described step by step:

User asks in Host: "Find the latest MCP-related GitHub Issues"

  ┌─────────────── Host (Claude Desktop) ───────────────┐
  │                                                      │
  │  ① User input                               ⑧ Display │
  │     ↓                                                ↑ │
  │  ┌──────────────── Client ────────────────────┐     │ │
  │  │                                              │     │ │
  │  │  ② tools/list ────────────────→  MCP Server │     │ │
  │  │     ← [search_issues, create_issue, ...]     │     │ │
  │  │                                              │     │ │
  │  │  ③ LLM sees available tools, decides to call │     │ │
  │  │     search_issues                             │     │ │
  │  │                                              │     │ │
  │  │  ④ tools/call ─────────────────→  MCP Server │     │ │
  │  │     {"name":"search_issues",                  │     │ │
  │  │      "arguments":{"query":"MCP","limit":5}}   │     │ │
  │  │                                              │     │ │
  │  │  ⑤ ← Returns Issue list as JSON                │     │ │
  │  │                                              │     │ │
  │  │  ⑥ LLM receives results, generates response   │     │ │
  │  └──────────────────────────────────────────────┘     │ │
  │                                                      │ │
  └──────────────────────────────────────────────────────┘

Key point: the LLM doesn't know the MCP Server exists, and never communicates with it directly. The LLM only sees tool names, descriptions, and parameter schemas — it decides "which tool to call, with what parameters." The actual protocol communication is handled entirely by the Client.

This layered design is MCP's most elegant feature: model and protocol are decoupled. Swap LLM providers — the Client stays the same, the Server stays the same. Only the model API call in the Host changes.

The Three Core Primitives at a Glance

MCP defines three categories of capabilities, each serving a different invocation scenario:

Why separate these three? Because each scenario has different invocation permissions. Tools are automatically invoked by the LLM — expose them carefully (you don't want the model accidentally deleting files). Resources are read proactively by the application layer — no LLM decision-making needed. Prompts are manually chosen by the user — they're shortcut entry points. This categorization lets MCP Servers precisely control "which role can do what, under what circumstances."

All primitives are transmitted via JSON-RPC 2.0, supporting two transport methods:

• stdio (standard input/output): ideal for local inter-process communication, no network configuration needed
• Streamable HTTP (with SSE streaming): ideal for remote services, supports streaming responses and resumability

MCP vs Native Function Calling: The Key Differences

This is where developers get confused most often. Let's clarify with a side-by-side comparison:

In one sentence: Function calling defines "how the model outputs a tool call" — MCP defines "how tools are managed and connected." The two aren't competing. MCP's Client layer ultimately translates MCP tool descriptions into whatever function-calling format the target model expects. MCP is the higher-level abstraction.

A Concrete Scenario: With vs Without MCP

Imagine you need Claude Desktop to connect to three external tools: GitHub (view Issues), Slack (send messages), and Postgres (query a database).

Without MCP

• GitHub integration: write a full code module handling GitHub REST API authentication, requests, response parsing, error retries
• Slack integration: write another module handling Slack Web API auth, message formatting, file uploads
• Postgres integration: write yet another module handling connection pools, SQL execution, result formatting

Three codebases, three authentication schemes, three error-handling strategies. Want to add a fourth tool (say Jira)? Write another one. And if you switch to Cursor IDE? Rewrite everything.

With MCP

• Launch github-mcp-server (community-built, one command)
• Launch slack-mcp-server (community-built, one command)
• Launch postgres-mcp-server (community-built, one command)

Claude Desktop, as Host, automatically discovers all tools exposed by the three Servers through its built-in Client. The LLM sees a unified tool list and calls them as needed. Adding a fourth tool? Just launch another MCP Server. Switching to Cursor IDE? The three Servers stay the same — Cursor's built-in Client connects directly.

That's the power of a standardized protocol. Same idea as USB unifying peripheral interfaces — you don't write a driver for every mouse.

Who's Behind MCP?

Originator: Anthropic open-sourced MCP in November 2024.

Current Steward: Transferred to the Linux Foundation in 2025, now a formal open-source standards project.

License: Apache 2.0 — fully open, no vendor lock-in.

This is worth emphasizing: MCP is not an Anthropic-proprietary protocol. The Linux Foundation transfer means:

• Open-source community governance — any organization can participate in standards development
• Apache 2.0 license allows commercial use, modification, and redistribution
• A thriving ecosystem of community-built MCP Servers already exists (GitHub, Slack, Postgres, Google Maps, Figma, and more)

If you're worried "does using MCP lock me into Anthropic?" — don't be. MCP is positioned like Kubernetes or Node.js: an open standard with multi-vendor implementations.

Common Misconception: "MCP Is Just Function Calling 2.0"

This is the most frequent misunderstanding. Let me restate it clearly:

Function calling is a model capability. The model says "I understand this tool, I want to invoke it, here are the parameters."

MCP is a protocol-layer standard. It defines "how tools are discovered, how they describe themselves, what a call request looks like, how results come back, what transport channel to use."

An analogy:

• Function calling is like "a person who speaks English" (language ability)
• MCP is like "the international mail format standard" (protocol specification)

A person can speak English (function calling), but if everyone formats letters differently, cross-organization communication is still chaos. MCP establishes a unified "envelope format" — where the sender, recipient, subject, and body each go — so anyone who speaks English can communicate efficiently.

Before You Start Coding: Concepts to Internalize

Before the next article gets hands-on with code, make sure you've absorbed these four concepts:

1. MCP's Architecture Triangle: Host (user interface) → Client (protocol bridge) → Server (tool execution). Three layers, each with a distinct role.
2. The Three Primitives' Distinctions: Tools (model-invoked), Resources (app-read), Prompts (user-chosen). Know who controls what.
3. MCP ≠ Function Calling: MCP is the protocol layer, function calling is a model capability. The MCP Client translates MCP tools into the model's function-calling format.
4. Transport-Agnostic: stdio for local, HTTP+SSE for remote. You don't need to worry about transport details when writing a Server.

If you're not yet comfortable with AI Agents themselves, start here:

• What Is an AI Agent — From Chatbot to Autonomous Agent
• Agent Tool Design — How to Choose the Right Tools for AI Agents
• Write Your First AI Agent — 50 Lines of Code

Series Roadmap

The MCP Protocol Series spans 6 articles, from concept to production:

1. ← You are here: MCP Protocol Primer — concepts, architecture, comparisons
2. Build Your First MCP Server — a weather-query tool in 50 lines of Python
3. Deep Dive: MCP's Three Primitives — Tools/Resources/Prompts hands-on
4. MCP Transport Layer Explained — stdio vs Streamable HTTP, when to use which
5. Advanced MCP — server-initiated LLM sampling, user elicitation, and async tasks
6. MCP in Production — OAuth 2.1, gateway proxies, audit trails, and registry publishing

📖 Next: Build Your First MCP Server — A Weather Query Tool in 50 Lines of Python