MCP学习总结

pur_e

已于 2025-04-02 14:03:27 修改

阅读量810

点赞数 12

分类专栏： AI 文章标签： MCP AI

于 2025-04-02 11:51:58 首次发布

本文链接：https://blog.youkuaiyun.com/pur_e/article/details/146940466

版权

AI 专栏收录该内容

1 篇文章

订阅专栏

一、诞生的背景及历史

各家大模型都有自己的Function Calling的实现方式，与别家不兼容。开发者如果要提供工具，需要适配不同大模型厂商，或者自己根据提示词工程设计一套自有的协议，导致整个工具生态混乱无序，野蛮生长。2024年11月，Claude大模型的开发商——Anthropic提出一个模型上下文协议MCP（Model Context Protocol），意在统一大模型工具的调用协议，提供统一的注册调用、安全认证等协议。

二、定义

MCP（Model Context Protocol）模型上下文协议，用于定义大模型与工具之间的接入规范。其实与IT界早已有的HTTP协议、TCP/IP协议等标准协议类似，其在AI大模型能力调用领域的重要性当然不可否认，但论突破性、独创性则并没有超出以往边界。协议也在快速发展中，日前（24年3月26日）刚将OAuth标准认证协议集成进来。
详细来说，其将能力调用双方定义为MCP Server与MCP Client两类实体，中间辅以资源Resource、工具Tool等资源定义，传输Transfer等流程定义，来构建整个标准规范。其中Server端定义具体的工具，包括其能力描述、能力实现、资源定义，并以规范接口暴露特定功能。Client端则可在与Server端建立连接后，查询工具、资源等，进行调用。具体调用流程如下：

其中工具详细定义如下：

{
  name: string;          // 工具的唯一标识符
  description?: string;  // 人类可读的描述
  inputSchema: {         // 工具参数的 JSON Schema
    type: "object",
    properties: { ... }  // 工具特定的参数
  }
}

官方提供的不同语言的SDK，如python、js等，以python为例，可直接使用装饰器@mcp.tool()来定义工具，将自动解析函数名、函数描述对外暴露。

@mcp.tool()
async def get_alerts(state: str) -> str:
    """获取指定州的天气警报（使用两字母州代码如CA/NY）"""
    url = f"{NWS_API_BASE}/alerts/active/area/{state}"
    data = await make_nws_request(url)

    if not data or "features" not in data:
        return "无法获取警报或未找到警报。"

    if not data["features"]:
        return "该州没有活动警报。"

    alerts = [format_alert(feature) for feature in data["features"]]
    return "\n---\n".join(alerts)

而客户端则可列出所有工具，组装给LLM大模型调用

	# 列出可用工具
    response = await self.session.list_tools()
    tools = response.tools
    print("\n已连接到服务器，可用工具:", [tool.name for tool in tools])
	available_tools = [{
        "name": tool.name,
        "description": tool.description,
        "input_schema": tool.inputSchema
    } for tool in response.tools]

    # 初始 Claude API 调用
    response = self.anthropic.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=1000,
        messages=messages,
        tools=available_tools
    )

LLM大模型会自动在合适的时机返回调用工具，客户端要做的就是解析LLM指令，并实际的调用工具，将返回结果给大模型

for content in response.content:
        if content.type == 'text':
            final_text.append(content.text)
            assistant_message_content.append(content)
        elif content.type == 'tool_use': # 大模型返回需要调用工具
            tool_name = content.name
            tool_args = content.input

            # 实际执行工具调用
            result = await self.session.call_tool(tool_name, tool_args)
            tool_results.append({"call": tool_name, "result": result})
            final_text.append(f"[调用工具 {tool_name}，参数 {tool_args}]")

            assistant_message_content.append(content)
            messages.append({
                "role": "assistant",
                "content": assistant_message_content
            })
            # 组装工具调用结果，返回大模型
            messages.append({
                "role": "user",
                "content": [
                    {
                        "type": "tool_result",
                        "tool_use_id": content.id,
                        "content": result.content
                    }
                ]
            })

            # 获取 Claude 的下一个响应
            response = self.anthropic.messages.create(
                model="claude-3-5-sonnet-20241022",
                max_tokens=1000,
                messages=messages,
                tools=available_tools
            )

            final_text.append(response.content[0].text)

三、与Function Calling和AI Agent对比

MCP的出现毫无疑问会被提及与另外两个概念的区别和联系：Function Calling和AI Agent，其实Function Calling本质就是MCP的前身，只不过以前都是各家忙活各家的，没有统一标准。现在MCP正在建立事实的标准，大厂OpenAI与微软相继宣布支持，其他厂家宣布跟进是迟早的事，而国内知识付费人贩卖焦虑和一大把的自媒体赠流量早就是成熟的产业链，无形中也充当了一把幕后推手：当一个标准人尽皆知，也就变成事实标准了。
而AI Agent，其实对于标准的智能体概念，本来就是大模型和工具生态的交互形成复杂的智能体，MCP的出现无疑会加速生态的构建，使其更加完善。而对于国内的智能体构建平台，无论是Coze、dify、百练，在大模型还不完全具备自主生产级别交付、适应复杂流程的条件下，还是具有一定的生命力。当然，大模型能力迭代一日千里，当真正的AGI出现时，肯定会被革命。不过与那时候真正需要考虑的事情相比又不值一提了。