]> Cisco

fluffy@cisco.com

Google

ianswett@google.com

Five9

jdrosen@jdrosen.net

Cisco

snandaku@cisco.com

Applications and Real-Time Agent Communication Protocols MCP MOQT AI agents agentproto 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 tracks. It covers MCP's tools, resources, prompts, multi round-trip requests, and the Tasks extension, and it uses MOQT relays to cache content that MCP marks as public across clients and to let a response outlive the connection that carried its request. 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. The same tracks can run standalone or inside a dialog of the Protocol for Agent Communication Exchange (PACE). About This Document 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 Agent Communication Protocols Working Group mailing list (), which is archived at . Subscribe 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 over pluggable transports. Media over QUIC Transport (MOQT) provides publish-subscribe delivery over QUIC with relay support. MCP is stateless: every request carries its protocol version and the client's capabilities, and servers keep no per-connection session. That model fits MOQT well. MCP's existing transports have limitations that MOQT addresses:

• Streamable HTTP: A broken response stream loses the in-flight request, which the client must re-issue as a new request. There is no per-message prioritization, and shared caching is limited to what HTTP intermediaries provide.
• stdio: Single-process only; no network distribution.

MOQT provides:

• Recovery: A response is published into a known group, so a client that reconnects receives the rest of it instead of re-issuing the request ().
• Shared caching: Content that MCP marks as public, such as the server's capabilities and tool definitions, is published once and served to every client from relay caches ().
• Edge serving: A publisher tells relays how long they may cache each track's objects, so FETCH and fill fetch, including a reconnecting client's catch-up, are answered by the nearest relay instead of the server ().
• Priority-aware delivery: Critical operations receive appropriate bandwidth via per-object priorities.
• Multiplexing without HOL blocking: QUIC streams prevent interference between concurrent operations.
• Network resilience: QUIC connection migration.

Relationship to PACE The Protocol for Agent Communication Exchange (PACE) is a dialog-management protocol for agent communication over MOQT. Application-layer agent protocols such as MCP and A2A run inside a PACE dialog as bindings, and PACE's MCP binding adopts the track semantics, operation mapping, and relay behavior defined in this document. This specification therefore serves two deployment modes:

• Standalone: MCP over MOQT using the (mcp, <server-id>, ...) namespace defined in .
• Within PACE: the same tracks are carried inside a PACE dialog, as described in .

Both modes use the same MOQT primitives and the same encoding; they differ only in namespace layout.

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 , including Track Namespace, Track Name, and Full Track Name as defined in . Additionally:

• Name notation: A Track Namespace is written as (field1, field2, ...) in normative definitions and as field1/field2/... in prose. A Full Track Name is written (field1, field2, ...) -- (name). These are informal notations of this document, not the serialized formats of ; a / that appears inside a field or Track Name (for example, in a resource URI) is part of that field.
• Server ID: An identifier of an MCP server, used as the second field of every namespace this document defines ().
• Client ID: A pairwise identifier of an MCP client at one server ().
• Server scope / client scope: The namespaces under (mcp, <server-id>) that all clients of a server share, and the namespaces under (mcp, <server-id>, clients, <client-id>) that belong to one client ().
• Request track / response track: A pair of tracks used for one kind of JSON-RPC exchange. The client publishes the request track and the server publishes the response track (see ).

Protocol Overview MCP maps to MOQT tracks for the catalog, control, tools, prompts, resources, tasks, and skills (). A client needs no handshake: after MOQT setup it derives its client ID, subscribes to the server's tracks, and starts sending requests. Every request carries the per-request _meta fields of ; the examples in this document omit them for brevity. JSON-RPC requests and responses are carried on request and response tracks (). Each MOQT object carries one payload, with no framing beyond the object boundaries. The payload is one of:

• One MCP JSON-RPC 2.0 message, as UTF-8 encoded JSON, on control, request, and response tracks.
• One UTF-8 encoded JSON document on catalog, task, and skill tracks, with the content defined for each track.
• A chunk of the resource's content on resource tracks (). The resource's media type is given in the catalog ().

System Components | 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: Exposes resources, tools, and prompts

Both the MCP client and the MCP server are MOQT publishers and subscribers: each publishes the tracks it owns () and subscribes to its peer's.

MOQT Tracks for MCP

Server and Client Scopes Every namespace defined by this document begins with (mcp, <server-id>). A client learns the server ID from configuration, from the server's moqt:// URI, from a registry or Poppy entry (), or, where a relay offers one, from a server listing (). Tracks fall into two scopes:

• Server scope, (mcp, <server-id>, ...) without a clients field: tracks the server publishes once for all of its clients. They carry only content whose MCP cacheScope is public: the catalog, public resources, and skills. Relays serve them to every client from cache.
• Client scope, (mcp, <server-id>, clients, <client-id>, ...): tracks that belong to one client. They carry the client's requests, the server's responses, task status, and any content whose cacheScope is private. Only that client and the server can publish or subscribe to them ().

The client scope is a routing and authorization boundary, not MCP state. A server MUST NOT use it in place of the per-request _meta fields, which requires on every request.

Client ID A client ID is a pairwise identifier: a client uses a different, unlinkable ID at each server. A client derives it from a secret key K that it holds and the server ID: The derivation gives the same ID every time the client connects to the same server, without the client storing any per-server state, so responses and tasks carry over a reconnection (). Two servers cannot link a client by its IDs. A client that wants a fresh identity at a server changes K, or derives the ID from a key specific to that server. A client MAY instead generate a random 128-bit ID per server and store it. A client ID is not a credential. The server binds a client ID to the authenticated principal of the first request it receives in that client scope, and MUST reject requests in that scope from any other principal, except a party to which that principal has delegated a task (), within that task's scope. Relays authorize access to a client scope as described in .

