3 ms·

This isn't a zero-sum game or a choice of one over the other. They solve different layers of the developer experience: MCP provides a standardized, portable int

This isn't a zero-sum game or a choice of one over the other. They solve different layers of the developer experience: MCP provides a standardized, portable interface for external data/tools (the infrastructure), while Skills offer project-specific, high-level behavioral context (the orchestration). A robust workflow uses MCP to ensure tool reliability and Skills to define when and how to deploy those tools.

Aperocky 6mo ago
MCP is just CLI wrapped in boxes. CLI is the same API in more concise format. At minimum, the same amount of context overhead exist for MCP, but most of the time more because the boxes have size. CLI can be secure, AWS CLI is doing just fine. You can also play simple tricks to hide secret in a daemon or run them remotely, and all of them are still smaller than a MCP.
- BeetleB 6mo ago
  I've always wondered: Doesn't the fact that the MCP input/output is more structured lead to higher reliability? With MCP you declare the types for input (string, int, list, etc) and output. As part of our product, we have an MCP server. Since many of our MCP tools are expensive, for our tests we simply give the LLM all the tool descriptions (but in text form, not structured) and ask it which tool it would call for a given query and assert on the response. The tests are flaky. In practice, I've always seen the LLM make the right tool call with the proper formatting of args, etc. In the tests (same LLM model), it occasionally makes mistakes on the argument types and it has to try again before it gets it right. My assumption was that the structure MCP provides was the reason there was a discrepancy.
  - Aperocky 6mo ago
    This maybe one of the area that MCP are ok-ish, however at huge cost to context.
    - BeetleB 6mo ago
      As I and others have pointed out: The context problem with MCP is mostly solved. See https://news.ycombinator.com/item?id=47719249 https://news.ycombinator.com/item?id=47719249 for an example I gave.
      - cruffle_duffle 6mo ago
        Tool discovery is only one very small part of the “context problem”. The bigger problem is the outputs. You can’t compost them. Ever watch Claude code run some crazy shit through python and jq to take some input, transform it in some crazy way and output exactly what it needs back into its context? You simply can’t do that with mcp. It’s basically forced to accept the exact shape of the mcp output into its context and then take that intermediate output and dump it right back into another tool. That is incredibly wasteful! If your lucky the mcp might expose a way to ship its output into a text file so at least the agent can have a go at it with CLI tools.
        BeetleB 6mo ago
        I can see your point, but for pretty much everything I use MCP for, composability is not useful.
zhdc1 6mo ago
Completely agree. I don’t see why people view this as an either or decision. Also worth mentioning that some paid MCP providers offer an actual value added. Sure, I can use curl or a self hosted crawler for web searches, but is it really worth the pain?
soco 6mo ago
Also, the skills can be ignored or thwarted if the LLM feels like, while a policy at the MCP server level stays there.
chris_ivester 6mo ago
This is exactly right, and I'd add one more layer that the thread is mostly missing: this combination matters most when the agent itself is hosted in the cloud rather than running locally. Skills + MCP is the architecture for cloud-hosted agents - Skills give the agent its context and workflow, MCP tools give it reach into external services without the agent needing to manage credentials or runtime dependencies.
dvcrn 6mo ago
Hi, author here! I fully agree with your comment here and that’s exactly my point in the post: Different tools that work great for different tasks. If anything, the post is a take against treating Skills + CLI as a zero-sum replacement for MCP, and calling MCP dead/outdated Especially portability is just not possible with Skills+CLI (yet). I can use the same MCP servers through remote MCP on my phone, web, iPad, in ChatGPT, Perplexity, Claude, Mistral and so on, which I can’t do with Skills.

Aperocky 6mo ago

MCP is just CLI wrapped in boxes. CLI is the same API in more concise format. At minimum, the same amount of context overhead exist for MCP, but most of the time more because the boxes have size. CLI can be secure, AWS CLI is doing just fine. You can also play simple tricks to hide secret in a daemon or run them remotely, and all of them are still smaller than a MCP.

BeetleB 6mo ago
I've always wondered: Doesn't the fact that the MCP input/output is more structured lead to higher reliability? With MCP you declare the types for input (string, int, list, etc) and output. As part of our product, we have an MCP server. Since many of our MCP tools are expensive, for our tests we simply give the LLM all the tool descriptions (but in text form, not structured) and ask it which tool it would call for a given query and assert on the response. The tests are flaky. In practice, I've always seen the LLM make the right tool call with the proper formatting of args, etc. In the tests (same LLM model), it occasionally makes mistakes on the argument types and it has to try again before it gets it right. My assumption was that the structure MCP provides was the reason there was a discrepancy.
- Aperocky 6mo ago
  This maybe one of the area that MCP are ok-ish, however at huge cost to context.
  - BeetleB 6mo ago
    As I and others have pointed out: The context problem with MCP is mostly solved. See https://news.ycombinator.com/item?id=47719249 https://news.ycombinator.com/item?id=47719249 for an example I gave.
    - cruffle_duffle 6mo ago
      Tool discovery is only one very small part of the “context problem”. The bigger problem is the outputs. You can’t compost them. Ever watch Claude code run some crazy shit through python and jq to take some input, transform it in some crazy way and output exactly what it needs back into its context? You simply can’t do that with mcp. It’s basically forced to accept the exact shape of the mcp output into its context and then take that intermediate output and dump it right back into another tool. That is incredibly wasteful! If your lucky the mcp might expose a way to ship its output into a text file so at least the agent can have a go at it with CLI tools.
      - BeetleB 6mo ago
        I can see your point, but for pretty much everything I use MCP for, composability is not useful.

zhdc1 6mo ago

Completely agree. I don’t see why people view this as an either or decision. Also worth mentioning that some paid MCP providers offer an actual value added. Sure, I can use curl or a self hosted crawler for web searches, but is it really worth the pain?

soco 6mo ago

Also, the skills can be ignored or thwarted if the LLM feels like, while a policy at the MCP server level stays there.

chris_ivester 6mo ago

This is exactly right, and I'd add one more layer that the thread is mostly missing: this combination matters most when the agent itself is hosted in the cloud rather than running locally. Skills + MCP is the architecture for cloud-hosted agents - Skills give the agent its context and workflow, MCP tools give it reach into external services without the agent needing to manage credentials or runtime dependencies.

dvcrn 6mo ago

Hi, author here! I fully agree with your comment here and that’s exactly my point in the post: Different tools that work great for different tasks. If anything, the post is a take against treating Skills + CLI as a zero-sum replacement for MCP, and calling MCP dead/outdated Especially portability is just not possible with Skills+CLI (yet). I can use the same MCP servers through remote MCP on my phone, web, iPad, in ChatGPT, Perplexity, Claude, Mistral and so on, which I can’t do with Skills.