北京
一个MCP演示看起来很酷：“这是所有端点，这是所有数据库表，这是所有内部操作，现在智能体什么都能调用了。”
头十分钟确实让人感觉强大无比。然后模型开始调用错误的工具，把正确的参数填进了不匹配的格式，用搜索端点去要图表，重试了一个破坏性的操作，或者因为工具名称模糊到能表达三种不同意思，自信满满地返回了一个答案。
毛病不出在MCP本身。问题在于把MCP当成后端的一层魔法适配器。
MCP服务器不是“让智能体能访问我的API”那么简单。它是一个产品交互面，服务的用户极为字面化、极容易分心。而这个用户恰好是个语言模型。
最常见的坑，就是一个端点对应一个工具。GET /users/:id 变成 get_user，GET /users 变成 list_users，GET /invoices/:id 变成 get_invoice，POST /reports 变成 create_report，这样一路列下去。看着干净，因为完美复刻了API结构。但对智能体来说，这往往是个糟糕的设计。
人类能读文档、理解产品语境、在相似路由之间做出选择。模型并不真正“理解”你的产品。它做的事是模式匹配，匹配的是名称、描述、schema、历史消息，以及上下文窗口里还能塞得下的那些东西。
如果你给了模型40个长得差不多的工具，你给的不是能力，是40种“差点就对了”的错误方式。
在给FXMacroData搭建MCP层的时候，这个教训变得非常直观。后端正常的API路由覆盖了日历事件、外汇对、利率、COT持仓、大宗商品、债券收益率、元数据和文档。把每条路由都镜像进MCP，看起来够全面，但会让智能体在一堆似是而非的选项里反复纠结。
真正有用的MCP边界反而小得多：市场摘要一个工具，发布日历一个工具，外汇对快照一个工具，可图表化的指标历史一个工具，COT持仓一个工具，大宗商品一个工具，债券收益率一个工具，数据覆盖和元数据一个工具。
这在演示里显得没那么唬人。但在真实对话里更有用。智能体不再需要判断一个问题该映射到哪个端点、哪个缓存过的仪表盘载荷，还是哪张规范化数据表。它只需要识别用户的意图。
一个API路由说的是：你发这个请求，服务器会响应。
一个MCP工具应该说的是：用我来干这个明确的任务，用这些明确的输入，预期会得到这类结果。这意味着一个好的工具描述不是营销文案，而是给模型用的路由逻辑。
坏的描述：name是 get_data，description是“从API获取数据”。
好的描述：name是 lookup_release_calendar，description是“返回某个币种在某个日期范围内的经济发布事件。在回答关于即将发生的宏观事件之前，先用这个工具”。
即便你不关心金融领域，这个模式也成立。工具就是承诺，是对模型注意力的一种引导，而不是权限清单的粗暴罗列。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
