3 ms·

I know of two benefits to MCP over Skills: - If your agent doesn't have a full Bash-style code execution environment it can't run skills. MCP is a solid option

by simonw 8mo ago

I know of two benefits to MCP over Skills: - If your agent doesn't have a full Bash-style code execution environment it can't run skills. MCP is a solid option for wiring in tools there. - MCP can help solve authentication, keeping credentials for things in a place where the agent can't steal those credentials if it gets compromised. MCPs can also better handle access control and audit logging in a single place.

staticassertion 8mo ago
Can you explain the auth part? I feel like auth for an agent is largely a matter of either verifying its context or issuing it a JWT that's scoped to its rights, which I assume is quite similar to how any tools would work. But I'm very unfamiliar with MCP.
- monkpit 8mo ago
  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.
  - simonw 8mo ago
    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.
    - zbentley 8mo ago
      This is right. It’s not about scoping auth, it’s about preventing secret misuse/exfil. (Moved from wrong sub)
    - steve-atx-7600 8mo ago
      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.
    - dcherman 8mo ago
      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.
      - simonw 8mo ago
        If the agent has permission to run kubectl config view what's to stop it from reading those config files directly?
        dcherman 8mo ago
        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.
        simonw 8mo ago
        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.
        dcherman 8mo ago
        You can make the identical argument for the CLI tool. Allow kubectl, deny everything else.
        simonw 8mo ago
        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.
  - deleted 8mo ago
    [deleted]
  - JambalayaJimbo 8mo ago
    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?
    - simonw 8mo ago
      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.
    - conception 8mo ago
      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.
    - gavmor 8mo ago
      Typically, no; an MCP is a deterministic program with SSE protocols.
  - staticassertion 8mo ago
    Oh. Yeah, that's neat at least. I don't think it's a big deal but that's nice enough.
