Skip to main content
Task: Discover signals based on description, with details about where they are deployed. Response Time: ~60 seconds (inference/RAG with back-end systems) Request Schema: https://adcontextprotocol.org/schemas/v2/signals/get-signals-request.json Response Schema: https://adcontextprotocol.org/schemas/v2/signals/get-signals-response.json The get_signals task returns both signal metadata and real-time deployment status across platforms, allowing agents to understand availability and guide the activation process.

Request Parameters

Deliver To Object

Destination Object

Each deployment target uses a type field to discriminate between platform-based and agent-based deployments: *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 deployment targets in the request, the signal agent will include activation_key fields in the response for those deployments (when is_live: true). Permission Model: The signal agent determines key inclusion based on the caller’s authentication and authorization. For example:
  • A sales agent receives keys for deployments matching its agent_url
  • A buyer with credentials for multiple DSP platforms receives keys for all those deployments
  • Access is determined by the signal agent’s permission system, not by flags in the request

Filters Object

Response Structure

All AdCP responses include:
  • message: Human-readable summary of the operation result
  • context_id: Session continuity identifier for follow-up requests
  • data: Task-specific payload (see Response Data below)
The response structure is identical across protocols, with only the transport wrapper differing:
  • MCP: Returns complete response as flat JSON
  • A2A: Returns as artifacts with message in text part, data in data part

Response Data

Field Descriptions

  • signals: Array of matching signals
    • signal_agent_segment_id: Unique identifier for the signal
    • name: Human-readable signal name
    • description: Detailed signal description
    • signal_type: Type of signal (marketplace, custom, owned)
    • data_provider: Name of the data provider
    • coverage_percentage: Percentage of audience coverage
    • deployments: Array of destination deployments
      • agent_url: URL identifying the destination agent
      • account: Account identifier if applicable
      • is_live: Whether signal is currently active on this deployment
      • activation_key: The key to use for targeting (see Activation Key below). Only present if is_live=true AND this deployment has requester=true in the request.
      • estimated_activation_duration_minutes: Time to activate if not live
    • pricing: Pricing information
      • cpm: Cost per thousand impressions
      • currency: Currency code

Activation Key Object

The activation key represents how to use the signal on a deployment target. It can be either a segment ID or a key-value pair: Segment ID format:
Key-Value format:

Protocol-Specific Examples

The AdCP payload is identical across protocols. Only the request/response wrapper differs.

MCP Request - Sales Agent Requesting Signals

A sales agent querying for signals. Because the authenticated caller is wonderstruck.salesagents.com, the signal agent will include activation keys in the response:

MCP Response - With Activation Key

Because the authenticated caller matches the deployment target, the response includes the activation key:

MCP Request - Buyer Querying Multiple DSP Platforms

A buyer checking availability across multiple DSP platforms:

MCP Response - Buyer With Multi-Platform Access

A buyer with credentials for both The Trade Desk and Amazon DSP receives keys for both platforms:

A2A Request

Natural Language Invocation

Explicit Skill Invocation

A2A Response

A2A returns results as artifacts with the same data structure:

Protocol Transport

  • MCP: Direct tool call with arguments, returns complete response as flat JSON
  • A2A: Skill invocation with input, returns structured artifacts with message and data separated
  • Data Consistency: Both protocols contain identical AdCP data structures and version information

Scenarios

All Platforms Discovery

Discover all available deployments across platforms:

Response

Message: “Found luxury automotive contextual segment from Peer39 with 15% coverage. Live on Index Exchange and OpenX, pending activation on Pubmatic.” Payload:

Response Fields

  • context_id (string): Context identifier for session persistence
  • signals (array): Array of matching signals
    • signal_agent_segment_id (string): Universal identifier for the signal
    • name (string): Human-readable signal name
    • description (string): Detailed signal description
    • signal_type (string): Type of signal (marketplace, custom, owned)
    • data_provider (string): Provider of the signal data
    • coverage_percentage (number): Estimated reach percentage
    • deployments (array): Platform-specific deployment information
      • platform (string): Target platform name
      • account (string, nullable): Specific account if account-specific
      • is_live (boolean): Whether signal is currently active
      • scope (string): “platform-wide” or “account-specific”
      • decisioning_platform_segment_id (string): Platform-specific ID to use
      • estimated_activation_duration_minutes (number, optional): Time to activate if not live
    • pricing (object): Pricing information
      • cpm (number): Cost per thousand impressions
      • currency (string): Currency code

Error Codes

Discovery Errors

  • SIGNAL_AGENT_SEGMENT_NOT_FOUND: Signal agent segment ID doesn’t exist
  • AGENT_NOT_FOUND: Private signal agent not visible to this principal
  • AGENT_ACCESS_DENIED: Principal not authorized for this signal agent

Discovery Warnings

  • PRICING_UNAVAILABLE: Pricing data temporarily unavailable for one or more platforms
  • PARTIAL_COVERAGE: Some requested platforms don’t support this signal type
  • STALE_DATA: Some signal metadata may be outdated due to provider refresh delays

Usage Notes

  1. Authentication-Based Keys: Activation keys are only returned when the authenticated caller matches one of the deployment targets
  2. Permission Security: The signal agent determines key inclusion based on caller identity, not request flags
  3. Deployment Status: Check is_live to determine if activation is needed
  4. Multiple Deployments: Query multiple deployment targets to check availability across platforms
  5. Activation Required: If is_live is false, use the activate_signal task
  6. The message field provides a quick summary of the most relevant findings

Response - Multiple Signals Found

Response - Partial Success with Warnings

Response - No Signals Found

Implementation Guide

Generating Signal Messages

The message field should provide actionable insights: