The community declared MCP dead six months ago. Skills are the new standard now. Read any AI tooling blog and that is the line you get. A developer who uses these tools every day published “I Still Prefer MCP Over Skills” on Friday and the HN thread is still climbing with 150 comments and counting. His argument did not come from a slide deck. It came from trying to ship real integrations.
He is not wrong.
What Skills Are Actually Good For
Skills are great at one thing. Transferring knowledge to an LLM that did not have it before. If your SKILL.md teaches a model about your product, your API, your internal conventions, that is exactly what the format was designed for. You write the markdown, the model reads it, it knows things it did not know before. No infrastructure required.
That is genuinely useful. If you want an AI to understand your internal codebase, your API surface, your team conventions, writing a Skill is a reasonable way to do that.
Where Skills Fall Apart
The moment a Skill needs to actually do something, the format breaks down.
Every Skill that requires a CLI to function is dead on arrival in ChatGPT, Perplexity, standard web Claude, and any ephemeral compute environment. Those platforms do not run arbitrary binaries. They run LLM inference. If your Skill starts with “install this CLI first,” you have already excluded every client that is not a full compute environment like Claude Code or Codex.
The context bloat problem is the one that gets talked about less. Loading an entire SKILL.md into context when you only need one function signature is the equivalent of handing someone a car’s entire owner’s manual when they just want to call car.turn_on(). The LLM has to read all of it. You pay for those tokens. The context window fills up. Your actual task gets less room.
The secret management situation is worse than it sounds. Skills often dump credentials into .env files in plain text. MCP handles auth via OAuth, which means the model never sees raw tokens and the auth flow can be managed centrally. In ephemeral environments, the difference is stark. A CLI works today and forgets your credentials tomorrow. OAuth remembers.
The Fragmentation Nobody Talks About
Skill management is the wild west. Some tools support npx skills. Some support GitHub installs. Some support marketplaces. Some support nothing. The author tried installing an OpenClaw skill into Claude and got YAML parsing errors because metadata fields did not match the platform’s expectations.
This is not a hypothetical problem. It is the actual experience of trying to share skills across agent frameworks. The skill format promises portability. The implementation delivers incompatibility.
MCP does not have this problem because it was designed for a specific architecture. A server is a server. A client is a client. The protocol is the protocol. If a tool supports MCP, it works with any MCP server. If a tool supports skills, it depends on which skill format version the tool decided to implement this week.
The Real Architecture Question
MCP gets the architecture right for service access. Remote servers, OAuth authentication, sandboxed execution, auto-updates that work across all clients simultaneously. These are not nice-to-haves. They are the difference between an integration that works in production and an integration that requires manual setup every time the environment changes.
Skills give you a markdown file and a dependency on a binary. For pure knowledge transfer, that is fine. For anything that needs to reach a live API, manage credentials, and run reliably across platforms, you are fighting the format.
The community declared MCP dead because the marketing shifted to skills. The developers who actually need their AI to make API calls, access authenticated services, and run in ephemeral environments are still using MCP. The gap between the narrative and the reality is worth thinking about before you rewrite your integrations.
Sources:
– David Coffee — I Still Prefer MCP Over Skills
– Hacker News Discussion
