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.
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.
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.
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.
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.
With MCP you can at least set things up such that the agent can't access the raw credentials directly.