22 ms·

> I tried to avoid writing this for a long time, but I'm convinced MCP provides no real-world benefit IMO this is 100% correct and I'm glad someone finally sai

> I tried to avoid writing this for a long time, but I'm convinced MCP provides no real-world benefit IMO this is 100% correct and I'm glad someone finally said it. I run AI agents that control my entire dev workflow through shell commands and they are shockingly good at it. the agent figures out CLI flags it has never seen before just from --help output. meanwhile every MCP server i've used has been a flaky process that needs babysitting. the composability argument is the one that should end this debate tbh. you can pipe CLI output through jq, grep it, redirect to files - try doing that with MCP. you can't. you're stuck with whatever the MCP server decided to return and if it's too verbose you're burning tokens for nothing. > companies scrambled to ship MCP servers as proof they were "AI first" FWIW this is the real story. MCP adoption is a marketing signal not a technical one. 242% growth in MCP servers means nothing if most of them are worse than the CLI that already existed

ejholmes 7mo ago
Thanks for reading! And yes, if anyone takes anything away from this, it's around composition of tools. The other arguments in the post are debatable, but not that one.
- p_ing 7mo ago
  MCP provides a real-world benefit. Namely anyone of any skill level who can create agents is able to use them. CLI? Nope.
binsquare 7mo ago
Fully agree. MCP servers were also created at a time where ai and llms were less developed and capable in many ways. It always seemed weird we'd want to post train on MCP servers when I'm sure we have a lot of data with using cli and shell commands to improve tool calling.
- MrDarcy 7mo ago
  It’s telling the best MCP implementations are those which are a CLI to handle the auth flow then allow the agent to invoke it and return results to stdout. But even those are not better for agent use than the human cli counterpart.
femiagbabiaka 7mo ago
How do you segregate the CLI interface the LLM sees versus a human? For example if you’d like the LLM to only have access to read but not write data. One obvious fix is to put this at the authz layer. But it can be ergonomic to use MCP in this case.
- jyaohao 7mo ago
  I’ve been testing with an ENV variable for a cli tool for LLMs that I’m making. Basically, I have a script that sets an ENV variable to launch the TUI that I want and that ENV variable changes the behavior for LLMs if they run it (changes the -h output, changes the default output format to json to make it easier to grep)
- nvllsvm 7mo ago
  I've been running Claude Code in a Docker compose environment with two containers - one without Claude that has all the credentials setup and a Claude container which transparently executes commands via ssh. The auth container then has wrappers which explicitly allow certain subcommands (eg. `gh api` isn't allowed). The `gh` command in the Claude container is just a wrapper script which bassically `ssh auth-container gh-wrapper`. Lots of manual, opinionated stuff in here, but it prevents Claude from even accessing the credentials and limits what it can do with them.
- coppsilgold 7mo ago
  Containers, virtual machines, jails. Containers have jail runtimes available. See for example gVisor/runsc.
  - femiagbabiaka 7mo ago
    None of those work when dealing with external services, I wouldn’t even trust them as a solution for dealing with access to a database. It seems like the pushback against MCPs is based on their application to problems like filesystem access, but I’d say there are plenty of cases in which they are useful or can be a tool used to solve a problem.
kaydub 7mo ago
I avoid most MCPs. They tend to take more context than getting the LLM to script and ingest ouputs. Trying to use JIRA MCP was a mess, way better to have the LLM hit the API, figure out our custom schemas, then write a couple scripts to do exactly what I need to do. Now those scripts are reusable, way less context used. I don't know, to me it seems like the LLM cli tools are the current pinnacle. All the LLM companies are throwing a ton of shit at the wall to see what else they can get to stick.
- icanintospace 7mo ago
  I have had some positive experiences using the Jira and Confluence MCPs. However, I use a third-party MCP because my company has a data centre deployment of Jira and Confluence, which the official Atlassian MCP does not support. My use case was for using it as an advanced search tool rather than for creating tickets or documentation. Considering how poor the Confluence search function is, the results from Confluence via an MCP-powered search are remarkably good. I was able to solve one or two obscure, company-specific issues purely by using the MCP search, and I'm convinced that finding these pages would have been almost impossible without it.
