【MCP】详细了解MCP协议:和function call的区别何在?如何使用MCP?

【MCP】详细了解MCP协议:和function call的区别何在?如何使用MCP?

本文介绍了MCP大模型上下文协议的的概念,并对比了MCP协议和function call的区别,同时用python sdk为例介绍了mcp的使用方式。

1. 什么是MCP?

官网:https://modelcontextprotocol.io/introduction

2025年,Anthropic提出了MCP协议。MCP全称为Model Context Protocol,翻译过来是大模型上下文协议。这个协议的主要为AI大模型和外部工具(比如让AI去查询信息,或者让AI操作本地文件)之间的交互提供了一个统一的处理协议。我们常用的USB TypeC接口(USB-C)统一了USB接口的样式,MCP协议就好比AI大模型中的USB-C,统一了大模型与工具的对接方式。

MCP协议采用了C/S架构,也就是服务端、客户端架构,能支持在客户端设备上调用远程Server提供的服务,同时也支持stdio流式传输模式,也就是在客户端本地启动mcp服务端。只需要在配置文件中新增MCP服务端,就能用上这个MCP服务器提供的各种工具,大大提高了大模型使用外部工具的便捷性。

image.png

MCP是开源协议,能让所有AI厂商、AI工具都将MCP集成到自己的客户端中,从而扩大MCP的可用面。毕竟只有用的人越多,协议才能不断发展,不断变得更好。

2. 了解function call

在MCP没有出来之前,我们的AI Agent开发如果想调用外部工具需要针对不同的AI大模型SDK编写不同的代码,其中最为常用的是openai提供的function call的处理逻辑。

本小节参考博客:

2.1. function call demo

2.1.1. 配置工具,AI提供参数

当我们调用 OpenAI Chat Completions 接口时,可以通过tools参数传入可供使用的外部工具。这个工具的调用中就包含了工具的作用,工具需要传入的参数,以及参数的释义。其中tool_choice字段设置为auto代表让大模型自动选择tools,设置为none时不会调用外部工具。

{ "tool_choice":"auto","messages":[{ "role":"system","content":"你是一个天气查询助手"},{ "role":"user","content":"帮我查询上海的天气"}],"tools":[{ "type":"function","function":{ "name":"get_weather","description":"获取指定城市的天气","parameters":{ "type":"object","properties":{ "city":{ "type":"string","description":"城市名"}},"required":["city"],}}}]}

对应的python openai代码如下,我们将tools部分放入一个包含dict的list,作为create函数的tools参数即可。同时tool_choice传入auto代表自动选择工具。这里我用了硅基流动提供的Qwen2.5模型作为演示,运行下面这个代码需要修改api_key为正确值。

import openai # 1.75.0import json # 后续会用到jsondefmain(): client = openai.OpenAI( api_key="xxxxx", base_url="https://api.siliconflow.cn/v1") tools =[{ "type":"function","function":{ "name":"get_weather","description":"获取指定城市的天气","parameters":{ "type":"object","properties":{ "city":{ "type":"string","description":"城市名"}},"required":["city"],}}}] res = client.chat.completions.create(model="Qwen/Qwen2.5-32B-Instruct", messages=[{ "role":"system","content":"你是一个天气查询助手"},{ "role":"user","content":"帮我查询上海的天气"}], tools=tools, tool_choice="auto")print("content:",res.choices[0].message.content)print("tools:",res.choices[0].message.tool_calls)print("message:", res.choices[0].message.to_dict())

运行程序,发出请求后,大模型就会根据用户提出的问题和提供的tools,来为这个tools编写需要提供的参数。此时content会是空,不会输出内容,tool_calls中会包含调用的工具和参数。

❯ uv run main.py content: tools: [ChatCompletionMessageToolCall(id='01964be6e485603d6a2a0acbbc7eba91', function=Function(arguments='{"city": "上海"}', name='get_weather'), type='function')] message: {'content': '', 'role': 'assistant', 'tool_calls': [{'id': '01964be6e485603d6a2a0acbbc7eba91', 'function': {'arguments': '{"city": "上海"}', 'name': 'get_weather'}, 'type': 'function'}]} 

对应如下json格式响应,包含了我们的参数

"message":{ "role":"assistant","content":"","tool_calls":[{ "id":"01964be6e485603d6a2a0acbbc7eba91","type":"function","function":{ "name":"get_weather","arguments":"{\n \"city\": \"上海\"\n}"}}]}
2.1.2. 调用工具并让AI二次处理

