5 ms·

All of that can be solved in better ways than MCP. 1+2+4 belongs to sandboxing. 3 to sandbox UIs. Ideally baked into the next generation OSs. MCP is the wrong

by kaoD 7d ago

All of that can be solved in better ways than MCP. 1+2+4 belongs to sandboxing. 3 to sandbox UIs. Ideally baked into the next generation OSs. MCP is the wrong abstraction for all of that. Skills are better as pluggable interfaces, and I predict[0] chat and agentic loops will converge eventually (Anthropic already did this correctly; OpenAI, it's your turn) and skills marketplace will replace MCP in its current form. I see value in MCP, but it feels like a stopgap/stepping stone. [0] Where "predict" = "hope". The best solutions are often not the winners.

tacoooooooo 7d ago
Skills are adjacent to MCP. They do not cover the same surface, in anyway. I don't understand this argument at all (and I see lots of people making it, so enlighten me) I want my agent to be able to convert reliably between timezones. A skill does not solve this. It needs a deterministic tool it can call
- kaoD 7d ago
  Skills are not only Markdown files. I often structure my skills as small Python scripts and the actual Markdown is only the skill front matter and maybe some brief documentation. You can even stick an OpenAPI schema or whatever you see fit. If you often need timezone conversion, sounds like a `timezones` skill exposing a few lines in a Python script. Boom. No MCP needed. No server needed. It's just files, all the way down. If you find yourself operating with dates a lot maybe you need a `datetime` skill wrapping a bunch of tiny scripts. Fully deterministic, cheap on tokens, and you can even run them without an agent (shocking nowadays :P) As I identify repetitive actions I add (Claude adds) new scripts to the Skill to save tokens in the future, whereas MCP I'm at the mercy of the server provider. E.g. I have a Magic the Gathering skill with a bunch of tools to retrieve card databases, simulate hands, get card images... This article enlightened me: https://mariozechner.at/posts/2025-11-02-what-if-you-dont-need-mcp/ https://mariozechner.at/posts/2025-11-02-what-if-you-dont-ne... This is why I don't feel Skills are orthogonal. They feel like MCP on steroids since the scripts can be composed with Bash et al (huge battle-tested ecosystem, plenty in the training set)... and you don't need crappy abstractions like "resources" (yes, that's a thing in MCP) when the agent has a shell and a filesystem. I've used this pattern to great success. Nowadays I just share these `.skill` packages with my friends (I think they're just a fancy ZIP file?) The only thing missing for me is credentials and sandboxing (see my GP post). I have my own ideas on how to solve this (and some of that Claude in cloud already solves for me), but it's not easy (which is how MCP won).
  - tacoooooooo 7d ago
    > If you often need timezone conversion, sounds like a `timezones` skill exposing a few lines in a Python script. Boom. No MCP needed. No server needed okay, but now my agent needs a coding environment / sandbox. MCP (or tool use in general) solves this without that (extremely tenuous and expensive to do at scale in prd) requirement. The skill is totally orthogonal here--solving a totally separate problem
    - kaoD 7d ago
      I guess someone could expose the coding environment via MCP.
      - tacoooooooo 7d ago
        They could and code execution is actually exposed to the model as a tool! But if im running a customer support agent at scale, i'm not sure I want it to be able to write code. I do know I need it to be able to convert timezones though. (its also far more expensive / token inefficient to have it write code each time to convert timezones rather to use a predefined tool I made an know works)
        kaoD 7d ago
        > token inefficient to have it write code It does not write code. It just calls my tool. But I see your other points though.

by kaoD 7d ago

tacoooooooo 7d ago

Skills are adjacent to MCP. They do not cover the same surface, in anyway. I don't understand this argument at all (and I see lots of people making it, so enlighten me) I want my agent to be able to convert reliably between timezones. A skill does not solve this. It needs a deterministic tool it can call

kaoD 7d ago
Skills are not only Markdown files. I often structure my skills as small Python scripts and the actual Markdown is only the skill front matter and maybe some brief documentation. You can even stick an OpenAPI schema or whatever you see fit. If you often need timezone conversion, sounds like a `timezones` skill exposing a few lines in a Python script. Boom. No MCP needed. No server needed. It's just files, all the way down. If you find yourself operating with dates a lot maybe you need a `datetime` skill wrapping a bunch of tiny scripts. Fully deterministic, cheap on tokens, and you can even run them without an agent (shocking nowadays :P) As I identify repetitive actions I add (Claude adds) new scripts to the Skill to save tokens in the future, whereas MCP I'm at the mercy of the server provider. E.g. I have a Magic the Gathering skill with a bunch of tools to retrieve card databases, simulate hands, get card images... This article enlightened me: https://mariozechner.at/posts/2025-11-02-what-if-you-dont-need-mcp/ https://mariozechner.at/posts/2025-11-02-what-if-you-dont-ne... This is why I don't feel Skills are orthogonal. They feel like MCP on steroids since the scripts can be composed with Bash et al (huge battle-tested ecosystem, plenty in the training set)... and you don't need crappy abstractions like "resources" (yes, that's a thing in MCP) when the agent has a shell and a filesystem. I've used this pattern to great success. Nowadays I just share these `.skill` packages with my friends (I think they're just a fancy ZIP file?) The only thing missing for me is credentials and sandboxing (see my GP post). I have my own ideas on how to solve this (and some of that Claude in cloud already solves for me), but it's not easy (which is how MCP won).
- tacoooooooo 7d ago
  > If you often need timezone conversion, sounds like a `timezones` skill exposing a few lines in a Python script. Boom. No MCP needed. No server needed okay, but now my agent needs a coding environment / sandbox. MCP (or tool use in general) solves this without that (extremely tenuous and expensive to do at scale in prd) requirement. The skill is totally orthogonal here--solving a totally separate problem
  - kaoD 7d ago
    I guess someone could expose the coding environment via MCP.
    - tacoooooooo 7d ago
      They could and code execution is actually exposed to the model as a tool! But if im running a customer support agent at scale, i'm not sure I want it to be able to write code. I do know I need it to be able to convert timezones though. (its also far more expensive / token inefficient to have it write code each time to convert timezones rather to use a predefined tool I made an know works)
      - kaoD 7d ago
        > token inefficient to have it write code It does not write code. It just calls my tool. But I see your other points though.