MCP 是不是已经死了？没人再提这个了

Skill 和 Tool 不是两个层面上的东西吗

我感觉 mcp 像是提供了 api 接口，但 ai 直接拟人化操作了，就好比淘宝提供了商品搜索的 api ，但你让 ai 去比价，它第一步是打开浏览器登录淘宝

MCP 是工具，SKILL 是技能（经验），两个不是替代的关系。

SKILL 和 MCP 完全是两个不同的东西。SKILL 是教 AI 怎么做一个事情，MCP 是给 AI 接入外部资源的工具。

对于开发者来说应该是 MCP is everywhere 了，MCP 已经是很多流程中的依赖了，所以“存在感”降低了。但是如果你打开你的 AI 日志，应该已经是挂了很长一列的 MCP 了。

MCP 是必备品
skill 目前还是可选项

预言一下，MCP 会像当年的 WAP 一样被遗弃，未来会有更多的服务抛弃 MCP 转向 Skill+API

skill 包括 mcp 了

MCP 统一定义了规范，skill 才能更方便的使用。

#4 说的对，Skills 更多用于扩展 AI 的能力，MCP 用于连接外部系统。

现在做的好的 Skill 都带 /srcpits 目录，里面有一堆 py/js 代码，很多 Agent 都有沙箱环境，可以运行这些代码；
那你把 MCP 里的逻辑放到 Skill 的 /scripts 目录里，让 Agent 执行，其实也能实现和 MCP 类似的效果，但就是会浪费很多上下文，浪费 token ，而且很难保证 AI 每次都能乖乖按照预期跑。

MCP 就是把这部分代码实现分离出去，只对 AI 暴露 “调用 XX 工具” 这一个工具，附带参数格式；
AI 只需要发起一次工具调用就能解决问题，最多可能参数有点小错，AI 会根据报错提示自动重试。
（例如，输入地址 “苏州工业园区”，看似正确对吧？其实少了一个 “市” 字，AI 提交了报错就马上改对了）

更何况 “连接到外部系统” 这个诉求 Skill 无法替代，比如通过获取某地区交通情况，你总不能让 AI 开天眼去监控街区吧，这个你用 Skills 去做，也是要通过百度地图 API ，要么 AI 自己写代码，要么 AI 去操纵网页，还不如直接接入百度地图 MCP 。这一点和 #2 说的一样。

mcp 获取数据
skills 处理数据

我觉得 mcp 就是 api + 说明书

我是这么理解的：
MCP：独立的技能/功能点，
SKILL：就像是手册，可以将各种技能/功能组合使用完成一个特定的事。
就好像中式茶艺一样，烧水、洗茶具、泡茶都可以是单独的功能（ MCP ），但因为有中式茶艺这套流程将烧水、洗茶具、泡茶这些功能点穿起来，还可以细化细节，如烧水用什么水，洗茶具用什么方式，泡茶用什么流程。

并没有，天天用，很好用

mcp 是提供数据的

mcp 不就是 api ，没有 api 你怎么获取私域数据

不是的, MCP 其实还在用, SKILL 里面描述的流程, 可能到具体实施的时候还是在 subagent 里面调用了 mcp 工具.

mcp 的重要性不高了，anthropic 自己都不怎么聊他了。

对于用户而言 mcp 普遍浪费 token 不说，最大的矛盾是现在的 llm 实际非常擅长调用 cli 和 api ，和写脚本解决问题，那他这个“ai agent 时代的 usbc”这个 value proposition 就不是特别立的住了（因为对于用户来说他不管你是怎么解决问题的，能解决就行了）。

对于开发而言，mcp 服务因为带上了 context ，调试难度成倍上升，如果不带 context 那和传统 api 也没多大区别，开发者的动力也没那么高，很多服务都是有 mcp ，但不好用（或者永远是 beta ）

另外最后对于 agent 而言，最重要的是 context management ，mcp 相当于是一个隔离层，你的信息过去之后就是隔离的了，不像 cli 还可以 tail 来看 log ，agent 可以自主 debug/recover 状态，同样也是一个 anti pattern for current agent design

最后 skill 是 skill ，mcp 是 mcp 解决的不是一个问题，不要混为一谈

@s1n1an MCP 能做的事情 rest api+skill 难道不能做吗？甚至做的更好，而且已经有 openapi.json 这样的规范了

