@adcp/sdk 15.8.1 → 15.9.1

package/dist/lib/schemas-data/3.2/mcp/2026-07-28/protocol/sync-agent-notification-configs-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-agent-notification-configs-request.json",
+  "$id": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-agent-notification-configs-request.json",
   "title": "Sync Agent Notification Configs Request",
   "description": "Register, replace, pause, or clear caller-scoped agent-level webhook subscribers. This task manages notifications whose lifecycle belongs to the seller agent itself rather than to an account or media buy. The initial use case is `capabilities.changed`, which invalidates cached `get_adcp_capabilities` responses. Declarative semantics match account-level `notification_configs[]`, but the replacement is scoped to the authenticated caller or registry identity: the submitted array is that caller's complete desired set, keyed by `subscriber_id`; persisted subscribers for that caller whose `subscriber_id` does not appear in the submitted array are removed; sending `[]` clears only that caller's set. Sellers MUST reject this task unless `get_adcp_capabilities.adcp.capability_changes.notifications.supported` is true.",
   "x-tool-summary": "Register, replace, pause, or clear caller-scoped webhooks for agent-level notifications.",
@@ -104,9 +104,9 @@
   ],
   "$defs": {
     "external:core/version-envelope.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/version-envelope.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/version-envelope.json",
       "title": "AdCP Version Envelope",
-      "description": "Release-precision AdCP protocol version negotiation fields. Composed via `allOf` into every AdCP request and response schema so the version semantics live in exactly one place. Distinct from `core/protocol-envelope.json`, which wraps responses at the transport layer (context_id / task_id / status / payload). This envelope is part of the payload itself.",
+      "description": "Release-precision AdCP protocol version negotiation fields. Composed via `allOf` into AdCP request schemas and shared response components so the version semantics live in one place. Strict (`additionalProperties: false`) request schemas also redeclare these two fields in their own `properties` via `$ref`, because draft-07 does not evaluate properties across `allOf`. The Trusted Match match requests are the exception: they inline both fields for their strict privacy boundary. Distinct from `core/protocol-envelope.json`, which wraps responses at the transport layer (context_id / task_id / status / payload). This envelope is part of the payload itself.",
       "type": "object",
       "properties": {
         "adcp_version": {
@@ -130,7 +130,7 @@
       }
     },
     "external:core/agent-notification-config.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/agent-notification-config.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/agent-notification-config.json",
       "title": "Agent Notification Config",
       "description": "Caller-scoped agent-level webhook subscription. Caller-anchored event types (capabilities.changed, principal.changed) always fire principal-wide; account-anchored event types may also be listed here with the explicit all_authorized_accounts acknowledgment and fire with per-delivery-attempt authorization scoping over the caller's currently authorized accounts. Registration goes through the task declared by get_adcp_capabilities.adcp.capability_changes.notifications.registration_task: sync_principal when the broader principal surface is supported, or the specialized sync_agent_notification_configs compatibility task. Both tasks operate on one underlying caller-scoped subscriber set. This surface is intentionally separate from account-level notification_configs[]: a registry or buyer can subscribe before it has an account, and one fire invalidates the agent-wide get_adcp_capabilities cache. The persisted set is scoped to the authenticated caller or registry identity, so one caller's declarative replacement cannot clear another caller's subscribers. As with other AdCP webhooks, the default signing scheme is the RFC 9421 webhook profile against the seller's brand.json agents[] JWKS; the optional authentication block opts into the deprecated Bearer / HMAC-SHA256 fallback for compatibility. Credentials and shared secrets in authentication.credentials are write-only and MUST NOT be echoed on reads. Sellers MUST verify endpoint control before activating a new or changed active agent-level notification config; delivery-time SSRF validation still applies to every fire.",
       "type": "object",
@@ -153,7 +153,7 @@
           "items": {
             "allOf": [
               {
-                "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-agent-notification-configs-request.json#/$defs/external:enums~1notification-type.json"
+                "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-agent-notification-configs-request.json#/$defs/external:enums~1notification-type.json"
               },
               {
                 "not": {
@@ -189,7 +189,7 @@
             "schemes": {
               "type": "array",
               "items": {
-                "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-agent-notification-configs-request.json#/$defs/external:enums~1auth-scheme.json"
+                "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-agent-notification-configs-request.json#/$defs/external:enums~1auth-scheme.json"
               },
               "minItems": 1,
               "maxItems": 1
@@ -211,7 +211,7 @@
           "description": "When false, the seller persists the configuration but suppresses fires. Use to pause a subscriber without losing the registration. Paused configs may skip only the outbound proof challenge while inactive; sellers MUST still enforce URL parsing, HTTPS, hostname normalization, and reserved-range rejection at write time. Reactivation requires full SSRF validation with connect pinning plus proof-of-control for any tuple without current valid proof."
         },
         "ext": {
-          "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-agent-notification-configs-request.json#/$defs/external:core~1ext.json"
+          "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-agent-notification-configs-request.json#/$defs/external:core~1ext.json"
         }
       },
       "required": [
@@ -273,7 +273,7 @@
       ]
     },
     "external:enums/notification-type.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/enums/notification-type.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/enums/notification-type.json",
       "title": "Notification Type",
       "description": "Type of push notification fired by a seller agent. Media-buy-anchored cadence reports (`scheduled`, `final`, `delayed`, `adjusted`, `window_update`) fire against a media buy's `reporting_webhook`; `impairment` is media-buy-anchored but fires against `push_notification_config`. Account-anchored notifications include creative, account, product, signal, wholesale-feed, and reporting events, including `reporting.delivery_ready`, `reporting.status_changed`, and `reporting.ledger_changed`; these outlive any single media buy and fire against matching account `notification_configs[]`. The reporting events repair through `get_reporting_status`: delivery_ready is managed-delivery-only, while status_changed and ledger_changed are valid in every reporting tier. Caller-anchored notifications (`capabilities.changed`, `principal.changed`) fire against the caller-scoped subscriber set managed by `sync_principal` or the specialized `sync_agent_notification_configs` compatibility task. New notification types MUST declare their anchor (media-buy, account, or caller), logical notification_id semantics, repair key, and classification in enumDescriptions; only invalidation-only caller-eligible types flow through include_future_event_types. Account-level subscribers MUST reject media-buy- or caller-anchored event types, and persistent account- or caller-anchored types MUST NOT use push_notification_config. Caller-level entries MAY include account-anchored types only with all_authorized_accounts true; each delivery attempt, including retries, is scoped to accounts currently authorized for that caller. Caller-level entries MUST NOT include media-buy-anchored types. Caller- and account-level subscriptions to the same event are independent and receivers dedupe by logical notification_id.",
       "type": "string",
@@ -335,7 +335,7 @@
       }
     },
     "external:enums/auth-scheme.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/enums/auth-scheme.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/enums/auth-scheme.json",
       "title": "Authentication Scheme",
       "deprecated": true,
       "description": "Legacy authentication schemes for the webhook auth block. Bearer: token sent in Authorization header. HMAC-SHA256: legacy shared-secret signing. Both are deprecated; new integrations SHOULD omit the authentication block and use the RFC 9421 webhook signing profile (applicable on schemas where authentication is optional). Removed in AdCP 4.0.",
@@ -346,14 +346,14 @@
       ]
     },
     "external:core/ext.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/ext.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/ext.json",
       "title": "Extension Object",
       "description": "Extension object for platform-specific, vendor-namespaced parameters. Extensions are always optional and must be namespaced under a vendor/platform key (e.g., ext.gam, ext.roku). Used for custom capabilities, partner-specific configuration, and features being proposed for standardization.",
       "type": "object",
       "additionalProperties": true
     },
     "external:core/context.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/context.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/context.json",
       "title": "Context Object",
       "description": "Opaque correlation data that is echoed unchanged in responses. Used for internal tracking, UI session IDs, trace IDs, and other caller-specific identifiers that don't affect protocol behavior. Context data is never parsed by AdCP agents - it's simply preserved and returned.",
       "type": "object",

