Introduction
Every AI agent eventually needs to connect to external systems—databases, APIs, file systems, and third-party services. Until recently, each integration was custom-built, creating fragmented ecosystems where tools built for one AI system couldn't work with another. The Model Context Protocol (MCP) changes this.
The Vision: MCP is to AI agents what USB was to hardware peripherals—a universal standard that lets any tool work with any AI system.
Developed by Anthropic and released as an open standard, MCP provides a unified way for AI applications to connect with external data sources and tools. It's already supported by Claude Desktop, VS Code, and numerous other applications, with adoption accelerating across the AI industry.
The Integration Problem
Before MCP, connecting AI agents to external systems was a fragmented mess:
The N×M Problem
📝integration_nightmare.txt
1BEFORE MCP: The Integration Nightmare
2
3AI Applications: External Systems:
4┌─────────────────┐ ┌─────────────────┐
5│ Claude Desktop │───┬───▶│ GitHub API │
6│ │ │ │ (custom adapter)│
7│ │───┼───▶│ Slack API │
8│ │ │ │ (custom adapter)│
9│ │───┼───▶│ PostgreSQL │
10│ │ │ │ (custom adapter)│
11└─────────────────┘ │ └─────────────────┘
12 │
13┌─────────────────┐ │ ┌─────────────────┐
14│ ChatGPT │───┼───▶│ GitHub API │
15│ │ │ │ (different code)│
16│ │───┼───▶│ Slack API │
17│ │ │ │ (different code)│
18└─────────────────┘ │ └─────────────────┘
19 │
20┌─────────────────┐ │ ┌─────────────────┐
21│ Custom Agent │───┴───▶│ Same APIs... │
22│ │ │ (yet another │
23│ │ │ implementation)│
24└─────────────────┘ └─────────────────┘
25
26N applications × M data sources = N×M custom integrations
2710 apps × 20 sources = 200 separate integrations!Problems with Custom Integrations
| Problem | Impact | Example |
|---|---|---|
| Duplicated effort | Same integration built many times | Every app builds its own GitHub connector |
| Inconsistent quality | Some integrations better than others | OAuth handling varies wildly |
| Maintenance burden | Updates needed across many codebases | API change breaks N implementations |
| Security gaps | Each implementation has own vulnerabilities | Token handling differs per integration |
| No portability | Tools locked to one AI system | Can't reuse Claude tools with GPT |
🐍before_mcp.py
1# Before MCP: Custom integration for each AI system
2
3# For Claude
4class ClaudeGitHubTool:
5 """GitHub tool specifically for Claude."""
6
7 def get_file(self, repo: str, path: str):
8 # Claude-specific implementation
9 token = self.get_claude_oauth_token()
10 response = requests.get(
11 f"https://api.github.com/repos/{repo}/contents/{path}",
12 headers={"Authorization": f"token {token}"}
13 )
14 # Format for Claude's expected response format
15 return self._format_for_claude(response.json())
16
17# For GPT - completely separate implementation
18class GPTGitHubTool:
19 """GitHub tool specifically for GPT."""
20
21 def read_file(self, repository: str, file_path: str):
22 # GPT-specific implementation
23 api_key = self.get_gpt_stored_key()
24 response = requests.get(
25 f"https://api.github.com/repos/{repository}/contents/{file_path}",
26 headers={"Authorization": f"token {api_key}"}
27 )
28 # Format for GPT's expected response format
29 return self._format_for_gpt(response.json())
30
31# Different method names, different auth, different formatting
32# Duplicated logic, duplicated bugs, duplicated maintenanceWhat is MCP
The Model Context Protocol (MCP) is an open protocol that standardizes how AI applications communicate with external data sources and tools. It transforms the N×M problem into an N+M solution.
📝with_mcp.txt
1WITH MCP: The Standardized Approach
2
3AI Applications: MCP Servers:
4┌─────────────────┐ ┌─────────────────┐
5│ Claude Desktop │────┐ │ GitHub Server │
6│ (MCP Client) │ │ │ (one impl) │
7└─────────────────┘ │ └────────▲────────┘
8 │ │
9┌─────────────────┐ │ ┌────────┴────────┐
10│ VS Code │────┼────▶│ MCP Protocol │
11│ (MCP Client) │ │ │ (standard) │
12└─────────────────┘ │ └────────┬────────┘
13 │ │
14┌─────────────────┐ │ ┌────────▼────────┐
15│ Custom Agent │────┘ │ Slack Server │
16│ (MCP Client) │ │ (one impl) │
17└─────────────────┘ └─────────────────┘
18
19N applications + M servers = N+M implementations
2010 apps + 20 servers = 30 implementations (not 200!)Core Components
MCP defines a client-server architecture:
| Component | Role | Examples |
|---|---|---|
| MCP Host | The AI application users interact with | Claude Desktop, VS Code, custom apps |
| MCP Client | Protocol handler within the host | Manages server connections |
| MCP Server | Provides tools/resources to clients | GitHub server, database server |
| Transport | Communication channel | stdio, HTTP/SSE, WebSocket |
📘mcp_architecture.ts
1// MCP Architecture Overview
2
3// The MCP Host is your AI application
4interface MCPHost {
5 // Contains one or more MCP clients
6 clients: Map<string, MCPClient>;
7
8 // The LLM doing the reasoning
9 llm: LanguageModel;
10
11 // Route tool calls to appropriate servers
12 routeToolCall(name: string, args: object): Promise<Result>;
13}
14
15// MCP Client manages connection to one server
16interface MCPClient {
17 // Connect to an MCP server
18 connect(transport: Transport): Promise<void>;
19
20 // Discover what the server provides
21 listTools(): Promise<Tool[]>;
22 listResources(): Promise<Resource[]>;
23 listPrompts(): Promise<Prompt[]>;
24
25 // Execute operations
26 callTool(name: string, args: object): Promise<ToolResult>;
27 readResource(uri: string): Promise<ResourceContent>;
28 getPrompt(name: string, args?: object): Promise<PromptMessage[]>;
29}
30
31// MCP Server exposes capabilities
32interface MCPServer {
33 // Declare available capabilities
34 tools: Tool[];
35 resources: Resource[];
36 prompts: Prompt[];
37
38 // Handle requests from clients
39 handleToolCall(name: string, args: object): Promise<ToolResult>;
40 handleResourceRead(uri: string): Promise<ResourceContent>;
41 handlePromptGet(name: string, args?: object): Promise<PromptMessage[]>;
42}The USB Analogy
MCP is often compared to USB, and the analogy is instructive:
Before USB (Before MCP)
📝before_usb.txt
1HARDWARE BEFORE USB:
2
3Keyboard ──────▶ PS/2 Port (purple)
4Mouse ─────────▶ PS/2 Port (green)
5Printer ───────▶ Parallel Port (25-pin)
6Modem ─────────▶ Serial Port (9-pin)
7Scanner ───────▶ SCSI Port (50-pin)
8
9Every device type needed:
10- Different physical connector
11- Different electrical spec
12- Different driver architecture
13- Different communication protocol
14
15Adding new device = new port type needed on motherboardAfter USB (After MCP)
📝after_usb.txt
1HARDWARE WITH USB:
2
3Keyboard ──────▶ ┌──────────┐
4Mouse ─────────▶ │ │
5Printer ───────▶ │ USB │──────▶ Computer
6Modem ─────────▶ │ Standard │
7Scanner ───────▶ │ │
8New Device ────▶ └──────────┘
9
10One universal standard:
11- Same physical connector
12- Same electrical spec
13- Same driver model
14- Same communication protocol
15
16Adding new device = just implement USB protocolMCP as AI's USB
📝mcp_as_usb.txt
1AI INTEGRATIONS WITH MCP:
2
3GitHub ────────▶ ┌──────────┐
4Slack ─────────▶ │ │
5Database ──────▶ │ MCP │──────▶ Any AI App
6Files ─────────▶ │ Standard │
7Web Search ────▶ │ │
8New Service ───▶ └──────────┘
9
10One universal protocol:
11- Same message format
12- Same capability discovery
13- Same authentication flow
14- Same error handling
15
16Adding new integration = just implement MCP serverWhy Standards Win
USB succeeded not because it was technically superior to every specialized connector, but because the benefits of standardization outweighed optimization for specific use cases. MCP follows the same principle—universal compatibility beats custom optimization.
Key Concepts
MCP provides three main types of capabilities:
1. Tools
Tools are functions the LLM can call to perform actions:
{}tool_example.json
1{
2 "name": "create_github_issue",
3 "description": "Create a new issue in a GitHub repository",
4 "inputSchema": {
5 "type": "object",
6 "properties": {
7 "repo": {
8 "type": "string",
9 "description": "Repository in format owner/repo"
10 },
11 "title": {
12 "type": "string",
13 "description": "Issue title"
14 },
15 "body": {
16 "type": "string",
17 "description": "Issue body/description"
18 },
19 "labels": {
20 "type": "array",
21 "items": { "type": "string" },
22 "description": "Labels to apply"
23 }
24 },
25 "required": ["repo", "title"]
26 }
27}2. Resources
Resources are data the LLM can read (like files or database records):
{}resource_example.json
1{
2 "uri": "file:///project/src/main.py",
3 "name": "Main Application",
4 "description": "Primary application entry point",
5 "mimeType": "text/x-python"
6}
7
8// Resources can also be dynamic
9{
10 "uri": "postgres://db/users?query=active",
11 "name": "Active Users",
12 "description": "Currently active user records"
13}3. Prompts
Prompts are reusable templates for common interactions:
{}prompt_example.json
1{
2 "name": "code_review",
3 "description": "Template for reviewing code changes",
4 "arguments": [
5 {
6 "name": "diff",
7 "description": "The code diff to review",
8 "required": true
9 },
10 {
11 "name": "focus_areas",
12 "description": "Specific areas to focus on",
13 "required": false
14 }
15 ]
16}Capability Discovery
📘discovery.ts
1// MCP enables automatic capability discovery
2
3async function discoverServerCapabilities(client: MCPClient) {
4 // Connect to server
5 await client.connect();
6
7 // Discover what's available
8 const tools = await client.listTools();
9 const resources = await client.listResources();
10 const prompts = await client.listPrompts();
11
12 console.log("Available tools:", tools.map(t => t.name));
13 // ["create_issue", "list_repos", "get_file", "search_code"]
14
15 console.log("Available resources:", resources.map(r => r.uri));
16 // ["file:///repo/...", "github://issues/..."]
17
18 console.log("Available prompts:", prompts.map(p => p.name));
19 // ["code_review", "bug_report", "pr_summary"]
20}MCP vs Alternatives
How does MCP compare to other approaches for AI tool integration?
MCP vs Direct Function Calling
| Aspect | Direct Function Calling | MCP |
|---|---|---|
| Setup | Define functions in code | Connect to MCP servers |
| Portability | Tied to one application | Works across any MCP client |
| Discovery | Hardcoded tool list | Dynamic capability discovery |
| Updates | Redeploy application | Update server independently |
| Ecosystem | Build everything yourself | Reuse community servers |
MCP vs OpenAI Plugins (deprecated)
| Aspect | OpenAI Plugins | MCP |
|---|---|---|
| Ownership | Controlled by OpenAI | Open protocol by Anthropic |
| Specification | Proprietary | Open standard |
| Transports | HTTP only | stdio, HTTP/SSE, WebSocket |
| Local execution | No | Yes (stdio) |
| Status | Deprecated | Actively developed |
MCP vs Custom REST APIs
| Aspect | Custom REST APIs | MCP |
|---|---|---|
| Schema format | OpenAPI/Swagger | JSON Schema (simpler) |
| AI optimization | Generic HTTP | Designed for LLM interaction |
| Resources | GET endpoints | First-class resource concept |
| Prompts | Not supported | Built-in prompt templates |
| Streaming | Varies | Native support |
MCP doesn't replace REST APIs—MCP servers often wrap REST APIs to expose them to AI systems in a standardized way.
Summary
Key takeaways about MCP:
- Universal standard: MCP provides a single protocol for AI-to-tool communication
- Client-server architecture: AI apps (clients) connect to capability providers (servers)
- Three capability types: Tools (actions), Resources (data), Prompts (templates)
- Dynamic discovery: Clients can discover what servers provide at runtime
- Portable: Build once, use with any MCP-compatible AI application
- Open: Not locked to any single AI provider
Next: Let's dive deep into MCP's architecture—the transport layers, message formats, and protocol flow that make it work.