AdCP — Choose your SDK

The AdCP SDKs absorb L0–L3 (wire, signing, auth, protocol semantics) so you write L4 business logic. Pick the SDK in the language you’re already in — all three SDKs target the same wire conformance bar.

For production, start with a maintained SDK. AdCP remains an open wire protocol, and raw schemas are appropriate for SDK authors, code generators, and specialized infrastructure. A production implementation built directly on the wire must independently get version negotiation, validation, signing, authorization, async state, idempotency, retry, compatibility, and audit behavior right. That is a legitimate enterprise investment, but it should be a deliberate one—not the default integration path.

For the layered model behind this — what each layer contains and what an SDK at each layer should provide — see the SDK stack reference.

Coverage matrix

What “shipped” means at each layer is the L0–L3 checklist. Last updated: 2026-09-11.

SDK	Current package	3.2 RC support	L0	L1	L2	L3
`@adcp/sdk` (TypeScript)	`14.0.0-rc.33`	Exact `3.2.0-rc.1` support	✅	✅	✅	✅
`adcp` (Python)	`8.0.0b14`	Exact `3.2.0-rc.1` schemas and types; higher-level helpers remain partial	✅	⚠️	⚠️	⚠️
`adcp/v3` (Go)	`v3.2.1`	Exact `3.2.0-rc.1` generated schemas and types; higher layers remain role-dependent	✅	⚠️	⚠️	⚠️

Legend: ✅ shipped · ⚠️ partial / role-dependent · ❌ not yet covered. The L0–L3 columns describe the current package, not a 3.2 support claim.

All three maintained SDKs now embed RC.1. Pin the exact package and wire versions shown here for development and staging. This is not a GA signal: production integrations should remain on 3.1 until 3.2 is released. See the 3.2 prerelease program.

The TypeScript SDK currently provides the broadest L0–L3 surface. Python is a first-class SDK with complete schema/type coverage and role-dependent higher layers. The Go adcp/v3 module provides typed AdCP 3.x surfaces, signing, and transport/server building blocks with role-dependent coverage. Check the release links below for changes after this matrix date. For the status of every published protocol version, see Versions & Compatibility. Migration and archived-version guidance lives under Release notes & migration. TypeScript and Python are the first-class supported languages, with the layer coverage shown in the matrix above. Go is moving in the same direction. Other languages are not on the official roadmap; community-maintained ports are welcome — see the Builders Working Group and the Slack community.

Media-buy compatibility across 3.x

Sharing a protocol schema bundle does not imply identical workflow automation. Keep the SDK package version, the served AdCP version, and the seller’s advertised lifecycle tools separate.

SDK	Entry point for mixed-version buying	Current boundary
TypeScript	`agent.negotiateMediaBuyLifecycle()` selects native or established tools per operation.	Named `allowedLosses` permit supported legacy mutations; results expose the executed tools and losses. Direct `agent.listProducts()` / `agent.buyProducts()` calls use the native tools.
Python	Established client methods remain available; `adcp.compat.purchase_continuation.LegacyPurchaseCoordinator` handles explicit legacy purchase continuations.	Compact methods such as `client.buy_products()` dispatch the same-named tool. The continuation coordinator requires a store and executor; it is not a general automatic lifecycle router.
Go	Version helpers, generated request/response types, and typed server registration.	Buyer lifecycle selection and continuation orchestration remain application-owned.

The TypeScript coordinator already supports ordinary legacy purchase behavior with explicit loss opt-ins. Its current listing adapter rejects compact criteria, and its direct-buy adapter still requires a real feed_version, even when the caller accepts non-atomic fencing. Products-only brief purchase continuations provide a separate legacy path. A missing new guarantee does not make the seller’s established creation API unusable. On the seller side, the frameworks keep registered legacy handlers available; implementing compact handlers alone does not generate every legacy behavior. Retain the established handlers when serving older buyers and choose an unversioned default appropriate to those integrations. See the SDK lifecycle compatibility audit for the nine buyer–seller combinations, exact audited releases, current gaps, and reproducible probes. TypeScript’s existing compatibility guide documents coordinator options, continuation storage, and supported projections.

JavaScript / TypeScript

npm install @adcp/sdk@14.0.0-rc.33

import { createSingleAgentClient } from '@adcp/sdk';

const client = createSingleAgentClient({
  id: 'sales',
  name: 'Sales agent',
  agent_uri: 'https://sales.example.com/mcp',
  protocol: 'mcp',
});

const products = await client.listProducts({
  adcp_version: '3.2-rc.1',
  account: { account_id: 'account_123' },
  criteria: {
    offer_filters: { channels: ['ctv'] },
  },
});

Resources:

Package exports:

