Skip to content

Specification Overview

Version: 1.1.0-draft Status: Draft Specification Last Updated: 2026-02-06

Conventions

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in RFC 2119 and RFC 8174.

Protocol Capabilities

UCAP defines five capabilities. Four are new, purpose-built for content access. One — Subscription — is a UCP extension that builds on UCP's existing Checkout capability.

UCAP-Native Capabilities

These are new capabilities defined by UCAP:

Capability ID Description
Content Access dev.ucap.content.access Fetch published content with automatic entitlement checking
Catalog Search dev.ucap.content.catalog.search Free-text search across publishers and posts
Catalog Lookup dev.ucap.content.catalog.lookup Direct lookup by publication or post ID
Identity Linking dev.ucap.content.identity Link agent identity to user identity via OAuth

UCP Extension

This capability extends UCP's Checkout, inheriting its payment flow and augmenting it with subscription-specific fields:

Capability ID Extends Description
Subscription dev.ucap.content.subscription dev.ucp.shopping.checkout Recurring content subscriptions with entitlement management

Capability Design

Each capability is independently implementable. A conformant UCAP server MUST implement Content Access and SHOULD implement Catalog Search and Catalog Lookup. Other capabilities are OPTIONAL.

Capabilities follow a reverse-domain naming convention (dev.ucap.*) consistent with UCP's namespace governance model.

Capability Composition

┌──────────────────────────────────────────────────────────┐
│                   UCAP Capabilities                      │
├──────────────────────────────────────────────────────────┤
│                                                          │
│   ┌─────────────────────────────────────────────────┐    │
│   │            Content Access (REQUIRED)            │    │
│   │          dev.ucap.content.access                │    │
│   └─────────────────────────────────────────────────┘    │
│                                                          │
│   ┌──────────────────────┐ ┌────────────────────────┐    │
│   │   Catalog Search     │ │   Catalog Lookup       │    │
│   │  (RECOMMENDED)       │ │  (RECOMMENDED)         │    │
│   └──────────────────────┘ └────────────────────────┘    │
│                                                          │
│   ┌──────────────────────┐ ┌────────────────────────┐    │
│   │   Subscription       │ │   Identity Linking     │    │
│   │  (OPTIONAL)          │ │  (OPTIONAL)            │    │
│   └──────────────────────┘ └────────────────────────┘    │
│                                                          │
└──────────────────────────────────────────────────────────┘

Transport Bindings

UCAP capabilities can be accessed through multiple transport bindings:

Transport Description Use Case
REST / HTTP Standard HTTP API with JSON request/response Direct integration, server-to-server
MCP Model Context Protocol tools AI agent integration (Claude, etc.)

REST / HTTP

The primary transport. All capabilities define HTTP endpoints under the /v1/ path prefix. Requests and responses use application/json.

MCP

UCAP servers MAY expose capabilities as MCP tools. MCP tools SHOULD wrap the HTTP API, not replace it. See MCP Integration for details.

Versioning

The UCAP specification follows Semantic Versioning 2.0:

  • Major version for breaking changes to capability interfaces
  • Minor version for new capabilities or backward-compatible additions
  • Patch version for clarifications and editorial fixes

All HTTP endpoints are prefixed with /v1/ for the current major version.

References