Model Context Protocol and Agent Skills over Media over QUIC Transport
draft-jennings-agentproto-mcp-over-moqt-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Cullen Fluffy Jennings , Ian Swett , Jonathan Rosenberg , Suhas Nandakumar | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jennings-agentproto-mcp-over-moqt-00
Model Context Protocol C. Jennings
Internet-Draft cisco
Intended status: Experimental I. Swett
Expires: 7 January 2027 Google
J. Rosenberg
Five9
S. Nandakumar
Cisco Systems
6 July 2026
Model Context Protocol and Agent Skills over Media over QUIC Transport
draft-jennings-agentproto-mcp-over-moqt-00
Abstract
This document defines how to use Media over QUIC Transport (MOQT) as
the underlying transport protocol for the Model Context Protocol
(MCP). MCP enables integration between language model applications
and external data sources and tools. MOQT provides publish-subscribe
delivery over QUIC and WebTransport with native prioritization, relay
caching, and multiplexing.
This specification maps MCP messages onto MOQT objects and defines
procedures for session establishment, capability discovery, and
ongoing communication. It covers MCP's core primitives (resources,
tools, prompts, sampling, and notifications) through dedicated MOQT
tracks.
The document also describes Agent Skills -- composed instructions
that extend AI capabilities beyond atomic tool operations -- using
progressive loading aligned with MOQT's object-based delivery.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://example.org/mcp-moqt/. Status information for this document
may be found at https://datatracker.ietf.org/doc/draft-jennings-
agentproto-mcp-over-moqt/.
Discussion of this document takes place on the Model Context Protocol
Working Group mailing list (mailto:mcp@example.org), which is
archived at https://example.org/mcp/.
Source for this draft and an issue tracker can be found at
https://github.com/example/mcp-moqt.
Jennings, et al. Expires 7 January 2027 [Page 1]
Internet-Draft MCP over MOQT July 2026
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5
1.2.1. MCP Lifecycle State Chart . . . . . . . . . . . . . . 5
1.2.2. System Components . . . . . . . . . . . . . . . . . . 6
2. MOQT Tracks for MCP . . . . . . . . . . . . . . . . . . . . . 7
2.1. Control Tracks . . . . . . . . . . . . . . . . . . . . . 7
2.2. Resource Tracks . . . . . . . . . . . . . . . . . . . . . 8
2.3. Tool Tracks . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Prompt Tracks . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Sampling Tracks . . . . . . . . . . . . . . . . . . . . . 9
2.6. Notification Tracks . . . . . . . . . . . . . . . . . . . 9
2.7. Elicitation Tracks . . . . . . . . . . . . . . . . . . . 10
2.8. Task Tracks . . . . . . . . . . . . . . . . . . . . . . . 10
2.9. Log Tracks . . . . . . . . . . . . . . . . . . . . . . . 11
Jennings, et al. Expires 7 January 2027 [Page 2]
Internet-Draft MCP over MOQT July 2026
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 11
3.1. MOQT Session Establishment . . . . . . . . . . . . . . . 11
3.2. Session Discovery . . . . . . . . . . . . . . . . . . . . 11
3.2.1. Discovery Flow . . . . . . . . . . . . . . . . . . . 11
3.2.2. Discovery Request . . . . . . . . . . . . . . . . . . 12
3.2.3. Discovery Response . . . . . . . . . . . . . . . . . 13
3.3. Session Resumption . . . . . . . . . . . . . . . . . . . 15
3.4. Priority Management . . . . . . . . . . . . . . . . . . . 15
3.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 15
3.5.1. Transport-Level Errors . . . . . . . . . . . . . . . 15
3.5.2. Subscription Lifecycle . . . . . . . . . . . . . . . 16
3.5.3. MCP-Level Errors . . . . . . . . . . . . . . . . . . 16
3.5.4. Skills-Specific Errors . . . . . . . . . . . . . . . 17
3.5.5. Error Recovery . . . . . . . . . . . . . . . . . . . 17
4. Capability Discovery . . . . . . . . . . . . . . . . . . . . 17
4.1. Discovery Catalog Track . . . . . . . . . . . . . . . . . 18
4.2. Namespace-Based Discovery . . . . . . . . . . . . . . . . 18
4.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 18
5. Relay Support . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Subscription Aggregation . . . . . . . . . . . . . . . . 19
5.2. Content Caching . . . . . . . . . . . . . . . . . . . . . 19
5.3. Relay Namespace Aggregation . . . . . . . . . . . . . . . 19
6. Agent Skills . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Skills Overview . . . . . . . . . . . . . . . . . . . . . 20
6.2. Skills Track Structure . . . . . . . . . . . . . . . . . 20
6.3. Invocation Flow . . . . . . . . . . . . . . . . . . . . . 21
6.4. Execution Request and Response . . . . . . . . . . . . . 22
6.5. Relay Caching for Skills . . . . . . . . . . . . . . . . 22
7. Multi-Server Operation . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8.1. Transport Security . . . . . . . . . . . . . . . . . . . 23
8.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 23
8.3. Session ID Confidentiality . . . . . . . . . . . . . . . 23
8.4. Relay Trust Model . . . . . . . . . . . . . . . . . . . . 23
8.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 24
8.6. Cross-Server Context Leakage . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Basic Session Establishment . . . . . . . . . . . . . . 24
10.2. Tool Execution . . . . . . . . . . . . . . . . . . . . . 25
10.3. Skill Invocation . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
Jennings, et al. Expires 7 January 2027 [Page 3]
Internet-Draft MCP over MOQT July 2026
1. Introduction
The Model Context Protocol (MCP) [MCP] enables integration between
LLM applications and external data sources using JSON-RPC 2.0 over
pluggable transports. Media over QUIC Transport (MOQT) [MOQT]
provides publish-subscribe delivery over QUIC [QUIC] with relay
support.
MCP's existing transports have limitations that MOQT addresses:
* *Streamable HTTP*: Request-response model requires polling for
server-initiated events; no native prioritization or relay caching
* *stdio*: Single-process only; no network distribution
MOQT provides:
* Native publish-subscribe: MCP primitives map to tracks with
independent lifecycle and versioning
* Priority-aware delivery: Critical operations receive appropriate
bandwidth via per-object priorities
* Multiplexing without HOL blocking: QUIC streams prevent
interference between concurrent operations
* Relay infrastructure: Subscription aggregation and caching at edge
* Network resilience: QUIC connection migration and 0-RTT resumption
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses terminology from [MCP] and [MOQT]. Additionally:
* Track namespace: An ordered tuple of byte strings identifying a
content namespace in MOQT, written as (elem1, elem2, ...) in
normative definitions and as elem1/elem2/... in prose and
examples.
* Track name: A byte string identifying a specific track within a
namespace.
Jennings, et al. Expires 7 January 2027 [Page 4]
Internet-Draft MCP over MOQT July 2026
1.2. Protocol Overview
Each MCP JSON-RPC 2.0 message is encoded as the payload of a single
MOQT object. One JSON-RPC message corresponds to exactly one MOQT
object; there is no additional framing beyond the MOQT object
boundaries. The payload is UTF-8 encoded JSON.
MCP primitives map to dedicated MOQT tracks: control, resources,
tools, prompts, sampling, notifications, elicitation, tasks, logs,
and skills. Sessions begin with MOQT setup, session discovery via
FETCH, MCP capability negotiation, then ongoing pub-sub communication
on the established tracks.
1.2.1. MCP Lifecycle State Chart
Jennings, et al. Expires 7 January 2027 [Page 5]
Internet-Draft MCP over MOQT July 2026
┌─────────────┐
│ DISCONNECTED│
└──────┬──────┘
│ QUIC Connect
▼
┌─────────────┐
│ MOQT │
│ ESTABLISHED │
└──────┬──────┘
│ FETCH Discovery
▼
┌─────────────┐
│ SESSION │
│ DISCOVERED │
└──────┬──────┘
│ Subscribe Control +
│ MCP Initialize
▼
┌─────────────┐
┌──────────▶│ MCP ACTIVE │◀──────────┬──────────┐
│ │ │ │ │
│ └──┬───┬───┬──┘ │ │
│ │ │ │ │ │
│ Tool Result │ │ │ Notification │ │ Skill
│ │ │ │ │ │ Complete
▼ │ │ ▼ │ │
┌─────────────┐ │ │ ┌─────────────┐ │ ┌──────┴──────┐
│ TOOL │ │ │ │ ELICITATION │ │ │ SKILL │
│ EXECUTING │───────┘ │ │ PENDING │ │ │ EXECUTING │
└─────────────┘ │ └─────────────┘ │ └─────────────┘
│ │ │
│ │ │
└───────┴──────────┘
│
▼
┌─────────────┐
│ DISCONNECTED│
└─────────────┘
1.2.2. System Components
Jennings, et al. Expires 7 January 2027 [Page 6]
Internet-Draft MCP over MOQT July 2026
┌─────────────────┐ MOQT Session ┌─────────────────┐
│ MCP Client │<==================>│ MCP Server │
│ │ │ │
│ ┌─────────────┐ │ │ ┌─────────────┐ │
│ │MCP Transport│ │ │ │MCP Transport│ │
│ │ Adapter │ │ │ │ Adapter │ │
│ └─────────────┘ │ │ └─────────────┘ │
│ ┌─────────────┐ │ │ ┌─────────────┐ │
│ │ MOQT │ │ │ │ MOQT │ │
│ │ Endpoint │ │ │ │ Endpoint │ │
│ └─────────────┘ │ │ └─────────────┘ │
└─────────────────┘ └─────────────────┘
The MCP client-host-server architecture maps to MOQT as follows:
* MCP Host: Acts as MOQT client, managing multiple server
connections
* MCP Client: Implemented as MCP transport adapter within the host
* MCP Server: Acts as MOQT publisher, exposing resources, tools, and
prompts
2. MOQT Tracks for MCP
This section defines the track namespace structure for each MCP
primitive. All tracks use the namespace prefix (mcp, <session-id>)
followed by a type-specific suffix. Session IDs are obtained through
the discovery mechanism defined in Section 3.2.
2.1. Control Tracks
Two unidirectional control tracks carry MCP session management:
initialize requests/responses, ping/pong, capability negotiation, and
session teardown.
Track namespace: (mcp, <session-id>, control)
Jennings, et al. Expires 7 January 2027 [Page 7]
Internet-Draft MCP over MOQT July 2026
+==================+====================+===========+==============+
| Direction | Track Name | Publisher | Content |
+==================+====================+===========+==============+
| Client-to-Server | (client-to-server) | MCP | initialize, |
| | | Client | ping, tool |
| | | | cancellation |
+------------------+--------------------+-----------+--------------+
| Server-to-Client | (server-to-client) | MCP | initialize |
| | | Server | response, |
| | | | pong, status |
+------------------+--------------------+-----------+--------------+
Table 1
Each control message maps to one MOQT object in its own group. Group
IDs increment sequentially from 0. Object ID is always 0.
2.2. Resource Tracks
Resource tracks deliver server-published content (files, API schemas,
database results) that MCP exposes as read-only data sources.
Track namespace: (mcp, <session-id>, resources) Track name:
(<resource-uri>)
Each resource version creates a new group (IDs incrementing from 0).
Within a group, objects represent chunks of the resource content
(object IDs starting at 0). This enables streaming delivery of large
resources and version-based caching at relays.
2.3. Tool Tracks
Tool tracks carry tool invocation requests and responses using MOQT's
Standalone Fetch. Each tool invocation is a request-response pair.
Track namespace: (mcp, <session-id>, tools) Track name: (<tool-name>)
Each invocation creates a new group. Object 0 contains the tool
request (JSON-RPC tools/call). Subsequent objects contain the
response and any progress notifications. Tools defining an
outputSchema include structured results in the structuredContent
field alongside the content array.
2.4. Prompt Tracks
Prompt tracks distribute pre-defined templates that standardize
common operations.
Jennings, et al. Expires 7 January 2027 [Page 8]
Internet-Draft MCP over MOQT July 2026
Track namespace: (mcp, <session-id>, prompts) Track name: (<prompt-
name>)
Each prompt version is a new group. Object 0 contains the prompt
template with parameter schemas and metadata.
2.5. Sampling Tracks
Sampling tracks carry server-initiated LLM completion requests. MCP
allows servers to request that the client perform an LLM inference
(text, audio, or image generation), optionally with tool use in a
multi-turn loop.
Track namespace: (mcp, <session-id>, sampling)
+==================+============+============+===============+
| Direction | Track Name | Publisher | Content |
+==================+============+============+===============+
| Server-to-Client | (request) | MCP Server | createMessage |
| | | | requests |
+------------------+------------+------------+---------------+
| Client-to-Server | (response) | MCP Client | completion |
| | | | results |
+------------------+------------+------------+---------------+
Table 2
Each sampling request creates a new group on the request track. The
client publishes the corresponding response on the response track
using the same group ID. When multi-turn tool loops are involved,
subsequent objects within the group carry intermediate tool calls and
results.
2.6. Notification Tracks
Notification tracks provide asynchronous event delivery for server-
sent events.
Track namespace: (mcp, <session-id>, notifications) Track name:
(<category>)
Standard categories:
* progress - Tool/task execution progress
* resources - Resource change notifications (listChanged, updated)
* prompts - Prompt availability changes
Jennings, et al. Expires 7 January 2027 [Page 9]
Internet-Draft MCP over MOQT July 2026
* tools - Tool availability changes
* tasks - Task state transitions
* system - Server status and error conditions
Custom categories use the pattern <domain>/<type>.
Each notification creates a new group with a single object (ID 0)
containing the JSON-RPC notification message.
2.7. Elicitation Tracks
Elicitation tracks handle server-initiated user input collection.
MCP supports Form mode (structured data via JSON Schema) and URL mode
(redirect to external URL for sensitive operations like OAuth).
Track namespace: (mcp, <session-id>, elicitation, <request-id>)
+==================+============+===========+======================+
| Direction | Track Name | Publisher | Content |
+==================+============+===========+======================+
| Server-to-Client | (request) | MCP | elicitation request |
| | | Server | (form schema or URL) |
+------------------+------------+-----------+----------------------+
| Client-to-Server | (response) | MCP | user response |
| | | Client | (accept/decline/ |
| | | | cancel) |
+------------------+------------+-----------+----------------------+
Table 3
Each elicitation exchange uses a unique <request-id>, creating
isolated track pairs for concurrent operations. Group IDs increment
for each message in the exchange.
2.8. Task Tracks
Task tracks carry status updates for MCP Tasks -- durable state
machines wrapping long-running tool calls or sampling requests.
Track namespace: (mcp, <session-id>, tasks) Track name: (<task-id>)
Each task state transition creates a new group. Object 0 contains
the task status: working, input_required, completed, failed, or
cancelled. Clients subscribe to receive push updates, avoiding the
need to poll via tasks/get.
Jennings, et al. Expires 7 January 2027 [Page 10]
Internet-Draft MCP over MOQT July 2026
2.9. Log Tracks
Log tracks carry diagnostic information for monitoring and
troubleshooting.
Track namespace: (mcp, <session-id>, logs) Track name: (<level>)
Standard levels: error, warn, info, debug, trace. Component-specific
categories use <level>/<component> (e.g., error/transport).
Each log entry is a single object in its own group.
3. Protocol Operation
3.1. MOQT Session Establishment
The session begins with a QUIC connection or WebTransport
[WebTransport] session, followed by the MOQT handshake (CLIENT_SETUP
and SERVER_SETUP) to negotiate protocol versions and Setup Options.
This specification requires MOQT draft-18 or later. Implementations
MUST support Standalone Fetch, SUBSCRIBE_NAMESPACE,
PUBLISH_NAMESPACE, SUBSCRIBE_TRACKS, bidirectional subscription
initiation, and authorization tokens.
MCP endpoints MAY be identified using the moqt:// URI scheme defined
in [MOQT]. All namespaces whose first tuple element begins with a
period (0x2e) are reserved by MOQT; MCP implementations MUST NOT use
such prefixes.
Implementations SHOULD use MOQT's authorization token mechanism for
per-track access control, attaching tokens to subscription and fetch
requests.
3.2. Session Discovery
Clients discover MCP sessions and obtain session IDs through a well-
known discovery track.
Track namespace: (mcp, discovery) Track name: (sessions)
3.2.1. Discovery Flow
Jennings, et al. Expires 7 January 2027 [Page 11]
Internet-Draft MCP over MOQT July 2026
Client Server
│ │
│ FETCH (mcp,discovery)/ │
│ sessions │
│────────────────────────────▶│
│ │ Generate session ID
│ Object: session details │
│◀────────────────────────────│
│ │
│ SUBSCRIBE control tracks │
│────────────────────────────▶│
│ │
│ MCP Initialize (on control) │
│────────────────────────────▶│
│ │
│ Initialize Response │
│◀────────────────────────────│
│ │
│ MCP Active │
│────────────────────────────▶│
Clients MAY combine discovery and MCP initialization in a single
FETCH to reduce round-trips from 4 to 2. In this case the FETCH
object payload includes both the discovery request and the initialize
message, and the response object includes both session details and
the initialize response.
3.2.2. Discovery Request
The client sends a Standalone Fetch to the well-known discovery
track. The MOQT object payload (delivered on the response stream)
contains the request:
{
"jsonrpc": "2.0",
"id": 1,
"method": "discovery/request_session",
"params": {
"client_nonce": "client-nonce-abc123",
"client_info": {
"name": "ExampleClient",
"version": "1.0.0"
},
"requested_capabilities": ["resources", "tools", "prompts"]
}
}
Jennings, et al. Expires 7 January 2027 [Page 12]
Internet-Draft MCP over MOQT July 2026
For the combined flow, use method discovery/request_session_with_init
and include an mcp_initialize field:
{
"jsonrpc": "2.0",
"id": 1,
"method": "discovery/request_session_with_init",
"params": {
"client_nonce": "client-nonce-abc123",
"client_info": {
"name": "ExampleClient",
"version": "1.0.0"
},
"requested_capabilities": ["resources", "tools", "prompts"],
"mcp_initialize": {
"protocolVersion": "2025-11-25",
"capabilities": {
"roots": { "listChanged": true },
"sampling": { "tools": true },
"elicitation": { "form": true, "url": true },
"tasks": {}
},
"clientInfo": {
"name": "ExampleClient",
"version": "1.0.0"
}
}
}
}
3.2.3. Discovery Response
Jennings, et al. Expires 7 January 2027 [Page 13]
Internet-Draft MCP over MOQT July 2026
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"session_id": "session-uuid-456",
"server_info": {
"name": "ExampleServer",
"version": "2.0.0",
"protocol_version": "2025-11-25"
},
"control_tracks": {
"client_to_server":
"mcp/session-uuid-456/control/client-to-server",
"server_to_client":
"mcp/session-uuid-456/control/server-to-client"
},
"session_namespace": "mcp/session-uuid-456",
"session_expires": "2026-06-27T12:00:00Z"
}
}
When the combined flow is used, the response additionally includes
mcp_initialize_response:
{
"mcp_initialize_response": {
"protocolVersion": "2025-11-25",
"capabilities": {
"resources": { "subscribe": true, "listChanged": true },
"tools": { "listChanged": true },
"prompts": { "listChanged": true },
"logging": {},
"tasks": {}
},
"serverInfo": {
"name": "ExampleServer",
"version": "2.0.0"
}
}
}
Jennings, et al. Expires 7 January 2027 [Page 14]
Internet-Draft MCP over MOQT July 2026
3.3. Session Resumption
If the underlying QUIC connection migrates (e.g., network change on a
mobile device), the MOQT session persists and no MCP re-
initialization is required. If the QUIC connection is lost entirely,
the client SHOULD attempt to reconnect and re-FETCH the discovery
track using the same client_nonce. Servers MAY return the same
session ID if the previous session has not expired, allowing the
client to resume subscriptions without full re-initialization.
In-flight tool calls or task operations that were interrupted SHOULD
be treated as failed by the client. The client MAY retry them on the
re-established session.
3.4. Priority Management
MOQT subscriber priorities (0-255, lower is higher priority) optimize
MCP message delivery:
+==========+========+====================+=======================+
| Priority | Range | Track Type | Example |
+==========+========+====================+=======================+
| CRITICAL | 1-5 | Session Control | initialize, terminate |
+----------+--------+--------------------+-----------------------+
| HIGH | 6-30 | Elicitation, Tools | permission prompts |
+----------+--------+--------------------+-----------------------+
| MEDIUM | 31-60 | Notifications | resource changes |
+----------+--------+--------------------+-----------------------+
| LOW | 61-90 | Resources, Prompts | documentation |
+----------+--------+--------------------+-----------------------+
| LOWEST | 91-127 | Logs | debug, trace |
+----------+--------+--------------------+-----------------------+
Table 4
Applications MAY dynamically adjust priorities based on user
interaction state (e.g., boosting skill loading when a user is
actively waiting).
3.5. Error Handling
3.5.1. Transport-Level Errors
MOQT error mechanisms relevant to MCP:
* REQUEST_ERROR: Subscription or publish request failed (invalid
session ID, unauthorized access, non-existent resource).
Jennings, et al. Expires 7 January 2027 [Page 15]
Internet-Draft MCP over MOQT July 2026
* FETCH_ERROR: Standalone or Joining Fetch failed at the transport
level.
* GOAWAY: Server is terminating. Clients SHOULD reconnect and re-
establish the MCP session.
Additional MOQT error codes:
+====================+==================+====================+
| Code | Meaning | MCP Recovery |
+====================+==================+====================+
| DELIVERY_TIMEOUT | Object delivery | Retry the |
| | exceeded timeout | operation |
+--------------------+------------------+--------------------+
| SESSION_CLOSED | Normal session | Reconnect if |
| | termination | needed |
+--------------------+------------------+--------------------+
| TOO_FAR_BEHIND | Subscriber | Reduce |
| | cannot keep up | subscription scope |
+--------------------+------------------+--------------------+
| EXPIRED_AUTH_TOKEN | Auth token | Re-authenticate |
| | expired | and retry |
+--------------------+------------------+--------------------+
| EXCESSIVE_LOAD | Server | Back off with |
| | overloaded | exponential delay |
+--------------------+------------------+--------------------+
Table 5
3.5.2. Subscription Lifecycle
PUBLISH_DONE indicates the publisher has finished sending objects for
a subscription. This is not an error. Clients SHOULD re-subscribe
if the content is expected to continue (e.g., a resource that
receives periodic updates).
3.5.3. MCP-Level Errors
MCP errors are JSON-RPC error responses within MOQT objects:
Jennings, et al. Expires 7 January 2027 [Page 16]
Internet-Draft MCP over MOQT July 2026
{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": -32601,
"message": "Method not found",
"data": { "details": "Tool 'unknown_tool' not found" }
}
}
Standard JSON-RPC error codes: -32700 (parse error), -32600 (invalid
request), -32601 (method not found), -32602 (invalid params), -32603
(internal error).
3.5.4. Skills-Specific Errors
+============+===================+===============================+
| Error Code | Description | Recovery Action |
+============+===================+===============================+
| -33001 | Skill not found | Check registry, refresh cache |
+------------+-------------------+-------------------------------+
| -33002 | Required tool | Verify tool server |
| | unavailable | connectivity |
+------------+-------------------+-------------------------------+
| -33003 | Dependency | Check skill dependencies |
| | resolution failed | |
+------------+-------------------+-------------------------------+
| -33004 | Instruction load | Retry with higher priority |
| | timeout | |
+------------+-------------------+-------------------------------+
Table 6
3.5.5. Error Recovery
1. Transient errors: Retry with exponential backoff
2. Session errors: Re-establish via discovery
3. Resource errors: Invalidate cache and re-fetch
4. Skill errors: Fall back to direct tool operations
4. Capability Discovery
After session establishment, clients discover available resources,
tools, and prompts through two complementary mechanisms.
Jennings, et al. Expires 7 January 2027 [Page 17]
Internet-Draft MCP over MOQT July 2026
4.1. Discovery Catalog Track
Servers publish a catalog track enumerating available capabilities:
Track namespace: (mcp, <session-id>, discovery) Track name: (catalog)
{
"resources": ["documentation", "api_schemas", "examples"],
"tools": ["file_operations", "database_query", "code_analysis"],
"prompts": ["code_review", "data_analysis"],
"tasks_supported": true
}
Clients FETCH the catalog for one-time discovery, or SUBSCRIBE for
real-time updates when capabilities change.
4.2. Namespace-Based Discovery
MOQT's SUBSCRIBE_NAMESPACE discovers available tracks under a prefix
without prior knowledge of track names. SUBSCRIBE_TRACKS combines
discovery and subscription, requesting the publisher send PUBLISH
messages for matching tracks.
SUBSCRIBE_NAMESPACE {
Request ID (i) = 1,
Track Namespace = ("mcp", "<session-id>", "resources")
}
The server responds with NAMESPACE messages for each available track,
followed by NAMESPACE_DONE.
Servers use PUBLISH_NAMESPACE to announce new track availability.
Relays forward these announcements to clients with active namespace
subscriptions.
4.3. Dynamic Updates
When capabilities change during a session (tools added/removed,
resources updated), servers either:
* Publish a new catalog object on the discovery track, or
* Send PUBLISH_NAMESPACE for the new track
Clients with active subscriptions receive updates automatically.
Jennings, et al. Expires 7 January 2027 [Page 18]
Internet-Draft MCP over MOQT July 2026
5. Relay Support
MOQT relays enable scalable MCP deployments through subscription
aggregation and content caching.
5.1. Subscription Aggregation
When multiple clients subscribe to the same track, relays maintain a
single upstream subscription and fan out content downstream. This
applies to resource subscriptions, notification streams, and skill
registry updates.
5.2. Content Caching
Relays cache content based on update frequency:
+=============================+==================================+
| Content Type | Cache Strategy |
+=============================+==================================+
| Resources (docs, schemas) | Long TTL, version-keyed |
+-----------------------------+----------------------------------+
| Tool schemas | Until explicitly invalidated |
+-----------------------------+----------------------------------+
| Skill registry/instructions | Version-keyed, push invalidation |
+-----------------------------+----------------------------------+
| Capability catalog | Until session restart |
+-----------------------------+----------------------------------+
| Notifications, tool results | Not cached (ephemeral) |
+-----------------------------+----------------------------------+
Table 7
5.3. Relay Namespace Aggregation
Relays aggregate namespace information from multiple upstream
servers, presenting a unified view to downstream clients:
Jennings, et al. Expires 7 January 2027 [Page 19]
Internet-Draft MCP over MOQT July 2026
Client Relay Server A Server B
│ │ │ │
│ SUBSCRIBE_NAMESPACE │ │ │
│ ("mcp","unified", │ │ │
│ "tools") │ │ │
│───────────────────────▶│ │ │
│ │ SUBSCRIBE_NAMESPACE │ │
│ │────────────────────▶│ │
│ │ SUBSCRIBE_NAMESPACE │ │
│ │───────────────────────────────▶│
│ │ │ │
│ │◀────────────────────│ │
│ │◀───────────────────────────────│
│ │ │ │
│ NAMESPACE (aggregated) │ │ │
│◀───────────────────────│ │ │
│ NAMESPACE_DONE │ │ │
│◀───────────────────────│ │ │
6. Agent Skills
Agent Skills are composed instructions that orchestrate multiple
tools for complex tasks. Skills are an application-layer construct
built on MCP's primitives (tools, prompts, resources) rather than a
protocol-level MCP feature. Long-running skills leverage MCP Tasks
for durable status tracking.
6.1. Skills Overview
Skills complement tools: tools are atomic and stateless, while skills
are context-aware multi-step workflows. Skills use progressive
loading:
* Metadata (~100 tokens): ID, triggers, dependencies
* Instructions (<5k tokens): Full prompt and execution logic
* Resources: Templates and schemas loaded during execution
Support for Skills is OPTIONAL. Servers advertising skills MUST
implement the skills registry track and support FETCH for metadata
and instructions. Clients SHOULD cache by version.
6.2. Skills Track Structure
Track namespace: (mcp, <session-id>, skills)
Jennings, et al. Expires 7 January 2027 [Page 20]
Internet-Draft MCP over MOQT July 2026
+=========================+========================================+
| Track Name | Purpose |
+=========================+========================================+
| (registry) | Complete skill catalog |
+-------------------------+----------------------------------------+
| (<skill-id>, metadata) | Identification, triggers, dependencies |
+-------------------------+----------------------------------------+
| (<skill-id>, | Full prompt and execution logic |
| instructions) | |
+-------------------------+----------------------------------------+
| (<skill-id>, execution, | Streaming execution state |
| <invocation-id>) | |
+-------------------------+----------------------------------------+
Table 8
6.3. Invocation Flow
Client Relay Origin
│ │ │
│ User types: "/commit" │ │
│ (Match cached registry) │
│ │ │
│ FETCH skills/commit/ │ │
│ metadata │ │
│───────────────────────▶│ [CACHE HIT] │
│ Object: {version,deps} │ │
│◀───────────────────────│ │
│ │ │
│ FETCH skills/commit/ │ │
│ instructions │ │
│───────────────────────▶│ [CACHE HIT] │
│ Object: {instructions} │ │
│◀───────────────────────│ │
│ │ │
│ (AI executes instructions via tool calls) │
│ │ │
│ FETCH tools/git/status │ │
│───────────────────────▶│───────────────────────▶│
│◀───────────────────────│◀───────────────────────│
│ │ │
│ FETCH tools/git/commit │ │
│───────────────────────▶│───────────────────────▶│
│◀───────────────────────│◀───────────────────────│
Jennings, et al. Expires 7 January 2027 [Page 21]
Internet-Draft MCP over MOQT July 2026
6.4. Execution Request and Response
Request (published on execution track):
{
"jsonrpc": "2.0",
"id": "exec-001",
"method": "skills/invoke",
"params": {
"skill_id": "commit",
"invocation_id": "inv-xyz789",
"parameters": { "push": false },
"context": {
"working_directory": "/home/user/project",
"git_state": { "branch": "feature/auth", "has_staged": true }
},
"options": { "stream_progress": true, "timeout_ms": 60000 }
}
}
Response stream (successive objects in the execution track group):
Object 0 -- Acknowledgment:
{"jsonrpc":"2.0","id":"exec-001","result":{"status":"accepted","invocation_id":"inv-xyz789"}}
Object 1 -- Progress:
{"jsonrpc":"2.0","method":"skills/progress","params":{"invocation_id":"inv-xyz789","step":1,"total_steps":3,"message":"Checking status..."}}
Object 2 -- Completion:
{"jsonrpc":"2.0","id":"exec-001","result":{"status":"completed","output":{"commit_sha":"abc123","message":"Add auth flow"}}}
6.5. Relay Caching for Skills
Skills content is versioned and immutable, making it highly
cacheable. Relays cache metadata and instructions keyed by version.
When a skill is updated at the origin, the new version propagates
through the relay hierarchy via push invalidation. Clients with
active registry subscriptions receive updates automatically.
7. Multi-Server Operation
When a client connects to multiple MCP servers, each connection
maintains its own session ID and track namespace:
Jennings, et al. Expires 7 January 2027 [Page 22]
Internet-Draft MCP over MOQT July 2026
Server A: mcp/session-a/resources/documentation
Server B: mcp/session-b/tools/code_analysis
Server C: mcp/session-c/prompts/review_templates
The client coordinates across sessions by:
* Subscribing to related resource tracks from multiple servers and
selecting sources based on freshness or performance
* Passing tool results from one server as input to tools on another
* Failing over to alternative servers when one becomes unavailable
No cross-server state sharing occurs at the protocol level; the
client is responsible for coordination.
8. Security Considerations
8.1. Transport Security
All MCP over MOQT communication MUST use TLS 1.3 (via QUIC) or an
equivalent security mechanism. Plaintext communication is not
permitted.
8.2. Authorization
Implementations SHOULD use MOQT's authorization token mechanism to
control access to individual tracks. Tokens SHOULD be scoped to
specific track namespaces or patterns (e.g., a token granting access
to mcp/<session-id>/tools/* but not mcp/<session-id>/logs/*). Tokens
MUST have bounded lifetimes; servers MUST reject expired tokens with
EXPIRED_AUTH_TOKEN.
8.3. Session ID Confidentiality
Session IDs MUST be generated with sufficient entropy (at least 128
bits) to prevent guessing. Session IDs SHOULD NOT be logged in
cleartext or exposed to third parties, as knowledge of a session ID
permits subscription to that session's tracks (subject to
authorization).
8.4. Relay Trust Model
Relays can observe and cache MCP content passing through them.
Deployments MUST consider:
Jennings, et al. Expires 7 January 2027 [Page 23]
Internet-Draft MCP over MOQT July 2026
* Relays can read all cached content (resources, tool schemas, skill
instructions). Sensitive content SHOULD use end-to-end encryption
above the MOQT layer.
* Relays MUST NOT modify cached content. Clients MAY verify content
integrity using hashes provided in skill metadata.
* Relay operators are trusted with the same data they cache.
Deployments requiring confidentiality from relays should use
direct QUIC connections.
8.5. Denial of Service
Servers SHOULD limit:
* Maximum subscriptions per client session
* Maximum concurrent FETCH operations
* Rate of group creation on control and notification tracks
* Total bandwidth per session
Servers MAY use EXCESSIVE_LOAD to signal overload and TOO_FAR_BEHIND
to disconnect slow consumers.
8.6. Cross-Server Context Leakage
In multi-server deployments, the client is responsible for ensuring
that data from one server is not inappropriately shared with another.
Tool results, resource content, and sampling responses SHOULD NOT be
forwarded across server boundaries without explicit user or policy
authorization.
9. IANA Considerations
This document has no IANA actions. Future versions may request
registration of the mcp namespace prefix in an MOQT namespace
registry if one is established.
10. Examples
10.1. Basic Session Establishment
Jennings, et al. Expires 7 January 2027 [Page 24]
Internet-Draft MCP over MOQT July 2026
1. Client establishes QUIC connection to server
2. MOQT handshake: CLIENT_SETUP / SERVER_SETUP
3. Client FETCHes (mcp, discovery)/(sessions) with client info
4. Server responds with session_id and track information
5. Client subscribes to control tracks
6. Client publishes MCP initialize on client-to-server control
7. Server publishes capabilities on server-to-client control
8. Session is active
10.2. Tool Execution
Client → Server (Standalone Fetch):
Track: (mcp, session-uuid, tools)/(read_file)
Object payload:
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "read_file",
"arguments": {"path": "/project/README.md"}
}
}
Server → Client (Fetch response object):
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [
{"type": "text", "text": "# Project README\n..."}
]
}
}
10.3. Skill Invocation
1. User types "/commit"
2. Client matches against cached skill registry
3. FETCH (mcp, sess, skills)/(commit, metadata)
→ version, dependencies, required tools
4. FETCH (mcp, sess, skills)/(commit, instructions)
→ full prompt with execution steps
5. AI executes: FETCH tools/git (status, diff, commit)
6. Result returned to user
11. References
Jennings, et al. Expires 7 January 2027 [Page 25]
Internet-Draft MCP over MOQT July 2026
11.1. Normative References
[MCP] Anthropic, "Model Context Protocol Specification", 25
November 2025, <https://modelcontextprotocol.io/
specification/2025-11-25>.
[MOQT] Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell,
"Media over QUIC Transport", 3 March 2026,
<https://www.ietf.org/archive/id/draft-ietf-moq-transport-
18>.
[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", May 2021,
<https://www.rfc-editor.org/rfc/rfc9000.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
11.2. Informative References
[WebTransport]
Vasiliev, V., "The WebTransport Protocol Framework", June
2023, <https://www.rfc-editor.org/rfc/rfc9297.html>.
Appendix A. Acknowledgments
This document is a revision of draft-jennings-mcp-over-moqt available
at https://datatracker.ietf.org/doc/draft-jennings-mcp-over-moqt/
(https://datatracker.ietf.org/doc/draft-jennings-mcp-over-moqt/).
Authors' Addresses
Cullen Jennings
cisco
Email: fluffy@cisco.com
Ian Swett
Google
Email: ianswett@google.com
Jennings, et al. Expires 7 January 2027 [Page 26]
Internet-Draft MCP over MOQT July 2026
Jonathan Rosenberg
Five9
Email: jdrosen@jdrosen.net
Suhas Nandakumar
Cisco Systems
Email: snandaku@cisco.com
Jennings, et al. Expires 7 January 2027 [Page 27]