Stop rewriting the same API glue for every AI platform. One weather-query function: for Claude Desktop I wrapped a RESTful API, for Coze a plugin JS, for Dify a YAML, for LangChain a custom Tool class. Param names, return formats, auth-all different. Every upstream model update means checking compatibility line by line; you feel like a manual switchboard operator glueing AI tools together, with maintenance cost rising exponentially.
This isn't a capability problem-it's protocol fragmentation. AI tools exploded but stayed isolated, each framework inventing its own "dialect." Only when Anthropic pushed out the MCP protocol did things really change. MCP isn't a framework; it's a unified communication standard-write a tool once, callable by any MCP-supporting client.
This piece skips the 5-minute toy and goes engineering-grade: architecture, ecosystem, hands-on, and pitfalls.
1. MCP Isn't a Framework, It's a Protocol
Many compare MCP with LangChain or Semantic Kernel-that's the wrong track. MCP doesn't care how you implement tools or define business logic; it defines one thing: how an AI client (Host) discovers and invokes remote tools (Server) in a standardized way.
Three roles:
- MCP Host: the AI app itself, e.g., Claude Desktop, Cherry Studio, Cline. Issues user commands, shows final results.
- MCP Client: the protocol client embedded in the Host, maintaining a 1:1 connection with a Server, translating requests.
- MCP Server: the tool you write, wrapping your "exclusive capability"-querying DBs, calling APIs, manipulating files.
The flow is clear: at Host startup, the Client finds the Server via config and gets the capability list (list_tools). The user issues a command; the Host sends the question plus the tool list to the LLM. The LLM analyzes, decides which tool to call, and generates params matching the Schema. The Client sends the call to the Server, gets the result back to the LLM, which integrates and shows it. That's MCP's "decouple and reuse" value: write a tool once, every MCP-supporting client can use it-no per-platform glue.
2. Ecosystem: Not Just Claude, China Is Already In
Many think MCP serves only Claude. By 2026 its ecosystem covers major vendors, open-source frameworks, and creative apps.
Microsoft released an official MCP Server collection covering Azure, GitHub, Teams. Alibaba Cloud blogged a Grafana MCP Server demo, letting LLMs return Dashboard real-time images and lists. LangChain shipped langchain-mcp-adapters, converting MCP Server tools to LangChain Tool objects-seamless new-protocol adoption for an old framework. On the client side, Cherry Studio 1.1.2 has built-in MCP, Cline (VS Code plugin) acts as Host, even Unity engine uses Codex + MCP to let AI manipulate scene objects in-game.
2026 Best MCP Server Complete Guide on Juejin lists dozens of production-grade Servers from knowledge retrieval to code gen to ops, stressing "don't treat them as toys-they're production tools giving Agents structured access." Find Servers in three places: the GitHub official repo, the awesome-mcp-servers list, the glama.ai marketplace.
It's not too late. Stop writing per-platform plugins; wrap core capabilities as an MCP Server and reach all major Hosts at once.
3. Hands-on: Build a Runnable MCP Server from Scratch
Below is a minimal Python MCP Server, math-tutor, with two tools: add and multiply. Based on the official mcp Python lib, fully runnable, Python 3.10+.
1. Environment: manage the project with uv
# Install uv (if missing)
curl -LsSf https://astral.sh/uv/install.sh | sh
# Create project
uv init math-tutor
cd math-tutor
uv add mcp[cli]2. Core code: server.py
import asyncio
from mcp.server import Server, NotificationOptions
from mcp.server.models import InitializationCapabilities
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent
server = Server("math-tutor")
@server.list_tools()
async def handle_list_tools() -> list[Tool]:
"""Tell the Host what I can do"""
return [
Tool(
name="add",
description="Calculate the sum of two numbers",
inputSchema={
"type": "object",
"properties": {
"x": {"type": "number", "description": "First addend"},
"y": {"type": "number", "description": "Second addend"}
},
"required": ["x", "y"]
}
),
Tool(
name="multiply",
description="Calculate the product of two numbers",
inputSchema={
"type": "object",
"properties": {
"a": {"type": "number", "description": "Multiplier"},
"b": {"type": "number", "description": "Multiplicand"}
},
"required": ["a", "b"]
}
)
]
@server.call_tool()
async def handle_call_tool(name: str, arguments: dict) -> list[TextContent]:
"""Execute a specific tool"""
if name == "add":
result = arguments["x"] + arguments["y"]
return [TextContent(type="text", text=f"Result is {result}")]
elif name == "multiply":
result = arguments["a"] * arguments["b"]
return [TextContent(type="text", text=f"Result is {result}")]
else:
raise ValueError(f"Unknown tool: {name}")
async def main():
async with stdio_server() as (read_stream, write_stream):
await server.run(
read_stream,
write_stream,
InitializationCapabilities(
sampling={},
experimental={},
),
notification_options=NotificationOptions()
)
if __name__ == "__main__":
asyncio.run(main())3. Configure and launch
Edit pyproject.toml, add the entry point:
[project.scripts]
math-tutor = "server:main"Then uv run math-tutor runs it. Now you need a Host to test.
4. Test with MCP Inspector
The official Inspector debug tool-no need to write a client:
npx @anthropic-ai/mcp-inspector uv run math-tutorOpen the given URL in a browser, see the Server's tool list, click add, input params, get the result instantly. Far more efficient than repeatedly restarting in Claude Desktop.
5. Plug into Claude Desktop (or other Host)
Edit claude_desktop_config.json (usually under ~/Library/Application Support/Claude/):
{
"mcpServers": {
"math-tutor": {
"command": "uv",
"args": ["run", "math-tutor"]
}
}
}Restart Claude Desktop, type "use the math assistant to compute 3.14 times 2.5," and it auto-invokes your Server and returns the result.
You write zero HTTP routes, JSON parsing, or auth logic-MCP wraps the transport; you focus on call_tool business logic.
4. Advanced: Real Business, Grafana Example
A toy Server is step one; the real value is wrapping enterprise systems as MCP Servers for AI to operate directly. Alibaba Cloud's MCP Server dev: LLMs seamlessly dock with Grafana is a good demo: let LLMs return Grafana Dashboard lists and real-time charts via MCP.
Core idea: in call_tool, call the Grafana API (API Key auth), get JSON, process as needed. E.g., list_dashboards returns the panel list, get_dashboard_image calls Grafana's render API returning an image URL. When the user says "show the app monitoring dashboard," AI pulls the image directly, not just an ID.
Hands-on points:
- Tool descriptions (
description) must be detailed enough-the LLM uses them to decide when to call you. E.g., "Get a real-time screenshot of a specified Grafana panel; requires dashboardUid, panelId, and time range." - Define param Schema strictly;
requiredmust be accurate, or the LLM may omit key params. - Security: for sensitive data, use read-only API Keys with scoped limits (e.g., view only specified Dashboards). Recommended three steps: read-only first, narrow scope second, full logging third-gradually open permissions.
5. Pitfalls and Selection: Don't Let MCP Become a New Burden
Tool descriptions are for the LLM. Writing "this is an addition tool" is as good as nothing. The LLM needs enough context to judge when to call you. Correct: "Calculate the sum of two numbers, for scenarios needing arithmetic, e.g., the user asks 'what's 1+2' or 'add 3 and 5.'"
One Server, one responsibility. Don't cram DB queries, file ops, and email into one Server. MCP Servers should be orthogonal, single-responsibility, easy to compose and permission.
Don't ignore transport choice. MCP supports multiple transports: stdio (local processes), HTTP (Streamable HTTP, streaming output). stdio is most convenient for local dev; for remote teams or production, use HTTP mode with auth. The new spec is pushing safer streaming transports-worth watching.
References