emacser 加油啊,隔壁 vim 也可以接 MCP 了

1 个赞

我还是没搞懂 mcp 到底在试图解决什么问题。

目前看起来, 大概的思路似乎是把 AI 模型能够使用的工具和模型的使用者写请求本身分离开来?模型的使用者不需要具体实现模型够说明使用的工具的逻辑,而这些工具由 MCP 的 server 来提供,而模型的调用者只需要连接上一个 MCP server,就可以使用 MCP server 定义的全部工具?

我个人感觉这个 MCP 对于交互类的用户 APP 可能比较有用,比如说 claude-desktop 是一个 GUI 软件,那么这个 GUI 软件必然不可能让用户自己去写 tool-use 的 json schema 和 具体函数的实现逻辑。相反提供一个通用的 MCP server 接口,这样用户就可以拿 claude-desktop 直接去对接任意的 MCP 从而让模型调用任意的工具。

但是对自己写代码开发应用的情况来说,我假设你的应用的场景下需要调用的工具是明确的,那可调用函数的逻辑本身自己写就好了 (除非你的 app 有对接任意外部 MCP 执行任意未知函数的需求),直接传 tool-use 的 json schema 感觉也并不麻烦。这样 MCP 我暂时不是很清楚有什么特别的作用?

欢迎大家指正我的观点,提供额外的见解。

4 个赞

好像已经有人写了一个 GitHub - lizqwerscott/mcp.el: An Mcp client inside Emacs

哪位懂行的看看给大家介绍介绍?

1 个赞

当时刚出的时候我研究了一下,实在感觉是为了用新铲子而挖了个坑,甚至Claude Desktop的MCP我都关了

3 个赞

其实 MCP 协议背后的命题是,最适合 AI 的场景是什么?

目前其实还在寻找当中,MCP 的想法是,文本编辑器是最适合 AI 的场景,所以需要拓宽文本编辑器的业务能力。

但在这个基础上,需要保证数据的私密性与安全性,才可能被人大规模使用,否则 AI 口无遮拦,会损害到使用方的利益。

mcp 其实就是提供了一个统一的接口来实现人工智能系统与数据源之间碎片化集成。类似 Language Server Protocol

但是对自己写代码开发应用的情况来说,我假设你的应用的场景下需要调用的工具是明确的

可以复用已经实现这个工具的 mcp server 来实现需要的功能。

2 个赞

给编辑器用的通用agent框架,方便往里面补function call

ai工具起名一套一套的,很唬人

3 个赞

我原来一直对这两个概念比较模糊,所以 mcp 和 function/tool calling 的区别就是一个生态的不同角色是吗?function calling各家LLM自己定义,接口不一;mcp作为中间商,统一定义一个标准。所以mcp的支持是谁给的,LLM provider吗?要让一个provider(比如deepseek)支持mcp,是不是既要让这个provider提供function calling的支持,也要提供mcp的支持,还是mcp的支持不用provider本身提供?

这个其实就像是 LSP protocol / client / server 之间的关系一样。

比如 LSP 定义了一套 completion 的规范,然后 LSP client 要把 LSP server 发送回来的 completion candidates 转换为 editor 自身对应的补全项,在 emacs 上就是要实现一个相对应的 completion-at-point-function。

MCP protocol 定义了一套工具调用的 specification,然后 MCP server 会按照这套 specification 去提供 API。MCP client 则负责完成和 LLM 模型本身的适配工作。

具体地说,MCP client 需要完成如下的工作:对接工具包如 gptel 或者 llm,生成对应的 json schema (如果模型支持 tool use 的话),以及将 MCP server / 工具包之间交换输出的工作。如果模型不支持 tool use 调用,也可以通过 prompt injection 告诉 LLM 有什么工具可以调用,然后再解析模型的自然语言输出并转换为调用 MCP server 的 json schema(当然这么做感觉就走远了)。模型本身可以对 MCP 一无所知。

1 个赞