@msg7086
@emric
虽然看起来是两个层面的东西，但是 skill 是它的一个入口，skill 有更多选择的话，那 MCP 存在感就很低了，而且没有他就一样可以 work, 甚至 work 的更好，比如最近有些人就直接给所有的 electron app 加上了 Cli 的调用支持。

@s1n1an 同感

@JoeJoeJoe 一些现存的 MCP 还通过这种方式来运行，但是基本上没看到新的了。其实 MCP 也很容易被取代，比如一旦他们支持了 API ，那 skill 就可以直接调 API

@maolon 是的，我了解他们不是一个层面上的东西，但是 skill 会很大程度上影响 MCP ，所以我觉得有必要放在这里一起聊。skill 从更高维度去解决了调用外部/内部/甚至调用一切的问题，那 MCP 这个更下一层级的技术的存在感就变得很低了

skill 本身就是个 tool ，也就是个 mcp 协议的东西

有很多数据库的 mcp 可以立马用上，纯 skill 调用还是太麻烦

没有可比性，skill 是告诉 ai 怎么用 mcp

mcp 不是协议吗？？？ skill 只是更具体的边界约束和操作方法描述
难道我一直理解错误？

感觉可以结合一下， 至少应该先解决 mcp 占用上下文的问题，
如果 mcp 也可以只占用一个简短介绍的上下文， 具体子工具到用的适合再加载，然后依然 jsonrpc 调用， 我感觉比 skill+脚本好一些，脚本没有固定格式很看 AI 自己的理解能力，

多看看资料吧你理解的 mcp 错得离谱

mcp 是个标准的协议，实现可以是 web 也可以是 cli ，没有 mcp skill 啥也做不了

不是，感觉这个帖子下的这些回复，到底有没有具体看过什么是 Skill 啊？
居然还有人说没有 Skill 没法掉外部系统？ Skill 里面那么大个脚本目录是看不到吗。
我的理解就是对于绝大部分场景，直接写 Skill 就好了。需要调用第三方服务的直接写脚本处理。

mcp 是向 LLM 提供可调用的 tools 扩展的（虽然协议里面还可以提供 prompt, resource 之类的，但是我就没见过哪个 mcp server 实现的）。
现在不提这个，是因为 Agent 已经实现了绝大部分核心的 tools ，包含文件读写，网络搜索，task 管理等等。
用户除了一些真正的外部服务，比如 figma ，obsidian ，实际上并不需要接什么乱七八糟良莠不齐的 mcp

有没有可能这俩都是过度

1 、mcp 的实现已经基本穷举了。有机会让 LLM 调用的工具总共就那么多。没必要太细分。你常用的软件也就那么几个。
2 、风头已过，已经成了基本逻辑，没必要多提及。你看现在还有人提面向对象么？
3 、目前的互联网内容，生意属性远大于实际表达。所以有很明显的跟风现象。

mcp 和 skills 是两个层，mcp 提供基础能力，skill 是它之上的组合能力

@nc
哈哈哈，你说的一点毛病没有。
不过 Rest API + Skills 其实已经很接近 MCP 了，MCP 不也是用一个 JSON 把参数格式描述定义好，然后让 AI 来按需调用嘛，本质上已经差不多了。

MCP 有一个好处是对 AI 只暴露接口，业务逻辑在外部实现，这样就算你的 Agent 没有沙箱也能接；
Skills 要让 Agent 执行代码，会多消耗一部分 token ，然后必须有代码沙箱，不然跑不起来。

MCP 和 SKILL 不都是向法学硕士描述如何使用工具的技术机制吗，且两者的机制都相对简单，所以说 SKILL 是 MCP 的换壳版或升级版没什么毛病吧，不知道哪些强调这是两个层面的东西的说法，到底是要表达啥

跟我理解的也差不多，虽然从定义上 mcp 和 skills 是两个层面的东西，但是如果一个新的什么接口要暴露出去大概率是先有 api ，再有人封装成 mcp 。现在直接有 skills ，直接脚本+api 调用完全就可以把这个事情做掉了，mcp 的存在感要弱化很多，mcp 目前还会存在但是感觉会慢慢淡出人们的视野。

mcp 就是一种 api 形式，现在也没人聊 rust 了，不等于不存在

我个人理解，如果返璞归真地说，Skill 属于提供给 LLM 的 Prompt 的一部分，MCP 和 HTTP 或者 Shell 一样是一种协议。

人类也可以直接把 JSON-Scheme 送进 stdio 来调用 MCP 接口。就像你提到的可以请求 HTTP ，WS 什么的。

如果你的 Skill 是从 MCP 拿到结果，那 LLM 就会去调 MCP 。

