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)
The Best Companion Tool for AI Agents
One CLI to search, connect, and command every tool in your stack. Zero context window bloat. Maximum productivity.
Key Features
Instant Commands from OpenAPI/Postman
-
Point Sidekick at any OpenAPI/Swagger spec or Postman collection — local file or URL — and every endpoint becomes a CLI command instantly.
# Import an OpenAPI spec from a URL or local file sdkck openapi import https://petstore3.swagger.io/api/v3/openapi.json --name petstore # Import a Postman collection the same way sdkck openapi import ./postman_collection.json --name myapi # Every operation is now a real command sdkck petstore listPets sdkck petstore getPetById --param petId=42 sdkck petstore createPet --body name=Fido --body tag=dog
…
What 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:
Detail guide can be found here
# 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 (1)
The context window savings get attention, but there's something else: CLI tools expose a gradient of interaction.
--dry-run,--verbose,--format json— the agent can probe cheaply before committing. MCP is binary: the tool is either loaded or it isn't, and once loaded, you pay the full schema cost whether you use one endpoint or fifty.The
sdkck searchpattern is basically lazy loading for tool discovery. The agent finds what it needs in the moment rather than ingesting a catalog upfront. That's not just cheaper, it's closer to how you'd actually want an agent to reason through a problem. Start narrow, expand only when the task demands it.