"It's API, MCP, and CLI from Here On" — What It Takes for Software to Survive the AI Agent Era

Hello, this is Hamamoto from TIMEWELL.

Six months ago, SaaS company stocks collapsed in a cascade. Market watchers called it the "SaaSpocalypse," and according to reporting by Fortune, roughly $400 billion in market capitalization evaporated within a matter of weeks [1]. At that moment, I wrote an article titled "It's API, MCP, and CLI from Here On." The conclusion itself I have no intention of changing by a single character even now. But the parts I described back then as "still unresolved" have been cleared away wholesale over these past months. The pace of change around MCP (Model Context Protocol, the common standard that connects AI to external tools) in particular has been fast. The specification was substantially revised in November 2025, and a little earlier, in September, an official registry had already gone live [2][3][5].

Six months is enough for parts of an article to go stale as a matter of fact. Here I'll build on the earlier assessment while rewriting it from top to bottom using primary sources as of July 2026. If you want a quick read on where your own company's AI adoption currently stands, starting from the AI Literacy Check should make what follows feel like your own concern.

The SaaSpocalypse Shock

In February 2026, SaaS company stock prices plunged across the board. The trigger, it's said, was the moment the real-world capabilities of the then-latest-generation AI agents — Anthropic's Claude, OpenAI's Codex — appeared to exceed what the market had imagined. Fortune magazine named this phenomenon the "SaaSpocalypse" [1].

First, let me make the gap between then and now explicit. At the time that drop happened, in February 2026, Anthropic's top model was Claude Opus 4.6. But now, in July 2026, the line has advanced through Claude Opus 4.7 to the current flagship, Claude Opus 4.8 (model ID claude-opus-4-8, with a one-million-token context window). Alongside it stand Claude Fable 5 as the top generally available model and Claude Sonnet 5 as the balanced option for speed and intelligence [8]. Agents' underlying capability has clearly moved up a notch from where it was when it triggered the SaaSpocalypse. The pressure on software that assumes humans touch the UI has, if anything, intensified rather than eased since then — that's my honest read.

There was a remark that seemed almost to foresee this crash — words Microsoft's Satya Nadella is said to have spoken in public.

Today's business applications are ultimately just CRUD databases with a bit of business logic

The first time I heard it, I thought "surely that's an exaggeration." But watching agents call APIs on their own and turn business logic day after day, the core of the statement comes into focus. Agents don't ask for beautiful screens. They don't move a mouse. What they read are the API responses exchanged in JSON. GUIs polished for humans are having their very reason for existence questioned at a fundamental level.

Behind the provocative phrasing "SaaS is Dead" lies this structural change. So how does software change in the age of AI agents? And why did I arrive at the conclusion "it's API, MCP, and CLI"? Let me go through it in order, weaving in the latest developments from the past six months.

The End of UI-First

Traditional SaaS was designed on the premise that humans operate the UI. The center of value lay in UX — how easily and how unerringly you could finish your work. The flow was simple too: a person operates the UI, the SaaS processes data, and the result comes back to the screen.

The reality of 2026 is different. The "user" of SaaS has become the AI agent, and humans simply issue instructions in natural language. Agents don't look at the screen, and they don't know where the buttons are. What they understand is the structure of the API. So the center of gravity of the value demanded from SaaS has shifted from UI usability to the expressiveness and reliability of the API.

This shift becomes clear when you line it up as the evolution of enterprise systems. The 1990s were the era of SoR — Systems of Record. ERP and CRM accurately managed customer data and transaction records. In the 2010s, as smartphones spread, SoE — Systems of Engagement — was added, and after that big data and AI brought SoI — Systems of Insight. And now, in the age of agents, what's called for is SoK — Systems of Knowledge creation. Not merely recording data, but generating knowledge from it and reassembling the business processes themselves. When Nadella said "just a CRUD database," I think it was a criticism of SaaS still marking time at the SoR stage.

In Six Months, MCP Went from "Unfinished" to "Standard"

This is where my article from six months ago aged the most. Back then I introduced MCP as "a standard Anthropic proposed in 2024," and then lined up three problems — configuration fragmentation, gaps in API coverage, and token waste — as "still unresolved." Rereading it now, that diagnosis was frozen at the temperature of early 2025.

First, let me lay the foundations. MCP is a protocol that sits on top of JSON-RPC 2.0, made up of three parties: host, client, and server. The server side offers Resources, Prompts, and Tools, while the client side has capabilities called Sampling, Roots, and Elicitation. The official site positions itself as "a USB-C port for AI applications," and it can now be handled by a wide range of clients including Claude, ChatGPT, Visual Studio Code, and Cursor [2][4]. Up to here, the broad outline is the same as six months ago. The question is how the parts I called "holes" got filled.

The first, "configuration fragmentation" — the problem of not being able to tell which servers to trust. An official answer arrived here. On September 8, 2025, the MCP Registry (registry.modelcontextprotocol.io) was released in preview [5]. It's a public catalog-cum-API of servers, in which each server self-declares in a format called server.json. The design permits both a public sub-registry that behaves like a "marketplace" for clients and a private sub-registry that meets strict internal requirements. At least 9 companies and 16 individuals are reported to have been involved in the initial development [5]. On the very question of standardizing discovery and distribution that I had written off as "unresolved," the project has stepped up head-on.

The second, "gaps in API coverage" — the complaint that autonomous workflows stall midway. The specification dated November 25, 2025 (the previous version was dated June 18, 2025) prepared an answer. As an experimental feature, asynchronous tasks were added, letting you track long-running, durable requests by polling and retrieve the results later (SEP-1686) [3]. Instead of waiting in front of the screen for a process to finish, you fire it off and receive it later. There's a sense that the specification has finally come around to the way agents work.

The third — and the point I reflected on most — was my flat assertion that "MCP is nothing more than an incomplete API wrapper." That is now close to factually wrong. In the 2025-11-25 version, tools and toolChoice were added so you can call tools within Sampling (SEP-1577), and a URL mode was provided for Elicitation, which asks the user for additional information (SEP-1036). Combined with Roots, MCP can carry out bidirectional exchanges in which the server queries back to the client. The image of a one-way, thin wrapper no longer fits [3].

