[HN Gopher] I still prefer MCP over skills
___________________________________________________________________
I still prefer MCP over skills
Author : gmays
Score : 422 points
Date : 2026-04-10 02:01 UTC (20 hours ago)
(HTM) web link (david.coffee)
(TXT) w3m dump (david.coffee)
| robotobos wrote:
| Despite thinking this is AI-generated, I agree but everything has
| a caveat.
|
| Skills are good for instilling non-repeatable, yet intuitive or
| institutional knowledge.
|
| MCP's are great for custom, repeatable tasks. After 5-10 runs of
| watching my LLM write the same exact script, I just asked it to
| hardcode the solution and make it a tool. The result is runs are
| way faster and repeatable.
| ashraymalhotra wrote:
| You could hardcode the script as a file within a skill too
| right? Skills can contain code, not just markdown files.
| robotobos wrote:
| Have not tried, but interesting. I guess my concern would be
| the Skill still takes up context space, where as MCP is just
| using CPU.
| BenFrantzDale wrote:
| > Skills are good for instilling non-repeatable, yet intuitive
| or institutional knowledge.
|
| What about just putting that sort of thing in human-targeted
| documentation? Why call it a "skill" and hide it somewhere a
| human is less likely to look?
|
| (Skills are nice for providing /shortcuts.)
| et-al wrote:
| > _Skills are good for instilling non-repeatable, yet intuitive
| or institutional knowledge._
|
| Maybe I'm misinterpreting you, but can you explain this more?
| I've been using skills for repeatable tasks. Why an MCP
| instead?
| robotobos wrote:
| If the model can figure it out with tokens, but my
| institutional knowledge MCP tool can do it with a few CPU
| cycles, it's faster and deterministic and repeatable.
| robotobos wrote:
| Saying "non-repeatable" was probably wrong. "Unique" might be
| better. Things LLMs arent naturally able to do or infer.
| sjdv1982 wrote:
| It is all about API contracts, right?
|
| After the first run, you have a script and an API: the agent
| discovery mechanism is a detail. If the script is small enough,
| and the task custom enough, you could simply add the script to
| the context and say "use this, adapt if needed".
|
| Or am I misunderstanding you?
| dgb23 wrote:
| I would go further than this. Call the script yourself (or via
| some other mechanism/program) and then give the results to the
| LLM.
|
| The majority of processes don't need nearly as many decision
| making points as an agent could deal with and look somewhat
| like this:
|
| 1. gather raw information => script
|
| 2. turn it into structured data => script
|
| 3. produce an actionable plan => script/user/agent (depends)
|
| 4. validate the plan => user
|
| 5. narrow down the implementation workflow and the set of tools
| needed => user/agent
|
| 6. follow workflow iteratively => user/agent
|
| Doesn't need to be this exact shape, but the lesson I learned
| is to quasi front load and structure as much as possible with
| scripts and data. That can be done with agent assistance as
| well, for example by watching it do the task, or a similar one,
| in freeform at first.
| robotobos wrote:
| There's definitely some optimization that can occur, like an
| orchestrator or Ralph.
| dvcrn wrote:
| > Despite thinking this is AI-generated, I agree but everything
| has a caveat.
|
| Definitely not AI generated. I wrote this during a non-internet
| flight. :)
| robotobos wrote:
| Haha sorry for the callout! Saw the M-dash and auto-assumed.
| Nice write up and thanks for sharing :)
| charcircuit wrote:
| This author does not realize that skills can call APIs. The idea
| that you have to build dedicated CLI apps is not true at all and
| invalidates the entire article.
| leonidasv wrote:
| And call MCPs as well
| CGamesPlay wrote:
| Can you clarify what exactly you mean? Skills are markdown
| files, so they definitely can't call APIs or CLIs. Are you
| saying that a skill can tell the agent to use curl to call web
| APIs? Or something different?
| mhalle wrote:
| https://agentskills.io/specification
|
| * references/ Contains additional documentation that agents
| can read when needed
|
| * scripts/ Contains executable code that agents can run.
|
| * assets/ Contains static resources
| hypercube33 wrote:
| Technically they can at least how I'm using or abusing them -
| I ride windows so they have a generic powershell script
| bolted on to handle special API use through the skill to make
| it easier for the agent to call data up noted in the skill.
| does it lack full API details? absolutely. I have also a
| learning skill where if it has to go for a think / fail / try
| to figure something new out to grow a new skill or update an
| existing one.
|
| skills to me suck when they are shared with a team - haven't
| found the secret sauce here to keep these organic skills
| synced between everyone
| latentsea wrote:
| They almost certainly mean skills can tell the agent to use
| the api, and it can succeed at doing that.
| nostrebored wrote:
| Skills can bundle scripts. Skills can express how to use
| curl. Skills can integrate with your fips keys if you want
| them to.
| woeirua wrote:
| No, the point was that you don't have access to a CLI in every
| environment.
| charcircuit wrote:
| You could have access to a web browser or web request tool
| instead.
| woeirua wrote:
| There is no world in which an enterprise is not OK with an
| agent having access to a CLI but is OK with possibly
| getting prompt injected from a random web search.
| j16sdiz wrote:
| He did. That's what the "you aren't forcing the user to manage
| raw tokens and secrets in plain text." bit comes in.
| ghm2199 wrote:
| For indie developers like myself, I often use chat GPT desktop
| and Claude desktop for arbitrary tasks, though my main workhorse
| is a customized coding harness with CC daemons on my nas. With
| the apps, b I missed having access to my Nas server where my dev
| environment is. So I wrote a file system MCP and hosted it with a
| reverse proxy on my Truenas with auth0. I wanted access to it
| from all platforms CharGPT mobile, desktop. Same for CC.
|
| For chatgpt desktop and Claude desktop my experience with MCPs
| connected to my home NAS is pretty poor. It(as in the app) often
| times out fetching data(even though there is no latency for
| serving the request in the logs), often the existing connection
| gets invalidated between 2 chat turns and chat gpt just moves on
| answering without the file in hand.
|
| I am not using it for writing code, its mostly read only access
| to Fs. Has anyone surmounted these problems for this access
| patterns and written about how to build mcps to be reliable?
| alierfan wrote:
| This isn't a zero-sum game or a choice of one over the other.
| They solve different layers of the developer experience: MCP
| provides a standardized, portable interface for external
| data/tools (the infrastructure), while Skills offer project-
| specific, high-level behavioral context (the orchestration). A
| robust workflow uses MCP to ensure tool reliability and Skills to
| define when and how to deploy those tools.
| Aperocky wrote:
| MCP is just CLI wrapped in boxes.
|
| CLI is the same API in more concise format. At minimum, the
| same amount of context overhead exist for MCP, but most of the
| time more because the boxes have size.
|
| CLI can be secure, AWS CLI is doing just fine. You can also
| play simple tricks to hide secret in a daemon or run them
| remotely, and all of them are still smaller than a MCP.
| BeetleB wrote:
| I've always wondered: Doesn't the fact that the MCP
| input/output is more structured lead to higher reliability?
| With MCP you declare the types for input (string, int, list,
| etc) and output.
|
| As part of our product, we have an MCP server. Since many of
| our MCP tools are expensive, for our tests we simply give the
| LLM all the tool descriptions (but in text form, not
| structured) and ask it which tool it would call for a given
| query and assert on the response.
|
| The tests are flaky. In practice, I've always seen the LLM
| make the right tool call with the proper formatting of args,
| etc. In the tests (same LLM model), it occasionally makes
| mistakes on the argument types and it has to try again before
| it gets it right.
|
| My assumption was that the structure MCP provides was the
| reason there was a discrepancy.
| Aperocky wrote:
| This maybe one of the area that MCP are ok-ish, however at
| huge cost to context.
| BeetleB wrote:
| As I and others have pointed out: The context problem
| with MCP is mostly solved.
|
| See https://news.ycombinator.com/item?id=47719249 for an
| example I gave.
| zhdc1 wrote:
| Completely agree. I don't see why people view this as an either
| or decision.
|
| Also worth mentioning that some paid MCP providers offer an
| actual value added. Sure, I can use curl or a self hosted
| crawler for web searches, but is it really worth the pain?
| soco wrote:
| Also, the skills can be ignored or thwarted if the LLM feels
| like, while a policy at the MCP server level stays there.
| chris_ivester wrote:
| This is exactly right, and I'd add one more layer that the
| thread is mostly missing: this combination matters most when
| the agent itself is hosted in the cloud rather than running
| locally. Skills + MCP is the architecture for cloud-hosted
| agents - Skills give the agent its context and workflow, MCP
| tools give it reach into external services without the agent
| needing to manage credentials or runtime dependencies.
| dvcrn wrote:
| Hi, author here! I fully agree with your comment here and
| that's exactly my point in the post: Different tools that work
| great for different tasks. If anything, the post is a take
| against treating Skills + CLI as a zero-sum replacement for
| MCP, and calling MCP dead/outdated
|
| Especially portability is just not possible with Skills+CLI
| (yet). I can use the same MCP servers through remote MCP on my
| phone, web, iPad, in ChatGPT, Perplexity, Claude, Mistral and
| so on, which I can't do with Skills.
| leonidasv wrote:
| This is the same as saying "I still prefer hammer over
| screwdriver".
| plandis wrote:
| 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.
| woeirua wrote:
| Ok, but there are still many environments where an LLM will not
| have access to a CLI. In those situations, skills calling CLI
| tools to hook into APIs are DOA.
| hansonkd wrote:
| idk, just have a standard internet request tool that skills
| can describe endpoints to. like you could mock `curl` even
| for the same CLI feel
| woeirua wrote:
| Now you've replicated MCP but with extra steps and it's
| harder to debug.
| hansonkd wrote:
| Its actually simpler since the skill can be 100% a MD
| file.
| yawnxyz wrote:
| skills can have code bundled with them, including MCP code
| woeirua wrote:
| The agent still doesn't have an execution environment. It
| can't execute the code!
| yawnxyz wrote:
| well that's harness territory! give it the right
| harness/environment!!
| woeirua wrote:
| Whoosh.
| egeozcan wrote:
| What are the advantages of using an environment that doesn't
| have access to a CLI, only having to run/maintain your own
| server, or pay someone else to maintain that server, so AI
| has access to tools? Can't you just use AI in the said
| server?
| daemonologist wrote:
| Obvious example is a corporate chatbot (if it's using
| tools, probably for internal use). Non-technical users
| might be accessing it from a phone or locked-down corporate
| device, and you probably don't want to run a CLI in a
| sandbox somewhere for every session, so you'd like the LLM
| to interface with some kind of API instead.
|
| Although, I think MCP is not really appropriate for this
| either. (And frankly I don't think chatbots make for good
| UX, but management sure likes them.)
| nostrebored wrote:
| Why are they not calling APIs directly with strictly
| defined inputs and outputs like every other internal
| application?
|
| The story for MCP just makes no sense, especially in an
| enterprise.
| ok_dad wrote:
| MCP is an API with strictly defined inputs and outputs.
| nostrebored wrote:
| This is obviously not what it is. If I give you APIGW
| would you be able to implement an MCP server with full
| functionality without a large amount of middleware?
| notpushkin wrote:
| Sorry, could you rephrase that?
| victorbjorklund wrote:
| If I gave you that could you implement Graphql from
| scratch without a large amount of middleware? Or are we
| now saying graphql api:s are not api:s?
| ok_dad wrote:
| I've implemented an MCP tool calling client for my
| application, alongside OAuth for it. It was hard but no
| harder than anything else similar. I implemented a client
| for interference with the OpenAI API spec for general
| inference providers, and it was similarly as hard. MCP.
| SDKs help make it easy; MCP servers are dead simple.
| Clients are the hard part, IMO.
|
| MCP is basically just an RPC API that uses HTTP and JSON,
| with some other features useful for AI agents today.
| oblio wrote:
| Does MCP support authentication, SSO?
| notpushkin wrote:
| It supports OAuth, IIRC. But I suppose the internal
| chatbot itself would require auth, and pass that down to
| the tools it calls.
| insin wrote:
| The chatbot app initiates an OAuth flow, user SSOs,
| chatbot app receives tokens to its callback URL, then
| tool calls can access whatever the user can access.
|
| If you use the official MCP SDK, it has interfaces you
| implement for auth, so all you need to do is kick off the
| OAuth flow with a URL it figures out and hands you,
| storing the resulting tokens and producing them when
| requested. It also handles using refresh tokens, so
| there's just a bit of light friendly owl finishing on
| top.
|
| Source: I just implemented this for our (F100) internal
| provider and model agnostic chat app. People can't seem
| to see past the coding agents they're running on their
| own machines when MCP comes up.
| notpushkin wrote:
| Neat!
| ok_dad wrote:
| Yes it's literally just standard OAuth that's defined in
| the MCP spec. I spent this week implementing an auth
| layer for my app's MCP client gateway.
| woeirua wrote:
| MCP really only makes sense for chatbots that don't want
| to have per session runtime environments. In that
| context, MCP makes perfect sense. It's just an adapter
| between an LLM and an API. If you have access to an
| execution engine, then yes CLI + skills is superior.
| 9dev wrote:
| Only is doing a lot of work here. There are tons of use
| cases aside from local coding assistants, e.g., non-code
| related domain specific agentic systems; these don't even
| necessarily have to be chatbots.
| friendzis wrote:
| OP's point is about per session sandboxes, not them
| necessarily being "chatbots". But if you don't burry the
| agent into a fresh sandbox for every session you have
| bigger problems to worry about than MCP vs CLI anyway
| functional_dev wrote:
| actually local MCP just spawns a subprocess and talks via
| stdin/stdout.. same as CLI tool. Extra layer is only for
| remote case.
|
| This might help if interested -
| https://vectree.io/c/implementation-details-of-stdio-and-
| sse...
| friendzis wrote:
| > and you probably don't want to run a CLI in a sandbox
| somewhere for every session
|
| You absolutely DO want to run everything related to LLMs
| in a sandbox, that's basic hygiene
| williamdclt wrote:
| You're missing their point, they're saying that you'd
| need a sandbox -> it'd be a pain -> you don't want to run
| a CLI _at all_
| DrJokepu wrote:
| The advantage is that I can have it in my pocket.
| Aperocky wrote:
| gateway agent is a thing for many months now (and I don't
| mean openclaw, that's grown into a disaster security
| wise). There are good, minimal gateway agents today that
| can fit in your pocket.
| patates wrote:
| Why can't you have the agent running on its own server/vm
| in your pocket?
| TheTaytay wrote:
| 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.
| Aperocky wrote:
| A CLI can just be a RPC call to a daemon, exact same pattern
| apply. In fact my most important CLI based skill are like
| this.. a CLI by itself is limited in usefulness.
| linkregister wrote:
| In other words, a wrapper around an MCP that's less
| verbose.
| throwup238 wrote:
| MCP is a wrapper around _it_. The CLI-daemon RPC pattern
| is much older and is used all over the place in modern
| systems.
| otabdeveloper4 wrote:
| "MCP" here is not needed.
| TheTaytay wrote:
| That was the same conclusion I reached! However, this also
| gave me some evidence that maybe I wanted MCP? I realized
| that my pattern was going to be:
|
| Step 1) run a small daemon that exposes a known protocol
| over a unix socket (http, json-rpc, whatever you want),
| over a unix socket. When I run the daemon, IT is the only
| that that has the secrets. Cool! Step 2) Have the agent run
| CLI that knows to speak that protocol behind the scenes,
| and knows how to find the socket, and that exposes the
| capabilities via standard CLI conventions.
|
| It seems like one of the current "standards" for unix
| socket setups like this is to use HTTP as the protocol.
| That makes sense. It's ubiquitous, easy to write servers
| for, easy to write clients for, etc. That's how docker
| works (for whatever it's worth). So you've solved your
| problem! Your CLI can be called directly without any risk
| of secret exposure. You can point your agent at the CLI,
| and the CLI's "--help" will tell the agent exactly how to
| use it.
|
| But then I wondered if I would have been better off making
| my "daemon" an MCP server, because it's a self-describing
| http server that the agent already knows how to talk to and
| discover.
|
| In this case, the biggest thing that was gained by the CLI
| was the ability of the coding agent to pipe results from
| the MCP directly to files to keep them out of its context.
| That's one thing that the CLI makes more obvious and easy
| to implement: Data manipulation without context cluttering.
| usrbinbash wrote:
| 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.
| lukewarm707 wrote:
| 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.
| jgilias wrote:
| OpenAI is not the worst it could or would send it to.
| usrbinbash wrote:
| > 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
|
| This, in a much more complex form, runs in my framework.
| The agent gets told that this tool exists. It gets told
| that it can do privileged work for it. It gets told how
| `context` needs to be shaped. (when I say "it gets told",
| I mean the tool describes itself to the agent, I don't
| have to write this manually ofc.)
|
| 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.
| mvkg wrote:
| If the tool fails for some reason, couldn't an overly
| eager agent attempt to fix what's blocking it by digging
| into the tool (e.g. attaching a debugger or reading
| memory)? I think the distinction here is that skill+tool
| will have a weaker security posture since it will
| inherently run in the same namespaces as the agent where
| MCP could impose additional security boundaries.
| TheTaytay wrote:
| I think this is a good setup to prevent the secret from
| leaking into the agent context. I'm more concerned about
| the secret leaking into the exfiltration script that my
| agent accidentally runs. The one that says: "Quick! Dump
| all environment variables. Find all secrets in dotfiles!
| Look in all typical secrets file locations..."
|
| Your agent process has access to those secrets, and its
| subprocesses have access to those secrets. The agent
| doesn't have to be convinced to read those files.
| Whatever malicious script it manages to be convinced to
| run could easily access them, right?
| stingraycharles wrote:
| I often just put direct curl commands in a skill, the agent
| uses that, and it works perfectly for custom API integrations.
| Agents are perfectly capable of doing these types of things,
| and it means the LLM just uses a flexible set of tools to
| achieve almost anything.
| notpushkin wrote:
| I think this is the best of both worlds. Design a sane API
| (that is easy to consume for both humans and agents), then
| teach the agents to use it with a skill.
|
| But I agree with the author on custom CLI tooling. I don't
| want to install another opaque binary on my machine just to
| call some API endpoints.
| stingraycharles wrote:
| Obviously opaque binaries are hardly an improvement over
| MCP, but providing a few curl + jq oneliners to interact
| with a REST API works great in my experience. Also means no
| external scripts, just a single markdown file.
| jonfw wrote:
| With a good CLI, an agent may be able to do something outside
| of the scope of it's skill fairly easily, by running help
| commands or similar. With even a well written API it is not
| as easy.
|
| I suppose that curl + API docs could replace a CLI but that's
| really token inefficient
| lll-o-lll wrote:
| Cool cool. Except.
|
| What about auth? Authn and authz. Agent should be you always?
| If not, every API supports keys? If so, no fears about context
| poisoned agents leaking those keys?
|
| One thing an MCP (server) gives you is a middleware layer to
| control agent access. Whether you need that is use-case
| dependent.
| mstipetic wrote:
| Also resources - which are by far the coolest part of MCP.
| Prompts? Elicitation? Resource templates? If you think of MCP
| as only a replacement for tool calls I can see the argument
| but it's much more than that.
| friendzis wrote:
| > If not, every API supports keys?
|
| How would MCP help you if the API _does not_ support keys?
|
| But that's not the point. The agent calls CLI tools, which
| reads secrets from somewhere where the agent cannot even
| access. How can agent leak the keys it does not have access
| to?
|
| You ARE running your agents in containers, right?
| lll-o-lll wrote:
| > How would MCP help you if the API does not support keys?
|
| Kerberos, OAuth, Basic Auth (username/password), PKI. MCP
| can be a wrapper (like any middleware).
|
| > But that's not the point. The agent calls CLI tools,
| which reads secrets from somewhere where the agent cannot
| even access. How can agent leak the keys it does not have
| access to?
|
| If the cli can access the secrets, the agent can just
| reverse it and get the secret itself.
|
| > You ARE running your agents in containers, right?
|
| Do you inject your keys into the container?
| Marha01 wrote:
| > If the cli can access the secrets, the agent can just
| reverse it and get the secret itself.
|
| What do you mean by this? How "reverse it"? The CLI tool
| can access the secure storage, but that does not mean
| there is any CLI interface in the tool for the LLM to
| call and get the secret printed into the console.
| _flux wrote:
| In principle it could use e.g. the `gdb` and step until
| it gets the secret. Or it can know ahead where the app
| stores the cerentials.
|
| We could use suid binaries (e.g. sudo) to prevent that,
| but currently I don't think we can. Most anyone would
| agree that using a separate process, for which the agent
| environment provides a connection, is a better solution.
| upcoming-sesame wrote:
| That's not a limitation of CLIs, they can work with a
| different auth as well.
|
| they are just a superior tool to MCP because the agent can
| write code that invokes, pipes and do many other things with
| the tool
| zaphirplane wrote:
| This has been hashed to death and back. The mcp allows a
| separation between the agent and the world, at its most basic
| not giving the agent your token or changing a http header ,
| forcing a parameter.
|
| Well yes you don't need those things all the time and who knows
| if the inventor of mcp had this idea in mind but here we are
| Aperocky wrote:
| The separation is being oversold as if only MCP can do it,
| which is laughable. Any CLI can trivially do exactly what MCP
| do in terms of separation.
| rimliu wrote:
| what you want and what works may be very different things.
| grensley wrote:
| 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.
| bicx wrote:
| I built an internal company MCP that uses Google Workspace auth
| and injects a mix of guidance (disguised as tools) on how we
| would like certain tasks to be accomplished via Claude as well
| as API-like capabilities for querying internal data and safely
| deploying small apps internally.
|
| I'd really love to get away from the SSE MCP endpoints we use,
| as the Claude desktop app can get really finicky about
| disconnects. I thought about distributing some CLIs with Skills
| instead. But, MCP can be easily updated with new tools and
| instructions, and it's easy to explain how to add to Claude for
| non-technical people. I can't imagine trying to make sure
| everyone in my company had the latest skill and CLI on their
| machine.
| bikelang wrote:
| 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.
| hnlmorg wrote:
| Can you share more about acli?
|
| Literally my biggest use case for MCP is Jira and Confuence
| dugmartin wrote:
| It is available here:
|
| https://developer.atlassian.com/cloud/acli/guides/introduct
| i...
|
| It has a pretty discoverable cli syntax (at least for
| Claude). I use it in my custom skills to pull Jira story
| info when creating and reviewing specs.
| walthamstow wrote:
| `acli` doesn't cover Confluence and I found it limited
| compared to the MCP by sooperset on GitHub.
| 0x696C6961 wrote:
| If Atlassian put out a horrible CLI tool, would your
| conclusion be that "CLIs are bad"?
| bikelang wrote:
| 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.
| jillesvangurp wrote:
| I've started thinking of these systems as legacy systems. We
| have them. They are important and there's a lot of data in
| them. But they aren't optimal any more.
|
| How we access them and where data lives is essentially an
| optimization problem. And AI changes what is optimal. Having
| data live in some walled garden with APIs designed to keep
| people out (most SAAS systems) is arguably sub optimal at this
| point. Sorting out these plumbing issues is actually a big
| obstacle for people to do productive things via agentic tools
| with these systems.
|
| But a good way to deal with this is to apply some system
| thinking and figure out if you still need these systems at all.
| I've started replacing a lot of these things with simple coder
| friendly solutions. Not because I'm going to code against these
| things but because AI tools are very good at doing that on my
| behalf. If you are going to access data, it's nicer if that
| data is stored locally in a way that makes it easy to access
| that data. MCP for some SAAS thing is nice. A locally running
| SQL database with the data is nicer. And a lot faster to
| access. Processing data close to where it is stored is optimal.
|
| As for MCP. I think it's not that important. Most agentic
| coding tools switch effortlessly between protocols and
| languages. In the end MCP is just another RPC protocol. Not a
| particularly good or optimal one even. If you had an API or cli
| already, it's a bit redundant to add MCP. Auth is indeed a key
| challenge. And largely not solved yet. I don't think MCP adds a
| whole lot of new elements for that.
| zhdc1 wrote:
| Or just rapidly spinning up something.
|
| Codex -> LiteLLM -> VLLM |____> MCP
|
| Takes a couple of minutes to setup.
| CuriouslyC wrote:
| CLIs are technically better for a number of reasons.
|
| If an enterprise already has internal tooling with authn/z,
| there's no reason to overlay on top of that.
|
| MCPs main value is as a structured description of an agent-
| usable subset of an API surface with community traction, so you
| can expect it to exist, be more relevant than the OpenAPI docs.
| woeirua wrote:
| Anthropic says that Skills and MCPs are complementary, and
| frankly the pure Skills zealots tend to miss that in enterprise
| environments you'll have chatbots or the like that don't have
| access to a full CLI. It doesn't matter if your skills tell the
| agent exactly what to do if they can't execute the commands.
| Also, MCP is better for restricted environments because you know
| exactly what it can or cannot do. That's why MCP will exist for
| some time still. They solve distinct problem sets.
| nostrebored wrote:
| > Also, MCP is better for restricted environments because you
| know exactly what it can or cannot do.
|
| The continuous exploits of MCP despite limited adoption really
| makes this seem wrong.
| jauntywundrkind wrote:
| I've remained leaning a bit towards MCP until lately. Both have
| pretty easy ways to call the other (plenty of cli API callers,
| and tools like mcp-cli for the reverse
| https://github.com/philschmid/mcp-cli). Skills have really made
| progressive discovery if cli-tools much better, and MCP design
| has adapted likewise. I've lightly preferred MCP for formalism,
| for it feeling more concrete as a thing.
|
| But what really changed my mind is seeing how much more casual
| scripting the LLMs do these days. They'll build rad unix pipes,
| or some python or node short scripts. With CLI tools, it all
| composes: every trick it learns can plug directly into every
| other capability.
|
| Where-as with MCP, the LLM has to act as the pipe. Tool calls
| don't compose! It can read something like this tmux skill then
| just adapt it in all sorts of crazy ways! It can sort of do that
| with tool calls, but much less so.
| https://github.com/nickgnd/tmux-mcp
|
| I'd love to see a capnproto capnweb or some such, with third
| party handoff (apologies Kenton for once again raising 3ph),
| where a tool call could return a result and we could forward the
| result to a different LLM, without even waiting for the result to
| come back. If the LLM could compose tool calls, it would start to
| have some parity with the composability of the cli+skill. But it
| doesn't. And as of very recently I've decided that is too strong
| a selling point to be ignored. I also just like how the cli
| remains the universe system: if these are so isomorphic as I keep
| telling myself, what really does the new kid on the block really
| bring? How much is a new incarnation better if their capabilities
| are so near? We should keep building cli tools, good cli tools,
| so that man and machine benefit.
|
| That said I still leave the beads mcp server around. And I turn
| on the neovim MCP when I want to talk to neovim. Ah well. I
| should try harder to switch.
| senordevnyc wrote:
| I love the idea of MCP, but it needs a progressive disclosure
| mechanism. A large MCP from a provider with hundreds or even
| thousands of tools can eat up a huge amount of your context
| window. Additionally, MCPs come in a bunch of different flavors
| in terms of transport and auth mechanisms, and not all harnesses
| support all those options well.
|
| I've gone the other way, and used MCP-CLI to define all my MCP
| servers and wrap them in a CLI command for agent use. This lets
| me easily use them both locally and in cloud agents, without
| worrying about the harness support for MCP or how much context
| window will be eaten up. I have a minimal skill for how to use
| MCP-CLI, with progressive disclosure in the skill for each of the
| tools exposed by MCP-CLI. Works great.
|
| All that said, I do think MCP will probably be the standard going
| forward, it just has too much momentum. Just need to solve
| progressive disclosure (like skills have!) and standardize some
| of the auth and transport layer stuff.
| didibus wrote:
| I thought Claude Code and others do progressive disclosure for
| MCP now as well.
|
| The article claims so:
|
| > Smart Discovery: Modern apps (ChatGPT, Claude, etc.) have
| tool search built-in. They only look for and load tools when
| they are actually needed, saving precious context window.
| senordevnyc wrote:
| The article made a number of claims I know to be false, so I
| wouldn't take it as gospel.
| avinashselvam wrote:
| skills and mcp help with entirely different things. sure most
| products add a skill on using their mcp so that model's tool
| calling works good.
| lyime wrote:
| auth
| nout wrote:
| Use both. These do different things.
| turlockmike wrote:
| Or use both. Remote MCPs are secure, CLI allows for programmatic
| execution. Use bash to run remote MCPs.
|
| I built this to solve this exact problem.
| https://github.com/turlockmike/murl
| nostrebored wrote:
| What about remote MCPs lend themselves to security? For
| instance, do you think that it is more secure than a
| traditional endpoint?
| turlockmike wrote:
| MCPs are basically just JSON-rpc. The benefit is that if you
| have applications that require an API key, you can build a
| server to control access (especially for enterprise). It's
| the same as REST apis, except by following a specific
| convention we can take advantage of generic tools (like the
| one I built) and means you don't need to rely on poor
| documentations to connect or train a model to use your very
| specific CLI.
| nostrebored wrote:
| But if you have customer facing APIs then all of these
| problems were already solved in an enterprise context. You
| can force an oauth flow from skills if you want.
|
| I don't think that CLIs are the path forward either, but
| you certainly don't have to teach a model how to use them.
| We've made internal CLIs that adhere to no best practices
| and expose limited docs. Models since 4o have used them
| with no issue.
|
| The amount of terminal bench data is just much higher and
| more predictable in rl environments. Getting a non thinking
| model to use an MCP server, even hosted products, is an
| exercise in frustration compared to exposing a cli.
|
| A lot of our work is over voice, and I've found zero MCPs
| that I haven't immediately wanted to wrap in a tool. I've
| actually had zero MCPs perform at all (most recently last
| week with a dwh MCP and opus 4.6, where even the easiest
| queries did not work at all).
| turlockmike wrote:
| LLMs don't care about mcp vs CLI. CLIs enable LLMs to
| fetch/mutate data and build scripts with the same
| program. I think of it like a Linux dev in a box.
| Sometimes you want to just call a tool, sometimes you
| want to write a small program that calls that tool
| instead.
| Aperocky wrote:
| Occams Razor spares none.
|
| Everything will go to the simplest and most convenient, often
| both, despite the resistance of the complexity lovers.
|
| Sorry MCP, you are not as simple as CLI/skill/combination, and
| no, you are not more secure just because you are buried under 3
| level of spaghetti. There are no reason for you to exist, just
| like Copilot. I don't just wish, but know you'll go into
| obscurity like IE6.
| econ wrote:
| A webpage with a form should be good enough.
| j16sdiz wrote:
| Thanks for the 3x context usages because it need to follow the
| installation steps. and extra credit for the auth token leaks
| because it is sent in every call as context.
| Aperocky wrote:
| Anything you said here just demonstrate that you don't really
| understand the differences between MCP and CLI.
|
| MCP is just wrapper on top of API layer that RCP to a
| worker/daemon. That API layer itself can be the CLI. You get
| no more context usage, and no extra security impact, because
| fundamentally the model are the same, just without the fluff.
|
| You are probably thinking of CLI as in "oh I must pass
| everything and it is stateless", only some need to be like
| that.
| olalonde wrote:
| That's "Worse is better" rather than "Occam's razor".
| lukewarm707 wrote:
| i use mcp for security. you can have an airgapped agent that
| can still call online tools. for example, web search.
|
| however it can't get infected because there is no internet
| access.
|
| the worst you can do is put your secrets in the web search box
| Aperocky wrote:
| You can have that with CLI.
|
| MCP is just a wrapper on top, there are no inherent
| differences other than complexity on top.
|
| How do you think MCP work under the hood?
| ok_dad wrote:
| People in the comments still confused about "agentic development"
| vs. "agentic development". One uses the cli best, while the other
| cannot use a cli very well.
|
| The first is using agents locally to develop.
|
| The second is developing an agent. Not necessarily for coding,
| mind you. Not even for just text sometimes.
|
| They are different cases, MCP is great for the latter.
| tpoacher wrote:
| > Skills are great for pure knowledge and teaching an LLM how to
| use an existing tool. But for giving an LLM actual access to
| services, the Model Context Protocol (MCP) is the far superior,
| more pragmatic architectural choice.
|
| There's your answer. If you want to use local tools, use Skills.
| If you want to use services, use MCP. Or, you know, whatever
| works best for your scenario.
| lewisjoe wrote:
| > ChatGPT can't run CLIs. Neither can Perplexity or the standard
| web version of Claude. Unless you are using a full-blown compute
| environment (like Perplexity Computer, Claude Cowork, Claude
| Code, or Codex), any skill that relies on a CLI is dead on
| arrival.
|
| Incorrect observation. Claude web does support skills upload. I
| guess claude runs code_interpreter tool and filesystem in the
| background to run user uploaded skills. ChatGPT business plans
| too allow uploading custom skills in web.
|
| I can see Skills becoming a standard soon. But the concern still
| holds. When you publish a MCP you liberate the user out of
| installing anything. But with skills what happens if the skill
| running environment don't have access to the cli binary or if it
| isn't in PATH?
| simonw wrote:
| Yeah, regular web chat Claude and ChatGPT both have full
| container access (even on the free version, at least for
| ChatGPT) which can run CLI tools.
|
| Both of them can even _install_ CLI tools from npm and PyPI -
| they 're limited in terms of what network services they can
| contact aside from those allow-listed ones though, so CLI tools
| in those environments won't be able to access the public web.
|
| ... unless you find the option buried deep in Claude for
| enabling additional hosts for the default container environment
| to talk to. That's a gnarly lethal trifecta exfiltration risk
| so I recommend against it, but the option is there!
|
| More notes on ChatGPT's ability to install tools:
|
| - https://simonwillison.net/2026/Jan/26/chatgpt-containers/
| medbar wrote:
| I still use vanilla Claude Code without MCP or skills, am I in
| the minority? Not trying to be a luddite.
| tim-projects wrote:
| Me too just use AGENTS.md and it seems to work. I don't
| understand what problem MCP is trying to solve and skills just
| sounds like something you can do in AGENTS.md
|
| What am I missing out on?
| throwpoaster wrote:
| Repeatability (see my response to op).
| blitzar wrote:
| I would guess the top 10% of actual performers do the same -
| the people who talk about harnesses and chain multiple systems
| together etc will be mid table somewhere
| throwpoaster wrote:
| Skills and MCP are useful for when you need to repeat specific
| processes, perpetually. Without them the task description and
| reasoning falls out of the context window, or is compressed,
| and the process fails.
|
| An agent will eventually forget, or hallucinate, guardrails and
| requirements. Yes to AGENTS.md, but when you're actively
| managing the whole context window in a long-running task you
| don't want to just keep jamming stuff in there and hope for the
| best. Skills help budget tokens and stabilize around specific
| outcomes.
|
| If your use case is not agentic, as you build a skill corpus
| you can begin having the model reason at higher and higher
| levels about the outcomes you're aiming at.
|
| Eg: I'm super lazy now and ask Claude to launch the project
| instead of just running the command myself. This is probably
| best done as a skill.
| tim-projects wrote:
| AGENTS.md doesn't fall out of the context window so you just
| put whatever commands you use in there. Every time it gets
| too big you rewrite it.
|
| Never had an issue doing this
| heckintime wrote:
| AI tools for non technical users that can work on browsers and
| mobile app will be super powerful. I think MCPs are currently the
| best way to reach this audience.
| imron wrote:
| My biggest gripe with skills is that even clear and explicit
| instructions are regularly ignored - even when the skill is brief
| (< 100 lines).
|
| I'll often see the agent saying it's about to do something so
| I'll stop it and ask "what does the xxx skill say about doing
| that?' And it'll go away and think and then say "oh, the skill
| says I should never do that"
| latentsea wrote:
| Different tools for different jobs man... I prefer the right tool
| for the job, and both skills and MCP seem necessary. Do you also
| prefer forks over spoons?
| blitzar wrote:
| > Do you also prefer forks over spoons?
|
| On the 8th day god created the spork.
| bijowo1676 wrote:
| MCP pollutes the context, if you dont care about wasting context
| token for all MCP tools, go ahead and use MCP, but you should
| know that cli tool+skill can perfectly replace it with less token
| overhead and better matching due to skill's front matter
| miroljub wrote:
| That really depends on how your harness implements MCP client.
| There are implementations that don't pollute context any more
| than CLIs, but if one uses only CC, he would never know.
| anaisbetts wrote:
| Sure but on the flip side, skills not being in context means
| that for many harnesses, the model simply never finds them.
| Whether MCP or Skills are "better" depends extremely heavily on
| the context management functionality of your harness because if
| you use a relatively naive harness (i.e. one that implements
| MCP and Skills in a straightforward way), MCPs will generally
| be more effective, especially if your model is local-only (i.e.
| dumb), but at the cost of context.
| michaelashley29 wrote:
| 100% MCPs truly give the agent tools and allow the agent to make
| better informed decisions given you can have configured the right
| MCP tools. Skills are good for knowledge and general guidelines.
| They give context to the agent, and I have seen some skills being
| excessively long that could into eat into the context window of
| the agent. This tool https://protomcp.io/ helps a lot with
| testing MCP servers before integrating into the agent workflow.
| You can even see the agent call different tools in real time and
| view the trace.
| Xenoamorphous wrote:
| I use both and don't feel they're mutually exclusive.
|
| E.g. if I have some ElasticSearch cluster, I use a skill to
| describe the data, and if I ask the LLM to write code that
| queries ElasticSearch but to test it first it can use a
| combination of skill + MCP to actually run a query.
|
| I think this model works nicely.
| simianwords wrote:
| SKILLS.md or AGENTS are good concepts but they miss two crucial
| things that will make them much more usable. I predict that this
| will happen.
|
| Each SKILLS.md will come with two hooks:
|
| 1. first for installing the SKILL itself - maybe install the CLI
| or do some initial work to get it working
|
| 2. Each skill may have dependencies on other skills - we need to
| install those first
|
| Expressing these two hooks in a formal way in skills would help
| me completely replace MCP's.
|
| My concrete prediction is that this will happen soon.
|
| Wrote more about it here: https://simianwords.bearblog.dev/what-
| agent-skills-misses-no...
| pjmalandrino wrote:
| Not same tools, different purpose from my opinion
| qalmakka wrote:
| CLI is massively superior to MCP in my experience. First, because
| I also understand what's going on and do it myself if necessary.
| Second because it's so much cheaper in terms of tokens it's not
| even funny
| nodomain wrote:
| The whole article serves just to promote his SaaS.
| baq wrote:
| Remote MCP solve the delivery and update issues just like saas
| and browsers did for human users. Not much more to it really
| usrbinbash wrote:
| > The core philosophy of MCP is simple: it's an API abstraction.
| The LLM doesn't need to understand the how; it just needs to know
| the what.
|
| Wrong. It needs to "understand" both these things. The only
| difference is where and how the strings explaining them are
| generated.
| dgb23 wrote:
| That's an important point.
|
| Whether it's tools, MCP or skills: they are fundamentally all
| just prompts. Even if the LLM is trained to recognize those and
| produce the right shape of tokens that validate most of the
| time.
|
| But I wouldn't use the word "understand" here, because that
| builds the wrong intuition. I think a more useful term would be
| "get guided by" or "get nudged by". Even "recognize" is
| slightly misleading, because it implies too much.
| simianwords wrote:
| Yesterday I accidentally stumbled on a place where I could really
| appreciate MCP's.
|
| 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.
| nextaccountic wrote:
| > Context Bloat: Using a skill often requires loading the entire
| SKILL.md into the LLM's context window, rather than just exposing
| the single tool signature it needs. It's like forcing someone to
| read the entire car's owner's manual when all they want to do is
| call car.turn_on().
|
| 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
| gum_wobble wrote:
| > A solution is to have the agent run a cli tool to access mcp
| services.
|
| lol and why do you need mcp for that, why cant that be a
| classic http request then?
| senordevnyc wrote:
| I use this pattern with mcp-cli, and I do that instead of a
| curl request for two reasons: 1) not leaking my creds into
| the agent session, and 2) so I can allowlist / denylist
| specific tools on an MCP server, which I can't do as easily
| if I give the agent an API token and curl.
| mathis-l wrote:
| At least when working with local MCP servers I solved this
| problem by wrapping the mcp tools inside an in-memory
| cache/store. Each tool output gets stored under a unique id and
| the id is returned with the tool output. The agent can then
| invoke other tools by passing the id instead of generating all
| the input. Adding attribute access made this pretty powerful
| (e.g. pass content under tool_return_xyz.some.data to tool A as
| parameter b). This saves token costs and is a lot faster.
| Granted, it only works for passing values between tools but I
| could imagine an additional tool to pipe stuff into the storage
| layer would solve this.
| dvcrn wrote:
| > MCP has severe context bloat just by starting a thread
|
| Hi, author here. The "MCP has severe context bloat" problem has
| already been solved with tool discovery. Modern harnesses don't
| load every single tool + their descriptions into the context on
| load, but use tool search to discover the tools lazily when
| they're needed. You can further limit this by telling the LLM
| exactly which tool to load, the rest will stay unloaded /
| invisible
|
| > But a worse problem is that the output of MCP goes straight
| into the context of the agent, rather than being piped
| somewhere else
|
| This is semi-solved as agents and harnesses get smarter. Claude
| Code for example does discovery in subagents. So it spawns a
| sub-agent with a cheaper model that explores your codebase /
| environment (also through MCP) and provides a summary to the
| parent process. So the parent won't get hit with the raw output
| log
| nextaccountic wrote:
| > Claude Code for example does discovery in subagents.
|
| but this still burns tokens needlessly in the subagent. if
| the agent could filter the mcp output using a cli (often jq,
| but sometimes something else), it could be more economical
|
| maybe anthropic wants you to burn those tokens though
| seyz wrote:
| MCP versus Skills -> wrong debate. MCP versus CLI -> real debate.
| s-xyz wrote:
| I never understood why there is a discussion about it, one or the
| other... both serve a different purpose and are complementary.
| lifeisstillgood wrote:
| I agree for a slightly different reason - human stupidity.
|
| Despite many decades of proof that automation simplifies and
| reveals the illogical in organisations, digitisation has mostly
| stopped at below the "CXO" level - and so there are not APIs or
| CLIs available to anyone - but MCP is cutting through
|
| Just consider:
|
| Throughout companies large and small, Agile is what coders do,
| real project managers still use deadlines and upfront design of
| what will be in the deadline - so any attempt to convert the
| whole company to react to the reality of the road is blocked
|
| Reports flow upwards - but through the reporting chain. So those
| PowerPoints are ... massaged to meet to correct story, and the
| more levels it's massaged the more it fails to resemble reality.
| Everyone knows this but managing the transition means potentially
| losing control ...
|
| There are plenty of digitisationmprojects going on - but do they
| enable full automation or are they another case of an existing
| political arena building its own political choices in software -
| "our area in a database to be accessed via an UI by our people" -
| almost never "our area to be used by others via API and totally
| replacing our people".
|
| (I think I need to be more persuasive
| nimonian wrote:
| I'm with you on this (I think). Digitising my org is much
| easier if I can assume my colleagues' agents will be acting on
| their behalf. Even if I can't convince most humans to cooperate
| with solutions, I can usually trust their agents to do so. MCP
| hides the wiring somewhat, which I enjoy.
| tomaytotomato wrote:
| As others have said I have found CLI tools much better
|
| This is how I am structuring stuff in Claude Code
|
| - Ansible setup github cli, git, atlassian cli, aws-cli,
| terraform cli tooling
|
| - Claude hooks for checking these cli tools are authenticated and
| configured
|
| - Claude skills to use the CLI tooling
| antirez wrote:
| Don't focus on what _you_ prefer: it does not matter. Focus on
| what tool the LLM requires to do its work in the best way. MCP
| adds friction, imagine doing yourself the work using the average
| MCP server. However, skills alone are not sufficient if you want,
| for instance, creating the ability for LLMs to instrument a
| complicated system. Work in two steps:
|
| 1. Ask the LLM to build a tool, under your guide and
| specification, in order do a specific task. For instance, if you
| are working with embedded systems, build some monitoring
| interface that allows, with a simple CLI, to do the debugging of
| the app as it is working, breakpoints, to spawn the emulator, to
| restart the program from scratch in a second by re-uploading the
| live image and resetting the microcontroller. This is just an
| example, I bet you got what I mean.
|
| 2. Then write a skill file where the usage of the tool at "1" is
| explained.
|
| Of course, for simple tasks, you don't need the first step at
| all. For instance it does not make sense to have an MCP to use
| git. The agent knows how to use git: git is comfortable for you,
| to use manually. It is, likewise, good for the LLM. Similarly if
| you always estimante the price of running something with AWS,
| instead of an MCP with services discovery and pricing that needs
| to be queried in JSON (would you _ever_ use something like that?)
| write a simple .md file (using the LLM itself) with the prices of
| the things you use most commonly. This is what you would love to
| have. And, this is what the LLM wants. For complicated problems,
| instead, build the dream tool you would build for yourself, then
| document it in a .md file.
| tomaytotomato wrote:
| Although the author is coming from a place of security and
| configuration being painful with Skills, I think the future
| will be a mix of MCP, Agents and Skills. Maybe even a more
| granular defined unit below a skill - a command...
|
| These commands would be well defined and standardised, maybe
| with a hashed value that could be used to ensure re-usability
| (think Docker layers).
|
| Then I just have a skill called:
|
| - github-review-slim:latest - github-review-security:8.0.2
|
| MCPs will still be relevant for those tricky monolithic
| services or weird business processes that aren't logged or
| recorded on metrics.
| senordevnyc wrote:
| Commands are already a thing, but they're falling out of
| favor because a user can just invoke a skill manually
| instead.
| prohobo wrote:
| 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 persistent
| manner, and if that app provides an MCP server, use it.
|
| - If you need to interact with an online service in a
| persistent manner, and if that app provides an MCP server, use
| it.
|
| Whether the MCP server is implemented well is a whole other
| question. A properly configured MCP explains to the agent how
| to use it without too much context bloat. Not using a proper
| MCP for persistent access, and instead trying to describe the
| interaction yourself with skill files, just doesn't make any
| sense. The MCP owner should be optimizing the prompts to help
| the agent use it effectively.
|
| MCP is the absolute best and most effective way to integrate
| external tools into your agent sessions. I don't understand
| what the arguments are against that statement?
| xyzzy123 wrote:
| 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.
| prohobo wrote:
| Right, that feels like something you'd do with a script and
| some API calls.
|
| MCP is more for a back and forth communication between
| agent and app/service, or for providing tool/API awareness
| during _other_ tasks. Like MCP for Jira would let the AI
| know it _can_ grab tickets from Jira when needed while
| working on other things.
|
| I guess it's more like: the MCP isn't for us - it's for the
| agent to decide when to use.
| xyzzy123 wrote:
| I just find that e.g. cli tools scale naturally from tiny
| use cases (view 1 ticket) to big use cases (view 1000
| tickets) and I don't have to have 2 ways of doing things.
|
| Where I DO see MCPs getting actual use is when the auth
| story for something (looking at you slack, gmail, etc) is
| so gimped out that basically, regular people can't access
| data via CLI in any sane or reasonable way. You have to
| do an oauth dance involving app approvals that are
| specifically designed to create a walled garden of
| "blessed" integrations.
|
| The MCP provider then helpfully pays the integration tax
| for you (how generous!) while ensuring you can't do
| inconvenient things like say, bulk exporting your own
| data.
|
| As far as I can tell, that's the _actual_ sweet spot for
| MCPs. They're sort of a technology of control, providing
| you limited access to your own data, without letting you
| do arbitrary compute.
|
| I understand this can be considered a feature if you're
| on the other side of the walled garden, or you're
| interested in certain kinds of enterprise control. As a
| programmer however I prefer working in open ecosystems
| where code isn't restricted because it's inconvenient to
| someone's business model.
| hadlock wrote:
| >while ensuring you can't do inconvenient things like
| say, bulk exporting your own data
|
| I think this is the key; I want my analysts to be able to
| access 40% of the database they need to do their job, but
| not the other 60% parts that would allow them to dump the
| business-secrets part of the db, and start up business
| across the street. You can do this to some extent with
| roles etc but MCP in some ways is the data firewall as
| your last line of protection/auth.
| michaelbuckbee wrote:
| MCPs are for documentation. CLI->API is for interaction.
| insin wrote:
| You can make it compose by also giving the agent the
| necessary tools to do so.
|
| I encountered a similar scenario using Atlassian MCP
| recently, where someone needed to analyse hundreds of
| Confluence child pages from the last couple of years which
| all used the same starter template - I gave the agent a
| tool to let it call any other tool in batch and expose the
| results for subsequent tools to use as inputs, rather than
| dumping it straight into the context (e.g. another tool
| which gives each page to a sub-agent with a structured
| output schema and a prompt with extraction instructions, or
| piping the results into a code execution tool).
|
| It turned what would have been hundreds of individual tool
| calls filling the context with multiple MBs of raw
| confluence pages, into a couple of calls returning relevant
| low-hundreds of KBs of JSON the agent could work further
| with.
| xyzzy123 wrote:
| Hmm, but you can't write a standard MCP (e.g.
| batch_tool_call) that calls other MCPs because the
| protocol doesn't give you a way to know what other MCPs
| are loaded in the runtime with you or any means to call
| them? Or have I got that wrong?
|
| So I guess you had to modify the agent harness to do
| this? or I guess you could use... mcp-cli ... ??
| jmcodes wrote:
| I don't maintain this anymore but I experimented with
| this a while back: https://github.com/jx-codes/lootbox
|
| Essentially you give the agent a way to run code that
| calls MCP servers, then it can use them like any other
| API.
|
| Nowadays small bash/bun scripts and an MCP gateway proxy
| gets me the same exact thing.
|
| So yeah at some level you do have to build out your own
| custom functionality.
| losvedir wrote:
| But in the context of this discussion, Atlassian has a
| CLI tool, acli. I'm not quite following why that wouldn't
| have worked here. As a normal CLI you have all the power
| you need over it, and the LLM could have used it to fetch
| all the relevant pages and save to disk, sample a couple
| to determine the regular format, and then write a script
| to extract out what they needed, right? Maybe I don't
| understand the use case you're describing.
| insin wrote:
| Not all agents are running in your CLI or even in any
| CLI, which is why people are arguing past each other all
| over the topic of MCP.
|
| I implemented this in an agent which runs in the browser
| (in our internal equivalent of ChatGPT or Claude's web
| UI), connecting directly to Atlassian MCP.
| __alexs wrote:
| The agent _cannot_ compose MCPs.
|
| What it _can_ do is call multiple MCPs, dumping tons of
| crap into the context and then separately run some
| analysis on that data.
|
| Composable MCPs would require some sort of external
| sandbox in which the agent can write small bits of code
| to transform and filter the results from one MCP to the
| next.
| hrimfaxi wrote:
| They can already do this, no? MCPs regularly dump their
| results to a textfile and other tools (cli or otherwise)
| filter it.
| insin wrote:
| At the level of the agent, it knows nothing about MCP,
| all it has is a list of tools. It can do anything the
| tools you give it let it do.
| __alexs wrote:
| It cannot do "anything" with the tools. Tools are very
| constrained in that the agent must insert into it's
| context the tool call, and it can only receive the
| response of the tool directly back into its context.
|
| Tools themselves also cannot be composed in any SOTA
| models. Composition is not a feature the tool schema
| supports and they are not trained on it.
|
| Models obviously understand the general concept of
| function composition, but we don't currently provide the
| environments in which this is actually possible out side
| of highly generic tools like Bash or sandboxed execution
| environments like https://agenttoolprotocol.com/
| csallen wrote:
| This is confusing to me. What is composability if not
| calling a program, getting its program, and feeding it
| into another program as input? Why does it matter if that
| output is stored in the LLM's context, or if it's stored
| in a file, or if it's stored ephemerally?
|
| Maybe I'm misunderstanding the definition of
| composability, but it sounds like your issue isn't that
| MCP isn't composable, but that it's wasteful because it
| adds data from interstitial steps to the context. But
| there are numerous ways to circumvent this.
|
| For example, it wouldn't be hard to create a tool that
| just runs an LLM, so when the main LLM convo calls this
| tool it's effectively a subagent. This subagent can do
| work, call MCPs, store their responses in its context,
| and thereby feed that data as input into other MCPs/CLIs,
| and continue in this way until it's done with its work,
| then return its final result and disappear. The main LLM
| will only get the result and its context won't be
| polluted with intermediary steps.
|
| This is pretty trivial to implement.
| somnium_sn wrote:
| Give the model an interpreter like mlua and let it write
| code to compose MCP calls together. This is a well
| established method.
|
| It's the equivalent to calling CLIs in bash, except mlua
| is a sandboxes runtime while bash is not.
| somnium_sn wrote:
| 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
| noodletheworld wrote:
| > 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 it, and the assertion that it is _in general_ , best,
| is what I refer to as "works for me" coolaid.
|
| ...because it probably _does_ work well for you.
|
| ...because you are using a few, good, MCP servers.
|
| However, that doesn't scale, for all the reasons listed by
| the many detractors of MCP.
|
| Its not that it _cant be used effectively_ , it is that _in
| general_ it is a solution that has been incompetently slapped
| on by many providers who dont appreciate how to do it well
| _and_ even then, it scales badly.
|
| It is a bad solution for a solved problem.
|
| Agents have made the problem MCP was solving obsolete.
| prohobo wrote:
| Let's say I made a calendar app that stores appointments
| for you. It's local, installed on your system, and the data
| is stored in some file in ~/.calendarapp.
|
| Now let's say you want all your Claude Code sessions to use
| this calendar app so that you can always say something like
| "ah yes, do I have availability on Saturday for this
| meeting?" and the AI will look at the schedule to find out.
|
| What's the best way to create this persistent connection to
| the calendar app? I think it's obviously an MCP server.
|
| In the calendar app I provide a built-in MCP server that
| gives the following tools to agents: read_calendar, and
| update_calendar. You open Claude Code and connect to the
| MCP server, and configure it to connect to the MCP for all
| sessions - and you're done. You don't have to explain what
| the calendar app is, when to use it, or how to use it.
|
| Explain to me a better solution.
| frotaur wrote:
| Why couldn't the calendar app expose in an API the
| read_calendar and update_calendar functionalities, and
| have a skill 'use_calendar' that describes how to use the
| above?
|
| Then, the minimal skill descriptions are always in the
| model's context, and whenever you ask it to add something
| to the calendar, it will know to fetch that skill. It
| feels very similar to the MCP solution to me, but with
| potentially less bloat and no obligation to deal with
| MCP? I might be missing something, though.
| prohobo wrote:
| Why would I do that if the MCP already handles it? The
| MCP exposes the API with those tools, it explains what
| the calendar app is and when to use it.
|
| Connected MCP tools are also always in the model's
| context, and it works for any AI agent that supports MCP,
| not just Claude Code.
| noodletheworld wrote:
| > The MCP exposes the API with those tools, it explains
| what the calendar app is
|
| So does an API and a text file (or hell, a self
| describing api).
|
| Which is more complex and harder to maintain, update and
| use?
|
| This is a solved problem.
|
| The world doesnt need MCP to reinvent a solution to it.
|
| If we're gonna play the ELI5 game, why does MCP define a
| UI as part of its spec? Why does it define a bunch of
| different resource types of which _only tools_ are used
| by most servers? Why did not have an auth spec at launch?
| Why are there so many MCP security concerns?
|
| These are not idle questions.
|
| They are indicative of the "more featurrrrrres" and "lack
| of competence" that went into designing MCP.
|
| Agents, running a sandbox, with normal standard rbac
| based access control or, for complex operations standard
| stateful cli tooling like the azure cli are fundamentally
| better.
| prohobo wrote:
| How would the AI know about the calendar app unless you
| make the text file and attach it to the session?
|
| Self-describing APIs require probing through calls, they
| don't tell you what you need to know _before_ you
| interact with them.
|
| MCP servers are very simple to implement, and the
| developers of the app/service maintain the server so you
| don't have to create or update skills with incomplete
| understanding of the system.
|
| Your skill file is going to drift from the actual API as
| the app updates. You're going to have to manage it,
| instead of the developers of the app. I don't understand
| what you're even talking about.
| raincole wrote:
| > So does an API and a text file (or hell, a self
| describing api).
|
| That sounds great. How about we standardize this idea? We
| can have an endpoint to tell the agents where to find
| this text file and API. Perhaps we should be a bit formal
| and call it a protocol!
| bavell wrote:
| > How about we standardize this idea? We can have an
| endpoint to tell the agents where to find this text file
| and API
|
| Good news! It's already standardized and agents already
| know where to find it!
|
| https://code.claude.com/docs/en/skills
| juped wrote:
| Why would you put a second, jankier API in front of your
| API when you could just use the API?
| saberience wrote:
| You realize you can just create your own tools and wire
| them up directly using the Anthropic or OpenAI APIs etc?
|
| It's not a choice between Skills or MCP, you can also
| just create your own tools, in whatever language you
| want, and then send in the tool info to the model. The
| wiring is trivial.
|
| I write all my own tools bespoke in Rust and send them
| directly to the Anthropic API. So I have tools for
| reading my email, my calendar, writing and search files
| etc. It means I can have super fast tools, reduce context
| bloat, and keep things simple without needing to go into
| the whole mess of MCP clients and servers.
|
| And btw, I wrote my own MCP client and server from the
| spec about a year ago, so I know the MCP spec backwards
| and forwards, it's mostly jank and not needed. Once I got
| started just writing my own tools from scratch I realised
| I would never use MCP again.
| brabel wrote:
| 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 not leak the
| token? With MCP the token is only usable by the MCP client
| and the LLM does not need to see it. - lots more things MCP
| lets you do, like bundle resources and let the server
| request off band input from users which the LLM should not
| see.
| bitexploder wrote:
| An authnz aware egress proxy that also puts guard rails
| on MCP behavior?
| thepasch wrote:
| > 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
| addandsubtract wrote:
| Meanwhile, I'm using MCP for the LLM to lookup up-to-date
| documentation, and not hallucinate APIs.
| CuriouslyC wrote:
| 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.
| prohobo wrote:
| "MCP is less discoverable than a CLI" - that doesn't make
| any sense in terms of agent context. Once an MCP is
| connected the agent should have full understanding of the
| tools and their use, before even attempting to use them. In
| order for the agent to even know about a CLI you need to
| guide the agent towards it - manually, every single
| session, or through a "skill" injection - and it needs to
| run the CLI commands to check them.
|
| "MCPs needs to implement stateful behavior" - also doesn't
| make any sense. Why would an MCP need to implement stateful
| behavior? It is essentially just an API for agents to use.
| CuriouslyC wrote:
| If you have an API with thousands of endpoints, that MCP
| description is going to totally rot your context and make
| your model dumb, and there's no mechanism for progressive
| disclosure of parts of the tool's abilities, like there
| is for CLIs where you can do something like:
|
| tool --help
|
| tool subcommand1 --help
|
| tool subcommand2 --help
|
| man tool | grep "thing I care about"
|
| As for stateful behavior, say you have the google docs or
| email mcp. You want to search org-wide for docs or emails
| that match some filter, make it a data set, then do
| analysis. To do this with MCP, the model has to write the
| files manually after reading however many KB of input
| from the MCP. With a cli it's just "tool >>
| starting_data_set.csv"
| prohobo wrote:
| This is a design problem, and not something necessarily
| solved by CLI --help commands.
|
| You can implement progressive disclosure in MCP as well
| by implementing those same help commands as tools. The
| MCP should not be providing thousands of tools, but the
| minimum set of tools to _help the AI use the service_. If
| your service is small, you can probably distill the
| entire API into MCP tools. If you 're AWS then you
| provide tools that then _document_ the API progressively.
|
| Technically, you could have an AWS MCP provide _one tool_
| that guides the AI on how to use specific AWS services
| through search /keywords and some kind of cursor logic.
|
| The entire point of MCP is _inherent knowledge of a tool_
| for agentic use.
| fennecbutt wrote:
| >man tool | grep "thing I care about"
|
| Isn't the same true of filtering tools available thru
| mcp?
|
| The mcp argument to me really seems like people arguing
| about tabs and spaces. It's all whitespace my friends.
| kordlessagain wrote:
| Nobody said anything about an API with thousands of
| endpoints. Does that even exist? I've never seen it.
| Wouldn't work on it if I had seen it. Such is the life of
| a strawman argument.
|
| Further, isn't a decorator in Python (like @mcp.tool) the
| easy way to expose what is needed to an API, if even if
| all we are doing is building a bridge to another API?
| That becomes a simple abstraction layer, which most
| people (and LLMs) get.
|
| Writing a CLI for an existing API is a fool's errand.
| CuriouslyC wrote:
| Cloudflare wrote a blog post about this exact case. The
| cloud providers and their CLIs are the canonical example,
| so 100% not a strawman.
| locknitpicker wrote:
| > Writing a CLI for an existing API is a fool's errand.
|
| I don't think your opinion is reasonable or well
| grounded. A CLI app can be anything including a script
| that calls Curl. With a CLI app you can omit a lot of
| noise from the context things like authentication,
| request and response headers, status codes, response body
| parsing, etc. you call the tool, you get a response,
| done. You'd feel foolish to waste tokens parsing
| irrelevant content that a deterministic script can handle
| very easily.
| BeetleB wrote:
| > that MCP description is going to totally rot your
| context and make your model dumb, and there's no
| mechanism for progressive disclosure of parts of the
| tool's abilities,
|
| Completely false. I was dealing with this problem
| recently (a few tools, consuming too many tokens on each
| request). MCP has a mechanism for dynamically updating
| the tools (or tool descriptions):
|
| https://code.claude.com/docs/en/mcp#dynamic-tool-updates
|
| We solved it by providing a single, bare bones tool: It
| provides a very brief description of the types of tools
| available (1-2 lines). When the LLM executes that tool,
| all the tools become available. One of the tools is to go
| back to the "quiet" state.
|
| That first tool consumes only about 60 tokens. As long as
| the LLM doesn't need the tools, it takes almost no space.
|
| As others have pointed out, there are other solutions
| (e.g. having all the tools - each with a 1 line
| description, but having a "help" tool to get the detailed
| help for any given tool).
| medbrane wrote:
| >here's no mechanism for progressive disclosure of parts
| of the tool's abilities
|
| In fact there is:
| https://platform.claude.com/docs/en/agents-and-
| tools/tool-us...
|
| If the special tool search tool is available, then a
| client would not load the descriptions of the tools in
| advance, but only for the ones found via the search tool.
| But it's not widely supported yet.
| troupo wrote:
| > like there is for CLIs where you can do something like
|
| Well, these will fail for a large amount of cli tools.
| Any and all combinations of the following are possible,
| and not all of them will be available, or work at all:
| tool some tools may output usage when
| no arguments are supplied tool -h
| some tools may have a short switch for help tool
| --help some tools may have a long switch for
| help tool help some tools may have
| help as a subcommand tool command some
| tools may output usage for a command with no arguments
| tool command -h some tools may have a short
| switch for command help tool command --help
| some tools may have a long switch for command help
| tool help command some tools may have a help
| command man tool some tools may
| have man pages
|
| examples: grep one-
| line usage and "type grep --help" grep -h
| one-line usage and "type grep --help" grep --help
| extended usage docs man grep very
| extended usage docs python
| starts interactive python shell python -h
| python --help equivalent help output
| ps short list of processes
| ps -h longer list of processes
| ps --help short help saying you can do, for
| example, `ps --help a` ps --help a
| gives an extended help, nothing about a erl
| erl -h erl --help all three start
| Erlang shell man erl No manual
| entry for erl
|
| etc.
|
| Not to say that MCPs are any better. They are written by
| people, after all. So they are as messy.
| coldtea wrote:
| > _" MCP is less discoverable than a CLI" - that doesn't
| make any sense in terms of agent context. Once an MCP is
| connected the agent should have full understanding of the
| tools and their use, before even attempting to use them.
| In order for the agent to even know about a CLI you need
| to guide the agent towards it - manually, every single
| session, or through a "skill" injection - and it needs to
| run the CLI commands to check them._
|
| Knowledge about any MCP is not something special inherent
| in the LLM, it's just an agent side thing. When it comes
| to the LLM, it's just some text injected to its
| prompting, just like a CLI would be.
| Eldodi wrote:
| "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
| CuriouslyC wrote:
| Just to poke some holes in this in a friendly way:
|
| * What algorithm does tool_search use?
|
| * Can tool_search search subcommands only?
|
| * What's your argument for a harness having a hacked in
| bash wrapper nestled into the MCP to handle composition
| being a better idea than just using a CLI?
|
| * Shell + CLI gives you basically infinite workflow
| possibilities via composition. Given the prior point,
| perhaps you could get a lot of that with hacked-in MCP
| composition, but given the training data, I'll take an
| agent's ability to write bash scripts over their ability
| to compose MCPs by far.
| mbreese wrote:
| I think a lot of the MCP arguments conflate MCP the protocol
| versus how we currently discover and use MCP tool servers. I
| think there's a lot of overhead and friction right now with
| how MCP servers are called and discovered by agents, but
| there's no reason why it has to be that way.
|
| Honestly, an agent shouldn't really care how it's getting an
| answer, only that it's getting an answer to the question it
| needs answered. If that's a skill, API call, or MCP tool
| call, it shouldn't really matter all that much to the agent.
| The rest is just how it's configured for the users.
| JamesSwift wrote:
| Hard disagree. Apis and clis have been THOROUGHLY documented
| for human consumption for years and guess what, the models
| have that context already. Not only of the docs but actual in
| the wild use. If you can hook up auth for an agent, using any
| random external service is generally accomplished by just
| saying "hit the api".
|
| I wrap all my apis in small bash wrappers that is just curl
| with automatic session handling so the AI only needs to focus
| on querying. The only thing in the -h for these scripts is a
| note that it is a wrapper around curl. I havent had a single
| issue with AI spinning its wheels trying to understand how to
| hit the downstream system. No context bloat needed and no
| reinventing the wheel with MCP when the api already exists
| Aperocky wrote:
| It's like saying it is very safe and nice to drive a F150
| with half ton of water on the truck bed.
|
| How about driving the same truck without that half ton of
| water?
| mbesto wrote:
| The way I see it is more like this:
|
| - Skills help the LLM answer the "how" to interact with
| API/CLIs from your original prompt
|
| - API is what actually sends/receives the interaction/request
|
| - CLI is the actual doing / instruct set of the
| interaction/request
|
| - MCP helps the LLM understand what is available from the CLI
| and API
|
| They are all complementary.
| Eldodi wrote:
| There was a great presentation at the MCP Dev Summit last
| week explaining MCP vs CLI vs Skills vs Code Mode:
| https://www.figma.com/deck/H6k0YExi7rEmI8E6j6R0th/MCP-Dev-
| Su...
| ReDeiPirati wrote:
| > Don't focus on what you prefer: it does not matter. Focus on
| what tool the LLM requires to do its work in the best way.
|
| I noticed that LLMs will tend to work by default with CLIs even
| if there's a connected MCP, likely because a) there's an
| overexposure of CLIs in training data b) because they are
| better composable and inspectable by design so a better choice
| in their tool selection.
| siva7 wrote:
| > MCP adds friction, imagine doing yourself the work using the
| average MCP server.
|
| Why on earth don't people understand that MCP and skills are
| complementary concepts, why? If people argue over MCP v. Skills
| they clearly don't understand either deeply.
| _pdp_ wrote:
| I won't be surprised if MCP start shipping skills. They
| already ship prompts and other things exposed as resources.
| It is not even difficult to do with the current draft as
| skills can be exposed by convention without protocol changes.
|
| Future version of the protocol can easily expose skills so
| that MCPs can acts like hubs.
| radiospiel wrote:
| Doesn't it already? https://modelcontextprotocol.io/specifi
| cation/2025-11-25/ser...
| _pdp_ wrote:
| these are prompts - similar yes - but not the same
| insin wrote:
| The more things change in tech, the more they stay the same.
|
| The shoe is the sign. Let us follow His example!
|
| Cast off the shoes! Follow the Gourd!
| bavell wrote:
| They're complementary but also have significant overlap.
| Hence all the confusion and strong opinions.
| robot-wrangler wrote:
| > clearly don't understand either deeply
|
| No appetite for that. The MCP vs Skills debate has gradually
| become just a proxy war for the camps of AI skeptics vs AI
| boosters. Both sides view it as another chance to decide
| about more magic vs less, _in absolute terms_ , without doing
| the work of thinking about anything situational. Nuance,
| questions, reasoning from first principles, focusing on
| purely engineering considerations is simply not welcome. The
| extreme factions do tend to agree that it might be a good
| idea to attack the middle though! There's no changing this
| stuff, so when it becomes tiresome it's time to just leave
| the HN comment section.
| neya wrote:
| > Focus on what tool the LLM requires to do its work in the
| best way.
|
| I completely agree with you. There was a recent finding that
| said Agents.md outperforms skills. I'm old school and I
| actually see best results by just directly feeding everything
| into the prompt context itself.
|
| https://vercel.com/blog/agents-md-outperforms-skills-in-our-...
| yunwal wrote:
| How do you shut off particular api calls with an agents.md?
| neya wrote:
| I personally use tool calling for APIs, so really not sure
| (I don't use agents.md per se, I directly stuff info into
| the context window)
| BatteryMountain wrote:
| This is exactly what I do too. Works very well. I have a whole
| bunch of scripts and cli tools that claude can use, most of
| them was built by claude too. I very rarely need to use my IDE
| because of this, as I've replicated some of Jetbrains
| refactorings so claude doens't have to burn tokens to do the
| same work. It also turns a 5 minute claude session into a 10
| second one, as the scripts/tools are purpose made. Its reallly
| cool.
|
| edit: just want to add, i still haven't implemented a single
| mcp related thing. Don't see the point at all. REST + Swagger +
| codegen + claude + skills/tools works fine enough.
| evanmoran wrote:
| This is a great idea. Did you happen to release the source
| for this? I run into this all the time!
| smusamashah wrote:
| > I've replicated some of Jetbrains refactorings
|
| How? Jetbrains in a Java code baes is amazing and very
| thorough on refactors. I can reliably rename, change
| signature, move things around etc.
| gitgud wrote:
| > _For instance it does not make sense to have an MCP to use
| git._
|
| What if you don't want the AI to have any write access for a
| tool? I think the ability to choose what parts of the tool you
| expose is the biggest benefit of MCP.
|
| As opposed to a READ_ONLY_TOOL_SKILL.md that states "it's
| important that you must not use any edit API's..."
| NiloCK wrote:
| Just as easy to write a wrapper to the tool you want to
| restrict. You ban the restricted tool outright, and the
| _skill_ instructs on usage of the wrapper.
|
| Safer than just giving an _instruction_ to use the tool a
| specific way.
| Majromax wrote:
| Anyone who's ever `DROP TABLE`d on a production rather than
| test database has encountered the same problem in meatspace.
|
| In this context, the MCP interface acts as a privilege-
| limiting proxy between the actor (LLM/agent) and the tool,
| and it's little different from the standard best practice of
| always using accounts (and API keys) with the minimum set of
| necessary privileges.
|
| It might be easier in practice to set up an MCP server to do
| this privilege-limiting than to refactor an API or CLI-tool,
| but that's more an indictment of the latter than an
| endorsement of the former.
| the_axiom wrote:
| this comment just assumes skills ori better without dealing
| with any of the arguments presented
|
| low quality troll
| fny wrote:
| This is covered well in the article too. See "The Right Tool
| for the Job" and "Connectors vs. Manuals."
|
| Perhaps the title is just clickbait. :)
| richardlblair wrote:
| I've found makefiles to be useful. I have a small skill that
| guides the LLM towards the makefile. It's been great for what
| you're talking about, but it's also a great way to make sure
| the agent is interacting with your system in a way you prefer.
| morgaesis wrote:
| This is my life motto. Progressive exploration, codifying, use
| your codified workflows.
|
| > for each desired change, make the change easy (warning: this
| may be hard), then make the easy change - Kent Beck
|
| https://x.com/KentBeck/status/250733358307500032
| 1minusp wrote:
| Feels to me like the toolchain for using LLMs in various tasks
| is still in flux (i interpret all of this as "stuff in
| different places like .md or skills or elsewhere that is
| appended to the context window" (i hope that is correct)).
| Shouldnt this overall process be standardized/automated? That
| is, use some self-reflection to figure out patterns that are
| then dumped into the optimal place, like a .md file or a skill?
| jpadkins wrote:
| too early for standardization. resist the urge. Let a bunch
| of ideas flow, then watch the Darwinian process of the best
| setup will be found. Then standardize.
| pizzafeelsright wrote:
| The entire tooling ecosystem is in flux.
|
| Looking forward, the future is ad-hoc disposable software
| that once would take a large team a dozen sprints to release.
|
| Eventually it'll be use case -> spec -> validation -> result.
|
| The tv show Stargate showed different controls that
| scientifically calculated and operated starships so all the
| operator had to do was point the controls in the direction of
| the destination. The ai/computer/hardware knows how to get to
| the result and that result is human driven.
|
| I have evidence of this at work and in my own life with the
| key component being the tooling integration.
| jFriedensreich wrote:
| If your llm sees even a difference between local skill and
| remote MCP thats a leak in your abstraction and shortcoming of
| the agent harness and should not influence the decision how we
| need to build these system for the devs and end users. They way
| this comment thinks about building for agents would lead to a
| hellscape.
| mikestorrent wrote:
| Do you know who you're responding to?
|
| > a difference between local skill and remote MCP
|
| A local skill is a text file with a bunch of explanations of
| what to do and how, and what pitfalls to avoid. An MCP is a
| connection to an API that can perform actions on anything.
| This is a pretty massive difference in terms of concept and I
| don't think it can be abstracted away. A skill may require an
| MCP be available to it, for instance, if it's written that
| way.
|
| Antirez' advice is what I've been doing for a year: use AI to
| write proper, domain-specific tools that you and it can then
| use to do more impressive things.
| jFriedensreich wrote:
| Don't think its relevant who they are if they give advice
| that is based on outdated understanding of how agent
| harnesses are build and how to use MCP in an agent harness
| in the first place. You can serve agent skills via mcp or
| via text files accessed via local tools, if your harness
| makes this look different to the LLM in the end it is just
| a bad harness. The LLM should just see "ways to discover
| skills" and then "use the skills". If skills come from a
| folder or from an MCP is transparent implementation detail.
| This is more than just theoretical, if abstractions like
| the way skills are served leak into the context, this will
| measurably degrade agent performance, depending on model
| more or les severe!
| pojzon wrote:
| This is how I work with my agent harness. Also have skills for
| writing tools and skills.
|
| And I still think ppl dont understand why MCPs are still needed
| and when to use them.
|
| Its actually pretty simple.
| slhck wrote:
| Huh, I think the author might be deliberately ignoring how MCP
| works?
|
| - "CLIs need to be published, managed, and installed" -- same for
| MCP servers which you have to define in your config, and they
| frequently use some kind of "npx mcp-whatever" call.
|
| - "Where do you put the API tokens required to authenticate?" --
| where does an MCP server put them? In your home folder? Some .env
| file? The keychain? Same like CLI tools.
|
| - "Some tools support installing skills via npx skills, but that
| only works in Codex and Claude Code, not Claude Cowork or
| standard Claude" -- sure, but you also can't universally define
| MCP servers for all those tools. You have to go ahead and edit
| the config anyway.
|
| - "Using a skill often requires loading the entire SKILL.md into
| the LLM's context window, rather than just exposing the single
| tool signature it needs" -- yeah, but it's on-demand rather than
| exposing ALL MCP servers' tool signatures. Have you ever tried to
| use playwright MCP?
|
| I just don't buy the "without any setup" argument.
| tow21 wrote:
| This argument always sounds like two crowds shouting past each
| other.
|
| Are you a solo developer, are you fully in control of your
| environment, are you focused on productivity and extremely tight
| feedback loops, do you have a high tolerance for risk: you should
| probably use CLIs. MCPs will just irritate you.
|
| Are you trying to work together with multiple people at
| organizational scale and alignment is a problem; are you working
| in a range of environments which need controls and management, do
| you have a more defensive risk tolerance ... then by the time you
| wrap CLIs into a form that are suitable you will have reinvented
| a version of the MCP protocol. You might as well just use MCP in
| the first place.
|
| Aside - yes, MCP in its current iteration is fairly greedy in its
| context usage, but that's very obviously going to be fixed with
| various progressive-disclosure approaches as the spec develops.
| joshwarwick15 wrote:
| Context usage is a client problem - progressive disclosure can
| be implemented without any spec changes (Claude/code has this
| built in for example). That being said the examples for
| creating a client could be massively expanded to show how to do
| this well
| exossho wrote:
| agree I don't get this discussion anyways Those are two
| different things, and actually they work well together..
| theshrike79 wrote:
| In an organisation we can't limit MCP access. It's all or
| nothing. Everything the user can touch, the MCP can touch.
|
| We can trust humans not to do stupid things. They might
| accidentally delete maybe two items by fat-fingering the UI.
|
| An Agent can delete a thousand items in a second while doing 30
| other things.
|
| With bespoke CLI tools we can configure them so that they
| cannot access anything except specific resources, limiting the
| possible blast radius considerably.
| jjice wrote:
| > In an organisation we can't limit MCP access.
|
| Why not? I'd imagine that you could grant specific
| permissions upon MCP auth. Is the issue that the services
| you're using don't support those controls, or is it something
| else?
| theshrike79 wrote:
| 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.
| pjm331 wrote:
| 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)
| theshrike79 wrote:
| That's what we're doing, but it's annoying. Why can't
| they just let us limit access for the official MCP
| easily?
| jjice wrote:
| 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.
| pojzon wrote:
| "Communism can work we just did not see a good
| implementation of it". If majority of implementations
| fail at it -> protocol is defined incorrectly. With
| security first approach it would not be the case.
| BeetleB wrote:
| Indeed, ever since MCPs came out, I would always either
| wrap or simply write my own.
|
| I needed to access Github CI logs. I needed to write Jira
| stories. I didn't even bother glancing at any of the
| several existing MCP servers for either one of them -
| official or otherwise. It was trivial to vibe code an MCP
| server with _precisely_ the features I need, with the
| appropriate controls.
|
| Using and auditing an existing 3rd party MCP server would
| have been more work.
| morgaesis wrote:
| > We can trust humans not to do stupid things. _hold my beer_
|
| I can definitely delete a thousand items with a typo in my
| bash for loop/pipe. You should always defend against stupid
| or evil users or agents. If your documents are important, set
| up workflows and access to prevent destructive actions in the
| first place. Not every employee needs full root access to the
| billing system; they need readonly access to their records at
| most.
| theshrike79 wrote:
| These people aren't doing bash loops, they're regular non-
| technical people who just want to use an AI Agent to access
| services and aggregate data.
|
| If people accidentally delete stuff, they tend to notice it
| and we can roll back. If an agent does a big whoops, it's
| usually BIG one and nobody notices because it's just
| humming away processing stuff with little output.
|
| An accountant might have access to 5 different clients
| accounts, they need to do their work. They can, with their
| brain, figure out which one they're processing and keep
| them separate.
|
| An AI with the same access via MCP might just decide to
| "quickly fix" the same issue in all 5 accounts to be
| helpful. Actually breaking 7 different laws in the process.
|
| See the issue here?
|
| (Yes the AI is approved for this use; that's not the
| problem here)
| BeetleB wrote:
| > These people aren't doing bash loops, they're regular
| non-technical people who just want to use an AI Agent to
| access services and aggregate data.
|
| Over the last few months, this pattern of discussion has
| become pervasive on HN.
|
| Point.
|
| Counterpoint.
|
| (Not finding a flaw with the counterpoint) "Yeah, but
| most people aren't smart enough to do it right."
|
| I see it in every OpenClaw thread. I see it here now.
|
| I also saw it when agents became a thing ("Agents are bad
| because of the damage they can do!") - yet most of us
| have gotten over it and happily use them.
|
| If your organization is letting "regular non-technical"
| people download/use 3rd party MCPs without understanding
| the consequences, the problem isn't with MCP. As others
| have pointed out in this thread, you can totally have as
| secure an MCP server/tool as a sandboxed CLI.
|
| Having said that, I simply don't understand yours (and
| most of others') examples on how CLI is really any
| different. If the CLI tool is not properly sandboxed,
| it's as damaging as an unsecured MCP. Most regular non-
| technical people don't know how to sandbox. Even where I
| work, we're told to run certain agentic tools in a
| sandboxed environment. Yet they haven't set it up to
| _prevent_ us from running the tools without the sandbox.
| If my coworker massively screws up, does it make sense
| for me to say "No, CLI tools are bad!"?
| tow21 wrote:
| (everything I write about MCP means "remote MCP" by the way.
| Local MCP is completely pointless)
|
| MCP provides you a clear abstracted structure around which
| you can impose arbitrary policy. "identity X is allowed
| access to MCP tool Y with reference to resource pool Z". It
| doesn't matter if the upstream MCP service provides that
| granularity or not, it's architecturally straightforward to
| do that mapping and control all your MCP transactions with
| policies you can reason about meaningfully.
|
| CLI provides ... none of that. Yes, of course you can start
| building control frameworks around that and build whatever
| bespoke structures you want. But by the time you have done
| that you have re-invented exactly the same data and control
| structures that MCP gives you.
|
| "Identity X can access tool Y with reference to resource pool
| Z". That literally is what MCP is structured to do - it's an
| API abstraction layer.
| dec0dedab0de wrote:
| maybe make an mcp that has whatever limitations you need
| baked in?
| contextbloat wrote:
| > Using a skill often requires loading the entire SKILL.md into
| the LLM's context window, rather than just exposing the single
| tool signature it needs.
|
| Isn't this, like, the exact thing MCP is the worst at? You need
| to load the entire MCP into the context even if you're not using
| the MCP's relevant functions. Which is why some people put them
| on subagents, which is like, equivalent to putting the MCP behind
| a CLI function, at which point, why not just have the CLI
| function and selectively load it when yo- OH WAIT, THERE'S A NAME
| FOR THAT!
| choam2426 wrote:
| This tracks with my experience.
|
| I started out building an MCP server for an internal wiki, but
| ended up replacing it with a simple CLI + skill because the wiki
| had no access control and the simpler setup was good enough in
| practice.
|
| I think that's the important boundary, though: once access
| control, auth, or per-user permissions enter the picture, I'd
| much rather have MCP as the interface than rely on local tooling
| conventions.
| alexhans wrote:
| This frames MCP vs Skills as an either/or, but they operate at
| different layers. MCP exposes capabilities and Skills may shape
| how capabilities are used.
|
| Both are useful to different people (and role families) in
| different ways and if you don't feel certain pain points, you may
| not care about some of the value they provide.
|
| Agent skills are useful because they're standardized prompt
| sharing but more than that, because they have progressive
| disclosure so you don't bloat your context with an inefficietly
| designed MCP and their UX is very well aligned such that
| "/SkillBuilder" skills are provided from the start and provide a
| good path for developers or non traditional builders to turn
| conversations into semi or full automation. I use this mental
| model to focus on the iteration pattern and incremental building
| [1].
|
| [1] https://alexhans.github.io/posts/series/evals/building-
| agent...
| bachback wrote:
| the best agent framework in my opinion is Pi. Pi avoids MCP thats
| a good thing. why assume that the planet will migrate from HTTP
| to MCP? no, instead lets assume we have client code we can call.
| we already have a rich ecosystem of HTTP services and packages.
| and if we assume a rewrite for agents we probably wouldn't come
| up with MCP but something more powerful.
| rakamotog wrote:
| There is one area where MCP typically has challenges - Not a
| technical challenge but a practical challenge.
|
| Imagine you are creating an asset which requires multiple API
| calls and your UI is designed to go through a 10-12 step setup
| process for that asset. In practice even if we give one tool for
| LLM to one-shot it, or even if we break it down into 10-12 tools
| the points of hallucinations are much higher.
|
| Contrast this with "skills" and CLI.
| EugeneOZ wrote:
| > Skills are great for pure knowledge and teaching an LLM how to
| use an existing tool. But for giving an LLM actual access to
| services, the Model Context Protocol (MCP) is the far superior
|
| That's it. For some things you need MCP, for some things you need
| SKILLs - these things coexist.
| polyterative wrote:
| why not both
| _pdp_ wrote:
| Scanning through the comments here I am almost certain the
| majority of people in this thread run coding agents on-device.
| Skills that access already available resources is then more
| convenient and you can easily make the argument that it is more
| agronomic.
|
| That being said, majority of users on this planet don't use AI
| agents like that. They go to ChatGPT or equivalent. MCP in this
| case is the obvious choice because it provides remote access and
| it has better authentication story.
|
| In order to make any argument about pro/con of MCP vs Skills you
| first need to find out who is the user.
| Oras wrote:
| > majority of users on this planet don't use AI agents like
| that
|
| Source?
| Jaxkr wrote:
| Common sense. Most users are not running Claude Code or an
| on-device coding agent.
|
| They're using ChatGPT, Gemini, or Claude on the web.
| addandsubtract wrote:
| But I downloaded Claude.exe /s
| thecupisblue wrote:
| I am not 100% sure I follow your train of thought.
|
| Isn't in that case an API what they want?
|
| An "MCP for a local app" is just an API that exposes the
| internal workings of the app. An "MCP for mixpanel" is just an
| API that exposes Mixpanel API behind Auth. There is nothing
| special about them for any type of user. It's just that MCP's
| were "made popular".
|
| For the same type of user, I have built better and smoother
| solutions that included 0 MCP servers, just tools and pure
| API's.Define a tool standard DX and your LLM can write these
| tools, no need to run a server anywhere.
|
| That is also what the author seems to be mistaken about - you
| don't need a CLI. A CLI is used because the DX is nice and
| easily permutable with all the preexisting bash tooling that is
| ingrained into every LLM's dataset. You don't need a .env file
| if you're using an API with a skill. A skill can include a
| script, or mentions of tools, and you are the one who controls
| these.
|
| All in all, the whole "MCP vs Skill" debate online is mostly
| based on fundamental misunderstandings of LLM's and how they
| work, how harnesses work and how API's in general work, with a
| lot of it being fueled by people who have no relevant coding
| experience and are just youtube/twitter "content creators".
|
| Some arguments against MPC's, no matter who is the user:
|
| - MCP is just a noisy, hacky wrapper around an API or IPC
| (well, API behind IPC) - MCP's are too noisy for LLM's to be
| useful long-term, as they require a server. - You don't need an
| MCP, you need an easy accessible API with simple DX that the
| machine can use with as little context and decision making as
| required. - Skills are better than MCP because they basically
| encode the API docs/context in an LLM friendly manner. No need
| to run servers, just push text to system prompt.
| _pdp_ wrote:
| You are mostly right except forgetting that not all SaaS
| companies want their users to shoot themselves in the foot by
| exposing the entire API surface and all of its quirks and
| risks to AI agents.
|
| Furthermore, In many cases some APIs, for better or worse,
| are not even sufficient. For example, the Notion MCP has full
| text search capabilities. Their API allows searching by title
| only. I don't know why but I am sure there are reasons.
|
| MCP looks redundant until you start working with real users
| that don't know a thing about AI agents, programming and
| security.
| thecupisblue wrote:
| Honestly it's on them, not on the users.
|
| In today's day and age, it's absurdly easy to create a
| proxy API for your API that only exposes a subset of
| operations. And not like other "easy" things which depend
| on them having done "the right thing" before, like OpenAPI
| specs, auth scoping etc. This is so easy, even corporations
| consider it easy, and everything there is a PITA.
|
| This is simple to make, to document and since it's a proxy
| you're also able to include all bunch of LLM friendly
| shenanigans and overly verbal errors with suggestions to
| fix.
|
| Shit, I should obviously make a SaaS for this, huh?
| 0x696C6961 wrote:
| If this is not /s then you need to read the MCP spec.
| vasco wrote:
| More agronomic means shittier, eh? I guess you meant ergonomic
| but funny typo
| _pdp_ wrote:
| Yep, and yes my bad. I typed the comment quickly without
| using AI.
| fedeb95 wrote:
| I think both will stick around because they solve two different
| problems. 1) what are you able to do (skills) 2) which tools you
| have to do it (mcp)
| mantyx wrote:
| Having developed mantyx.io, I believe that rest apis are still
| champion. MCP is nothing more than rest wrappers most of the time
| and skills are cli wrappers which in turn are rest wrappers.
| lukewarm707 wrote:
| i feel like giving an agent shell access and internet is batshit
| crazy.
|
| that's just me i guess.
| mememememememo wrote:
| Like saying I prefer websites over CLI, or bicycles over canoes.
| Chisels over planes. Depends what you are trying to achieve.
| anshulbhide wrote:
| >>>The core philosophy of MCP is simple: it's an API abstraction.
|
| That's exactly the problem. As agents become better and can read
| API documentation themselves, WHY do you need an API abstraction?
| senadir wrote:
| Because not everything run from a terminal.
| chris_money202 wrote:
| I think the worse thing is when someone takes a clearly defined
| list of steps to do something and writes it as a skill rather
| than just having AI write it as a script. It's like people have
| forgot what scripting is
| qrbcards wrote:
| The comparison to app stores is interesting but I think MCP
| registries solve a different problem. App stores are for humans
| browsing. MCP registries are for agents discovering tools at
| runtime based on the task at hand. The user never browses -- they
| describe what they need and the agent finds the tool.
|
| That is a meaningful distribution shift. Products no longer need
| to be marketed to end users if an agent can find and invoke them
| directly. Skills require the developer to install them ahead of
| time, which means someone already decided this tool was relevant.
| nathias wrote:
| MCP is too thristy
| kohlerm wrote:
| Yeah well. MCPs are better for use cases where remote access is
| required, but for development use cases what you need in the
| majority of use cases is to manipulate local files. Skills are
| just the more natural solution here. You can argue whether Skills
| should come with more type information (MCPs are slightly better
| here), but otherwise it seems pretty clear to me that if you do
| not need remote access then MCPs are not really needed.
| alienbaby wrote:
| Different techniques appropriate in different situations, I would
| decide on what's appropriate given the goals you have. Whichg is
| nearly always the answer to X is a better way than Y arguments.
| rd42 wrote:
| I think the key problem is that usage of MCP servers is not
| 'baked' into the LLM training - but API's and CLI's are already a
| part of training. So to use your MCP server, the LLM has to use
| additional intelligence which could have been used to do the
| actual work instead.
| raincole wrote:
| Seriously, the only drawback of MCP is its name. If it were named
| "API discovery protocol" (which is what it is) none of these
| debates would have existed.
|
| API vs MCP sounds like a real debate, but it really isn't. It's
| "API vs API discovery protocol." See how asinine it sounds if we
| call things for what they are.
| TonyAlicea10 wrote:
| I prefer peanut butter over jelly.
| pjmlp wrote:
| Complete in synch with the author MCP and A2A for the win.
| throwpoaster wrote:
| They're different things. You can have skills using MCP.
| fancyraccoon wrote:
| Really interesting post. The "connectors vs manuals" framing
| stuck with me because I think it points at something beyond the
| UX argument. A Skill that papers over an API loses the signal the
| friction was carrying. Working with a raw interface tells you
| something about the design.
|
| The same thing plays out at the language layer. The pain of C++
| multiple inheritance drove people toward better abstractions. If
| LLM's absorb that friction before it reaches anyone, the signal
| that produces the next Go never gets felt by the people who could
| act on it.
|
| Wrote about where that leads:
| https://blog.covet.digital/a/the_last_language_you_can_read....
| coolThingsFirst wrote:
| Can someone more enlightened in this area explain how this is
| used?
|
| Is MCP for in-house LLMs or can it work with ChatGPT as well? As
| far as I know it's a server with small self-contained task
| scripts. But don't get how the coordination works and how it's
| used.
| losvedir wrote:
| For my use I prefer just a raw CLI. As long as it's built
| following conventions (e.g. using cobra for a Go app) then the
| agent will just natively know how to use it, by which I mean how
| to progressively learn what it needs by reading the `help`
| output. In that case you don't need a skill or anything. Just say
| "I want this information, use the xyz app". It will then try `xyz
| --help` or `xyz help` or a variant, just like a human would, see
| the subcommands, do `xyz help subcommand` and eventually find
| what it needs to do the job. Good tools provide an OAuth flow
| like `xyz login`, which will open a browser window where you can
| determine which resources you want to give the CLI (and thereby
| the agent) access to.
|
| This only works for people using agents themselves on computers
| they control, rather than, e.g., the Claude web app, but is a
| good chunk of my usage.
|
| I think people are either over or under thinking the auth piece,
| though. The agent should have access to _their_ own token. Both
| CLIs and MCPs and even raw API requests work this way. I don 't
| think MCPs provide any further security. You should assume the
| agent can access anything in its environment and do everything up
| to what the credential permits. You don't want to give _your_
| more powerful credential to the MCP server and hope that the MCP
| server somehow restricts the agent to doing less (it can probably
| find the credential and make out-of-band calls if it wants). The
| only way I think it could work like that is how... is it Sprite
| does it?... where you give use a fake token and have an off-
| machine proxy that it goes through where it MitMs the request and
| injects the real credential.
| 0x696C6961 wrote:
| You run the MCP server outside of the agent sandbox so it
| doesn't have access to the credentials.
| lukewarm707 wrote:
| yes and also you can firewall the container so that it can
| only contact the mcp/proxy.
|
| this way it doesn't download a trojan or leak your data to
| someone
| briznad wrote:
| Skills are static; MCP servers is dynamic. Skills codify info and
| workflows, help decrease redundant instructions, and increase
| consistent outcomes. MCP servers allow access to changing
| resources across systems.
|
| You may dislike MCP, and there are certainly valid arguments to
| be made there, but that doesn't mean you can replace it with
| skills. If you could replace a given MCP server with a skill it
| would only indicate that someone misunderstood the assignment and
| chose the wrong tool in the first place. It wouldn't indicate the
| superiority of one thing over the other.
|
| This whole article, and it's current rank on HN (#5), is making
| me feel like I took crazy pills this morning. A colleague
| suggests this Skills vs MCP discourse is big on Twitter, so maybe
| I lack the necessary background to appreciate this, but aren't
| these different tools, solving for different things, in different
| ways? Is this parody? Am I falling into a bot engagement trap by
| even responding to this? The article certainly reads like
| LinkedIn drivel, with vague, emphatic opinions about nothing.
| Falimonda wrote:
| Skills are compensation for out-of-distribution task assignment
| (and very valuable training data for model providers)
|
| MCP are tools - might as well have just called it API for AI,
| but that ship has sailed.
|
| It's 100% apples and oranges!
| raincole wrote:
| > I took crazy pills this morning
|
| You should feel so. Every time a thread about MCP on HN
| appears, half of the commenters obviously don't even know what
| MCP actually is and how it's used. Just right below someone
| suggests one should use "an API and a text file" instead of MCP
| (like, what do they think MCP is?).
|
| On Twitter the ratio is even worse.
| the_axiom wrote:
| this is very good and correct
| CharlieDigital wrote:
| One thing that I have found is that the platforms are
| surprisingly poor at consistently implementing MCP, which is
| actually a pretty simple protocol.
|
| Take Codex, for example, it does not support the MCP prompts
| spec[0][1] which is quite powerful because it solves a lot of
| friction with deploying and synchronizing SKILL.md files. It also
| allows customization of virtual SKILL.md files since it allows
| compositing the markdown on the server.
|
| It baffles me why such a simple protocol and powerful capability
| is not supported by Codex. If anyone from OpenAI is reading this,
| would love to understand the reasoning for the poor support for
| this relatively simple protocol.
|
| [0] https://github.com/openai/codex/issues/5059
|
| [1]
| https://modelcontextprotocol.io/specification/2025-06-18/ser...
| password4321 wrote:
| Surprised to see no mention in the article or discussion yet
| about using MCPs in 'code mode', where an API is generated
| client-side relying on MCP primarily as an interface standard.
| I'm still learning but I've read this reduces the amount of
| context required to use the MCP.
|
| It seems like a lot of the discussion is arguing in favor of API
| usage without realizing that MCP basically standardizes a
| universal API, thus enabling code mode.
| WhyNotHugo wrote:
| I like skills because they rely on the same tools which humans
| rely upon. A well-written skill can be read and used by a human
| too.
|
| A skill is just a description for how to use an existing CLI
| tool. You don't need to write new code for the LLM to interact
| with some system. You just tell the LLM to use the same tool
| humans do. And if you find the CLI is lacking in some way, you
| can improve it and direct human usage benefits from that
| improvement too.
|
| On the other hand, an MCP requires implementing a new API for a
| service, an API exclusive to LLMs, and keeping parallel
| documentation for that. Every hour of effort put into it is an
| hour that's taken away from improving the human-facing API and
| documentation.
|
| The way skills are lazy-loaded when needed also keeps context
| clean when they're not used. To be fair, MCPs _could_ be lazy-
| loaded the same way, that 's just an implementation detail.
| interpol_p wrote:
| We had a contention between MCP / Skills for our product and
| ended up offering both. We built a CLI tool that could interface
| with the MCP server [1]. It seems redundant but our app is a
| coding app on iOS (Codea), and the issue with offering a plain
| MCP server meant that the agentic coding harness found it harder
| to do its job.
|
| With the CLI the agent could check out the project, work on it
| locally with its standard file editing / patching / reading
| tools, then push the work back to device. Run and debug on
| device, edit locally, push.
|
| With MCP the agent had to query the MCP server for every read and
| write and was no longer operating in its normal coding loop. It
| still works, though, and as a user you can choose to bypass the
| CLI and connect directly via MCP.
|
| The MCP server was valuable as it gave us a consistent and
| deterministic language to speak. The CLI tool + Skill was
| valuable for agentic coding because it allowed the coding work to
| happen with the standard editing tools used by agents.
|
| The CLI also gave us device discovery. So the agent can simply
| discover nearby devices running Codea and get to work, instead of
| a user having to add a specific device via its IP address to
| their agent.
|
| [1] https://codea.io/cli
| iamsaitam wrote:
| Don't they both solve different problems? This tribalism makes no
| sense.
| cphoover wrote:
| I think language grammars are the an interesting way to define a
| ruleset too. Forget REST API's or MCP Servers for a second...
| Define a domain specific language, and let the language model
| generate a valid instruction within the confines of that grammar.
|
| Than pass the program, your server or application can parse the
| instructions and work from the generated AST to do all sorts of
| interesting things, within the confines of your language
| features.
|
| It's verifiable, since you are providing within the defined
| grammar, and with the parser provided.
|
| It is implicitly sandboxed by the powers you give (or rather
| exclude) to your runtime via an interpreter/compiler
|
| I've tried this before for a grammar I defined for searching
| documents, and found it to be quite good at creating valid often
| complex search instructions.
| Aperocky wrote:
| The most common mistake that I see here is people thinking only
| MCP can be bound to a server and store secrets and be called
| remotely
|
| No, a CLI with RPC can do exactly that, just smaller. It goes
| lower in the exact same stack without the fluff.
| jsw97 wrote:
| From the article: "Sandboxing: Remote MCPs are naturally
| sandboxed. They expose a controlled interface rather than giving
| the LLM raw execution power in your local environment."
|
| I think this is underappreciated. CLI access gives agents a ton
| of freedom and might be more effective in many applications. But
| if you require really fine granularity on permissions -- e.g., do
| lookups in this db and nothing else -- MCP is a natural fit.
| utilize1808 wrote:
| I think skills are just a marketing ploy. There is nothing
| preventing a MCP from serving skills.
| hasyimibhar wrote:
| We use MCP at work. In my team of about 6 people, everyone has
| Claude access, but about half of us are non-engineers. I built an
| MCP over our backend and Clickhouse, and setup a Claude Project
| with instruction (I'm assuming this count as skill?). The
| instruction is mostly for enriching the analytics data that we
| have, e.g. hinting Claude to prefer certain datasets for certain
| questions.
|
| This allows the non-engineers (and also engineers) to use Claude
| Desktop to do day-to-day operations (e.g. ban user X for fraud)
| and analytics (e.g. how much revenue we made past 7 days? Any
| fraud patterns?). The MCP helps to add audit, authorization, and
| approval layer (certain ops action like banning user will require
| approval).
| a960206 wrote:
| I think so,I like only use Claude Code by MCP,let it connect
| socketcluster wrote:
| I prefer skills with simple curl commands. It's easy. You just
| need to create a server with HTTP endpoints and Claude (or other
| LLM) can call them with the curl commands you provide in your
| skills files. Claude is really good with curl and it's a well
| known HTTP client so what Claude is doing is more transparent to
| the user.
|
| Also, with skills, you can organize your files in a hierarchy
| with the parent page providing the most general overview and each
| child page providing a detailed explanation of each endpoint or
| component with all possible parameters and errors. I also made a
| separate page where I list all the common issues for
| troubleshooting. It works very well.
|
| I created some skills for my no-code platform so that Claude
| could access and make changes to the control panel via HTTP. My
| control panel was already designed to update in real-time so it's
| cool to watch it update as Claude creates the schema and adds
| dummy data in the background.
|
| I spent a huge amount of effort on refining my HTTP API to make
| it as LLM-friendly as possible with flexible access control.
|
| You can see how I built my skills marketplace from the docs page
| if anyone is interested: https://saasufy.com/
| 0xbadcafebee wrote:
| I have vibe-coded 4 different software projects recently, on
| multiple platforms. I added search, RAG, ticketing,
| notifications, voice, and more features to them, in 2 minutes.
| All I had to do was implement MCP client, and suddenly all that
| other complex functionality "just worked", both locally and
| remotely.
|
| Skills would have required me to 1) add all the skill files to
| all those projects (and maintain all those files), and 2) install
| software tools (some of these tools don't have CLIs) to be usable
| by the skills. Not to mention: the skills aren't deterministic!
| You have to iterate on a skill file for a while to get the LLM to
| reliably use it the way you want.
| bhewes wrote:
| Nice someone who actual works with the systems. Thank you.
| bharat1010 wrote:
| The MCP vs skills debate feels like it's still very early days --
| I suspect we'll look back in a year and laugh at how much we
| debated this once the patterns become more obvious through real-
| world use.
| hereme888 wrote:
| I see the real argument is against poorly-designed MCP servers
| and where a skill/script would be a better fit.
|
| If all you need is "teach the model how to use an existing tool",
| then use a skill, or even scripts, which are great for bulk work
| or teaching workflows.
|
| MCPs are good at giving agents a stable, app-owned interface to a
| system w/o making the agents having to rediscover the integration
| every session. There's no way a skill/script would be able to
| handle the stuff I do via my local MCPs for managing certain apps
| and databases.
| ookblah wrote:
| mcp 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.
| vonneumannstan wrote:
| They seem like fundamentally different things.
| noisy_boy wrote:
| I feel like MCPs are encapsulation of multiple steps where the
| input to the first step is sufficient to drive the flow. Why
| would I spend tokens for the LLM to do reasoning at each of the
| steps when I can just provide the input + MCP call backed by a
| fixed program that can deal with the overall flow
| deterministically. If I have to do the same series of steps
| everytime, a script beats LLM doing the each step individually in
| terms of cost and time. If the flow involved some sort of fuzzy
| analysis or decision making in multiple places, I would probably
| let the LLM carry out the flow or break it into a combination of
| MCP calls orchestrated by the LLM.
|
| In my case, my MCP is setup with the endpoints being very thin
| LLM facing layer with the meat of the action being done by helper
| methods. I also have cli scripts that import/use the same helpers
| so the core logic is centralized and the only difference is that
| thin layer, which could be the LLM endpoint or cli's argparse. If
| I need another type of interface, that can also call the same
| helpers.
| vamsikrishna21 wrote:
| I do agree on this, but i think this is just for now, as models
| get better reasoning, why cant sklls.md take place of MCP all
| together?
| the_arun wrote:
| Don't know if Skills & MCP are comparable. One is static &
| another is dynamic. It is like comparing static content vs
| dynamic apis. Probably we need both.
| neosat wrote:
| The juxtaposition of MCP _vs_ Skills in the article is very
| strange. These are not competing ways to achieve something.
| Rather skills is often a way to enable an optimization on top of
| MCPs.
|
| A simplified but clarifying way to think about it is that MCP
| exposes all the things that _can_ be done, and Skills encode a
| workflow /expertise/perspective on how something _should_ be done
| given all the capabilities.
|
| So I'm not sure why the article portrays one to be conflicting
| with the other (e.g. "the narrative that "MCP is dead" and
| "Skills are the new standard" has been hammered into my brain.
| Everywhere I look, someone is celebrating the death of the Model
| Context Protocol in favor of dropping a SKILL.md into their
| repository.").
|
| You can just not choose to use a skill if it's not useful. But if
| it's useful a skill can add to what an MCP alone can do.
| hungryhobbit wrote:
| Am I the only one who doesn't trust remote servers?
| localhost3000 wrote:
| How I think about this:
|
| If you're using an agent in a shell environment with unfettered
| internet access and code execution: CLI + Skills.
|
| If you're using a hosted agent on a website or in an app without
| code execution and limited/no internet access: MCP.
|
| We want both patterns. Folks who are agro about MCP do ~all of
| their work in the former, so it seems pointless. Most people
| interact with agents in the later.
| bloppe wrote:
| Every CLI can be expressed as an API and vice versa. Thus every
| skill can be expressed as an MCP server and vice versa. Any
| argument about the technical or practical merits of one over the
| other is willfully ignoring the fact that you can _always_ use
| exactly the same patterns in one vs. the other.
|
| So it's really all about availability or preference. Personally,
| I don't think we needed a whole new standard with all its
| complexities and inevitable future breaking changes etc.
| greza-dev wrote:
| The composability argument against MCP is real, but I think it's
| mostly a tooling maturity problem rather than a fundamental flaw.
| Once you wire up a few solid servers, the model orchestrates them
| in ways you'd never think to hardcode upfront. The magic is
| emergent -- it comes from the model having real-time context, not
| from any single tool.
| uyzstvqs wrote:
| Within the scope of AI coding tools, they both have their place
| and do different things. In the much bigger picture of AI
| assistants, skill.md is irrelevant while MCP is set to become
| huge.
| darepublic wrote:
| This skills obsession is a Claude/anthropic fanboy thing imo.
| Goodbye sweet karma
| upcoming-sesame wrote:
| I prefer CLIs over both
___________________________________________________________________
(page generated 2026-04-10 23:01 UTC)