大家在刚接触DeepSeek这类大模型的时候，可能会以为它是一个全知全能的工具，所以我们自然而然地可能就想问它一些关于生活的话题，比如"今天南京的天气如何"。
但我们知道，DeepSeek是用过去已知的知识训练完毕的大模型，它并不能及时获取或更新相关数据。当然，如果你勾选联网搜索，是有可能查询到最近的一些信息的。然而对于时效性很强的信息，它大概率不清楚，甚至DeepSeek可能会胡编乱造南京的天气情况------这种现象就是模型的幻觉。
那么，有没有什么方法能够获取到我们想要的信息呢？在MCP技术概念提出之前，大家通常采用本地的Function Call（函数式调用）方式实现这一目的。
具体流程是：服务提供商会先在本地搭载一个程序，其中编写天气查询的服务函数。当你向DeepSeek提问时，需要将这个本地函数一起注册给DeepSeek。
DeepSeek通过交流和你提供的已注册函数集合，会判断是否触发其中某些函数。如果发现你的问题恰好与某函数相关，就会触发对应函数并执行，获取结果。由于程序返回的结果可读性较差，DeepSeek会对其润色后再返回给我们。
我们可以用代码演示这个流程，我们可以使用之前介绍过的硅基流动的DeepSeek接口：包教包会！5分钟快速对接DeepSeek，完全免费！。
首先定义相关函数，比如这里定义了一个get_current_weather函数，它会接收地点参数并返回对应天气（为简化演示，这里返回固定结果，实际可对接真实天气服务）。
python
def get_current_weather(location: str, unit: str = "摄氏度"): """获取指定地点的当前天气信息
参数: 地点 (str): 城市名称，例如："北京" 温度单位 (str): 温度单位，可选"摄氏度"或"华氏度"
返回: dict: 包含天气信息的字典 """ weather_data = { "location": location, "temperature": "25", "unit": unit, "forecast": "sunny", "humidity": 65, } return weather_data当用户提问"南京今天的天气如何"时，需要同时将函数说明（包含名称、描述、参数）注册到会话信息中。这样DeepSeek就能从提问中提取"南京"作为参数。
提交后，DeepSeek会返回触发的函数名称和参数，我们本地执行函数后将结果再提交给DeepSeek润色，最终得到可读性强的回复："南京今天天气晴朗，温度25℃，湿度65%，较为舒适，适合外出。"这就是函数调用的具象化体现。
但这种方式存在一个问题：函数执行必须由本地完成。那么能否让远程服务商代为执行呢？这就是MCP技术的作用。
MCP全称Model Context Protocol（模型上下文协议），本质上是一个开放式协议。只要服务商按协议规则编写代码，就能形成各种MCP服务。配置服务列表后，DeepSeek在会话中就能自动调用对应服务（如查询天气、订火车票、查股票等）。如果MCP服务足够多，大模型几乎能帮我们完成任何事情。
MCP协议由Anthropic公司（开发Claude.ai的团队）于2023年提出，旨在通过标准化协议实现AI与外部服务的动态交互，突破传统函数调用的机械性。
GitHub上MCP官方列出的服务已覆盖数据库查询、代码调试、3D建模、企业ERP、智能家居等多个领域。
我们也可以根据官方文档在本地启动天气服务：配置环境后创建weather.py服务文件，用mcp.tool装饰器注册天气函数即可。启动服务后，在Claude Desktop的开发者模式中配置MCP服务，聊天界面会出现小锤子图标显示已注册的工具函数。
接着我们可以向他提问，询问某一个地点的天气。这个时候大模型会发现，我们的聊天可能触及到了某个MCP服务中的函数。
接着大模型就会调用对应的函数并且获取到对应的返回结果。跟我们刚才演示的函数式调用的代码逻辑相同，大模型也会将这个返回结果加以润色。
但由于这个天气预报的服务只能够查询美国的天气，所以呢，我在这里询问南京的天气如何，这里就无法调用对应的MCP的服务了。
MCP的概念最早起源于国外的公司，因此啊，这阵风还没有完全吹到国内来，所以目前更多的应用呢只能基于Claude Desktop进行执行。但是目前，众多开源技术社区已经加大了对MCP服务的支持，其中最活跃的GLAMA开源社区中已有361个MCP服务。相信在不远的将来，我们就可以在DeepSeek中使用到众多便捷的MCP服务工具。