]> Cisco Systems

fluffy@cisco.com

Google

ianswett@google.com

Five9

jdrosen@jdrosen.net

Cisco Systems

snandaku@cisco.com

Applications Model Context Protocol Internet-Draft 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. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Model Context Protocol Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Model Context Protocol (MCP) enables integration between LLM applications and external data sources using JSON-RPC 2.0. Media over QUIC Transport (MOQT) provides efficient publish-subscribe delivery over 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

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 when, and only when, they appear in all capitals, as shown here. This document uses terminology from and .

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.

MCP Lifecycle State Chart

System Components Below figure shows system components proposed in this specification.

│ 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

MOQT Tracks for MCP

Track Types This section defines the track naming conventions and mappings for MCP operations.

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:

, control) ]]>

Track name (Client-to-Server):

Track name (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.

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:

, 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.).

Tool Tracks Tool tracks map MCP tool execution, facilitating tool invocation requests, responses, and progress updates using MOQT's FETCH operations. Track namespace:

, 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.

Prompt Tracks Prompt tracks map MCP prompts, distributing pre-defined templates and instructions that standardize common operations across the MCP ecosystem. Track namespace:

, prompts) ]]>

Track name:

) ]]>

Groups and objects are mapped as follows: Each prompt version is assigned a unique group ID starting from 0, incrementing with each prompt update. Within each group, object ID 0 contains the prompt template and metadata. Objects contain JSON-encoded prompt definitions including template text, parameter schemas, and versioning information.

Notification Tracks Notification tracks map MCP notifications, providing asynchronous event delivery for server-sent notifications, progress updates, and system events. Track namespace:

, 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 <domain>/<type> (e.g., ai/model_updated, workspace/file_changed). Groups and objects are mapped as follows: 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.

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:

, 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 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.

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:

, 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 Component-specific categories may be defined using the pattern <level>/<component> (e.g., error/transport, debug/tools, info/resources) to provide granular filtering capabilities. Groups and objects are mapped as follows: Each log entry creates a new group with group IDs assigned sequentially starting from 0, ordered by log timestamp. Within each group, object ID 0 contains the log entry. Objects contain JSON-encoded log messages including severity level, timestamp, source component, and message content.

Protocol Operation

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 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.

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.

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 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.

Discovery Flow The session discovery process follows this sequence:

Standard Discovery Flow

Optimized Discovery Flow (RTT Reduction)

The optimized flow reduces session establishment from 4 round-trips to 2 by combining discovery and MCP initialization into a single exchange.

Discovery Request Format Clients send FETCH requests to the well-known discovery track with a client-generated nonce or identifier in the payload:

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:

Discovery Response Format The server responds with a JSON-encoded MOQT object containing the newly minted session ID and control track information:

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:

After establishing a session, clients discover available capabilities (resources, tools, prompts, and skills) using the mechanisms described in . After receiving the discovery response, clients subscribe to control tracks and proceed with capability discovery (see ).

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: Priority Range Track Type Example CRITICAL 1-5 Session Control initialize, terminate HIGHEST 6-15 User Elicitation permission prompts HIGH 16-30 Skills/Tool Execution /commit, git operations MEDIUM-HI 31-45 Notifications resource changes MEDIUM 46-60 Skill Instructions prompt loading MEDIUM-LO 61-75 Resources documentation LOW 76-90 Tool Schemas capability metadata LOWEST 91-127 Logs debug, trace 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)

Error Handling Error handling in MCP over MOQT leverages both MOQT's native error mechanisms and MCP's JSON-RPC error responses.

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.

MCP-Level Errors MCP errors are returned as JSON-RPC error responses within MOQT objects:

Standard MCP error codes apply: - -32700: Parse error - -32600: Invalid request - -32601: Method not found - -32602: Invalid params - -32603: Internal error

Skills-Specific Errors Skills execution may encounter additional error conditions: Error Code Description Recovery Action -33001 Skill not found Check registry, refresh cache -33002 Required tool unavailable Verify tool server connectivity -33003 Dependency resolution failed Check skill dependencies -33004 Instruction load timeout Retry with higher priority -33005 Context sharing conflict Resolve context state

Error Recovery Clients SHOULD implement the following recovery strategies: Transient errors: Retry with exponential backoff Session errors: Re-establish MCP session via discovery Resource errors: Invalidate cache and re-fetch Skill errors: Fall back to individual tool operations if possible

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.

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. 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

Capability Discovery After establishing a session (), clients discover available capabilities (resources, tools, prompts, and skills) using two complementary mechanisms: Capability Catalog: Application-level catalog with rich metadata Namespace-Based Discovery: Protocol-level discovery using native MOQT messages Implementations MAY support either or both mechanisms depending on their needs.

Capability Catalog Servers implement capability catalog tracks that enumerate available MCP capabilities and their associated track patterns within a specific session: Track namespace: mcp/<session-id>/discovery Track name: catalog

Clients discover available capabilities by issuing FETCH requests to the catalog track for initial discovery, or SUBSCRIBE for real-time updates when capabilities change.

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.

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:

", "resources") } ]]>

The server responds with NAMESPACE messages for each available track:

", "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 = "" } ]]>

PUBLISH_NAMESPACE for Server Announcements MCP servers use PUBLISH_NAMESPACE to proactively announce track namespace availability to connected clients and relays:

", "tools") } ]]>

Relays receiving PUBLISH_NAMESPACE forward these announcements to interested subscribers, enabling efficient fan-out of capability updates.

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:

Choosing a Discovery Mechanism Use Case Recommended Approach Rich metadata needed (content types, caching hints) Capability Catalog Simple track enumeration Namespace-Based Relay aggregation scenarios Namespace-Based Legacy MOQT implementations (pre-draft-16) Capability Catalog Minimal protocol overhead Namespace-Based

Relay Namespace Aggregation Relays can aggregate namespace information from multiple upstream servers and present a unified namespace view to downstream clients:

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.

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

Skills Track Structure and Data Formats Skills use a hierarchical track namespace under mcp/<session-id>/skills/: Track Namespace Name Purpose Registry (mcp, <session-id>, skills) registry Complete skill catalog for trigger matching Metadata (mcp, <session-id>, skills, <skill-id>) metadata Skill identification, triggers, dependencies Instructions (mcp, <session-id>, skills, <skill-id>) instructions Full prompt text and execution logic Execution (mcp, <session-id>, skills, <skill-id>, execution) <invocation-id> Bidirectional streaming for active invocations 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.

Skills Invocation Protocol

Invocation Flow

Streaming Skill Execution with Progress

Skills Execution Request Format

Skills Execution Response Stream

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:

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

Security Considerations TODO

IANA Considerations TODO

Examples

Basic Session Establishment This example shows a minimal MCP session establishment over MOQT:

Tool Execution Example Executing a file read tool:

Skill Invocation Example Invoking the /commit skill with progressive loading:

Multi-Server Skill Workflow A deployment workflow using skills from multiple servers:

Cisco Google Google Meta Anthropic PBC Fastly Mozilla In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Google

Acknowledgments TODO