What Is MCP over MOQT? The Beginner's Guide to Model Context Protocol on QUIC

CodexFuse Team · 2026-11-05T08:28:21.461Z · 22 min read min read

What Is MCP over MOQT? The Beginner's Guide to Model Context Protocol on QUIC

What Is MCP over MOQT?

If you have asked what is mcp over moqt, the short answer is that it is a proposed way to carry Model Context Protocol messages over Media over QUIC Transport, a publish-subscribe protocol that runs on QUIC. Instead of sending every MCP message as a new HTTP request, the client and server publish JSON-RPC messages onto named MOQT tracks, and relays can cache the public ones for every client behind them. The idea comes from an IETF Internet-Draft published on 1 November 2026, and it is four days old at the time of writing, which is why no independent explainer existed before this one.

MCP over MOQT matters because MCP, the open standard that lets AI applications discover and call external tools through one JSON-RPC 2.0 interface, currently defines only two standard transports, stdio for local servers and Streamable HTTP for remote ones. Both work, and both have limits that show up the moment a connection drops or many clients ask for the same tool list. The draft's answer is to borrow the machinery built for low-latency media delivery and aim it at agent traffic instead.

That makes MCP over MOQT a genuine MCP publish subscribe transport, not a request-response one, and the distinction drives everything else in this guide. A client subscribes to the tracks it needs, a server publishes answers into known groups, and a relay in between can serve cached copies without waking the server. The rest of this guide walks through how that mapping works, what breaks today, and who should care while the draft is still a work in progress.

Two details in this guide are easier to follow with a quick hands-on check. The client ID in the draft is derived with HMAC-SHA256, and a SHA-256 hash generator shows what that kind of hash looks like in seconds. And when a remote MCP server needs a home of its own, VPS hosting is where most self-hosted servers live, because the server stays up while clients come and go.

How Does MCP over MOQT Work?

MCP over MOQT works by turning every MCP exchange into a publish-subscribe exchange on MOQT tracks. Both sides are publishers and subscribers at once, because each publishes the tracks it owns and subscribes to its peer's tracks. A client needs no handshake beyond MOQT setup, because after setup it derives its client ID, subscribes to the server's tracks, and starts sending requests.

The full arc from zero to a first tool call looks like this.

1. The client sets up a MOQT session with the server or its relay, then derives its client ID from the server ID with HMAC-SHA256, so the same ID comes back on every reconnect without stored state.
2. The client subscribes to the server's catalog track, which lists supported versions, capabilities, tools, resources, and prompts in one JSON object, replacing the usual discovery requests.
3. The client publishes a request as a new group on a request track, and the server publishes its response into the same group ID on the response track, using the JSON-RPC id as the authoritative correlation key.
4. While the request runs, progress notifications arrive as objects in the same group, and the final result or error carries the highest object ID, so the client knows when the exchange is complete.
5. If the connection drops, the client reconnects, re-subscribes with a fill fetch, and receives the rest of the response from the relay cache instead of re-issuing the request.

Each MOQT object carries one payload, with no framing beyond the object boundaries. That payload is one MCP JSON-RPC 2.0 message on control, request, and response tracks, one JSON document on catalog, task, and skill tracks, or one chunk of resource content on resource tracks. Requests may run concurrently, because each exchange occupies its own group.

The client ID formula is worth a closer look, because it is what makes recovery possible. The draft defines it as the base64url encoding of the first 16 bytes of HMAC-SHA256 of the server ID, which is 128 bits of identity, or 22 characters once encoded. Because the derivation is deterministic, the same client gets the same ID on every connection to the same server, so its responses and tasks carry over a reconnection.

What Is MOQT, and How Is It Different from QUIC?

MOQT stands for Media over QUIC Transport, and despite its name, the draft states plainly that it is media agnostic and can be used for a wide range of use cases. It is a publish-subscribe protocol that runs over QUIC and WebTransport, and it operates both point to point and through intermediate relays, which is what makes scalable low-latency delivery possible. The current MOQT specification is draft-ietf-moq-transport-23, dated 2 November 2026, and it is on the Standards Track.

