Skip to main content
Model Context Protocol を使って AdCP を統合するためのトランスポート別ガイドです。タスク処理、ステータス管理、ワークフローパターンは Task Lifecycle を参照してください。

MCP 経由で AdCP をテスト

CLI ツール を使うか、AgenticAdvertising.org のアシスタント Addie とチャットして AdCP タスクをテストできます。

ツールコールパターン

基本のツール呼び出し

フィルター付きツール呼び出し

アプリケーションレベルのコンテキスト付き呼び出し

MCP レスポンス形式

規範的: AdCP MCP レスポンスはフラット構造を使用します — エンベロープフィールド(statuscontext_idcontexttask_idtimestampreplayedadcp_errorgovernance_context)とタスクボディフィールドが、ツールレスポンスのルートに兄弟として現れます。core/protocol-envelope.json で定義される payload オブジェクトは文書上のグルーピング構造であり、シリアライズされるワイヤーキーではありません: ボディフィールドは MCP 上で payload: キーの下にネストされません。これは MCP のネイティブな structuredContent の慣習に一致します。
プロデューサールール。 MCP ツール実装は、エンベロープフィールドとボディフィールドをルートにフラットな兄弟として発行しなければなりません(MUST)。ボディフィールドを payload: キーの下にネストするのは非コンフォーマントです — レシーバーはフラットなルートから解析し、ネストされた表現はすべての出荷済み SDK を壊します。 レシーバールール。 MCP ツールコンシューマーは、ツールレスポンスのフラットなルートからエンベロープとボディのフィールドを解析しなければなりません(MUST)。レシーバーはネストされた payload: キーを要求してはなりません(MUST NOT)。スキーマの payload はドキュメントであり、ワイヤー要件ではありません。レスポンスに status が不在の場合(レガシーまたはトランスポートネイティブの状態キャリア)、レシーバーは非エラーレスポンスについて completed をデフォルトとし、エラーエンベロープについては adcp_error を検査しなければなりません(MUST)。 context_id vs context — 意味的に直交。
  • context_id は、複数のツール呼び出しにわたって関連オペレーションを追跡するためのサーバー管理のセッション識別子です。サーバーがそれを発行し、呼び出し元はセッションをつなぐため後続の呼び出しでエコーしてもよい(MAY)。MCP のトランスポートレベルセッションとは別物です。
  • context は、呼び出し元が供給する不透明なエコーオブジェクトcore/context.json)です — エージェントは解析せずにバイト単位で保持します。バイヤー側の相関(UI セッション ID、トレース ID、カスタムメタデータ)に使われます。
  • 両方が同じレスポンスに現れてもよい(MAY)。これらはエイリアスではありません
ステータス処理: 完全なステータス処理パターンは Task Lifecycle を参照してください。

利用可能なツール

すべての AdCP タスクは MCP ツールとして利用できます:

プロトコルツール

Media Buy ツール

Signals ツール

タスクパラメータ: Media Buy および Signals セクションの各タスクドキュメントを参照。

トランスポートラッパーとしての MCP Tasks

AdCP のタスクライフサイクル状態はアプリケーション層の状態です。MCP Tasks は tools/call リクエストをラップして、LLM ではなく MCP クライアントが CallToolResult を待てるようにします。これらは AdCP の task_id、ステータスペイロード、Webhook、ポーリング/リコンシリエーション面を置き換えません。 タスク拡張された MCP 呼び出しは、status がまだ submitted である AdCP ペイロードを配信した後に正常に完了できます。その時点から、メディアバイ、クリエイティブ、シグナル、またはガバナンスのワークフローは AdCP 層で開いたままであり、Webhook または AdCP ポーリングで観測すべきです。 :::warning クライアントサポートは限定的 ほとんどのチャットベース MCP クライアント(Claude Desktop、Cursor)はまだ MCP Tasks をサポートしていません。クライアントがタスク拡張ツール呼び出しをサポートしない場合、代わりに標準の tools/callWebhook または AdCP ポーリングを加えて使用してください — これらは任意の MCP クライアントで動作します。トランスポート非依存のパターンは Async OperationsPush Notifications を参照してください。 MCP Tasks は、MCP クライアントを自分で制御する場合(例: @modelcontextprotocol/sdk で独自のオーケストレーターを構築)に、初回の tools/call 結果のプロトコルレベルの待機が欲しいときに有用です。これらは任意のトランスポート配管であり、正準の AdCP タスクストアではありません。 :::

