Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP is a fad

tombedor.dev

Post reply on HN
Print view View original

111–120 of 129 posts

Re: MCP is a fad

#111

Post by jjfoooo4 »

vidarh wrote: post #3

This article could really mostly be reduced to the last two paragraphs, but then it calls skills "over-engineered". Skills are basically just having the agent read the front matter with instructions to read the rest if a given skill seems useful in a given context... I don't know how it could be more minimal.

(I'm the author)

Looking at the post again, I think I agree that calling Claude Skills overengineered is too harsh. I think Skills is definitely an improvement over MCP.

However I still think it's a generally a mistake to put useful commands and documentation in AI-specific files. In my opinion a better approach is to optimize the organization of docs and commands for human usability, and teach the AI how to leverage those.

I do use Claude Skills, but only to wire up just commands. I wrote a little package to do this automatically: https://github.com/tombedor/just-claude

Re: MCP is a fad

#112

Post by jjfoooo4 »

karussell wrote: post #101
fzaninotto wrote: post #73

I think this article misses the most important point of MCP: Authentication. Granted, it wasn't in the initial spec, but it is now, and it really opens interoperability without compromising on security. Think about how to provide your SaaS service to users of ChatGPT or Claude.ai (not only coding tools like VSCode). At one time, the user will need to allow the SaaS service to interact with their agent, and will have…

Wouldn't the OpenAPI spec work too? Then no additional components are necessary. Just a link to the spec file...

(I'm the author of the post)

This would be my critique of MCP-specific security implementations. I think robust tools for this already exist, and in general AI API calls can and should be treated like any other RPC call.

Re: MCP is a fad

#114

Post by OutOfHere »

mgaunard wrote: post #4

AI for coding itself is a fad

The applications of MCP and tool-calling are vastly wider than just for coding, with tremendous diversity. Constraining it to the single application of coding doesn't make any sense.

Re: MCP is a fad

#115

Post by Sammi »

nextaccountic wrote: post #108

> Robust security against agent actions going haywire can be achieved via command runners like just or make. These tools provide everything that MCP does - command specifications, descriptions, arguments. Agents allow you to specify what command prefixes can be invoked without approval - put your agent commands in a justfile, and only auto-allow shell commands prefixed with just. Shell scripting isn't easily sandboxe…

I didn't get how limiting the agent to running just scripts from a justfile limits what the agent can run in any way. Because what's stopping the agent from editing the justfile to add whatever it wants to run?

Re: MCP is a fad

#116

Post by nextaccountic »

Sammi wrote: post #115
nextaccountic wrote: post #108

> Robust security against agent actions going haywire can be achieved via command runners like just or make. These tools provide everything that MCP does - command specifications, descriptions, arguments. Agents allow you to specify what command prefixes can be invoked without approval - put your agent commands in a justfile, and only auto-allow shell commands prefixed with just. Shell scripting isn't easily sandboxe…

I didn't get how limiting the agent to running just scripts from a justfile limits what the agent can run in any way. Because what's stopping the agent from editing the justfile to add whatever it wants to run?

Indeed, there's a very large number of things an agent can do to workaround those restrictions (for example, maybe you make it so justfile is off limits, but what about .env? what about ~/.bashrc?). Running commands in your dev machine is dangerous and AI agents should never have this kind of unsandboxed access

Re: MCP is a fad

#117

Post by p337 »

the_mitsuhiko wrote: post #54
kburman wrote: post #18

This analysis dismisses MCP by focusing too narrowly on local file system interactions. The real value isn't just running scripts; it's interoperability. MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code. Comparing it to local scripts is like calling USB a fad because parallel ports worked for printers. The power is standardi…

> MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code. My agent writes its own glue code so the benefit does not seem to really exist in practice. Definitely not for coding agents and increasingly less for non coding agents too. Give it a file system and bash in a sandbox and you have a capable system. Give it some skills and i…

You end up wasting tokens on implementation, debugging, execution, and parsing when you could just use the tool (tool description gets used instead).

Also, once you give it this general access, it opens up essentially infinite directions for the model to go to. Repeatability and testing become very difficult in that situation. One time it may write a bash script to solve the problem. The next, it may want to use python, pip install a few libraries to solve that same problem. Yes, both are valid, but if you desire a particular flow, you need to create a prompt for it that you'll hope it'll comply with. It's about shifting certain decisions away from the model so that it can have more room for the stuff you need it to do while ensuring that performance is somewhat consistent.

For now, managing the context window still matters, even if you don't care about efficient token usage. So burning 5-10% on re-writing the same API calls makes the model dumber.

Re: MCP is a fad

#118

Post by everybodyknows »

monooso wrote: post #57

Simon Willison made many of the same points (without the technical deep dive) back in October 2025 [1], when Anthropic announced Skills. A couple of choice quotes, which are echoed in this new article: > I like to joke that one of the reasons it took off is that every company knew they needed an “AI strategy”, and building (or announcing) an MCP implementation was an easy way to tick that box. > Almost everything I m…

He argues that Claude Skills is a superior approach:

https://simonwillison.net/2025/Oct/16/claude-skills/#skills-...

Anyone here compared, by applying both to the same task?

Re: MCP is a fad

#119

Post by WorldMaker »

Someone1234 wrote: post #5

Fair warning, if you load the site in dark-mode the diagrams are completely broken. They're PNGs with an alpha-transparency background and gray/black for the actual content, when the site is in dark mode you can see nothing at all... So make sure to change to light-mode in the top-right if you want to read this article at all.

Feel like the author should have just included the white backgrounds in the PNGs.

Though the more technically fun solution would be to use SVG instead of PNG because then the author could apply a whole dark mode color palette with CSS.

Re: MCP is a fad

#120

Post by jauntywundrkind »

falloutx wrote: post #32
kburman wrote: post #18

This analysis dismisses MCP by focusing too narrowly on local file system interactions. The real value isn't just running scripts; it's interoperability. MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code. Comparing it to local scripts is like calling USB a fad because parallel ports worked for printers. The power is standardi…

adding MCP servers isnt free, they take space in your context and if you are working at anything bigger than a startup, none of the companies allow thier workers to connect to other companies' MCPs and they can easily make thier MCP a data exfil machine

I'm not sure what the use case is? The llm is the user's agent and can coordinate inter-MCP work itself, can feed data across mcp's.
Post reply on HN