给你的Agent装个“外挂”？别再被私有协议坑了

最近在折腾AI Agent的工具调用，被各种私有协议搞得头大。OpenAI的Function Calling一套规则，Claude又是另一套，等你对接完自家内部的API，发现格式又不一样了。每次换模型或者加新工具，都得重写一遍适配层，这谁顶得住？

直到我发现了MCP（Model Context Protocol）协议——这玩意儿简直就是Agent工具调用的“万能插座”。今天我就用踩坑记录的方式，带你用Python给Agent集成MCP协议，彻底告别重复造轮子。

MCP协议：Agent工具的“USB标准”

先说清楚MCP是什么。简单理解，它是一套让AI模型和外部工具对话的标准化协议。就像USB接口一样，不管你是插U盘、键盘还是手机，接口都一样。MCP让不同模型（Claude、GPT、龙虾模型）都能用同一套方式调用工具。

核心三件套：

• MCP Server：工具提供方，比如你的天气查询API、数据库接口
• MCP Client：Agent侧，负责和模型沟通，转发工具调用请求
• 协议格式：JSON-RPC 2.0，定义了请求/响应的标准结构

对比Function Calling，MCP最大优势是解耦。Function Calling是模型厂商定义的，模型换了你就得改。MCP是中间层，模型和工具都通过这个标准接口对话，换模型不用动工具代码。

踩坑实录：从环境配置到协议调试

第一步：环境配置的坑

# 我以为直接pip install mcp就行，结果...
pip install mcp

# 报错：缺少依赖
# 实际需要：
pip install "mcp[cli]" httpx sse-starlette

坑点1：官方文档没明确说需要sse-starlette，但不用的话Server启动会报错。这是MCP支持流式传输的依赖。

第二步：工具函数封装

假设我们要封装一个天气查询工具：

# weather_tool.py
from mcp.server import Server
from mcp.types import Tool, TextContent
import httpx

app = Server("weather-server")

@app.list_tools()
async def list_tools():
    return [
        Tool(
            name="get_weather",
            description="获取指定城市的天气",
            inputSchema={
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "城市名称"}
                },
                "required": ["city"]
            }
        )
    ]

@app.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "get_weather":
        city = arguments["city"]
        # 调用实际的天气API
        async with httpx.AsyncClient() as client:
            resp = await client.get(
                f"https://api.weather.com/v1/{city}",
                headers={"Authorization": "Bearer your_key"}
            )
            data = resp.json()
        
        return [TextContent(type="text", text=f"{city}今天{data['temp']}℃，{data['condition']}")]

坑点2：inputSchema必须严格符合JSON Schema规范。我第一次少写了"type": "object"，Client死活调不通，报错信息还不明确。

第三步：协议调试技巧

调试MCP最实用的几招：

# 调试脚本：直接测试Server
import asyncio
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

async def test_server():
    server_params = StdioServerParameters(
        command="python",
        args=["weather_tool.py"]
    )
    
    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            
            # 1. 先列工具，看Schema对不对
            tools = await session.list_tools()
            print("可用工具:", [t.name for t in tools.tools])
            
            # 2. 测试调用
            result = await session.call_tool("get_weather", {"city": "北京"})
            print("调用结果:", result.content[0].text)

asyncio.run(test_server())

坑点3：MCP默认用stdio通信，但生产环境需要用SSE（Server-Sent Events）。切换时要注意：

# 生产环境用SSE
from mcp.server.sse import SseServerTransport
from starlette.applications import Starlette
from starlette.routing import Route

sse = SseServerTransport("/messages")

async def handle_sse(request):
    async with sse.connect_sse(request.scope, request.receive, request._send) as streams:
        await app.run(streams[0], streams[1], app.create_initialization_options())

app = Starlette(
    routes=[
        Route("/sse", endpoint=handle_sse, methods=["GET"]),
        Route("/messages/", endpoint=sse.handle_post_message, methods=["POST"]),
    ]
)

实战对比：MCP vs Function Calling

我做了个简单测试，用同一个天气工具：

实际场景：我们团队有个内部知识库查询工具，之前用Function Calling给GPT用，后来想接Claude，重写了两天。换成MCP后，工具代码一行没改，只在Agent侧换了Client实现，半小时搞定。

商业价值：这不只是技术优化

1. 降低多模型切换成本：今天用GPT，明天换龙虾模型，工具层完全不用动
2. 工具市场标准化：可以像npm/pip一样发布MCP工具包，别人直接用
3. 私有协议兼容：把内部API包装成MCP Server，对外就是标准接口

我们有个客户做电商客服Agent，需要对接十几个内部系统（订单、库存、CRM）。之前每个系统一套接口，Agent代码臃肿不堪。用MCP重构后，每个系统变成一个MCP Server，Agent只管调用，维护成本降了70%。

下一步行动

1. 立即试水：把上面的天气工具代码跑通，10分钟就能看到效果
2. 改造现有工具：挑一个你正在用的API，包装成MCP Server
3. 加入生态：去龙虾官网(yitb.com)的MCP工具市场看看，已经有现成的数据库、搜索引擎工具包

关键提醒：MCP还在快速迭代，协议版本要锁定。我用的是2024-11-05版本，生产环境建议固定版本号，别用latest。

想深入交流MCP踩坑经验，或者需要具体场景的代码示例，直接去龙虾官网的开发者社区发帖，我都在。