[sean_lynch]

Before you get too far into the usual “MCP is dead, Skills forever” debate

The real valuable capability MCP offers over skills/CLI is isolating the auth flow outside of the agent’s context window, and potentially out of the harness completely. This is valuable from a security perspective obviously. It’s also just a much easier user experience for normies and large businesses adopting AI tools. I hear all the context bloat and tool call redundancy complaints. But this structure for handling auth has real value.

Maybe the idealized form of MCP is just an auth gateway for the API and nothing else. That’d still be a win.

[mooreds]

I think that this extension points out other benefits to MCP over skills:

   * centralized control
   * ease of use for employees
   * auditing/compliance
   * deployment model

It seems the state of the art for deploying skills is "copy this file and put it in this place" or "check out this repo and add a symlink" or "run this slash command to install the skill". (I'm not aware of any solution that pushes skills out.)

These options are simple, but not as easy as this extension makes rollout of a new MCP server to an employee.

[blcknight]

There's a new standard in progress for skills over MCP

https://modelcontextprotocol.io/community/working-groups/ski...

[rhipitr]

Isn’t tool drift/version also a benefit? Especially in scenarios where the use must be standardized and up to date?

[debarshri]

All the points that you are mentioning, you can technically do with tools too. We do that at adaptive [1]. We are building privileges access stuff for agents, and it works. The usecases you are mentioning can be done with tools via our platform.

[1] https://adaptive.live

[mooreds]

> you can technically do with tools too

By tools, do you mean skills? Or do I misunderstand you?

Thanks for sharing your solution. I clicked around and the information on your site is sparse. The postgresql page[0] doesn't really illustrate how your system works; just says that it does.

Regardless, there's a big difference between a proprietary way to inject skills and MCP, a standardized way to control access and deploy AI compatible logic.

0: https://adaptive.live/integrations/postgresql

[debarshri]

Apologies about the sparse information. We’re preparing for a launch. Thought this would be a great place to make the comment. It is indeed a combination of tools and skills.

Your argument is fair but yea, we are seeing adoption because tools often map to users mental model of how they want to use the agent.

[mooreds]

No worries, always appreciate the discussion. Good luck on the launch!

[debarshri]

You sound like someone who is technically well-versed with the landscape. would love to get some feedback from you.

[shepherdjerred]

Claude CLI has plugins and plugin marketplaces that solve the problem you're describing.

[maxrev17]

Mcp allows a fantastic audit trail also. As well as allowing segregation of responsibilities - ie authenticating 6 linear accounts across 6 clients and then deciding which one to use with deterministic audited methods

[Ferret7446]

> The real valuable capability MCP offers over skills/CLI is

The real lesson is that MCP vs skills is not a binary. They are simply different tools. Each may or may not be better given different requirements.

Which is better, a knife or a saw?

[fnordpiglet]

There’s even a skills over MCP WG; and I typically deliver skills via tools in my MCPs intentionally. I find Claude and codex recall of skills via MCP tools to actually be higher than skills themselves, which I feel have an (unmeasured) less than 30% recall rate. I have to typically force skills to be loaded explicitly through / or $ depending on the flavor and skill graphs are very unreliable.

[9dev]

Aside from that, MCPs also allow connecting an external platform without a runtime environment. Every time this topic comes up, engineers act like Claude Code was the only application for AI agents, while there's tons of use cases in other verticals aside from coding. The harness is not running on a local machine, but rather an isolated and restricted container in some cloud deployment, where running arbitrary code would be a big nope. But you still want customers to be able to connect their existing tools to your agent.

MCP is the perfect answer for this - it gives an agent a connector with built-in authentication to all kinds of additional tooling. Skills just don't qualify here at all.

[yaur]

> the usual “MCP is dead, Skills forever” debate

Is that really a thing? Everything on the other side of the MCP boundary (at least how I'm using it) is deterministic and about 100x faster (not to mention safer) than inference.

[shepherdjerred]

Skills can be about as deterministic. Consider GitHub MCP vs skill for GH CLI.

It might use the view_pr tool, or `gh pr view`, but in the end it's still performing a deterministic action.

The benefit might be that the GH skill can contain more domain specific information about GitHub, and you only pay the context cost when the skill is read.

Personally I generally avoid MCP and have skills for CLIs -- if one doesn't exist, then I author one. For example I have a CLI for Grafana, Discord, Sentry, etc.

https://github.com/shepherdjerred/monorepo/tree/main/package...

[altmanaltman]

> It might use the view_pr tool, or `gh pr view`, but in the end it's still performing a deterministic action.

No its providing a deterministic output. The action it takes is still not determistic, right, since it can be either of the two options.

I don't see the benefit or even the point of "more domain specific knowledge" in a skill especially for the example you shared.

[alehlopeh]

Claude Code uses gh cli just fine without any skills.

[theshrike79]

If "fine" is what you need, then ok. It can stumble its way to everything eventually.

With a proper skill it can one-shot even complex commands that require poking to gh api because the basic command set doesn't work. Or it knows how to track a running CI workflow efficiently without having to try three different methods.

Source: I daily drive Claude + gh cli.

[lavataco]

I’m work on a platform for restaurant reviewing with your friends, and (after a few stumbles) MCP definitely seems the way to go. Normies will not hunt down their claude directory and paste a skill file. “Connections” is something they understand, and pasting the mcp or finding it in the marketplace is easier for them.

TBD if having agent access to places and reviews is helpful, hah!

[trollbridge]

"Normies" pasting in MCP sounds like a nightmare from a security perspective.

[tommy_axle]

Yes, definitely the official directory for apps/connectors where possible, which security and vetting is a priority. It's similar in some ways to how it was/is with mobile where you have the official store vs directly running an apk.

[brookst]

I agree that having auth outside of context window is good.

But the real value of MCP is adding a semantic layer on top of APIs. Skills are client side and don’t know the server’s capabilities. MCP lets the server explain its API in natural language so clients who have no prior knowledge of the server, it’s API, or its domain can use it intelligently.

I used to think MCP was dumb. I’ve written to large MCP servers, one for CAD and one for music, and I am a complete convert.

[c0rruptbytes]

MCP tool search fixes the major issue imo, MCP clears skills/clis in every other way

[mediaman]

Yes, people conflated progressive disclosure as a method with skills as a particular implementation because skills became the first widely adopted use of progressive disclosure.

But progressive disclosure is just a method that you can apply to lots of things to reduce context bloat. Any time you provide some kind of limited index or search to an AI and then let it expand that based on the circumstances of the request, it's progressive disclosure.

And one of the things you can apply it to is MCPs.