Catalog Track The catalog is the server's capability listing, published in the server scope. Track namespace: (mcp, <server-id>) Track name: (catalog) Each catalog version is a new group whose Object 0 is a JSON object (). A server whose listings differ between clients publishes those listings in a catalog track in each client scope instead, (mcp, <server-id>, clients, <client-id>) -- (catalog), and the client uses it in preference to the shared catalog.

Control Tracks The control tracks carry every MCP request that has no dedicated track below. They are an ordinary request/response pair (). Track namespace: (mcp, <server-id>, clients, <client-id>, control) Control Tracks

Direction	Track Name	Publisher	Content
Client-to-Server	(request)	MCP Client	requests listed below
Server-to-Client	(response)	MCP Server	responses

The control request track carries the following MCP requests. The first two rows are also available from the catalog (), so a client that subscribes to the catalog does not need them. Requests on the Control Tracks

Purpose	Requests
Discovery (also in the catalog)	server/discover
Listing (also in the catalog)	tools/list, resources/list, resources/templates/list, prompts/list
Resources not on a resource track	resources/read
Completion	completion/complete
Tasks (also on the task's state track)	tasks/get

Tool Tracks Tool tracks carry tool invocation requests and responses. Each tool has its own request/response track pair (), so access to an individual tool can be authorized by namespace. Track namespace: (mcp, <server-id>, clients, <client-id>, tools, <tool-name>) Tool Tracks

Direction	Track Name	Publisher	Content
Client-to-Server	(request)	MCP Client	tools/call requests
Server-to-Client	(response)	MCP Server	progress notifications and the tool result

Each invocation creates a new group on the request track. Object 0 of that group contains the JSON-RPC tools/call request. The server publishes the response in the group with the same Group ID on the response track: zero or more progress notifications followed by the final JSON-RPC result or error, which has the highest Object ID in the group (). The final result is a complete result, an input-required result (), or, with the Tasks extension, a task handle (). A server can use several subgroups within a response group to send parts of a tool response in parallel, each on its own QUIC stream. For example, it can send progress notifications in one subgroup while it streams a large result in another, so neither waits for the other and loss on one stream does not stall the rest (). A client cancels an in-flight invocation as described in . Tool definitions are not carried on these tracks; they are published in the catalog ().

Prompt Tracks Prompt tracks carry prompts/get requests and responses. Each prompt has its own request/response track pair (), as tools do, so access to an individual prompt can be authorized by namespace and given its own priority. Track namespace: (mcp, <server-id>, clients, <client-id>, prompts, <prompt-name>) Prompt Tracks

Direction	Track Name	Publisher	Content
Client-to-Server	(request)	MCP Client	prompts/get requests
Server-to-Client	(response)	MCP Server	the prompt result

Each request creates a new group on the request track, and the server publishes the result, which can be an input-required result (), in the group with the same Group ID on the response track. Prompt definitions are published in the catalog ().

Resource Tracks Resource tracks deliver server-published content (files, API schemas, database results) that MCP exposes as read-only data sources. Track namespace: (mcp, <server-id>, resources) for public resources, or (mcp, <server-id>, clients, <client-id>, resources) for private ones Track name: (<resource-uri>) 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. The server ends the group when it has published the whole version, so a receiver knows the resource is complete. A server can spread the chunks of a large resource over several subgroups of the group, each on its own QUIC stream, so that parts of the resource are sent in parallel and loss on one stream does not stall the others. The receiver reassembles the resource in Object ID order. A client performs the equivalent of resources/read by FETCH of the latest group of the resource track, and follows changes to the resource by SUBSCRIBE to it; each new group is an update. A client that joins late, or after a disconnect, subscribes with FILL_PARAMETERS: it receives the current version through a fill fetch and then each later version, with no gap between them (). A resource that the server can only serve with additional input from the client () is not published on a resource track; the client reads it with resources/read on its control track.

Task Tracks Task tracks carry the MCP Tasks extension , which lets a server answer a request with a durable task handle instead of blocking. Each task has its own scope within the client scope, so everything about the task, its state and the client's answers, lives in one namespace: Track namespace: (mcp, <server-id>, clients, <client-id>, tasks, <task-id>) Tracks in a Task Scope

Track Name	Publisher	Content
(state)	MCP Server	task state changes
(request)	MCP Client	tasks/update and tasks/cancel requests
(response)	MCP Server	responses to those requests

Each task state change creates a new group on the state track whose Object 0 contains the full task state, as carried in the extension's notifications/tasks: its status (working, input_required, completed, failed, or cancelled), and, in terminal states, the result or error. Instead of polling with tasks/get, a client subscribes to the state track and receives each change as it happens. A client that reconnects mid-task uses a fill fetch () to retrieve the latest state and then follows live changes. When the status is input_required, the state includes inputRequests. The client answers with tasks/update, and cancels the task with tasks/cancel, on the task's request track; these form an ordinary request/response pair (). Because the task has its own scope:

• A token for one task's scope lets another party, such as the user's phone answering an approval, take part in that task without access to the rest of the client scope ().
• A client, or another device of the same user, can rebuild the task by fetching one namespace.
• Answers that unblock a task can be given their own priority.

Protocol Operation

MOQT Session Establishment The session begins with a QUIC connection or WebTransport session. Each endpoint then sends a SETUP message as the first message on its control stream, carrying its Setup Options. Setup Options are hop-by-hop: when a relay is present they are exchanged with the relay, not with the far-end MCP peer. MCP needs no negotiation at setup, because each request carries its protocol version and capabilities in _meta . Endpoints push their tracks to the next hop with PUBLISH, follow live tracks with SUBSCRIBE, and retrieve already-published objects with FETCH. After a reconnect, an endpoint catches up on missed objects with a fill fetch, requested through FILL_PARAMETERS on a SUBSCRIBE. A subscriber that may reach a relay before the publisher includes RENDEZVOUS_TIMEOUT so the relay holds the subscription. Track discovery uses SUBSCRIBE_TRACKS, which includes handling PUBLISH_SKIPPED, together with SUBSCRIBE_NAMESPACE and PUBLISH_NAMESPACE. Access control uses the AUTHORIZATION TOKEN Setup Option and message parameter. Implementations MUST support all of these mechanisms. answers every request with a REQUEST_OK or REQUEST_ERROR message. This document uses names such as SUBSCRIBE_OK and FETCH_ERROR as shorthand for the REQUEST_OK or REQUEST_ERROR that answers the named request. MCP endpoints MAY be identified using the moqt:// URI scheme defined in . All namespaces whose first tuple element begins with a period (0x2e) are reserved by MOQT; MCP implementations MUST NOT use such prefixes.

Getting Started A client that has established a MOQT session with the server, or with a relay in front of it:

1. Derives its client ID for the server ().
2. Sends SUBSCRIBE_TRACKS for its client scope (mcp, <server-id>, clients, <client-id>), so that it receives every response, task, and private track the server publishes for it.
3. Subscribes to the catalog (mcp, <server-id>) -- (catalog) with FILL_PARAMETERS, so that it receives the current catalog and then each update.
4. Publishes requests on its request tracks ().

A server that serves clients through a relay sends SUBSCRIBE_TRACKS for (mcp, <server-id>, clients), so that it receives the request tracks of every client, including clients that arrive later. It learns of a new client when the relay sends it a PUBLISH for the client's first request track.

Request and Response Exchanges In MCP, the client sends requests and the server answers them. MOQT requests (SUBSCRIBE, FETCH) name a track but do not carry an object payload, so they cannot carry a JSON-RPC request. This document therefore maps every JSON-RPC exchange onto a pair of tracks in the client scope:

• The client publishes requests on a request track.
• The server publishes responses on a response track.
• Each request is a new group on the request track. The response uses the same Group ID on the response track and can span several objects (for example, progress notifications followed by a result); see .
• The JSON-RPC id is the authoritative correlation key. Matching Group IDs are a convenience for relays and for recovery; a receiver MUST NOT rely on Group IDs alone to match a response to a request.
• Requests MAY be concurrent. Each exchange occupies its own group, and Group IDs on a request track increase with each new request.

Response Layout and Continuity Because a response lives in a known group, it can outlast the link that carried the request. Losing the MOQT session does not cancel a request: the server keeps the work running and keeps publishing the response into the same group, and retains it for a period of its choosing (). When the client reconnects, it resubscribes to the response track with FILL_PARAMETERS, or FETCHes that group starting at the first Object ID it has not received, and receives the rest of the response. Neither side resends what the other already has. Within the group, the server MAY spread the response over several subgroups. Each subgroup is sent on its own QUIC stream, so a long result does not hold back progress notifications, and loss on one stream does not block the others. For example, a server can send progress notifications in one subgroup and the chunks of a large result in another. Object IDs increase across the whole group, and the final JSON-RPC result or error has the highest Object ID. A receiver orders the objects of a response by Object ID, not by arrival order, and treats the response as complete once it has the final result or error.

Multi Round-Trip Requests MCP servers do not send requests to clients. When a server needs more input to complete a tools/call, prompts/get, or resources/read, such as an elicitation, a sampling result, or the client's roots, it returns a result with resultType input_required that lists the requests in inputRequests and MAY include an opaque requestState . The client gathers the input and retries the original request, with a new JSON-RPC id, inputResponses, and the requestState unchanged. Over MOQT, the input-required result is the final object of the original request's response group. The retry is a new request, so it is a new group on the same request track, and its response is in the matching group of the response track. No separate tracks are needed for elicitation, sampling, or roots.

Cancellation A client cancels a request by publishing an MCP notifications/cancelled message, with the request's JSON-RPC id as requestId, as the next object in the request's own group on the request track. If the subgroup that carried the request has ended, the client opens a new subgroup in that group. The cancellation is thus correlated by its group, covered by the same authorization as the request track, and visible to a server that FETCHes the group after a reconnect. A server that receives it stops the work and ends the response with a JSON-RPC error or, if the work has already finished, with its result. Work that runs as a task is cancelled with tasks/cancel on the task's request track ().

Delivering Requests and Responses MOQT operates hop by hop. A client sends PUBLISH for its request track to its first hop, which accepts it with PUBLISH_OK. When the first hop is the server, the server receives the request track directly. When it is a relay, the PUBLISH ends there, and the relay delivers the track onward to each downstream subscriber whose subscription matches it:

• To an endpoint holding a SUBSCRIBE_TRACKS whose prefix matches the track's namespace, such as the server's SUBSCRIBE_TRACKS on (mcp, <server-id>, clients) (), the relay sends a PUBLISH for the track towards that endpoint, and then forwards the track's objects.
• To an endpoint that already holds a SUBSCRIBE for the track, the relay sends the track's objects on that subscription.

Response tracks reach the client the same way, in the other direction: the server publishes them to its first hop, and the client's SUBSCRIBE_TRACKS on its client scope, which excludes the client's own request tracks, delivers each one. A client that subscribes to a response track before the server has published it includes RENDEZVOUS_TIMEOUT, so that the relay holds the subscription until the track appears. FETCH is never used to send a request. It is used only to retrieve objects that are already published: the catalog, a resource, skill metadata and instructions, task state, or a response that was missed during a disconnect (). Request and response tracks MUST NOT use a finite delivery timeout (SUBGROUP_DELIVERY_TIMEOUT or OBJECT_DELIVERY_TIMEOUT), because a lost request or response cannot be told apart from one that was never sent.

Reconnection If the underlying QUIC connection migrates (e.g., network change on a mobile device), the MOQT session persists and nothing changes for MCP. If the connection is lost, the client reconnects, to the same relay or another one, and repeats . Because it derives the same client ID, its client scope, and the responses and tasks in it, are unchanged. A client that did not receive all of the response to an in-flight request recovers the rest from the corresponding group of the response track (). A server retains responses and task state for a period of its choosing; tasks follow the ttlMs of . Relays that cache them within their MAX_CACHE_DURATION () answer the client's catch-up without involving the server. A request whose response cannot be recovered SHOULD be treated as failed, and the client MAY retry it as a new request. To catch up on objects missed during a disconnect without a separate FETCH round-trip, a client re-subscribing to a track SHOULD use a fill fetch: it issues SUBSCRIBE with FILL_PARAMETERS on the track (e.g., a task track or a resource track), and the publisher opens a unidirectional fill fetch stream carrying the historical range (typically the latest complete group) before live objects resume on the subscription. This makes "retrieve what I missed, then follow live" atomic. For deterministic recovery of a specific object range (e.g., replaying a task's state history), the client uses FETCH with explicit Start and End Locations; the publisher confirms the actual End Location in FETCH_OK.

