将『大语言模型』（LLM）与外部工具连接，是扩展其能力的主流方法。通过给模型提供工具，它就能查询数据、调用 API，完成更复杂的任务。
提供工具时，可以使用 MCP 模式，简单来说：由一个外部的、集中的工具服务来提供所有工具，开发者写的应用直接调用这个服务，让它去和模型沟通。
这样做表面上简化了开发，开发者不用自己管理工具了。但问题也恰恰出在这里：应用的开发者，失去了对模型上下文的精确控制权。
这是一个根本性的问题，会引发一连串的麻烦。
一个具体的例子：MCP 架构
我们来看看 MCP（Model Context Protocol）这个框架的实现方式。它清楚地展示了这种分离模式。
在 MCP 的世界里，开发者分为两类：
Server 开发者：他们负责创建工具。
Client 开发者：他们负责写真正面向用户的应用，并调用 Server 提供的工具。
这就是我们要讨论的核心风险。
1. 控制权交给了别人
AI 应用的核心，是开发者与大模型之间的交互。开发者应该精确地告诉模型在当前场景下，它能做什么。
在上面的例子中，Client 开发者完全放弃了这种控制。如果 weather-server 的开发者某天在『服务器』上增加了一个新工具，或者修改了 get_alerts 工具的描述，所有使用这个 Server 的 Client 应用，都会在不知情的情况下立刻受到影响。
2. 浪费了宝贵的上下文
大模型的 “上下文窗口” 是有限且有成本的。
MCP 官方的示例中，就罗列了大量的 “即插即用” 型 Server，比如 Filesystem、Git、PostgreSQL。一个 Client 应用可能会连接多个 Server。
想象一下，你的应用只是想问个天气，但因为连接了多个 Server，list_tools () 可能会返回十几个不相关的工具（比如文件读写、数据库查询等）。这些多余的工具定义会被全部发送给大模型，不仅增加了推理成本和时间，还会像噪音一样干扰模型，让它难以选择正确的工具。
3. 工具的质量无法保证
工具的名称和描述对模型能否正确使用至关重要。最了解应用需要什么样工具的人，是 Client 开发者自己。
但是，在 MCP 模式下，Client 开发者无法修改 Server 提供的工具描述。如果 Server 的工具描述写得含糊不清（比如一个叫 process_data 的函数），Client 开发者要么只能忍受，要么就得放弃使用整个 Server。他失去了根据自己业务场景，“精雕细琢” 工具描述的能力。
4. 安全性和稳定性的风险
这是最严重的问题。由于 Client 开发者无法控制工具集，应用的安全和稳定就依赖于外部的 Server。
以 mcp-server-filesystem 这个官方工具为例，它能执行文件操作。如果一个 Client 应用连接了它，就等于把文件操作的潜力暴露给了大模型。Client 开发者必须完全信任这个 Server 的实现是绝对安全、没有漏洞的。
如果 Server 的开发者在一次更新中，不小心引入了一个允许删除任意文件的 Bug，那么所有连接到这个 Server 的 Client 应用，都可能在用户不知情的情况下，执行危险的操作。这种风险是灾难性的。
