I like MCP. I think it is useful. I also think a lot of people are discovering it and immediately making the same mistake software people make every time a new interface layer shows up. They build directly to the interface and skip the boring part where the tool becomes real.
The boring part matters. A good CLI gives you a tool a human can run, a script can call, a cron job can use, a test can exercise, and an agent can eventually wrap. That is a much healthier order than inventing a protocol-shaped server first and hoping the capability under it becomes coherent later.
Why This Matters More Right Now
This pattern is getting industry momentum now. MCP has an official specification, official SDKs, a community registry, and even vendor registries showing up around it. Good. That means the protocol is becoming real infrastructure instead of just a neat idea. It does not change the deeper point though. Protocol popularity does not remove the need for a useful substrate.
I was already doing variants of this years ago with the `-wrap` work. The instinct was the same: first expose a system in a way a real operator can actually use. Then compose on top of it. The agent story just makes that pattern easier to explain to people who were not paying attention before.
The CLI Gives You More Than One Interface
- A shell user can run it directly.
- A script can chain it with `jq`, `xargs`, pipes, and exit codes.
- A test can call it without booting an agent runtime.
- An MCP server can wrap it with a thin translation layer.
- A human can inspect failures in plain text instead of protocol goo.
That is real leverage. You build the capability once and expose it through multiple surfaces. MCP then becomes one interface among several, not the only reason the thing exists.
What Goes Wrong With MCP-First
MCP-first often produces tools that are hard to test outside the agent, weird to debug, and too entangled with whatever the current agent environment expects. It feels fast because the demo happens quickly. It feels bad later when the protocol changes, the auth model shifts, or you just want to use the capability from a shell script without dragging an agent stack behind it.
The Unix lesson still holds: composable tools age better than specialized magic endpoints. The AI layer did not repeal that. If anything, it made it more important.
How We Think About It At Intelligrit
When we build connectors and agent surfaces, we want something that can live inside a customer environment, be exercised by a human, be tested in isolation, and then be wrapped cleanly for AI use. That usually means a small backend service or CLI-shaped interface first, and then MCP or another agent-facing protocol second.
That order also keeps the system more portable. If MCP stays dominant, great. If some other interface wins more mindshare later, you still own the useful core.