@adcp/sdk — main entry: caller (createSingleAgentClient, ADCPMultiAgentClient) and shared types
@adcp/sdk/server — agent-side server primitives (createAdcpServerFromPlatform, decisioning-platform interfaces); the lower-level createAdcpServer export is retained under @adcp/sdk/server/legacy/v5
@adcp/sdk/signing — RFC 9421 signing primitives
@adcp/sdk/signing/server — webhook + request verifiers (createWebhookVerifier, verifyRequestSignature, createExpressVerifier)
@adcp/sdk/signing/client — outbound signing (signRequest, signWebhook, createSigningFetch)
@adcp/sdk/testing — buyer-side storyboard runner (runStoryboard, comply, testAgent) and seller-side controller scaffold (createComplyController — see Get Test-Ready)
@adcp/sdk/conformance — assertion + storyboard helpers for conformance harnesses
@adcp/sdk/schemas — bundled AdCP JSON Schemas
@adcp/sdk/types — TypeScript type definitions

Maintaining older integrations

SDK 14 keeps the established 3.0/3.1 tools and compatibility adapters for mixed-version deployments. It also retains @adcp/sdk/server/legacy/v5 and @adcp/sdk/types/v2-5 for applications actively migrating older code. New 3.2 integrations should use the main server and per-tool type exports.

Python

pip install adcp==8.0.0b14

from adcp import ADCPClient, AgentConfig, Protocol, GetProductsRequest

client = ADCPClient(AgentConfig(
    id='sales',
    agent_uri='https://sales.example.com/mcp',
    protocol=Protocol.MCP,
))

result = await client.get_products(
    GetProductsRequest(
        idempotency_key='550e8400-e29b-41d4-a716-446655442045',
        buying_mode='brief',
        brief='Video campaign for pet owners',
    ),
)

Resources:

Go

go get github.com/adcontextprotocol/adcp-go/adcp/v3@v3.2.1

The Go SDK’s adcp/v3 module provides RC.1 generated schemas and types, typed tool registration, response builders, signing, a compliance test controller, and transport/server building blocks. Higher-layer coverage remains role-dependent. The /v3 suffix is required by Go semantic import versioning.

Component	Import
Tool registration	`adcp.AddTool(server, name, desc, handler)`
HTTP server	`adcp.Serve(createAgent)`
Response builders	`adcp.ProductsResponse(data)`, `adcp.MediaBuyResponse(data)`, etc.
Test controller	`adcp.RegisterTestController(server, store)`
Skills	github.com/adcontextprotocol/adcp-go/skills

See the Go SDK README for the full API reference. Resources:

GitHub Repository

CLI tools

The JavaScript and Python SDKs include command-line tools for testing and development. Both SDKs share the same positional shape: adcp <agent> [tool] [payload]. The first positional is an alias, a built-in (test-mcp, test-a2a), or a URL — protocol is auto-detected. Save aliases with --save-auth to avoid retyping.

JavaScript CLI

npx @adcp/sdk@14.0.0-rc.33 --help
npx @adcp/sdk@14.0.0-rc.33 --save-auth my-agent https://sales.example.com/mcp
npx @adcp/sdk@14.0.0-rc.33 my-agent list_products '{"adcp_version":"3.2-rc.1","account":{"account_id":"account_123"}}'
# or against the built-in public test agent:
npx @adcp/sdk@14.0.0-rc.33 test-mcp list_products '{"adcp_version":"3.2-rc.1"}'

The CLI also drives storyboards (adcp storyboard run), conformance grading (adcp grade), and registry diagnostics. See --help for the full surface.

Python CLI

uvx --from adcp==8.0.0b14 adcp --help
uvx --from adcp==8.0.0b14 adcp --save-auth my-agent https://sales.example.com/mcp
uvx --from adcp==8.0.0b14 adcp my-agent get_products '{"adcp_version":"3.2-rc.1","idempotency_key":"550e8400-e29b-41d4-a716-446655442064","buying_mode":"brief","brief":"CTV campaign"}'

What’s next

Build an agent — server-side L4 path. Skill files + coding agent.
Build a caller — client-side L4 path. Install, call, handle responses, ingest reporting.
Schemas — schema bundle, type generation, version pinning.
Migrate from hand-rolled — already running an AdCP agent built before the SDKs covered much? Swap one layer at a time.

Getting Started

Building with AdCP

Protocol

Using AAO

FAQ

Trust & Security

Reference

Certification

Choose your SDK

Coverage matrix

Media-buy compatibility across 3.x

JavaScript / TypeScript

Python

Go

CLI tools

JavaScript CLI

Python CLI

What’s next

​Coverage matrix

​Media-buy compatibility across 3.x

​JavaScript / TypeScript

​Python

​Go

​CLI tools

​JavaScript CLI

​Python CLI

​What’s next

Coverage matrix

Media-buy compatibility across 3.x

JavaScript / TypeScript

Python

Go

CLI tools

JavaScript CLI

Python CLI

What’s next