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, , 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, , resources) Track name: () 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, , tools) Track 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, , prompts) Track name: Jennings, et al. Expires 3 September 2026 [Page 8] Internet-Draft MCP over MOQT March 2026 () 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, , notifications) Track name: () 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 / (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, , elicitation, ) Track name (Server-to-Client): () Track name (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, , logs) Track name: () 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 / (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//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", "", "resources") } The server responds with NAMESPACE messages for each available track: NAMESPACE { Request ID (i) = 1, Track Namespace = ("mcp", "", "resources", "documentation") } NAMESPACE { Request ID (i) = 1, Track Namespace = ("mcp", "", "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", "", "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//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 | | | , | | catalog for | | | skills) | | trigger | | | | | matching | +--------------+---------------+-----------------+-----------------+ | Metadata | (mcp, | metadata | Skill | | | , | | identification, | | | skills, | | triggers, | | | ) | | dependencies | +--------------+---------------+-----------------+-----------------+ | Instructions | (mcp, | instructions | Full prompt | | | , | | text and | | | skills, | | execution logic | | | ) | | | +--------------+---------------+-----------------+-----------------+ | Execution | (mcp, | | Bidirectional | | | , | | streaming for | | | skills, | | active | | | , | | 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, . [MOQT] Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", 16 December 2025, . [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", May 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [WebTransport] Vasiliev, V., "The WebTransport Protocol Framework", June 2023, . 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]