What shouldn't be overlooked is the progress on security and authorization. The old article touched only on token waste, but the real pressure point in the age of agents isn't there. The 2025-11-25 version incorporated support for OpenID Connect Discovery (PR #797), step-up scope consent using WWW-Authenticate (SEP-835), and OAuth Client ID Metadata Documents (SEP-991), and it also updated the Security Best Practices guidance [3]. Even so, risks remain: prompt injection, tool poisoning by malicious servers, and the "confused deputy" problem, where an agent borrowing someone's permissions ends up performing operations it never should have. The more the specification matures, the more it demands the design skill to build with least privilege on the assumption that these risks exist. I see this as the main battleground of the second half of 2026.

One more thing: WebMCP, which the old article introduced as if it were a mature technology "co-developed by Google and Microsoft and shipped in Chrome," was in fact something different. Correctly, it is a draft proposal first published by the W3C's Web Machine Learning Community Group on August 13, 2025. The tool-registration API is document.modelContext.registerTool(), and engineers from Microsoft and Google are named among the main contributors [6][7]. However, even as of 2026 it isn't built into major browsers as standard — it's strictly a proposal at the exploratory stage. It has promise, but writing it in a way that led readers to think it was "already usable" was inaccurate. I'll correct that frankly.

As for token waste, it remains a genuine issue even now. The structure in which a huge JSON schema describing tool specifications is sent to the model on every call, squeezing context and cost, hasn't changed. That said, seeing how far things have progressed — adopting JSON Schema 2020-12 as the default dialect (SEP-1613), guidance on tool names, turning icons into metadata (SEP-973), and even the formalization of governance such as Working Groups and a tiered system for SDKs (SEP-1302, SEP-1730) — I feel MCP is shifting its footing from an "interesting experiment" to a "standard that can withstand operations" [3].

The CLI Comeback

While MCP evolves noisily, the CLI — the command-line interface, with a history of more than 30 years — is quietly but surely gaining presence.

The symbol of this is the rise of terminal-native AI agents. Reporting in early 2026 noted that a non-negligible share of public commits on GitHub came from such agents, with predictions that the ratio would grow substantially within the year. Since that is a projection from the time, I'll avoid asserting the exact figure, but as a felt sense six months on, a development style with the CLI as its native tongue has fully entered the mainstream. Behind this lies the across-the-board lift from models like the Claude Opus 4.8 and Fable 5 I mentioned earlier. The more an agent's ability to plan and execute rises, the more the value of a plain tool like the CLI stands out by contrast [8].

Why does the CLI mesh so well with agents? There are three reasons.

The first is universality. Configure it once on your PC, and you can invoke it the same way from an IDE or a terminal. Like the AWS CLI or the gcloud SDK, a single binary covers nearly all of a platform's functionality. The fragmentation that tends to arise with MCP servers — "this one tool needs its own separate config file" — simply doesn't happen.

The second is maturity. The problems that get thorny in computer-to-computer communication — authentication, error handling — have matured over decades. Multi-factor authentication and single sign-on have long been a given in the world of the CLI.

The third is affinity with agents. Agents don't need to decipher the context of a screen. From the structured text returned by --help alone, they can accurately grasp how to use a tool and move straight into the task. In the developer community there's a persistent view that "much of what you can do with MCP, you can do better with the CLI," and I find myself fairly sympathetic to it. It's a topic where opinions split, but at least in situations where an agent operates autonomously, I can't find an interface with less friction than the CLI right now.

Let me add one more modest but important trend. The practice of placing machine-readable documentation aimed at agents has been spreading. For example, you put an llms.txt at the root of a site, handing the model a map of what it should read first. The idea is to design an entrance for agents, separate from the UI meant for humans. At its root, it comes from the same place as the CLI-first philosophy.

The Three Interfaces Don't Compete

So far I've followed API, MCP, and CLI. The core of the claim "it's API, MCP, and CLI from here on" is this single point: rather than being in a relationship where they fight over the same ground, the three divide roles among themselves at separate layers, in a complementary relationship.

API is the layer that underpins everything. It's the contract by which a service offers its capabilities to the outside, the formal front door that programs access. If this isn't robust and expressive, whatever you stack on top of it will crumble.

MCP is the translator standing between AI models and a wide variety of tool groups. It converts the countless APIs with disparate specifications into a unified format the model can understand, standardizing connection. Choosing which server to trust used to be the worry, but now that a map called the registry has been prepared, this translator has become much easier to use.

CLI is the most natural conversation partner for agents. The rhythm of an agent's thinking — plan, execute, verify the result — is astonishingly compatible with the operation of stacking commands one at a time.

WebMCP, rather than standing alongside these three, is an option specialized for scenes where a user collaborates with an agent through the browser. It has appeal, but at this point it's a draft, and it isn't in browsers either. The accurate distance to keep is one where you don't over-invest your expectations.

What's being asked isn't a ranking of "which is strongest." It's how far you can shape your own service into a form that's easy for agents to handle. Whether you can prepare a state in which agents can easily access it, operate it easily, and be granted permissions safely will decide the life and death of software from here on. On the foundation of the API, layer the connectivity of MCP and the operability of the CLI. This trinity design has become an indispensable condition.

Agent-Friendly Design: Where to Start

Granting that the structural change itself makes sense, what do you do starting tomorrow? This is the part I most want readers to take away from the article.

The starting point is a review of your own API's quality. Idempotency that doesn't break no matter how many times the same operation is called, fine-grained endpoints, asynchronous support that lets you fire off time-consuming processing and leave it running, and audit logs that let you trace who did what. Asynchronous support in particular is a requirement that meshes directly with MCP's asynchronous tasks. These are turning from "nice to have" into "you won't get chosen without them."

Next comes getting the CLI in shape. If your service doesn't have a CLI, it's well worth taking up. Even if you already have one, on the premise that agents will use it, push ahead with fuller help messages, JSON support in output, and simplified authentication flows. Aiming not for a CLI that feels good for a human to read, but for a CLI a machine can read without getting lost, is the 2026 way of doing things.

And then, considering MCP support. If MCP is becoming the standard in the ecosystem your company belongs to, it's hard to avoid supporting it. Register yourself in the official registry with a server.json so you get found; lock down authorization with OAuth and OpenID Connect and narrow scopes to the minimum; make use of bidirectional features like Elicitation to safely interpose confirmations. Beyond building your own server, it's worth holding the perspective of leveraging existing implementations and measuring cost-effectiveness.

For those on the side of choosing SaaS, I'd propose the following checklist. The era of judging on a UI demo alone is already over.

Check item	What to verify
API quality	Is a REST or GraphQL API published? Is idempotency guaranteed?
Asynchronous support	Is it designed so you can fire off long-running processing and retrieve the result later?
CLI availability	Is an official CLI provided, with rich JSON output and help?
MCP support	Is there an MCP server registered in the official registry? Are updates continuing?
Authentication and authorization	Can you create accounts for agents? Can you narrow scopes to the minimum?
Security	Is there a stated policy against tool poisoning and permission misuse?
Bidirectional features	Is there a mechanism, like Elicitation, that returns a confirmation when needed?
Observability	Can usage and audit logs be retrieved via API?

Among the three interfaces, I believe the one that will keep gaining weight is the CLI. The CLI is closest to the native tongue of agents. There's no doubt that the API is the foundation and that MCP connects the ecosystem. Even so, in getting an agent to advance a task autonomously, the entrance with the least friction and the most straightforward to handle is, at this point, unquestionably the CLI. What's different from six months ago is that beside it, MCP has grown from an "unfinished experiment" into a "standard that can withstand operations." That's exactly why the phrase "trinity" now carries far more reality than before.

Responding to this kind of structural change isn't a matter a technical team can settle on its own. Reviewing API design, getting CLI tooling in shape, judging the priority of MCP support — every one of these is a management decision that comes with budget and staffing allocation. At TIMEWELL's WARP program, former DX and data-strategy specialists from major enterprises provide hands-on support, from crafting DX strategy for the AI agent era through to the actual review of API design and system architecture. "To make our own service agent-friendly, what should we tackle first?" If you'd like to untangle that question together, reach out through WARP's individual consultation. When I rewrite this article again six months from now, I hope your company will be on the "already handled" side.

---

References

[1] Fortune magazine reporting (February 2026). The naming of the "SaaSpocalypse" and the report that roughly $400 billion in market capitalization was lost within a matter of weeks.

[2] Model Context Protocol. Specification (latest). https://modelcontextprotocol.io/specification/latest

[3] Model Context Protocol. Key Changes (2025-11-25 changelog; previous version 2025-06-18). https://modelcontextprotocol.io/specification/2025-11-25/changelog

[4] Model Context Protocol. Official home (introduction). https://modelcontextprotocol.io

[5] Model Context Protocol Blog. Introducing the MCP Registry (preview, 2025-09-08). https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/

[6] W3C Web Machine Learning Community Group. WebMCP repository. https://github.com/webmachinelearning/webmcp

[7] W3C Web Machine Learning Community Group. WebMCP specification draft (first published 2025-08-13). https://webmachinelearning.github.io/webmcp/

[8] Anthropic. Claude models overview (current model lineup: Claude Opus 4.8 / Fable 5 / Sonnet 5). https://platform.claude.com/docs/en/about-claude/models/overview