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