SDK 実装

@modelcontextprotocol/sdk パッケージを使う場合、MCP Tasks のサポートは最小限のコードで済みます。InMemoryTaskStore(または独自の TaskStore 実装)を Server コンストラクターに渡します — SDK が tasks/gettasks/resulttasks/listtasks/cancel のハンドラーを自動登録します:
tools/call ハンドラーで、task フィールドを確認してストアを使います:
SDK はポーリング、キャンセル、TTL クリーンアップ、tasks/result レスポンスの _meta 注入を処理します。InMemoryTaskStore は非永続です — 本番では、データベースでバックアップされた TaskStore を実装してください。 Server の代わりに McpServer を使う場合、server.experimental.tasks.registerToolTask() でタスク対応ツールを登録します — 高レベル API は taskSupport を宣言するツールについてこれを強制します。 :::warning 本番のタスク分離 InMemoryTaskStore はタスクをセッションでスコープしません — タスク ID を知る任意のクライアントがそれを読み取り、キャンセル、リストできます。本番では、すべてのオペレーションで sessionId によりフィルタリングする TaskStore を実装してください。また、クライアント提供の TTL 値をサーバー側でクランプし、タスク作成にレート制限を強制してください。 :::

サーバーケイパビリティ

AdCP MCP サーバーはケイパビリティで tasks を宣言します:

ツールレベルのタスクサポート

各ツールは、execution.taskSupport を通じてタスク拡張実行をサポートするかどうかを宣言します: taskSupport: "optional" のツールはどちらの方法でも呼び出せます:
  • task フィールドなし: 同期 — 結果を直接返す
  • task フィールドあり: 即座に CreateTaskResult を返す。トランスポートネイティブの tasks/get で MCP タスクをポーリングし、トランスポートネイティブの tasks/resultCallToolResult を取得し、その結果内の AdCP ペイロードを検査する。

ツールをタスクとして呼び出す

tools/call リクエストに task フィールドを含めます:
サーバーは即座にタスクハンドルを返します:
クライアントは、タスクが終端状態(completedfailedcancelled)に達するまで tasks/get で MCP トランスポートタスクをポーリングし(pollInterval を尊重)、その後 tasks/resultCallToolResult を取得します。トランスポートタスクを中止するには、MCP taskId を付けて tasks/cancel を送ります。 CallToolResult を取得した後、AdCP レスポンスペイロードを検査します。それが status: "submitted" と AdCP task_id を含む場合、トランスポートタスクはキューイングされた AdCP レスポンスを配信しましたが、アプリケーションワークフローはまだ開いています。Webhook または AdCP ポーリング(get_task_status、または 3.x のレガシー tasks/get)で続行します。

MCP タスクステータス vs. AdCP ステータス

AdCP は MCP Tasks より豊富なステータスセットを使用します。実装が AdCP の進捗をトランスポートネイティブの MCP タスクにミラーする場合、このマッピングは MCP ラッパーにのみ使用してください。AdCP ペイロードがドメインワークフロー状態の真実の源のままです:

長寿命オペレーションのための Webhook

