Signals Specification

Documentation Index

Fetch the complete documentation index at: https://docs.adcontextprotocol.org/llms.txt

Use this file to discover all available pages before exploring further.

​

Abstract

​

Protocol Overview

• Natural language signal discovery based on marketing objectives
• Multi-platform signal discovery in a single request
• Signal activation for specific platforms and accounts
• Transparent pricing with CPM and revenue share models
• Signal size reporting with unit types (individuals, devices, households)

​

Transport Requirements

{
  "$schema": "https://adcontextprotocol.org/schemas/3.1.0-rc.4/protocol/get-adcp-capabilities-response.json",
  "status": "completed",
  "adcp": {
    "major_versions": [2],
    "idempotency": { "supported": true, "replay_ttl_seconds": 86400 }
  },
  "supported_protocols": ["signals"]
}

​

Core Concepts

​

Request Roles

• Orchestrator: The platform making the API request (e.g., a buyer agent or AI assistant)
• Account: The commercial relationship on whose behalf the request is made. See Accounts Protocol.

​

Signal Agent Types

• Signal agents MUST return REFERENCE_NOT_FOUND for unauthorized accounts — the same response as “agent does not exist.” Distinguishing “exists but unauthorized” from “does not exist” would enable cross-tenant enumeration of private agents. See the uniform-response MUST in error-handling.mdx for the full set of observable channels that MUST match on both paths.
• Signal agents MUST NOT expose private signals across accounts

• Signal agents MUST support public wholesale feed access without account registration
• Signal agents SHOULD support account-personalized wholesale feed views for registered accounts

​

Identifiers

• signal_agent_segment_id: Opaque signal handle issued by the signal source. Signals Protocol responses MUST return this for each signal and orchestrators MUST use it in activate_signal requests. For seller-offered media-buy signal targeting, buyers use signal_ref as the named signal reference and include signal_agent_segment_id only when the selected product option exposes a distinct execution handle.
• activation_key: Key for external deployment targeting. Signal agents MUST return this when is_live: true AND the caller has access to the deployment. Orchestrators MUST use this for platform or destination targeting (not signal_agent_segment_id). For seller-offered signals selected on a sales-agent media buy, use packages[].targeting_overlay.signal_targeting_groups; include activation_key only when the seller requires a prior activation key.

​

Governance metadata

• restricted_attributes: Array of GDPR Article 9 special category values this signal touches. Governance agents SHOULD prefer declared attributes over semantic inference.
• policy_categories: Array of policy category IDs this signal is sensitive for. Governance agents match these against a plan’s policy_categories to flag sensitive data usage.

​

Enrichment and progressive disclosure

​

Definition enrichment fields

• Taxonomy metadata: taxonomy.ref, taxonomy.values[], taxonomy.value_mappings[], and taxonomy.parent_match_behavior describe how the signal maps to an external or provider-owned taxonomy. These fields do not change package targeting grammar.
• Source and methodology disclosure: data_sources, methodology, segmentation_criteria, criteria_url, refresh_cadence, lookback_window, and onboarder describe how the segment was compiled. Offline and public-record source categories require onboarder.
• Modeling disclosure: modeling is required when methodology is modeled or audience_expansion is true. Required modeling disclosures must name the jurisdictions where the disclosure applies.
• Jurisdiction and privacy metadata: countries, GDPR-scoped consent_basis, restricted_attributes, policy_categories, and art9_basis let governance agents evaluate use constraints structurally. Federating agents that surface a peer’s signal MUST treat the peer’s countries[] as an upper bound, re-check it against the buyer’s intended deployment countries, and only apply narrower local policy.
• Data-subject-rights routing: data_subject_rights.channels[] declares where access, erasure, objection, portability, or rectification requests route for this signal. At least one channel must support one or more of access, erasure, or objection. response_sla_days is signal-scoped because custom/private signals and upstream-specific routes may not share a public provider-wide policy surface. Global Privacy Control support is not declared on signal definitions, and consumers MUST NOT infer GPC handling from data_subject_rights.

​

Runtime validation notes

• value_type: "categorical" with taxonomy requires taxonomy.value_mappings.
• audience_scope: "single_domain" requires originating_domain.
• methodology: "modeled" or audience_expansion: true requires modeling.
• Offline or public-record data_sources[] require onboarder.
• data_subject_rights.channels[] must include at least one channel supporting one or more of access, erasure, or objection.

​

Tasks

​

get_signals

• Orchestrators MUST include signal_spec, signal_refs, or deprecated signal_ids
• Signal agents MUST return all required fields per response schema
• Signal agents MUST include activation_key when is_live: true AND caller has deployment access

​

activate_signal

• Orchestrators MUST include signal_agent_segment_id and destinations
• On success, signal agents MUST return a deployments array with is_live for each deployment
• Signal agents MUST return activation_key when is_live: true AND caller has deployment access
• On failure, signal agents MUST return an errors array (with no deployments array)

​

Error Handling

​

Security Considerations

​

Transport Security

​

Authentication

• Orchestrators MUST authenticate with signal agents using valid credentials
• Signal agents MUST validate credentials before processing requests
• Signal agents SHOULD use account context to determine catalog access level

​

Activation Key Security

• Signal agents MUST only return activation_key to authenticated callers with deployment access
• Signal agents MUST NOT return activation keys for deployments the caller cannot access

​

Data Minimization

• Signal agents MUST NOT return signals the authenticated agent or account is not authorized to access

​

Conformance

​

Signal Agent Conformance

1. Support at least one specified transport (MCP or A2A)
2. Implement get_signals per schema
3. Return required fields as defined in response schemas
4. Use specified error codes
5. Enforce access control for private signals and, when activation is supported, activation keys

​

Orchestrator Conformance

1. Authenticate with signal agents
2. Include required fields as defined in request schemas
3. Handle async activation responses when using activate_signal
4. Use activation_key for external deployment targeting when activation is in scope, and use package-level signal_targeting_groups for seller-offered signal selection on sales-agent media buys

​

Implementation Notes

​

Multi-Platform Discovery

​

Activation Timing

• Simple activations: 1-2 hours
• Complex deployments: up to 24-48 hours

​

Destination Type Selection

• Orchestrators buying through a Sales Agent SHOULD use type: "agent" destinations with the SA’s URL. The SA handles downstream platform coordination — which DSP it uses is an implementation detail.
• Orchestrators buying directly on a DSP SHOULD use type: "platform" destinations. The orchestrator is responsible for ensuring the activation platform matches where campaigns will run.
• Signal marketplace agents MUST support both destination types per the destination schema.

​

Schema Reference