<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=1200&amp;auto=format&amp;fit=crop"><h2 id="introduction">Introduction</h2>If you’ve been following the AI tooling space in 2026, you’ve probably heard “MCP” mentioned more and more. Anthropic’s Model Context Protocol has quietly become the connective tissue of the modern AI agent ecosystem — the USB-C of AI integrations. In this post, we’ll break down exactly what MCP is, how it works under the hood, and how to build production-grade MCP servers your agents can actually rely on.<img src="https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=900&amp;auto=format&amp;fit=crop" alt="Abstract network connections representing AI protocols"> Photo by <a href="https://unsplash.com/@larskienle">Lars Kienle</a> on Unsplash<hr><h2 id="what-is-mcp">What Is MCP?</h2>Model Context Protocol is an open standard that defines how AI models (and the applications running them) communicate with external tools, data sources, and services. Before MCP, every AI framework invented its own tool-calling convention — OpenAI had function calling, LangChain had its own tool interface, LlamaIndex had yet another. Integrating a new tool meant writing N different adapters for N different frameworks.MCP standardizes this with three core concepts:<table><thead><tr><th>Concept</th><th>Description</th></tr></thead><tbody><tr><td>Resources</td><td>Static or dynamic data the model can read (files, DB rows, API responses)</td></tr><tr><td>Tools</td><td>Functions the model can invoke with arguments</td></tr><tr><td>Prompts</td><td>Reusable prompt templates with slot-filling</td></tr></tbody></table>An MCP server exposes these via a well-defined JSON-RPC-based protocol over stdio or HTTP/SSE. Any MCP-compatible host (Claude, Cursor, OpenClaw, your custom agent) can discover and call them automatically.<hr><h2 id="architecture-overview">Architecture Overview</h2><div><pre><code>┌─────────────────────────────────┐
│ MCP Host (Claude) │
│ ┌───────────────────────────┐ │
│ │ MCP Client │ │
│ └───────────┬───────────────┘ │
└─────────────────────────────────┘
 │ JSON-RPC (stdio / HTTP+SSE)
 ┌────────┴────────┐
 │ │
┌────▼────┐ ┌────▼────┐
│ MCP │ │ MCP │
│ Server │ │ Server │
│(GitHub) │ │ (DB) │
└─────────┘ └─────────┘
</code></pre></div>The host acts as the orchestrator. When the model decides it needs to fetch a GitHub issue, the host routes that request to the registered GitHub MCP server, gets a response, and feeds it back into the model context. The model never directly touches the tool implementation — it just sees structured inputs and outputs.<hr><h2 id="building-a-production-mcp-server">Building a Production MCP Server</h2>Let’s build a minimal but production-ready MCP server in Python using the official <code>mcp</code> SDK.<h3 id="1-install-the-sdk">1. Install the SDK</h3><h3 id="2-define-your-server">2. Define Your Server</h3><div><pre><code>from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent
import httpx
import asyncio

app = Server("weather-mcp")

@app.list_tools()
async def list_tools():
 return [
 Tool(
 name="get_current_weather",
 description="Get current weather for a city",
 inputSchema={
 "type": "object",
 "properties": {
 "city": {"type": "string", "description": "City name"},
 "units": {
 "type": "string",
 "enum": ["metric", "imperial"],
 "default": "metric"
 }
 },
 "required": ["city"]
 }
 )
 ]

@app.call_tool()
async def call_tool(name: str, arguments: dict):
 if name == "get_current_weather":
 city = arguments["city"]
 units = arguments.get("units", "metric")
 async with httpx.AsyncClient() as client:
 resp = await client.get(
 "https://api.openweathermap.org/data/2.5/weather",
 params={"q": city, "units": units, "appid": "YOUR_KEY"}
 )
 data = resp.json()
 return [TextContent(
 type="text",
 text=f"Weather in {city}: {data['weather'][0]['description']}, "
 f"Temp: {data['main']['temp']}°"
 )]