simianwords 8mo ago
I don't agree with either. Skills with an API exposed by the service solves both your problems. The LLM can look at the OpenAPI spec and construct queries - I often do this pretty easily.
- simonw 8mo ago
  How can you disagree with my first point? You can't use skills if you don't have a Bash environment in which to run them. Do you disagree? Skills with an API exposed by the service usually means your coding agent can access the credentials for that service. This means that if you are hit by a prompt injection the attacker can steal those credentials.
  - simianwords 8mo ago
    Fair points, learned something new.
  - ntonozzi 8mo ago
    Something like Cloudflare's Code Mode fixes both of these! No privileged bash environment, no VM necessary, no exposing credentials to the LLM. As the article states, LLMs are fantastic at writing code, and not so good at issuing tool calls.
    - m11a 8mo ago
      Cloudflare's Code Mode is conceptually the same as Anthropic's Code Mode (https://www.anthropic.com/engineering/code-execution-with-mcp https://www.anthropic.com/engineering/code-execution-with-mc...), or the various open source implementations that predate and postdate those blog posts. tbh, that companies tried to make something proprietary of this concept is probably why its adoption has been weak and why we have "MCP vs CLI/Skills/etc" debates in the first place. In contrast, CLI tools only require a general a bash shell (potentially in a sandbox environment), which is very standardised.
- mememememememo 8mo ago
  It creates a new problem. I need an isolated shell environment. I need to lock it down. I need containers. I need to ensure said containers are isolated and not running as root. I probably need Kubernetes to do this at scale. &tc Also even with above there is more opportunity for the bot to go off piste and run cat this and awk that. Meanwhile the "operator" i.e. the Grandpa who has an iPhone but never used a computer has no chance of getting the bot back on track as he tries to renew his car insurance. "Just going to try using sed to get the output of curl https://.." "I don't understand I just want to know the excess for not at fault incident when the other guy is uninsured". Everyone has gone claw-brained. But it really is ok to write code and save that code to disk and execute thay code later. You can use MCP or even just hard coded API call from your back end to the service you wanna use like it's 2022.
tomjwxf 8mo ago
[dead]
throwuxiytayq 8mo ago
- MCPs can be long-running processes that have state, e.g., they can maintain a persistent connection with a server or local software. - MCPs are trivial to write and maintain - at least in my experience and language of choice - and bash scripts are cursed. But I guess you can use a different scripting language. - Agents can pollute their context by reading the script. I want to expose a black box that just works.

by simonw 8mo ago

staticassertion 8mo ago

Can you explain the auth part? I feel like auth for an agent is largely a matter of either verifying its context or issuing it a JWT that's scoped to its rights, which I assume is quite similar to how any tools would work. But I'm very unfamiliar with MCP.

monkpit 8mo ago
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.
- simonw 8mo ago
  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.
  - zbentley 8mo ago
    This is right. It’s not about scoping auth, it’s about preventing secret misuse/exfil. (Moved from wrong sub)
  - steve-atx-7600 8mo ago
    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.
  - dcherman 8mo ago
    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.
    - simonw 8mo ago
      If the agent has permission to run kubectl config view what's to stop it from reading those config files directly?
      - dcherman 8mo ago
        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.
        simonw 8mo ago
        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.
        dcherman 8mo ago
        You can make the identical argument for the CLI tool. Allow kubectl, deny everything else.
        simonw 8mo ago
        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.
- deleted 8mo ago
  [deleted]
- JambalayaJimbo 8mo ago
  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?
  - simonw 8mo ago
    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.
  - conception 8mo ago
    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.
  - gavmor 8mo ago
    Typically, no; an MCP is a deterministic program with SSE protocols.
- staticassertion 8mo ago
  Oh. Yeah, that's neat at least. I don't think it's a big deal but that's nice enough.

simianwords 8mo ago

I don't agree with either. Skills with an API exposed by the service solves both your problems. The LLM can look at the OpenAPI spec and construct queries - I often do this pretty easily.

simonw 8mo ago
How can you disagree with my first point? You can't use skills if you don't have a Bash environment in which to run them. Do you disagree? Skills with an API exposed by the service usually means your coding agent can access the credentials for that service. This means that if you are hit by a prompt injection the attacker can steal those credentials.
- simianwords 8mo ago
  Fair points, learned something new.
- ntonozzi 8mo ago
  Something like Cloudflare's Code Mode fixes both of these! No privileged bash environment, no VM necessary, no exposing credentials to the LLM. As the article states, LLMs are fantastic at writing code, and not so good at issuing tool calls.
  - m11a 8mo ago
    Cloudflare's Code Mode is conceptually the same as Anthropic's Code Mode (https://www.anthropic.com/engineering/code-execution-with-mcp https://www.anthropic.com/engineering/code-execution-with-mc...), or the various open source implementations that predate and postdate those blog posts. tbh, that companies tried to make something proprietary of this concept is probably why its adoption has been weak and why we have "MCP vs CLI/Skills/etc" debates in the first place. In contrast, CLI tools only require a general a bash shell (potentially in a sandbox environment), which is very standardised.
mememememememo 8mo ago
It creates a new problem. I need an isolated shell environment. I need to lock it down. I need containers. I need to ensure said containers are isolated and not running as root. I probably need Kubernetes to do this at scale. &tc Also even with above there is more opportunity for the bot to go off piste and run cat this and awk that. Meanwhile the "operator" i.e. the Grandpa who has an iPhone but never used a computer has no chance of getting the bot back on track as he tries to renew his car insurance. "Just going to try using sed to get the output of curl https://.." "I don't understand I just want to know the excess for not at fault incident when the other guy is uninsured". Everyone has gone claw-brained. But it really is ok to write code and save that code to disk and execute thay code later. You can use MCP or even just hard coded API call from your back end to the service you wanna use like it's 2022.

tomjwxf 8mo ago

[dead]

throwuxiytayq 8mo ago

- MCPs can be long-running processes that have state, e.g., they can maintain a persistent connection with a server or local software. - MCPs are trivial to write and maintain - at least in my experience and language of choice - and bash scripts are cursed. But I guess you can use a different scripting language. - Agents can pollute their context by reading the script. I want to expose a black box that just works.