Henry Hund’s Protocol — product marketing as a living MCP server.
Henry Hund (ex-COO Aptible, mid-eight-figure acquisition 2025) is building Protocol, a productized version of the context-MCP pattern he already runs himself in Claude Code. The pitch: convert your approved product marketing into an MCP server that AI tools query on demand and that updates from usage signal and market change. The structural bet — that the unit of B2B GTM distribution is the MCP-served context pack, not a SaaS app — is the most strategically consequential bet in the field right now. If Protocol becomes the messaging-source-of-truth standard, every other GTM tool consumes its output. Here is the architecture, where it stops short, and where the action layer fits.
TL;DR
- Protocol is PMM-as-MCP-server. The unit of delivery is a context pack — positioning, ICP, value props, objection handlers — exposed via an MCP endpoint that AI tools (Claude, ChatGPT, IDEs, internal agents) query per call.
- The artifact is “living”: it updates from two signal sources — usage (which queries surface gaps, which framings get cited) and market change (competitor updates, product shifts). The positioning artifact decays slower than its inputs because the inputs feed it.
- The proof point is Hund himself. He runs Claude Code + a context MCP server stocked with PULL framework notes, Mom Test notes, and product context. Claude pulls context on demand per call. Protocol is the productized version of that exact pattern — the founder is the most demanding user.
- The structural bet: MCP-as-distribution. The conventional SaaS distribution unit is an app you log into. The MCP distribution unit is a context pack the tools you already live in query during real work. Upstream of every other GTM tool.
- Where context layers stop short: no campaign execution, no reply-data backflow, no outcomes-anchored feedback loop. The pack informs copy. It does not ship copy and it does not learn from whether the copy converted.
- Pricing is not public. Protocol is in private beta — waitlist with work email and company. The actual feature surface is gated.
- How Allston/Skylarq fits: consume Protocol packs as the messaging anchor for outbound campaigns, contribute reply-data backflow as the freshness signal Protocol’s internal usage loop is blind to, and run the action layer where positioning becomes pipeline.
Why read Protocol
Positioning rots faster than docs can keep up with. The traditional positioning artifact is a Notion doc, a slide deck, or a one-pager — read at low frequency by the team and updated at lower frequency by the head of marketing. By month three the artifact is stale; by month six it is wrong; by month twelve the team has stopped consulting it and is operating from a folk model of the positioning that was correct two product iterations ago.
The MCP-served context pack inverts both clocks. It is queried per call by every AI tool the team uses — which means consumption is no longer optional, it is structural. And it updates from usage signal (which queries surface gaps, which framings get cited, which positioning lines get traction in the tools that pull the pack) plus market signal (competitor changes, product updates, category drift). The mechanism is structural rather than disciplinary — the artifact becomes durable because it lives inside the workflow rather than alongside it.
One upstream point that determines the rest of this chapter. The conventional positioning artifact fails not because the doc is poorly written but because the doc is poorly positioned in the workflow. A Notion page in a folder is read when someone remembers to look. An MCP endpoint that Claude queries every time it writes a one-pager, an email, a deck, or a sales script is read constantly. The Hund bet is that the positioning artifact’s durability is a function of where it lives in the stack, not how well it is written. We think this is the correct read.
The structural bet — MCP-as-distribution
This is the central argument of the chapter and the reason Protocol is worth reading regardless of whether the product ships. The conventional B2B SaaS distribution unit is the app: a buyer logs in, navigates the dashboard, clicks through features. Distribution is the front door and the front door is the product. Every minute the buyer spends in your app is a minute they are paying for the right to spend more minutes in your app — a self-justifying loop that is the entire premise of SaaS pricing.
The MCP distribution unit is the context pack. The buyer does not log in. The buyer lives in Claude, ChatGPT, Cursor, an internal agent — and those tools query the pack as part of doing real work. The pack is consumed inside the tooling the user already lives in. The buyer never sees the front door because the front door has been replaced by a wire protocol that runs in the background of every other tool they touch.
If MCP servers become the standard distribution mechanism for B2B AI tooling — and the signal across Anthropic’s ecosystem, Cursor’s ecosystem, and the broader agent tooling layer suggests they will — then Protocol’s position is upstream of every other GTM tool in the stack. Positioning anchors messaging. Messaging anchors copy. Copy anchors campaigns. The thing closest to the messaging anchor compounds most, because everything downstream depends on it and every downstream consumer queries it.
The wager is not on Protocol the product. The wager is on the proposition that the MCP-served context pack is the durable unit. If the proposition holds, Protocol or something like it wins by default. If the proposition fails, Protocol becomes a feature of a CMS and content brands compete on framework IP instead. The proposition is what to evaluate, not the product surface.
The architecture — four components
Protocol’s feature surface (per the site) is four components. The four together produce a positioning artifact that decays slower than its inputs because the inputs feed it.
- Context pack builder. The source-of-truth artifact. Positioning statements, ICP definitions, value propositions, objection handlers, comparative positioning against named competitors, the proof-point library. The pack is composed once and then maintained against usage and market signal — but the initial composition still requires PMM discipline upstream. The builder is the editor for an artifact that already needs to exist conceptually.
- MCP server distribution.The endpoint that exposes the pack to Claude, ChatGPT, IDE agents, and internal tooling. The pack is no longer a document the team reads. It is a queryable endpoint the team’s tools pull on a per-task basis — every email draft, every one-pager, every sales script, every objection handler call into the same source of truth. The consumption surface is the protocol, not a webpage.
- Usage-based feedback loop. The pack learns from how teams query it. Which positioning lines get retrieved most often. Which queries return weak or missing content. Which framings get cited in downstream artifacts and which get rewritten. The signal is consumption-anchored — the pack updates against how it is used, not against how the market responds to its output.
- Market change tracking. The external signal layer. Competitor positioning shifts, product launches, category language drift. The pack refreshes against the market so the positioning does not date itself the moment a competitor reframes their wedge. The mechanism is plausibly external scrape plus operator-curated input — the public surface is light on detail given the private beta.
The architecture is internally coherent. The thing that determines whether it is operationally load-bearing is whether the team using it already has a positioning doc worth turning into a pack. Protocol systematizes what is upstream of it. It does not replace the upstream.
Hund’s own pattern as the proof point
The most credible signal for Protocol is not the product page. It is the LinkedIn comment Hund left on the post announcing it. He described his own setup explicitly: Claude Code, plus a context MCP server stocked with Rob Snyder’s PULL framework notes, Mom Test notes, and product context. Claude pulls context from the MCP on demand per call. Protocol is the productized version of that exact pattern.
This is the rare case where the founder is structurally the most demanding user of the product. The dogfooding is not performative — Hund is not running a paid version of his own tool to generate a screenshot. He built the pattern for himself, ran it, found it durable, and is now productizing the workflow he already depends on. The product roadmap is constrained by the constraint that it has to keep working for him on the live operating motion he runs.
The implication for the buyer is direct: the most strenuous QA test on Protocol is whether Hund can keep using his own setup as the product surface evolves. If Protocol grows in a direction that breaks his Claude Code workflow, his own usage rebels and the product corrects. This is the strongest possible alignment between founder and product, and it is the central reason to take Protocol seriously even when the public feature surface is thin.
Where Protocol stops short
Protocol is rigorous at the messaging-source-of-truth layer and silent on the layers below it. Five honest gaps an operator hits the moment they think about running it in production:
- The context pack is the input to outbound, not the outbound. Positioning is upstream of campaigns. Protocol delivers a queryable positioning artifact. It does not run the campaigns the positioning informs. The team still needs the layer that turns a queried pack into a 5-touch sequence, schedules the touches, manages deliverability, and lands the messages in the inbox. Protocol is the brief. The campaign-running layer is the build.
- The usage feedback loop is internal. Protocol learns from how the team queries the pack — which positioning lines get retrieved, which queries surface gaps. The signal is consumption-anchored, not outcomes-anchored. A messaging line that gets queried frequently but converts poorly looks like a winner to a usage loop and like a failure to a reply-data loop. The Protocol feedback signal is structurally blind to the conversion question.
- No campaign-execution integration.The pack informs copy. It does not ship copy. The handoff from “Claude wrote a draft against the pack” to “the draft went out across 800 prospects, got 47 replies, and 12 booked meetings” sits in a different system. Protocol does not own the bridge.
- Private beta, gated feature surface.The public artifact is the site copy plus Hund’s LinkedIn posts. The actual product is gated to waitlist access. The adopter signal is limited to Hund’s pre-launch positioning and the early-access cohort that has not yet reported publicly. The honest read is that Protocol’s feature depth is a hypothesis until the beta opens.
- Requires structured PMM discipline upstream. A team that does not already have a clear positioning doc, ICP, value-prop set, and objection map will not produce a useful context pack by buying Protocol. The product systematizes the artifact a disciplined PMM has already produced. It does not generate that artifact from scratch. Operators expecting Protocol to do the PMM work will leave the pack thin and the queries will return thin answers.
These are not criticisms of the wedge. Protocol is intentionally scoped at the messaging-source-of-truth layer — that is the layer where the structural bet sits. The gaps are at the layers below, and the operator who closes them turns the context pack from a positioning artifact into a pipeline engine.
How Allston/Skylarq fits above Protocol
The strategic response is not to compete on the context server. That is Hund’s wedge, he is the right operator to win it, and the structural bet is fair. The complementary position is the action layer — where the pack becomes a campaign and the campaign produces reply data. Three specific moves:
- Consume Protocol packs as the messaging anchor for outbound. Skylarq agents that draft outbound — first touches, follow-ups, objection responses, comparative positioning — pull from a Protocol-style context pack as the source of truth. The pack is the positioning brief. The agent is the writer. The campaign is the runtime. The architecture treats Protocol as upstream and consumes its output rather than rebuilding it.
- Skylarq reply backflow becomes Protocol’s missing freshness signal.Protocol’s usage loop is consumption-anchored — it sees what the team queries. Skylarq’s reply backflow is outcomes-anchored — it sees how prospects respond to messaging derived from the pack. A messaging line that gets queried 200 times and produces 2 replies is the failure case Protocol’s loop is structurally blind to. The Skylarq layer catches it, and the catch flows back into the pack as a freshness signal that is market-truthed rather than internally-truthed.
- Allston audit deliverables reference Protocol-style context packs as the upstream input. When we scope a customer engagement, the audit asks where the messaging source of truth lives, whether it is queryable, and whether it updates on a cadence that matches the market clock. Protocol-style packs are in scope as the upstream artifact. Skylarq is the consumer. Allston is the integrator. The customer ends up with a messaging anchor that lives in the workflow and a campaign layer that produces the reply data the anchor needs to stay current.
The aggregate position: don’t fight Hund at the messaging-source-of-truth layer. Consume his output, contribute the freshness signal he can’t see internally, and run the action layer where the pack becomes pipeline. The two layers are complements, not substitutes.
The freshness-signal differentiation
This is the underrated insight in the architecture. Protocol’s feedback loop is “how teams query the pack.” Skylarq’s reply backflow is “how prospects respond to messaging derived from the pack.” The second is structurally stronger as a learning signal because it is outcomes-anchored, not consumption-anchored.
A messaging line that gets queried frequently inside the team’s tooling is a line the team finds useful. A messaging line that produces replies in cold outbound is a line the market finds useful. The two signals correlate weakly. The most queried line is often the line the team is most comfortable with — the one that confirms the existing positioning. The line that produces replies is often the one the team rewrites under pressure because the comfortable line wasn’t working. The difference between “the team likes this line” and “the market responds to this line” is the entire gap between an artifact that is internally coherent and an artifact that is externally true.
The Protocol-plus-Skylarq architecture catches both signals. Usage signal tells the pack which lines are easy for the team to deploy. Reply signal tells the pack which lines convert. The pack updates against the conjunction, not the disjunction. A line that is consumed often and replies poorly is a flagged candidate for revision. A line that is consumed rarely and replies well is a flagged candidate for promotion. The two-signal architecture is meaningfully more current than either alone.
Operator failures when adopting context-layer products
The failure modes below are not specific to Protocol — they are the patterns we observe across teams trying to adopt any context-layer product, and they apply directly to Protocol-style adoption. Five failures that produce the largest negative variance:
- Building a context pack without underlying positioning discipline. The pack is an editor for an artifact that already needs to exist. A team without a clear positioning doc, ICP statement, and objection map will produce a pack that is structurally complete and semantically thin — the queries return answers, but the answers are the same hedged generalities the team was producing before. The product systematizes the upstream artifact. It does not generate it.
- Treating the pack as the outbound source-of-truth without running campaigns against it. Positioning is hypothesis until campaign data confirms or denies. A team that locks the pack and runs no campaigns is producing a positioning artifact that is internally elegant and externally untested. The pack needs the campaign layer below it not for execution alone but for the falsification signal that keeps it true.
- Skipping the reply-data integration. Consumption-anchored feedback loops miss the conversion question. A team that adopts the pack and the usage loop without piping reply data back into the pack is operating with a feedback signal that is internally biased toward team comfort and externally blind to market response. The pack drifts toward what the team likes saying rather than what the market replies to.
- Over-investing in the context layer at the expense of execution. A pristine pack with no campaigns running underneath is essay-writing. The most common failure mode in PMM-heavy teams is to spend three quarters refining the positioning artifact and one quarter shipping a single campaign. The action layer compounds. The artifact layer is binary — it is either current or stale, and the only thing that keeps it current is reply data from a running campaign.
- Assuming MCP distribution is universally adopted.The structural bet is real but not yet won. Some buyers will continue to want a CMS, some will continue to want a Notion doc, some will continue to want a Google Doc with a quarterly review meeting. Protocol’s bet is that the MCP-served pack becomes the standard. The bet is plausible. The bet is not yet settled. Operators who go all-in on the MCP distribution model in 2026 should size the position to a bet that is probably correct, not a bet that is already won.
Protocol-style-adoption checklist
- Positioning doc is current — ICP, value props, objection handlers, comparative positioning against named competitors — and the team can produce the underlying artifact without the tool
- Context pack is composed against the positioning doc and accessible via an MCP endpoint that the team’s tooling can reach
- AI tooling (Claude, ChatGPT, IDE agents, internal agents) is configured to query the pack per task — first-touch drafting, objection responses, one-pager generation, sales script preparation
- Usage feedback loop is running and the operator reviews the signal at a fixed cadence — which queries return weak content, which lines get retrieved most, which framings get cited downstream
- Market-tracking layer is wired to competitor positioning shifts and product updates, with operator review on a cadence shorter than the market clock
- Reply-data integration is considered explicitly — this is the gap most teams skip, and it is the gap that determines whether the pack stays externally true or drifts toward internal comfort
- Campaign-execution layer is planned downstream — the pack is the brief, the campaign layer is the runtime, and the two are wired with reply data flowing back
- The team has at least one running campaign producing reply data against pack-derived messaging, so the pack is being externally falsified on a rolling basis
- The freshness cadence is named — the pack updates at a frequency that matches the market clock, not the calendar quarter
- The pack is not the only positioning artifact — a human-readable doc still exists for the cases where AI tooling is not the consumer (board reviews, fundraising decks, customer-facing one-pagers)
Where this fits
Protocol is one chapter in our framework analysis series, and it sits at the top of the GTM stack — the messaging-source-of-truth layer that anchors everything below it. Rob Snyder’s PULL framework is the methodological foundation Hund himself cites — his Claude Code MCP setup loads PULL framework notes as core context, and Protocol’s pack composition borrows the PULL discipline at the positioning layer. Richard Makara’s GTM Context OS is the open-source analog at the doc layer — a directory-and-slash-command scaffold for a context system that lives in the repo rather than on an MCP endpoint. MKT1 is the comparable distribution model on the content side, where the unit of delivery is the framework itself rather than a productized server.
On the operator side, the chapters that compound on Protocol-style adoption are downstream — the campaign-execution layer, the reply-data backflow, the discovery rubric that turns positioning into qualified pipeline. The pack is the brief. The chapters below it are the build.
Related chapters
- Rob Snyder’s PULL framework — the methodological foundation Hund himself cites in his Claude Code setup.
- Richard Makara’s GTM Context OS — the open-source analog at the doc layer.
- MKT1 — the comparable distribution model on the content side.
- SalesGraph — the relationship-graph layer that sits downstream of positioning.
Allston Labs consumes Protocol-style context packs and runs the campaigns that produce the reply data.
We treat the messaging-source-of-truth as the upstream brief, draft outbound from the pack, ship the multi-touch sequences across channels, and feed every reply back as the freshness signal the internal usage loop can’t see. The positioning anchor stays current because the campaign data keeps it honest.