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 来实现需要的功能。

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

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

2 个赞