Formalize `status-change-resource-type` enum for MCP Resources subscription

[bokelley]

Summary

The spec doesn't ship a closed enum for status-change `resource_type` values. Implementers inventing event-bus status changes have to guess which resource categories are first-class. The SDK shipping the v6 `DecisioningPlatform` runtime needed this taxonomy and currently uses an SDK-defined union:

```ts
type StatusChangeResourceType =
| 'media_buy'
| 'creative'
| 'audience'
| 'signal'
| 'proposal'
| 'plan'
| 'rights_grant'
| 'delivery_report'
| 'property_list'
| 'collection_list';
```

These are the resource categories adopters publish status changes against today (`publishStatusChange({ resource_type, resource_id, payload })`). They map to the URI scheme `adcp://{account_id}/{resource_type}/{resource_id}` that the framework projects to MCP Resources subscribers.

Why this matters

When MCP Resources subscription wiring lands in the AdCP spec — projecting status changes to `notifications/resources/updated` — the `resource_type` becomes a wire string buyers parse. Without a normative spec enum:

• Different SDKs invent different sets, breaking interop. A salesagent (Python) and adcp-client (TypeScript) implementation could both ship `audience` lifecycle events but use different naming.
• Buyers can't enumerate "all subscribable resource types" without inspecting capability declarations from each agent.
• Adding a new lifecycle channel (e.g., `pcim_session` for sponsored intelligence) requires every implementer to coordinate.

Proposed fix

Add `schemas/v3/enums/status-change-resource-type.json`:

```json
{
"$schema": "http://json-schema.org/draft-07/schema#\",
"$id": "/schemas/v3/enums/status-change-resource-type.json",
"title": "Status Change Resource Type",
"description": "Resource categories whose lifecycle changes can be subscribed to via MCP Resources / push-notification webhooks.",
"type": "string",
"enum": [
"media_buy", "creative", "proposal", "delivery_report",
"audience", "signal", "plan", "rights_grant",
"property_list", "collection_list"
]
}
```

Reference from `mcp-webhook-payload.json` and the MCP Resources subscription URI scheme spec.

Open question — `x-` prefix for SDK extensions?

If the spec ships a tighter set, SDKs that ship more resource categories than the spec lists would need either (a) a spec follow-up to add the missing values, or (b) an `x-` prefix convention for SDK-extended values. The proposed enum above includes everything the v6 SDK ships today; if any of these are deemed out-of-scope for the wire-level enum, the SDK would x-prefix them. Worth documenting the convention either way.

Reference

• Original report: PR fix(addie): Remove duplicate validate_adagents tool causing API 400 errors #1005 protocol round-3 review (Protocol-M2)
• SDK source: `src/lib/server/decisioning/status-changes.ts:38-48`
• Existing status-change projection: `adcp://{account_id}/{resource_type}/{resource_id}` (SDK-defined URI scheme)

Context

Filing on behalf of the v6 SDK preview (PR #1005) which centralized the status-change taxonomy for the first time. Other implementations will hit this when they wire MCP Resources subscription on top of AdCP.

[bokelley]

Triage

Classification: Feature request
Bucket(s): spec / protocol
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Flag — delivery_report has no companion *-changed-webhook.json, no x-entity type, and no subscribable status machine in 3.0 GA; formalizing it presupposes a lifecycle model not yet designed. plan is wire-ambiguous (spec defines both governance_plan and media_plan); remaining 8 values are structurally clean.
• adtech-product-expert: Flag — delivery_report is a pull artifact in operator reality (get_media_buy_delivery), not a lifecycle resource DSPs/SSPs subscribe to; adding it risks a second notification channel that collides with reporting-webhook.json. plan is redundant with proposal, which already has proposal-status and is the 3.0 GA canonical term.

My take: The interop gap is real and the window to fix it (before MCP Resources subscription lands) is right. Two values need a decision before a PR is safe — the other 8 are straightforward. Two editorial fixes are needed regardless: $id must use /schemas/enums/… (not /schemas/v3/enums/…), and enumDescriptions must be added per the existing enum convention.

Option A — 8-value set, ship now (drop delivery_report + plan; add delivery_report once its subscription lifecycle is scoped in 3.1):

{
  "$id": "/schemas/enums/status-change-resource-type.json",
  "type": "string",
  "enum": [
    "media_buy", "creative", "proposal",
    "audience", "signal", "rights_grant",
    "property_list", "collection_list"
  ]
}

Downstream SDKs can x- prefix delivery_report until it's promoted. Unblocks MCP Resources subscription wiring on the stable values.

Option B — Full 10-value set (requires scoping delivery_report as a first-class subscribable entity with a status machine, and explicitly deprecating plan in favor of proposal):

{
  "$id": "/schemas/enums/status-change-resource-type.json",
  "type": "string",
  "enum": [
    "media_buy", "creative", "proposal", "delivery_report",
    "audience", "signal", "plan", "rights_grant",
    "property_list", "collection_list"
  ]
}

Ships the full SDK taxonomy as-is but makes a forward-commitment on delivery_report lifecycle before the 3.1 subscription storyboard exists, and adds a plan token that could confuse buyers once governance_plan/media_plan disambiguation lands.

@bokelley, your call: A (ship the 8 safe values now, follow up on delivery_report once its subscription model is scoped) or B (scope the full set first)?

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01JzBThrMhJpJBxuJ4PjkRZA

---

Generated by Claude Code