I think they’re saying you could start up the mcp and pass it creds/auth for some downstream service, and then the LLM uses the tool and has auth but doesn’t know the creds.

Right. If you're running a CLI tool that is authenticated there's effectively no way to prevent the coding agent from accessing those credentials itself - they're visible to the process, which means they're visible to the agent.

With MCP you can at least set things up such that the agent can't access the raw credentials directly.

How so? Let's use a common CLI tool as an example - kubectl. Config is generally stored in ~/.kube in a variety of config files. Running `kubectl config view` already redacts the auth information from the config. LLMs could invoke `kubectl` commands without having knowledge of how it's authenticated.

If the agent has permission to run kubectl config view what's to stop it from reading those config files directly?

The same permissions model that works for other tools. In Claude Code terms, allow Bash(kubectl:*). Deny Read(**/.kube/**). That allows kubectl access without allowing the tool to read ~/.kube directly.

Your argument is the same for an MCP server - auth is stored somewhere on disk, what's to stop it from reading that file? The answer is the same as above.

Would that stop Claude from executing this code:

  python -c '
  print(open("~/.kube/config.txt").read())
  '

The point I'm making here is that with an MCP you can disable shell access entirely, at which point the agent cannot read credential files that it's not meant to be able to access.

You can make the identical argument for the CLI tool. Allow kubectl, deny everything else.

I don't understand.

My argument here is that one of the reasons to use MCP is that it allows you to build smaller agents that do not have a full code execution environment, and those agents can then use MCPs to make calls to external services without revealing those credentials to the agent.

I think we both agree that if your agent has full Bash access it can access credentials.

I think the gist of what we're debating is principle of least privilege - give the LLM the fewest privileges needed to accomplish the task and no more, that way you avoid issues like leaking credentials.

The approach you're proposing is that with a well designed MCP server, you can limit the permissions for your agent to only interacting with that MCP server, essentially limiting what it can do.

My argument is that you can accomplish the identical thing with an agent by limiting access to only invoking a specific CLI tool, and nothing more.

Both of our approaches accomplish the same thing. I'm just arguing that an MCP server is not required to accomplish it.

If you're "limiting access to only invoking a specific CLI tool" then yeah, that's functionally equivalent to an MCP server. Most of the work I do with tools avoids MCPs entirely because you don't need them to hook up tools using raw JSON calls to LLMs or the official provider libraries.

But... if you're going all-in on the Bash/Python/arbitrary-programming-language environments that are necessary to get Skills to work, you're going to find yourself in a position where the agent can probably read config files that you don't want it to see.

Also, you can set permissions to allow and disallow specific mcp server tool calls. With a skill you’d have to do something in the shell environment to block unwanted behaviors with auth or other means in a way that isn’t declarative.

This is right. It’s not about scoping auth, it’s about preventing secret misuse/exfil.

(Moved from wrong sub)

The MCP implementation is itself an agent right? Is that not just pushing the problem somewhere else?

Also, I run programs on my machine with a different privilege level than myself all the time. Why can’t an agent do that?

No, mcp just is a server that returns prompts to the llm. The server can be/do whatever. You can have an echo mcp that list echoes back whatever you send it.

I define the agent as the harness that runs the LLM in a loop calling tools. The MCI implementation is one of those tools. I wouldn't call an MCP implementation an agent.

Typically, no; an MCP is a deterministic program with SSE protocols.

Oh. Yeah, that's neat at least. I don't think it's a big deal but that's nice enough.

Isn’t the last point the case with every AI startup? Nobody has a moat and it’s tough to build one because the playing field is so level.

I've been confused by this with many LLM products in general. Sometimes infrastructure is part of it so there's that, but often it seems like the product is a magic incantation of markdown files.

Solving for infrastructure is a huge part of the problem too. Curious to know what you think about it?

Here I'm mostly considering the seemingly countless services that are little more than some markdown files and their own API passing data to/from the LLM procider's API.

By no means is that every AI product today, and I wasn't saying the OP QA service falls into that bucket though.

More of a general comment related to the GP, maybe too off topic here though?

The pelxiglas is cheaper than taking the system down…

(2017)

I want to be proven wrong, but every use case someone presents for OpenClaw is just a worse version of Claude Code, at least, so far.

The next line in the comment you’re responding to is

> Sometimes ideas are dumb, but checking and guiding step by step helps it ship working things in hours.

which matches my experience exactly. I consider it to be about as magical as the parent comment is claiming, but I wouldn’t call it totally automatic.

You’re absolutely right!

is this real life

is this just fanta sea

Caught in a landslide, no escape from reality

Be the change you want to see… it’s not like this being public changes much, anyone who wanted to exploit this could do it without this site

Sure, someone could, if they thought to look and did look and compiled the same list. But this makes the work required to start a lot smaller.

But putting all of them in a tidy list definitely changes the value.

For 99% of my use cases, Claude Code is the clear winner. So, when I tried to use OpenClaw to test it out, it just seemed like a worse, slower, less-capable version of Claude Code. And it is. I haven’t seen the use case where OpenClaw can really shine yet, but I’m sure it’s coming. Like others are saying, I’m willing to be convinced, but so far it hasn’t happened.

Ask it to do something in the future or something with a conditional, plain CC can't do that.

Like "message me when it is about to rain"