activate_signal
Task: Activate a signal for use on a specific platform/account. Response Time: Minutes to days (asynchronous with potential human-in-the-loop) Request Schema:https://adcontextprotocol.org/schemas/v1/signals/activate-signal-request.json
Response Schema: https://adcontextprotocol.org/schemas/v1/signals/activate-signal-response.json
The activate_signal task handles the entire activation lifecycle, including:
- Initiating the activation request
- Monitoring activation progress
- Returning the final deployment status
Request Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
signal_agent_segment_id | string | Yes | The universal identifier for the signal to activate |
destinations | Destination[] | Yes | Target destination(s) for activation (see Destination Object below) |
Destination Object
Each destination uses atype field to discriminate between platform-based and agent-based destinations:
| Parameter | Type | Required | Description |
|---|---|---|---|
type | string | Yes | Discriminator: “platform” for DSPs, “agent” for sales agents |
platform | string | Conditional* | Platform identifier (e.g., ‘the-trade-desk’, ‘amazon-dsp’). Required when type=“platform” |
agent_url | string (URI) | Conditional* | URL identifying the sales agent. Required when type=“agent” |
account | string | No | Account identifier on the platform or agent |
platform is required when type="platform", agent_url is required when type="agent".
Activation Keys: If the authenticated caller has access to any of the destinations in the request, the signal agent will include activation_key in the response for those destinations.
Permission Model: The signal agent determines key inclusion based on the caller’s authentication and authorization. For example:
- A sales agent receives keys for destinations matching its
agent_url - A buyer with credentials for multiple DSP platforms receives keys for all those platforms
- Access is determined by the signal agent’s permission system, not by flags in the request
Response Structure
All AdCP responses include:- message: Human-readable summary of the activation status
- context_id: Session continuity identifier for tracking progress
- data: Task-specific payload (see Response Data below)
- MCP: Returns complete response as flat JSON
- A2A: Returns as artifacts with message in text part, data in data part
- Status tracking: Check completion status via task_id
- Progress updates: Real-time updates on activation progress
Response Data
Field Descriptions
- deployments: Array of deployment results for each destination
- platform: Platform identifier for DSPs (either platform or agent_url will be present)
- agent_url: URL identifying the destination agent (either platform or agent_url will be present)
- account: Account identifier if applicable
- activation_key: The key to use for targeting (see Activation Key below). Only present if the authenticated caller has access to this destination.
- estimated_activation_duration_minutes: Estimated completion time for async operations
- deployed_at: ISO 8601 timestamp when activation completed
- errors: Optional array of errors and warnings encountered during activation
- code: Standardized error code for programmatic handling
- message: Human-readable error description with context
- field: Field path associated with the error (optional)
- suggestion: Suggested fix for the error (optional)
- details: Additional activation-specific error details (optional)
Activation Key Object
The activation key represents how to use the signal on a destination platform. It can be either a segment ID or a key-value pair: Segment ID format (typical for DSP platforms):Protocol-Specific Examples
The AdCP payload is identical across protocols. Only the request/response wrapper differs.MCP Request - Sales Agent Activation
MCP Response - Synchronous (Key-Value)
Immediate response with activation key:MCP Request - DSP Platform Activation
MCP Response - Asynchronous (Segment ID)
Initial response:A2A Request
Natural Language Invocation
Explicit Skill Invocation
A2A Response (with streaming)
Initial response:Protocol Transport
- MCP: Returns task_id for polling-based asynchronous operation tracking or webhook-based push notifications
- A2A: Uses Server-Sent Events for real-time progress updates and completion
- Data Consistency: Both protocols contain identical AdCP data structures and version information
Webhook Support
For long-running activations (when initial response issubmitted), configure a webhook to receive the complete response when activation completes:
activate_signal response:
Scenarios
Async Activation - Initial Response (Pending)
Message: “I’ve initiated activation of ‘Luxury Automotive Context’ on PubMatic for account brand-456-pm. This typically takes about 60 minutes. I’ll monitor the progress and notify you when it’s ready to use.” Complete Response:Async Activation - Final Response (Deployed)
Message: “Excellent! The ‘Luxury Automotive Context’ signal is now live on PubMatic. You can start using it immediately with the activation key provided. The activation completed faster than expected - just 52 minutes.” Complete Response:Sync Activation - Sales Agent (Immediate)
Message: “Signal successfully activated on Wonderstruck sales agent. Use the key-value pair in your targeting configuration.” Complete Response:Success with Warnings
Message: “Successfully activated ‘Luxury Automotive Context’ on PubMatic, but noted some configuration issues. The signal is live and ready to use, though performance may be sub-optimal until the account settings are updated.” Complete Response:Error Response (Failed)
Message: “I couldn’t activate the signal on PubMatic. Your account ‘brand-456-pm’ doesn’t have permission to use Peer39 data. Please contact your PubMatic account manager to enable Peer39 access, then we can try again.” Complete Response:Error Codes
Activation Errors
SIGNAL_AGENT_SEGMENT_NOT_FOUND: Signal agent segment ID doesn’t existACTIVATION_FAILED: Could not activate signal for unspecified reasonsALREADY_ACTIVATED: Signal already active on the specified platform/accountDEPLOYMENT_UNAUTHORIZED: Can’t deploy to platform/account due to permissionsINVALID_PRICING_MODEL: Requested pricing model not available for this signal
Configuration Warnings
SUBOPTIMAL_CONFIGURATION: Signal activated but account settings may impact performanceSLOW_ACTIVATION: Activation taking longer than expected but still in progressFREQUENCY_CAP_RESTRICTIVE: Signal activated but account frequency caps may reduce performance
Error Handling Philosophy
Status vs Errors
- Task Status: Indicates overall activation outcome (
deployed,failed, etc.) - Errors Array: Contains specific issues, warnings, and remediation steps
- Partial Success: Signal can be
deployedwhile still having warnings inerrorsarray
Error Types
- Fatal Errors: Prevent activation (status =
failed) - Warnings: Signal activates successfully but with caveats (status =
deployed+ errors) - Configuration Issues: Non-blocking problems that affect performance
Usage Notes
- Account-Specific: Include the
accountparameter for account-specific activations - Platform-Wide: Omit the
accountparameter for platform-wide activations - Async Operation: This is a long-running task that provides status updates
- Monitoring: Use task ID to monitor progress via polling or SSE
- Idempotent: Safe to retry if activation fails
Implementation Guide
Generating Activation Messages
Themessage field should provide clear status updates and actionable information: