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

MCP is dead?

quandri.io

Post reply on HN
Print view View original

351–360 of 444 posts

Re: MCP is dead?

#351

Post by zuzululu »

brabel wrote: post #298
troupo wrote: post #261

Earlier quoted context omitted.

This is a great example of the AI-hype-induced reply. > to an LLM that can call tools (since MCP essentially turns an API into a LLM tool). "Tools" is literally an API call > With MCP, the agent sees a bunch of tools it can call, Yes, the agent first calls a specific API that returns the schema for that particular server. It's literally the same. > One more very important factor is authorization, which no one seems t…

If you think tool call and letting the LLM call an API via curl are the same thing, you haven’t a clue how LLMs work and honestly shouldn’t be commenting on the topic at all.

sometimes I remind myself HN is reddit now except when Dang is awake

Re: MCP is dead?

#353

Post by ok_dad »

bluegatty wrote: post #317
didibus wrote: post #137

Earlier quoted context omitted.

You do know MCPs are loaded on demand same as skills now right? The only place where sometimes it still uses too much context is if you have too many MCPs (same issue with skills) or some MCP is poorly designed and responds with huge description or MCP calls respond with way too much info, but skills can have this issue as well.

Yes, MCP taking the form of 'skill' because MCP serves no purpose. The concept of 'mcp server' is a brittle abstraction that need not exist. A 'skill' is utterly superior in every sense: a 'right sized abstraction for whatever it is you're trying to do' - that can include cli / rest - and other key bits of information.

You realize that not every user of agents uses them like Claude or Codex on your local CLI right? MCP is the standard for cloud agents. How do you get a cloud agent working in an ephemeral container access to skills? The answer is MCP.

Re: MCP is dead?

#354

Post by ok_dad »

rixed wrote: post #325
Mashimo wrote: post #228

Earlier quoted context omitted.

> Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something? I'm not super deep into all of this, but I think except latest Claude Code release the mcp is frontloaded into the context. So if you don't need it that often you have to disable and enabled it again when needed. And I guess you can put some usage examples into the skill file. Which might migate the…

Yes I believe it is preloaded (from a recent test with latest claude-code actually). But that's an issue with the harness not something that's mandated by the MCP protocol.

I like MCP, but most servers and harnesses just dump all of the tools into context each message. Also the default tutorials for everything around MCP say to dump tools this way.

It’s really hard to determine which tools an agent will need on the fly. The best idea I’ve seen was to do a “search tools” tool which an agent would use to find relevant tools, then have an “execute tool” tool which did what it says.

Alternatively, if you’re using an agent that’s good with code, give it something like “port of context” (pctx) which translates MCP tools into a JavaScript package so the agent can chain MCP tools together with code, and they can filter the data down to just what they need. I haven’t used this method much yet but soon I need to improve the MCP gateway in our cloud agent builder product so I’m going to try this one out soon myself.

Re: MCP is dead?

#356

Post by octoberfranklin »

rubslopes wrote: post #254
zingar wrote: post #249

Earlier quoted context omitted.

Can you not just install/ restrict the available CLIs in the same way you do with MCPs? Or what else am I missing about why MCP is more secure than a CLI?

MCP allows you to easily separate API requests from their access tokens, so that the LLM only has access to the requests part. Giving an LLM CLI access removes all boundaries, anything goes. EDIT: to add an example: I have a personal claw agent that I only use CLI, I don't care. But I'm also building an agent inside a company product, and there we use MCP all the way.

You can easily do this with simple Unix `chmod x-rw` on a wrapper that makes HTTP requests, adding the access token as it does.

Re: MCP is dead?

#357

Post by ok_dad »

IggleSniggle wrote: post #328
brookst wrote: post #303

Earlier quoted context omitted.

MCP is a higher layer than your existing API. It’s like saying APIs are dead because you can just use HTTP. They’re not the same thing, though of course you can hand-roll the higher layer in the lower one. It’s just more work, less standard, less valuable. I don’t think models will ever prefer a low level API to a decorated index of API features and how to use them, same way developers will never prefer a list of HTT…

Right; isn't this already captured by an openapi spec with RBACs? Plus the benefit that your ai agent can keep using all the pre-AI tools that already interface with those specs. What is MCP bringing that an openapi spec doesn't?

You can build an MCP client really really easy today with libraries and it integrates with inference calls very well. If you want to give a cloud agent access to another api, you need to bills a connector or give it shell access or some sort of sandbox with tools to access that stuff. That’s fine, but how do you then give it auth access? How do you ensure security boundaries? MCP builds those in and the shape (prompts, resources, tools, etc) are good for agentic work.

It’s like asking why we needed browsers when we had BBSes; they serve a different but similar purpose and are build on different abstraction levels.

Re: MCP is dead?

#358

Post by octoberfranklin »

mrgaro wrote: post #294
zingar wrote: post #249

Earlier quoted context omitted.

Can you not just install/ restrict the available CLIs in the same way you do with MCPs? Or what else am I missing about why MCP is more secure than a CLI?

Another examole which is trivial with MCP but hard with cli binaries: blocking certain commands, such as write operations from the agent. With MCP your client can easily have a blocklist for commands, but with cli you would need to code custom logic for each cli separately.

Access control is the operating system's job, and modern OSes already provide plenty of great tools for doing that.

Just use the existing sandboxing infrastructure like bubblewrap, seccomp, etc. I have way more faith in that than in something than some regex-based blocklist.

Re: MCP is dead?

#359

Post by kylling »

mrgaro wrote: post #226
tlogan wrote: post #112

Earlier quoted context omitted.

I would bet that MCP is going to die. The main reason is that it adds another layer (and human) that can, and probably will, get out of sync with the real-world implementation, whether that implementation is an API, web, or a CLI. AI should not be using a protocol or set of instructions that is different from what humans have access to (know and use). Sure, companies want to expose MCP servers because it is the cool…

MCP has a great advantage over agent using cli: MCP is much easier to secure so that it's hardwired that the agent can only call the pre-configured MCP server. We run our agents so that they don't have access to public internet, so they could not run any cli commands. It's all either built-in agent tools, or 3rd party mcp servers. The agents never have access to any credentials, which makes them much more safe to use…

It is crazy how the preferred way or securing AI are vibe coded MCP servers which at the same time do access control, credentials handling and HTTP server/client boilerplate. Want to use a new API: just vibe code a new MCP you won't fully review. It is hardly better than yoloing. The security critical parts needs to leave MCP and be integrated with, or be in front of, the API in a way humans will understand and review.
Post reply on HN