Are MCP and CLIs Competing?

* Agentic AI Foundation ---------------------------------------- A deep dive into Nick Cooper’s talk at MCP Dev Summit North America 2026 MCP or CLI? That’s the question everyone’s asking. Nick Cooper, Member of Technical Staff at OpenAI and a contributor to the MCP ecosystem, shared that he’d been thinking about this debate for a year, but stopped short of picking a side: “As for whether or not one is better than the other, it’s not a decision between one or the other. You clearly want both.” PROTOCOLS ARE JUST LANGUAGES Nick started by naming something he said makes protocol discussions harder than they need to be. “Protocol” sounds technical and unapproachable, especially to anyone who has tried to explain it to a high school student. His reframe was simple. Protocols are languages. When two systems talk to each other, they’re doing the same thing two people do across a table, exchanging meaning through a shared set of rules. From that foundation, he traced the layered history of how computer communication actually works. Every layer adds more constraint, more structure, more specialization, and each new layer creates new places to inject things the previous one couldn’t handle. * Electrical signals * TCP * HTTP * REST * OpenAPI * MCP Each step forced people to constrain and specialize. Each step also created standard patterns for observability, authentication, and security that didn’t exist in the layer below. MCP sits high in that stack. But crucially, it still touches lower layers. MCP servers run over HTTP or Standard I/O. The raw primitives are always there underneath. THE TOKEN EFFICIENCY PROBLEM Nick stated a blunt observation: when a model runs on a task, output costs more than input: in money, in latency, in attention. That asymmetry shapes everything. Early MCP usage treated the protocol much like function calling. You expose tools, the model picks them, results come back. The problem is that as MCP server counts have exploded into the thousands, exposing a meaningful slice of them to a model in a single context window eats through that context fast. You spend more tokens explaining schema than solving the actual problem. Two patterns have emerged as responses to this. * Shell/filesystem-like invocation, where resources are files and tools are executables * Code-like invocation, where tools become functions, typically in TypeScript or Python Nick pointed out that both are really the same idea at different syntax levels. Bash is a programming language, even if most people don’t think of it that way. Code mode (writing programs rather than making individual tool calls) is more efficient for the model on two fronts. It can express a sequence of actions in a single output rather than iterating through them one by one. And the output of that program, already filtered and shaped by code logic, becomes better input for the next round. You stop using the model as a control flow primitive for things a for loop does for free. INTENT IS WHAT MCP ACTUALLY ADDS If you have nothing (no existing API, no prior infrastructure) you can build anything. A CLI, an MCP server, either one. Nick would advise building something intentional around the problem, not just exposing raw functionality and hoping the model figures out what to do with it. If you already have an existing API, he was clear. Don’t just point a model at it. Write a CLI around it, or write an MCP server around it. The act of building that layer is what forces you to think about what the user actually wants the model to do. MCP’s real contribution in his framing isn’t the protocol mechanics. It’s the intent it brings to API design. “MCP is an API for AI,” he said. When you start an MCP project, you’re not thinking about how another developer will call your endpoint. You’re thinking about how a model will use these tools. That question surfaces security and observability concerns that generic API thinking tends to skip. He shared that an email system has an obvious API surface — send, receive, list. But the moment you think through it carefully, you end up with drafts, labels, folders, categorization, contact management. Hundreds of tools, all technically correct, all potentially confusing for a model. Building an MCP server forces you to ask what the user actually wants, and to expose the right level of abstraction rather than the full API surface. CLIs have a long history. There are thousands of them already built. MCP servers bring AI intent to what you build. The most capable systems, Nick argued, combine both. MCP AS AN AGENT-TO-AGENT PROTOCOL MCP is typically described as a tool protocol or a context protocol. But Nick pointed out that at a higher level, it already behaves like an agent-to-agent protocol. Tools are abilities. Tasks are delegated work. Messages, inputs, and outputs are structured and explicit. The pieces are already there. Nobody is really treating it that way yet. His bet is that as more companies and products on the other end of an MCP connection become AI-capable, the abstraction level on both sides should rise. You don’t need to define every verb for another agent the way you do for a developer API. You can open the interface up and let the other side interpret intent, not just execute instructions. The last thing he raised was a call for input, not a finished answer. Discovery of identity: how to find and verify what’s on the other side of a connection across a federated landscape of providers, clients, and hosts, is the hard problem coming next. He asked people to engage on MCP Discord. The problem is too distributed to solve without the community. Nick Cooper is a Member of Technical Staff at OpenAI. To learn more about MCP and connect with engineers thinking through these problems, visit aaif.io, join the conversation in the AAIF Discord, or join us at an upcoming AAIF event.