MCP Tasks は MCP セッション内での待機を処理しますが、多くの AdCP オペレーションは単一のセッションより長く続きます(例: パブリッシャー承認に 24 時間かかるメディアバイ)。これらについては、AdCP 呼び出しに push_notification_config を登録します:
MCP タスクはセッション内のトランスポートラッパーを追跡します。Webhook は AdCP アプリケーションタスクを独立して追跡し、MCP セッション終了後も有効なままです。Webhook のペイロード形式と認証は Push Notifications を参照してください。

コンテキスト管理(MCP 固有)

重要: MCP はコンテキストを手動管理する必要があります。会話状態を保つには context_id を渡してください。

コンテキストセッションパターン

使用例

基本的なコンテキスト付きセッション

MCP Tasks を用いた非同期処理

taskSupport: "optional" のツールでは、task オプションを渡して MCP Tasks を使います:
Webhook POST format:
Note: レシーバーは、Webhook URL を解析するのではなく、ペイロードボディの operation_id(および task_type)を使って Webhook を相関しなければなりません(MUST)。バイヤーは自身のサーバー側ルーティングの便宜のため operation_id を URL パスやクエリに埋め込んでもよい(MAY、URL 構造はセラーにとって不透明で完全にバイヤー定義)が、セラーはその URL を決して解析しません — セラーは登録時に渡されたバイヤー供給の operation_id をエコーし、相関のワイヤーレベルの真実の源はペイロードフィールドです。mcp-webhook-payload.jsonWebhooks — Operation IDs を参照してください。 result フィールドには AdCP のデータペイロードが入ります。completed/failed ではタスクレスポンス全体(例: create-media-buy-response.json)、それ以外のステータスではステータス別スキーマ(例: create-media-buy-async-response-working.json)を使用します。

MCP Webhook のエンベロープフィールド

