Why Every Tool Now Needs Two Faces - CLI for Humans, MCP for AI

· 4 min read

My blog publisher has two faces. Through the CLI, I type clio publish and watch colorful output stream past, confirmation messages that make me feel in control. Through MCP, Claude calls publish_essay() and receives structured JSON, no colors needed. Same functionality. Different species of user. This isn’t redundancy - it’s evolution.

We used to debate CLI versus GUI. Now we’re architecting something stranger: parallel infrastructures for carbon and silicon users. Every tool splitting into two paths, like light through a prism, each wavelength optimized for different kinds of perception.

The CLI speaks human. Progress bars because we need to see movement. Colored output because our pattern recognition evolved for a world of meaning through hue. Verbose confirmations because we distrust what we cannot see happening. --help flags written in prose because we parse intent through narrative.

The MCP speaks machine. JSON responses because structure is meaning. No progress bars because async promises are the only timeline that matters. Silent success because exceptions are the only information worth transmitting. Documentation as schema because types are more precise than prose.

I watched myself building this duality into my blog publisher without planning it. The human side got prettier while the machine side got more atomic. Not because I decided to segregate interfaces, but because the physics of interaction demanded it. Humans need to feel the tool working. AI needs to know it worked.

This isn’t about backwards compatibility. We’re not maintaining legacy human interfaces while building for an AI future. We’re recognizing that both interfaces are primary, serving constituents who inhabit the same systems through fundamentally different phenomenologies.

When GitHub Copilot reads my code, it doesn’t see syntax highlighting. When I read the same code, the colors are load-bearing. The code hasn’t changed, but it exists differently for each of us. We’re building Schr ö dinger’s interfaces - simultaneously optimized for observers who collapse different aspects of the wave function.

The pattern extends beyond developer tools. Notion has an API for agents and a canvas for humans. Stripe has a dashboard for humans and webhooks for machines. Every service sprouting dual interfaces, not as redundancy but as recognition that we’re serving two species of user who parse reality through different grammars.

What fascinates me is where these interfaces diverge. Humans want confirmation; machines want idempotency. Humans need metaphors; machines need contracts. Humans parse meaning through journey; machines parse through state.

The MCP protocol isn’t just another API standard. It’s acknowledgment that AI agents deserve their own ergonomics. Not anthropomorphized interfaces that pretend machines think like us, but genuinely alien interfaces optimized for genuinely alien cognition.

But here’s the twist: MCP servers could theoretically serve humans too. Imagine a terminal that translates MCP’s structured responses into human-readable output. Or a GUI that wraps MCP functions in buttons and forms. The same server, multiple clients. The protocol becomes the source of truth, with adapters for different kinds of consciousness.

Maybe the future isn’t parallel interfaces but unified backends with species-specific frontends. MCP as the universal protocol, with CLIs, GUIs, and AI agents all consuming the same structured functionality through their own lenses. The tool doesn’t need two faces - it needs one protocol and multiple masks.

Yet something resists this convergence. When I build for humans, I embed assumptions about patience, context, error recovery. When I build for AI, I assume infinite memory, perfect recall, no emotional state. These aren’t just interface differences - they’re architectural choices that cascade through the entire system.

We’re discovering that human-optimized and AI-optimized systems diverge at levels deeper than presentation. Different error handling philosophies. Different concepts of session state. Different assumptions about what constitutes “done.” The split isn’t cosmetic - it’s ontological.

The future isn’t “AI-first” or “human-centered” design. It’s building for a world where every tool serves two masters with fundamentally different ways of knowing. Where convergence and divergence happen simultaneously. Where the same function exists in quantum superposition until observed by human or machine.

P.S. Yesterday I caught myself explaining to Claude how to use a tool I built. Then I realized - I wasn’t teaching it the CLI commands. I was describing the MCP schema. We’ve crossed a threshold where tools need documentation in two languages, for two kinds of mind. Whether these converge or diverge further remains an open question - one we’re answering in production, one integration at a time.