不过最近 MCP 感觉确实没啥人提了...

我觉得 mcp 依然有人在说

但是 rule 好像真的没有人再说了

感觉一些 rule 也可以写在 skill 里

perplex 的人也提了同样的观点，我很赞同，也不再开 mcp 的新坑了，等这个观点成为广泛的共识之后再开坑

刚用 AI 的时候做了两个 mcp ，得想方设法把提示词一块塞进去，放描述里嫌长放 resource 里嫌怪，哪哪都别扭。看到成熟的 skills 库后，我寻思这不也能调脚本吗，那还费劲整 mcp 干啥~

mcp 能做的 skill 全部能过，反之不能，为什么还要用 mcp 呢

想分开用无非就是多费一些 Token ，不想分开用，那么 Skill 就等于 MCP 的说明书

没有 mcp 怎么开发 skill ？ mpc 就是官方对接文档

Skills 都快死了，更何况 mcp

skill：告诉 AI 如何做，有的会放脚本
MCP：直接把工具和说明书扔 AI 面前
MCP 有统一的标准，但是 skill 目前没有

pi-coding-agent 就默認不支持 MCP: https://mariozechner.at/posts/2025-11-02-what-if-you-dont-need-mcp/

感觉上面好多人根本没看过 MCP Specification 就在回答

MCP 完全有能力包括详细的每个工具怎么调用的说明进去（而不是像很多人理解的那样就一个 json schema 描述字段就完事了）

MCP 最大的问题还是一次性暴露的工具函数太多了、schema 加上说明会占用大量的 token —— 即使你这次做的工具完全没有用到它

而 Skill 通过「渐进式暴露」可以说在很大的程度上解决了这个问题

---

而 MCP 死了吗？我觉得并没有，至少它目前仍然很难说被 skill 完全替代 - 我个人觉得，skill 调用命令行的方式还是太不优雅了

而且有一个很重要的点，MCP 本质上还是工具调用，而工具调用的参数是用 json schema 定义的，然后最前沿的模型都是支持 Structured Output 保证输出数据一定会满足定义的 json schema 的

而命令行呢？ AI 经常会在转义这种基本问题上卡一卡，然后也可能随时多/少点参数；命令行本身做了强校验还好，AI 还能根据错误信息自动纠错、就是浪费点 token ；而如果要是没做校验或是校验逻辑输出的错误信息太抽象可能 AI 都不知道出问题了/怎么也想不到问题到底出在哪

我的理解是如果龙虾调用 3dmax c4d ue 之类的软件来实现一些复杂的内容应该就需要 mcp 了

skill 有取代 mcp 的趋势，虽然他们不是一共东西，但是 skill 也能达到 mcp 的目的。

大致理解，mcp 不就是 ai 的 openapi.json 吗

@nowheremanx 然后 skill 就是 readme.md

不同的东西来的 mcp 我现在高强度用来连数据库

@msg7086 两者不同维度的东西。 不太恰当的比喻，把 skill 当做一套 workflow ，比如 dify ，cozes 里的，mcp 当做一个 api 工具调用。

skill 不是使用 mcp 提供的能力吗，没 mcp ，skill 用啥

这话跟开玩笑一样！！现在是 skill/agent 比较火，但是他们三个其实不是一个东西。agent （大脑）依赖 mcp （协议）调用 skill （手脚）。而 skill 要被 agent 发现，也要依赖 mcp 。你告诉我 mcp 怎么死？

@ssssiiiirren

@ciki

@maolon

我感觉鉴权用 MCP 来实现比较好一些？ Skill 鉴权总是很麻烦

把 mcp 当中台用呗

@irainsoft 你错了，SKILL 里面可以包含 MCP 。

你如何让 ai 接入第三方系统里? 最简单就是 api 那么 mcp 就是提供 api 的功能

@glaz #58 我没说不能包含啊。我只是说了是俩不同的玩意。你可以在 SKILL 里提示 AI 使用指定的 MCP 来解决问题

如果你避免不了 MCP ，那还是老实的用，那些可能恶心点儿的地方，可以试试用我的 MCPMate 来解决：

https://mcp.umate.ai/
https://github.com/loocor/mcpmate

我理解 skill 和 mcp 是两个层面的东西，但我觉得，长期看，mcp 确实没必要了

@irainsoft 不是 SKILL 指定 MCP 。是 SKILL 文件里面本来就有 MCP ，并不是你理解的就只是说明文件。