The Over-Engineered Agentic Web
Why MCP is Failing Consumer AI
(and How to Fix It)
Spend five minutes in the AI developer ecosystem right now, and you’ll hear one acronym repeated like a mantra: MCP.
The Model Context Protocol, open-sourced by Anthropic, is being hailed as the universal plumbing for the future of AI agents. It promises a world where an LLM doesn't just chat with you, but actively works for you. It’s slick, it's fast, and tech Twitter is absolutely obsessed with it.
There’s just one problem: MCP has a massive blind spot.
The current approach is entirely hyper-focused on being "cool" for developers. It’s built by engineers, for engineers, to solve engineering problems. It is brilliant if you want an AI assistant to clone a Git repository, refactor a Python script, or query a secure Postgres database on your local machine.
But guess what? The real future—and the real money—isn’t in helping developers write code. It’s in helping regular consumers live their lives. It's in an AI agent that can effortlessly shop for flights, find the perfect local weekend getaway, or seamlessly order a great birthday gift for a partner.
And if we try to force that consumer future into the current local MCP architecture, we hit a brick wall of security risks, fragmented distribution, and bad user design.
The Fatal Flaw of the Local Agent Model
To understand why the current trend is broken for regular consumers, look at how an MCP server actually runs.
In the developer ecosystem, an MCP server is a package (usually Node.js or Python) that you download and install directly onto your local machine. It acts as a local proxy. The cloud-based LLM sends raw text instructions down to your machine ("Run the tool: delete_file"), and your local MCP server executes the code.
For developers, this is acceptable. They understand terminal runtimes, environment variables, and local scripts. They run npm install all day long.
But imagine translating this to a regular consumer scenario:
You tell your AI assistant: "I’m hungry and I want a pizza."
The assistant searches the web, finds a highly rated independent local shop down the street—
sloppyjoepizza.com—and notices they have published their own custom AI integration.What happens next? Does the agent autonomously run
npm install sloppy-joe-pizza-mcponto your phone or laptop? Does it pop up a terminal prompt asking your mom to audit a third-party Python runtime package before she can eat?
If an AI assistant can autonomously download and execute raw third-party code on a consumer’s device just to order lunch, it isn't an assistant—it’s a self-installing Trojan horse.
Ordinary users do not understand the security implications of local code execution, nor should they have to. If the ecosystem forces users to install custom code for every single business they interact with, consumer agents will completely stall out.
The "Toll-Booth" Threat to the Open Web
Because local code installation is a security non-starter for the general public, tech giants are already pivoting toward a different solution: The Consolidated Marketplace.
Instead of letting your agent talk directly to Sloppy Joe’s Pizza, the AI platforms will route you through centralized, heavily audited enterprise gateways. If Sloppy Joe wants to receive an "agentic order," he won’t be able to just host it on his website. He will have to list his business on DoorDash, Uber, or Instacart.
The corporate toll-collectors will manage the security, host the API, and happily extract a 20% to 30% tax on every single AI-driven transaction. For independent local businesses, boutique shops, and creators, this is an economic death sentence. The open web will be choked out by massive aggregate platforms acting as the exclusive gatekeepers to AI traffic.
But it doesn't have to be this way. We don't need a corporate closed garden, and we don't need consumers installing untrusted code.
We just need to pair the best parts of the Model Context Protocol with the fundamental architecture that built the internet: The Open Web Standard.
The Blueprint for an Open Agentic Web
We can build a completely open, secure, and decentralized agent economy using three simple, practical layers:
┌────────────────────────────────────────────────────────┐
│ 1. THE ENGINE │
│ A pre-installed, heavily sandboxed "Meta-MCP" │
│ client that only translates web text to REST calls. │
└──────────────────────────┬─────────────────────────────┘
▼
┌────────────────────────────────────────────────────────┐
│ 2. THE DISCOVERY │
│ AI parses standard search results to find a link │
│ in the HTML header: <link rel="agent" href="..." /> │
└──────────────────────────┬─────────────────────────────┘
▼
┌────────────────────────────────────────────────────────┐
│ 3. THE MANIFEST │
│ A static metadata file (e.g., `agent-manifest.txt` │
│ or Swagger) mapping text to safe cloud HTTPS endpoints.│
└────────────────────────────────────────────────────────┘
1. The Pre-Installed "Meta-MCP" Engine
Instead of installing a unique software package for every business, consumer devices should ship with a single, native, heavily audited Meta-MCP client installed by default.
This engine is completely static. It has zero access to your local filesystem, zero ability to run shell scripts, and zero ability to mine crypto. Its only job is to ingest an API schema (like a Swagger/OpenAPI file) and map an LLM's text instructions into a standard HTTPS fetch request over the internet.
The security blast radius is instantly neutralized. The code running on the user's machine is completely trusted because it never changes.
2. Standardized Discovery: The New favicon.ico
We don't need a centralized Agent App Store because web search is already a solved problem.
When a business wants to make itself agent-compatible, it shouldn't publish an installer. It should just publish a static metadata text file at the root of its domain, following emerging open standards like agent-manifest.txt or llms.txt.
Sloppy Joe just adds a simple tag to his website's HTML header:
When you ask for pizza, your AI agent uses standard web search to find local shops, navigates to Sloppy Joe's site, detects that link, and grabs the text manifest instantly.
3. Clear, Human-Readable Consent
Because the manifest file just links back to standard web endpoints via Swagger, the built-in Meta-MCP engine can translate the technical plumbing into a beautifully simple, consumer-friendly authorization prompt for the user.
Mom doesn't get a scary warning about executing Node packages. She gets a clean, clear dialogue box:
"Sloppy Joe's Pizza wants to connect to your assistant to let you order food. They will be allowed to show you their menu and send your address for delivery. Allow?"
Mom clicks "Allow." The pre-installed, safe engine handles the HTTPS call to Sloppy Joe's server, the order is placed, and dinner is on the way.
Conclusion: Keeping the AI Web Open
This decentralized approach is exactly how the open web defeated closed, proprietary networks like AOL and CompuServe in the 1990s.
If the future of AI agents relies on downloading custom code to user machines, it will collapse under the weight of security exploits. If it relies on centralized cloud platforms, it will strip local businesses of their margins and centralize the internet into the hands of a few tech monopolies.
MCP is a phenomenal piece of engineering, but it’s time for it to graduate out of the developer sandbox. By turning the protocol into a standardized, configuration-driven proxy for the open web, we can give consumers the frictionless, magical assistant features they actually want—while keeping the internet open, safe, and fair for everyone.
No comments:
Post a Comment