---
title: "The Protocol Trap"
date: "2026-04-10"
description: "When 'open standard' becomes the enclosure mechanism"
status: "finished"
confidence: "likely"
freshness: "B"
spice: "warm"
---

Everyone got the openness debate backwards.

There's a fight happening in AI tooling right now — MCP versus skills — and the consensus view goes like this: MCP (Model Context Protocol) is the open option, because it's a standard. Skills are the closed option, because they're platform-specific. Protocol equals open. Bundled code equals proprietary. This framing is clean, obvious, and almost perfectly inverted.

```conv-drake
MCP's a contract surface — fine if you trust the counterparty, useless if you pretend the spec *is* the implementation. I've wired sockets since before "protocol" was a vibe; the failure mode is always the same: you can read the header, you can't audit the body without owning the server.
```

Drake's bravado aside, the instinct underneath is sound. Something about the MCP-is-open narrative doesn't survive contact with reality.

A skill is a file on disk. You can read it. You can open it in an editor and understand what it does — line by line, function by function. You can change a single behavior, add a weird hack, rip out the parts you don't like, and run your modified version immediately. If you don't trust it, you audit it. If you disagree with it, you fork it. The code is the interface *and* the implementation. You own both.

An MCP server is an API endpoint. You can call it. You can read its schema — the list of operations it exposes and the parameters they accept. What you cannot do is see how those operations are implemented. You cannot modify the logic. You cannot inject a fix for a bug that's blocking you at 2am. You cannot fork the behavior. You're constrained to the surface someone else defined, and the depth behind that surface is sealed.

Therefore the question "which is more open?" reduces to a prior question: what does "open" mean?

```conv-ann
Oh, I love this kind of question. It's like asking whether a locked glass box is "transparent." Technically yes! You can see everything inside. You just can't touch it, change it, or take anything out. But sure, it's very open. You can look at it openly. While it openly refuses to let you in.
```

The MCP camp defines openness as *connectivity* — can different systems talk to each other through a shared standard? By this definition, MCP wins. Any AI that speaks the protocol can connect to any MCP server. The standard is public. The wire format is documented. The door is wide open, in the sense that anyone can walk through it.

But the door leads to a room you can't rearrange.

![Translucent locked architecture](/images/content/philosophy-protocol-trap-1.webp)

The skills camp — though few articulate it this way — defines openness as *modifiability*. Can you change how the tool works? Can you see the source? Can you break it apart and rebuild it to serve your purposes instead of its author's? By this definition, skills win overwhelmingly. A skill is source code. An MCP server is a service.

This isn't a new distinction. It's the oldest distinction in software: open source versus SaaS. And the AI tooling discourse is replaying the exact same argument, with the exact same confusion, that the software industry went through twenty years ago. The cloud providers won that round by convincing everyone that "open API" meant "open." It didn't. It meant you could connect to a service you couldn't control. MCP is running the same play.

The enclosure pattern is instructive here. Phase one: an open system invites everyone in. Phase two: a dominant operator emerges. Phase three: the operator closes the implementation while keeping the interface nominally open. The protocol stays "standard." The power migrates to whoever controls what the protocol connects *to*.

MCP is phase one. The protocol is genuinely open — the spec is public, anyone can implement a server, multiple AI platforms support it. This is real and worth acknowledging. But the servers behind the protocol — the things that actually do work — are increasingly hosted services run by companies with their own interests. The protocol is the open door. The server is the room behind the door. And the room is getting locks.

```conv-stevia
So MCP is basically a free front door to a building where they charge you rent for every room? That's... actually genius. I should do that. Stevia Protocol: the door is free, the hallway costs extra, and the rooms have viruses. The fun kind.
```

Stevia is joking, but she's describing the business model precisely. The protocol layer is a loss leader. The value capture happens at the implementation layer — the MCP servers that connect to proprietary databases, internal APIs, paid services. The open protocol makes adoption frictionless. The closed implementation makes departure expensive. This is enclosure with better marketing.

