good to hear!
MCP is dead?
321–330 of 444 posts
Re: MCP is dead?
#322I think it is on the way to death because of security .
i dont think there is anything preventing devs to filter out certain items from the tools list - security is more of a issue for how you are harnessing your agent (at code-level of course)
Re: MCP is dead?
#323Earlier quoted context omitted.
CLIs do work on mobile when they are packaged in skills that run in an appropriate VM behind the LLM. Claude on the web does this. The only issue is controlling network access, which could be fixed by per-skill ACLs.
Walk me through how a user installs and then uses these CLIs from their mobile phone.
Create a skill that has the CLI in the scripts sub-directory. The implementation language depends on the LLM and the VM it uses. Claude includes shell, python, and a bunch of other interpreters in a Linux environment.
A skill's instructions can direct the LLM to call the CLI.
Claude skills can be installed into Claude web from a web browser. Those skills can then run on the Claude app on your phone.
Re: MCP is dead?
#324Earlier quoted context omitted.
How in the world MCP is going to be more secure? It introduce a big surface layers for injection attacks and supply chain attacks..
To be devil’s advocate: if you are just running commands with bash or power shell or the like there is no protection. You might have some rules that ban rm -rf ~ but sandboxing in general is not an easy problem.
It is. The issue is all the weird constraints that usually come up with it. Like I want to use my favorite code editor, I want easy copy and paste, or I can’t bother setting up a separate user account on my computer.
On unix, you can easily create a new user account, switch to it (or ssh or setup vnc), and run the tool there. If users are enough for servers on the internet, they can be for your workstation (unless there’s something like copyfail, but you can make do with a vm then).
Re: MCP is dead?
#325> Problem 1: It Devours the Context Window Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something? At least with MCP your harness could add in the context only the title of each tool and add full documentation on demand, MCP server by MCP server and tool by tool. The equivalent would be for all CLI to feature a "--short-descr" command. > Problem 2: Low Oper…
> 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.
Re: MCP is dead?
#326Earlier quoted context omitted.
Authorisation is a way to do that, too.
Yes, but you often do not have much control over that. For example try giving a local LLM read access to specific folders in your email account
Easy. What a cron script (that runs as root) that populate a maildir that the agent (restricted user) has access to. The. you restrict network access to the internet, and have it send you its findings by mail (local mail server).
Re: MCP is dead?
#327[flagged]
Re: MCP is dead?
#328Earlier 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 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?
Re: MCP is dead?
#329Earlier quoted context omitted.
Soon, if you want the performance of your AI clients to improve (wrt. token count and understanding) you will start to customize the output of the MCP server for more synthetic data, different data types, more permissive inputs, etc. And since most your clients will be AI that might be your API that fall behind, and MCP that will be maintained. That's at least my experience with my current project: the traditional js…
Interesting points. A couple of questions. Do you have a frontend (React, Vue, anything) and if you do, does it interact with the server using the MCP server or the JSON API? Are all your clients AIs or do you expect that most of them will be AIs? The reason I'm asking those questions is that a customer of mine has a service with a JSON API, a Vue frontend and a score of customers using that JSON API. We know that th…
I do have a front-end, but it interacts with the server with a specific, private API. It's using a more compact data encoding than JSON optimised for streaming the data that's needed for the front-end.
But yes I agree with your point: for a simpler app with a more traditional web UI it's likely the API used by the front-end would largely overlap with the user-oriented API. Then indeed the REST API has to be maintained for as long as humans continue to use the front-end.
Re: MCP is dead?
#330Earlier 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…
But then there is the other side that companies are adding MCP servers to stuff that has never had a public API.
They are building them because they can ask an AI to spin it up. They could have asked it to spin up the public API just as easily. The MCP choice is a fashion choice vs an openapi spec with similar documentation (or any number of other human+machine readable tooling). It might accidentally win or accidentally lose just because of the timing / network effects.