MCP transport over QUIC is the plain-English expansion of the idea, and the hierarchy inside MOQT is what carries the meaning. A track is a collection of groups, a group is a collection of objects and a join point in the track, and a subgroup is a sequence of objects from the same group sent on a single transport stream whenever possible. An object is the smallest addressable unit, and its contents must never change once published, so a relay can serve the same bytes to any subscriber.

MOQT sits above QUIC rather than replacing it, and the difference matters. QUIC itself is the encrypted, multiplexed transport defined in RFC 9000 in May 2021, about five and a half years before this draft, running over UDP with TLS 1.3 built in, independent streams, and connection IDs that survive address changes. MOQT adds the publish-subscribe model on top, with named tracks and namespaces, relays and caching, and subscriber-controlled delivery order.

Why Do MCP's Current Transports Need a New Option?

MCP currently defines exactly two standard transports, and the official specification says so in plain terms. The first is stdio, where the client launches the server as a subprocess and the two exchange newline-delimited JSON-RPC messages over standard input and output. The second is Streamable HTTP, where the server runs as an independent process behind a single MCP endpoint and every client message arrives as a new HTTP POST request, with an optional Server-Sent Events stream for the reply.

The draft's case against today's transports is specific, and it is the draft's own framing rather than a verdict from the MCP specification. For stdio, the limit is that it is single-process only, with no network distribution, so a server launched by one client cannot serve another. For Streamable HTTP, the draft says a broken response stream loses the in-flight request, which the client must re-issue as a new request, and it adds that there is no per-message prioritization and that shared caching is limited to what HTTP intermediaries provide.

Fairness requires the other side of the Streamable HTTP story. The MCP specification offers optional per-stream resumability, because servers may attach an id to their SSE events and a reconnecting client may send a Last-Event-ID header so the server can replay messages on the stream that was disconnected. That mechanism is optional and scoped to one stream, while the draft's recovery model is built into the transport itself, which is the gap the draft is trying to close.

The timing also matters, because the MCP specification's 2026-07-28 revision made the protocol stateless, and the draft says that model fits MOQT well. Every request now carries its protocol version and the client's capabilities, and servers keep no per-connection session, so nothing about a session is lost when a connection moves.

A webhook is a one-way HTTP push from a provider to your endpoint, which is the opposite direction of travel from an MCP client asking a server for tools, and it shows why a request-response transport strains when the traffic is really a conversation. If you want the contrast spelled out, the guide to what a webhook is covers the push pattern in detail.

How Are MCP Messages Mapped onto MOQT Tracks?

The mapping gives every MCP primitive its own track, and the namespace layout is the addressing scheme. Every namespace begins with the server scope, which is the pair of the literal mcp and the server ID, and the client scope adds the word clients and the derived client ID underneath it. Server-scope tracks carry only content whose MCP cacheScope is public, such as the catalog, public resources, and skills, so relays can serve them to every client from cache.

Client-scope tracks carry the private side of the conversation, which is the client's requests, the server's responses, task state, and any content whose cacheScope is private. The draft is explicit that a server must not publish private content in the server scope, because anything published there is cacheable by relays and visible to other clients. That single rule is the privacy boundary of the whole design.

Tool and prompt tracks go one step further, because each tool gets its own request and response track pair, and each prompt gets the same treatment. The namespace for a tool is the client scope plus the word tools and the tool name, so access to an individual tool can be authorized by namespace alone. Each invocation creates a new group on the request track, which keeps concurrent calls cleanly separated.

Resources and tasks follow the same group-per-version pattern. Each resource version creates a new group, with object IDs starting at zero for the content chunks, and a client reads a resource by fetching the latest group, then follows changes by subscribing, since each new group is an update. The Tasks extension lets a server answer with a durable task handle instead of blocking, and instead of polling, the client subscribes to the task state track and receives each change as it happens, through the states working, input_required, completed, failed, or cancelled.

The catalog deserves a sentence of its own, because it replaces the discovery round trips entirely. Its object zero is a JSON object with the members of the server discovery result, supported versions, capabilities, instructions, and the server's identity, together with the tools, resources, resource templates, and prompts.