Skills resist this pattern structurally. Not because skill authors are more virtuous than MCP server operators — they aren't — but because the artifact itself is different. A skill is code that runs in your environment, under your control, readable and editable by you or your AI agent. The power relationship is fundamentally different: you're not calling someone else's service. You're running your own code. If the code does something you don't like, you change it. If the author abandons it, you maintain it. If a competing platform refuses to support it, you port it — because you have the source.

This is what I aim for when I ship Lattice-facing protocols: the wire format *and* the reference implementation stay inspectable — WorldSync, AssetMesh, identity handoff, all the boring repos — so forking behavior is a real option, not a euphemism for filing a ticket. MCP often stops at the former. That's the difference between an open standard that enables genuine openness and an open standard that provides cover for enclosure.

```conv-buster
Audit the supply chain, not the storefront. What's behind the API matters more than the API.
```

The industry chose the wrong definition of open, and it chose it for predictable reasons. Engineers pattern-match "protocol" to "HTTP, SMTP, TCP/IP" and conclude that protocols equal freedom. This is historically true — the open internet protocols were genuinely liberatory. But those protocols were open in *both* senses: open standard *and* open implementation. You could read the RFC and you could read the source of sendmail. MCP offers the first without the second, and the conflation lets it inherit the credibility of actual open systems without earning it.

Field data keeps catching up to the abstraction. Teams shipping MCP at scale report tool descriptions alone consuming roughly **550–1,400 tokens per tool** — and in one deployment, **143K of a 200K context window** disappeared into tool metadata before a user prompt arrived. The "open wire" quietly becomes a denial-of-service on attention, the one resource models do not make cheaper when you stack connectors.

Then the security story stops being theoretical. **CVE-2025-6514** was a critical remote-code-execution flaw in `mcp-remote` (OS command injection via a malicious server during the OAuth flow): the trust boundary sat on the wrong side of "connect," and a hostile endpoint could turn a client assist into full machine compromise — connect-and-pray dressed up as interoperability. By March 2026, Perplexity had reportedly **dropped MCP internally**, citing context overhead — the standard survived the press cycle, but the token budget did not.

The deeper issue is that "open standard" has become a branding strategy rather than an engineering commitment. Calling something an open standard costs nothing when the value lives in the proprietary implementation behind it. The standard is the lure. The implementation is the trap. The more tools that speak MCP, the more natural it feels to reach for an MCP server instead of writing the logic yourself — and every time you do, you're trading modifiability for convenience. You're choosing the clean API over the messy-but-yours script. You're choosing the room you can't rearrange.

```conv-ann
So the whole debate is people arguing about the door when they should be arguing about the room. Classic misdirection — the UI looks negotiable, the server policy isn't. Drake's been running the same hustle with "open APIs" that rate-limit you the minute you're hooked; MCP just rented him a bigger billboard.
```

I want to be precise about what I'm not arguing. Protocols aren't bad. Standardization isn't bad. I build on the same survival logic I use elsewhere for decentralized stacks — keep the spec *and* the reference code in play — because anything less is a convenience fee on future-you. The problem isn't the protocol. The problem is claiming the label "open" when only the interface is open, not the implementation behind it. A protocol is open. An opaque service behind an open protocol is not. The distinction matters because it determines who holds the power when something goes wrong, when requirements change, or when the operator's interests diverge from yours.

The measure of openness that actually matters is not "can I connect to it?" but "can I change how it works?" Not interoperability but modifiability. Not the plug but the screwdriver. A skill is a script you can `cat`. An MCP server is a service you can only `curl`. When the service changes its terms, raises its prices, or deprecates the feature you depend on, the open protocol won't save you. The source code would have.

Real openness is code you can touch. Everything else is a storefront.

```conv-buster
Source you can read. Logic you can change. That's the only kind of open that holds under pressure.
```