Skip to main content
tools/list is authoritative for the active account. Enrollment, account kind, permissions, feature rollout, and host support can narrow the catalog. This page explains the complete registered families and intended use.

Plan and billing

Legal acceptance and payout changes remain authorization-sensitive even though they are exposed through the shared contract. Follow the tool response and Page requirements; never pass bank details through free text.

Buyer tools

Buyer search and get kinds include the account’s advertisers, campaigns, creatives, creative collections, proposals, media buys, sellers, asks, and other kinds advertised by the live schema. Follow the Buyer workflows page for sequencing.

Seller tools

Seller search and get kinds include the Seller singleton, inventory sources, coverage, wholesale products, playbook, business rules, media buys, work items, signals, asks, and other kinds advertised by the live schema. Follow the Seller workflows page for sequencing.

MCP App and resource-bound tools

These tools support interactive Pages or resources. A compliant host may keep some of them out of model context and invoke them only through the associated app contract.

Core read examples

List objects:
Read one object with related detail:
Campaign proposals, recentActivity, deliverySummary, and sourceIdentity are accepted include names so the API can return a precise unavailableIncludes explanation, but they are not populated in the preview. Search documentation:
Read a selected documentation result by its returned document path:
Arbitrary web URLs and internal repository paths are not readable through the documentation search contract.

Read structured results

Every tool returns MCP content for a person or model to read. Integrations should make decisions from structuredContent. tools/list is authoritative for inputs and publishes an output schema where the current tool declares one; the patterns below cover the remaining preview tools. Do not parse IDs, revisions, actions, or recovery guidance out of rendered prose. A write may return action: "unchanged"; that is a successful idempotent outcome. On partial work, preserve partialWrite, warnings, errors, per-seller or per-source outcomes, and any returned current revision. request_proposals.status can be running when another caller is already using the same idempotency key; retry that same key until it becomes complete, partial, or failed. For example, a successful advertiser creation returns the new identity under the noun rather than as an unlabelled string:
request_proposals returns enough state to continue each seller branch:
These examples show the continuation fields, not every property. Treat the live output schema as authoritative as the preview evolves.

Errors and result handling

Tool errors use bounded structured codes and explanatory text. Common classes include validation errors, access denial, not found, revision conflict, unsupported preview behavior, external failure, and partial results.
  • Treat isError: true as a failed tool result even when the MCP transport itself returned successfully.
  • Preserve structured IDs and recovery fields; do not parse prose to recover an identifier already present in structuredContent.
  • A partial result is not an empty result. Read its warnings, coverage, and per-source or per-seller outcomes.
  • Re-read after any response that reports a partial write.
For transport-wide behavior, see Errors, Rate Limits, and Preview limitations.