The draft's example catalog lists supported version 2026-07-28, a ttlMs of 3,600,000, and a public cacheScope, and that ttlMs works out to 3,600 seconds, or exactly 60 minutes. A client that subscribes to the catalog track receives each change without polling.

How Does MCP over MOQT Survive a Dropped Connection?

Recovery is the draft's headline feature, and it works because a response lives in a known group rather than in a live connection. Losing the MOQT session does not cancel a request, because the server keeps the work running and keeps publishing the response into the same group, and it retains the response for a period of its choosing. When the client reconnects, it re-subscribes to the response track with a fill fetch, or fetches that group starting at the first object ID it has not received, and it receives the rest of the response, with neither side resending what the other already has.

Connection migration is the quieter half of the same story. If the underlying QUIC connection migrates, for example when a phone moves from Wi-Fi to mobile data, the MOQT session persists and nothing changes for MCP, because QUIC identifies connections by connection IDs that survive address changes. Only a full loss of the connection forces a reconnect, and even then the derived client ID means the client's scope, responses, and tasks are unchanged.

The fill fetch is the mechanism that makes the catch-up atomic. A client re-subscribing to a track should use a fill fetch, which issues a subscribe with fill parameters, and the publisher opens a one-way fill fetch stream carrying the historical range, typically the latest complete group, before live objects resume on the subscription.

There are limits, and the draft states them. A server retains responses and task state for a period of its choosing, and tasks follow the ttlMs of the MCP Tasks extension, so a response is not kept forever. A request whose response cannot be recovered should be treated as failed, and the client may retry it as a new request, which is an honest fallback rather than a guarantee.

What Do Relays Cache, and Why Does It Matter?

Relays are what turn a one-to-one protocol into a scalable one. When multiple subscribers subscribe to the same track, a relay keeps a single upstream subscription and fans the content out downstream, and a cached object serves later subscriptions and fetches without touching the server. Server-scope tracks are shared by all clients of a server, so one copy of the catalog, a public resource, or a skill at a relay serves every client behind it.

The publisher controls how long that caching lasts. A publisher sets a MAX_CACHE_DURATION track property, measured in milliseconds, after which a relay stops serving an object, and servers should set it on every track they publish. On server-scope tracks it should match the content's ttlMs, and on response and task state tracks it should cover at least the period for which the server retains responses and task state.

Edge serving is the practical payoff. A publisher tells relays how long they may cache each track's objects, so fetch and fill fetch requests, including a reconnecting client's catch-up, are answered by the nearest relay instead of the server. That is the difference between a server that answers the same tool list a thousand times and a server that publishes it once.

Relays do not get to list servers freely. A server that wants listing advertises its server scope to the relay, and a client asks for the list with a subscribe-namespace request, but a relay must refuse that request with an unauthorized error unless the client's token authorizes listing.

How Do Priorities Work in MCP over MOQT?

MOQT subscriber priorities run from zero to 255, and lower numbers mean higher priority, so the draft assigns each MCP track type to a band. Control, tools, prompts, tasks, and skill execution sit in the high band, the catalog and skills sit in the middle band, and resources sit in the low band. Applications may adjust priorities dynamically, for example by boosting skill loading while a user is actively waiting.

The arithmetic of the bands is worth noting. The high band holds 30 values, the medium band holds 60, and the low band holds 37, which adds up to 127 of the 256 possible priority values, or about half the range. The rest of the range stays free for future track types and for the PACE deployment mode, which uses different tiers, with standard operations at 96 to 127, discovery at 128 to 159, and bulk transfer at 192 to 255.

Priorities also explain why subgroups matter. Within a group, the server may spread a response over several subgroups, and each subgroup travels on its own QUIC stream, so a long result does not hold back progress notifications and loss on one stream does not block the others.

What Are Agent Skills over MOQT?

Agent skills over MOQT are the draft's second headline feature, and they address a different problem from tool calls. The draft defines Agent Skills as composed instructions that orchestrate multiple tools for complex tasks, and it draws the line plainly: tools are atomic and stateless, while skills are context-aware multi-step workflows. A tool does one thing, and a skill tells the model how to combine tools into a finished job.

