Model Context Protocol and Agent Skills over Media over QUIC Transport
draft-jennings-ai-mcp-over-moq-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-03-02 | ||
| 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-ai-mcp-over-moq-00
Model Context Protocol C. Jennings
Internet-Draft Cisco Systems
Intended status: Experimental I. Swett
Expires: 3 September 2026 Google
J. Rosenberg
Five9
S. Nandakumar
Cisco Systems
2 March 2026
Model Context Protocol and Agent Skills over Media over QUIC Transport
draft-jennings-ai-mcp-over-moq-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 is a protocol that enables seamless integration between
language model applications and external data sources and tools.
MOQT provides efficient, low-latency, publish-subscribe media
delivery over QUIC and WebTransport.
This specification describes the mapping of MCP messages onto MOQT
objects and defines the procedures for establishing and maintaining
MCP sessions over MOQT. It covers transport of MCP's core primitives
including resources, tools, prompts, and notifications through
dedicated MOQT tracks with appropriate priority management and
delivery guarantees.
A key focus of this document is the delivery and execution of Agent
Skills - composed instructions that extend AI capabilities beyond
atomic tool operations. Skills use progressive loading (metadata,
instructions, resources) that aligns naturally with MOQT's object-
based delivery, enabling efficient bandwidth utilization and
aggressive caching strategies.
The specification also describes relay support for scalable MCP
deployments, including subscription aggregation, content caching, and
multi-hop architectures that enable global distribution of MCP
services with optimized performance.
About This Document
This note is to be removed before publishing as an RFC.
Jennings, et al. Expires 3 September 2026 [Page 1]
Internet-Draft MCP over MOQT March 2026
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-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.
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 3 September 2026.
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
Jennings, et al. Expires 3 September 2026 [Page 2]
Internet-Draft MCP over MOQT March 2026
1.2.1. MCP Lifecycle State Chart . . . . . . . . . . . . . . 5
1.2.2. System Components . . . . . . . . . . . . . . . . . . 6
2. MOQT Tracks for MCP . . . . . . . . . . . . . . . . . . . . . 7
2.1. Track Types . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Control Tracks . . . . . . . . . . . . . . . . . . . 7
2.1.2. Resource Tracks . . . . . . . . . . . . . . . . . . . 7
2.1.3. Tool Tracks . . . . . . . . . . . . . . . . . . . . . 8
2.1.4. Prompt Tracks . . . . . . . . . . . . . . . . . . . . 8
2.1.5. Notification Tracks . . . . . . . . . . . . . . . . . 9
2.1.6. Elicitation Tracks . . . . . . . . . . . . . . . . . 10
2.1.7. Log Tracks . . . . . . . . . . . . . . . . . . . . . 11
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 12
3.1. MOQT Session Establishment . . . . . . . . . . . . . . . 12
3.2. Proposed Session ID Discovery . . . . . . . . . . . . . . 12
3.2.1. Well-Known Discovery Track . . . . . . . . . . . . . 12
3.2.2. Discovery Flow . . . . . . . . . . . . . . . . . . . 13
3.2.3. Discovery Request Format . . . . . . . . . . . . . . 14
3.2.4. Discovery Response Format . . . . . . . . . . . . . . 16
3.3. Priority Management . . . . . . . . . . . . . . . . . . . 18
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 19
3.4.1. Transport-Level Errors . . . . . . . . . . . . . . . 20
3.4.2. MCP-Level Errors . . . . . . . . . . . . . . . . . . 20
3.4.3. Skills-Specific Errors . . . . . . . . . . . . . . . 20
3.4.4. Error Recovery . . . . . . . . . . . . . . . . . . . 21
4. Relay Support . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Subscription Aggregation and Caching . . . . . . . . . . 21
4.2. Capability Discovery . . . . . . . . . . . . . . . . . . 22
4.2.1. Capability Catalog . . . . . . . . . . . . . . . . . 22
4.2.2. Namespace-Based Discovery . . . . . . . . . . . . . . 23
4.2.3. Dynamic Capability Updates . . . . . . . . . . . . . 24
4.2.4. Choosing a Discovery Mechanism . . . . . . . . . . . 25
4.2.5. Relay Namespace Aggregation . . . . . . . . . . . . . 25
5. Agent Skills and MCP Integration . . . . . . . . . . . . . . 26
5.1. Skills Overview . . . . . . . . . . . . . . . . . . . . . 27
5.2. Skills Track Structure and Data Formats . . . . . . . . . 27
5.3. Skills Invocation Protocol . . . . . . . . . . . . . . . 28
5.3.1. Invocation Flow . . . . . . . . . . . . . . . . . . . 28
5.3.2. Streaming Skill Execution with Progress . . . . . . . 30
5.3.3. Skills Execution Request Format . . . . . . . . . . . 31
5.3.4. Skills Execution Response Stream . . . . . . . . . . 32
6. Multi-Server Context Sharing . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Basic Session Establishment . . . . . . . . . . . . . . . 34
9.2. Tool Execution Example . . . . . . . . . . . . . . . . . 34
9.3. Skill Invocation Example . . . . . . . . . . . . . . . . 35
9.4. Multi-Server Skill Workflow . . . . . . . . . . . . . . . 36
Jennings, et al. Expires 3 September 2026 [Page 3]
Internet-Draft MCP over MOQT March 2026
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Normative References . . . . . . . . . . . . . . . . . . 36
10.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction
The Model Context Protocol (MCP) [MCP] enables integration between
LLM applications and external data sources using JSON-RPC 2.0. Media
over QUIC Transport (MOQT) [MOQT] provides efficient publish-
subscribe delivery over QUIC [QUIC] with CDN support.
This document specifies MCP transport over MOQT, addressing
limitations of existing transports:
* *WebSocket*: No prioritization, head-of-line blocking, no caching/
relay
* *HTTP*: Request-response model conflicts with event-driven
architecture, SSE has limited bidirectional support
MOQT provides:
* *Native publish-subscribe*: MCP resources, tools, and capabilities
map to tracks with independent lifecycle and versioning
* *Priority-aware delivery*: Critical operations receive appropriate
bandwidth
* *Multiplexing*: QUIC prevents head-of-line blocking between
operations
* *Relay infrastructure*: Caching and subscription aggregation at
edge
* *Network resilience*: QUIC connection migration for mobile
applications
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].
Jennings, et al. Expires 3 September 2026 [Page 4]
Internet-Draft MCP over MOQT March 2026
1.2. Protocol Overview
MCP messages (JSON-RPC 2.0) are embedded in MOQT payloads. Each MCP
primitive maps to dedicated tracks: resources, tools, prompts,
notifications, and skills. Sessions begin with capability
negotiation, then clients subscribe to relevant tracks for ongoing
communication.
1.2.1. MCP Lifecycle State Chart
┌─────────────┐
│ DISCONNECTED│
└──────┬──────┘
│ QUIC Connect
▼
┌─────────────┐
│ TRANSPORT │
│ CONNECTED │
└──────┬──────┘
│ MOQT Setup
▼
┌─────────────┐
│ MOQT │
│ ESTABLISHED │
└──────┬──────┘
│ Track Subscribe
▼
┌─────────────┐
│ TRACKS │
│ SUBSCRIBED │
└──────┬──────┘
│ MCP Initialize
▼
┌─────────────┐
│ MCP │
│ INITIALIZING│
└──────┬──────┘
│ Capabilities Exchange
▼
┌─────────────┐
│ CAPABILITIES│
│ NEGOTIATED │
└──────┬──────┘
│ Discovery Complete
▼
┌─────────────┐
┌──────────▶│ MCP ACTIVE │◀──────────┬──────────┐
│ │ │ │ │
Jennings, et al. Expires 3 September 2026 [Page 5]
Internet-Draft MCP over MOQT March 2026
│ └──┬───┬───┬──┘ │ │
│ │ │ │ │ │
│ Tool Result │ │ │ Notification │ │ Resource
│ │ │ │ │ │ Update
▼ │ │ ▼ │ │
┌─────────────┐ │ │ ┌─────────────┐ │ ┌──────┴──────┐
│ TOOL │ │ │ │ ELICITATION │ │ │ SKILL │
│ EXECUTING │───────┘ │ │ PENDING │ │ │ EXECUTING │
└─────────────┘ │ └─────────────┘ │ └─────────────┘
│ │ │ │ │
│ │ │ │ │ Skill
│ │ │ │ │ Complete
└──────────────────┼───────┴──────────┴──────────┘
│
▼
┌─────────────┐
│ SESSION │
│ TERMINATING │
└──────┬──────┘
│ Cleanup
▼
┌─────────────┐
│ DISCONNECTED│
└─────────────┘
1.2.2. System Components
Below figure shows system components proposed in this specification.
┌─────────────────┐ 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
Jennings, et al. Expires 3 September 2026 [Page 6]
Internet-Draft MCP over MOQT March 2026
* *MCP Server*: Acts as MOQT publisher, exposing resources, tools,
and prompts
2. MOQT Tracks for MCP
2.1. Track Types
This section defines the track naming conventions and mappings for
MCP operations.
2.1.1. Control Tracks
Control tracks handle MCP session management using two unidirectional
tracks for bidirectional communication. The client-to-server track
carries initialize requests, ping messages, capability negotiations,
session teardown, and tool cancellations. The server-to-client track
carries responses, pong messages, status updates, and teardown
confirmations.
Track namespace:
(mcp, <session-id>, control)
Track name (Client-to-Server):
(client-to-server)
Track name (Server-to-Client):
(server-to-client)
Groups and objects are mapped as follows:
Each MCP control message is encoded as a single MOQT object within a
group. Group IDs are assigned sequentially starting from 0,
incrementing for each new control message. Object IDs within each
group are always 0 since each control message maps to exactly one
object. Objects contain JSON-encoded MCP control messages as defined
in the MCP specification.
2.1.2. Resource Tracks
Resource tracks map MCP resources, delivering server-published
content and metadata that serve as the main data sources exposed by
MCP servers to clients.
Track namespace:
Jennings, et al. Expires 3 September 2026 [Page 7]
Internet-Draft MCP over MOQT March 2026
(mcp, <session-id>, resources)
Track name:
(<resource-uri>)
Groups and objects are mapped as follows:
Each resource version is assigned a unique group ID, starting from 0
and incrementing with each resource update. Within each group,
objects represent chunks or segments of the resource content. Object
IDs start at 0 and increment sequentially for each chunk. Objects
contain the actual resource data encoded according to the resource's
declared content type (binary data, JSON, text, etc.).
2.1.3. Tool Tracks
Tool tracks map MCP tool execution, facilitating tool invocation
requests, responses, and progress updates using MOQT's FETCH
operations.
Track namespace:
(mcp, <session-id>, tools)
Track name:
(<tool-name>)
Groups and objects are mapped as follows:
Each tool invocation creates a new group with a unique group ID
assigned by the requesting client. Within each group, object ID 0
contains the tool request (JSON-encoded MCP tool call), subsequent
object IDs contain tool responses and progress updates. Objects are
JSON-encoded according to the MCP tool execution protocol.
2.1.4. Prompt Tracks
Prompt tracks map MCP prompts, distributing pre-defined templates and
instructions that standardize common operations across the MCP
ecosystem.
Track namespace:
(mcp, <session-id>, prompts)
Track name:
Jennings, et al. Expires 3 September 2026 [Page 8]
Internet-Draft MCP over MOQT March 2026
(<prompt-name>)
Groups and objects are mapped as follows:
Each prompt version is assigned a unique group ID starting from 0,
incrementing with each prompt update. Within each group, object ID 0
contains the prompt template and metadata. Objects contain JSON-
encoded prompt definitions including template text, parameter
schemas, and versioning information.
2.1.5. Notification Tracks
Notification tracks map MCP notifications, providing asynchronous
event delivery for server-sent notifications, progress updates, and
system events.
Track namespace:
(mcp, <session-id>, notifications)
Track name:
(<category>)
The category parameter classifies notification types to enable
efficient subscription management and routing. Common category
values include:
* progress - Tool execution progress updates and status reports
* resources - Resource change notifications (listChanged, updated)
* prompts - Prompt template updates and availability changes
* system - Server status updates, connection events, error
conditions
* elicitation - User input request notifications and responses
* tools - Tool availability changes and capability updates
Custom categories may be defined for application-specific
notification types following the pattern <domain>/<type> (e.g., ai/
model_updated, workspace/file_changed).
Groups and objects are mapped as follows:
Jennings, et al. Expires 3 September 2026 [Page 9]
Internet-Draft MCP over MOQT March 2026
Each notification event creates a new group with group IDs assigned
sequentially starting from 0. Within each group, object ID 0
contains the notification payload. Objects contain JSON-encoded
notification messages as defined in the MCP specification, including
event type, timestamp, and payload data.
2.1.6. Elicitation Tracks
Elicitation tracks map MCP user input collection, handling
interactive flows for gathering user consent and data through pairs
of unidirectional tracks. The elicitation flow uses a unidirectional
track pair to collect user input efficiently while preserving
privacy. Each request creates isolated track pairs, allowing
concurrent operations. Servers request user consent and input, while
clients retain control to reject or modify requests.
Track namespace:
(mcp, <session-id>, elicitation, <request-id>)
Track name (Server-to-Client):
(<server-to-client>)
Track name (Client-to-Server):
(<client-to-server>)
The Server-to-Client elicitation track is published by the MCP Server
and subscribed to by the MCP Client, carrying:
* Elicitation request initiation
* Input schema definitions
* Validation error messages
* Request timeout notifications
* Request cancellation notices
The Client-to-Server elicitation track is published by the MCP Client
and subscribed to by the MCP Server, carrying:
* User consent responses
* Input data submissions
Jennings, et al. Expires 3 September 2026 [Page 10]
Internet-Draft MCP over MOQT March 2026
* Request rejection notifications
* Request cancellation confirmations
Groups and objects are mapped as follows:
Each elicitation exchange creates new groups with group IDs starting
from 0 and incrementing for each message in the exchange. Within
each group, object ID 0 contains the elicitation message (request,
response, or status update). Objects contain JSON-encoded
elicitation messages including input schemas, validation
requirements, and user responses.
2.1.7. Log Tracks
Log tracks map MCP logging information, providing debugging and
monitoring capabilities by carrying diagnostic information for system
troubleshooting and performance optimization.
Track namespace:
(mcp, <session-id>, logs)
Track name:
(<category>)
The category parameter organizes log entries by severity level and
source component to enable selective monitoring and efficient log
processing. Standard category values include:
* error - Error conditions, exceptions, and critical failures
* warn - Warning messages and non-critical issues requiring
attention
* info - General informational messages about system operations
* debug - Detailed debugging information for troubleshooting
* trace - Fine-grained execution tracing for performance analysis
* audit - Security and compliance audit trails
* metrics - Performance metrics and system statistics
Jennings, et al. Expires 3 September 2026 [Page 11]
Internet-Draft MCP over MOQT March 2026
Component-specific categories may be defined using the pattern
<level>/<component> (e.g., error/transport, debug/tools, info/
resources) to provide granular filtering capabilities.
Groups and objects are mapped as follows:
Each log entry creates a new group with group IDs assigned
sequentially starting from 0, ordered by log timestamp. Within each
group, object ID 0 contains the log entry. Objects contain JSON-
encoded log messages including severity level, timestamp, source
component, and message content.
3. Protocol Operation
3.1. MOQT Session Establishment
The session establishment process begins with establishing the
underlying MOQT session, which can be either a direct QUIC connection
or a WebTransport [WebTransport] session depending on the deployment
environment. QUIC connections provide optimal performance for
server-to- server communication, while WebTransport enables browser-
based clients to participate in MCP sessions.
The MOQT handshake phase involves the exchange of CLIENT_SETUP (0x20)
and SERVER_SETUP (0x21) messages that negotiate protocol versions,
supported features, and operational parameters.
3.2. Proposed Session ID Discovery
MCP sessions require unique identifiers to organize track namespaces
and enable proper message routing. This section defines a well-known
track approach for session discovery that allows clients to
dynamically discover available MCP services and obtain session
identifiers through standardized FETCH operations.
3.2.1. Well-Known Discovery Track
The discovery mechanism uses a well-known track namespace and name
that all MCP servers must support. This track serves as the entry
point for clients to discover available MCP sessions and obtain the
necessary session identifiers for subsequent operations.
Track Namespace: mcp/discovery
Track Name: sessions
Jennings, et al. Expires 3 September 2026 [Page 12]
Internet-Draft MCP over MOQT March 2026
Clients initiate discovery by sending a FETCH request to this well-
known track, providing a client-side nonce or identifier as a
parameter. The server responds with a JSON-encoded MOQT object
containing server details, a newly minted session identifier, and
information about available tracks on that server.
3.2.2. Discovery Flow
The session discovery process follows this sequence:
3.2.2.1. Standard Discovery Flow
Client Server
│ │
│ FETCH mcp/discovery/sessions│
│ (with client nonce) │
│────────────────────────────▶│
│ │
│ │ Generate session ID
│ │ Prepare track catalog
│ │
│ FETCH_OK │
│◀────────────────────────────│
│ │
│ Data stream: FETCH_HEADER │
│ + Object with session │
│ details │
│◀────────────────────────────│
│ │
│ Subscribe to control tracks │
│────────────────────────────▶│
│ │
│ MCP Initialize │
│────────────────────────────▶│
│ │
│ Initialize Response │
│◀────────────────────────────│
│ │
│ Begin MCP operations │
│────────────────────────────▶│
3.2.2.2. Optimized Discovery Flow (RTT Reduction)
Jennings, et al. Expires 3 September 2026 [Page 13]
Internet-Draft MCP over MOQT March 2026
Client Server
│ │
│ FETCH mcp/discovery/sessions│
│ (with nonce + MCP init) │
│────────────────────────────▶│
│ │
│ │ Generate session ID
│ │ Process MCP initialize
│ │ Prepare track catalog
│ │
│ FETCH_OK │
│◀────────────────────────────│
│ │
│ Data stream: FETCH_HEADER │
│ + Object with session │
│ details + MCP init response │
│◀────────────────────────────│
│ │
│ Subscribe to control tracks │
│────────────────────────────▶│
│ │
│ Begin MCP operations │
│ (initialization complete) │
│────────────────────────────▶│
The optimized flow reduces session establishment from 4 round-trips
to 2 by combining discovery and MCP initialization into a single
exchange.
3.2.3. Discovery Request Format
Clients send FETCH requests to the well-known discovery track with a
client-generated nonce or identifier in the payload:
Jennings, et al. Expires 3 September 2026 [Page 14]
Internet-Draft MCP over MOQT March 2026
FETCH {
Type (i) = 0x16,
Length (16),
Request ID (i) = 1,
Subscriber Priority (8) = 30,
Group Order (8) = 0,
Fetch Type (i) = 0x1, // Standalone
Track Namespace (tuple) = (... "mcp", "discovery"),
Track Name Length (i) = 8,
Track Name = "sessions",
Start Location = {Group: 0, Object: 0},
End Location = {Group: 0, Object: 1},
Number of Parameters (i) = 1,
Parameters = {
"mcp_payload": {
"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", "skills"]
}
}
}
}
3.2.3.1. RTT Optimization with Combined Initialize
To reduce round-trip time, clients MAY include their MCP initialize
request within the discovery FETCH payload. This allows the server
to perform both session discovery and MCP initialization in a single
exchange:
Jennings, et al. Expires 3 September 2026 [Page 15]
Internet-Draft MCP over MOQT March 2026
FETCH {
Type (i) = 0x16,
Length (16),
Request ID (i) = 1,
Subscriber Priority (8) = 30,
Group Order (8) = 0,
Fetch Type (i) = 0x1, // Standalone
Track Namespace (tuple) = ("mcp", "discovery"),
Track Name Length (i) = 8,
Track Name = "sessions",
Start Location = {Group: 0, Object: 0},
End Location = {Group: 0, Object: 1},
Number of Parameters (i) = 1,
Parameters = {
"mcp_payload": {
"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", "skills"],
"mcp_initialize": {
"protocolVersion": "2025-06-18",
"capabilities": {
"resources": { "subscribe": true },
"tools": { "progress": true },
"prompts": {},
"elicitation": {},
"skills": { "progressive_loading": true, "streaming": true }
},
"clientInfo": {
"name": "ExampleClient",
"version": "1.0.0"
}
}
}
}
}
}
3.2.4. Discovery Response Format
The server responds with a JSON-encoded MOQT object containing the
newly minted session ID and control track information:
Jennings, et al. Expires 3 September 2026 [Page 16]
Internet-Draft MCP over MOQT March 2026
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"session_id": "session-uuid-456",
"server_info": {
"name": "ExampleServer",
"version": "2.0.0",
"protocol_version": "2025-06-18"
},
"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": "2025-06-18T12:00:00Z"
}
}
3.2.4.1. Combined Discovery and Initialize Response
When the client uses the RTT optimization by including MCP initialize
in the discovery request, the server responds with both session
discovery and MCP initialization results:
Jennings, et al. Expires 3 September 2026 [Page 17]
Internet-Draft MCP over MOQT March 2026
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"session_id": "session-uuid-456",
"server_info": {
"name": "ExampleServer",
"version": "2.0.0",
"protocol_version": "2025-06-18"
},
"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": "2025-06-18T12:00:00Z",
"mcp_initialize_response": {
"protocolVersion": "2025-06-18",
"capabilities": {
"resources": { "subscribe": true, "listChanged": true },
"tools": { "progress": true },
"prompts": { "listChanged": true },
"elicitation": {},
"skills": { "progressive_loading": true, "streaming": true }
},
"serverInfo": {
"name": "ExampleServer",
"version": "2.0.0"
}
}
}
}
After establishing a session, clients discover available capabilities
(resources, tools, prompts, and skills) using the mechanisms
described in Section 4.2.
After receiving the discovery response, clients subscribe to control
tracks and proceed with capability discovery (see Section 4.2).
3.3. Priority Management
MOQT's object priorities optimize MCP message delivery by considering
the importance of different track types specified.
Jennings, et al. Expires 3 September 2026 [Page 18]
Internet-Draft MCP over MOQT March 2026
The following priority assignments are RECOMMENDED, but applications
MAY adjust them as needed:
+===========+========+==================+=======================+
| Priority | Range | Track Type | Example |
+===========+========+==================+=======================+
| CRITICAL | 1-5 | Session Control | initialize, terminate |
+-----------+--------+------------------+-----------------------+
| HIGHEST | 6-15 | User Elicitation | permission prompts |
+-----------+--------+------------------+-----------------------+
| HIGH | 16-30 | Skills/Tool | /commit, git |
| | | Execution | operations |
+-----------+--------+------------------+-----------------------+
| MEDIUM-HI | 31-45 | Notifications | resource changes |
+-----------+--------+------------------+-----------------------+
| MEDIUM | 46-60 | Skill | prompt loading |
| | | Instructions | |
+-----------+--------+------------------+-----------------------+
| MEDIUM-LO | 61-75 | Resources | documentation |
+-----------+--------+------------------+-----------------------+
| LOW | 76-90 | Tool Schemas | capability metadata |
+-----------+--------+------------------+-----------------------+
| LOWEST | 91-127 | Logs | debug, trace |
+-----------+--------+------------------+-----------------------+
Table 1
Priorities can also be dynamically adjusted based on:
* User interaction urgency (elicitation requests get higher
priority)
* Skill/tool execution criticality (error handling gets priority
boost)
* Resource size and frequency (large resources get lower priority)
* Server load conditions (adaptive priority scaling)
* Active user engagement (boost skill loading when user is waiting)
3.4. Error Handling
Error handling in MCP over MOQT leverages both MOQT's native error
mechanisms and MCP's JSON-RPC error responses.
Jennings, et al. Expires 3 September 2026 [Page 19]
Internet-Draft MCP over MOQT March 2026
3.4.1. Transport-Level Errors
MOQT provides several error handling mechanisms that apply to MCP
operations:
* *SUBSCRIBE_ERROR*: Returned when a client cannot subscribe to an
MCP track. Common causes include invalid session IDs,
unauthorized access, or non-existent resources.
* *FETCH_ERROR*: Returned when a FETCH operation fails. For tool
execution, this indicates the tool request could not be processed
at the transport level.
* *GOAWAY*: Indicates the server is terminating the session.
Clients SHOULD attempt to reconnect and re-establish the MCP
session.
3.4.2. MCP-Level Errors
MCP errors are returned as JSON-RPC error responses within MOQT
objects:
{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": -32600,
"message": "Invalid Request",
"data": {
"details": "Tool 'unknown_tool' not found"
}
}
}
Standard MCP error codes apply: - -32700: Parse error - -32600:
Invalid request - -32601: Method not found - -32602: Invalid params -
-32603: Internal error
3.4.3. Skills-Specific Errors
Skills execution may encounter additional error conditions:
Jennings, et al. Expires 3 September 2026 [Page 20]
Internet-Draft MCP over MOQT March 2026
+============+===================+===============================+
| 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 | |
+------------+-------------------+-------------------------------+
| -33005 | Context sharing | Resolve context state |
| | conflict | |
+------------+-------------------+-------------------------------+
Table 2
3.4.4. Error Recovery
Clients SHOULD implement the following recovery strategies:
1. *Transient errors*: Retry with exponential backoff
2. *Session errors*: Re-establish MCP session via discovery
3. *Resource errors*: Invalidate cache and re-fetch
4. *Skill errors*: Fall back to individual tool operations if
possible
4. Relay Support
MOQT relays enable scalable MCP deployments by providing intelligent
aggregation, caching, and distribution capabilities that optimize
performance for AI workflows and reduce server load across multiple
clients.
4.1. Subscription Aggregation and Caching
MOQT relays aggregate multiple client subscriptions to the same
content into single upstream requests, reducing server load and
bandwidth. When clients subscribe to identical resources, tool
metadata, or notification streams, the relay maintains one upstream
subscription and fans out content to all clients.
Jennings, et al. Expires 3 September 2026 [Page 21]
Internet-Draft MCP over MOQT March 2026
Relays also cache content aggressively:
* *Static resources* (documentation, API references): Cached with
long TTLs since they change infrequently but are accessed
frequently
* *Tool schemas*: Cached until explicitly invalidated, as they
define stable interface contracts
* *Capability metadata*: Cached as one-time objects after session
initialization
* *Skills registry and instructions*: Cached by version with push-
based invalidation
4.2. Capability Discovery
After establishing a session (Section 3.2), clients discover
available capabilities (resources, tools, prompts, and skills) using
two complementary mechanisms:
1. *Capability Catalog*: Application-level catalog with rich
metadata
2. *Namespace-Based Discovery*: Protocol-level discovery using
native MOQT messages
Implementations MAY support either or both mechanisms depending on
their needs.
4.2.1. Capability Catalog
Servers implement capability catalog tracks that enumerate available
MCP capabilities and their associated track patterns within a
specific session:
Track namespace: mcp/<session-id>/discovery Track name: catalog
Jennings, et al. Expires 3 September 2026 [Page 22]
Internet-Draft MCP over MOQT March 2026
{
"server_catalog": {
"mcp/{session-id}/resources": {
"available_tracks": [
"documentation", "api_schemas", "examples", "templates"
],
"content_types": ["text/markdown",
"application/json", "text/plain"],
"update_frequency": "daily",
"cache_recommended": true
},
"mcp/{session-id}/tools/": {
"available_tracks": [
"file_operations", "database_query", "code_analysis"
],
"execution_types": ["synchronous", "asynchronous"],
"progress_tracking": true,
"cache_recommended": false
},
"mcp/{session-id}/prompts/": {
"available_tracks": [
"code_review", "data_analysis", "content_generation"
],
"template_versions": ["1.0", "1.1", "2.0"],
"cache_recommended": true
}
},
"discovery_timestamp": "2025-06-18T10:30:00Z"
}
Clients discover available capabilities by issuing FETCH requests to
the catalog track for initial discovery, or SUBSCRIBE for real-time
updates when capabilities change.
4.2.2. Namespace-Based Discovery
MOQT draft-16 introduces SUBSCRIBE_NAMESPACE and PUBLISH_NAMESPACE
messages that enable protocol-level discovery of available tracks
under specific namespace prefixes.
4.2.2.1. SUBSCRIBE_NAMESPACE for Track Discovery
Clients use SUBSCRIBE_NAMESPACE to discover all available tracks
under an MCP namespace prefix without prior knowledge of specific
track names:
Jennings, et al. Expires 3 September 2026 [Page 23]
Internet-Draft MCP over MOQT March 2026
SUBSCRIBE_NAMESPACE {
Request ID (i) = 1,
Track Namespace = ("mcp", "<session-id>", "resources")
}
The server responds with NAMESPACE messages for each available track:
NAMESPACE {
Request ID (i) = 1,
Track Namespace = ("mcp", "<session-id>", "resources", "documentation")
}
NAMESPACE {
Request ID (i) = 1,
Track Namespace = ("mcp", "<session-id>", "resources", "api-schemas")
}
NAMESPACE_DONE {
Request ID (i) = 1,
Status Code (i) = 0,
Reason Phrase = ""
}
4.2.2.2. PUBLISH_NAMESPACE for Server Announcements
MCP servers use PUBLISH_NAMESPACE to proactively announce track
namespace availability to connected clients and relays:
PUBLISH_NAMESPACE {
Request ID (i) = 1,
Track Namespace = ("mcp", "<session-id>", "tools")
}
Relays receiving PUBLISH_NAMESPACE forward these announcements to
interested subscribers, enabling efficient fan-out of capability
updates.
4.2.3. Dynamic Capability Updates
Both discovery mechanisms support real-time updates when capabilities
change during a session.
*Capability Catalog Updates*: Clients subscribed to the capability
catalog track receive new catalog objects when capabilities are
added, removed, or modified.
*Namespace Updates*: Servers publish PUBLISH_NAMESPACE announcements
that relays forward to clients with active namespace subscriptions:
Jennings, et al. Expires 3 September 2026 [Page 24]
Internet-Draft MCP over MOQT March 2026
Client Relay Server
│ │ │
│ (Existing subscription │ │
│ to namespace) │ │
│ │ │
│ │ │ New tool added
│ │ │
│ │ PUBLISH_NAMESPACE │
│ │ ("mcp", "sess-123", │
│ │ "tools", "new-tool") │
│ │◀───────────────────────│
│ │ │
│ NAMESPACE │ │
│ ("mcp", "sess-123", │ │
│ "tools", "new-tool") │ │
│◀───────────────────────│ │
│ │ │
│ (Client discovers new │ │
│ tool availability) │ │
4.2.4. Choosing a Discovery Mechanism
+===============================+======================+
| Use Case | Recommended Approach |
+===============================+======================+
| Rich metadata needed (content | Capability Catalog |
| types, caching hints) | |
+-------------------------------+----------------------+
| Simple track enumeration | Namespace-Based |
+-------------------------------+----------------------+
| Relay aggregation scenarios | Namespace-Based |
+-------------------------------+----------------------+
| Legacy MOQT implementations | Capability Catalog |
| (pre-draft-16) | |
+-------------------------------+----------------------+
| Minimal protocol overhead | Namespace-Based |
+-------------------------------+----------------------+
Table 3
4.2.5. Relay Namespace Aggregation
Relays can aggregate namespace information from multiple upstream
servers and present a unified namespace view to downstream clients:
Jennings, et al. Expires 3 September 2026 [Page 25]
Internet-Draft MCP over MOQT March 2026
Client Relay Server A Server B
│ │ │ │
│ SUBSCRIBE_NAMESPACE │ │ │
│ ("mcp", "unified", │ │ │
│ "tools") │ │ │
│───────────────────────▶│ │ │
│ │ │ │
│ │ SUBSCRIBE_NAMESPACE │ │
│ │ ("mcp", "sess-a", │ │
│ │ "tools") │ │
│ │────────────────────▶│ │
│ │ │ │
│ │ SUBSCRIBE_NAMESPACE │ │
│ │ ("mcp", "sess-b", │ │
│ │ "tools") │ │
│ │───────────────────────────────────▶│
│ │ │ │
│ │ NAMESPACE responses │ │
│ │ from both servers │ │
│ │◀────────────────────│ │
│ │◀───────────────────────────────────│
│ │ │ │
│ │ (Relay aggregates │ │
│ │ and deduplicates) │ │
│ │ │ │
│ NAMESPACE │ │ │
│ (aggregated responses) │ │ │
│◀───────────────────────│ │ │
│ │ │ │
│ NAMESPACE_DONE │ │ │
│◀───────────────────────│ │ │
5. Agent Skills and MCP Integration
Agent Skills represent a paradigm shift in how AI capabilities are
extended and distributed. Unlike atomic tools that perform single
operations, Skills provide composed instructions for complex tasks
that may orchestrate multiple tools. This section describes the
comprehensive architecture for Skills delivery and execution over
MOQT.
Jennings, et al. Expires 3 September 2026 [Page 26]
Internet-Draft MCP over MOQT March 2026
5.1. Skills Overview
Skills and Tools serve complementary roles in MCP. Tools provide
atomic capabilities invoked via direct RPC calls, while Skills
provide composed instructions for complex tasks through prompt
expansion and orchestration. Tools are stateless with schemas always
available; Skills are context-aware with progressive loading
(metadata, then instructions, then resources).
Support for Skills is OPTIONAL. Servers advertising the skills
capability MUST implement the skills registry track and support FETCH
operations for skill metadata and instructions. Clients SHOULD cache
skill content by version. When Skills are not supported, clients
fall back to direct tool operations.
Skills use three progressive loading levels optimized for MOQT
delivery:
* *Metadata* (~100 tokens): Skill identification, triggers,
dependencies
* *Instructions* (<5k tokens): Full prompt text and execution logic
* *Resources*: Templates, schemas, and examples loaded during
execution
5.2. Skills Track Structure and Data Formats
Skills use a hierarchical track namespace under mcp/<session-
id>/skills/:
Jennings, et al. Expires 3 September 2026 [Page 27]
Internet-Draft MCP over MOQT March 2026
+==============+===============+=================+=================+
| Track | Namespace | Name | Purpose |
+==============+===============+=================+=================+
| Registry | (mcp, | registry | Complete skill |
| | <session-id>, | | catalog for |
| | skills) | | trigger |
| | | | matching |
+--------------+---------------+-----------------+-----------------+
| Metadata | (mcp, | metadata | Skill |
| | <session-id>, | | identification, |
| | skills, | | triggers, |
| | <skill-id>) | | dependencies |
+--------------+---------------+-----------------+-----------------+
| Instructions | (mcp, | instructions | Full prompt |
| | <session-id>, | | text and |
| | skills, | | execution logic |
| | <skill-id>) | | |
+--------------+---------------+-----------------+-----------------+
| Execution | (mcp, | <invocation-id> | Bidirectional |
| | <session-id>, | | streaming for |
| | skills, | | active |
| | <skill-id>, | | invocations |
| | execution) | | |
+--------------+---------------+-----------------+-----------------+
Table 4
The registry track contains an array of skill entries, each
specifying: id, name, version, description, triggers (commands and
patterns), loading hints (token sizes, preload preferences),
required/optional tools and permissions, and composition
relationships (which skills can invoke each other).
Individual metadata objects provide detailed capability information
including content hashes for integrity verification, activation
context requirements, tool and resource dependencies, permission
requirements, and execution characteristics (streaming support,
cancellation, timeouts).
Instructions objects contain the complete prompt text with step-by-
step execution logic, parameter schemas with types and defaults, and
output format specifications for success and error cases.
5.3. Skills Invocation Protocol
5.3.1. Invocation Flow
Jennings, et al. Expires 3 September 2026 [Page 28]
Internet-Draft MCP over MOQT March 2026
Client Relay Origin
│ │ │
│ User types: "/commit" │ │
│ │ │
│ (Match against │ │
│ cached registry) │ │
│ │ │
├────────────────────────┼─────────────────────────┤
│ PHASE 1: LOAD SKILL METADATA │
├────────────────────────┼─────────────────────────┤
│ │ │
│ FETCH │ │
│ mcp/sess/skills/ │ │
│ commit/metadata │ │
│───────────────────────▶│ │
│ │ │
│ │ [CACHE HIT] │
│ │ │
│ FETCH_OK + OBJECT │ │
│ { │ │
│ skill_id: "commit", │ │
│ version: "2.1.0", │ │
│ requires: [ │ │
│ "tools/git/*" │ │
│ ] │ │
│ } │ │
│◀───────────────────────│ │
│ │ │
├────────────────────────┼─────────────────────────┤
│ PHASE 2: LOAD SKILL INSTRUCTIONS │
├────────────────────────┼─────────────────────────┤
│ │ │
│ FETCH │ │
│ mcp/sess/skills/ │ │
│ commit/instructions │ │
│───────────────────────▶│ │
│ │ │
│ │ [CACHE HIT - v2.1.0] │
│ │ │
│ FETCH_OK + OBJECT │ │
│ { │ │
│ instructions: "..." │ │
│ } │ │
│◀───────────────────────│ │
│ │ │
├────────────────────────┼─────────────────────────┤
│ PHASE 3: EXECUTE SKILL (TOOL CALLS) │
├────────────────────────┼─────────────────────────┤
Jennings, et al. Expires 3 September 2026 [Page 29]
Internet-Draft MCP over MOQT March 2026
│ │ │
│ (AI processes │ │
│ instructions) │ │
│ │ │
│ FETCH tools/git/status │ │
│───────────────────────▶│───────────────────────▶│
│ │ │
│ FETCH_OK + OBJECT │ │
│◀───────────────────────│◀───────────────────────│
│ │ │
│ FETCH tools/git/diff │ │
│───────────────────────▶│───────────────────────▶│
│ │ │
│ FETCH_OK + OBJECT │ │
│◀───────────────────────│◀───────────────────────│
│ │ │
│ FETCH tools/git/commit │ │
│───────────────────────▶│───────────────────────▶│
│ │ │
│ FETCH_OK + OBJECT │ │
│ {commit_sha: "abc123"} │ │
│◀───────────────────────│◀───────────────────────│
│ │ │
5.3.2. Streaming Skill Execution with Progress
Jennings, et al. Expires 3 September 2026 [Page 30]
Internet-Draft MCP over MOQT March 2026
Client Relay Origin
│ │ │
│ SUBSCRIBE │ │
│ skills/deploy/ │ │
│ execution/inv-xyz │ │
│───────────────────────▶│ SUBSCRIBE │
│ │───────────────────────▶│
│ │ │
│ SUBSCRIBE_OK │ SUBSCRIBE_OK │
│◀───────────────────────│◀───────────────────────│
│ │ │
│ Publish request │ │
│ {action: "invoke", │ │
│ params: {env: "prod"}}│ │
│───────────────────────▶│───────────────────────▶│
│ │ │
│ │ Object (progress) │
│ │ {status: "started"} │
│ │◀───────────────────────│
│ Object │ │
│◀───────────────────────│ │
│ │ │
│ │ Object (progress) │
│ │ {step: "building", │
│ │ progress: 25} │
│ │◀───────────────────────│
│ Object │ │
│◀───────────────────────│ │
│ │ │
│ │ Object (progress) │
│ │ {step: "deploying", │
│ │ progress: 75} │
│ │◀───────────────────────│
│ Object │ │
│◀───────────────────────│ │
│ │ │
│ │ Object (complete) │
│ │ {status: "completed", │
│ │ result: {url: "..."}} │
│ │◀───────────────────────│
│ Object │ │
│◀───────────────────────│ │
│ │ │
5.3.3. Skills Execution Request Format
Jennings, et al. Expires 3 September 2026 [Page 31]
Internet-Draft MCP over MOQT March 2026
{
"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/new-feature",
"has_staged": true
}
},
"options": {
"stream_progress": true,
"timeout_ms": 60000
}
}
}
5.3.4. Skills Execution Response Stream
// 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": 4,
"message": "Checking repository status...",
"tool_call": {"tool": "git/status", "status": "in_progress"}
}
}
Jennings, et al. Expires 3 September 2026 [Page 32]
Internet-Draft MCP over MOQT March 2026
// Object 2: Progress
{
"jsonrpc": "2.0",
"method": "skills/progress",
"params": {
"invocation_id": "inv-xyz789",
"step": 2,
"message": "Analyzing changes...",
"tool_call": {"tool": "git/diff", "status": "completed"}
}
}
// Object 3: Completion
{
"jsonrpc": "2.0",
"id": "exec-001",
"result": {
"status": "completed",
"output": {
"commit_sha": "abc123def456",
"message": "Add user authentication flow",
"files_committed": ["src/auth.ts", "src/middleware/jwt.ts"]
}
}
}
6. Multi-Server Context Sharing
When an MCP client connects to multiple servers simultaneously, each
connection maintains its own session ID and track namespace for
isolation:
Server A: mcp/session-a-uuid/resources/documentation
Server B: mcp/session-b-uuid/tools/code_analysis
Server C: mcp/session-c-uuid/prompts/review_templates
The client coordinates these sessions while presenting a unified
capability view. Key considerations include:
* *Resource synchronization*: Subscribe to related tracks across
servers, selecting sources based on performance, recency, or
availability
* *Tool execution context*: Track execution state across servers for
proper workflow sequencing; pass results between servers as needed
* *Cache coordination*: Reuse cached context across servers where
appropriate, tracking versions for consistency
Jennings, et al. Expires 3 September 2026 [Page 33]
Internet-Draft MCP over MOQT March 2026
7. Security Considerations
TODO
8. IANA Considerations
TODO
9. Examples
9.1. Basic Session Establishment
This example shows a minimal MCP session establishment over MOQT:
1. Client establishes QUIC connection to server
2. Client sends CLIENT_SETUP, server responds with SERVER_SETUP
3. Client sends FETCH to mcp/discovery/sessions with client info
4. Server responds with session_id and available tracks
5. Client subscribes to control tracks
6. Client sends MCP initialize on client-to-server control track
7. Server responds with capabilities on server-to-client control track
8. Session is now active
9.2. Tool Execution Example
Executing a file read tool:
Jennings, et al. Expires 3 September 2026 [Page 34]
Internet-Draft MCP over MOQT March 2026
Client → Server:
FETCH mcp/{session-id}/tools/filesystem
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "read_file",
"arguments": {"path": "/project/README.md"}
}
}
Server → Client:
FETCH_OK + OBJECT
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [
{"type": "text", "text": "# Project README\n..."}
]
}
}
9.3. Skill Invocation Example
Invoking the /commit skill with progressive loading:
1. User types: "/commit"
2. Client checks cached registry, finds "commit" skill
3. Client FETCHes skill metadata (if not cached):
FETCH mcp/{session-id}/skills/commit/metadata
→ Returns: version, dependencies, required tools
4. Client FETCHes skill instructions:
FETCH mcp/{session-id}/skills/commit/instructions
→ Returns: full prompt with execution steps
5. AI processes instructions, calls required tools:
FETCH mcp/{session-id}/tools/git {method: "status"}
FETCH mcp/{session-id}/tools/git {method: "diff"}
FETCH mcp/{session-id}/tools/git {method: "commit", args: {...}}
6. Skill completes, returns result to user
Jennings, et al. Expires 3 September 2026 [Page 35]
Internet-Draft MCP over MOQT March 2026
9.4. Multi-Server Skill Workflow
A deployment workflow using skills from multiple servers:
User: "/deploy to production"
1. Load /deploy skill from Enterprise Server B
2. /deploy instructions: "First ensure changes committed"
3. Invoke /commit skill from Anthropic Server A
4. /commit executes using GitHub Tools Server
5. Return to /deploy, execute deployment tools
6. Stream progress updates to client
7. Return deployment result with URL
10. References
10.1. Normative References
[MCP] Anthropic, "Model Context Protocol Specification", 18 June
2025, <https://modelcontextprotocol.io/
specification/2025-06-18>.
[MOQT] Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell,
"Media over QUIC Transport", 16 December 2025,
<https://www.ietf.org/archive/id/draft-ietf-moq-transport-
16>.
[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>.
10.2. Informative References
[WebTransport]
Vasiliev, V., "The WebTransport Protocol Framework", June
2023, <https://www.rfc-editor.org/rfc/rfc9297.html>.
Jennings, et al. Expires 3 September 2026 [Page 36]
Internet-Draft MCP over MOQT March 2026
Appendix A. Acknowledgments
TODO
Authors' Addresses
Cullen Jennings
Cisco Systems
Email: fluffy@cisco.com
Ian Swett
Google
Email: ianswett@google.com
Jonathan Rosenberg
Five9
Email: jdrosen@jdrosen.net
Suhas Nandakumar
Cisco Systems
Email: snandaku@cisco.com
Jennings, et al. Expires 3 September 2026 [Page 37]