[deleted]
I still prefer MCP over skills
311–320 of 415 posts
Re: I still prefer MCP over skills
#312mcp is really easy for non-techies to understand. if i own the system, can install cli tools, cli + skills beat it every time and i can tweak, etc. if you're asking someone else to do that there's real friction. i'll sometimes use mcp if i just want to get up and running am not watching context as much, then if they offer a cli i'll just move to skill + that or write my own wrapper off the api.
Re: I still prefer MCP over skills
#313Earlier quoted context omitted.
I feel like the MCP conversation conflates too many things and everyone has strong assumptions that aren't always correct. The fundamental issue is between one-off vs. persistent access across sessions: - If you need to interact with a local app in a one-off session, then use CLI. - If you need to interact with an online service in a one-off session, then use their API. - If you need to interact with a local app in a…
MCP is less discoverable than a CLI. You can have detailed, progressive disclosure for a CLI via --help and subcommands. MCPs needs to be wrapped to be composed. MCPs needs to implement stateful behavior, shell + cli gives it to you for free. MCP isn't great, the main value of it is that it's got uptake, it's structured and it's "for agents." You can wrap/introspect MCP to do lots of neat things.
"MCP is less discoverable than a CLI" -> not true anymore with Tool_search. The progressive discovery and context bloat issue of MCP was a MCP Client implementation issue, not a MCP issue.
"MCPs needs to be wrapped to be composed." -> Also not true anymore, Claude Code or Cowork can chain MCP calls, and any agent using bash can also do it with mcpc
"MCPs needs to implement stateful behavior, shell + cli gives it to you for free." -> having a shell+cli running seems like a lot more work than adding a sessionId into an MCP server. And Oauth is a lot simpler to implement with MCP than with a CLI.
MCP's biggest value today is that it's very easy to use for non-tech users. And a lot of developers seem to forget than most people are not tech and CLI power users
Re: I still prefer MCP over skills
#314Earlier quoted context omitted.
This has devolved into "MCP is web scale." https://youtu.be/b2F-DItXtZs
You're clearly very intelligent and a real software engineer, maybe you can explain where I'm wrong?
Sure thing! That probably won't take more than a couple years at 10-20 hours a week of tutelage, and although my usual rate for consulting of any stripe is $150 an hour, for you I'm willing to knock that all the way down to just $150 an hour.
Re: I still prefer MCP over skills
#315Earlier quoted context omitted.
I haven’t seen a single major MCP provider that would let us limit access properly Miro, Linear, Notion etc… They just casually let the MCP do anything the user can and access everything. For example: Legal is never letting us connect to Notion MCP as is because it has stuff that must NEVER reach any LLM even if they pinky swear not to train with our stuff. -> thus, hard deterministic limits are non-negotiable.
it's straightforward to spin up a custom MCP wrapper around any API with whatever access controls you want the only time i reach for official MCP is when they offer features that are not available via API - and this annoys me to no end (looking at you Figma, Hex)
That’s what we’re doing, but it’s annoying. Why can’t they just let us limit access for the official MCP easily?
Re: I still prefer MCP over skills
#316Earlier quoted context omitted.
And in a skill, I can store the secret in the skill itself, or a secure storage the skill accesses, and the agent never gets to see the secret. 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.
what stops the agent from echoing the secure storage? what i see is that you give it a pass manager, it thinks, "oh, this doesn't work. let me read the password" and of course it sends it off to openai.
> what stops the agent from echoing the secure storage?
The fact that it doesn't see it and cannot access it.
Here is how this works, highly simplified:
def tool_for_privileged_stuff(context:comesfromagent):
creds = _access_secret_storage(framework.config.storagelocation)
response = do_privileged_stuff(context.whatagentneeds, creds)
return response # the agent will get this, which is a string
The agent never accesses the secrets storage. The tool does. The tool then uses the secret to do whataever privileged work needs doing. The secret never leaves the tool, and is never communicated back to the agent. The agent also doesn't need, or indeed can give the tool a secret to use.
And the "privileged work" the tool CAN invoke, does not include talking to the secrets storage on behalf of the agent.
All the info, and indeed the ability to talk to the secrets storage, belongs to the framework the tool runs in. The agent cannot access it.
Re: I still prefer MCP over skills
#317Earlier quoted context omitted.
> MCP is the absolute best and most effective way to integrate external tools into your agent sessions Nope. The best way to interact with an external service is an api. It was the best way before, and its the best way now. MCP doesn't scale and it has a bloated unnecessarily complicated spec. Some MCP servers are good; but in general a new bad way of interacting with external services, is not the best way of doing i…
You haven’t actually done that have you. If you did, you would immediately understand the problems MCP solves on top of just trying to use an API directly: - easy tool calling for the LLM rather than having to figure out how to call the API based on docs only. - authorization can be handled automatically by MCP clients. How are you going to give a token to your LLM otherwise?? And if you do, how do you ensure it does…
> easy tool calling for the LLM rather than having to figure out how to call the API based on docs only
I think the best way to run an agent workflow with custom tools is to use a harness that allows you to just, like, write custom tools. Anthropic expects you to use the Agent SDK with its “in-process MCP server” if you want to register custom tools, which sounds like a huge waste of resources, particularly in workflows involving swarms of agents. This is abstraction for the sake of abstraction (or, rather, market share).
Getting the tool built in the first place is a matter of pointing your agent at the API you’d like to use and just have them write it. It’s an easy one-shot even for small OSS models. And then, you know exactly what that tool does. You don’t have to worry about some update introducing a breaking change in your provider’s MCP service, and you can control every single line of code. Meanwhile, every time you call a tool registered by an MCP server, you’re trusting that it does what it says.
> authorization can be handled automatically by MCP clients. How are you going to give a token to your LLM otherwise??
env vars or a key vault
> And if you do, how do you ensure it does not leak the token?
env vars or a key vault
Re: I still prefer MCP over skills
#318Earlier quoted context omitted.
I feel like the MCP conversation conflates too many things and everyone has strong assumptions that aren't always correct. The fundamental issue is between one-off vs. persistent access across sessions: - If you need to interact with a local app in a one-off session, then use CLI. - If you need to interact with an online service in a one-off session, then use their API. - If you need to interact with a local app in a…
My main complaint with mcp is that it doesn't compose well with other tools or code. Like if I want to pull 1000 jira tickets and do some custom analysis I can do that with cli or api just fine, but not mcp.
Give the model a REPL and let it compose MCP calls either by using tool calls structured output, doing string processing or piping it to a fast cheap model to provide structured output.
This is the same as a CLI. Bash is nothing but a programming language and you can do the same approach by giving the model JavaScript and have it call MCP tools and compose them. If you do that you can even throw in composing it with CLis as well
Re: I still prefer MCP over skills
#319Earlier quoted context omitted.
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.
If Atlassian put out a horrible CLI tool, would your conclusion be that "CLIs are bad"?
The Atlassian CLI is pretty bad too! But at least the robot can consistently use it. And I can use it to help the robot figure out Atlassian’s garbage data structures. There’s not much I can do to debug their awful MCP.
Re: I still prefer MCP over skills
#320Earlier quoted context omitted.
it's straightforward to spin up a custom MCP wrapper around any API with whatever access controls you want the only time i reach for official MCP is when they offer features that are not available via API - and this annoys me to no end (looking at you Figma, Hex)
That’s what we’re doing, but it’s annoying. Why can’t they just let us limit access for the official MCP easily?
Agreed. Sounds like a failure of the services, but not MCP. Can't believe in 2026 we don't have better permissions on systems like this.