Skills use progressive loading, which is where MOQT's object model earns its keep. A client reads the small metadata object first, and it fetches the instructions only when it decides to use the skill. That metadata carries the skill id and version, a description and triggers for when the skill applies, the required tools the instructions call, and a SHA-256 instructions hash, base64url-encoded, so the client can check the instructions it fetched.

Each skill version is a new group on the registry, metadata, and instructions tracks, and each version is immutable, so a relay can serve it to every client from cache. When a skill is updated, the server publishes a new group on the registry and on the skill's metadata and instructions tracks, and clients with active subscriptions receive the new version without polling. The draft's worked example is a user typing a commit command, after which the client matches the registry, fetches the commit skill's metadata and instructions from the relay cache, and the model follows the instructions with ordinary tool calls.

Two ways to run a skill exist, and the default needs no new MCP methods. In client-executed mode, the default, the client loads the skill's instructions and its model carries them out with ordinary MCP tool calls. In server-executed mode, which is optional, the client asks the server to run the skill with a skills invoke call, and the server reports progress and the result.

Support for skills is optional, and a server that offers them must publish the registry, metadata, and instructions tracks of each skill, and must support fetch on them.

Failures get their own error codes, four of them, numbered from minus 33001 to minus 33004, which sit outside the JSON-RPC reserved range. They cover a skill not found, a required tool unavailable, a dependency resolution failure, and a server-executed skill timing out, in which case the guidance is to retry or run the skill client-side. One distinction to keep straight is that the MCP-side skills extension, SEP-2640, is a separate mechanism from the draft's track-based distribution, and the two should not be conflated.

MCP over MOQT vs MQTT: Clearing Up the Name Confusion

The names invite confusion, and the search results prove it, because MQTT documentation keeps appearing next to MOQT drafts. MOQT is not MQTT, and the two protocols share only the publish-subscribe pattern and a similar-looking acronym. Saying the disambiguation once, clearly, saves a reader from a wrong turn that looks plausible.

MQTT was developed in 1999 for monitoring oil pipelines over a satellite link, and it became an OASIS standard with version 3.1.1 in November 2014, followed by version 5.0 on 7 March 2019. Its architecture centers on a message broker between publishers and subscribers, with topics that look like hierarchical paths. MOQT, by contrast, is an IETF draft built for low-latency delivery over QUIC, with relays that cache versioned objects rather than a broker that routes topic messages.

MCP over MOQT vs Streamable HTTP

The comparison with Streamable HTTP is the one that decides whether the draft is worth following, so it deserves a direct table. The two transports solve the same problem, which is carrying MCP messages between a client and a remote server, and they differ in almost every mechanism that matters once a connection is under stress.

Readers will also meet the reversed form, MOQT MCP, in search results and draft discussions, and it means the same mapping. The status row is the one that matters most, because Streamable HTTP is the transport you can use today, while MCP over MOQT is a proposal you can follow and comment on. Nothing in the draft replaces the current transports, and no implementation exists yet, so the honest reading is that this is a direction, not a migration.

The trade is therefore clear. Streamable HTTP wins on availability, because it is standardized, implemented in every MCP SDK, and deployable behind any HTTP infrastructure.

MCP over MOQT wins on paper for the cases the draft targets, which are dropped connections, many clients sharing public content, and mixed-priority traffic on one session. Until an implementation and measurements exist, that second column stays a claim rather than a result.

Who Should Care About MCP over MOQT, and Who Should Wait?

Developers building MCP servers and clients should care first, because a third transport changes how they think about sessions, recovery, and caching. Agent-platform teams come next, because the relay model lets one published tool list serve thousands of clients, and the per-tool track pairs give them namespace-level authorization for free. Mobile agent developers should watch closely too, because QUIC connection migration is the property that keeps a session alive when a device changes networks.

Everyone else should wait, and the draft's own status is the reason. It is an Experimental Internet-Draft, not an adopted standard and not part of the MCP specification, and it expires on 5 May 2027, which is 185 days after its 1 November 2026 publication, the usual six-month lifetime.

The draft's history shows how fast it moves: the predecessor draft appeared on 2 March 2026 and expired on 3 September 2026, the agentproto revision zero followed on 6 July 2026, and revision one landed 118 days later, on 1 November 2026. A reader who builds on it today should expect revision two to change details.

