Skip to main content

Hypercontext vs. MCP

MCP answers: how do an agent and a service talk? The Hypercontext Protocol answers: what of a person's life may cross, on what terms, and for how long?

The Model Context Protocol solved a real problem. Before it, every agent-to-service connection was a bespoke integration. MCP standardized the plumbing: a bridge between an agent and a service, so tools and data can flow across it.

The Hypercontext Protocol lives one layer up, and it is a different kind of thing. It is a social contract rather than a wire format. Nothing about a bridge tells you what should be allowed to cross it.

Diagram: three-layer flow. On the left, a person and their hypercontext, held where they host it and curated by their own agent. In the middle, the Hypercontext Protocol boundary listing its guarantees: minimal disclosure, purpose-bound use, transparent holdings, expiring grants, deletion on disconnect, your curator decides. To the right, MCP drawn as the bridge between an agent and a service, and finally the service itself, which holds a sliver and delivers relevance. Footer: MCP answers how an agent and a service talk; HCP answers what of a person's life may cross, on what terms, and for how long.

The two protocols compose​

They are complements, never competitors. In a well-built system the MCP activation aligns with the Hypercontext Protocol: the bridge carries only the context necessary for that agent to do its job, because your curator decided so before anything touched the wire. MCP moves the sliver. HCP is the reason it is a sliver.

It is not complicated to honor. AI is good at reasoning about what context a job requires. The hard part was never technical; it was that nobody named the contract, so services defaulted to taking everything they could.

Why the contract needs its own name​

A bridge is neutral. The same MCP connection can carry a scoped, purpose-bound, expiring sliver, or it can carry your entire life into a vendor's database. Both look identical at the transport layer. The difference is the contract, and an unnamed contract cannot be demanded, marketed, audited, or refused.

Naming it changes the conversation on both sides. A user can ask "does this implement the Hypercontext Protocol?" and know what a yes commits the service to: the eight tenets, all of them, verifiably. A builder can implement it and say so, and the claim means something specific.

What each layer never does​

  • MCP never decides what to share. It has no opinion; it is a pipe.
  • HCP never dictates implementation. Transports, storage, curator design, and hosting can all differ across implementations. The contract is what stays fixed.

Further Reading​