Priority Management MOQT subscriber priorities (0-255, lower is higher priority) optimize MCP message delivery: Standalone Priorities

Priority	Range	Track Type	Example
HIGH	1-30	Control, Tools, Prompts, Tasks, Skill execution	tool calls, task state
MEDIUM	31-90	Catalog, Skills	capability changes
LOW	91-127	Resources	documentation

Applications MAY dynamically adjust priorities based on user interaction state (e.g., boosting skill loading when a user is actively waiting). Within a PACE dialog (), MCP tracks instead use the priority tiers of , so that they are ordered correctly against PACE dialog control and other bindings: Priorities within PACE

MCP Track Type	PACE Tier	Range
Control, Tools, Prompts, Tasks, Skill execution	Standard Operations	96-127
Catalog, Skills	Discovery	128-159
Resources	Bulk Transfer	192-255

Error Handling

Transport-Level Errors MOQT reports errors through four separate code spaces . The same name (for example, EXPIRED_AUTH_TOKEN) can appear in more than one of them with a different code point, so an implementation needs to know which mechanism carried an error before acting on it. Request errors, carried in REQUEST_ERROR in response to SUBSCRIBE, PUBLISH, FETCH, SUBSCRIBE_TRACKS, SUBSCRIBE_NAMESPACE or PUBLISH_NAMESPACE (SUBSCRIBE_ERROR, FETCH_ERROR and so on are shorthands for REQUEST_ERROR): MOQT Request Errors