package/dist/lib/schemas-data/3.2/mcp/2026-07-28/protocol/sync-principal-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-principal-request.json",
+  "$id": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-principal-request.json",
   "title": "Sync Principal Request",
   "x-status": "experimental",
   "description": "This task begins after authentication: AdCP defines no credential-registration protocol, and the seller’s authorization system (OAuth, API keys, signed requests, workload identity) issues and maps credentials before the first call. Declaratively synchronize selected sections of the authenticated principal's standing configuration with one AdCP agent. The principal is a party: a buyer agent, or an operator-side identity acting through any client. Use this task only to change state; read current state, the configuration version, and destination setup progress through get_principal, and prefer this task over the narrower sync_agent_notification_configs when both are advertised. This task does not register a buyer agent: the stable principal MAY be a delegated human user or an autonomous workload. Identity is resolved from authenticated transport and MUST NOT be accepted from request-body agent URLs, signing key IDs, account IDs, or other self-asserted fields. Each present section is the caller's complete desired set and replaces only that section; omitted sections remain unchanged. All submitted sections apply atomically or none do. This task configures reusable principal resources but grants no advertiser-account authority. Sellers implementing it MUST advertise adcp.principal and protocol.principal.",
@@ -180,9 +180,9 @@
   ],
   "$defs": {
     "external:core/version-envelope.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/version-envelope.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/version-envelope.json",
       "title": "AdCP Version Envelope",
-      "description": "Release-precision AdCP protocol version negotiation fields. Composed via `allOf` into every AdCP request and response schema so the version semantics live in exactly one place. Distinct from `core/protocol-envelope.json`, which wraps responses at the transport layer (context_id / task_id / status / payload). This envelope is part of the payload itself.",
+      "description": "Release-precision AdCP protocol version negotiation fields. Composed via `allOf` into AdCP request schemas and shared response components so the version semantics live in one place. Strict (`additionalProperties: false`) request schemas also redeclare these two fields in their own `properties` via `$ref`, because draft-07 does not evaluate properties across `allOf`. The Trusted Match match requests are the exception: they inline both fields for their strict privacy boundary. Distinct from `core/protocol-envelope.json`, which wraps responses at the transport layer (context_id / task_id / status / payload). This envelope is part of the payload itself.",
       "type": "object",
       "properties": {
         "adcp_version": {
@@ -206,7 +206,7 @@
       }
     },
     "external:enums/principal-kind.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/enums/principal-kind.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/enums/principal-kind.json",
       "title": "Principal Kind",
       "x-status": "experimental",
       "description": "Seller-resolved kind of the authenticated principal: an autonomous buyer-agent workload or an operator-side identity such as a person at the operator.",
@@ -217,7 +217,7 @@
       ]
     },
     "external:core/agent-notification-config.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/agent-notification-config.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/agent-notification-config.json",
       "title": "Agent Notification Config",
       "description": "Caller-scoped agent-level webhook subscription. Caller-anchored event types (capabilities.changed, principal.changed) always fire principal-wide; account-anchored event types may also be listed here with the explicit all_authorized_accounts acknowledgment and fire with per-delivery-attempt authorization scoping over the caller's currently authorized accounts. Registration goes through the task declared by get_adcp_capabilities.adcp.capability_changes.notifications.registration_task: sync_principal when the broader principal surface is supported, or the specialized sync_agent_notification_configs compatibility task. Both tasks operate on one underlying caller-scoped subscriber set. This surface is intentionally separate from account-level notification_configs[]: a registry or buyer can subscribe before it has an account, and one fire invalidates the agent-wide get_adcp_capabilities cache. The persisted set is scoped to the authenticated caller or registry identity, so one caller's declarative replacement cannot clear another caller's subscribers. As with other AdCP webhooks, the default signing scheme is the RFC 9421 webhook profile against the seller's brand.json agents[] JWKS; the optional authentication block opts into the deprecated Bearer / HMAC-SHA256 fallback for compatibility. Credentials and shared secrets in authentication.credentials are write-only and MUST NOT be echoed on reads. Sellers MUST verify endpoint control before activating a new or changed active agent-level notification config; delivery-time SSRF validation still applies to every fire.",
       "type": "object",