async def main():
 async with stdio_server() as (read_stream, write_stream):
 await app.run(read_stream, write_stream, app.create_initialization_options())

if __name__ == "__main__":
 asyncio.run(main())
</code></pre></div><h3 id="3-register-it-with-your-mcp-host">3. Register It with Your MCP Host</h3>For Claude Desktop, add to <code>~/Library/Application Support/Claude/claude_desktop_config.json</code>:<div><pre><code>{
 "mcpServers": {
 "weather": {
 "command": "python",
 "args": ["/path/to/weather_server.py"]
 }
 }
}
</code></pre></div><hr><h2 id="production-concerns">Production Concerns</h2><h3 id="error-handling">Error Handling</h3>MCP servers need to return well-formed error responses, not crash. Wrap tool implementations in try/except and return <code>isError: true</code> content:<div><pre><code>@app.call_tool()
async def call_tool(name: str, arguments: dict):
 try:
 # ... your logic
 except Exception as e:
 return [TextContent(type="text", text=f"Error: {str(e)}")]
 # Or use the MCP error type for structured errors
</code></pre></div><h3 id="authentication">Authentication</h3>For HTTP-transported MCP servers, implement OAuth 2.0. The MCP spec now defines a standard auth flow for remote servers. For internal/self-hosted servers, mTLS or API key headers are common patterns.<h3 id="observability">Observability</h3>Log every tool call with:<ul><li>Tool name + arguments (sanitize PII)</li><li>Latency</li><li>Success/failure</li><li>Caller identity (if multi-tenant)</li></ul><div><pre><code>import logging
import time

@app.call_tool()
async def call_tool(name: str, arguments: dict):
 start = time.time()
 try:
 result = await _execute_tool(name, arguments)
 logging.info("tool_call", extra={
 "tool": name, 
 "latency_ms": (time.time() - start) * 1000,
 "success": True
 })
 return result
 except Exception as e:
 logging.error("tool_call_failed", extra={"tool": name, "error": str(e)})
 raise
</code></pre></div><h3 id="versioning">Versioning</h3>Version your tool schemas. Adding required fields is a breaking change. Use semantic versioning in your server name (<code>weather-mcp-v2</code>) or expose a <code>/version</code> resource.<hr><table><thead><tr><th>Feature</th><th>MCP</th><th>OpenAI Function Calling</th><th>LangChain Tools</th></tr></thead><tbody><tr><td>Framework-agnostic</td><td>✅</td><td>❌ (OpenAI-only)</td><td>❌ (LangChain-only)</td></tr><tr><td>Standardized protocol</td><td>✅</td><td>Partial</td><td>❌</td></tr><tr><td>Resources + Prompts</td><td>✅</td><td>❌</td><td>❌</td></tr><tr><td>Remote server support</td><td>✅ (HTTP/SSE)</td><td>❌</td><td>Limited</td></tr><tr><td>Ecosystem maturity</td><td>Growing fast</td><td>Mature</td><td>Mature</td></tr></tbody></table>MCP wins on portability. If you’re building a tool that should work with multiple AI platforms, MCP is the obvious choice in 2026.<hr><h2 id="the-mcp-ecosystem-in-2026">The MCP Ecosystem in 2026</h2>The ecosystem has exploded:<ul><li>Official servers: GitHub, Slack, Google Drive, PostgreSQL, Puppeteer, and dozens more</li><li>Registries: MCP Hub and similar directories let you discover community servers</li><li>Framework support: LangChain, LlamaIndex, and AutoGen all support MCP servers natively now</li><li>Security: The MCP working group published security guidelines — server sandboxing, capability negotiation, and input validation are all formalized</li></ul><img src="https://images.unsplash.com/photo-1504639725590-34d0984388bd?w=900&amp;auto=format&amp;fit=crop" alt="Developer working on AI integrations"> Photo by <a href="https://unsplash.com/@ikukevk">Kevin Ku</a> on Unsplash<hr><h2 id="should-you-build-an-mcp-server">Should You Build an MCP Server?</h2>Yes, if:<ul><li>You have internal tooling (databases, APIs, services) that agents should be able to access</li><li>You want to share tools across multiple AI products/frameworks</li><li>You’re building a developer-facing product that integrates with AI assistants</li></ul>Maybe not, if:<ul><li>You only use one AI framework exclusively and have no plans to switch</li><li>Your tool is a one-off hack that only one agent will ever use</li></ul><hr><h2 id="conclusion">Conclusion</h2>MCP is no longer a niche Anthropic experiment — it’s becoming infrastructure. The bet that open standards beat proprietary silos is playing out in real time. Building MCP-compatible tools now means your integrations will work with Claude, Cursor, OpenClaw, and whatever AI host comes next. That’s a solid investment.The official spec, SDK, and server examples live at <a href="https://modelcontextprotocol.io/">modelcontextprotocol.io</a>. Start there. <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

