Here’s my hot take after a year of experimenting with AI agents: MCPs are mostly a solution to a problem that doesn’t exist.
Not all of them. But most of the ones being built right now, for tools that already have a solid CLI? They’re unnecessary. The AI doesn’t need them. It was already doing the thing.
I say this as someone who went on a genuine MCP binge. New integration drops, I installed it. Shiny new server for a tool I use daily, sign me up. I’ve tried probably a dozen at this point. The pattern became hard to ignore.
The GitHub MCP problem
The GitHub MCP was the one that finally made it click.
I set it up properly: authenticated, configured, the whole thing. It worked. I could ask my AI agent to check PR statuses, create issues, all of it through this nice structured integration. Great!
Then I noticed something. In other contexts, without the MCP at all, the agent was running gh pr list, gh issue create, gh repo clone the whole GitHub CLI suite, completely unprompted, completely correctly. No special configuration. Just… it knew.
The MCP was a middleman between the model and a tool it already spoke fluently. I was adding plumbing to a tap that wasn’t dry.
So I uninstalled it. Shrugged. Moved on.
Then reinstalled it two months later when I forgot this lesson. Then uninstalled it again. I’ve done this cycle three times now.
Why the CLI is already AI’s first language
Here’s what makes this obvious in retrospect: these models were trained on an enormous amount of terminal output. Man pages. README files. Stack Overflow answers packed with CLI commands and their outputs. GitHub issues full of shell sessions. Every --help flag, every brew install, every curl-pipe-bash that somebody pasted into a forum thread.
The command line isn’t just something AI agents can figure out. It’s closer to their native environment. They understand flags, exit codes, piped output, environment variables: not because someone wrote a custom integration, but because humans have been writing about this stuff for decades and it all ended up in the training data.
When you give an AI agent access to a terminal and tell it to interact with GitHub, it doesn’t need a structured API wrapper. It reaches for gh the same way a senior engineer would.
The same logic applies to most standard developer tooling. Good CLIs are well-documented, well-used, and therefore well-understood by the model. Shopify CLI, AWS CLI, kubectl, docker, git I haven’t needed an MCP for any of them. I just let the agent use the terminal.
Where MCPs actually make sense
I want to be fair here, because MCPs aren’t useless. They solve real problems in specific situations.
If you need complex OAuth flows and token management, a CLI isn’t going to cut it. If your tool streams data bidirectionally and needs the model to react to events in real time, you need something more than stdin/stdout. If your tool has no CLI at all (some proprietary internal system, some third-party service with only a web UI) then building an MCP is genuinely the right call.
The test I’ve landed on is simple: does a good CLI exist for this? If yes, try the CLI first. Don’t build the MCP until you’ve confirmed the AI can’t handle it through the terminal.
Most of the time, it can.
MCPs are the new microservices
Here’s what’s actually happening culturally: MCPs have become a buzzword inside a buzzword.
We’re deep in an AI hype cycle, and MCPs are a shiny sub-ecosystem within it. There’s a particular kind of developer energy (I recognize it because I’ve felt it) that gets excited about building integrations. About making things connect. About having a little server that talks to another little server in a structured, typed, elegant way.
That energy is great. It builds ecosystems. It’s also how we ended up with microservices architectures for apps that would have been fine as a monolith.
The MCP space right now has a lot of “I built this because it was interesting to build” energy, and I say that without judgment because I’ve absolutely done the same thing. But if you’re reaching for an MCP because MCPs are the thing you do when you want AI to interact with a tool (rather than because the CLI genuinely wasn’t good enough) you might want to pump the brakes.
Shipping an MCP for a tool that already has an excellent, widely-documented CLI isn’t an integration. It’s a wrapper around something that didn’t need wrapping, with a maintenance burden attached.
The practical test
Before you build (or install) an MCP for a developer tool, ask yourself two things:
- Does a CLI exist for this?
- Have I actually tried giving the AI access to the terminal and seeing what happens?
If you’ve done step 2 and the model struggled, great! Now you have a real reason to build the MCP. But in my experience, step 2 usually surprises you.
I’ve watched Claude Code run Shopify CLI commands I didn’t know existed. I’ve seen it compose multi-step gh workflows that I would have taken longer to type manually. The agents aren’t doing anything magical. The CLI is just a format they know well: better than most people expect.
Try the CLI first. You might find you don’t need the MCP, and that’s one less thing to maintain, configure, and update when the underlying tool changes its API.
I build integrations for a living at Victoria Garland, which maybe makes me the wrong person to tell you not to build integrations. But sometimes the CTO job is knowing which complexity to skip.