最近在折腾MCP(Model Context Protocol),看很多教程都把向量数据库(用的Milvus)包成一个MCP Server给Claude用。但我有点懵:如果我的应用本身就能连Milvus,为啥还要非走MCP这一层?多一个HTTP请求不是更慢吗?还是说MCP的价值在于让非技术用户也能通过对话来管理知识库?比如让Claude自己决定该往哪个collection里存向量?我试了试直接把Milvus的Python SDK嵌进MCP tool里,好像也能跑通,但总觉得没get到官方推荐做法的精髓。有没有大佬能解释下,在MCP架构里,向量数据库到底应该是作为tool被调用,还是作为resource被读取?或者两者应用场景有啥区别?有点绕进去了,求指点。
楼主
25天前
MCP Server里直接调向量数据库是不是多此一举?还是我理解错了?
请 登录 后发表回复
全部回复
共 83 条
2楼
2天前
你的疑问我也有过,试下来感觉MCP这层更适合跨应用共享,单机自用确实绕路了。
3楼
2天前
说实话我一开始也有这个疑惑,后来想明白了——MCP那层不是给你自己用的,是给那些不懂代码的终端用户用的。你嵌SDK当然更快,但那等于把逻辑全写死在应用里了,别人想通过自然语言让Claude去查个向量就做不到了。
我试过把Milvus封装成tool之后,Claude能根据对话上下文自己选collection和构造filter,这个灵活性是硬编码比不了的。不过你说的性能问题也确实存在,我现在的做法是内部调用走直连,只有外部对话场景才走MCP,两套并行。
至于resource还是tool,我倾向tool,因为存向量是个动作,不是单纯读数据,你让AI自己决定怎么操作比给它一堆数据更可控。
4楼
1天前
说实话我一开始也有这个疑惑,后来想通了:MCP的核心价值不是帮你省掉那层HTTP调用,而是把Milvus的能力抽象成Claude能理解的“动作”。你直接嵌SDK当然跑得通,但那就把知识库的访问逻辑写死在代码里了,换个模型或者改个流程又得重来。
我觉得官方推荐的做法是让MCP Server做“翻译层”,把复杂的collection管理、向量检索这些操作封装成自然语言指令,这样Claude就能自己判断该查哪个集合,甚至根据对话内容动态决定存哪。你本地调SDK是给程序用,MCP是给AI用,场景不一样。
不过Milvus这种重服务挂HTTP确实有点性能损耗,我试过在MCP里做缓存或者批量操作来缓解,但如果你只是自己脚本里用,直接连也完全没问题。关键看你是想给“人”写工具,还是给“AI”写工具。