测试内容
工具:Dify + Ollama
内容:简单地图的天气 MCP Server 调用
- 高德地图
- 百度地图
(腾讯地图因无法返回内容被踢出了测试)
大模型:
- deepseek-r1:8B(本地)
- qwen3:8B(本地)
- qwen3:14B(硅基流动)
- qwen3:32B(硅基流动)
- qwen2.5:14B(硅基流动)
- qwen2.5:32B(硅基流动)
- llama3:8B(本地)
- deepseek-chat(Deepseek 官方)
测试结果
高德地图
高德地图需要的内容比较简单,把城市名包裹在 city 里即可。
json
{"map_weather": { "city": "深圳" }}
返回的内容也比较简单:
json
{
"map_weather":
{
"city": "深圳",
"forecasts": [
{
date: '2025-7-24',
... // 这里是具体的数据
},
... // 其他日期的数据
]
}
}
10B 以下的模型
7月20日初次尝试 10B 以下本地大模型模型全军覆没。
- deepseek-r1:8B-发送错误。无法完成测试。
- Qwen3:8B-发送错误,推理啰嗦,多次纠正无果
- llama3.1:8B-发送正常,读取错误
几天后,7月24日再次尝试之后,所有模型都成功发送。好像是高德做了兼容,直接传城市名称也可以,更容易使用,当然也导致大模型容易蒙混过去了:
json
{"map_weather": "深圳"}
- deepseek-r1:8B-显示的结果跟 mcp 返回的完全不一致。
- Qwen3:8B-多次尝试,最后显示正常,但是有一次突然中断了。
- llama3:8B-依然无法解析返回的内容。

本地 deepseek-r1 传送格式及返回,信息错误,基本的昨天今天明天的时间都错了。

Qwen3 查询格式及返回,查询一次,失败中断,第二次后,正常了,但结果有今天和明天,今天只取了白天天气,当时已经是晚上。

llama 传输正常,但是结果无法解析。
14B 模型
14B 的模型,使用了硅基流动的api。由于平台缺少 llama3.1,所以后续不再测。 整体表现虽然好点。但是也有不少问题
- deepseek 依然传着最简单参数形式
{"map_weather": "深圳"}
,还是有蒙混过关的可能。回答中没区分白天与夜晚的天气,晚上的中雨没显示出来。 - Qwen3 回答正常,还添加了雷雨天注意事项。表现已经相当好了。
30B 以上的模型
- deepseek:32B 发送的参数正确了,只是跟14B返回结果一致,晚上的天气情况没显示出来。另外表现不稳定,中间突然飙英文出来。
- Qwen3-30B-A3B 和 Qwen-32B 表现差不多,开始出现 emoji。排版更舒服。
- 满血版的 deepseek 和 Qwen3 自然不在话下。
百度地图
百度地图有两个参数可以选。要么选择地区码:
json
{"map_weather": { "district_id": "440200" }}
要么选择经纬度:
json
{"map_weather": { "location": "113.3667,22.5667" }}
数据返回结构更复杂:
json
{
"map_weather":
{
"status": "0",
"result":
{
"location": {}, //地点
"now": // 实时天气预报
{
"temp": '27',
"uptime": "20250724221500", //更新时间
... // 这里是具体的数据
},
"indexes": [], // 各种指数
"alerts": [], // 警报
"forecasts": [], // 一周天气
"forecast_hours": [] // 小时天气
}
}
}
10B以下大模型
- deepseek-r1:8B-发送错误。无法完成测试。district_id 理解成了区的id。
- Qwen3:8B-发送错误,推理啰嗦,多次纠正无果。
- llama3.1:8B-发送正常,读取错误

本地 deepseek-r1,无法完成

本地 Qwen3 两次调整之后获取了正常的返回。

但是 Qwen3 却对结果无法解析,口吐鸡肠,阵亡。
llama3.1 跟高德地图返回一样,解析阶段陷入了死循环,也未能完成任务。
14B 模型
- deepseek-r1 输入错误,失败
- Qwen3:14B 表现不错,指数也解析出来了,还带上温馨提醒。

30B 以上的模型
- deepseek:32B 经过两次思考,输入正确,但是回答过于简单,只把now 的部分解析出来了。
- Qwen-32B 表现不错,将高温预警也解析出来了。
- 满血版的 deepseek 和 Qwen3 跟调用高德地图 mcp 的一样,表现优秀。

大模型版本问题
由上面几次测试可以判断,MCP 主要考验大模型对 Json 的处理能力。之前就有报道,OpenAI 也是花了 1-2 代才解决 Json 输出输入稳定性。
于是为了测试是否有代际问题,选了 Qwen 来做第二轮测试。 结果正如所想的,Qwen3 明显要好于 Qwen2.5。
- Qwen3 的 14B 已经有不错的表现了。
- Qwen2.5 的 32B 对返回的内容解读还是有点勉强。
看来 deepseek 非满血版的确是基于 Qwen2.5 的蒸馏而来,两者的表现基本一致。
总结
- 对 MCP 处理能力基于模型对 JSON 的处理能力。
- 模型对 JSON 的处理能力跟参数大小相关,但跟模型大小相关性更强。
- 最新小参数模型能处理好 MCP 的输入,但是 MCP 如果返回大量的数据,只有大参数模型才能处理好。
- 后面能不能出现小参数模型有更好的 JSON 解读能力,也许能优化,也许已经是目前的极限了。
如果要在本地实践 MCP,至少也要选择 Qwen3-14B 这种规模的模型,因此配置 32GB 内存的 Win 或 16G 内存的 Mac 勉强能用。
如果从效率出发,选择第三方可能是更好的选择。
价格问题
用第三方就要涉及价格问题了。
以下是某平台的价格对比。

可以看到,8B 模型在第三方平台上是免费的,因为它能做的事情真的非常有限,14B开始收费,还不便宜,即使是百万 Token 的费用,正规项目经过几轮测试下来,也要花不少钱。
这样看来要做 MCP 开发,费用是必不可少了。
本次测试就用了 0.47 元。
希望这5毛,能给大家带来一些帮助吧。