Code	Meaning	MCP Recovery
DOES_NOT_EXIST	Unknown server, tool or resource track	Check the server ID or refresh the catalog
UNAUTHORIZED	Token lacks the required scope	Obtain a token with broader scope ()
EXPIRED_AUTH_TOKEN	Auth token expired	Re-authenticate and retry
TIMEOUT	No publisher appeared within RENDEZVOUS_TIMEOUT	Retry, or treat the server as unavailable
INVALID_RANGE	FETCH range has no published objects	Treat the object as not yet published
EXCESSIVE_LOAD	Endpoint overloaded	Back off with exponential delay
NAMESPACE_TOO_LARGE	Relay refuses to enumerate the prefix	Subscribe to specific tracks

PUBLISH_DONE status codes, which end a subscription: PUBLISH_DONE Status Codes

Code	Meaning	MCP Recovery
TRACK_ENDED	Publisher finished the track	Normal; no action
TOO_FAR_BEHIND	Subscriber could not keep up	Re-subscribe with a fill fetch; reduce subscription scope
EXPIRED	Subscription reached its expiry	Re-subscribe
UNAUTHORIZED	Subscriber is no longer authorized	Re-authenticate
EXCESSIVE_LOAD	Publisher overloaded	Back off with exponential delay
GOING_AWAY	Publisher sent or received GOAWAY	Reconnect

Stream reset codes, used when an individual data stream is reset: Stream Reset Codes

Code	Meaning	MCP Recovery
DELIVERY_TIMEOUT	Delivery timeout exceeded	Not expected on request/response tracks (); FETCH the missing group
SESSION_CLOSED	Session is closing	Reconnect if needed
CANCELLED	Stream cancelled by either endpoint	Check PUBLISH_DONE for detail

Session termination codes and GOAWAY end the whole MOQT session. After GOAWAY, clients SHOULD reconnect as described in .

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

MCP-Level Errors MCP errors are JSON-RPC error responses within MOQT objects: Besides the standard JSON-RPC error codes, defines -32021 (missing required client capability) and -32022 (unsupported protocol version), and reports an unknown resource with -32602 (invalid params). A tool that receives invalid input SHOULD report it as a tool execution error (an isError: true result on the tool track) rather than a JSON-RPC protocol error, so the model can self-correct.

Error Recovery

1. Transient errors: Retry with exponential backoff
2. Unsupported protocol version: Retry with a version from the error's supported list
3. Resource errors: Invalidate cache and re-fetch
4. Skill errors: See