mcp-webhook-payload.json には以下が含まれます: 必須フィールド:
  • idempotency_key — 発火ごとのトランスポート重複排除キー(完全なセマンティクスはスキーマを参照)
  • operation_id — バイヤー供給の相関識別子で、セラーがそのままエコーする。レシーバーは URL パスではなくこれを使って通知を発信元タスクにルーティングする。セラーは URL を解析してこれを導出してはならない(MUST NOT)。URL 構造はセラーの視点からは実装依存である。
  • task_id — 相関用の一意なタスク ID
  • task_type — タスクごとのハンドラーにルーティングするためのタスク名(例: create_media_buy, sync_creatives
  • status — 現在のタスクステータス(completed, failed, working, input-required など)
  • timestamp — Webhook 生成時の ISO 8601 タイムスタンプ
任意フィールド:
  • notification_id — 再発行追跡のためのイベント層の安定 ID(スキーマを参照)
  • protocol — AdCP プロトコルファミリー(media-buy または signals
  • context_id — 会話/セッション ID
  • message — ステータス変更に関する人間向けコンテキスト
Data フィールド:
  • result — タスク固有の AdCP ペイロード(下記のデータスキーマ検証を参照)

Webhook が送信される条件

Webhook は次の すべて を満たす場合に送信されます:
  1. タスクが非同期をサポート(例: create_media_buy, sync_creatives, get_products
  2. リクエストに pushNotificationConfig が指定 されています
  3. タスクが非同期実行 — 初回レスポンスが working または submitted
初回レスポンスがすでに終端(completed, failed, rejected)なら、結果が手元にあるため Webhook は送信されません。 Webhook を送るステータス変化:
  • working → 進捗更新(処理中)
  • input-required → 人による入力が必要
  • completed → 最終結果
  • failed → エラー詳細

データスキーマの検証

MCP Webhook の result フィールドはステータス別スキーマを使用します: スキーマ参照: async-response-data.json

Webhook Handler Example

タスク管理とポーリング

コンテキスト期限切れの扱い

主な違い: コンテキストを自動管理する A2A と異なり、MCP は context_id を明示的に扱う必要があります。

非同期処理の扱い

AdCP レスポンスが working または submitted を返す場合、結果を受け取る方法が必要です。これは MCP クライアントが MCP Tasks をサポートするかどうかに関わらず適用されます — 以下のパターンは任意のクライアントで動作します。

オプション 1: Webhook(推奨)

Webhook URL を設定すると、オペレーション完了時にサーバーが結果を POST します。これは外部依存(パブリッシャー承認、人間のレビュー)でブロックされる submitted オペレーションに適したアプローチです。
ペイロード形式と認証は Push Notifications を参照してください。

オプション 2: ポーリング(バックアップ)

submitted オペレーションのバックアップとして、または Webhook エンドポイントを公開できない場合に AdCP ポーリングを使います。3.x では、セラーが宣伝する場合は get_task_status を優先し、そうでなければレガシー tasks/get を使います:

ステータス別の扱い

統合の例

MCP 固有の考慮点

サーバー側のツールラッパーはエンベロープフィールドを許容しなければならない

バイヤー SDK は、エンベロープレベルのフィールド(idempotency_keycontext_idcontextgovernance_contextpush_notification_config)を、それらを消費しない読み取り専用ツールを含め、すべての AdCP ツール呼び出しで一様に送信します。MCP ツール実装はこれらのフィールドを受け入れ、使わないものを無視しなければなりません(MUST)。エンベロープフィールドが存在するという理由で呼び出しを拒否してはなりません(MUST NOT)。よくある罠:
  • FastMCP / Pydantic の厳格なシグネチャidempotency_key: str | None = None(および他のエンベロープフィールド)を受け入れて無視するオプショナルとして宣言するか、**kwargs で未知のものを飲み込みます。入力モデルを制御できる場合は model_config = ConfigDict(extra='allow')
  • Zod / valibot の入力スキーマの .strict().strict() を外すか、passthrough バリアントを使います。
  • 入力モデルに additionalProperties: false を注入する OpenAPI codegen — ジェネレーター設定を修正します。スペックのリクエストスキーマは additionalProperties: true を宣言しています。
idempotency_key に対して unexpected_keyword_argument を送出するラッパーは、エンベロープ契約に従う任意のバイヤー SDK に対してコンプライアンスに失敗します。規範ルールは security.mdx > Server-side tool wrapper conformance を参照してください。

ツールディスカバリー

MCP サーバーカードによる AdCP 拡張

推奨: 実行時の機能発見には get_adcp_capabilities を使用してください。サーバーカード拡張はツールカタログやレジストリ向けの静的メタデータを提供します。
MCP サーバーは /.well-known/mcp.json(または /.well-known/server.json)のサーバーカードで AdCP 対応を宣言できます。AdCP 固有メタデータは adcontextprotocol.org 名前空間の _meta フィールドに記載します。
AdCP 対応の検出:
メリット:
  • テストコールなしで AdCP の対応状況を把握できます
  • 実装しているプロトコルドメイン(media_buy, creative, signals)を宣言できます
  • サポートする拡張を宣言できる(Context & Sessions 参照)
  • バージョンに基づく互換性チェックが可能
Note: _meta フィールドは MCP server.json spec に従い逆 DNS の名前空間を使用します。/.well-known/mcp.json/.well-known/server.json の両方をサポートしてください。

パラメータバリデーション

エラーハンドリング

AdCP エラーは isError: true のツールレベルレスポンスとして structuredContent.adcp_error にエラーが格納されて返されます。完全な抽出ロジックと JSON-RPC トランスポートコードは Transport Error Mapping を参照してください。

ベストプラクティス

  1. セッションラッパーを利用 してコンテキストを自動管理
  2. レスポンス処理前に status フィールド を確認
  3. コンテキスト期限切れ はリトライで丁寧に処理
  4. ステータス処理パターンは Core Concepts を参照
  5. 利用可能なら MCP ツールスキーマで パラメータ検証

次のステップ

ステータス処理、非同期オペレーション、確認フローについては Task Lifecycle を参照してください。このガイドは MCP トランスポート固有の内容に絞っています。