earendil.com

You Said No MCP

yarapavan · 473 points · 275 comments · il y a 8 heures · Open original

Comments

5 preview comments · loading full thread
alin23il y a 5 heures

Lately I found MCP to be much more than a coding tool. For example, I implemented it in my more complex macOS apps [0] like rcmd, Clop, Lunar, so they can be configured by natural language. So even with a local Qwen and Pi you can now say things like: Set up Clop to optimise any PNG that I drop in my website assets folder and convert to a webp with the same name near it Get Crank to start Time Machine backups immediately when I connect my HDD and notify me when the backup is done. I want to be able to hold rcmd and fuzzy search and focus cmux agent panes BetterTouchTool has a great MCP which can create native SwiftUI views and bind them to hotkeys, trackpad gestures etc. It can leverage its immense macOS automation tools and private APIs to let agents do Computer Use. You would need a much more capable coding model to code those tools from scratch and get the same fail-safe logic that the apps have honed over the years. Like, since MCP, Crank [1] has fully replaced my use of crontab, launchd, scattered scripts I run once a week. Not that it could not do that before, but it's so much simpler now to just describe the automation and have it happen reliably and visible in the UI. The friction is gone. [0] https://reddit.com/r/macapps/comments/1wkv0dy/mcp_in_macos_a... [1] https://lowtechguys.com/crank

gk1il y a 2 heures

Props to the team not only for changing their minds from a strongly-held belief but making it very public and not hiding the fact that it's a reversal. The linked post from Armin is gold: "... whenever you are confronted with a very strong opinion about a topic, reasonable discussions about the topic often involve arguments that have long become outdated or are no longer strictly relevant to the conversation." (https://lucumr.pocoo.org/2016/11/5/be-careful-about-what-you...) And that's from 2016! These days if you're arguing from a position you took even a week ago, you already might be out of sync.

CharlieDigitalil y a 5 heures

This was the easiest call and many like me made it in March[0] among all of the anti-MCP wave of influencers claiming it dead (many, many prominent folks in tech including Garry Tan). Literally every tech influencer in every social feed in March was calling MCP dead and crowning CLI the winner (completely ignoring every reasonable argument around security, observability/telemetry, ease of deployment and operations, etc.) A direct quote from March, 2026[1]: > If you’re still not convinced that a lot of this discourse [regarding the death of MCP] lacks nuance and is just hype, congrats on buying into the current AI-influencer FOMO hype cycle; see you in 6 months when the influencers move on to the next revelation of the moment to stay relevant and get your eyeballs and dollars. It was fairly obvious why MCP would be needed once AI engineering and uptake moved beyond the solo developer and single harness stack of "what works for Me" versus "what works for My Team", particularly in an enterprise context. The key mistake people made was thinking in terms of their own workflows and own local stacks instead of a team's workflow and a team's operational stack. There was also an ignorance of MCP's stateless HTTP mode (yes, it was already a thing in March; the 2026-07-28 revision of the spec just prioritizes it as the primary focus moving forward) versus local `stdio`. My biggest complaint right now is that OpenAI has still refused to implement the MCP Prompts spec[2] and in general, the major clients have spotty implementation for some of the features in the spec. [0] https://news.ycombinator.com/item?id=47380270 [1] https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/ [2] https://github.com/openai/codex/issues/5059

_fwil y a 7 heures

I appreciate their reluctance towards MCP, but /something/ is better than nothing. It’s suboptimal for the reasons the author outlines: but so is USB-C. So is NVME, so is HDMI. We use these hugely successful technologies in spite of their flaws because they’re widely compatible and easy for the end user. That’s why MCP is everywhere. It might not be performant, robust and uniform but it WILL get better over time. And I’d much rather have the broad MCP ecosystem that we have now than seven or eight different “optimal” ways of plugging in an LLM to something useful.

crossroadsguyil y a 10 minutes

[delayed]