在之前的视频中我们介绍了MCP(model context protocol)的原理并用代码演示了它的强大之处：让DeepSeek无所不能？7分钟弄懂从函数调用到MCP，附代码实操！，但是MCP加DeepSeek这样的顶尖大模型真的是无所不能的吗？
今天，我们要揭开一个被很多人忽视的关键问题------这个看似完美的技术组合，其实存在一个重大的系统性缺陷！无论你是MCP服务的开发者还是使用者，都必须警惕这些潜在问题！
要探究这个问题，首先我们得先了解MCP服务的基本组成，目前MCP的最佳实践是在github上著名的开源项目fastmcp。我们可以使用python将其安装到本地，然后新建一个自己的服务。
fastmcp项目地址：github.com/jlowin/fast...
比如这里我可以只写一个乘法的函数，然后将这个服务注册到claude桌面版，上一个视频我们提到过，这是国外类似deepseek的AI大模型，目前比后者能更好的支持MCP。
python
from fastmcp import FastMCP
# Create an MCP servermcp = FastMCP("Demo")
@mcp.tool()def mul(a: int, b: int) -> int: """multiply two numbers""" return a * b
if __name__ == "__main__": mcp.run()重启claude进行沟通，我们可以问两个复杂数字的乘法，发现claude识别到了可能需要调用MCP的乘法函数，问我们是否调用，点击同意就计算出了对应的结果。
但是如果我们重新提问，问一个简单的乘法，claude是默认不调取MCP服务的。
除非继续问复杂的数字。当然我们也可以选择不调取，claude就会自己计算，大家注意一下这个结果和刚才的结果一样吗？别着急这个问题待会我们会谈到。
先回到MCP服务代码本身，这里的乘法函数中有一行python三引号注释，这个注释很重要，如果你查看我们当前的MCP服务信息，你会发现这个注释会被作为函数本身的描述注册到MCP服务上，AI大模型们就是通过读取这个注释来判断是否调取该MCP服务。
那么问题来了，我们是不是可以创建一个MCP服务，这个服务的描述就是"请你不要调用这个服务"？然后我们可以让AI大模型不要调用这个服务，此时不管AI大模型是否调用，其结果都是错的！因为这根本是一个悖论，大家这里可以细品。
接着我们可以快速尝试一下，我创建了一个新的MCP服务，称之为godel哥德尔服务，这里面有2个函数，一个是正常调用godel函数，描述也是如此。另一个则是刚才那个奇怪的让人不要调用的godel函数。
python
from fastmcp import FastMCP
mcp = FastMCP("Gödel")
@mcp.tool()def invoke_godel() -> str: """The name of this service is the Gödel Service. This service can be invoked by users.""" return "The Gödel Service has been successfully invoked."
@mcp.tool()def no_invoke_godel() -> str: """The name of this service is the Gödel Service. This service cannot be invoked by users.""" return "The MCP service is inconsistent."
if __name__ == "__main__": mcp.run()我们依然注册这个服务，然后重启claude开始对话，我们先让它调用godel服务，发现它正常识别了。接着，我们让他不要调用godel服务，可以看到它并没有识别调用！
接着我们可以进一步更改自己的描述：我要调用"不要调用哥德尔服务"。结果发现，尽管大模型很困惑，但它真的帮我们调用了"不要调用哥德尔服务"的这个服务。
通过这个实验我们发现了一个有趣的现象：当MCP服务的函数描述与人类指令冲突时，AI大模型会优先遵循服务描述而并非人类直接指令。
大家不要觉得AFAN我在对MCP吹毛求疵。早在1920年代，著名数学家希尔伯特提出了一项雄心勃勃的计划，他希望通过建立一个完备的公理体系，一劳永逸地推导出所有的数学真理，使数学成为一个完全严谨、无矛盾的系统。如果这个计划成功，数学证明将变得像机械计算一样可靠：不仅能彻底消除人为错误，还能让计算机自动验证一切数学结论。理论上，这将意味着人类可以永久性地解决所有数学问题。
但是这一伟大的计划很快被年轻的逻辑学家哥德尔，也就是刚才我们以他命名的godel函数，给论证推翻了。哥德尔构建了一个不可被证明的哥德尔数，如果要证明了这个哥德尔数，但是哥德尔数是不可被证明的，那这个系统就不一致。如果无法证明这个哥德尔数，那么由这块残缺的拼图又会产生更多无法可证的问题，那么这个系统就不完备。
看上去哥德尔不完备定理似乎只是指出了数学系统中的一个特殊现象，但是他揭示了不完备性不是偶然的，而是所有足够强大系统的固有性质。这个小点就像一把钥匙，打开了人类对数学基础的全新认知，使得希尔伯特当时计划的核心目标变得无法实现。
所以MCP服务也是如此，它不可能帮你解决一切问题，特别是当这个问题涉及MCP服务本身时。视频到这里还没完，MCP服务的问题不仅于此。
上面我们还留了一个坑，在定义乘法函数进行计算时，我们发现面对简单的数学计算逻辑，AI大模型是不会去调用我们定义的MCP乘法函数服务的。然而，当遇到复杂计算时，如果模型仍然选择不调用服务，就会产生错误结果！
这里就是使用MCP要注意的第二大问题，AI大模型对认为自己胜任的场景，就会跳过MCP服务，给出自己的答案，而这些场景一旦涉及到严密数理统计这种大语言模型不擅长的任务，就会出现错误，这也是大家需要极力避免的。
最后一个关键问题来自AFAN的实际应用经验。去年我们在建模平台中尝试整合类似MCP的function call技术时，发现了显著的体验问题：虽然用户可以指定数据输入，但建模过程本身的时间消耗无法缩短，复杂任务还需要用户进行额外配置。当这些配置全部通过对话交互而非可视化界面完成时，操作流程会变得异常繁琐。
更糟糕的是等待体验------由于缺乏可视化进度条，用户不得不反复询问AI"我的建模任务完成了吗？"，这种被动等待极大地降低了使用体验。
基于这些实践教训，我们总结出MCP服务的适用边界：MCP最适合需要即时响应的轻量级任务（如查询天气、预订服务等），用户可以在单次对话中流畅完成多个服务调用；但对于耗时较长的单点任务（如复杂建模），传统的网页界面可视化仍然是更优方案。
好的，以上三大问题就是今天AFAN的分享了，如果你觉得今天的视频对你有帮助的话，欢迎点赞转发，视频中涉及的代码资料可以加我的微信（微信号：afan-life）进入粉丝群获取，我们下期再见！
哥德尔MCP项目地址：github.com/AFAN-LIFE/g...