MCP New

The protocol many of us cooled on just got a real upgrade — and the catch is as important as the hype

← AI Agents · Tech · CLI for agents · CLI not MCP (GTM) · OpenClaw MCP · Harness map · Codex engineering

Why this page exists (Shadstone context)

We already argued hard for CLI for agents and CLI over MCP for business pulse. Mike told IT to move toward CLI (or at least add CLI next to MCP). That review is in flight — some CLI work may already be landing.

Then the industry noise flipped: MCP shipped its largest revision since launch, and technical voices (including people who were never fans) are saying the new version is actually good. This page is the reconciling field note: what changed, what the catch is, and what IT / product teams should do without abandoning the CLI direction.

Sources

Theo (t3.gg) @theo — x.com/i/status/2087280199406903762 (11 Aug 2026): “I was never a big fan of MCP. That might change now. The new version is genuinely really good, but it comes with a big catch…” (~18 min video; high bookmark signal).
Official: MCP 2026-07-28 specification — stateless protocol core, multi round-trip requests, header-based routing, cacheable list results, auth hardening, extensions framework, updated Tier 1 SDKs.
Cloudflare: The next generation of MCP (6 Aug 2026) — rewritten, stateless core that runs cleanly on Workers; no sticky-session dance.
Our prior stack guidance: /cli, /cli2, /openclawmcp.

Reply culture under Theo’s post is useful too: one line that sticks — stateless was always the right call; the catch is it’s a rewrite, not an upgrade, and most MCP servers in the wild are weekend projects nobody is going back to (maintenance will kill them if the protocol didn’t).

One-sentence TL;DR

MCP 2026-07-28 makes the protocol core stateless and HTTP-native (no initialize handshake / session tax the way the old design forced), which is why skeptics are reopening the door — but adopting it is closer to a server rewrite than flipping a version flag, and it still does not replace task-shaped CLIs for agent jobs. For Shadstone: keep shipping CLI, upgrade or retire MCP servers on purpose, don’t treat “MCP is good now” as “delete the CLI plan.”

What was wrong with “old MCP” (why we pushed CLI)

From our own pages and the industry critiques Theo and others rode:

Pain	Effect on agents / ops
Stateful sessions / sticky infra	Harder to run on ordinary HTTP, Workers, multi-instance hosts; more moving parts
Tool-list dump into context	Many tools burned tokens; agents “saw” everything whether they needed it or not
Thin API wrappers as MCP	Same as bad CLIs — endpoints, not jobs; agent still invents the workflow
Weekend servers	Catalog of half-maintained MCP servers; security and drift risk
GTM / pulse use case	cli2: daily Ads/CRM pulse was cleaner as agent-written scripts + CLI than a fat MCP in every chat

Matt Van Horn’s line on /cli still holds: a CLI is Google Maps for agents — task-shaped commands, predictable stdout, exit codes. MCP and REST are hosts and plumbing; they are not automatically agent-native design.

What “MCP new” actually changes (2026-07-28)

Headline from the official blog and Cloudflare: MCP is transforming from a bidirectional stateful protocol into a request/response-oriented stateless protocol.

Stateless core

No protocol-level session tax the old way (initialize handshake / session id sticky routing). Any instance can answer; scales on ordinary HTTP infrastructure.

HTTP / Workers friendly

Cloudflare’s pitch: run MCP in a Worker without stateful infrastructure gymnastics — fewer moving parts, lower cost to operate.

Multi round-trip requests

Cleaner multi-step interactions (e.g. when the server needs input mid-flow) without the old “session is the whole conversation” model.

Discover / list / cache

Discover-style flows and cacheable list results help clients learn capabilities without permanent session memory on the server.

Auth hardening

Continues the enterprise path (OAuth / OIDC-oriented hardening) — relevant if MCP is a host bridge into company tools.

Extensions framework

Formal extensions (tasks, apps, etc. moving out of an overloaded core) — less “everything is one bloated core protocol.”

Updated Tier 1 SDKs shipped with the revision. Details and exact RPC names live in the official changelog — treat this page as ops guidance, not a protocol lawyer’s brief.

Theo’s point: genuinely good — with a catch

I was never a big fan of MCP. That might change now. The new version is genuinely really good, but it comes with a big catch…

From the video framing + reply thread, the practical catch for teams is:

