一个常见的错误是直接把现有的 REST API 端点或函数封装成 MCP 工具，「反正功能都实现了，包一层不就行了？
LLM Agent 的上下文窗口（context window）是稀缺资源，而计算机内存是廉价且充裕的。这个根本差异决定了工具设计的方向。
简单例子：在通讯录中搜索联系人。
传统软件可以高效地存储和处理整个联系人列表，逐个检查每条记录。
但如果让 LLM Agent 使用一个返回「所有联系人」的工具，然后逐个 token 地阅读每一条……它就是在用最宝贵的上下文空间处理大量无关信息。
# ❌ 不好：直接暴露底层能力，让 Agent 自己处理 list_contacts() # 返回所有联系人，Agent 需要逐个筛选 get_contact(id) # Agent 需要知道 ID 才能调用# ✅ 好：针对 Agent 的认知模式设计 search_contacts(name="张") # 直接返回匹配结果 message_contact(name="张三") # 内部处理搜索和发送
两个极端
太细粒度：多次调用，浪费 token
太粗粒度：返回大量无关信息，填满上下文。
核心原则：把编排逻辑放在你的代码里，而不是放在 LLM 的上下文窗口里。