The Model Context Protocol shipped its 2026-07-28 revision and removed its own handshake. A close reading of the seven changes that bear on PCHP — which we are copying outright, which we must adapt, and the one place a consent protocol has to hold its ground.
PCHP composes over MCP rather than competing with it. MCP standardises how an agent reaches a tool; PCHP adds who asked, under what consent, for what purpose, and with what receipt. That only works if the two feel like one stack to an implementer — and the fastest way to break that is to solve a problem MCP has already solved, in different words.
So when MCP publishes a revision, the useful question is not what we think of it. It is: which of their answers are now the obvious ones, and where does a consent protocol genuinely need to differ? Seven items, below. Five we adopt, two we adapt, and the reasoning is given in each case so it can be argued with.
Our current published state: protocol pchp/2026-07-12, specification v0.1.0. These are proposed amendments, not shipped changes — the status page remains the record of what is actually enforced.
01AdaptMake each ACCESS stateless; keep the GRANT stateful.In MCP 2026-07-28: The initialize/initialized handshake and Mcp-Session-Id are gone. Every request carries its own protocol version, client identity and capabilities.
This is the change that matters most and the one we must not copy naively. MCP could go stateless because a tool call has no memory. Consent does: a grant is a durable promise and a receipt is a permanent record, and a protocol that forgets them is not a consent protocol. The resolution is to split the two. The grant stays stateful, durable and receipt-anchored. Every subsequent access becomes a self-describing, single-round-trip request carrying the receipt reference and the protocol version — no held session, no server-side conversation state. That is what our token plus receipt design already implies; the specification should say it outright, because a reader today could reasonably build a session-oriented implementation from the six phases as written.
02AdoptAdopt the shape verbatim as consent_required.In MCP 2026-07-28: Multi Round-Trip Requests. A server answers resultType: "input_required" naming what it needs; the client retries with inputResponses.
This is the single most valuable thing in the update for us, and it is almost embarrassing how exactly it fits. Phase 3 of our handshake — Offer — is the moment a requester asks for something the owner has not yet granted. Today the specification describes the issuer surfacing that to the owner and the exchange continuing, which quietly assumes a held connection. MRTR is a standard, stateless answer to precisely that problem, already implemented across four SDKs. We should mirror it rather than invent a synonym: a request lacking consent returns consent_required naming the exact scopes, the purpose, and where to grant them; the requester retries carrying the grant. Same shape, same intuition, one less thing for an implementer to learn.
03AdoptAdopt, and it is worth more to us than to them.In MCP 2026-07-28: Mcp-Method and Mcp-Name headers, so gateways, rate limiters and WAFs can route and meter without parsing the JSON body.
For MCP this is an operational convenience. For a consent protocol it is a security primitive. If the requested scope, purpose and receipt id travel in headers, an enforcement point can allow, deny, meter and log an access WITHOUT EVER READING THE PAYLOAD — the gateway sees that a subscriber asked for a tier-2 scope under a named purpose, and never sees the person's data. That is a materially stronger property than enforcement performed by the same code that handles the plaintext, and it maps directly onto the least-privilege and audit controls we are pursuing for FedRAMP High. Proposed: PCHP-Scope, PCHP-Purpose, PCHP-Receipt, PCHP-Protocol-Version.
04AdoptAdopt — and it resolves a gap we have been publishing.In MCP 2026-07-28: server/discover is optional. Clients may learn capabilities proactively, but the specification does not require it.
Our Phase 1 says a requester MUST begin by fetching a discovery document at a well-known location. We do not serve one. That is a conformance claim we fail ourselves, and it has been sitting in the published specification. MCP arriving at optional discovery is both a good design signal and a clean way to correct our own text honestly: discovery becomes a SHOULD with a defined shape, so an implementation without it is still conformant, and shipping ours becomes an improvement rather than a prerequisite.
05AdoptAdopt the binding rule.In MCP 2026-07-28: RFC 9207 issuer validation, client credentials bound to their issuing authorization server, and Dynamic Client Registration deprecated in favour of Client ID Metadata Documents.
A consent receipt that does not name and bind its issuer can be replayed against a different issuer that happens to trust the same signature. Our tokens are issuer-signed but the specification does not require a verifier to check which issuer, and it should: a receipt is valid only against the issuer that minted it, and a requester must reject a grant whose issuer does not match the one it negotiated with.
06AdaptAdopt the namespacing; study the subscription stream.In MCP 2026-07-28: Extensions get reverse-DNS namespaces. Tasks graduated from experimental to io.modelcontextprotocol/tasks, with poll-based tasks/get and a single subscriptions/listen change stream.
Namespacing is free and prevents a category of collision as soon as anyone else implements PCHP, so extensions should be ai.hushh.pchp/<name>. The subscription stream is more interesting: RFC-002, our Preference Subscription Fabric, is a change stream over a person's preferences, and MCP has just consolidated its own change notifications into one poll-friendly listen endpoint. Ours is still in design, which means we can learn from the shape they converged on rather than discovering the same lesson later.
07AdoptAdopt the policy. We do not have one.In MCP 2026-07-28: Roots, Sampling, Logging and the legacy HTTP+SSE transport are deprecated with a stated twelve-month minimum window.
We publish a scope registry that other people are invited to build against, and we have never said what happens when a scope is renamed or withdrawn. A person's grants and a subscriber's integrations both depend on that answer. A stated minimum window, published alongside the registry version, is the difference between a vocabulary others can safely adopt and one they cannot.
Mirroring MCP’s multi round-trip pattern rather than inventing our own. A requester asks for something it has not been granted; the issuer does not hold a connection open waiting for a human — it answers with exactly what is missing and where to get it, and the requester comes back.
// Requester asks. No session, no prior handshake.
POST /pchp/read
PCHP-Protocol-Version: pchp/2026-07-12
PCHP-Scope: prefs.apparel.shoe-size
PCHP-Purpose: retail.fit
// Issuer answers: not granted, here is precisely what is needed.
{
"resultType": "consent_required",
"required": [
{ "scope": "prefs.apparel.shoe-size", "tier": 2, "purpose": "retail.fit" }
],
"grantAt": "https://hushh.ai/@ada/consent?req=01J...",
"expiresIn": 900
}
// Requester retries, carrying the grant. Still no session.
POST /pchp/read
PCHP-Receipt: rcpt_01J...
{ "consentResponses": [ { "scope": "...", "receipt": "rcpt_01J..." } ] }Note what the gateway in front of this can do without opening the body: read the scope, the purpose and the receipt from headers, and allow, deny, meter or log the access. The enforcement point never sees the person’s data. That is change 03 doing real work rather than being a convenience.
It is worth being explicit about the one place we decline to follow, because it is the interesting disagreement rather than an oversight.
MCP could delete its handshake because a tool call is memoryless: the same request twice is the same request. Consent is not like that. A grant is a promise that persists after the exchange ends, revocation has to reach every access derived from it, and a receipt is a permanent, ordered record that someone may need to hold us to years later. Statelessness at that layer would not be an efficiency — it would delete the product.
So the split is deliberate: the grant is durable, ordered and receipted, and the accessis stateless and self-describing. We get MCP’s operational properties — no held connections, gateway-friendly, horizontally scalable — on the layer where they are free, and we keep the memory on the layer whose whole purpose is remembering.
The Model Context Protocol is Anthropic’s work, donated to a Linux Foundation body, and none of the above implies affiliation, partnership or endorsement. We read their specification closely because it is open and because the discipline shows: they deprecated their own primitives with a stated window and removed a handshake they had shipped. That is harder than adding features, and the field is better for it.
They are proposals, not shipped changes. The specification is open and the gaps are published alongside it.
One is a product of Hushh Technologies Corporation (brand: 🤫 “hussh”), an independent company. One runs on third-party silicon, systems, and cloud; platform names are used solely to describe where One software runs and imply no affiliation, endorsement, or sponsorship by those platforms. Our own go-to-market and bill-of-materials partner programs are real and actively in pursuit; we name a partner only once an agreement is executed.