@@ -240,7 +240,7 @@
           "items": {
             "allOf": [
               {
-                "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:enums~1notification-type.json"
+                "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:enums~1notification-type.json"
               },
               {
                 "not": {
@@ -276,7 +276,7 @@
             "schemes": {
               "type": "array",
               "items": {
-                "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:enums~1auth-scheme.json"
+                "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:enums~1auth-scheme.json"
               },
               "minItems": 1,
               "maxItems": 1
@@ -298,7 +298,7 @@
           "description": "When false, the seller persists the configuration but suppresses fires. Use to pause a subscriber without losing the registration. Paused configs may skip only the outbound proof challenge while inactive; sellers MUST still enforce URL parsing, HTTPS, hostname normalization, and reserved-range rejection at write time. Reactivation requires full SSRF validation with connect pinning plus proof-of-control for any tuple without current valid proof."
         },
         "ext": {
-          "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1ext.json"
+          "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1ext.json"
         }
       },
       "required": [
@@ -360,7 +360,7 @@
       ]
     },
     "external:enums/notification-type.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/enums/notification-type.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/enums/notification-type.json",
       "title": "Notification Type",
       "description": "Type of push notification fired by a seller agent. Media-buy-anchored cadence reports (`scheduled`, `final`, `delayed`, `adjusted`, `window_update`) fire against a media buy's `reporting_webhook`; `impairment` is media-buy-anchored but fires against `push_notification_config`. Account-anchored notifications include creative, account, product, signal, wholesale-feed, and reporting events, including `reporting.delivery_ready`, `reporting.status_changed`, and `reporting.ledger_changed`; these outlive any single media buy and fire against matching account `notification_configs[]`. The reporting events repair through `get_reporting_status`: delivery_ready is managed-delivery-only, while status_changed and ledger_changed are valid in every reporting tier. Caller-anchored notifications (`capabilities.changed`, `principal.changed`) fire against the caller-scoped subscriber set managed by `sync_principal` or the specialized `sync_agent_notification_configs` compatibility task. New notification types MUST declare their anchor (media-buy, account, or caller), logical notification_id semantics, repair key, and classification in enumDescriptions; only invalidation-only caller-eligible types flow through include_future_event_types. Account-level subscribers MUST reject media-buy- or caller-anchored event types, and persistent account- or caller-anchored types MUST NOT use push_notification_config. Caller-level entries MAY include account-anchored types only with all_authorized_accounts true; each delivery attempt, including retries, is scoped to accounts currently authorized for that caller. Caller-level entries MUST NOT include media-buy-anchored types. Caller- and account-level subscriptions to the same event are independent and receivers dedupe by logical notification_id.",
       "type": "string",
@@ -422,7 +422,7 @@
       }
     },
     "external:enums/auth-scheme.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/enums/auth-scheme.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/enums/auth-scheme.json",
       "title": "Authentication Scheme",
       "deprecated": true,
       "description": "Legacy authentication schemes for the webhook auth block. Bearer: token sent in Authorization header. HMAC-SHA256: legacy shared-secret signing. Both are deprecated; new integrations SHOULD omit the authentication block and use the RFC 9421 webhook signing profile (applicable on schemas where authentication is optional). Removed in AdCP 4.0.",
