← Patterns

Protocol Over Tool

Pattern · design-philosophy

Core Concept

When you find yourself building a tool that bridges two systems, stop and ask: should this be a protocol instead?

A tool solves your problem. A protocol solves a category of problems. The effort to build either is often similar, but a protocol compounds — it lets other people solve their own version of the same problem without you.

The Two Approaches

Build a ToolBuild a Protocol
SolvesYour specific problemA category of problems
Integration costN tools x M systems = N*M integrationsN tools x 1 protocol + M adapters = N+M integrations
Who benefitsYouEveryone with the same problem
AdoptionYou use itOthers can adopt independently
ExtensibilityYou maintain every integrationOthers write their own adapters
Lock-inTied to your architectureArchitecture-agnostic

The math is the key insight: N*M vs N+M. Five agents and four PM systems is 20 bespoke integrations or 9 protocol-conforming pieces. At scale, the protocol wins by orders of magnitude.

When to Reach for a Protocol

Not everything should be a protocol. Use this heuristic:

  1. Multiple producers and consumers exist — if only one system will ever serve this data and one system will ever consume it, a direct integration is simpler
  2. The schema is more stable than the systems — “a unit of work has a title, status, and description” is stable. Specific PM tools come and go.
  3. You’d otherwise build the same adapter twice — the moment you think “I need a Linear integration AND a Jira integration,” you need a protocol
  4. Interoperability is a feature, not an accident — if you want other people to plug into your system (or you want to plug into theirs), a protocol is the only way

When NOT to Reach for a Protocol

  1. You’re the only consumer. A protocol with one adapter is an over-engineered tool. Build the tool, extract the protocol later if demand appears.
  2. The problem is too novel. You don’t know the right abstractions yet. Build the tool, learn, then standardize. (This is why WCP starts as a tool and becomes a protocol in Phase 3.)
  3. Speed matters more than interoperability. Ship the direct integration, refactor later.

Intellectual Ancestry

TCP/IP — didn’t try to be a better network. Defined how ANY network could talk to any other network. Every proprietary network protocol lost.

HTTP / REST — didn’t try to build a better file transfer tool. Defined how any client could talk to any server. The web is a protocol, not a product.

LSP (Language Server Protocol) — Microsoft didn’t build a better IntelliSense for every editor. They defined how any editor could talk to any language server. One protocol replaced hundreds of editor-specific integrations.

MCP (Model Context Protocol) — Anthropic didn’t build integrations between Claude and every tool. They defined how any model could talk to any tool server. Same pattern.

RSS — a protocol for “here’s what’s new.” Simple, decentralized, composable. Worked for two decades despite every platform trying to replace it with proprietary feeds.

Where I’ve Seen It

The Trap: Premature Protocol

The biggest risk is designing a protocol before you understand the problem. Every failed XML schema and abandoned W3C spec is evidence of premature standardization.

The antidote is Phase 1 → Phase 3 thinking:

  1. Build the tool you need. Use it.
  2. Discover what’s stable (the schema) vs. what’s incidental (the storage, the UI).
  3. Extract the protocol from what survived real use.

This is why successful protocols almost always come from working implementations, not committee specifications. HTTP came from Tim Berners-Lee’s working hypertext system. MCP came from Anthropic’s working tool-use infrastructure. WCP should come from a working task tracker.

Cross-References