Conversation
Follow-up to #632. The schema's `mcp-webhook-payload.json` defines a typed `protocol` field (`AdcpProtocol` enum: `media-buy | signals | governance | creative | brand | sponsored-intelligence`); the builder was instead accepting an undocumented `domain` string and stuffing it into the wire body via `extra='allow'`. The JS reference implementation (`buildTaskWebhookPayload` in `from-platform.ts`) sets `payload.protocol` and never sets `domain` — so the Python SDK was the outlier. Replaces `create_mcp_webhook_payload(..., domain=...)` and `WebhookSender.send_mcp(..., domain=...)` with `protocol=...`. The kwarg accepts either an `AdcpProtocol` enum value or a kebab-case string; unknown values raise `ValidationError` at construction. `AdcpProtocol` is now publicly exported from `adcp.types`. Zero in-repo callers passed `domain=`; verified by grep before the swap. The kwarg was added in #632's same migration window so the breaking- change cycle is bundled. BREAKING CHANGE: `domain` kwarg removed from `create_mcp_webhook_payload` and `WebhookSender.send_mcp`. Migrate to `protocol` (kebab-case string or `AdcpProtocol` enum value). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Caller now passes only `task_type` and the builder fills `protocol` from the canonical `TaskType` → `AdcpProtocol` mapping. Mirrors `protocolForTool` in `adcontextprotocol/adcp-client:src/lib/server/ decisioning/runtime/protocol-for-tool.ts` so cross-SDK webhook bodies classify operations identically. The mapping covers all 20 spec values; explicit `protocol=` passed by the caller still wins. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #632. The schema's
mcp-webhook-payload.jsondefines a typedprotocolfield (AdcpProtocolenum:media-buy | signals | governance | creative | brand | sponsored-intelligence); the builder was instead accepting an undocumenteddomainstring and stuffing it into the wire body viaextra='allow'. The JS reference implementation (buildTaskWebhookPayloadinfrom-platform.ts) setspayload.protocoland never setsdomain— so the Python SDK was the outlier.Summary
create_mcp_webhook_payload(..., domain=...)→create_mcp_webhook_payload(..., protocol=...)WebhookSender.send_mcp(..., domain=...)→WebhookSender.send_mcp(..., protocol=...)protocolacceptsAdcpProtocol | str | None; unknown values raiseValidationErrorat construction.AdcpProtocolis now publicly exported fromadcp.types.Why a clean break (no
domaindeprecation alias)domainwas never in the spec; no schema contract to honor.domain=to the builder (verified by grep).Cross-SDK alignment
Verified in
adcontextprotocol/adcp-client(the JS SDK):buildTaskWebhookPayloadsetspayload.protocol = protocolForTool(opts.tool)(sameAdcpProtocol6-value enum).TaskTypeis enforced asSPEC_WEBHOOK_TASK_TYPESat theemitTaskWebhookdispatch layer (skip-with-warning vs. our raise-at-construction — both spec-conformant; different surfaces).Follow-up worth filing
The JS SDK auto-derives
protocolfrom the tool name (protocolForTool(opts.tool)). Our Python builder leavesprotocolas a manual kwarg. A future enhancement could mirror the JS behavior — caller passes onlytask_type, builder fills inprotocolfrom aTaskType → AdcpProtocolmapping. Out of scope here; flagging.BREAKING CHANGE:
domainkwarg removed. Migrate toprotocol.Test plan
pytest tests/— 4211 passed (added 1 new test for theprotocolkwarg accepting enum/string and rejecting unknowns)mypy src/adcp/— cleanruff+black— cleanpublic_api_snapshot.jsonregenerated to includeAdcpProtocolTaskTypeis auto-generated fromschemas/cache/enums/task-type.json; same source the JSSPEC_WEBHOOK_TASK_TYPESderives from)🤖 Generated with Claude Code