When you ask AI to check a calendar, send an email, or operate Git, the AI needs a way to call tools. Imagine asking an assistant to work in your office: they need to know how to use the phone, printer, and access card. Developers are now debating which path AI should use to discover and operate those tools.

CLI tools have existed for decades. Git, Docker, and many development tools already have command-line versions. An AI agent can run those commands directly in the terminal without extra integration work.

MCP, or Model Context Protocol, is a protocol pushed by Anthropic for connecting AI to external services such as Google Drive, Slack, calendars, and email. It adds a layer, but that layer can carry permission management and security controls.

In January, developer Peter Steinberger, the creator of OpenClaw and later an OpenAI hire, made a blunt argument online:

His point: if an AI needs a tool, let it run the existing terminal command. It is faster, cheaper in tokens, and the tools already exist. Why build a new protocol for every tool?

The counterargument is safety. Developers can look at a dangerous command and stop. Most users cannot. If an AI is acting on your Gmail or calendar, you need permission boundaries and confirmations. MCP is heavier, but that heaviness is partly the guardrail.

You may never run commands in a terminal, but you have probably connected Claude or ChatGPT to Google Drive, calendar, or email. A protocol layer like MCP is what makes that feel manageable.

Steinberger was not just making a joke. In OpenClaw, he wrote around ten custom CLI tools and let the agent call them through bash, bypassing MCP entirely. OpenAI clearly found the pattern interesting enough to hire him later.

The core argument is token cost. Anthropic's own engineering writing has noted that tool definitions and tool results can consume tens of thousands of tokens before the agent even starts working on your request. GitHub reduced tool-list overhead by about 50% after consolidating tools. Those tokens are not spent thinking about your task; they are spent reading tool manuals.

CLI does not require preloading all those manuals. If the agent needs git, it can run git log --oneline -10 or check --help when needed. Steinberger calls this progressive disclosure: load information only when it is needed.

CLI assumes the user can judge whether a command is safe. A developer will stop at rm -rf /, but most users are not developers. If an agent operates Gmail, Calendar, Slack, or Jira on behalf of many users, arbitrary bash is not acceptable.

MCP's value is standardized tool descriptions, permission labels, OAuth flows, and a multi-tenant governance model. CLI can imitate this only by rebuilding a permission system from scratch.

Matthew Hall's response is useful here: current MCP implementations can be rough, but that is a criticism of early implementations, not necessarily of the protocol's ceiling.

Steinberger later built mcporter, which compiles any MCP server into a standalone CLI:

The compiled tool lives locally and is called only when needed. This is not "CLI wins" or "MCP wins." It treats MCP as a standard format for describing tools, and CLI as the execution path.

The practical judgment: for most developer workflows - building features, running tests, managing Git, automating local work - CLI is faster, cheaper, and more stable. For products where agents operate third-party accounts on behalf of users, MCP's governance model is worth the overhead.