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 core capabilities, following the composable pattern from UCP:

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
Subscription dev.ucap.content.subscription Subscribe to publishers and manage entitlements
Identity Linking dev.ucap.content.identity Link agent identity to user identity via OAuth

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