@@ -433,14 +433,14 @@
       ]
     },
     "external:core/ext.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/ext.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/ext.json",
       "title": "Extension Object",
       "description": "Extension object for platform-specific, vendor-namespaced parameters. Extensions are always optional and must be namespaced under a vendor/platform key (e.g., ext.gam, ext.roku). Used for custom capabilities, partner-specific configuration, and features being proposed for standardization.",
       "type": "object",
       "additionalProperties": true
     },
     "external:core/agent-reporting-destination.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/agent-reporting-destination.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/agent-reporting-destination.json",
       "title": "Agent Reporting Destination",
       "x-status": "experimental",
       "description": "Reusable, non-secret reporting destination owned by the authenticated caller's relationship with one seller. Exactly one delivery pattern per destination; pattern is the discriminator and matches the managed reporting delivery pattern vocabulary. It does not grant account authority: account/reporting configuration separately binds authorized data to the seller-issued destination_ref. Sellers key ownership to the stable transport principal, never a signing key, token, or request-body identity. Credentials, private keys, bearer profiles, signed URLs, and embedded passwords are forbidden. Sellers implementing this schema advertise protocol.principal.",
@@ -473,7 +473,7 @@
               "description": "True permits use. False suspends the destination: the seller MUST stop initiating new deliveries to every generation of this destination_id within the advertised suspension interval, and new account-level delivery configurations MUST NOT select it. Suspension does not delete caller-owned data already delivered."
             },
             "provider": {
-              "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1delivery-provider.json"
+              "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1delivery-provider.json"
             },
             "transport": {
               "type": "string",
@@ -506,7 +506,7 @@
               "description": "Physical formats accepted by this file-transfer destination."
             },
             "accepted_verification_profiles": {
-              "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1reporting-verification-profile-set.json"
+              "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1reporting-verification-profile-set.json"
             }
           },
           "required": [
@@ -549,7 +549,7 @@
               "description": "True permits use. False suspends the destination: the seller MUST stop initiating new deliveries to every generation of this destination_id within the advertised suspension interval, and new account-level delivery configurations MUST NOT select it. Suspension does not delete caller-owned data already delivered."
             },
             "provider": {
-              "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1delivery-provider.json"
+              "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1delivery-provider.json"
             },
             "transport": {
               "type": "string",
@@ -566,7 +566,7 @@
               "description": "Provider-native project/dataset, database/schema, or catalog/schema locator. Printable ASCII without whitespace, '?', '#', '%', '\"', '<', or '>'. Never a credential or signed URL; sellers additionally screen and normalize per the secret_rejection and normalization rules."
             },
             "accepted_verification_profiles": {
-              "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1reporting-verification-profile-set.json"
+              "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1reporting-verification-profile-set.json"
             }
           },
           "required": [
@@ -608,7 +608,7 @@
               "description": "True permits use. False suspends the destination: the seller MUST stop publishing new revisions to every generation of this destination_id within the advertised suspension interval, and new account-level delivery configurations MUST NOT select it. Suspension does not delete caller-owned data already delivered or revoke provider-side grants by itself."
             },
             "provider": {
-              "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1delivery-provider.json"
+              "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1delivery-provider.json"
             },
             "transport": {
               "type": "string",
@@ -625,10 +625,10 @@
               "description": "Dataset-share access family, such as databricks_to_databricks, open_sharing, or secure_data_sharing."
             },
             "recipient": {
-              "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1delivery-recipient.json"
+              "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1delivery-recipient.json"
             },
             "accepted_verification_profiles": {
-              "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1reporting-verification-profile-set.json"
+              "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1reporting-verification-profile-set.json"
             }
           },
           "required": [
@@ -657,7 +657,7 @@
       }
     },
     "external:core/delivery-provider.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/delivery-provider.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/delivery-provider.json",
       "title": "Delivery Provider",
       "description": "Provider namespace for an external delivery or data-sharing service. This identifies a platform; it is not a credential, trust root, or authorization statement.",
       "type": "object",
