-
Notifications
You must be signed in to change notification settings - Fork 4
Description
Suggested in
modelcontextprotocol/modelcontextprotocol#2076 (comment) ,
It feels like we have a way to send resources from MCP, and there doesn't seem to be much distinguishing about skills that needs more than what resources offer.
I'm not sure what justifies added new complexity to the MCP spec here. There's little clear upside.
There's also, imo, a huge advantage to having resources. Resources inherently already have URI's, have addressability baked in. So one skill already has a means to refer to other skills. There's already tooling for fetching resources, which could be leveraged instead of having to carve new transport protocols out. Making skills a special kind of resource feels logical, consistent, and powerful.
I worry that our various extension points in AI are facing a credibility crisis, because there are so many different things happening. Adding a whole new mechanism when existing ones already would suit the use case makes MCP look bad. This was a quite popular by Bsky standards post, that I think represents how a lot of people feel, and which should be taken into account when we think about where to go next with MCP.
what you want is an MCP. oh wait have you tried installing a skill? no you don't have an agents,md file. actually what you want is a plugin. have you tried agent orchestration? you have gotta try hooks.
https://bsky.app/profile/oppi.li/post/3me64ejq6ls2u
I really think skills have the chance to use what material exists rather than compounding the complexity of MCP! The option to use resources, to define a schema & use that for skills is absent from
https://github.com/modelcontextprotocol/experimental-ext-skills/blob/main/docs/approaches.md . It should be regarded & imo favored.