After months wrestling with bloated context windows and flaky protocol servers, I went back to basics — and my AI coding agent finally started working the way I wanted.
I was the MCP evangelist in my team. I set up the Atlassian MCP server, the Playwright MCP, the Figma MCP and much more. Then I started actually using them with Claude Code on a real project.
I keep hitting the limit on Claude Pro plan with just a few round of prompting. I check the token counter and found out that all the MCP servers have took up almost 40% to 50% of the context window before the agent did a single useful thing!
That was the moment I uninstalled everything and opened a terminal.
The MCP promise vs. the MCP reality
Model Context Protocol arrived in late 2024 with enormous backing. Every major AI provider endorsed it. The pitch was clean: one standard protocol, any AI model, any tool. Build an MCP server for your database and every AI client could query it. No more per-client glue code.
In theory, beautiful. In practice, the seams show quickly.
What actually happens when MCP loads
A standard Atlassian MCP server dumps its entire tool schema into your context window on initialization — all 73 tools, their parameter descriptions, authentication flows, state management instructions. Your agent hasn't done anything yet, and roughly 40% of your context budget is already gone.
The deeper problem is architectural. MCP asks AI models to operate through an abstraction layer they were never trained on. Claude, GPT-4, Gemini — these models have been trained on billions of lines of terminal interactions. Stack Overflow answers, GitHub READMEs, documentation, tutorials — all of it is saturated with shell commands. They know git, gh, docker, kubectl as fluently as a senior engineer who's been at the terminal for a decade.
MCP schemas? Zero training data. The model is improvising every time.
Why CLI wins for developer workflows
Self-documenting by design. Every CLI tool ships with --help and man pages. The agent can explore what a command does, drill into subcommands, and discover options — all without an external schema definition. No MCP server to maintain, no schema to keep in sync.
Composability built over 50 years. Unix pipes. Output routing. Chaining. Parallel execution with && and ||. MCP is designing in 2025–2026 what Unix figured out in the 1970s and spent five decades debugging. CLI composability carries the reliability of a v50 system. MCP composability is v0.1.
LLMs just know this stuff. The model has seen find . -name "*.ts" | xargs grep "import" ten thousand times. It improvises novel combinations because the composability grammar is embedded in its weights. When it hits an error, it knows how to parse stderr, adjust flags, and retry. That fluency simply doesn't exist for MCP tool chains.
"Tool results and definitions can sometimes consume 50,000+ tokens before an agent reads a request... At Anthropic, we've seen tool definitions consume 134K tokens before optimization." - Anthropic Engineering Blog
"Previously, the Projects toolset, as with other now-consolidated toolsets, used a significant portion of the context window for the tools list. As a result, we've reduced token usage by around 23,000 tokens (50%)." - GitHub Changelog
"MCP were a mistake. Bash is better." - Peter Steinberger, creator of OpenClaw
Introducing Sidekick
This brings me to a project I've been using heavily: Sidekick (sdkck). It's an open-source agentic CLI built to give AI coding agents like Claude Code a clean, composable, extensible interface to the tools they need — without the MCP overhead.
Sidekick (sdkck)
Agentic CLI that provides multiple tools via plugins
Usage
$ npm install -g sdkck
$ sdkck COMMAND
running command...
$ sdkck (--version)
sdkck/0.4.0 linux-x64 node-v20.20.0
$ sdkck --help [COMMAND]
USAGE
$ sdkck COMMAND
...
Commands
sdkck commandssdkck help [COMMAND]sdkck pluginssdkck plugins add PLUGINsdkck plugins:inspect PLUGIN...sdkck plugins install PLUGINsdkck plugins link PATHsdkck plugins remove [PLUGIN]sdkck plugins resetsdkck plugins uninstall [PLUGIN]sdkck plugins unlink [PLUGIN]sdkck plugins updatesdkck search QUERYsdkck update [CHANNEL]sdkck version
sdkck commands
List all sdkck commands.
USAGE
$ sdkck commands [--json] [-c id|plugin|summary|type... | --tree] [--deprecated] [-x | ] [--hidden]
[--no-truncate | ] [--sort id|plugin|summary|type | ]
FLAGS
-c, --columns=<option>... Only show provided columns (comma-separated).
<options: id|plugin|summary|type>
-x, --extended Show extra columns.
--deprecated Show deprecated commands.
--hidden Show hidden commands.
--no-truncate Do not truncate output.
--sort=<option> [default: id] Property to sortWhat makes Sidekick interesting isn't just what it does — it's how it fits into AI-first workflows. Because it's a standard CLI, Claude Code and other agents can discover its capabilities naturally:
# Agent discovers available commands
sdkck --help
# Search for specific functionality
sdkck search "create pr"
sdkck search "jira" -d
sdkck search "update issue" --details
The search command is the key insight. Instead of dumping your entire tool catalogue into context, an agent can query for exactly what it needs in the moment. This is context efficiency by design.
Using Sidekick with Claude Code
Here's how to set this up. First, install Sidekick and any plugins your workflow needs:
# Install Sidekick globally
npm install -g sdkck
# Install plugins (community or your own)
sdkck plugins add myplugin
sdkck plugins add someuser/someplugin
# Verify installation
sdkck version
Then document it in your CLAUDE.md at the project root. This is the equivalent of an MCP server config — except it costs zero tokens at load time:
# CLAUDE.md
## Available CLI Tools
sdkck is installed and available. Use it for task and issue management.
### Discovery
sdkck search "<query>" # find relevant commands
sdkck search "<query>" -d # detailed help for each result
sdkck --help # full command list
### Workflow
Always search before assuming a command exists.
Prefer composing sdkck commands with standard Unix pipes.
When Claude Code encounters a task, it searches first, then acts. Here's what that looks like in practice:
# Claude Code working on a feature branch
# 1. Search for relevant commands
sdkck search "create pr" --details
# 2. Compose with existing tools
gh pr create --title "feat: add auth" --body "$(cat PR_TEMPLATE.md)"
# 3. Chain with other commands naturally
sdkck search "jira" | head -5
Extending Sidekick with plugins
The plugin system is where Sidekick becomes genuinely powerful. You can build and link your own tools for development:
Install a plugin from a github url.
sdkck plugins install https://github.com/someuser/someplugin
# Inspect what got installed
sdkck plugins inspect my-jira-plugin
# List all installed plugins
sdkck plugins
# Keep plugins updated
sdkck plugins update
For other coding agents — Cursor, Copilot, Kiro, OpenClaw — the integration pattern is the same: document Sidekick in whatever context file the agent reads (AGENT.md, .cursorrules, agent instructions), and let the agent discover capabilities through sdkck search rather than preloading schemas.
The honest nuance
I want to be fair here: MCP isn't bad. It has a legitimate use case, and writing it off entirely would be intellectually dishonest.
For 80–90% of developer-facing use cases — building features, running tests, managing git, automating your own workflows — CLI is the faster, cheaper, more reliable path. For multi-tenant products where your agent acts on behalf of customers inside their organizations, MCP's governance model earns its overhead.
The smartest teams in 2026 aren't picking sides. They're using CLI for development workflows and MCP for customer-facing compliance-sensitive features. But if you're a developer automating your own stack, there's no reason to carry MCP's weight.
Getting started
If you want to try this approach today:
Install Sidekick
npm install -g sdkck
# Explore what's available
sdkck commands
sdkck search "anything"
# In your project root
echo "sdkck is available. Use 'sdkck search <query>' to find commands." >> CLAUDE.md
That's it. No JSON config. No SSE server. No schema dumped into your context. Just a tool your agent can pick up and use.
The Unix philosophy — small, composable tools that do one thing well — has proven remarkably durable. Fifty years later, it turns out it's also the best interface we've built for AI agents. Not because we planned it that way. Because we already spent fifty years making it work.
Top comments (0)