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.
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.
Can't recall if I played on your servers, but I know I played an unreasonable amount of CS 1.6, including on a bunch of WC3 servers when I wasn't playing on ESEA.
If you happen to remember someone going by `nJs` - hi!
The point about coverage results is an important one to understand. Something that I like to say when discussing this with other folks is that while high code coverage does not tell you that you have a good test suite, low code coverage does tell you that you have a poor one. It's one metric amongst many that should be used to measure your code quality, it's not the end-all-be-all.
code coverage is a bad metric either way. soon as it gets mentioned anywhere, an mba manager wants it as close to 100 as possible and goodhart's law kicks in.
it's synonymous with LOC. don't bring it up anywhere.
There's another alternative - debug in CI itself. There's a few ways that you can pause your CI at a specific step and get a shell to do some debugging, usually via SSH. I've found that to be the most useful.
It’s slow and arduous work to inject at the right point and find out what went wrong. But it’s miles better than act. act is a noble idea, and I hope it can meet its target, but it falls short currently.
ssh-action gets you on the host, and lets you quickly establish what is happening and implement fixes. It’s top notch!
I generally would agree, but be careful. You don't know what you don't know, and that could be dangerous. As one example, I would guess that the vast majority of folks are not familiar with what an MWBC is and how they work, however they're extremely common, especially in older buildings. As another example, most folks have never heard of box fill and will just try to shove wires into a box until it fits.
I'm not an electrician and would definitely encourage folks to learn to do this work themselves, but be careful and if you encounter something that is not familiar, pause and learn until you understand what you're looking at, even if that means putting it back the way it was for a bit and doing some research.
Random aside, were you at KubeCon a couple years ago chatting with Sugu at the whole conference party in San Diegi? If so, hi! I was crazy out of my depth, but listening to folks that know this stuff better than I ever will was one of the highlights of that conference
Agreed, was typing a similar comment, however yours expressed that idea better than mine.
Consider that this pattern contains N different properties that renders N different components (plus the default case), I don't know why you would want to put this into one component rather than having the consumer select the right one themselves. This even introduces the possibility of bugs - what happens if a consumer passes two sets of properties (which admittedly could be somewhat prevented by Typescript)? I don't really see the benefits of this approach for this particular example.
Not only that, but it really illustrates that even well-known, famous engineers can start contributing to a project with simple pull requests that just rename variables or add comments to code for clarity.
Not every pull request needs to be introducing complex/intricate code, and yet it still has value to the project (and the community).
reply