微信扫码
添加专属顾问
我要投稿
探索MCP插件协议的神秘面纱,一窥Agent应用的扩展新天地。 核心内容: 1. MCP协议的初步理解与应用场景 2. MCP与LLM工具使用协议的关系解析 3. 实际代码示例,揭示MCP调用与工具调用的结合
我个人之前对MCP并不是很关心,最近与人讨论稍微研究了一下这方面。但并不算深入,也没有翻太多源码,所以本文的观点将来可能会被推翻。但只要这篇文章还在,就表示我的观点没有被推翻。
MCP是一种Agent应用的插件协议,而且这个插件更偏工具性质,不能大幅的覆盖原有Agent的功能和设定,更多是给它新增一些tools。
它本质上并不是LLM tool use协议的替代,官方demo的例子就是把MCP的调用转换为了LLM的tool调用给LLM模型,以下代码来自 https://modelcontextprotocol.io/quickstart/client
async def process_query(self, query: str) -> str: """Process a query using Claude and available tools""" messages = [ { "role": "user", "content": query } ] response = await self.session.list_tools() available_tools = [{ "name": tool.name, "description": tool.description, "input_schema": tool.inputSchema } for tool in response.tools] # Initial Claude API call response = self.anthropic.messages.create( model="claude-3-5-sonnet-20241022", max_tokens=1000, messages=messages, tools=available_tools ) # Process response and handle tool calls final_text = [] assistant_message_content = [] for content in response.content: if content.type == 'text': final_text.append(content.text) assistant_message_content.append(content) elif content.type == 'tool_use': tool_name = content.name tool_args = content.input # Execute tool call result = await self.session.call_tool(tool_name, tool_args) final_text.append(f"[Calling tool {tool_name} with args {tool_args}]") assistant_message_content.append(content) messages.append({ "role": "assistant", "content": assistant_message_content }) messages.append({ "role": "user", "content": [ { "type": "tool_result", "tool_use_id": content.id, "content": result.content } ] }) # Get next response from Claude response = self.anthropic.messages.create( model="claude-3-5-sonnet-20241022", max_tokens=1000, messages=messages, tools=available_tools ) final_text.append(response.content[0].text) return "\n".join(final_text)这段代码就已经很清楚了,再结合该文档前面的链接建立,感觉就是个很典型的插件模式。
MCP体系的命名是挺糟糕的:MCP Server是工具提供方,MCP client是Agent应用。
MCP本来是为Claude的App端与用户本地PC资源和Context进行交互而设计的,后来协议也在逐步往跨机器通讯来扩展。
MCP协议其实与LLM并不绑定,获取了tool之后如果是硬编码匹配tool函数名进行调用其实也没问题,这样就完全没有LLM参与了。只是实际使用中,肯定是希望避免对于具体插件的硬编码,这样就需要结合tool的描述来进行使用,所以就需要LLM的语义理解、推理能力、知识等。
这可以看成是传统软件开发中依赖注入(Dependency Injection)的一个实例,只不过真的想要实现注入工具的自动适配,需要有LLM的能力才能有效的使用。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-06-21
使用 LangSmith 进行 RAG 评估:构建生产级 RAG 系统的 AI 开发者指南
2026-06-20
RAG 投毒的六个影响因素与防御框架
2026-06-20
RAG 性能暴涨 5.9 倍!微软新框架让 LLM 自主检索,无需训练直接部署
2026-06-19
RAGular:适合知识库体质的 OCR 助手
2026-06-18
阿里扔出「向量版 SQLite」!十亿级向量毫秒检索,一行 pip install 搞定,本地 RAG 的游戏规则变了
2026-06-18
一个月拿下1500star,只因我们比MinerU多做了这件事
2026-06-18
为 1000 万+ 文档构建近零幻觉的 RAG Pipeline
2026-06-17
微软推出企业级 AgenticRAG!四个工具助力RAG新范式落地
2026-04-06
2026-04-27
2026-04-02
2026-03-31
2026-04-23
2026-04-20
2026-04-09
2026-04-12
2026-04-22
2026-04-10
2026-06-15
2026-06-10
2026-06-10
2026-05-20
2026-05-18
2026-05-11
2026-05-07
2026-05-06