随后,我们就可以根据这个大模型返回的参数来调用我们的函数,并得到函数的返回结果,再次与大模型进行对话。此时需要按下面的方式维护对话上下文,首先需要将第一次请求AI返回的结果插入到上下文中("role": "assistant"的json字符串),然后再插入工具调用的数据,格式如下:

{ "role":"tool",

Read more

【仿Mudou库one thread per loop式并发服务器实现】服务器边缘测试+性能测试

【仿Mudou库one thread per loop式并发服务器实现】服务器边缘测试+性能测试

服务器边缘测试+性能测试 * 1. 长连接连续请求测试 * 2. 超时连接释放测试1 * 3. 超时连接释放测试2 * 4. 超时连接释放测试3 * 5. 数据中多条请求处理测试 * 6. PUT大文件上传测试 * 7. 服务器性能测试 #include"httpserver.hpp"#defineWWWROOT"./wwwroot" std::string RequestStr(const HttpRequest &req){ std::stringstream ss; ss << req._method <<" "<< req._path <<

By Ne0inhk
【Linux系统编程】(四十二)吃透线程互斥!从原理到实战,手把手教你玩转 Linux 下的互斥锁

【Linux系统编程】(四十二)吃透线程互斥!从原理到实战,手把手教你玩转 Linux 下的互斥锁

目录 前言 一、线程互斥的核心概念:搞懂这些,才算入门 1.1 共享资源与临界资源 1.2 临界区 1.3 互斥的定义 1.4 原子性:互斥的底层要求 二、多线程共享资源的坑:亲眼看看问题出在哪 2.1 问题代码:未加互斥的售票系统 2.2 编译运行与异常结果 2.3 问题根源:三步分析 (1)线程调度的随机性 (2)耗时操作放大了竞争问题 (3)ticket--本身不是原子操作 2.4 解决问题的核心要求 三、Linux 下的互斥量:mutex 的使用全解析 3.1 互斥量的类型与核心接口

By Ne0inhk
【linux】高级IO,以ET模式运行的epoll版本的TCP服务器实现reactor反应堆

【linux】高级IO,以ET模式运行的epoll版本的TCP服务器实现reactor反应堆

小编个人主页详情<—请点击 小编个人gitee代码仓库<—请点击 linux系统编程专栏<—请点击 linux网络编程专栏<—请点击 倘若命中无此运,孤身亦可登昆仑,送给屏幕面前的读者朋友们和小编自己! 目录 * 前言 * 一、前置知识 * 二、第一阶段,基本框架的实现 * Connection * Main.cc * TcpServer * 测试 * 三、第二阶段,引入业务协议 * TcpServer * Main.cc * TcpServer * 测试 * 四、拓展 * 五、写博客一年的总结 * 六、源代码 * ClientCal.cc * Comm.hpp * Epoller.hpp * Log.hpp * Main.

By Ne0inhk
Flutter 组件 cleany 适配鸿蒙 HarmonyOS 实战:自动化清理矩阵,构建复杂应用的状态闭环与资源防腐架构

Flutter 组件 cleany 适配鸿蒙 HarmonyOS 实战:自动化清理矩阵,构建复杂应用的状态闭环与资源防腐架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 cleany 适配鸿蒙 HarmonyOS 实战:自动化清理矩阵,构建复杂应用的状态闭环与资源防腐架构 前言 在鸿蒙(OpenHarmony)生态迈向多任务并行、长周期驻留及高频账户流转的全场景办公与生活背景下,如何确保应用在退出登录、环境切换或异常恢复时能够“不留痕迹”地销毁脏数据,已成为衡量应用健壮性的核心指标。在鸿蒙设备这类强调分布式沙箱隔离与严苛内存占用(Resident Set Size)管控的环境下,如果应用缺乏统一的资源清理机制,由于由于散落在各处的 Stream 监听、本地缓存及内存单例,极易由于由于状态残留导致不同用户间的数据越权或 UI 状态的逻辑死锁。 我们需要一种能够集中注册清理任务、支持并发异步销毁且具备原子性执行保障的状态复位框架。 cleany 为 Flutter 开发者引入了极其暴力且高效的“全域清算”范式。它通过中心化的管理器(Manager),允许各个业务模块在初始化时注册其对应的资源回收钩子。在适

By Ne0inhk