Version Packages

[aao-release-bot]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to 3.0.x, this PR will be updated.

Releases

adcontextprotocol@3.0.13

Patch Changes

• d35ccf0: Backport MCP transport clarification to v3_envelope_integrity storyboard (3.0.x).

  Adds the MCP-specific note (already present on main) explaining that status must
  appear at the top level of structuredContent and is distinct from the
  task-body schema (get-adcp-capabilities-response.json). Addresses the
  confusion reported in v3_envelope_integrity/no_legacy_status_fields expects presence of status field on get_adcp_capabilities envelope, but SDK 7.7.0 does not inject one — schema/storyboard drift #4832: response_schema passes because the task schema
  intentionally omits protocol envelope fields; envelope_field_present for
  status is the separate, correct enforcement layer. Also updates the expected
  block header from "Response envelope:" to "Response envelope (all transports):"
  to match main-branch wording.

  The field_absent TODO comments for task_status/response_status are unchanged —
  those await field_absent runner support in adcp-client (tracked separately).
  The SDK gap (SDK 7.7.0 not emitting status on get_adcp_capabilities) is a
  sibling-repo concern also tracked separately.

• b2f9ce3: Docs: add the now-required account.supported_billing block to the four
  get_adcp_capabilities example JSON blocks that declare media_buy
  support.

  Since fix(schema): make account.supported_billing conditional on media_buy protocol #3750 (fix(schema): make account.supported_billing conditional on media_buy protocol), the response schema requires account.supported_billing
  whenever supported_protocols contains media_buy. Four illustrative
  examples in the docs (creative/sales-agent-creative-capabilities.mdx,
  media-buy/specification.mdx, reference/migration/channels.mdx,
  reference/migration/geo-targeting.mdx) were not updated alongside the
  schema and have been failing CI's schema validation step on 3.0.x HEAD,
  blocking every other patch PR against the branch.

  Each example now includes "account": { "supported_billing": ["operator", "agent"] }, matching the pattern already used in
  docs/building/integration/accounts-and-agents.mdx. Documentation only —
  no protocol behavior change.

• b605ef8: IdentityMatch & frequency capping architecture, with the wire-spec change and the data-flow boundary contract landing as authoritative protocol docs. Counting and policy live in the buyer's impression tracker; the IdentityMatch service consumes only cap-fire events at the boundary.

  Wire spec changes (identity-match-response.json):

  • Adds serve_window_sec (integer, 1–300, default 60) — per-package single-shot fcap window. After serving the user one impression on each eligible package within this window, the publisher MUST re-query Identity Match before serving from those packages again. Not a router response cache TTL.
  • Removes ttl_sec. Originally documented as a router cache TTL but operationally functioned as a per-package serve throttle. TMP is pre-launch (experimental, pre-3.0.0 GA) and not subject to deprecation cycles, so the field is removed outright.

  Doc updates:

  • docs/trusted-match/specification.mdx — adds serve_window_sec field, removes ttl_sec, adds normative conformance invariants for IdentityMatch eligibility (audience intersection; cap-state presence check; active state; audience freshness). Updates the caching section for the new contract.
  • docs/trusted-match/identity-match-implementation.mdx (new page) — frequency-cap data flow (boundary contract): the cap-fire event the impression tracker writes into the IdentityMatch cap-state store, and how the IdentityMatch service consumes it at query time. The protocol does not constrain how the impression tracker counts impressions, evaluates windows, or decides when a cap fires — those concerns live entirely in the buyer's impression-tracking pipeline.
  • docs/trusted-match/buyer-guide.mdx — updates frequency-cap management to reflect the impression-tracker / IdentityMatch split, and the serve-window contract section.
  • docs/trusted-match/migration-from-axe.mdx — adds OpenRTB 2.6 User.eids[] cross-walk for buyers bridging from OpenRTB-shaped pipelines.

  Three-layer model:

  • Wire spec (normative) — what crosses an agent boundary.
  • Conformance invariants (normative) — backend-agnostic eligibility logic, including a presence check against cap-state.
  • Boundary contract (normative for the cap-state store API) — what events flow from the impression tracker into the IdentityMatch cap-state store. Storage backend is implementer choice; the reference store ships in adcp-go/targeting/fcap (Valkey 9 hashes with HSETEX).

  Cap-state store surface: RecordCap(userIdentity, fields, expireAt) and IsCapped(userIdentity, field), where field is {seller_agent_url, package_id}. v1 keys cap-state at (user_identity, seller_agent_url, package_id); broader-dimension caps (advertiser, campaign, creative, line item) are a future extension to the boundary contract.

  Architecture history preserved at specs/identitymatch-fcap-architecture.md — captures design decisions, deferred security/privacy follow-ups, the rollout plan, and consolidated Slack/PR-review threads. Earlier iterations of the design (counter-based exposure tracking, log-based tracking with impression_id dedup, fcap_keys label model) were unwound — counting, dedup, and policy evaluation depend on buyer-internal concerns the protocol shouldn't constrain.

  All TMP surfaces remain x-status: experimental. Per the experimental-status contract, fields on this surface are not subject to deprecation cycles until 3.0.0 GA.

  Tracked deferred follow-ups (not in this PR):

  • TMPX harvest → competitor-suppression attack
  • Eligibility-as-audience-membership oracle (honeypot package_ids)
  • Consent revocation between IdentityMatch and impression
  • Side-channel via eligibility deltas
  • hashed_email in TMPX leak surface
  • DoS amplification via large package_ids[]
  • Cap-state extensions for advertiser/campaign/creative dimensions
  • Identity-graph plug-point in the impression tracker