Rewrite energy, not free upgrade. Spec + interaction model + SDKs were rewritten around the stateless core. Old servers don’t magically become “new MCP” because you bump a version string.
Long tail of servers dies of maintenance. Weekend MCP projects nobody owns won’t get ported. Catalog quality may get worse before better unless you own your servers.
Client-side / harness issues remain partially separate. Stateless transport doesn’t by itself fix “agent got 80 tools dumped into context.” That’s still harness + design (discovery, progressive tool load, REPL/sandbox patterns).
Kent’s counterpoint (reply): some of the old pain was mitigated with Durable Objects / good hosting; the new core is still welcome — and real client apps can upgrade in hours when owned end-to-end.

Does this reverse “CLI not MCP”?

No. It re-scopes MCP.

Layer	Prefer	Why
Jobs the agent runs daily (pulse, deploy, list files, rank report)	CLI (or agent-written scripts behind a CLI)	Task-shaped, token-cheap, works in any terminal agent (Codex, Claude Code, Grok Build)
Host bridge (Cursor/Claude host needs a standard tool bus into one service)	New MCP (owned server, 2026-07-28 path)	Stateless HTTP is finally a real production shape; good for shared hosts
Raw REST dump as tools	Neither — wrap into CLI or a small set of MCP tools	Endpoint catalogs still make agents thrash
Messaging / multi-surface	CLI + optional MCP facade (OpenClaw MCP)	OpenClaw as MCP server is still a bridge; jobs under it should stay task-shaped

Design rule (updated Aug 2026)

CLI first for agent work. MCP second for host interoperability — and only MCP servers you own, on the new stateless path, with a short tool list. Do not stop the IT CLI program because Twitter said MCP is cool again.

Guidance for IT (while CLI review is in progress)

Continue CLI work. Anything already planned (pulse scripts, RankingSolution-style commands, Bunny list, Link CLI) still wins for agents in terminals. That investment compounds with or without MCP.
Inventory MCP servers. For each: owner, last commit, auth model, tool count, whether it maps to a real job or a REST dump.
Triage:
- Keep + upgrade — high use, owned, will move to 2026-07-28 SDKs
- Wrap with CLI — keep API, add our-tool pulse agents actually call
- Retire — weekend / orphan servers; remove from agent configs
Pilot one new-style MCP on Worker/App Service/stateless HTTP for a single host (e.g. Claude Code or Cursor only) and measure latency, auth, and tool-list size — not “enable every MCP we ever bookmarked.”
Security: new auth posture is better on paper; still require secrets management, least privilege, and no production write tools without human gates (same lesson as gymhack).
Don’t dual-maintain forever. Prefer: one CLI as source of truth; thin MCP that shells out to that CLI if hosts demand MCP. One implementation of business logic.

How this maps to our stack

Surface	MCP new?	CLI?
/cli + /cli2	Host optional	Primary — GTM pulse, agent maps
OpenClaw MCP	Bridge clients → messaging; plan upgrade path to new SDKs	Still put real jobs behind clear commands where possible
RankingSolution / SEO brain	Optional MCP for IDE hosts	CLI + Smart Run remain the product spine (seoloop)
Grok Build / Codex / Claude Code	MCP when the host needs a standard bus	Native: shell + CLI is already home
exe.dev / agent VMs	Remote tools can be MCP or HTTP	SSH + CLI remains simplest for agents “on a computer”
HQ / company harness	May consolidate MCP access; secrets matter	Workers can invoke CLIs; shared Main still owns judgment

Practical decision matrix

Situation	Do this
Agent needs a daily multi-system pulse	CLI / script repo (cli2), not a fat MCP
Cursor/Claude users want one-click tools in the host UI	Owned MCP server on 2026-07-28, short tool list, or MCP → CLI shim
Orphan MCP with 40 tools nobody documents	Retire; replace top 3 jobs with CLI commands
New internal API	Ship CLI first; add MCP only if a host requires it
“Twitter said MCP is good now”	Read the catch: rewrite + ownership. Schedule pilot, don’t halt CLI

Related on this site

CLI for agents — Matt Van Horn / task-shaped interfaces
CLI not MCP for GTM pulse — company brains, thin MCP, pulse repos
OpenClaw MCP — MCP as bridge, still needs good tools underneath
Multi-agent harness map
Codex engineering · Harness tips
Stripe Link CLI · Bunny list script

Primary external: Theo on X · MCP 2026-07-28 · Cloudflare MCP v2

Field notes · August 2026 · MCP new is real · CLI still first · Catch = rewrite + ownership