> ## Documentation Index
> Fetch the complete documentation index at: https://docs.adcontextprotocol.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Schemas & SDKs

> Quick-start reference for AdCP schemas and client SDKs: installation, schema URLs, version discovery, and where to go next.

This page orients you to the two foundational resources for building with AdCP: the JSON schemas that define every request and response, and the SDKs that turn those schemas into typed code.

## SDKs

AdCP ships official SDKs for TypeScript, Python, and Go. Each SDK absorbs the protocol layers (wire format, signing, auth, lifecycle semantics) so you write business logic only.

<CardGroup cols={3}>
  <Card title="TypeScript" icon="js" href="https://www.npmjs.com/package/@adcp/sdk">
    `npm install @adcp/sdk`
  </Card>

  <Card title="Python" icon="python" href="https://pypi.org/project/adcp/">
    `pip install adcp`
  </Card>

  <Card title="Go" icon="golang" href="https://github.com/adcontextprotocol/adcp-go">
    `go get github.com/adcontextprotocol/adcp-go`
  </Card>
</CardGroup>

For the full coverage matrix (which layers each SDK ships today), version pinning guidance, and package export details, see [Choose your SDK](/dist/docs/3.2.0-beta.10/building/by-layer/L4/choose-your-sdk).

For the layered model behind the SDKs — what L0 through L4 each contain and why SDKs matter more in AdCP than in simpler protocols — see the [SDK stack reference](/dist/docs/3.2.0-beta.10/building/cross-cutting/sdk-stack).

## Schema URLs

AdCP schemas are published at `https://adcontextprotocol.org/schemas/` under the current major-version alias:

| Pattern           | Example                                                                                       | Use                                          |
| ----------------- | --------------------------------------------------------------------------------------------- | -------------------------------------------- |
| **Current major** | `https://adcontextprotocol.org/schemas/3.2.0-beta.10/media-buy/create-media-buy-request.json` | Pin validators to the AdCP 3.x schema family |

Schemas cover every task's request and response, shared enums, governance objects, creative formats, and signal definitions. Use the current major-version URL in production and CI so links stay stable across major releases.

For how wire-level `adcp_protocol_version` relates to schema bundle versions, and why those are different things, see [Versioning & governance](/dist/docs/3.2.0-beta.10/reference/versioning).

## Authorization in adagents.json

Publishers declare their agent endpoints and authorization scopes in `adagents.json`. The schema supports six authorization types — `property_ids`, `property_tags`, `inline_properties`, `publisher_properties`, `signal_ids`, and `signal_tags` — each scoping which inventory the agent is authorized to act on.

For the full authorization type reference and worked examples, see [Authorization Patterns](/dist/docs/3.2.0-beta.10/governance/property/adagents#authorization-patterns) in the governance docs.

## Validate an unreleased schema in both SDKs

Schema-changing pull requests build a deterministic protocol bundle and run both the TypeScript and Python generators against it. The check records three machine-readable values in `latest.tgz.provenance.json`: the protocol commit, the bundle SHA-256, and the published-version label. A passing SDK job therefore identifies the exact protocol input it consumed.

For same-repository pull requests, the workflow also publishes an immutable tuple keyed by the full head commit:

```text theme={null}
https://adcontextprotocol.org/protocol/pr/<commit-sha>/latest.tgz
https://adcontextprotocol.org/protocol/pr/<commit-sha>/latest.tgz.sha256
https://adcontextprotocol.org/protocol/pr/<commit-sha>/latest.tgz.provenance.json
```

These bundles are unsigned development artifacts. Verify the checksum and provenance before using one, and never use a PR bundle in production.

Preview bundles are retained for 90 days by default and removed by a daily cleanup job. Maintainers can change the window with the `SCHEMA_PR_BUNDLE_RETENTION_DAYS` repository variable. Rerun the protocol validation workflow to recreate an expired bundle for a still-current commit.

To reproduce the artifact locally after committing the protocol inputs, run:

```bash theme={null}
scripts/build-schema-pr-bundle.sh
```

The script derives both the source commit and deterministic timestamp from `HEAD`, refuses uncommitted bundle inputs, and writes the same three files under `dist/protocol/`.

When creating a dependent SDK pull request:

1. Copy the three artifact URLs from the protocol workflow summary.
2. Regenerate with the SDK repository's supported local-bundle input and commit its provenance metadata with the generated output.
3. Put the full protocol commit and bundle SHA-256 in the dependent pull request body.
4. After every protocol force-push or rebase, use the new head-SHA URL, regenerate, and confirm the old commit no longer appears in generated metadata or the pull request description.

The preview workflow is intentionally triggered only by changes under `static/schemas/source/**`. Once triggered, its TypeScript and Python jobs validate the complete bundle rather than only the changed schema files. Changes limited to compliance sources, the OpenAPI registry, or build tooling remain covered by their normal CI checks but do not publish a schema preview bundle.

## Where to go next

<CardGroup cols={2}>
  <Card title="Choose your SDK" icon="box" href="/dist/docs/3.2.0-beta.10/building/by-layer/L4/choose-your-sdk">
    Coverage matrix, install commands, and version pinning for each language.
  </Card>

  <Card title="Build an agent" icon="hammer" href="/dist/docs/3.2.0-beta.10/building/by-layer/L4/build-an-agent">
    Skill files and step-by-step guide for building a seller agent.
  </Card>

  <Card title="Build a caller" icon="phone" href="/dist/docs/3.2.0-beta.10/building/by-layer/L4/build-a-caller">
    Buyer-side reference for discovering capabilities and handling responses.
  </Card>

  <Card title="Validate your agent" icon="check" href="/dist/docs/3.2.0-beta.10/building/verification/validate-your-agent">
    Run the compliance suite to verify your implementation.
  </Card>
</CardGroup>