MCP 経由で AdCP をテスト
CLI ツール を使うか、AgenticAdvertising.org のアシスタント Addie とチャットして AdCP タスクをテストできます。ツールコールパターン
基本のツール呼び出し
フィルター付きツール呼び出し
アプリケーションレベルのコンテキスト付き呼び出し
MCP レスポンス形式
規範的: AdCP MCP レスポンスはフラット構造を使用します — エンベロープフィールド(status、context_id、context、task_id、timestamp、replayed、adcp_error、governance_context)とタスクボディフィールドが、ツールレスポンスのルートに兄弟として現れます。core/protocol-envelope.json で定義される payload オブジェクトは文書上のグルーピング構造であり、シリアライズされるワイヤーキーではありません: ボディフィールドは MCP 上で payload: キーの下にネストされません。これは MCP のネイティブな structuredContent の慣習に一致します。
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)。これらはエイリアスではありません。
利用可能なツール
すべての AdCP タスクは MCP ツールとして利用できます:プロトコルツール
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/call に Webhook または AdCP ポーリングを加えて使用してください — これらは任意の MCP クライアントで動作します。トランスポート非依存のパターンは Async Operations と Push Notifications を参照してください。
MCP Tasks は、MCP クライアントを自分で制御する場合(例: @modelcontextprotocol/sdk で独自のオーケストレーターを構築)に、初回の tools/call 結果のプロトコルレベルの待機が欲しいときに有用です。これらは任意のトランスポート配管であり、正準の AdCP タスクストアではありません。
:::
SDK 実装
@modelcontextprotocol/sdk パッケージを使う場合、MCP Tasks のサポートは最小限のコードで済みます。InMemoryTaskStore(または独自の TaskStore 実装)を Server コンストラクターに渡します — SDK が tasks/get、tasks/result、tasks/list、tasks/cancel のハンドラーを自動登録します:
tools/call ハンドラーで、task フィールドを確認してストアを使います:
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/resultでCallToolResultを取得し、その結果内の AdCP ペイロードを検査する。
ツールをタスクとして呼び出す
tools/call リクエストに task フィールドを含めます:
completed、failed、cancelled)に達するまで tasks/get で MCP トランスポートタスクをポーリングし(pollInterval を尊重)、その後 tasks/result で CallToolResult を取得します。トランスポートタスクを中止するには、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 固有)
重要: MCP はコンテキストを手動管理する必要があります。会話状態を保つにはcontext_id を渡してください。
コンテキストセッションパターン
使用例
基本的なコンテキスト付きセッション
MCP Tasks を用いた非同期処理
taskSupport: "optional" のツールでは、task オプションを渡して MCP Tasks を使います:
operation_id(および task_type)を使って Webhook を相関しなければなりません(MUST)。バイヤーは自身のサーバー側ルーティングの便宜のため operation_id を URL パスやクエリに埋め込んでもよい(MAY、URL 構造はセラーにとって不透明で完全にバイヤー定義)が、セラーはその URL を決して解析しません — セラーは登録時に渡されたバイヤー供給の operation_id をエコーし、相関のワイヤーレベルの真実の源はペイロードフィールドです。mcp-webhook-payload.json と Webhooks — 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— 相関用の一意なタスク IDtask_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— 会話/セッション IDmessage— ステータス変更に関する人間向けコンテキスト
result— タスク固有の AdCP ペイロード(下記のデータスキーマ検証を参照)
Webhook が送信される条件
Webhook は次の すべて を満たす場合に送信されます:- タスクが非同期をサポート(例:
create_media_buy,sync_creatives,get_products) - リクエストに
pushNotificationConfigが指定 されています - タスクが非同期実行 — 初回レスポンスが
workingまたはsubmitted
completed, failed, rejected)なら、結果が手元にあるため Webhook は送信されません。
Webhook を送るステータス変化:
working→ 進捗更新(処理中)input-required→ 人による入力が必要completed→ 最終結果failed→ エラー詳細
データスキーマの検証
MCP Webhook のresult フィールドはステータス別スキーマを使用します:
スキーマ参照:
async-response-data.json
Webhook Handler Example
タスク管理とポーリング
コンテキスト期限切れの扱い
context_id を明示的に扱う必要があります。
非同期処理の扱い
AdCP レスポンスがworking または submitted を返す場合、結果を受け取る方法が必要です。これは MCP クライアントが MCP Tasks をサポートするかどうかに関わらず適用されます — 以下のパターンは任意のクライアントで動作します。
オプション 1: Webhook(推奨)
Webhook URL を設定すると、オペレーション完了時にサーバーが結果を POST します。これは外部依存(パブリッシャー承認、人間のレビュー)でブロックされるsubmitted オペレーションに適したアプローチです。
オプション 2: ポーリング(バックアップ)
submitted オペレーションのバックアップとして、または Webhook エンドポイントを公開できない場合に AdCP ポーリングを使います。3.x では、セラーが宣伝する場合は get_task_status を優先し、そうでなければレガシー tasks/get を使います:
ステータス別の扱い
統合の例
MCP 固有の考慮点
サーバー側のツールラッパーはエンベロープフィールドを許容しなければならない
バイヤー SDK は、エンベロープレベルのフィールド(idempotency_key、context_id、context、governance_context、push_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 を使用してください。サーバーカード拡張はツールカタログやレジストリ向けの静的メタデータを提供します。/.well-known/mcp.json(または /.well-known/server.json)のサーバーカードで AdCP 対応を宣言できます。AdCP 固有メタデータは adcontextprotocol.org 名前空間の _meta フィールドに記載します。
- テストコールなしで AdCP の対応状況を把握できます
- 実装しているプロトコルドメイン(media_buy, creative, signals)を宣言できます
- サポートする拡張を宣言できる(Context & Sessions 参照)
- バージョンに基づく互換性チェックが可能
_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 を参照してください。
ベストプラクティス
- セッションラッパーを利用 してコンテキストを自動管理
- レスポンス処理前に status フィールド を確認
- コンテキスト期限切れ はリトライで丁寧に処理
- ステータス処理パターンは Core Concepts を参照
- 利用可能なら MCP ツールスキーマで パラメータ検証
次のステップ
- Core Concepts: ステータス処理とワークフローは Task Lifecycle を参照
- Task Reference: Media Buy Tasks と Signals
- Protocol Comparison: A2A integration と比較
- Examples: 完全なワークフロー例は Core Concepts に掲載