81–90 of 415 posts
Wrong. It needs to "understand" both these things. The only difference is where and how the strings explaining them are generated.
The "only skills" people are usually non-technical and the "only CLI" people are often solo builders. MCP makes a lot of sense for enterprise IMO. Defines auth and interfaces in a way that's a natural extension of APIs.
I think many of us have been burned by the absolutely awful and unstable JIRA MCP and found that skills using `acli` actually work and view the rest of the MCP space thru that lens. Lots of early - and current! - MCP implementations were bad. So it’s an uphill battle to rebuild reputation.
Literally my biggest use case for MCP is Jira and Confuence
I could not agree any less with the author. I don’t want APIs, I want agents to use the same CLI tooling I already use that is locally available. If my agents are using CLI tooling anyways there is no need to add an extra layer via MCP. I don’t want remote MCP calls, I don’t even want remote models but that’s cost prohibitive. If I need to call an API, a skill with existing CLI tooling is more than capable.
I keep getting hung up on securely storing and using secrets with CLI vs MCP. With MCP, you can run the server before you run the agent, so the agent never even has the keys in its environment. That way. If the agent decides to install the wrong npm package that auto dumps every secret it can find, you are less likely to have it sitting around. I haven’t figured out a good way to guarantee that with CLIs.
Sure, if I want my agents to use naked curl on the CLI, they need to know secrets. But that's not how I build my tools.
I wanted to connect my Claude account to my Notion account. Apparently all you need to do is just submit the notion MCP and log in. That's it! And I was able to interact with my Notion data from my Claude account!
Imagine how hard this would be with skills? It is literally impossible because with skills, you may need to install some local CLI which Claude honestly should not allow.
If not CLI, you need to interact with their API which again can't happen because you can't authenticate easily.
MCP's fill this narrow gap in my opinion - where you don't own the runtime and you want to connect to other tools like plugins.
MCP has severe context bloat just by starting a thread. If harnesses were smart enough to, during install time, summarize the tools provided by a MCP server (rather than dumping the whole thing in context), it would be better. But a worse problem is that the output of MCP goes straight into the context of the agent, rather than being piped somewhere else
A solution is to have the agent run a cli tool to access mcp services. That way the agent can filter the output with jq, store it in a file for analysis later, etc