Introduction
If you’ve been following the AI tooling space in 2026, you’ve probably heard “MCP” mentioned more and more. Anthropic’s Model Context Protocol has quietly become the connective tissue of the modern AI agent ecosystem — the USB-C of AI integrations. In this post, we’ll break down exactly what MCP is, how it works under the hood, and how to build production-grade MCP servers your agents can actually rely on.
Photo by Lars Kienle on Unsplash
What Is MCP?
Model Context Protocol is an open standard that defines how AI models (and the applications running them) communicate with external tools, data sources, and services. Before MCP, every AI framework invented its own tool-calling convention — OpenAI had function calling, LangChain had its own tool interface, LlamaIndex had yet another. Integrating a new tool meant writing N different adapters for N different frameworks.
MCP standardizes this with three core concepts:
Concept
      Description
    
Resources
      Static or dynamic data the model can read (files, DB rows, API responses)
    
Tools
      Functions the model can invoke with arguments
    
Prompts
      Reusable prompt templates with slot-filling
    
An MCP server exposes these via a well-defined JSON-RPC-based protocol over stdio or HTTP/SSE. Any MCP-compatible host (Claude, Cursor, OpenClaw, your custom agent) can discover and call them automatically.
Architecture Overview
┌─────────────────────────────────┐
│         MCP Host (Claude)       │
│  ┌───────────────────────────┐  │
│  │      MCP Client           │  │
│  └───────────┬───────────────┘  │
└─────────────────────────────────┘
              │ JSON-RPC (stdio / HTTP+SSE)
     ┌────────┴────────┐
     │                 │
┌────▼────┐       ┌────▼────┐
│  MCP    │       │  MCP    │
│ Server  │       │ Server  │
│(GitHub) │       │ (DB)    │
└─────────┘       └─────────┘
The host acts as the orchestrator. When the model decides it needs to fetch a GitHub issue, the host routes that request to the registered GitHub MCP server, gets a response, and feeds it back into the model context. The model never directly touches the tool implementation — it just sees structured inputs and outputs.
Building a Production MCP Server
Let’s build a minimal but production-ready MCP server in Python using the official mcp SDK.
1. Install the SDK
pip install mcp
2. Define Your Server
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent
import httpx
import asyncio
app = Server("weather-mcp")
@app.list_tools()
async def list_tools():
    return [
        Tool(
            name="get_current_weather",
            description="Get current weather for a city",
            inputSchema={
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "City name"},
                    "units": {
                        "type": "string",
                        "enum": ["metric", "imperial"],
                        "default": "metric"
                    }
                },
                "required": ["city"]
            }
        )
    ]
