Model Context Protocol (MCP) Explained: How AI Tool Calling Works

The Mess MCP Was Built to Fix

Before MCP, every AI platform handled tool calling its own way. OpenAI had Function Calling. Anthropic had Tool Use. Google had something similar but with different parameter shapes. If you wanted a single "query the database" tool to work with both GPT and Claude, you were writing two adapter layers — different field names, different error codes, different ways of threading context through the conversation.

Model Context Protocol (MCP) is Anthropic's answer to that fragmentation. It's an open protocol now backed by most major AI vendors, and its goal is straightforward: standardize how models invoke external tools. The USB-C analogy is overused but accurate here — the old connectors worked, but standardizing saves everyone time.

The protocol runs on JSON-RPC 2.0 over either stdio or HTTP/SSE. Three roles make up a complete MCP interaction:

• Host — the client environment running the model: Claude Code, Codex, Gemini CLI, or your own app
• MCP Client — embedded in the Host; manages the connection to the Server, sends requests, receives results
• MCP Server — the service process that exposes tools, resources, and prompt templates; can be a local process (stdio) or a remote service (HTTP)

The model itself never touches the protocol layer. It sees a tool list and tool results, same as always. The MCP Client handles all the translation between the JSON-RPC wire format and whatever the model expects.

---

How a Tool Call Actually Flows

Walking through a concrete example — Claude Opus querying a PostgreSQL database — makes the protocol tangible.

Step 1: Capability Negotiation

When the Host starts, the MCP Client sends an initialize request to the Server:

{
  "jsonrpc": "2.0",
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-03-26",
    "clientInfo": { "name": "claude-code", "version": "1.8.2" }
  }
}

The Server responds with the capabilities it supports — tools, resources, prompts — and the Client uses that to shape all subsequent interactions.

Step 2: Tool Discovery

The Client calls tools/list. The Server returns structured tool descriptions: name, description, and a JSON Schema for inputs. That description gets injected into the model's system prompt or tool list so the model knows what it can call.

Step 3: The Call

The model decides which tool to invoke based on user intent and generates a tool call. The Client intercepts it, converts it to MCP format, and sends it to the Server:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": { "sql": "SELECT * FROM orders WHERE status='pending' LIMIT 20" }
  }
}

Step 4: Result

The Server executes the tool logic and returns a structured result. The Client formats that result and injects it back into the model's context. The model continues generating from there.

The model sees none of the JSON-RPC machinery — just tool descriptions and return values. MCP handles the rest.

---

Three Native Capability Types

MCP isn't just a wrapper around function calling. It defines three distinct service primitives:

Type	What it does	Typical use
Tools	Execute actions, may have side effects	Query a DB, call an API, write a file
Resources	Expose read-only data, like a filesystem	Read config, fetch a document chunk
Prompts	Parameterized prompt templates	Standardized code review, report generation

Tools are what most developers reach for first, but Resources deserve attention. They let a Server expose data via URI (e.g., postgres://mydb/orders/schema), so the Client can fetch it on demand rather than stuffing everything into context upfront. For models with 128K+ context windows, that's a practical way to avoid burning tokens on data the model doesn't need yet.

---

Getting Started: Connecting and Building

Connect an existing MCP Server (under 5 minutes)

In Claude Code, drop a .mcp.json in your project root:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRESQL_CONNECTION_STRING": "postgresql://user:pass@localhost/mydb"
      }
    }
  }
}

Save and restart Claude Code — it discovers and connects the Server automatically. The community-maintained registry already covers 80+ servers: GitHub, Slack, Jira, filesystem access, Brave Search, and more.

Write your own MCP Server

The official Python SDK makes this quick:

pip install mcp

Minimal working server:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("my-tool-server")

@mcp.tool()
def get_weather(city: str) -> str:
    """Get current weather for a city."""
    # Replace with a real API call
    return f"{city}: sunny, 25°C"

if __name__ == "__main__":
    mcp.run()  # stdio by default

Any MCP-compatible Host — Claude Code, Codex, Gemini CLI, your own app — can call get_weather without any model-specific adapter code.

Choosing a transport

stdio is the right default for local development: low latency, simple setup. HTTP + SSE is the path for remote deployment — useful when your team needs to share tools or you're integrating with SaaS infrastructure. A reasonable pattern is to validate your logic over stdio first, then migrate to HTTP when you're ready to scale.

---

Ecosystem State and Real Limitations

Claude Code, Codex, and Gemini CLI all have native MCP support today. GPT models can reach MCP servers through Codex's integration, though OpenAI's Responses API is still working toward deeper native alignment — features like Resource subscriptions have uneven support across hosts.

DeepSeek V3, Qwen 3, and other models that expose an OpenAI-compatible interface can use MCP tools through an intermediary Host, but official native MCP client support for those models is still catching up.

The current stable protocol version is 2025-03-26. One thing worth taking seriously: an MCP Server can execute arbitrary code. Treat third-party servers the way you'd treat third-party dependencies — audit them before you connect, and don't blindly run npx -y on a server from an unknown source.

---

When you're actively debugging MCP tool chains, model API costs and latency start to matter more than you'd expect. I test most of my MCP server work through XycAi — one OpenAI-compatible endpoint that covers 200+ models including GPT and Claude Opus, with pricing starting around 14% of list price and ~5ms latency via CN2 direct connect. Claude Code and Codex both wire up in one command. The difference adds up fast when you're running high call volumes across multiple models.