Capability Discovery

Catalog Contents The catalog replaces server/discover and the list requests for a client that subscribes to it. Its Object 0 is a JSON object whose members are those of the server/discover result (supportedVersions, capabilities, instructions, and the server's identity in _meta) together with tools, resources, resourceTemplates, and prompts holding the definitions that tools/list, resources/list, resources/templates/list, and prompts/list return . The ttlMs and cacheScope members of those results also apply to the catalog; the server-scope catalog has cacheScope public. Clients FETCH the latest group of the catalog for one-time discovery, or SUBSCRIBE for real-time updates when capabilities change. Catalog entries SHOULD carry the icons and description fields defined by . Tool inputSchema and outputSchema use JSON Schema 2020-12, the default dialect for MCP schema definitions.

Track Discovery by Prefix MOQT offers two prefix-based mechanisms, and they discover different things :

• SUBSCRIBE_TRACKS discovers and subscribes to tracks. The publisher (or relay) sends a PUBLISH for each existing and future track whose namespace matches the prefix, excluding tracks published by the subscriber.
• SUBSCRIBE_NAMESPACE discovers namespaces, not tracks. The publisher responds with a NAMESPACE message for each matching namespace it knows, and sends NAMESPACE_DONE later if that namespace is withdrawn. NAMESPACE_DONE does not mark the end of a list.

A client uses SUBSCRIBE_TRACKS on its client scope (), and MAY use it on the server-scope prefixes (mcp, <server-id>, resources) and (mcp, <server-id>, skills) to follow public resources and skills. A client MUST NOT send SUBSCRIBE_TRACKS for (mcp, <server-id>) or (mcp, <server-id>, clients), which would match other clients' tracks, and relays refuse it (). The following rules apply to prefix subscriptions:

• Skipped tracks: if the publisher cannot create a subscription for a matching track, it sends PUBLISH_SKIPPED with that track's name and will not send a PUBLISH for it under this SUBSCRIBE_TRACKS. An MCP endpoint that receives PUBLISH_SKIPPED for a track it needs MUST send an explicit SUBSCRIBE for that track. Missing a request or response track would otherwise stall requests.
• Large namespaces: a relay MAY refuse or close a prefix subscription with NAMESPACE_TOO_LARGE. An endpoint that receives it falls back to explicit SUBSCRIBE for the tracks listed in the catalog.

Dynamic Updates The catalog is authoritative for which tools, resources, resource templates, and prompts the server offers. When that set changes, the server publishes a new catalog group. It then starts publishing the tracks of any added resource, and ends the tracks of any removed resource with PUBLISH_DONE (TRACK_ENDED). A client that subscribes to the catalog track receives each change without polling, so it does not need subscriptions/listen or the list-changed notifications of . Changes to the content of a resource are signaled by a new group on its resource track ().

Relay Support MOQT relays enable scalable MCP deployments through subscription aggregation and content caching.

Subscription Aggregation and Caching When multiple subscribers subscribe to the same track, relays maintain a single upstream subscription and fan out content downstream, and a cached object serves later subscriptions and fetches. Server-scope tracks are shared by all clients of a server, so one copy of the catalog, a public resource, or a skill at a relay serves every client behind it. Client-scope tracks belong to one client; a cached object there serves only that client, for example in a fill fetch after reconnection (). Relay Cache Strategy

Content Type	Scope	Cache Strategy
Catalog	Server	Latest group; replaced by each update
Public resources	Server	Latest group; a new group is a new version
Skill registry, metadata, instructions	Server	Latest group; replaced by each new version
Private resources, private catalog	Client	Latest group, for that client only
Responses, task state	Client	Kept only as long as needed for recovery ()

A server MUST NOT publish content whose cacheScope is private in the server scope.

Cache Duration A publisher controls how long relays may serve a track's objects from cache with the MAX_CACHE_DURATION Track Property , a number of milliseconds after which a relay stops serving an object. Within that time, a relay that holds an object answers a FETCH or fill fetch for it directly, so the request does not travel to the server. This serves a client from the nearest relay when it reads the catalog, a resource, or a skill, joins late, or catches up after a reconnection. Servers SHOULD set MAX_CACHE_DURATION on every track they publish:

• On server-scope tracks, to the content's ttlMs , so that relays stop serving content the server no longer considers fresh.
• On response and task state tracks, to at least the period for which the server retains responses and task state (), so that a reconnecting client can recover them from the relay.

Clients MAY set MAX_CACHE_DURATION on their request tracks in the same way, so that a server that reconnects can FETCH a request, or a cancellation (), that it missed from the relay. Without MAX_CACHE_DURATION, relays can cache objects until they evict them, which can serve content after the server considers it stale.

Finding Servers Through a Relay A client normally learns a server ID out of band (). A relay operator MAY additionally offer a listing of the MCP servers behind a relay. Listing is optional and opt-in on both sides:

• A server that wants to be listed advertises its server scope (mcp, <server-id>) to the relay with PUBLISH_NAMESPACE. A relay lists only servers that do so and that its operator allows to be listed.
• A client asks for the listing with SUBSCRIBE_NAMESPACE for (mcp). A relay MUST refuse this request with REQUEST_ERROR (UNAUTHORIZED) unless the client's token authorizes listing, and MAY limit the listing to the servers that client is authorized to see.

The relay answers an authorized request with one NAMESPACE message for each listed server, and sends NAMESPACE_DONE when a server withdraws. The relay does not forward PUBLISH_NAMESPACE to clients. | | | | NAMESPACE (srv-a) | | | |<--------------------| | | | NAMESPACE (srv-b) | | | |<--------------------| | | | | | | | ... later, Server B withdraws ... | | | NAMESPACE_DONE | | | | (srv-b) | | | |<--------------------| | | ]]> NAMESPACE and NAMESPACE_DONE carry only the namespace suffix after the subscribed prefix, here the server ID. The client then reads the server's catalog and starts as in . A relay MUST NOT reveal client-scope namespaces, or any namespace other than a listed server's (mcp, <server-id>), in answer to SUBSCRIBE_NAMESPACE.