@app.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "get_current_weather":
        city = arguments["city"]
        units = arguments.get("units", "metric")
        async with httpx.AsyncClient() as client:
            resp = await client.get(
                "https://api.openweathermap.org/data/2.5/weather",
                params={"q": city, "units": units, "appid": "YOUR_KEY"}
            )
            data = resp.json()
            return [TextContent(
                type="text",
                text=f"Weather in {city}: {data['weather'][0]['description']}, "
                     f"Temp: {data['main']['temp']}°"
            )]
async def main():
    async with stdio_server() as (read_stream, write_stream):
        await app.run(read_stream, write_stream, app.create_initialization_options())
if __name__ == "__main__":
    asyncio.run(main())
3. Register It with Your MCP Host
For Claude Desktop, add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
  "mcpServers": {
    "weather": {
      "command": "python",
      "args": ["/path/to/weather_server.py"]
    }
  }
}
Production Concerns
Error Handling
MCP servers need to return well-formed error responses, not crash. Wrap tool implementations in try/except and return isError: true content:
@app.call_tool()
async def call_tool(name: str, arguments: dict):
    try:
        # ... your logic
    except Exception as e:
        return [TextContent(type="text", text=f"Error: {str(e)}")]
        # Or use the MCP error type for structured errors
Authentication
For HTTP-transported MCP servers, implement OAuth 2.0. The MCP spec now defines a standard auth flow for remote servers. For internal/self-hosted servers, mTLS or API key headers are common patterns.
Observability
Log every tool call with:
Tool name + arguments (sanitize PII)
Latency
Success/failure
Caller identity (if multi-tenant)
import logging
import time
@app.call_tool()
async def call_tool(name: str, arguments: dict):
    start = time.time()
    try:
        result = await _execute_tool(name, arguments)
        logging.info("tool_call", extra={
            "tool": name, 
            "latency_ms": (time.time() - start) * 1000,
            "success": True
        })
        return result
    except Exception as e:
        logging.error("tool_call_failed", extra={"tool": name, "error": str(e)})
        raise
Versioning
Version your tool schemas. Adding required fields is a breaking change. Use semantic versioning in your server name (weather-mcp-v2) or expose a /version resource.
MCP vs. OpenAI Function Calling vs. LangChain Tools
Feature
      MCP
      OpenAI Function Calling
      LangChain Tools
    
Framework-agnostic
      ✅
      ❌ (OpenAI-only)
      ❌ (LangChain-only)
    
Standardized protocol
      ✅
      Partial
      ❌
    
Resources + Prompts
      ✅
      ❌
      ❌
    
Remote server support
      ✅ (HTTP/SSE)
      ❌
      Limited
    
Ecosystem maturity
      Growing fast
      Mature
      Mature
    
MCP wins on portability. If you’re building a tool that should work with multiple AI platforms, MCP is the obvious choice in 2026.
The MCP Ecosystem in 2026
The ecosystem has exploded:
Official servers: GitHub, Slack, Google Drive, PostgreSQL, Puppeteer, and dozens more
Registries: MCP Hub and similar directories let you discover community servers
Framework support: LangChain, LlamaIndex, and AutoGen all support MCP servers natively now
Security: The MCP working group published security guidelines — server sandboxing, capability negotiation, and input validation are all formalized
Photo by Kevin Ku on Unsplash
Should You Build an MCP Server?
Yes, if:
You have internal tooling (databases, APIs, services) that agents should be able to access
You want to share tools across multiple AI products/frameworks
You’re building a developer-facing product that integrates with AI assistants
Maybe not, if:
You only use one AI framework exclusively and have no plans to switch
Your tool is a one-off hack that only one agent will ever use
Conclusion
MCP is no longer a niche Anthropic experiment — it’s becoming infrastructure. The bet that open standards beat proprietary silos is playing out in real time. Building MCP-compatible tools now means your integrations will work with Claude, Cursor, OpenClaw, and whatever AI host comes next. That’s a solid investment.
The official spec, SDK, and server examples live at modelcontextprotocol.io. Start there.

Model Context Protocol (MCP): The Standard That's Changing How AI Agents Connect to Tools

댓글