@@ -674,7 +674,7 @@
       "additionalProperties": false
     },
     "external:core/reporting-verification-profile-set.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/reporting-verification-profile-set.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/reporting-verification-profile-set.json",
       "title": "Reporting Verification Profile Set",
       "description": "Verification profiles the destination can accept. native_commit requires provider-native transaction/version evidence plus counts and control totals; manifest_checksums requires a committed file manifest with cryptographic checksums; canonical_digest requires recomputation of the canonical logical-content digest. A reporting feed selects one profile from this allowed set according to the seller offering and the feed's strictness requirements.",
       "type": "array",
@@ -690,7 +690,7 @@
       "uniqueItems": true
     },
     "external:core/delivery-recipient.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/delivery-recipient.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/delivery-recipient.json",
       "title": "Delivery Recipient",
       "description": "Provider-interpreted recipient identity for a seller-hosted share. Examples include a sharing identifier or organization/account pair. The value is an identifier, never a credential.",
       "type": "object",
@@ -701,7 +701,7 @@
           "maxLength": 512
         },
         "cloud": {
-          "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:enums~1delivery-recipient-cloud.json"
+          "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:enums~1delivery-recipient-cloud.json"
         },
         "region": {
           "type": "string",
@@ -723,7 +723,7 @@
       }
     },
     "external:enums/delivery-recipient-cloud.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/enums/delivery-recipient-cloud.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/enums/delivery-recipient-cloud.json",
       "title": "Delivery Recipient Cloud",
       "x-status": "experimental",
       "description": "Cloud family hosting a delivery recipient's account, used together with region to disambiguate provider-native recipient identities.",
@@ -735,7 +735,7 @@
       ]
     },
     "external:core/principal-declarations.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/principal-declarations.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/principal-declarations.json",
       "title": "Agent Declarations",
       "x-status": "experimental",
       "description": "Bounded, non-secret facts the authenticated caller declares about what it can consume from this seller. This is the buyer-declared half of capability negotiation: get_adcp_capabilities stays objective seller facts, declarations stay caller facts, and the seller-computed accepted intersection is the negotiated contract for asynchronous interactions. Declarations exist chiefly because webhook fires have no request context to negotiate against: the durable declaration is the version and algorithm channel for pushes. Declarations are facts about consumption ability, never preferences, policies, or an open-ended feature language. Submitting an empty object clears the declared set.",
@@ -768,7 +768,7 @@
         "experimental_features": {
           "type": "array",
           "items": {
-            "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1experimental-feature-id.json"
+            "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/protocol/sync-principal-request.json#/$defs/external:core~1experimental-feature-id.json"
           },
           "minItems": 1,
           "maxItems": 32,
@@ -779,7 +779,7 @@
       "additionalProperties": false
     },
     "external:core/experimental-feature-id.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/experimental-feature-id.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/experimental-feature-id.json",
       "title": "Experimental Feature ID",
       "description": "Dot-separated lowercase identifier for an experimental AdCP surface, such as protocol.principal or media_buy.reporting_delivery.",
       "type": "string",
@@ -788,7 +788,7 @@
       "pattern": "^[a-z][a-z0-9_]*(\\.[a-z][a-z0-9_]*)*$"
     },
     "external:core/context.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/context.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/context.json",
       "title": "Context Object",
       "description": "Opaque correlation data that is echoed unchanged in responses. Used for internal tracking, UI session IDs, trace IDs, and other caller-specific identifiers that don't affect protocol behavior. Context data is never parsed by AdCP agents - it's simply preserved and returned.",
       "type": "object",