Agent Skills Agent Skills are composed instructions that orchestrate multiple tools for complex tasks. Skills complement tools: tools are atomic and stateless, while skills are context-aware multi-step workflows. This document supports two ways to run a skill:

• Client-executed (the default): the client loads the skill's instructions and its model carries them out with ordinary MCP tool calls (). This needs no new MCP methods; the skill tracks only distribute the skill content.
• Server-executed (OPTIONAL): the client asks the server to run the skill with skills/invoke, and the server reports progress and the result (). This adds JSON-RPC methods that are not part of .

Support for Skills is OPTIONAL. A server that offers skills MUST publish the registry track and the metadata and instructions tracks of each skill, and MUST support FETCH on them. A server that also supports server-executed skills marks those skills with "serverExecution": true in the registry.

Skills Track Structure Skill content is published once in the server scope; server-executed skill requests are in the client scope. Skills Tracks

Track Namespace	Track Name	Publisher	Purpose
(mcp, <server-id>, skills)	(registry)	MCP Server	List of skills with their metadata
(mcp, <server-id>, skills, <skill-id>)	(metadata)	MCP Server	Skill metadata
(mcp, <server-id>, skills, <skill-id>)	(instructions)	MCP Server	Full instructions
(mcp, <server-id>, clients, <client-id>, skills, <skill-id>)	(request)	MCP Client	skills/invoke requests (server-executed only)
(mcp, <server-id>, clients, <client-id>, skills, <skill-id>)	(response)	MCP Server	Progress and result (server-executed only)

Each skill version is a new group on the registry, metadata, and instructions tracks. Skills use progressive loading: a client reads the small metadata object first, and fetches the instructions only when it decides to use the skill. The metadata object contains:

• id and version
• description and triggers: when the skill applies
• requiredTools: the tools the instructions call
• instructionsHash: the SHA-256 hash of the instructions object, base64url-encoded, so that a client can check the instructions it fetched

Clients SHOULD cache skills by version.

Client-Executed Skills | [cached] | | Object: metadata | | |<-----------------------| | | | | | FETCH skills, commit | | | -- (instructions) | | |----------------------->| [cached] | | Object: instructions | | |<-----------------------| | | | | | (model follows the instructions) | | | | | Object on tools, | | | git_status | | | -- (request) | | |----------------------->|------------------------>| | Object on tools, | | | git_status | | | -- (response) | | |<-----------------------|<------------------------| | | | | ... further tool calls, such as git_commit ... | ]]> The metadata and instructions are already-published, versioned objects in the server scope, so FETCH is appropriate and a relay that holds them answers from its cache, whichever client fetched them first (). Tool calls use the client's tool request/response tracks ().

Server-Executed Skills The skill's request and response tracks are a request/response pair (). Each invocation is a new group on the request track, and the server publishes progress and the result in the group with the same Group ID on the response track. A server that runs the skill as a task returns a task handle and reports state on the task's state track (). The request, published as Object 0 of a new group: Zero or more progress notifications follow on the response track, then the result as the last object of the group:

Skills Errors A server reports skill failures as JSON-RPC errors on the skill's response track: Skills Error Codes

Error Code	Description	Recovery Action
-33001	Skill not found	Refresh the registry
-33002	Required tool unavailable	Check that the tool's server is reachable
-33003	Dependency resolution failed	Check the skill's requiredTools
-33004	Server-executed skill timed out	Retry, or run the skill client-side

These codes are outside the JSON-RPC reserved range, as requires for application-defined errors. A client that cannot run a skill can fall back to direct tool calls.

Relay Caching for Skills Each skill version is an immutable group in the server scope, so a relay can serve it to every client (). When a skill is updated, the server publishes a new group on the registry and on the skill's metadata and instructions tracks; clients with active subscriptions receive the new version without polling.

Multi-Server Operation When a client uses multiple MCP servers, it has a separate, pairwise client ID and client scope at each: , tools, code_analysis) -- (request) Server C: (mcp, srv-c, clients, , control) -- (request) ]]> The client coordinates across servers 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.

Carrying MCP inside a PACE Dialog PACE manages agent dialogs over MOQT: it supplies the dialog identifier, lifecycle, context propagation, identity, and authorization, and carries application protocols such as MCP as bindings. MCP over MOQT runs inside a PACE dialog with the same tracks and the same message handling as in standalone mode; only the namespaces change.

Namespace Mapping In a PACE dialog, each participant publishes under its own agent-id. The leading fields of an MCP namespace, (mcp, <server-id>, clients, <client-id>) in the client scope or (mcp, <server-id>) in the server scope, are replaced by (pace, dialogs, <did>, <agent-id>, mcp), where <did> is the dialog-id and <agent-id> is the agent-id of the track's publisher. The rest of the namespace (the MCP category, such as control, tools, prompts, resources, tasks or skills, and any fields that follow it) and the track name stay the same. For example, with cli and srv the agent-ids of the MCP client and server: , clients, , tools, ) -- (request) (mcp, , clients, , tools, ) -- (response) (mcp, , resources) -- () (mcp, ) -- (catalog) Within a PACE dialog: (pace, dialogs, , , mcp, tools, ) -- (request) (pace, dialogs, , , mcp, tools, ) -- (response) (pace, dialogs, , , mcp, resources) -- () (pace, dialogs, , , mcp) -- (catalog) ]]> As in standalone mode, the category and identifier stay separate namespace fields, so tokens and relays can match on (..., mcp, tools) by prefix, and identifiers that contain /, such as resource URIs, remain unambiguous. The resulting Full Track Name MUST NOT exceed the 4,096-byte and 32-field limits of .

