2026: The Year of Skills
Table of Contents
This was MCP’s year. We re-arranged our schedules to accomodate the highly anticipated server ships from our vendors. The promise of connecting agents to tools was irresistible. We wanted to see it, we wanted to use it, we wanted to build on it.
It wasn’t all good. MCP, as a protocol and a suite of products, is half-vibes. It mostly works, but I couldn’t tell you how. And that hasn’t stopped anyone from unlocking an incredible amount of value by letting their agents churn through tokens and make API calls on their behalf.
Something quieter happened in October. Anthropic released Skills, and a few days ago donated as an open format. No protocol specification; just markdown and some executables. If 2025 was the year of MCP, 2026 is shaping up to be the year of skills. But I hope it’s actually the year of CLIs.
The Context Tax
MCP’s core problem is upfront cost. Every MCP tool definition loads the context window before the agent reads a single user message. Each tool carries a detailed JSON schema with parameter descriptions, enum values, and usage examples. The Datadog search_datadog_logs tool alone has 12 parameters with multi-sentence descriptions. The GitHub pull_request_read tool enumerates seven method options with paragraph-length explanations of each. Those 38 tools consume 20k+ tokens of context window before I do anything useful. Anthropic acknowledged this directly in their November 2025 engineering post “Code execution with MCP”:
As MCP usage scales, there are two common patterns that can increase agent cost and latency: tool definitions overload the context window; intermediate tool results consume additional tokens.
Compare this to a CLI tool. The gh CLI - with the same functionality as the MCP tool - produces 650 tokens in top-level help text. And the agent doesn’t even need that upfront. It knows gh exists on the path; if and when it needs to list pull requests, it runs gh pr list --help (another 700 tokens) and moves on. Progressive disclosure is incredibly efficient. The total help text across all gh subcommands is about 8k tokens - and no agent ever needs all of it at once.
The Security Model
Simon Willison laid this out clearly in his April 2025 post on MCP prompt injection: rug pulls, tool shadowing, poisoning. MCP servers are long-running processes with persistent connections and mutable state. The attack surface is large and opaque.
Skills aren’t immune to these problems, but the properties are fundamentally different. There’s nothing magic about CLI tools and their security models.
Inspectable. A skill is a Markdown file and some scripts. There’s no protocol-level metadata hidden from the user. What you see is what the agent sees.
Reproducible. Skills that wrap CLI tools are just as safe (or unsafe) as running those tools directly.
Bounded. A CLI tool runs as your user, in your shell, with your permissions.
None of this makes skills perfectly safe. But inspectable, traceable, and bounded is a much better starting position than “opaque, mutable, and composable in ways the user can’t see.”
Equal Footing
MCP was a protocol designed for machines to talk to machines. Humans don’t interact with JSON tool schemas. The entire abstraction exists in a layer that only the agent sees, which is exactly what makes it hard to audit and easy to exploit.
Skills are tools that work the same way for humans and agents. The instructions are in Markdown that refer to executables files on your path. The discovery mechanism is a filesystem. They’re the same patterns we’ve used for decades: README files, man pages, --help flags, scripts in bin/.
The simplicity is the point. When the same artifact serves both the human and the agent, you get better artifacts. Humans write clearer instructions because they might read them too.
Where we go from here
I’m not sure what the future of MCP will be. But for the common case, skills are cheaper (fewer tokens), safer (inspectable), and more portable (Markdown works everywhere).
2025 was the year everyone scrambled to build MCP servers. 2026 is the year we realize most of them should have been skills. And, I hope we start building the CLI tools that makes those powerful. I’ve always wanted a better version of dogshell that supports read/write, OAuth, and a more intuitive interface. I hope to see more of these from every company.