package/dist/lib/schemas-data/3.2/mcp/2026-07-28/signals/activate-signal-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/signals/activate-signal-request.json",
+  "$id": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/signals/activate-signal-request.json",
   "title": "Activate Signal Request",
   "description": "Request parameters for activating or deactivating a signal on deployment targets",
   "type": "object",
@@ -94,9 +94,9 @@
   "additionalProperties": true,
   "$defs": {
     "external:core/version-envelope.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/version-envelope.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/version-envelope.json",
       "title": "AdCP Version Envelope",
-      "description": "Release-precision AdCP protocol version negotiation fields. Composed via `allOf` into every AdCP request and response schema so the version semantics live in exactly one place. Distinct from `core/protocol-envelope.json`, which wraps responses at the transport layer (context_id / task_id / status / payload). This envelope is part of the payload itself.",
+      "description": "Release-precision AdCP protocol version negotiation fields. Composed via `allOf` into AdCP request schemas and shared response components so the version semantics live in one place. Strict (`additionalProperties: false`) request schemas also redeclare these two fields in their own `properties` via `$ref`, because draft-07 does not evaluate properties across `allOf`. The Trusted Match match requests are the exception: they inline both fields for their strict privacy boundary. Distinct from `core/protocol-envelope.json`, which wraps responses at the transport layer (context_id / task_id / status / payload). This envelope is part of the payload itself.",
       "type": "object",
       "properties": {
         "adcp_version": {
@@ -120,7 +120,7 @@
       }
     },
     "external:core/destination.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/destination.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/destination.json",
       "title": "Destination",
       "description": "A deployment target where signals can be activated (DSP, sales agent, etc.)",
       "discriminator": {
@@ -175,7 +175,7 @@
       ]
     },
     "external:core/account-ref.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/account-ref.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/account-ref.json",
       "title": "Account Reference",
       "description": "Reference to an advertiser account by seller-assigned ID or natural key. account_id is the seller/storefront handle returned by list_accounts. The natural key is brand + operator + optional operator_unit.id + optional fixed currency + optional buyer-selected account timezone + sandbox; it describes the advertiser object the seller resolves or provisions. After a capability-gated identity rekey, the former natural key is tombstoned and returns ACCOUNT_MOVED to authorized callers rather than resolving or provisioning another account. brand.countries qualifies the advertiser's geographic identity. operator_unit identifies the operator-owned buying seat or business unit and is distinct from the seller account. operator_unit.name is display metadata and does not participate in identity. Use account_id when the seller or upstream platform owns the canonical account namespace; use the natural key for buyer-declared accounts (require_operator_auth: false).",
       "type": "object",
