Skip to content

Instantly share code, notes, and snippets.

@bparanj
Created June 9, 2026 00:35
Show Gist options
  • Select an option

  • Save bparanj/e8219db77e7f1a7c8a0c9648f94d7b8c to your computer and use it in GitHub Desktop.

Select an option

Save bparanj/e8219db77e7f1a7c8a0c9648f94d7b8c to your computer and use it in GitHub Desktop.

It is a fair question. Technically, in strict networking terms, a protocol usually implies a "handshake" or a two-way conversation between a client and a server (like HTTP or TCP).

Since Stave is a CLI/engine that processes data, calling it a "protocol" might feel like a stretch to a networking purist. However, in modern software architecture (and specifically in the context of the MCP comparison), you are correct enough to use it, provided you understand the distinction.

Here is how to think about it and whether you should change the wording:

1. The Case for "Protocol" (Why it works)

In systems design, a Protocol is simply a set of rules governing the exchange or transmission of data between components.

Even if there isn't a "live" connection:

  • The Hand-off is the Protocol: When an extractor (like Steampipe) finishes its job and hands a JSON file to Stave, that hand-off is governed by your obs.v0.1 schema. That "agreement" on how data is passed between two independent software entities is, in a broad sense, a protocol.
  • The Unix Parallel: You mentioned Unix pipes. While we often call it a "pipe," the protocol of Unix pipes is "lines of ASCII text terminated by a newline." It’s a 1-way protocol.
  • The "MCP" context: Anthropic calls MCP a protocol because it allows a Model and a Tool to interact. Even if you ran an LLM locally and it called a local script, the interface is the protocol.

2. The Case for "Contract" or "Schema" (The alternative)

If you want to be 100% technically "correct" to a cynical engineering audience:

  • Schema: Defines the structure of the data (obs.v0.1 is a schema).
  • Specification: Defines the requirements for the logic (ctrl.v1 is a spec).
  • Contract: Defines the obligation between two tools (The extractor must provide these fields).

3. Should you change it?

In your article, the term "Protocol" is powerful because it links you to MCP. If you call Stave a "Schema," it sounds like a boring database project. If you call it a "Protocol," it sounds like a Systemic Solution.

My Recommendation: Keep "Protocol" in the title/hook to maintain the MCP parallel, but use the word "Contract" (which you already do) to explain how it works.

You can bridge the gap by saying:

"While Stave isn't a client-server protocol in the networking sense, it is a data exchange protocol. It defines the rules for how security state moves from a provider to a reasoning engine, and how policy intent moves from a human to a machine."

Summary of terminology for your use case:

  • Is it a Protocol? In the broad sense of "Standardized Interaction," Yes.
  • Is it a Schema? Technically, Yes (it defines the JSON shape).
  • Is it a Contract? Historically, Yes (it’s an agreement between the producer and consumer).

Verdict: Keep "Protocol" for the marketing/architectural "M×N" narrative. It correctly conveys that you are building a standardized way for two different things to work together, which is exactly what Anthropic did. Neither the LLM nor the Tool "own" the MCP protocol; they both just "obey" it. That is exactly what you are doing with Stave.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment