Model Context Protocol C. Jennings Internet-Draft Cisco Systems Intended status: Experimental I. Swett Expires: 23 April 2026 Google J. Rosenberg Five9 S. Nandakumar Cisco Systems 20 October 2025 Model Context Protocol over Media over QUIC Transport draft-mcp-over-moqt-00 Abstract This document defines how to use Media over QUIC Transport (MOQT) as the underlying transport protocol for the Model Context Protocol (MCP). MCP 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. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://example.org/mcp-moqt/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-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. Jennings, et al. Expires 23 April 2026 [Page 1] Internet-Draft MCP over MOQT October 2025 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 23 April 2026. Copyright Notice Copyright (c) 2025 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1. Current Transport Challenges . . . . . . . . . . . . 4 1.1.2. MCP over MOQT . . . . . . . . . . . . . . . . . . . . 5 1.1.3. Operational Advantages . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 1.3.1. MCP Lifecycle State Chart . . . . . . . . . . . . . . 7 1.3.2. System Components . . . . . . . . . . . . . . . . . . 8 2. MOQT Tracks for MCP . . . . . . . . . . . . . . . . . . . . . 9 2.1. Control Flow . . . . . . . . . . . . . . . . . . . . . . 9 2.1.1. Client-to-Server Control Track . . . . . . . . . . . 9 2.1.2. Server-to-Client Control Track . . . . . . . . . . . 9 2.2. Track Types . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.1. Control Tracks . . . . . . . . . . . . . . . . . . . 10 2.2.2. Resource Tracks . . . . . . . . . . . . . . . . . . . 10 2.2.3. Tool Tracks . . . . . . . . . . . . . . . . . . . . . 11 2.2.4. Prompt Tracks . . . . . . . . . . . . . . . . . . . . 11 2.2.5. Notification Tracks . . . . . . . . . . . . . . . . . 12 2.2.6. Elicitation Tracks . . . . . . . . . . . . . . . . . 13 Jennings, et al. Expires 23 April 2026 [Page 2] Internet-Draft MCP over MOQT October 2025 2.2.7. Log Tracks . . . . . . . . . . . . . . . . . . . . . 14 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 15 3.1. MOQT Session Establishment . . . . . . . . . . . . . . . 15 3.2. Proposed Session ID Discovery . . . . . . . . . . . . . . 15 3.2.1. Well-Known Discovery Track . . . . . . . . . . . . . 15 3.2.2. Discovery Flow . . . . . . . . . . . . . . . . . . . 16 3.2.3. Discovery Request Format . . . . . . . . . . . . . . 17 3.2.4. Discovery Response Format . . . . . . . . . . . . . . 19 3.2.5. Session Establishment Flow . . . . . . . . . . . . . 22 3.3. Priority Management . . . . . . . . . . . . . . . . . . . 23 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 23 4. Relay Support . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1. Subscription Aggregation . . . . . . . . . . . . . . . . 23 4.1.1. Resource Subscription Aggregation . . . . . . . . . . 24 4.1.2. Tool Metadata Aggregation . . . . . . . . . . . . . . 24 4.2. Content Caching for MCP and AI Workflows . . . . . . . . 24 4.2.1. Static Resources and Documentation . . . . . . . . . 24 4.2.2. Tool Schema and Configuration Caching . . . . . . . . 25 4.2.3. Capability Information and Session Metadata . . . . . 25 4.2.4. Model Context and History Caching . . . . . . . . . . 25 4.3. Track Name Discovery and Dynamic Updates . . . . . . . . 25 4.3.1. Discovery Track Implementation . . . . . . . . . . . 26 4.3.2. Client Discovery via FETCH Operations . . . . . . . . 26 4.3.3. Asynchronous Updates via Subscriptions . . . . . . . 27 5. Agent Skills and MCP Integration . . . . . . . . . . . . . . 27 5.1. Skills Architecture Overview . . . . . . . . . . . . . . 27 5.2. Skills Transport over MOQT . . . . . . . . . . . . . . . 27 5.3. Skills Composition and Workflow Integration . . . . . . . 29 6. Shared Context Between One MCP Client and Multiple MCP Servers . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. Context Sharing Architecture . . . . . . . . . . . . . . 30 6.1.1. Session Isolation and Coordination . . . . . . . . . 30 6.2. Context Synchronization Mechanisms . . . . . . . . . . . 30 6.2.1. Resource Context Sharing . . . . . . . . . . . . . . 30 6.2.2. Tool Execution Context . . . . . . . . . . . . . . . 30 6.3. Context Synchronization Benefits . . . . . . . . . . . . 30 6.3.1. Shared Subscription Management . . . . . . . . . . . 31 6.3.2. Context Caching and Reuse . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . 31 10.2. Informative References . . . . . . . . . . . . . . . . . 32 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Jennings, et al. Expires 23 April 2026 [Page 3] Internet-Draft MCP over MOQT October 2025 1. Introduction The Model Context Protocol (MCP) [MCP] is an open protocol that enables seamless integration between LLM applications and external data sources and tools. MCP uses JSON-RPC 2.0 for message exchange and can operate over various transport protocols. Media over QUIC Transport (MOQT) [MOQT] is a protocol optimized for QUIC [QUIC] that provides efficient publish-subscribe media delivery with support for content distribution networks and low-latency requirements. This document outlines the use of MOQT as the transport layer for MCP, utilizing MOQT's object delivery and QUIC's multiplexed streams for low-latency communication. Paired unidirectional tracks enable real-time interactions between language models and external systems. MOQT's object-based delivery allows efficient resource and tool sharing across clients without redundant transfers. Relay networks support scalable content distribution, enabling global MCP deployment with optimized performance. Native prioritization ensures critical operations like tool execution and user interactions receive sufficient bandwidth. QUIC's connection migration and recovery provide reliable connectivity in mobile and unstable networks. 1.1. Motivation The Model Context Protocol (MCP) enables AI applications to integrate with external data sources and tools, but current transport mechanisms poses challenges that can hinder optimal performance and scalability. This specification addresses these challenges by leveraging Media over QUIC Transport (MOQT) as an alternate transport layer specifically optimized for MCP's operational requirements. 1.1.1. Current Transport Challenges WebSocket Transport lacks native prioritization mechanisms, causing critical control messages and urgent tool operations to compete equally with routine resource updates. Head-of-line blocking occurs when large resource transfers delay time-sensitive operations, and the protocol provides no built-in caching or relay capabilities for scalable content distribution. HTTP Transport operates on a strict request-response model that conflicts with MCP's inherently event-driven architecture. This mismatch forces artificial polling patterns for resource updates and prevents efficient server-initiated notifications. While Server Side Streaming provides a mechanism for servers to send asynchronous Jennings, et al. Expires 23 April 2026 [Page 4] Internet-Draft MCP over MOQT October 2025 events, it introduces significant challenges including connection complexity, limited browser support, proxy interference, and difficultly in handling bidirectional communication patterns essential for interactive MCP operations. Additionally, HTTP/1.1's connection limitations and HTTP/2's stream dependencies create bottlenecks in high-throughput AI applications. 1.1.2. MCP over MOQT MOQT's publish-subscribe architecture provides an ideal foundation for MCP operations, where MCP servers naturally function as publishers of resources, tools, and capabilities, while clients subscribe to relevant content streams. This alignment enables several key architectural benefits: *Semantic Mapping*: MCP's resource-centric model maps directly to MOQT's track-based content organization. Each resource, tool, or capability becomes a dedicated track with independent lifecycle management, version control, and access policies. *Event-Driven Communication*: MOQT's native support for asynchronous object delivery matches MCP's notification-based architecture, eliminating the artificial request-response constraints imposed by HTTP transport. *Priority-Aware Delivery*: MOQT's built-in prioritization system enables sophisticated quality-of-service policies, ensuring that critical MCP operations like tool execution and user interactions receive appropriate bandwidth allocation and reduced latency. 1.1.3. Operational Advantages The combination of MCP and MOQT can offer operational improvements along the following dimensions: Low Latency Operations: MOQT's object-based delivery model eliminates traditional HTTP request-response overhead, enabling direct message passing with minimal protocol overhead. Tool execution requests are sent as prioritized FETCH operations while control messages receive the highest priority (1-2), ensuring responsive interaction even under high system load. Bandwidth Efficiency: MOQT relays provide sophisticated caching mechanisms and subscription aggregations, that deduplicate frequently accessed resources across multiple clients. Large documentation sets, configuration files, and static assets are cached at relay points, dramatically reducing origin server load while enabling selective updates through version-aware object delivery. Jennings, et al. Expires 23 April 2026 [Page 5] Internet-Draft MCP over MOQT October 2025 Multiplexing and Concurrency: QUIC's multiplexing capabilities prevent head-of-line blocking between different MCP operations, allowing hundreds of concurrent tool executions, resource subscriptions, and notification streams to operate independently without mutual interference. Network Resilience and Mobility: QUIC's connection migration and 0-RTT reconnection capabilities maintain session continuity across network changes, a critical requirement for mobile AI applications and long-running workflows that may experience network interruptions. Edge-Optimized Content Distribution: The relay infrastructure supports geographically distributed caching and intelligent content placement, enabling global MCP deployments with optimized performance characteristics tailored to regional access patterns and data locality requirements. 1.2. 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]. 1.3. Protocol Overview MCP uses MOQT to map its abstractions to MOQT's transport mechanisms. MCP messages, encoded as JSON-RPC 2.0, are embedded in MOQT payloads, ensuring compatibility with MCP formats and efficient transport over QUIC streams. MCP sessions use MOQT sessions for communication, starting with a handshake to negotiate capabilities. This phase ensures clients and servers agree on features, resource types, and parameters. MCP Resources are server-controlled data sources exposed to clients for read access. In MOQT, each resource is published over *resources* track. Content is delivered via MOQT objects, supporting various data types like files, API responses, database results, and version control history. Streaming enables efficient handling of large resources, while automatic updates use new objects with updated sequence numbers for incremental changes. This supports advanced caching and efficient client synchronization. Jennings, et al. Expires 23 April 2026 [Page 6] Internet-Draft MCP over MOQT October 2025 Tools enable servers to execute client-requested operations. MOQT maps tools to dedicated *tools* tracks and uses FETCH for request- response patterns. Supported operations include API calls, file tasks, computations, and service integrations. Progress tracking uses notifications for real-time updates. FETCH ensures robust execution with prioritization, multiplexing, error handling, and timeout management. Notifications about resource changes and events are published in specialized tracks, allowing clients to subscribe without affecting other channels. User input is managed through interactive control tracks for consent and data collection. 1.3.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 │ └──────┬──────┘ Jennings, et al. Expires 23 April 2026 [Page 7] Internet-Draft MCP over MOQT October 2025 │ Discovery Complete ▼ ┌─────────────┐ ┌──────────▶│ MCP ACTIVE │◀──────────┐ │ │ │ │ │ └─────┬───┬───┘ │ │ │ │ │ │ Tool Result │ │ Notification │ Resource Update │ │ │ │ ▼ │ ▼ │ ┌─────────────┐ │ ┌─────────────┐ │ │ TOOL │ │ │ ELICITATION │ │ │ EXECUTING │──────────┘ │ PENDING │ │ └─────────────┘ └─────────────┘ │ │ │ │ └─────────────────────────┼───────────┘ │ ▼ ┌─────────────┐ │ SESSION │ │ TERMINATING │ └──────┬──────┘ │ Cleanup ▼ ┌─────────────┐ │ DISCONNECTED│ └─────────────┘ 1.3.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: Jennings, et al. Expires 23 April 2026 [Page 8] Internet-Draft MCP over MOQT October 2025 * *MCP Host*: Acts as MOQT client, managing multiple server connections * *MCP Client*: Implemented as MCP transport adapter within the host * *MCP Server*: Acts as MOQT publisher, exposing resources, tools, and prompts 2. MOQT Tracks for MCP 2.1. Control Flow The control flow establishes the fundamental communication channels for MCP session management and coordination. This specifcation prposes 2 unidirectional tracks for direction for performing session establishment, capability negotiation, and various control operations using the MOQT's publish-subscribe semantics. 2.1.1. Client-to-Server Control Track * *Publisher*: MCP Client * *Subscribers*: MCP Server, optional monitoring relays * *Content*: - MCP initialize requests - Ping messages (client-initiated) - Capability negotiation requests - Session teardown requests - Tool cancellation requests 2.1.2. Server-to-Client Control Track * *Publisher*: MCP Server * *Subscribers*: MCP Client, optional monitoring relays * *Content*: - MCP initialize responses - Pong messages (server responses) Jennings, et al. Expires 23 April 2026 [Page 9] Internet-Draft MCP over MOQT October 2025 - Capability negotiation responses - Session teardown confirmations - Server-initiated status updates 2.2. Track Types The various sub-sections provides information on track naming design defined by this specification to map to MCP operations. 2.2.1. Control Tracks Control tracks map MCP session management and coordination messages including initialization, ping/pong heartbeats, and capability negotiation and 2 unidirectional tracks for server and client to carryout message exchanges. 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.2.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: (mcp, , resources) Jennings, et al. Expires 23 April 2026 [Page 10] Internet-Draft MCP over MOQT October 2025 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.2.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.2.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 23 April 2026 [Page 11] Internet-Draft MCP over MOQT October 2025 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.2.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 23 April 2026 [Page 12] Internet-Draft MCP over MOQT October 2025 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.2.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 23 April 2026 [Page 13] Internet-Draft MCP over MOQT October 2025 * 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.2.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 23 April 2026 [Page 14] Internet-Draft MCP over MOQT October 2025 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 23 April 2026 [Page 15] Internet-Draft MCP over MOQT October 2025 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 23 April 2026 [Page 16] Internet-Draft MCP over MOQT October 2025 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) │ │────────────────────────────▶│ 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 23 April 2026 [Page 17] Internet-Draft MCP over MOQT October 2025 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"] } } } } 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 23 April 2026 [Page 18] Internet-Draft MCP over MOQT October 2025 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"], "mcp_initialize": { "protocolVersion": "2025-06-18", "capabilities": { "resources": { "subscribe": true }, "tools": { "progress": true }, "prompts": {}, "elicitation": {} }, "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 available track information: Jennings, et al. Expires 23 April 2026 [Page 19] Internet-Draft MCP over MOQT October 2025 { "jsonrpc": "2.0", "id": 1, "result": { "session_id": "session-uuid-456", "server_info": { "name": "ExampleServer", "version": "2.0.0", "protocol_version": "2025-06-18" }, "available_tracks": { "control": { "client_to_server": "mcp/session-uuid-456/control/client-to-server", "server_to_client": "mcp/session-uuid-456/control/server-to-client" }, "resources": [ { "name": "documentation", "track": "mcp/session-uuid-456/resources/documentation", "content_type": "text/markdown", "description": "API documentation and guides" } ], "tools": [ { "name": "file_operations", "track": "mcp/session-uuid-456/tools/file_operations", "description": "File system operations" } ], "prompts": [ { "name": "code_review", "track": "mcp/session-uuid-456/prompts/code_review", "description": "Code review prompt templates" } ] }, "session_expires": "2025-06-18T12:00:00Z" } } Jennings, et al. Expires 23 April 2026 [Page 20] Internet-Draft MCP over MOQT October 2025 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: { "jsonrpc": "2.0", "id": 1, "result": { "session_id": "session-uuid-456", "server_info": { "name": "ExampleServer", "version": "2.0.0", "protocol_version": "2025-06-18" }, "available_tracks": { "control": { "client_to_server": "mcp/session-uuid-456/control/client-to-server", "server_to_client": "mcp/session-uuid-456/control/server-to-client" }, "resources": [ { "name": "documentation", "track": "mcp/session-uuid-456/resources/documentation", "content_type": "text/markdown", "description": "API documentation and guides" } ], "tools": [ { "name": "file_operations", "track": "mcp/session-uuid-456/tools/file_operations", "description": "File system operations" } ], "prompts": [ { "name": "code_review", "track": "mcp/session-uuid-456/prompts/code_review", "description": "Code review prompt templates" } ] }, "session_expires": "2025-06-18T12:00:00Z", "mcp_initialize_response": { Jennings, et al. Expires 23 April 2026 [Page 21] Internet-Draft MCP over MOQT October 2025 "protocolVersion": "2025-06-18", "capabilities": { "resources": { "subscribe": true, "listChanged": true }, "tools": { "progress": true }, "prompts": { "listChanged": true }, "elicitation": {} }, "serverInfo": { "name": "ExampleServer", "version": "2.0.0" } } } } 3.2.5. Session Establishment Flow After receiving the discovery response, clients proceed with MCP session establishment using the provided session ID. The flow depends on whether the RTT optimization was used: 3.2.5.1. Standard Discovery Flow 1. Track Subscription: Client subscribes to the control tracks using the session ID from the discovery response 2. MCP Initialize: Client sends the standard MCP initialize message on the client-to-server control track 3. Capability Negotiation: Server responds with its capabilities on the server-to-client control track 4. Session Active: Client begins normal MCP operations using the discovered tracks and session ID 3.2.5.2. Optimized Discovery Flow (with combined initialize) 1. Track Subscription: Client subscribes to the control tracks using the session ID from the discovery response 2. Session Active: Since MCP initialization was completed during discovery, the client can immediately begin normal MCP operations using the discovered tracks and negotiated capabilities The RTT optimization reduces the session establishment from 4 round- trips to 2 round-trips by combining discovery and initialization operations. Jennings, et al. Expires 23 April 2026 [Page 22] Internet-Draft MCP over MOQT October 2025 3.3. Priority Management MOQT's object priorities optimize MCP message delivery by considering the importance of different track types specified. The following priority assignments are RECOMMENDED, but applications may adjust them as needed. 1. Control Messages: Highest priority (1-10) 2. Tool Operations: High priority (20-30) 3. Notifications: Medium priority (40-60) 4. Resource Operations: Lower priority (70-90) 5. Logs: Lowest priority (100+) Priorities can also be adjusted based on: * User interaction urgency (elicitation requests get higher priority) * Tool execution criticality (error handling gets priority boost) * Resource size and frequency (large resources get lower priority) * Server load conditions (adaptive priority scaling) 3.4. Error Handling TODO 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 MOQT relays provide significant efficiency gains by aggregating multiple client subscriptions to the same content into single upstream requests. When multiple clients subscribe to identical MCP resources, tools metadata, or notification streams, the relay consolidates these into a single subscription to the origin server, dramatically reducing server load and network bandwidth consumption. Jennings, et al. Expires 23 April 2026 [Page 23] Internet-Draft MCP over MOQT October 2025 4.1.1. Resource Subscription Aggregation When multiple clients subscribe to the same resource track, the relay maintains a single upstream subscription and fans out content to all interested clients: Client A subscribes: mcp/{session-id}/resources/documentation Client B subscribes: mcp/{session-id}/resources/documentation Client C subscribes: mcp/{session-id}/resources/documentation Relay behavior: - Single upstream subscription: mcp/{session-id}/resources/documentation - Fan-out to 3 downstream clients - Bandwidth savings: 3x reduction in server load The relay tracks subscription interest levels and automatically establishes upstream subscriptions when the first client subscribes to a track, and tears down the upstream subscription when the last client unsubscribes. 4.1.2. Tool Metadata Aggregation Tool discovery operations benefit significantly from aggregation since multiple clients typically need access to the same tool schemas and capabilities TODO: Add an examples 4.2. Content Caching for MCP and AI Workflows 4.2.1. Static Resources and Documentation Large documentation sets, API references, and knowledge bases represent the most cache-friendly content in MCP deployments. These resources are accessed frequently across multiple AI sessions but change infrequently, making them ideal candidates for aggressive caching. Static resources are delivered through dedicated tracks like mcp/{session-id}/resources/{resource-uri} and benefit significantly from relay caching since multiple clients often access the same content. Jennings, et al. Expires 23 April 2026 [Page 24] Internet-Draft MCP over MOQT October 2025 4.2.2. Tool Schema and Configuration Caching Tool schemas, parameter definitions, and configuration metadata are cached aggressively since they define the stable interface contracts between AI applications and external services. This metadata is cached with high TTL values, allowing relays to serve tool discovery requests without repeatedly querying the origin server. Schema definitions are published as MOQT objects that remain valid until tools are modified or removed, making them ideal candidates for aggressive aching policies. In case of modifications, new updated schema definitions are published with updated versioning info, 4.2.3. Capability Information and Session Metadata Server capability announcements that define supported features, resource types, and operational parameters negotiated during session establishment are cached via mcp/{session-id}/control/capabilities tracks as one-time objects published after MCP initialization, enabling relays to quickly respond to capability queries without server involvement. The caching strategy uses long-term storage with explicit invalidation only on server restart or capability changes. Session metadata comprises initialization parameters, connection preferences, and configuration data that define session characteristics and relay behavior. This metadata is distributed through mcp/{session-id}/control/metadata tracks as cacheable objects, with relay configuration parameters embedded in SERVER_SETUP message extensions. The cached metadata enables consistent session behavior across client reconnections and provides relays with the information needed for optimal routing and caching decisions. 4.2.4. Model Context and History Caching For AI workflows that involve multi-turn conversations or context building, relays can cache conversation contexts and interaction histories to support session resumption and context sharing: 4.3. Track Name Discovery and Dynamic Updates MOQT relays enhance the MCP experience by providing efficient service-level discovery mechanisms that help clients understand available resources, tools, and services within established MCP sessions without requiring prior configuration knowledge. Jennings, et al. Expires 23 April 2026 [Page 25] Internet-Draft MCP over MOQT October 2025 4.3.1. Discovery Track Implementation Relays implement service-level discovery tracks that catalog available MCP services and their associated track patterns within a specific session: Track namespace: mcp//discovery Track name: catalog { "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" } 4.3.2. Client Discovery via FETCH Operations Clients can efficiently discover available services by issuing FETCH requests to discovery tracks, receiving comprehensive information about available MCP capabilities Jennings, et al. Expires 23 April 2026 [Page 26] Internet-Draft MCP over MOQT October 2025 4.3.3. Asynchronous Updates via Subscriptions Beyond one-time discovery, clients can subscribe to discovery tracks to receive real-time updates when new services become available or existing services change their characteristics This subscription-based discovery update mechanism ensures that AI applications can dynamically adapt to changing service availability without requiring configuration changes or manual intervention. 5. Agent Skills and MCP Integration Agent Skills represent a powerful extension to the MCP ecosystem, providing modular capabilities that can be efficiently delivered and managed through MOQT's transport mechanisms. This section describes how Skills integrate with MCP over MOQT. 5.1. Skills Architecture Overview Agent Skills are filesystem-based resources that extend AI capabilities through three progressive loading levels, along the following dimensions: * Always loading metadata Loading (~100 tokens) provides basic skill identification and capabilities * Dynamicaly loading instructionns when triggered (under 5k tokens) containing skill logic and execution parameters * Resources and Code are loaded as needed for actual skill execution and data processing This progressive disclosure model aligns naturally with MOQT's object-based delivery system, where each loading level can be mapped to separate MOQT objects or tracks for optimal bandwidth utilization. 5.2. Skills Transport over MOQT Skills metadata is distributed through dedicated discovery tracks that enable clients to understand available capabilities without loading full skill implementations: Track namespace: mcp//skills Track name: catalog The skills catalog provides comprehensive metadata about available skills, their capabilities, dependencies, and loading requirements: Jennings, et al. Expires 23 April 2026 [Page 27] Internet-Draft MCP over MOQT October 2025 { "available_skills": [ { "skill_id": "powerpoint-processor", "name": "PowerPoint Processing", "description": "Create and modify PowerPoint presentations", "metadata_size": 95, "instructions_size": 4200, "resource_dependencies": ["office-templates", "style-schemas"], "security_level": "trusted", "loading_priority": "on-demand" }, { "skill_id": "pdf-analyzer", "name": "PDF Analysis", "description": "Extract and analyze content from PDF documents", "metadata_size": 87, "instructions_size": 3800, "resource_dependencies": ["pdf-schemas"], "security_level": "sandboxed", "loading_priority": "preload" } ], "catalog_version": "1.2.0", "last_updated": "2025-06-18T10:30:00Z" } Skills leverage MOQT's object-based delivery for efficient progressive loading: Each skill's metadata is delivered as a single MOQT object containing basic capability information, version data, and loading requirements. Track namespace: `mcp//skills/` Track name: `metadata` When a skill is activated, its instruction set is loaded through dedicated objects containing execution logic, parameter schemas, and operational guidelines. Track namespace: `mcp//skills/` Track name: `instructions` Skill resources such as templates, schemas, and code modules are loaded on-demand through separate resource tracks, enabling fine- grained loading control. Jennings, et al. Expires 23 April 2026 [Page 28] Internet-Draft MCP over MOQT October 2025 Track namespace: `mcp//skills/` Track name: `resources/` 5.3. Skills Composition and Workflow Integration Complex workflows can compose multiple skills together, with MOQT providing efficient coordination: * Dependency Resolution: Skills declare dependencies that are automatically resolved through catalog metadata * Execution Orchestration: Workflow engines can preload skill sets based on anticipated execution patterns * Resource Sharing: Common skill resources are shared across workflow steps to minimize loading overhead Skills can share context and state through dedicated context tracks: Track namespace: mcp//skills/context Track name: This enables sophisticated multi-step workflows where skills build upon each other's outputs while maintaining clean separation of concerns. MOQT relays implement sophisticated caching for skill distribution: * Metadata Caching: Skill catalogs cached with high TTL for quick discovery * Instruction Caching: Frequently used skills cached at edge locations * Resource Deduplication: Common skill resources shared across multiple skills * Version Management: Skill updates distributed efficiently through version-aware object delivery AI applications can implement predictive skill loading based on user patterns and workflow analysis, using MOQT's subscription management to preload likely-needed skills while avoiding bandwidth waste. Jennings, et al. Expires 23 April 2026 [Page 29] Internet-Draft MCP over MOQT October 2025 6. Shared Context Between One MCP Client and Multiple MCP Servers When a single MCP client connects to multiple MCP servers simultaneously, shared context management becomes critical for maintaining consistency, efficiency, and proper resource allocation across all active sessions. This section describes the mechanisms and considerations for managing shared context in multi-server MCP deployments over MOQT. 6.1. Context Sharing Architecture In a shared context scenario, the MCP client acts as a central coordinator that maintains relationships with multiple MCP servers, each providing different capabilities, resources, or specialized services. The client must manage session state, resource subscriptions, and context information across all servers while ensuring proper isolation and security boundaries. 6.1.1. Session Isolation and Coordination Each MCP server connection maintains its own unique session ID and track namespace to ensure proper 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 separate sessions while maintaining a unified view of available capabilities across all connected servers. 6.2. Context Synchronization Mechanisms 6.2.1. Resource Context Sharing When multiple servers provide related resources, the client can implement context synchronization by subscribing to relevant resource tracks from multiple servers and maintaining a unified context state. 6.2.2. Tool Execution Context Tool executions across multiple servers may require shared context to maintain workflow consistency. Tracking tool execution state across all severs help ensure proper sequencing of multi-server workflows. Similarly results from tools on one server can be automatically passed as parameters to tools on other servers, for example. 6.3. Context Synchronization Benefits Jennings, et al. Expires 23 April 2026 [Page 30] Internet-Draft MCP over MOQT October 2025 6.3.1. Shared Subscription Management The client optimizes network usage by implementing intelligent subscription management across multiple servers: * When multiple servers offer similar resources, the client can subscribe to the most appropriate source based on performance, recency, or quality metrics * Resource requests can be distributed across servers based on current load, response time, or geographic proximity * If one server becomes unavailable, the client can seamlessly redirect subscriptions to alternative servers providing similar capabilities 6.3.2. Context Caching and Reuse The client implements sophisticated caching strategies that work across all connected servers: * Context information cached from one server can be reused when working with other servers, where appropriate. * The client tracks resource versions across all servers to ensure cache consistency * Only changed context elements are synchronized across servers to minimize bandwidth usage 7. Security Considerations TODO 8. IANA Considerations TODO 9. Examples 10. References 10.1. Normative References [MCP] Anthropic, "Model Context Protocol Specification", 18 June 2025, . Jennings, et al. Expires 23 April 2026 [Page 31] Internet-Draft MCP over MOQT October 2025 [MOQT] Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", 23 June 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, . 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 23 April 2026 [Page 32]