CLI > MCP

What's the point of MCP?

I wanted Claude to access my Slack. To make that happen, I had to find and install an MCP server, authorize it specifically for Claude, and give it a permanent chunk of my context window. The authentication keeps breaking. I haven't set it up for Codex. I can't easily use or debug the tool myself.

Meanwhile, Slack was already set up and working nicely in my CLICLI (Command Line Interface). A text-based interface used to interact with software and operating systems by typing commands. CLIs are powerful tools for developers and system administrators..

This feels backwards.

MCP does two jobs

An agent needs two things to use a tool:

1. A specification: what can this tool do, what arguments does it accept, and what does it return?
2. Execution: a way to call the tool and receive the result.

MCP provides both. That makes sense when neither exists. But for many developer tools, execution already exists. It's the command line.

We keep building a second execution layer because the first one doesn't describe itself well enough.

The CLI is already the common interface

The CLICLI (Command Line Interface). A text-based interface used to interact with software and operating systems by typing commands. CLIs are powerful tools for developers and system administrators. is old, boring, and everywhere. That's an advantage.

It works for humans and agents. I can run the same command the agent runs, inspect the output, reproduce a failure, and put it in a script. It works on my laptop, over SSH, in a container, and on a remote machine. It doesn't care whether the caller is Claude, Codex, Gemini, or a shell script.

Authentication belongs to the tool, not the AI provider. If I've logged into Slack once, every authorized process can use that setup. I shouldn't need a separate Slack integration and OAuth dance for each agent.

CLIsCLI (Command Line Interface). A text-based interface used to interact with software and operating systems by typing commands. CLIs are powerful tools for developers and system administrators. also have an excellent debugging interface: the terminal. There is no hidden request envelope or opaque client state. The command, output, error, and exit code are right there.

And they load on demand. An agent doesn't need every command from every installed tool stuffed into its prompt before it starts working. It can discover the relevant tool, inspect its contract, run it, and discard the details.

CLIs aren't ready

Most CLIsCLI (Command Line Interface). A text-based interface used to interact with software and operating systems by typing commands. CLIs are powerful tools for developers and system administrators. were designed for a human squinting at a terminal, not a machine trying to act safely.

Their output is decorative rather than structured. Errors arrive as prose. Commands prompt unexpectedly. Help text is inconsistent. Exit codes are vague. Pagination, side effects, and retry behavior are implicit. An agent can usually muddle through, but "usually" isn't a sound interface.

The fix isn't another wrapper around every CLICLI (Command Line Interface). A text-based interface used to interact with software and operating systems by typing commands. CLIs are powerful tools for developers and system administrators.. It's a better CLICLI (Command Line Interface). A text-based interface used to interact with software and operating systems by typing commands. CLIs are powerful tools for developers and system administrators. contract.

A tool should be able to declare its commands, arguments, output schemas, errors, side effects, and authentication requirements in a standard machine-readable format. It should support structured output, keep data separate from diagnostics, run without an interactive terminal, bound its output, and state whether a retry is safe.

In other words, keep the execution model and standardize the specification.

A protocol for agent-friendly CLIs

People are working on this. The CLI Spec proposes six principles for tools that work for humans, scripts, and agents:

• Structured output
• Schema introspection
• Separation of stdout and stderr
• Non-interactive operation by default
• Safe retries
• Bounded output

Its most important idea is a schema command. A tool can describe its own capabilities without authentication, configuration, or network access. An agent can discover the tool at runtime instead of carrying its full definition around in every conversation.

That's close to the missing layer.

I don't particularly care whether CLICLI (Command Line Interface). A text-based interface used to interact with software and operating systems by typing commands. CLIs are powerful tools for developers and system administrators. Spec becomes the standard. I care that something does. We need agreement on how tools describe themselves, not a new bespoke bridge between every service and every AI client.

Where MCP still fits

MCP isn't pointless. It works where there is no local shell, where tools live behind a remote service, or where a host needs tighter control over discovery, permissions, and transport. A standard protocol is better than every AI company inventing its own plugin system.

But MCP shouldn't be the default wrapper around capabilities that already have a good executable interface.

Give me one tool I can install once, authenticate once, use myself, and hand to any agent. Let the tool describe what it can do. Let the operating system execute it. Let agents use the same interface humans have spent decades refining.

The command line is already the foundation. It just needs to learn how to introduce itself.