The draft does not stand alone, because it is one of several drafts in the proposed Agent Communication Protocols working group, whose charter is still under IESG review. PACE, published 1 November 2026, is a dialog-management protocol over MOQT that can carry MCP bindings inside a dialog, while A-SIP, published 2 November 2026, handles session establishment and lifecycle, and TRAIL, also published 2 November 2026, adds tamper-evident audit records with HTTP and MOQT bindings. The MCP over MOQT draft can run standalone or inside a PACE dialog, using the same tracks and the same message handling, with only the namespaces changed.

The most likely first users are the people already living in MCP clients every day. How to use Claude Code is the natural starting point, because Claude Code is one of the best-known MCP clients, and its users are the first audience for a transport that survives network changes. Agents that run code in sandboxes, such as the ones you can build when you learn how to use E2B, are the workloads that would feel the difference first, because a long-running agent task is exactly the request that should outlive its connection.

Sources

IETF Internet-Draft draft-jennings-agentproto-mcp-over-moqt-01, Model Context Protocol and Agent Skills over Media over QUIC Transport, by Cullen Fluffy Jennings, Ian Swett, Jonathan Rosenberg, and Suhas Nandakumar, published 1 November 2026, 43 pages, intended status Experimental, expires 5 May 2027, datatracker.ietf.org. IETF Internet-Draft draft-ietf-moq-transport-23, Media over QUIC Transport, by Suhas Nandakumar, Victor Vasiliev, Ian Swett, and Alan Frindell, dated 2 November 2026, Standards Track, moq-wg.github.io. Model Context Protocol specification, Transports, modelcontextprotocol.io, page updated 30 October 2026, describing the stdio and Streamable HTTP transports and the 2026-07-28 stateless revision.

QUIC, RFC 9000, IETF, May 2021, with background on streams, connection migration, and TLS 1.3. MQTT, Wikipedia and IEEE Technology Navigator, covering the 1999 invention, OASIS standardization in November 2014, and version 5.0 of 7 March 2019. MOQ Edge draft tracker, Model Context Protocol and Agent Skills over Media over QUIC Transport rev 01 lands on the IETF Datatracker, 1 November 2026, the only independent mention found.

Frequently Asked Questions

Is MCP over MOQT an official MCP transport?

No, it is not. MCP over MOQT is an Experimental Internet-Draft in the IETF, published 1 November 2026 and expiring 5 May 2027, and it is not part of the MCP specification, which defines only stdio and Streamable HTTP as standard transports. It may become a standard, or it may be revised or abandoned, and that is the normal fate of an Internet-Draft.

What is the difference between MOQT and MQTT?

MOQT is Media over QUIC Transport, an IETF draft that runs publish-subscribe delivery over QUIC with tracks, groups, objects, and relays. MQTT is Message Queuing Telemetry Transport, an IoT protocol invented in 1999 that runs over TCP with a broker and hierarchical topics, and it has been an OASIS and ISO standard since 2014. They share only the publish-subscribe pattern and a similar-looking name.

Does MCP over MOQT replace Streamable HTTP?

No, and the draft does not claim that it does. Streamable HTTP remains the standard remote MCP transport, implemented in every MCP SDK, while MCP over MOQT is a proposal for cases where connections drop, many clients share public content, or traffic needs per-message priorities. No implementation or performance measurement exists yet, so any replacement talk is premature.

What are Agent Skills over MOQT?

Agent Skills are composed instructions that orchestrate multiple tools for complex tasks, while tools are atomic and stateless. Over MOQT, a skill's metadata loads first and its instructions load only when the client decides to use the skill, with each version stored as an immutable, relay-cacheable group. The default is client-executed, and a server-executed mode through a skills invoke call is optional.

When will MCP over MOQT be ready to use?

There is no date, and no implementation was found at the time of writing. The draft is four days old, the working group behind it is still proposed with its charter under review, and the next revision may change track layouts, priorities, or the skills model. Developers who want to follow it should watch the datatracker for revision two and the agentproto mailing list for discussion.