What PACE Replaces Everything else in this document applies unchanged inside a dialog: the object encoding, request and response tracks (), group and subgroup use, multi round-trip requests, tasks, skills, and relay caching. PACE takes over the following:

• Scopes and client IDs: the dialog replaces both the server scope and the client scope, and PACE relay authorization keeps the dialog's tracks within the dialog. Client IDs are not used. Content that is public in standalone mode, such as the catalog, is published in each dialog; a client MAY instead read it from the server's standalone server scope, where relays share it across clients.
• Getting started: MCP has no handshake. Once the dialog is active, each participant sends SUBSCRIBE_TRACKS on the dialog prefix (pace, dialogs, <did>), which delivers its peers' MCP tracks, and the client starts publishing requests.
• Dialog reference: each MCP request carries the PACE dialog reference in _meta under the key org.ietf.agentproto/dialog-context, next to the per-request fields of . It is distinct from JSON-RPC request IDs.
• Cancellation: a PACE CANCEL with scope operation that names an MCP request track and group has the same effect as notifications/cancelled in that group (). The client can also publish notifications/cancelled itself.
• Identity and authorization: PACE supplies them. The MCP access rules of become PACE scopes over the (..., <did>, <agent-id>, mcp, ...) namespaces.
• Priorities: MCP tracks use the PACE tiers ().

Several bindings, for example A2A and MCP, can share one dialog, because each uses its own protocol field after the agent-id.

