The Protocol We Should Have Built for Humans
written by Stefan Christoph
Namaste from 6,165 Meters
I just summited Imja Tse (Island Peak, 6,165 meters) in Nepal. No Slack, no email, no MCP servers crashing in the background. Just ice, thin air, and the kind of clarity that only comes when every step costs you something.
At that altitude, you don’t tolerate inefficiency. Every piece of gear earns its place or stays behind. Every movement is deliberate. You can’t afford to fumble with equipment that doesn’t work the first time.
When I came back and started catching up, one talk stood out: David Soria Parra, co-creator of the Model Context Protocol at Anthropic, presenting “The Future of MCP” at AI Engineer Europe [1]. The talk covers the full arc: from open-sourcing MCP in November 2024 to 110 million SDK downloads per month, MCP Apps rendering interactive UIs inside chat, and the protocol’s donation to the Linux Foundation.
It’s an impressive 18 months of progress. But watching it, still in that altitude mindset where wasted effort feels unacceptable, I kept coming back to one thought:
We should have built this for human developers thirty years ago.
The Integration Tax Nobody Complained About
Here’s the thing about MCP that nobody talks about: almost everything it solves for AI agents, human developers have been suffering through for decades.
Typed tool contracts? We called those “API specifications” and most services shipped without them, or with per-language SDKs that each team maintained separately. A standard authorization flow? We scattered tokens across ~/.aws/credentials, ~/.kube/config, .env files, and browser cookies. Tool discovery? We called it “reading the docs,” if docs existed. Structured error responses? We got whatever the backend developer felt like returning that day.
It’s not that we had nothing. We had SDKs, client libraries, OpenAPI specs (eventually). But every solution was per-language, per-service, per-provider. The fragmentation was the problem, and we accepted it because integration was an upfront-heavy, amortizable cost. A team spends two weeks wiring up a new service, writes a wrapper, and moves on, maintenance, version migrations, and credential rotation trickle on afterwards, but quietly. The pain is real but amortized. Nobody files a bug report against “the entire concept of API integration.” Developers just dealt with it.
I wrote about this pattern in my Smithy post [2]: when AWS open-sourced 200+ API models in machine-readable Smithy format, it felt like a revelation. But it shouldn’t have been. Machine-readable API contracts should have been table stakes from the beginning. It took AI agents, I’d argue, to create the economic pressure that made it happen.
Why Agents Changed the Economics
Parra’s timeline tells the story:
MCP’s evolution from local experiment to industry standard in 18 months.
Eighteen months from “local experiment” to “industry standard with 110M+ monthly SDK downloads,” though that number likely includes CI pipelines and experimentation alongside production use. Still, the trajectory is unmistakable. Why so fast?
Because agents flipped the economics of bad APIs.
When a human developer integrates with a service, the cost is front-loaded. Build the wrapper, write the tests, move on, recurring maintenance stays, but the two weeks of upfront pain are amortized over months or years of usage.
When an AI agent integrates with a service, much of that cost recurs per session. The host can cache discovery and hold the credentials, but the model itself needs the tool schemas in its context and has to interpret responses fresh in every conversation. For well-known tools it’s used before, caching and prior knowledge help. But for every new tool (and agents encounter new tools constantly) the model rebuilds its understanding from scratch. The context window is the new integration budget, measured in tokens, not developer-weeks, tokens bound what fits in context, and the same discovery work also shows up as latency and, on a metered API, on the bill.
A poorly documented CLI that costs a human team two weeks to integrate costs an agent 8 turns of “Help Loop”: calling --help, parsing output, trying a command, failing, trying again. On every single invocation [3]. Multiply that by thousands of agent sessions per day, and suddenly the lack of typed contracts isn’t a minor inconvenience. It’s an architectural bottleneck.
That, I’d argue, is why MCP grew so fast. Not because it’s a better protocol than what we could have built in 2005. But because agents made the cost of not having it visible for the first time.
The Three-Layer Stack
One of Parra’s key frameworks is the “connectivity stack” that production agents use in 2026:
| Layer | What It Provides | Example |
|---|---|---|
| Skills | Domain knowledge as reusable instructions | Meeting prep workflows, expense report procedures |
| MCP | Typed integration protocol with semantics, governance, cross-boundary reach | Slack, Salesforce, calendar, databases |
| CLI / Computer Use | General access to existing systems | git, aws, grep, file operations |
His punchline: “These compose. Agents in 2026 use all of them.”
This matches exactly what I’ve been running in practice. In my “CLI vs MCP: The Wrong Debate” article [3], I argued that the CLI-vs-MCP framing is a false dichotomy. CLIs handle the universal: tools the model already knows from training data. MCP tends to be used for the specific: bespoke integrations the model has never seen. That is a habit of use rather than a property of the interfaces, either one can expose the familiar or the bespoke. Neither replaces the other.
What Parra adds is the Skills layer on top: codified workflows that orchestrate both CLI and MCP tools. This is what I’ve been calling “the coding agent that doesn’t code” [4]: an agent that runs your entire workday through structured Skills, not ad-hoc prompting.
The three layers aren’t competing. They’re a stack.
What’s New: The Protocol Becomes a Platform
The talk covers several developments that happened while I was trekking. Here’s what matters:
Programmatic Tool Calling
Instead of one tool call per turn, models now write code that orchestrates multiple MCP tools, including loops, branches, and error handling. This changes everything. The agent isn’t just calling tools sequentially; it’s programming against them.
Think about what this means: the model treats MCP tools the way a developer treats library functions. It composes them, handles edge cases, and retries on failure. The protocol stays the wire contract; what the model programs against now behaves like an SDK.
Progressive Discovery
Parra showed a comparison: without tool search, an agent loads ~56,000 tokens of tool definitions upfront. With progressive discovery, it loads ~9,000 tokens, discovering tools on demand as the task requires them.
This is the “npm install” moment for agents. You don’t load every package at startup. You discover what you need, when you need it. Server Cards, a metadata format served at .well-known endpoints, currently being standardized by its own MCP working group [7], are what make this possible without requiring a live connection to every server.
Tasks: Async, Long-Running Operations
The Tasks primitive enables “call-now, fetch-later” patterns. An agent kicks off a deep research task, continues with other work, and checks back for results. This is a building block for agent-to-agent handoffs, the async call pattern; identity, authorization, and state passing still have to come from elsewhere, and for workflows that run for minutes or hours, not milliseconds.
I wrote about the collaboration patterns emerging in MCP, and Tasks is the natural extension. The protocol is evolving from request-response to genuine collaboration between agents and tools.
MCP Apps: The UI Layer
This is perhaps the most surprising development. MCP Apps, launched January 26, 2026, let tools return interactive UI components that render directly in the conversation. Dashboards, forms, visualizations, multi-step workflows. All in sandboxed iframes, communicating via JSON-RPC over postMessage.
Supported by Claude, ChatGPT, VS Code, and Goose. Built as the first official MCP extension, with Anthropic, OpenAI, and Microsoft collaborating on the standard [5].
The implication: MCP is no longer just a tool-calling protocol. It’s becoming a platform, with a UI layer, an async execution model, a discovery mechanism, and a governance framework.
The Governance Question
In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF) under the Linux Foundation [6]. Founding members include Anthropic, OpenAI, Block, Microsoft, Google, and Amazon. Block contributed Goose (their open-source coding agent) and AGENTS.md.
This follows the Kubernetes playbook: take a protocol that’s gaining traction, put it under vendor-neutral governance, and let the ecosystem build around it. Whether this accelerates or slows MCP’s evolution remains to be seen. The Linux Foundation’s track record includes Kubernetes (fast-moving), while OpenStack, governed by the Open Infrastructure Foundation rather than the Linux Foundation, is the cautionary tale people usually reach for. The AAIF structure uses Working Groups with delegated authority, specifically designed to avoid bottlenecks. These groups own specific areas (Transports, Agents, Enterprise) with a contributor ladder defining progression paths.
The official 2026 roadmap names four priority areas, with its own explicit caveat that these are directions, not commitments [7]:
- Transport scalability: stateless sessions, load-balancer-friendly patterns
- Agent communication: hardening the Tasks primitive with retry semantics and expiry policies
- Governance maturation: contributor ladder, delegated approval for domain-specific proposals
- Enterprise readiness: audit trails, SSO, gateway patterns (as extensions, not core changes)
I wrote about the enterprise gap in my MCP Gateway post [8]: how the proliferation of MCP servers creates authentication chaos. The AAIF roadmap directly addresses this. The Enterprise Working Group is collecting problem statements and delivering solutions as lightweight extensions, keeping the core simple for smaller deployments while giving large organizations the controls they need.
The REST-in-1999 Parallel
In my CLI vs MCP article [3], I drew a parallel: MCP today is REST in 1999. Before OpenAPI, most web APIs were snowflakes, machine-readable interface definitions existed (WSDL, CORBA IDL), but nothing had taken hold for REST. Documentation was a PDF someone emailed you. Integration was a multi-week project of trial and error.
Parra’s talk reinforces this. The zombie processes, the inconsistent implementations, the authentication sprawl: these are symptoms of an infant protocol, not a broken one. The capabilities MCP provides (typed contracts, elicitation, sampling, tasks, apps) are things a CLI gives you no standard way to express, you can build equivalents in a custom protocol, but every client then has to learn yours.
But here’s what I keep coming back to: REST in 1999 was also something we should have had in 1989. The web existed. HTTP existed. The idea of machine-readable API contracts wasn’t technically impossible; it just wasn’t economically necessary. Developers tolerated the mess because the cost was bearable.
The same is true for MCP. We could have built a universal tool protocol for human developers at any point in the last twenty years. We didn’t, and that’s not a failure of imagination or laziness. It’s a market signal story. The cost of fragmented integration was real but individually bearable. Each developer absorbed it quietly. Agents made the cost collectively visible for the first time, because they pay it on every invocation, at scale, with no ability to “just deal with it.”
What This Means for Builders
If you’re building agent-powered systems today:
Don’t wait for the protocol to mature before adopting it. MCP is in its “messy middle,” but so was REST when Amazon built its first web services. The capabilities are real. The rough edges are temporary.
Invest in typed contracts for your internal tools. Every bespoke CLI that agents struggle with is a tax you’re paying on every invocation. Wrapping it in an MCP server with a proper schema is an upfront investment that compounds [3], you still maintain the server and evolve the schema, but that cost is shared across every agent session instead of paid inside each one.
Think in three layers. Skills for workflow orchestration. MCP for typed integrations. CLI for well-known tools. Don’t pick one; compose all three.
Watch the governance. The AAIF under the Linux Foundation is a strong adoption signal, not a guarantee, that MCP is here to stay. The Enterprise Working Group’s output will determine whether MCP becomes the enterprise standard or remains a developer tool.
Remember the human lesson. The protocol we built for agents is also the protocol we should have built for ourselves. Every improvement to MCP (better discovery, better auth, better error handling) makes life better for human developers too. The rising tide lifts all boats.
The mountains taught me something about protocols too. At 6,165 meters, you can’t waste energy on unnecessary steps. Every movement has to be efficient, every tool has to work the first time. You don’t get to “try --help again” when your oxygen is limited.
MCP isn’t perfect yet. But for agent-tool integration it’s the first serious attempt at efficiency by default that has actually taken hold: not as an afterthought, not as a wrapper, but as something the protocol describes up front. Schemas and a common transport make integration cheaper to build; they do not by themselves guarantee it is efficient. The fact that it took AI agents to force the issue says more about us than about the technology.
What’s your take: should we have built this for humans first? And what’s the next integration pain that agents will make visible?
Sources
[1] David Soria Parra, “The Future of MCP”, AI Engineer Europe, April 2026. Conference talk recap
[2] Stefan Christoph, “Caught up on AWS’s open-sourcing of API models in Smithy format”, LinkedIn, February 5, 2026
[3] Stefan Christoph, “CLI vs MCP: The Wrong Debate”, schristoph.online, March 17, 2026
[4] Stefan Christoph, “The Coding Agent That Doesn’t Code”, schristoph.online, March 14, 2026
[5] MCP Core Maintainers, “MCP Apps, Bringing UI Capabilities To MCP Clients”, Model Context Protocol Blog, January 26, 2026
[6] Linux Foundation, “Announces the Formation of the Agentic AI Foundation (AAIF)”, December 2025
[7] Model Context Protocol, “Roadmap” (official, last updated March 5, 2026; states “The ideas presented here are not commitments”), modelcontextprotocol.io/development/roadmap
[8] Stefan Christoph, “MCP Tool Chaos, got lost in authentication and governance?!”, LinkedIn, February 20, 2026
[9] Latent Space Podcast, “One Year of MCP, with David Soria Parra”, December 27, 2025
About the Author
Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.
This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.