@@ -196,7 +196,7 @@
         {
           "properties": {
             "brand": {
-              "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:core~1brand-ref.json",
+              "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:core~1brand-ref.json",
               "description": "Brand reference identifying the advertiser"
             },
             "operator": {
@@ -206,7 +206,7 @@
               "x-entity": "operator"
             },
             "operator_unit": {
-              "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:core~1operator-unit.json",
+              "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:core~1operator-unit.json",
               "description": "Optional operator-owned business unit, agency seat, or platform account. Only id participates in the natural account key; name is mutable display metadata."
             },
             "currency": {
@@ -274,7 +274,7 @@
       ]
     },
     "external:core/brand-ref.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/brand-ref.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/brand-ref.json",
       "title": "Brand Reference",
       "description": "Reference to a brand by domain and optional brand_id. The domain hosts /.well-known/brand.json or is registered in the brand registry. For single-brand domains, brand_id can be omitted. For house-of-brands domains, brand_id identifies the specific brand. For creative production, brand.json is the canonical source of master brand identity (logo, palette, fonts, voice, and visual guidelines), subject only to the supported per-call fields in brand_kit_override. Catalogs supply product or item payload; catalog item asset groups, including property- or franchise-level logos, are item identity and do not override these master brand fields.",
       "type": "object",
@@ -285,7 +285,7 @@
           "pattern": "^[a-z0-9]([a-z0-9-]*[a-z0-9])?(\\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)*$"
         },
         "brand_id": {
-          "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:core~1brand-id.json",
+          "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:core~1brand-id.json",
           "description": "Brand identifier within the house portfolio. Optional for single-brand domains."
         },
         "countries": {
@@ -344,7 +344,7 @@
           "description": "Inline override for brand-kit fields normally resolved from `/.well-known/brand.json` on `domain` (logo, colors, voice, tagline). Use when brand.json is missing, stale, or inappropriate for this specific call — e.g., a campaign-scoped tagline, a co-branded creative, a freshly-rebranded color palette the brand.json hasn't shipped yet. Same inline-override pattern as `industries` and `data_subject_contestation` above: brand.json is canonical, the override is per-call. Adopters needing to override fields outside this subset (`voice_attributes`, `prohibited_terms`, etc.) MUST publish a different brand.json and reference it via a different `domain` — the inline override is intentionally narrow to a small high-traffic subset.\n\n**Merge semantics (normative).** The merge is **field-level**, not whole-object replacement. Each field within `brand_kit_override` (`logo`, `colors`, `voice`, `tagline`) is evaluated independently — when a field is present on the override the override value applies; when a field is absent the brand.json value applies (or is absent if brand.json doesn't carry one either). For composite fields (`colors.primary`, `colors.secondary`, `colors.accent`), the merge is one level deeper: each color slot is evaluated independently — a producer can override `colors.primary` while still inheriting `colors.secondary` from brand.json. SDKs MUST NOT treat a present `brand_kit_override.colors` as wiping the brand.json `colors` block entirely; only the per-slot fields present in the override take precedence. Without this rule, a partial-override semantics would diverge across SDKs and produce inconsistent rendering for the same payload.",
           "properties": {
             "logo": {
-              "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:core~1assets~1image-asset.json",
+              "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:core~1assets~1image-asset.json",
               "description": "Override logo asset."
             },
             "colors": {
@@ -403,7 +403,7 @@
       ]
     },
     "external:core/brand-id.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/brand-id.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/brand-id.json",
       "title": "Brand ID",
       "description": "Identifier for a brand within a house portfolio. Must be lowercase alphanumeric with underscores only. The house chooses this identifier.",
       "type": "string",
@@ -418,7 +418,7 @@
       ]
     },
     "external:core/assets/image-asset.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/assets/image-asset.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/assets/image-asset.json",
       "title": "Image Asset",
       "description": "Image asset with URL and dimensions",
       "type": "object",
@@ -482,7 +482,7 @@
           "x-accessibility": true
         },
         "provenance": {
-          "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:core~1provenance.json",
+          "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:core~1provenance.json",
           "description": "Provenance metadata for this asset, overrides manifest-level provenance"
         }
       },
@@ -495,13 +495,13 @@
       "additionalProperties": true
     },
     "external:core/provenance.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/provenance.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/provenance.json",
       "title": "Provenance",
       "description": "Declares how content was produced, whether AI was involved, and what disclosure obligations apply. Attaches to creative manifests, individual assets, or content-standards artifacts. When present at multiple levels, the most specific provenance object replaces the inherited one entirely (no field-level merging). Provenance is a claim by the declaring party — receiving parties should verify claims independently via their own detection tools.",
       "type": "object",
       "properties": {
         "digital_source_type": {
-          "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:enums~1digital-source-type.json",
+          "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:enums~1digital-source-type.json",
           "description": "IPTC-aligned classification of AI involvement in producing this content"
         },
         "synthetic_depiction": {
@@ -611,7 +611,7 @@
             "type": "object",
             "properties": {
               "method": {
-                "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:enums~1embedded-provenance-method.json",
+                "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:enums~1embedded-provenance-method.json",
                 "description": "How provenance data is carried within the content"
               },
               "standard": {
@@ -662,7 +662,7 @@
             "type": "object",
             "properties": {
               "media_type": {
-                "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:enums~1watermark-media-type.json",
+                "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:enums~1watermark-media-type.json",
                 "description": "Media category of the watermarked content"
               },
               "provider": {
@@ -690,7 +690,7 @@
                 "additionalProperties": false
               },
               "c2pa_action": {
-                "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:enums~1c2pa-watermark-action.json",
+                "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:enums~1c2pa-watermark-action.json",
                 "description": "C2PA action classification for this watermark"
               },
               "embedded_at": {
@@ -741,7 +741,7 @@
                     "minProperties": 1,
                     "properties": {
                       "persistence": {
-                        "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:enums~1disclosure-persistence.json",
+                        "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:enums~1disclosure-persistence.json",
                         "description": "How long the disclosure must persist during content playback or display"
                       },
                       "min_duration_ms": {
@@ -753,13 +753,13 @@
                         "type": "array",
                         "description": "Preferred disclosure positions in priority order. The first position a format supports should be used.",
                         "items": {
-                          "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:enums~1disclosure-position.json"
+                          "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:enums~1disclosure-position.json"
                         },
                         "minItems": 1,
                         "uniqueItems": true
                       },
                       "ext": {
-                        "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:core~1ext.json"
+                        "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:core~1ext.json"
                       }
                     }
                   }
@@ -821,12 +821,12 @@
           }
         },
         "ext": {
-          "$ref": "https://adcontextprotocol.org/schemas/3.2.3/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:core~1ext.json"
+          "$ref": "https://adcontextprotocol.org/schemas/3.2.4/mcp/2026-07-28/signals/activate-signal-request.json#/$defs/external:core~1ext.json"
         }
       }
     },
     "external:enums/digital-source-type.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/enums/digital-source-type.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/enums/digital-source-type.json",
       "title": "Digital Source Type",
       "description": "Classification of AI involvement in content creation, aligned with IPTC digitalsourcetype vocabulary. Used in provenance metadata to declare how a creative asset, artifact, or individual asset was produced.",
       "type": "string",
@@ -854,7 +854,7 @@
       }
     },
     "external:enums/embedded-provenance-method.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/enums/embedded-provenance-method.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/enums/embedded-provenance-method.json",
       "title": "Embedded Provenance Method",
       "description": "How provenance data is carried within the content stream. Distinguishes between format-level manifest embedding (where the manifest travels inside the file container) and provenance markers (where invisible markers in the content itself encode or reference a provenance record). Both survive operations that strip sidecar metadata, but provenance markers additionally survive content-level transformations such as copy-paste, reformatting, and CMS re-encoding.",
       "type": "string",