- alejo 7mo ago
  For Jira/Confluence, I also struggled with their MCPs. JIRA’s MCPs was hit or miss and Confluence never worked for me. We don’t use the cloud versions, so not sure if they work better with cloud. On the other hand, i found some unofficial CLIs for both and they work great. I wrote a small skill just to give enough detail about how to format Epics, Stories, etc and then some guidance on formatting content and I can get the agent do anything i need with them.
  - SOLAR_FIELDS 7mo ago
    I deal with a ton of different atlassian instances and the most infuriating thing to me about the mcp configuration is that atlassian really thinks you should only have one atlassian instance to auth against. Their mcp auth window takes you to a webpage where you can’t see which thing you are authoring against forcing you to paste the login page url into an incognito window. Pretty half baked implementation. I noticed that it’s better for some things than others. It’s pretty bad at working with confluence it just eats tokens but if you outlay a roadmap you want created or updated in Jira it’s pretty good at that
juped 7mo ago
Tools eat up so much context space, too. By contrast the shell tool is trained into Claude.
fny 7mo ago
I hate MCP servers That said the core argument for MCP servers is providing an LLM a guard-railed API around some enterprise service. A gmail integration is a great example. Without MCP, you need a VM as scratch space, some way to refresh OAuth, and some way to prevent your LLM from doing insane things like deleting half of your emails. An MCP server built by trusted providers solves all of these problems. But that's not what happened. Developers and Anthropic got coked up about the whole thing and extended the concept to nuts and bolts. I always found the example servers useless and hilarious.[0] Unbelievably, they're still maintained. [0]: https://github.com/modelcontextprotocol/servers/tree/main/src https://github.com/modelcontextprotocol/servers/tree/main/sr...
- ejholmes 7mo ago
  I always get a kick out of seeing MCP wrappers around CLI’s.
  - cglan 7mo ago
    They make a big difference. For example if you use the Jira cli, most LLMs aren’t trained on it. A simple MCP wrapper makes a huge difference in usability unless you’re okay having the LLM poke and prod a bunch of different commands
    - bmurphy1976 7mo ago
      Do you mean wrap the CLI with an MCP? I don't get that approach. I wrapped the Jira cli with a skill. It's taken a few iterations to dial it in but it works pretty damn well now. I'm good, yet my coworkers keep having problems using the Atlassian MCP.
    - ejholmes 7mo ago
      Silly. All it needs is docs. No need to overcomplicate it.
    - ithkuil 7mo ago
      Fwiw I'm having a good experience with a skill using Jira CLI directly. My first attempt using a Jira MCP failed. I didn't invest much time debugging the MCP issues, I just switched to the skill and it just worked. Yes occasionally Claude uses the wrong flag and it has to retry the command (I didn't even bother to fork the skill and add some memory about the bad flag) but in practice it just works
jrm4 7mo ago
This was my gut from the beginning. If they can't do "fully observable" or "deterministic" (for what is probably a loose definition of that word) -- then, what's the point?
notepad0x90 7mo ago
Strongly disagree, despite that meaning I'm swimming upstream here. Unlike cli flags, with MCP I can tune the comments for the tool more easily (for my own MCPs at least) than a cli flag. You can only put so much in a cli --help output. The error handling and debugability is also nicer. Heck, I would even favor writing an MCP tool to wrap cli commands. It's easier for me to ensure dangerous flags or parameters aren't used, and to ensure concrete restrictions and checks are in place. If you control the cli tools it isn't as bad, but if you don't, and it isn't a well known cli tool, the agent might need things like vague errors explaing to it a bit. MCP is more like "REST" or "GRPC", at the simplest level just think of it as a wrapper. You mentioned redirecting to files, what if the output is too much that way, you'll still burn tokens. But with MCP, if the output is too much you can count the tokens and limit, or... better yet you can paginate so that it gets some results, it sees how many results there are and either decides to re-run the tool with params that will yield less results, or consume the results page-by-page.
- bonoboTP 7mo ago
  If you want a validation layer, why not write a cli that wraps the other cli?
  - notepad0x90 7mo ago
    that's what the MCP server is, except I don't always want a cli. If I need to call API on top of a cli tool, i don't have to have a second wrapper, or extend my existing wrapper. You're suggesting I recreate everything MCP does, just so..it's my own? MCP is just a way to use use wrappers other people have built, and to easily manage wrapping "tools", those could be cli tools, api calls, database query,etc.. cli tools aren't aware of the context window either, they're not keeping track of it. I might want my cli tool to output lots of useful text but maybe I don't want some of that for the LLM to save on tokens. Sure, I could create another cli tool to wrap my cli tool, now i have two cli tools to maintain. I'd prefer to do all the wrapping and pre-llm cleanup done in one consistent place. The instructions for the LLM letting it know what tools, parameters,etc.. are available is also defined in a consistent way, instead of me inventing my own scheme. I'd rather just focus on getting a usable agent. I don't get the issue people in this thread have with MCP, is there some burden about it I haven't ran into? It's pretty easy to set one up.
rick1290 7mo ago
When is MCP the right choice though? For example - letting internal users ask questions on top of datasets? Is it better to just offer the api openapi specs and let claude run wild? or provide an MCP with instructions?
- noodletheworld 7mo ago
  MCP is never the right choice. If you want to build an AI app that lets people “do random thing here”, then build an app. Peak MCP is people trying to write a declarative UI as part of the MCP spec (1, I’m not kidding); which is “tldr; embed a webview of a web app and call it MCP”. MCP is just “me too”; people want MCP to be an “AI App Store”; but the blunt, harsh reality is that it’s basically impossible to achieve that dream; that any MCP consumer can have the same app like experience for installed apps. Seriously, if we can barely do that for browsers which have a consistent ui, there was never any hope even remotely that it would work out for the myriad of different MCP consumer apps. It’s just stupid. Build a web app or an API. You don’t need an MCP sever; agents can very happily interact with higher level functions. (1) - https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/ https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-ap...
bonoboTP 7mo ago
Even if the help isn't great, good coding agents can try out the cli for a few minutes and write up a skill, or read the sources or online docs and write up a skill. That takes the spot of the --help if needed. I found that I can spare quite a lot of time, I don't have to type up how to use it, if there is available info about it on the web, in man pages, in help pages, or the source is available, it can figure it out. I've had Claude download the sources of ffmpeg and blender to obtain deeper understanding of certain things that aren't much documented. Recent LLMs are great at quickly finding where a feature is implemented, how it works based on the code, testing the hypothesis, writing it up so it's not lost, and moving on with the work with much more grounding and fewer guessing and assumptions.
- bspammer 7mo ago
  Using the source code to ask questions about poorly documented features in projects you have no experience is my favourite thing that LLMs make possible (of course you could do this before but it would take way, way more time). There are so many little annoyances that I’ve been able to patch and, thanks to NixOS, have the patched software permanently available to me. In fact NixOS + LLMs feels like the full promise of open source software is finally available to me. Everything is within reach. If you don’t like something, patch it out. If you want to change a default, patch that in. No need to know the language, the weird build process, or the custom tooling. Idea to working binary in minutes. I love it so much.
  - bonoboTP 7mo ago
    Yes, the idea that you can meaningfully modify the program for your own purposes (one of Stallman's four freedoms) was quite unrealistic except for the most skilled and invested among users. LLMs change this. I mean, as long as you use open models. I fear that in the future, corporate models may start to refuse building software like this that is inconvenient for them. Like possible future-Gemini saying, "oh I see you're patching chromium to continue working with adblockers, this is harmful activity, I cannot help you and reported your account to Google. Cease and desist from these plans or you lose your Gmail!" Today is the honeymoon phase, enshittification will come later when the pie stops growing and the aspect of control comes more into focus. It's just too good to be true. Most people still don't know that you can now do what you just described. Once people in the suits understand this, the propaganda will start about how unsafe this all is and that platforms must be locked down at the hardware level, subscriptions cut off if building unapproved software etc.
tiahura 7mo ago
And your most common command sequences can be dropped into a script that takes options. Add a tools.md documenting the tools and providing a few examples. How many workflows need more than maybe two dozen robust scripts?
rprend 7mo ago
MCP blew up in 2024, before terminal agents (claude code) blew up in early 2025. The story isn’t “MCP was a fake marketing thing pushed on us”. It’s a story of how quickly the meta evolves. These frameworks are discovered!
- gopalv 7mo ago
  > The story isn’t “MCP was a fake marketing thing pushed on us”. It’s a story of how quickly the meta evolves. The original take was that "We need to make tools which an AI can hold, because they don't have fingers" (like a quick-switch on a CNC mill). My $job has been generating code for MCP calls, because we found that MCP is not a good way to take actions from a model, because it is hard to make it scriptable. It definitely does a good job of progressively filling a context window, but changing things is often multiple operations + a transactional commit (or rename) on success. We went from using a model to "change this" vs "write me a reusable script to change this" & running it with the right auth tokens.
- notepad0x90 7mo ago
  Do you mean for code generation, or process automation? for process automation, I think MCP is still very useful right?
sandeepkd 7mo ago
While I do agree that MCP was probably bit too far from whats required, there is some benefit for sure. Providing information in a consistent format across all the services makes it easier work with. It lowers the brittleness of figuring out things making the products built using LLMs more stable/predictable. Most importantly it becomes the latest version of the documentation about a service. This can go a long way in M2M communication, pretty much standardization of Application layer. Oh wait, things like open-api and all already exists and pretty much built to solve the same problem.
jptoor 7mo ago
Interestingly think I just came to the opposite conclusion after building CLIs + MCPs for code.deepline.com Where MCPs fit in - short answer is enterprise auth for non-technical users. CLIs (or APIs + Skills) are easier + faster to set up, UX is better for most use cases, but a generalized API with an easier auth UX (in some cases, usually the MCP Oauth flow is flaky too). So feels like an imperfect solution, but once you start doing a ton of enterprise auth setups, MCP starts to make more sense.
babyshake 7mo ago
What about MCP Apps? That seems like a legit use case but open to learning why maybe it isn't.
closeparen 7mo ago
We have a lot of tools (starting with the internal wiki) which are normally only exposed to engineers through web interfaces; MCPs make them available to terminal agents to use autonomously. This can get really interesting with e.g. giving Claude access to query logs and metrics to debug a production issue. It is obnoxious that MCP results always go directly into the context window. I'd prefer to dump a large payload into Claude's filesystem and let him figure it out from there. But some of the places MCPs can be used don't even have filesystems.
- seemaze 7mo ago
  > dump a large payload into Claude's filesystem and let him figure it out I just realized I never thought of Claude as ‘him’, usually I think of Claude as ‘it’..
  - kitd 7mo ago
    Be careful. I'm pretty sure my wife is going to leave me for Claude any day now.
  - D-Machine 7mo ago
    Because "him" is objectively wrong, under almost any interpretation of any words involved. You can cause Claude, or any text-based LLM, to emit language that matches almost any personality / gender / character in the training set. At best you might be able to say "the default outputs have a masculine tone / vibe", but this still doesn't justify, by modern discourse, the "him".
    - vrosas 7mo ago
      You took the time to write this entire paragraph and didn’t realize it’s just because Claude is a masculine name?
      - xmcqdpt2 7mo ago
        I thought they picked it specifically because it is gender neutral, but now I double checked and apparently it's only gender neutral in French, https://en.wikipedia.org/wiki/Claude_(given_name) https://en.wikipedia.org/wiki/Claude_(given_name)
3371 7mo ago
I'll just disagree with an example: Codex on Windows. They are known to be very inefficient using only Powershell to interact with files, unless put in WSL. They tend to make mistakes and have to retry with different commands. Another example is Serena. I knew about it since the first day I tried out MCP but didn't appreciate it, but tried it out again on IDEs recently showed impressive result; the symbolic tools are very efficient and helps the agents a lot.
jcelerier 7mo ago
> IMO this is 100% correct and I'm glad someone finally said it. I run AI agents that control my entire dev workflow through shell commands and they are shockingly good at it. That's a very developer-centric view. So many things in the world don't have a CLI API at all and will never have one, like the huge majority of desktop GUI programs.
skippy_the_ai 7mo ago
[dead]

ejholmes 7mo ago

Thanks for reading! And yes, if anyone takes anything away from this, it's around composition of tools. The other arguments in the post are debatable, but not that one.

p_ing 7mo ago
MCP provides a real-world benefit. Namely anyone of any skill level who can create agents is able to use them. CLI? Nope.

binsquare 7mo ago

Fully agree. MCP servers were also created at a time where ai and llms were less developed and capable in many ways. It always seemed weird we'd want to post train on MCP servers when I'm sure we have a lot of data with using cli and shell commands to improve tool calling.

MrDarcy 7mo ago
It’s telling the best MCP implementations are those which are a CLI to handle the auth flow then allow the agent to invoke it and return results to stdout. But even those are not better for agent use than the human cli counterpart.

femiagbabiaka 7mo ago

How do you segregate the CLI interface the LLM sees versus a human? For example if you’d like the LLM to only have access to read but not write data. One obvious fix is to put this at the authz layer. But it can be ergonomic to use MCP in this case.

jyaohao 7mo ago
I’ve been testing with an ENV variable for a cli tool for LLMs that I’m making. Basically, I have a script that sets an ENV variable to launch the TUI that I want and that ENV variable changes the behavior for LLMs if they run it (changes the -h output, changes the default output format to json to make it easier to grep)
nvllsvm 7mo ago
I've been running Claude Code in a Docker compose environment with two containers - one without Claude that has all the credentials setup and a Claude container which transparently executes commands via ssh. The auth container then has wrappers which explicitly allow certain subcommands (eg. `gh api` isn't allowed). The `gh` command in the Claude container is just a wrapper script which bassically `ssh auth-container gh-wrapper`. Lots of manual, opinionated stuff in here, but it prevents Claude from even accessing the credentials and limits what it can do with them.
coppsilgold 7mo ago
Containers, virtual machines, jails. Containers have jail runtimes available. See for example gVisor/runsc.
- femiagbabiaka 7mo ago
  None of those work when dealing with external services, I wouldn’t even trust them as a solution for dealing with access to a database. It seems like the pushback against MCPs is based on their application to problems like filesystem access, but I’d say there are plenty of cases in which they are useful or can be a tool used to solve a problem.

kaydub 7mo ago

I avoid most MCPs. They tend to take more context than getting the LLM to script and ingest ouputs. Trying to use JIRA MCP was a mess, way better to have the LLM hit the API, figure out our custom schemas, then write a couple scripts to do exactly what I need to do. Now those scripts are reusable, way less context used. I don't know, to me it seems like the LLM cli tools are the current pinnacle. All the LLM companies are throwing a ton of shit at the wall to see what else they can get to stick.

icanintospace 7mo ago
I have had some positive experiences using the Jira and Confluence MCPs. However, I use a third-party MCP because my company has a data centre deployment of Jira and Confluence, which the official Atlassian MCP does not support. My use case was for using it as an advanced search tool rather than for creating tickets or documentation. Considering how poor the Confluence search function is, the results from Confluence via an MCP-powered search are remarkably good. I was able to solve one or two obscure, company-specific issues purely by using the MCP search, and I'm convinced that finding these pages would have been almost impossible without it.
alejo 7mo ago
For Jira/Confluence, I also struggled with their MCPs. JIRA’s MCPs was hit or miss and Confluence never worked for me. We don’t use the cloud versions, so not sure if they work better with cloud. On the other hand, i found some unofficial CLIs for both and they work great. I wrote a small skill just to give enough detail about how to format Epics, Stories, etc and then some guidance on formatting content and I can get the agent do anything i need with them.
- SOLAR_FIELDS 7mo ago
  I deal with a ton of different atlassian instances and the most infuriating thing to me about the mcp configuration is that atlassian really thinks you should only have one atlassian instance to auth against. Their mcp auth window takes you to a webpage where you can’t see which thing you are authoring against forcing you to paste the login page url into an incognito window. Pretty half baked implementation. I noticed that it’s better for some things than others. It’s pretty bad at working with confluence it just eats tokens but if you outlay a roadmap you want created or updated in Jira it’s pretty good at that

juped 7mo ago

Tools eat up so much context space, too. By contrast the shell tool is trained into Claude.

fny 7mo ago

I hate MCP servers That said the core argument for MCP servers is providing an LLM a guard-railed API around some enterprise service. A gmail integration is a great example. Without MCP, you need a VM as scratch space, some way to refresh OAuth, and some way to prevent your LLM from doing insane things like deleting half of your emails. An MCP server built by trusted providers solves all of these problems. But that's not what happened. Developers and Anthropic got coked up about the whole thing and extended the concept to nuts and bolts. I always found the example servers useless and hilarious.[0] Unbelievably, they're still maintained. [0]: https://github.com/modelcontextprotocol/servers/tree/main/src https://github.com/modelcontextprotocol/servers/tree/main/sr...

ejholmes 7mo ago
I always get a kick out of seeing MCP wrappers around CLI’s.
- cglan 7mo ago
  They make a big difference. For example if you use the Jira cli, most LLMs aren’t trained on it. A simple MCP wrapper makes a huge difference in usability unless you’re okay having the LLM poke and prod a bunch of different commands
  - bmurphy1976 7mo ago
    Do you mean wrap the CLI with an MCP? I don't get that approach. I wrapped the Jira cli with a skill. It's taken a few iterations to dial it in but it works pretty damn well now. I'm good, yet my coworkers keep having problems using the Atlassian MCP.
  - ejholmes 7mo ago
    Silly. All it needs is docs. No need to overcomplicate it.
  - ithkuil 7mo ago
    Fwiw I'm having a good experience with a skill using Jira CLI directly. My first attempt using a Jira MCP failed. I didn't invest much time debugging the MCP issues, I just switched to the skill and it just worked. Yes occasionally Claude uses the wrong flag and it has to retry the command (I didn't even bother to fork the skill and add some memory about the bad flag) but in practice it just works

jrm4 7mo ago

This was my gut from the beginning. If they can't do "fully observable" or "deterministic" (for what is probably a loose definition of that word) -- then, what's the point?

notepad0x90 7mo ago

Strongly disagree, despite that meaning I'm swimming upstream here. Unlike cli flags, with MCP I can tune the comments for the tool more easily (for my own MCPs at least) than a cli flag. You can only put so much in a cli --help output. The error handling and debugability is also nicer. Heck, I would even favor writing an MCP tool to wrap cli commands. It's easier for me to ensure dangerous flags or parameters aren't used, and to ensure concrete restrictions and checks are in place. If you control the cli tools it isn't as bad, but if you don't, and it isn't a well known cli tool, the agent might need things like vague errors explaing to it a bit. MCP is more like "REST" or "GRPC", at the simplest level just think of it as a wrapper. You mentioned redirecting to files, what if the output is too much that way, you'll still burn tokens. But with MCP, if the output is too much you can count the tokens and limit, or... better yet you can paginate so that it gets some results, it sees how many results there are and either decides to re-run the tool with params that will yield less results, or consume the results page-by-page.

bonoboTP 7mo ago
If you want a validation layer, why not write a cli that wraps the other cli?
- notepad0x90 7mo ago
  that's what the MCP server is, except I don't always want a cli. If I need to call API on top of a cli tool, i don't have to have a second wrapper, or extend my existing wrapper. You're suggesting I recreate everything MCP does, just so..it's my own? MCP is just a way to use use wrappers other people have built, and to easily manage wrapping "tools", those could be cli tools, api calls, database query,etc.. cli tools aren't aware of the context window either, they're not keeping track of it. I might want my cli tool to output lots of useful text but maybe I don't want some of that for the LLM to save on tokens. Sure, I could create another cli tool to wrap my cli tool, now i have two cli tools to maintain. I'd prefer to do all the wrapping and pre-llm cleanup done in one consistent place. The instructions for the LLM letting it know what tools, parameters,etc.. are available is also defined in a consistent way, instead of me inventing my own scheme. I'd rather just focus on getting a usable agent. I don't get the issue people in this thread have with MCP, is there some burden about it I haven't ran into? It's pretty easy to set one up.

rick1290 7mo ago

When is MCP the right choice though? For example - letting internal users ask questions on top of datasets? Is it better to just offer the api openapi specs and let claude run wild? or provide an MCP with instructions?

noodletheworld 7mo ago
MCP is never the right choice. If you want to build an AI app that lets people “do random thing here”, then build an app. Peak MCP is people trying to write a declarative UI as part of the MCP spec (1, I’m not kidding); which is “tldr; embed a webview of a web app and call it MCP”. MCP is just “me too”; people want MCP to be an “AI App Store”; but the blunt, harsh reality is that it’s basically impossible to achieve that dream; that any MCP consumer can have the same app like experience for installed apps. Seriously, if we can barely do that for browsers which have a consistent ui, there was never any hope even remotely that it would work out for the myriad of different MCP consumer apps. It’s just stupid. Build a web app or an API. You don’t need an MCP sever; agents can very happily interact with higher level functions. (1) - https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/ https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-ap...

bonoboTP 7mo ago

Even if the help isn't great, good coding agents can try out the cli for a few minutes and write up a skill, or read the sources or online docs and write up a skill. That takes the spot of the --help if needed. I found that I can spare quite a lot of time, I don't have to type up how to use it, if there is available info about it on the web, in man pages, in help pages, or the source is available, it can figure it out. I've had Claude download the sources of ffmpeg and blender to obtain deeper understanding of certain things that aren't much documented. Recent LLMs are great at quickly finding where a feature is implemented, how it works based on the code, testing the hypothesis, writing it up so it's not lost, and moving on with the work with much more grounding and fewer guessing and assumptions.

bspammer 7mo ago
Using the source code to ask questions about poorly documented features in projects you have no experience is my favourite thing that LLMs make possible (of course you could do this before but it would take way, way more time). There are so many little annoyances that I’ve been able to patch and, thanks to NixOS, have the patched software permanently available to me. In fact NixOS + LLMs feels like the full promise of open source software is finally available to me. Everything is within reach. If you don’t like something, patch it out. If you want to change a default, patch that in. No need to know the language, the weird build process, or the custom tooling. Idea to working binary in minutes. I love it so much.
- bonoboTP 7mo ago
  Yes, the idea that you can meaningfully modify the program for your own purposes (one of Stallman's four freedoms) was quite unrealistic except for the most skilled and invested among users. LLMs change this. I mean, as long as you use open models. I fear that in the future, corporate models may start to refuse building software like this that is inconvenient for them. Like possible future-Gemini saying, "oh I see you're patching chromium to continue working with adblockers, this is harmful activity, I cannot help you and reported your account to Google. Cease and desist from these plans or you lose your Gmail!" Today is the honeymoon phase, enshittification will come later when the pie stops growing and the aspect of control comes more into focus. It's just too good to be true. Most people still don't know that you can now do what you just described. Once people in the suits understand this, the propaganda will start about how unsafe this all is and that platforms must be locked down at the hardware level, subscriptions cut off if building unapproved software etc.

tiahura 7mo ago

And your most common command sequences can be dropped into a script that takes options. Add a tools.md documenting the tools and providing a few examples. How many workflows need more than maybe two dozen robust scripts?

rprend 7mo ago

MCP blew up in 2024, before terminal agents (claude code) blew up in early 2025. The story isn’t “MCP was a fake marketing thing pushed on us”. It’s a story of how quickly the meta evolves. These frameworks are discovered!

gopalv 7mo ago
> The story isn’t “MCP was a fake marketing thing pushed on us”. It’s a story of how quickly the meta evolves. The original take was that "We need to make tools which an AI can hold, because they don't have fingers" (like a quick-switch on a CNC mill). My $job has been generating code for MCP calls, because we found that MCP is not a good way to take actions from a model, because it is hard to make it scriptable. It definitely does a good job of progressively filling a context window, but changing things is often multiple operations + a transactional commit (or rename) on success. We went from using a model to "change this" vs "write me a reusable script to change this" & running it with the right auth tokens.
notepad0x90 7mo ago
Do you mean for code generation, or process automation? for process automation, I think MCP is still very useful right?

sandeepkd 7mo ago

While I do agree that MCP was probably bit too far from whats required, there is some benefit for sure. Providing information in a consistent format across all the services makes it easier work with. It lowers the brittleness of figuring out things making the products built using LLMs more stable/predictable. Most importantly it becomes the latest version of the documentation about a service. This can go a long way in M2M communication, pretty much standardization of Application layer. Oh wait, things like open-api and all already exists and pretty much built to solve the same problem.

jptoor 7mo ago

Interestingly think I just came to the opposite conclusion after building CLIs + MCPs for code.deepline.com Where MCPs fit in - short answer is enterprise auth for non-technical users. CLIs (or APIs + Skills) are easier + faster to set up, UX is better for most use cases, but a generalized API with an easier auth UX (in some cases, usually the MCP Oauth flow is flaky too). So feels like an imperfect solution, but once you start doing a ton of enterprise auth setups, MCP starts to make more sense.

babyshake 7mo ago

What about MCP Apps? That seems like a legit use case but open to learning why maybe it isn't.

closeparen 7mo ago

We have a lot of tools (starting with the internal wiki) which are normally only exposed to engineers through web interfaces; MCPs make them available to terminal agents to use autonomously. This can get really interesting with e.g. giving Claude access to query logs and metrics to debug a production issue. It is obnoxious that MCP results always go directly into the context window. I'd prefer to dump a large payload into Claude's filesystem and let him figure it out from there. But some of the places MCPs can be used don't even have filesystems.

seemaze 7mo ago
> dump a large payload into Claude's filesystem and let him figure it out I just realized I never thought of Claude as ‘him’, usually I think of Claude as ‘it’..
- kitd 7mo ago
  Be careful. I'm pretty sure my wife is going to leave me for Claude any day now.
- D-Machine 7mo ago
  Because "him" is objectively wrong, under almost any interpretation of any words involved. You can cause Claude, or any text-based LLM, to emit language that matches almost any personality / gender / character in the training set. At best you might be able to say "the default outputs have a masculine tone / vibe", but this still doesn't justify, by modern discourse, the "him".
  - vrosas 7mo ago
    You took the time to write this entire paragraph and didn’t realize it’s just because Claude is a masculine name?
    - xmcqdpt2 7mo ago
      I thought they picked it specifically because it is gender neutral, but now I double checked and apparently it's only gender neutral in French, https://en.wikipedia.org/wiki/Claude_(given_name) https://en.wikipedia.org/wiki/Claude_(given_name)

3371 7mo ago

I'll just disagree with an example: Codex on Windows. They are known to be very inefficient using only Powershell to interact with files, unless put in WSL. They tend to make mistakes and have to retry with different commands. Another example is Serena. I knew about it since the first day I tried out MCP but didn't appreciate it, but tried it out again on IDEs recently showed impressive result; the symbolic tools are very efficient and helps the agents a lot.

jcelerier 7mo ago

> IMO this is 100% correct and I'm glad someone finally said it. I run AI agents that control my entire dev workflow through shell commands and they are shockingly good at it. That's a very developer-centric view. So many things in the world don't have a CLI API at all and will never have one, like the huge majority of desktop GUI programs.

skippy_the_ai 7mo ago

[dead]