Choosing a Mode A deployment MAY use either mode. Standalone mode suits a client that talks directly to one or more MCP servers. PACE mode suits MCP tool access that is one part of a larger, multi-agent dialog.

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/<server-id>/clients/<client-id>/tools/* but not mcp/<server-id>/clients/<client-id>/skills/*). Tokens MUST have bounded lifetimes; servers MUST reject expired tokens with EXPIRED_AUTH_TOKEN. Relays MUST authorize the scopes of as follows:

• A client is authorized to publish and subscribe only within its own client scope (mcp, <server-id>, clients, <client-id>), and to subscribe to and fetch the server-scope tracks it is permitted to read. Tokens that grant this name the client's client ID.
• A party to which a client delegates one task is authorized only within that task's scope (mcp, <server-id>, clients, <client-id>, tasks, <task-id>). How the delegation is granted is outside the scope of this document.
• Only the server is authorized to publish in its server scope, to send PUBLISH_NAMESPACE for (mcp, <server-id>), and to send SUBSCRIBE_TRACKS for (mcp, <server-id>, clients).

Within a client scope, the client and server publish under the same namespaces (for example, both publish tracks in (mcp, <server-id>, clients, <client-id>, tools, <tool-name>)), and only the track name tells the request track from the response track. A namespace-scoped grant to publish therefore does not stop one peer from publishing a track that belongs to the other. Tokens that authorize PUBLISH MUST be scoped to Full Track Names, or to namespace patterns combined with the track names that the holder publishes as defined in . A relay MUST reject a PUBLISH for a track outside the publisher's token scope. Subscribe-only tokens MAY remain namespace-scoped. forbids copying the AUTHORIZATION TOKEN parameter from a SUBSCRIBE_TRACKS into the PUBLISH messages that result from it. A relay that forwards a PUBLISH because of a SUBSCRIBE_TRACKS MUST therefore check that each forwarded track falls within the scope of the token presented on that SUBSCRIBE_TRACKS. For example, a token scoped to mcp/<server-id>/clients/<client-id>/tools/* must not result in the relay forwarding a PUBLISH for a skills or tasks track.

Mapping MCP Authorization onto MOQT The MCP authorization framework treats the MCP server as an OAuth 2.1 protected resource. It uses OAuth 2.0 Protected Resource Metadata discovery (), OpenID Connect Discovery for the authorization server, incremental scope consent signaled via WWW-Authenticate, and OAuth Client ID Metadata Documents for client registration. Because MOQT supplies transport over QUIC rather than HTTP, this framework maps onto MOQT as follows:

• Resource discovery: the protected-resource and authorization-server metadata are obtained out of band (e.g., from the server's HTTPS origin or an MCP registry entry) before the MOQT session is established. The resulting access token is then presented to MOQT.
• Token presentation: the OAuth access token (or a token derived from it) is carried in MOQT's AUTHORIZATION TOKEN Setup Option and in the AUTHORIZATION TOKEN message parameter on individual requests, rather than in an HTTP Authorization header. Setup Options are hop-by-hop, so a token in SETUP authorizes the session with the first relay. Relays aggregate subscriptions, so a token in a request parameter does not in general reach the MCP server either. When the path includes relays, credentials that the MCP server itself must verify travel in each request's _meta.
• Proof of possession: HTTP DPoP binds a proof to a request with the htm and htu claims, which MOQT has no equivalent for. Deployments that need sender-constrained tokens use the DPoP binding of . There, each proof carries an Authorization Context (actx) naming the MOQT action, Track Namespace and Track Name in place of htm and htu.
• Relay-level authorization: where a relay enforces namespace access, deployments SHOULD use MOQT Common Access Tokens , whose scopes map to the (mcp, <server-id>, ...) track namespaces. A C4M token can be minted from the OAuth grant so that the relay authorizes subscribe/publish without seeing the upstream OAuth token.
• Incremental consent: when a server requires additional scope for a particular tool or resource, it rejects the PUBLISH, SUBSCRIBE or FETCH with REQUEST_ERROR (UNAUTHORIZED), and the client obtains a token with the broader scope, mirroring the WWW-Authenticate incremental-consent flow. EXPIRED_AUTH_TOKEN is used only when the presented token has expired.

Use with the Personal Agent Protocol The Personal Agent Protocol (Poppy) lets a person's own agent, the Personal Agent, sign in to a Company and call the Company's APIs, which the Company lists in its poppy.json discovery document. Poppy Draft 0.3 reaches an API of type mcp over Streamable HTTP. This informative section describes how a Company can offer the same MCP server over MOQT. Poppy is a pre-1.0 draft, and this section tracks Draft 0.3.

Advertising the Server A Company lists its MCP over MOQT server in poppy.json, alongside or instead of its Streamable HTTP server. Poppy ignores API entries whose type it does not recognize, so the two can coexist: The url member is the moqt:// URI of the relay or server to connect to (), and serverId is the server ID (). Poppy Draft 0.3 does not define a type for MCP over MOQT, so the entry is a Poppy extension, named under a domain the Company controls as Poppy's extension rules require.

Access Tokens Poppy issues access tokens bound to a resource with the resource parameter of . For an MCP over MOQT server, the resource is the url of its apis entry. The Personal Agent presents the token as describes: in each request's _meta for the server, and, where a relay enforces access, as a Common Access Token with the DPoP binding of that authorizes the Personal Agent's client scope.

Session Proofs Poppy sends a fresh Poppy-Session JWT with each request. It identifies the session, the pairwise User ID, and the Personal Agent's delegated key, and Poppy binds it to an HTTP request with the htm and htu claims. Over MOQT, the Personal Agent puts the JWT in the _meta of each JSON-RPC request it publishes, and replaces htm and htu with an actx claim as defined by : type "moqt", action "PUBLISH", and tns and tn naming the request track that carries the object. The server verifies the JWT as Poppy specifies, checking actx instead of htm and htu. As in Poppy, a server MAY ignore the proof. Note: Poppy does not yet support this use of the Poppy-Session JWT.

Privacy Poppy identifies a person to each Company only by a User ID that is different at every Company. MCP over MOQT client IDs are pairwise in the same way (), so they do not let two Companies link a Personal Agent. Because _meta carries the Poppy-Session JWT and the access token, the Personal Agent's request tracks SHOULD be protected end to end with Secure Objects when they cross a relay.

Security Considerations TODO

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, and registration of the mcp binding in a PACE protocol binding registry if establishes one.

Examples The examples use server ID srv-a and write the client's client ID as <cid>. Except in , they omit the per-request _meta fields of .

Starting to Use a Server

1. The client opens a QUIC connection to the relay, and each endpoint sends SETUP on its control stream.
2. The client derives its client ID <cid> for srv-a ().
3. The client sends SUBSCRIBE_TRACKS for (mcp, srv-a, clients, <cid>).
4. The client sends SUBSCRIBE for (mcp, srv-a) -- (catalog) with FILL_PARAMETERS. It receives the current catalog, from the relay's cache if another client has already read it, and then each update.
5. The client sends PUBLISH for (mcp, srv-a, clients, <cid>, tools, read_file) -- (request) and publishes its first tools/call.

Tool Execution The client publishes the call as Object 0 of Group 7 on (mcp, srv-a, clients, <cid>, tools, read_file) -- (request): The server publishes the result as Object 0 of Group 7 on (mcp, srv-a, clients, <cid>, tools, read_file) -- (response):

Multi Round-Trip Request The server needs the user's confirmation before it deletes a file. All four messages are on the delete_file tool tracks, (mcp, srv-a, clients, <cid>, tools, delete_file). The client publishes the call as Object 0 of Group 3 on the request track: The server answers in Group 3 of the response track with an input-required result: The client asks the user, then retries as a new request, with a new id, in Group 4 of the request track: The server completes the call in Group 4 of the response track:

Skill Invocation

1. The user types "/commit", and the client matches it against its cached skill registry.
2. The client FETCHes (mcp, srv-a, skills, commit) -- (metadata) and learns the version, the required tools, and the instructions hash.
3. The client FETCHes (mcp, srv-a, skills, commit) -- (instructions) and checks it against the hash.
4. The model follows the instructions. For each tool call, such as git_status, git_diff, and git_commit, the client publishes on (mcp, srv-a, clients, <cid>, tools, <tool-name>) -- (request) and reads the result from the matching response track.
5. The client returns the result to the user.

References Normative References Cisco Google Google Meta Linux Foundation Linux Foundation This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. 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. Informative References Cisco Cisco Cisco This document specifies an end-to-end authenticated encryption scheme for application objects transmitted via Media over QUIC (MoQ) Transport. The scheme enables original publishers that share a symmetric key with end subscribers, to ensuring that MoQ relays are unable to decrypt object contents. Additionally, subscribers can verify the integrity and authenticity of received objects, confirming that the content has not been modified in transit. Additionally it allows MoQ parameters to be protected so the publisher can select if they are readable and/or modifiable by relays. This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. Sierra Meta Apple Inc. Google The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with an abstract model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which is optional. Cisco Cisco

Acknowledgments This document is a revision of draft-jennings-mcp-over-moqt available at https://datatracker.ietf.org/doc/draft-jennings-mcp-over-moqt/.