@@ -868,7 +868,7 @@
       }
     },
     "external:enums/watermark-media-type.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/enums/watermark-media-type.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/enums/watermark-media-type.json",
       "title": "Watermark Media Type",
       "description": "Media category of a content watermark. Identifies what kind of content the watermark is applied to, which determines the detection and verification methods required.",
       "type": "string",
@@ -886,7 +886,7 @@
       }
     },
     "external:enums/c2pa-watermark-action.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/enums/c2pa-watermark-action.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/enums/c2pa-watermark-action.json",
       "title": "C2PA Watermark Action",
       "description": "C2PA action classification for a content watermark. Distinguishes watermarks that are cryptographically linked to a C2PA manifest (bound) from watermarks that exist independently (unbound). Aligns with the c2pa.watermarked.* action family in the C2PA action taxonomy.",
       "type": "string",
@@ -900,7 +900,7 @@
       }
     },
     "external:enums/disclosure-persistence.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/enums/disclosure-persistence.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/enums/disclosure-persistence.json",
       "title": "Disclosure Persistence",
       "description": "How long a disclosure must persist during content playback or display. Different jurisdictions and regulations require different persistence behaviors for AI-generated content labels. When multiple sources specify persistence for the same jurisdiction (e.g., brief and provenance), the most restrictive mode applies: continuous > initial > flexible.",
       "type": "string",
@@ -916,7 +916,7 @@
       }
     },
     "external:enums/disclosure-position.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/enums/disclosure-position.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/enums/disclosure-position.json",
       "title": "Disclosure Position",
       "description": "Where a required disclosure should appear within a creative. Used by creative briefs to specify disclosure placement and by formats to declare which positions they can render.",
       "type": "string",
@@ -932,14 +932,14 @@
       ]
     },
     "external:core/ext.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/ext.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/ext.json",
       "title": "Extension Object",
       "description": "Extension object for platform-specific, vendor-namespaced parameters. Extensions are always optional and must be namespaced under a vendor/platform key (e.g., ext.gam, ext.roku). Used for custom capabilities, partner-specific configuration, and features being proposed for standardization.",
       "type": "object",
       "additionalProperties": true
     },
     "external:core/operator-unit.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/operator-unit.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/operator-unit.json",
       "title": "Operator Unit",
       "description": "Operator-owned buying context used to distinguish business units, agency seats, or platform accounts beneath one operator domain. The id is stable identity in the operator's namespace; name is mutable display metadata and never participates in account identity.",
       "x-entity": "operator_unit",
@@ -975,7 +975,7 @@
       ]
     },
     "external:core/context.json": {
-      "$id": "https://adcontextprotocol.org/schemas/3.2.3/core/context.json",
+      "$id": "https://adcontextprotocol.org/schemas/3.2.4/core/context.json",
       "title": "Context Object",
       "description": "Opaque correlation data that is echoed unchanged in responses. Used for internal tracking, UI session IDs, trace IDs, and other caller-specific identifiers that don't affect protocol behavior. Context data is never parsed by AdCP agents - it's simply preserved and returned.",
       "type": "object",