Trillboards DOOH Advertising
REMOTE · API.TRILLBOARDS.COM · SCANNED SEP 24
DOOH advertising via AI agents. 5,000+ screens with edge AI audience intelligence.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security63
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation not fully verified: no authorisation is required to call this server, and 83 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. See how to fix → View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability76
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 22172 tokens (~260/item across 85 items; 83 tools + 2 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage93
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 78% of tool parameters carry a description.Partial
Tool Safety75
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- 0 of 4 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "delete_device" implies "delete" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
- An AI judge read all 85 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the Trillboards DOOH Advertising MCP server?
Trillboards DOOH Advertising is a hosted endpoint at https://api.trillboards.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · api.trillboards.com
claude mcp add --transport http snehdhruv-trillboards-dooh 'https://api.trillboards.com/mcp'
{
"mcpServers": {
"snehdhruv-trillboards-dooh": {
"url": "https://api.trillboards.com/mcp"
}
}
} {
"servers": {
"snehdhruv-trillboards-dooh": {
"type": "http",
"url": "https://api.trillboards.com/mcp"
}
}
} [mcp_servers.snehdhruv-trillboards-dooh] url = "https://api.trillboards.com/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"snehdhruv-trillboards-dooh": {
"type": "remote",
"url": "https://api.trillboards.com/mcp",
"enabled": true
}
}
} openclaw mcp add snehdhruv-trillboards-dooh --url 'https://api.trillboards.com/mcp' --transport streamable-http
mcp_servers:
snehdhruv-trillboards-dooh:
url: "https://api.trillboards.com/mcp" {
"McpServers": {
"snehdhruv-trillboards-dooh": {
"Transport": "http",
"Url": "https://api.trillboards.com/mcp"
}
}
} assistant mcp add snehdhruv-trillboards-dooh -t streamable-http -u 'https://api.trillboards.com/mcp'
{
"mcpServers": {
"snehdhruv-trillboards-dooh": {
"type": "http",
"url": "https://api.trillboards.com/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 18 Sept 26 0
- A breaking change shipped without a version bump: still 1.0.0 ▼ security
- Tool “comply_test_controller” was removed ▼ security
- 15 Sept 26 0
- The server rewrote its instructions, which are the text every model session reads security
- 12 Sept 26 0
- Injection markers: unverified → pass ▲ security
- Stability: unverified → pass ▲ security
- Transport: fail → pass ▲ security
- HSTS header: fail → pass ▲ security
- Authorization: Authorisation not fully verified: no authorisation is required to call this server, and 84 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. security
- Endpoint reachability: unreachable → reachable ▲ functional
- Tool coverage: unverified → 100 ▲ functional
- Schema quality: unverified → 100 ▲ functional
- MCP protocol: unverified → pass ▲ functional
- 11 Sept 26 0
- Endpoint reachability: reachable → unreachable ▼ security
- Stability: pass → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Transport: pass → fail ▼ security
- HSTS header: pass → fail ▼ security
- Authorization: Authorisation not fully verified: no authorisation is required to connect, but we couldn't read the tool list to see what that exposes. security
- Schema quality: 100 → unverified ▼ functional
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- 2 Sept 26 0
- Tool “get_signals” rewrote its description, which is the text the model reads security
- New tool “comply_test_controller” functional
- “activate_signal” added an optional parameter “signal_agent_segment_id” cosmetic
- “get_signals” added an optional parameter “pagination” cosmetic
- “get_signals” reworded the description of “signal_spec” cosmetic
- 29 Aug 26 0
- Stability: 0.97 → pass security
- 28 Aug 26 0
- Stability: pass → 0.97 functional
- 26 Aug 26 79
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 24 Sept 2026 · Probed https://api.trillboards.com/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=trillboards.com | CN=YR1,O=Let's Encrypt,C=US | 13 Sept 2026 | 12 Dec 2026 | RSA 2048 | SHA256-RSA | 603beb61649777f99150d87a26019def768 |
| SANs: *.trillboards.com, trillboards.com | ||||||
| CN=YR1,O=Let's Encrypt,C=US (CA) | CN=Root YR,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | RSA 2048 | SHA256-RSA | a20253f15f2691c05dc1ce13b9bcca4e |
| CN=Root YR,O=ISRG,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | RSA 4096 | SHA256-RSA | f24b6d17f9d9ad7cb1c9fea78782699f |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of api.trillboards.com. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| trillboards.com. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=31536000; includeSubDomains |
| content-security-policy | default-src 'self';script-src 'self' 'unsafe-inline' https://screen.trillboards.com https://cdn.jsdelivr.net;style-src 'self' 'unsafe-inline' https://cdn.jsdelivr.net https://fonts.googleapis.com;img-src 'self' https://cdn.trillboards.com https://maps.googleapis.com data: blob:;connect-src 'self' https://api.trillboards.com wss://api.trillboards.com;font-src 'self' https://fonts.gstatic.com https://cdn.jsdelivr.net;frame-src 'self' https://js.stripe.com;object-src 'none';upgrade-insecure-requests;base-uri 'self';form-action 'self';frame-ancestors 'self';script-src-attr 'none' |
| x-content-type-options | nosniff |
| x-frame-options | SAMEORIGIN |
| referrer-policy | no-referrer |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://api.trillboards.com/mcp | Verified | 200 | |
| http (plaintext) | http://api.trillboards.com/mcp | HTTPS enforced | 301 | https://api.trillboards.com/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
activate_signal ~296
[AdCP Signals] Activate an audience signal for DSP targeting. Returns an activation_key token for referencing this signal activation. Free-form Trillboards signal labels remain custom parameters. IAB Audience Taxonomy 1.1 segments are emitted only when registered IDs are supplied explicitly. WHEN TO USE: - Converting audience signals into actionable targeting parameters - Activating already-curated, registered IAB segment IDs for programmatic requests - Creating reusable targeting configurations RETURNS: - activation_key: Token for referencing this activation (24h expiry) - targeting: { iab_segments, iab_taxonomy_version, custom_params } - screen_count, provider, data_source, methodology EXAMPLE: User: "Activate the registered $100k-$149k household-income segment on my screens" activate_signal({ signal_type: "audience", parameters: { iab_audience_segment_ids: ["68"] }, screen_ids: ["507f1f77bcf86cd799439011"] })
| Name | Type | Req | Description |
|---|---|---|---|
| destinations | array | – | Where to push activated segments |
| parameters | object | yes | Signal parameters to activate as targeting |
| screen_ids | array | – | Specific screens to activate on (optional, defaults to all partner screens) |
| signal_agent_segment_id | string | – | – |
| signal_type | string | yes | Type of signal to activate (e.g., "audience", "venue", "behavior") |
No output schema declared.
No examples provided.
anomaly_detect ~465
Detect anomalies in observation patterns. Alert when metrics deviate significantly from trailing averages. Computes trailing mean and standard deviation for a given metric from the observation_stream, then identifies observations that fall beyond the configured sigma threshold (z-score based anomaly detection). WHEN TO USE: - Monitoring for unusual audience patterns (sudden spikes or drops in face count) - Detecting equipment anomalies (confidence drops indicating sensor issues) - Identifying unusual commerce or vehicle patterns - Finding outlier moments that may indicate events, incidents, or opportunities RETURNS: - anomalies: Array of anomalous observations with: - observation_id, device_id, venue_type, observed_at - metric_value: The observed value - z_score: How many standard deviations from the mean - direction: 'above' or 'below' the mean - payload: Full observation payload for context - baseline: { mean, stddev, sample_count, lookback_hours } - suggested_next_queries: Follow-up queries to investigate anomalies EXAMPLE: User: "Are there any unusual audience patterns at retail venues?" anomaly_detect({ metric: "face_count", venue_type: "retail", lookback_hours: 24, threshold_sigma: 2.0 }) User: "Detect anomalies in vehicle counts at this screen" anomaly_detect({ metric: "vehicle_count", screen_id: "507f1f77bcf86cd799439011", lookback_hours: 48, threshold_sigma: 2.5 })
| Name | Type | Req | Description |
|---|---|---|---|
| lookback_hours | number | – | Hours of historical data to compute baseline from (default: 24, max: 168) |
| metric | string | yes | The metric to check for anomalies. Extracted from observation payload (e.g., face_count, vehicle_count, confidence, emotional_engagement, crowd_energy, noise_level) |
| screen_id | string | – | Filter to a specific screen (mongo ID). Optional. |
| threshold_sigma | number | – | Number of standard deviations to consider anomalous (default: 2.0, range: 1.0-5.0) |
| venue_type | string | – | Filter to a specific venue type. Optional. |
No output schema declared.
No examples provided.
batch_impressions ~202
Record multiple impressions in a single request (up to 100). WHEN TO USE: - Bulk reporting impressions from offline period - Efficient batch processing of impressions - When device was offline and needs to sync RETURNS: - success: Boolean indicating success - processed: Number of impressions processed - failed: Number of failed impressions - total_earnings: Total earnings credited - errors: Any error details for failed impressions EXAMPLE: User: "Sync the last hour of impressions" batch_impressions({ impressions: [ { fingerprint: "P_abc123", ad_id: "507f1f77bcf86cd799439011", duration_seconds: 15 }, { fingerprint: "P_abc123", ad_id: "507f1f77bcf86cd799439012", duration_seconds: 10 } ] })
| Name | Type | Req | Description |
|---|---|---|---|
| impressions | array | yes | Array of impression objects (max 100) |
No output schema declared.
No examples provided.
configure_sensing ~503
Configure what a screen should sense using natural language. Generates and optionally pushes a sensing profile to the device. Uses Gemini AI to interpret a natural language sensing intent and generate a sensing profile that maps to available on-device ML models (BlazeFace, AgeGender, FER+, MoveNet, YAMNet, WhisperTiny, EfficientDet, YOLOv8-nano). WHEN TO USE: - Setting up a new screen to sense specific things (faces, vehicles, emotions, etc.) - Changing what a screen detects based on venue type or business needs - Configuring custom sensing for special events or campaigns - Translating business intent into ML model configuration RETURNS: - data: The generated sensing profile with: - profile_name, profile_type, description - models: Array of ML model IDs to activate - classes: COCO classes to detect (for object detection models) - thresholds: Confidence and alert thresholds - observation_families: What types of observations will be produced - capture_interval_ms, report_interval_ms: Timing configuration - estimated_fps_impact: CPU cost estimate - data_fields_produced: All data fields the profile will generate - reasoning: Why these models/classes were chosen - deployment_status: 'generated' | 'pushed' | 'push_failed' - metadata: { screen_id, auto_deploy, profile_id } - suggested_next_queries: Follow-up actions EXAMPLE: User: "Set up the lobby screen to detect foot traffic and emotions" configure_sensing({ screen_id: "507f1f77bcf86cd799439011", intent: "Detect foot traffic patterns, count people, and measure emotional reactions to displayed content", auto_deploy: false }) User: "Configure this drive-through screen for vehicle counting" configure_sensing({ screen_id: "507f1f77bcf86cd799439011", intent: "Count vehicles in drive-through lane, detect vehicle types, measure queue length", auto_deploy: true })
| Name | Type | Req | Description |
|---|---|---|---|
| auto_deploy | boolean | – | If true, automatically push the profile to the device. If false (default), generate only for review. |
| intent | string | yes | Natural language description of what the screen should sense/detect/measure |
| screen_id | string | yes | Screen ID (mongo ID) to configure sensing for |
No output schema declared.
No examples provided.
create_campaign ~401
Create a new advertising campaign targeting DOOH screens. WHEN TO USE: - Setting up a new ad campaign on available screens - Targeting specific venues, locations, or audience profiles - Allocating budget for programmatic DOOH buys RETURNS: - campaign_id: Unique campaign identifier (UUID) - name, status, budget, screen_count, dates Campaign starts in "draft" status. Use update_campaign to set status to "active". EXAMPLE: User: "Create a campaign targeting retail screens in NYC at $5 CPM" create_campaign({ name: "NYC Retail Q1", budget_cpm: 5.0, daily_budget_usd: 100, venue_types: ["retail"], targeting: { geo: { city: "New York", state: "NY" } }, creative_url: "https://cdn.example.com/ad.mp4", start_date: "2026-03-01", end_date: "2026-03-31" })
| Name | Type | Req | Description |
|---|---|---|---|
| budget_cpm | number | – | Bid CPM in USD (default: 4.0) |
| creative_duration | integer | – | Duration in seconds (default: 15) |
| creative_type | string | – | Creative format |
| creative_url | string | – | URL to video/image creative asset |
| daily_budget_usd | number | – | Daily budget cap in USD |
| end_date | string | – | Campaign end date (ISO 8601) |
| name | string | yes | Campaign name |
| screen_ids | array | – | Specific screen IDs to target (optional, overrides venue/geo targeting) |
| start_date | string | – | Campaign start date (ISO 8601) |
| targeting | object | – | Additional targeting criteria |
| total_budget_usd | number | – | Total campaign budget in USD |
| venue_types | array | – | Venue types to target: transit, retail, outdoor, office, etc. |
No output schema declared.
No examples provided.
create_experiment ~371
Create an incrementality experiment for a campaign. Sets up a geo-holdout, ghost ads, or propensity score matching experiment to causally measure DOOH advertising lift. WHEN TO USE: - Setting up a new A/B test before or during a campaign - Defining treatment and control DMAs for geo-holdout tests - Configuring experiment parameters (holdout %, MDE, power) RETURNS: The created experiment object with experiment_id, status, and all parameters. EXAMPLE: create_experiment({ campaign_id: "camp_abc123", experiment_type: "geo_holdout", treatment_dmas: ["501", "504"], control_dmas: ["503", "505"], holdout_pct: 0.15, target_mde: 0.10 })
| Name | Type | Req | Description |
|---|---|---|---|
| campaign_id | string | yes | Campaign identifier |
| control_dmas | array | – | DMA codes for control group (no ads) |
| experiment_type | string | yes | Experiment type: geo_holdout (matched DMAs), ghost_ads (PSA control), psm (propensity score matching) |
| holdout_pct | number | – | Fraction of devices to hold out (0.05-0.50). Default: 0.10 |
| target_alpha | number | – | Significance level (0.05 or 0.01). Default: 0.05 |
| target_mde | number | – | Minimum detectable effect (relative, e.g. 0.10 = 10% lift). Default: 0.10 |
| target_power | number | – | Statistical power (0.80 or 0.90). Default: 0.80 |
| treatment_dmas | array | – | DMA codes for treatment group (get ads) |
No output schema declared.
No examples provided.
create_media_buy ~419
[AdCP Media Buy] Create a media buy (campaign) from an AdCP buy specification. Creates a campaign that targets DOOH screens based on the provided specification. Returns a media_buy_id for tracking and a creative_deadline for asset submission. WHEN TO USE: - Executing a programmatic DOOH buy via an AI agent - Creating campaigns from DSP trading desk agents - Automated media buying workflows RETURNS: - media_buy_id: Unique identifier for this media buy - campaign_id: Internal campaign identifier - creative_deadline: Deadline for creative asset submission - targeting_summary: What was targeted - budget_summary: Budget allocation details EXAMPLE: User: "Buy retail screens in NYC at $5 CPM for next week" create_media_buy({ name: "NYC Retail Week 12", buy_spec: { venue_types: ["retail"], geo: { city: "New York", state: "NY" }, budget: { daily_usd: 500, bid_cpm: 5.0 }, schedule: { start_date: "2026-03-16", end_date: "2026-03-22" } }, creative: { url: "https://cdn.example.com/creative.mp4", type: "video", duration_seconds: 15 }, buyer_ref: "agency-order-12345" })
| Name | Type | Req | Description |
|---|---|---|---|
| brand | object | – | Brand reference |
| buy_spec | object | – | Buy specification (legacy) |
| buyer_ref | string | – | External reference ID from the buyer/agency |
| context | object | – | – |
| creative | object | – | – |
| end_time | string | – | ISO 8601 end time |
| idempotency_key | string | – | – |
| name | string | – | Media buy name |
| packages | array | – | AdCP product packages to buy |
| start_time | string | – | ISO 8601 start time |
| total_budget | object | – | – |
No output schema declared.
No examples provided.
create_webhook ~330
Create a new webhook subscription for real-time events. WHEN TO USE: - Setting up real-time notifications for device events - Integrating with external systems - Monitoring ad playback and impressions AVAILABLE EVENTS: - device.online: When a device comes online - device.offline: When a device goes offline - impression.recorded: When an impression is logged - campaign.allocated: When a campaign is allocated to a device - payout.processed: When a payout is processed - programmatic.ad_started: When a programmatic ad begins playing - programmatic.ad_ended: When a programmatic ad finishes playing - programmatic.no_fill: When a programmatic ad request gets no fill - programmatic.error: When a programmatic ad request errors RETURNS: - webhook_id: Unique webhook identifier - url: The webhook endpoint URL - events: Subscribed events - secret: HMAC signing secret (if provided) - status: enabled/disabled EXAMPLE: User: "Set up a webhook for device status changes" create_webhook({ url: "https://api.mycompany.com/trillboards/webhooks", events: ["device.online", "device.offline", "programmatic.error"], secret: "my-signing-secret-123" })
| Name | Type | Req | Description |
|---|---|---|---|
| description | string | – | Human-readable description for this webhook |
| events | array | yes | Events to subscribe to |
| secret | string | – | HMAC signing secret for verifying webhook authenticity (optional but recommended) |
| url | string | yes | HTTPS endpoint URL to receive webhook events |
No output schema declared.
No examples provided.
cross_signal_correlate ~432
Discover correlations between different signal types. Example: relationship between ad fill rate and audience attention for QSR venues. Queries the cross_signal_insights table for pre-computed correlations, or computes ad-hoc correlations from the observation_stream when no pre-computed insight exists. WHEN TO USE: - Understanding relationships between different sensing signals - Finding which audience behaviors correlate with business outcomes - Discovering hidden patterns (e.g., crowd_energy vs purchase_intent) - Validating hypotheses about audience-venue-time relationships RETURNS: - data: Correlation analysis with: - signal_a, signal_b: The two signals being correlated - correlation_r: Pearson correlation coefficient (-1 to +1) - correlation_r2: R-squared (proportion of variance explained) - p_value: Statistical significance - sample_count: Number of data points used - effect_size: Cohen's d effect size - confidence_interval_lower, confidence_interval_upper: 95% CI bounds - insight_summary: Human-readable interpretation - metadata: { computation_method, window, filters_applied } - suggested_next_queries: Related correlation analyses to explore EXAMPLE: User: "Is there a correlation between audience attention and ad fill rate at QSR venues?" cross_signal_correlate({ signal_a: "attention_score", signal_b: "ad_fill_rate", filters: { venue_type: "restaurant_qsr" } }) User: "How does crowd energy relate to purchase intent during lunch hours?" cross_signal_correlate({ signal_a: "crowd_energy", signal_b: "purchase_intent", filters: { daypart: "lunch" } })
| Name | Type | Req | Description |
|---|---|---|---|
| filters | object | – | Optional filters to narrow the correlation analysis |
| signal_a | string | yes | First signal to correlate (e.g., face_count, attention_score, crowd_energy, emotional_engagement, vehicle_count, noise_level, purchase_intent, ad_fill_rate) |
| signal_b | string | yes | Second signal to correlate against signal_a |
No output schema declared.
No examples provided.
delete_device ~114
Soft-delete a device from the partner account. WHEN TO USE: - Removing a device that's been decommissioned - Cleaning up test devices - Removing a device that's been relocated to another partner RETURNS: - success: Boolean indicating success - device_id: The deleted device ID - message: Confirmation message EXAMPLE: User: "Remove the old lobby kiosk" delete_device({ device_id: "lobby-kiosk-old" })
| Name | Type | Req | Description |
|---|---|---|---|
| device_id | string | yes | Your internal device identifier to delete |
No output schema declared.
No examples provided.
delete_webhook ~123
Delete a webhook subscription. WHEN TO USE: - Removing a webhook that's no longer needed - Cleaning up old integrations - Removing test webhooks RETURNS: - success: Boolean indicating success - webhook_id: The deleted webhook ID - message: Confirmation message EXAMPLE: User: "Delete the old webhook" delete_webhook({ webhook_id: "wh_mmmpdbvj_8b7c5a59296d" })
| Name | Type | Req | Description |
|---|---|---|---|
| webhook_id | string | yes | Webhook ID to delete (wh_xxx format or legacy ObjectId) |
No output schema declared.
No examples provided.
describe_endpoint ~194
Describe a single API operation including its parameters, response shape, and error codes. WHEN TO USE: - Inspecting an endpoint's full contract before calling it. - Discovering which error codes an endpoint can return and how to recover. RETURNS: - operation: Full discovery record for the endpoint. - parameters: Raw OpenAPI parameter definitions. - request_body: Body schema (when applicable). - responses: Map of status code → description/schema. - linked_error_codes: Error catalog entries the endpoint can emit. EXAMPLE: Agent: "How do I call the screen audience endpoint?" describe_endpoint({ path: "/v1/data/screens/{screenId}/audience", method: "GET" })
| Name | Type | Req | Description |
|---|---|---|---|
| method | string | yes | HTTP method (case-insensitive). |
| path | string | yes | The operation path (OpenAPI template form, e.g. "/v1/data/screens/{screenId}/audience"). |
No output schema declared.
No examples provided.
device_heartbeat ~219
Send a heartbeat signal from a device to report its status. WHEN TO USE: - Regular device health monitoring (every 30-60 seconds) - Reporting current playback status - Reporting errors or issues RETURNS: - success: Boolean indicating success - device_status: Current device status in system - next_heartbeat_seconds: Recommended interval for next heartbeat EXAMPLE: User: "Send heartbeat for device P_abc123" device_heartbeat({ fingerprint: "P_abc123", status: "playing", current_ad_id: "507f1f77bcf86cd799439011", uptime_seconds: 3600 })
| Name | Type | Req | Description |
|---|---|---|---|
| current_ad_id | string | – | Currently playing ad ID (if status is "playing") |
| error_message | string | – | Error message (if status is "error") |
| fingerprint | string | yes | Device fingerprint (e.g., "P_abc123") |
| status | string | – | Current device status |
| uptime_seconds | integer | – | Device uptime in seconds |
No output schema declared.
No examples provided.
discover_inventory ~317
Discover available DOOH screens across the exchange network. WHEN TO USE: - Finding screens by venue type (retail, transit, office, etc.) - Finding screens in a specific city/state or within a radius - Finding screens with a specific audience profile (high income, professionals, etc.) - Getting an overview of available inventory with live audience data RETURNS: - screens: Array of screen objects with location, venue type, online status, and live audience data - total: Total matching screens - online_count: Number of currently online screens Each screen includes real-time audience data when available: - face_count, attention_score, income_level, mood, lifestyle - purchase_intent, crowd_density, ad_receptivity, dwell_time EXAMPLE: User: "Find retail screens in New York with high-income audience" discover_inventory({ venue_types: ["retail"], location: { city: "New York", state: "NY" }, audience_profile: { income: "high" }, limit: 20 })
| Name | Type | Req | Description |
|---|---|---|---|
| audience_profile | object | – | Filter screens by current audience characteristics |
| limit | integer | – | Maximum screens to return (default: 50, max: 200) |
| location | object | – | Location filter — use city/state OR lat/lng/radius_km |
| venue_types | array | – | Filter by venue types: transit, retail, outdoor, health_beauty, point_care, education, office, entertainment, government, financial, residential |
No output schema declared.
No examples provided.
export_cohort ~258
Export exposed audience cohort to a DSP for retargeting. Pushes MAID hashes from the campaign's exposed cohort to the specified DSP (The Trade Desk, DV360, or Meta). Creates or reuses a DSP segment. WHEN TO USE: - Activating DOOH-exposed audiences for retargeting on digital channels - Pushing cohorts to TTD, DV360, or Meta Custom Audiences - Measuring cross-channel retargeting lift RETURNS: - status: 'synced', 'no_cohort', 'credentials_missing', or 'empty_cohort' - destination: the DSP name - segmentId: internal segment ID - externalSegmentId: DSP-side segment ID - maidCount: number of MAIDs uploaded - accepted: number accepted by DSP Supported destinations: ttd, dv360, meta, cadent, mediaocean EXAMPLE: export_cohort({ campaign_id: "camp_abc123", destination: "ttd" })
| Name | Type | Req | Description |
|---|---|---|---|
| campaign_id | string | yes | Campaign identifier |
| destination | string | yes | DSP destination: ttd (The Trade Desk), dv360 (Google DV360), meta (Meta/Facebook), cadent, mediaocean |
No output schema declared.
No examples provided.
export_dataset ~417
Export observation data as a structured dataset. Supports filtering by time, geography, venue type, and observation family. Applies k-anonymity (k=5) to protect individual privacy. Queries the relevant table based on the selected dataset type, applies filters, enforces k-anonymity by suppressing groups with fewer than 5 observations, and returns structured data. WHEN TO USE: - Exporting audience data for external analysis - Building datasets for machine learning or reporting - Getting structured vehicle or commerce data for a specific time/place - Creating cross-signal datasets for correlation analysis RETURNS: - data: Array of dataset rows (schema varies by dataset type) - metadata: { row_count, k_anonymity_applied, export_id, dataset, filters_applied, time_range } - suggested_next_queries: Related exports or analyses Dataset types: - observations: Raw observation stream data (all families) - audience: Audience-specific data (face_count, demographics, attention, emotion) - vehicle: Vehicle counting and classification data - cross_signal: Pre-computed cross-signal correlation insights EXAMPLE: User: "Export audience data from retail venues last week" export_dataset({ dataset: "audience", filters: { time_range: { start: "2026-03-09", end: "2026-03-16" }, venue_type: ["retail"] }, format: "json" }) User: "Get vehicle data near geohash 9q8yy" export_dataset({ dataset: "vehicle", filters: { time_range: { start: "2026-03-15", end: "2026-03-16" }, geo: "9q8yy" } })
| Name | Type | Req | Description |
|---|---|---|---|
| dataset | string | yes | Type of dataset to export |
| filters | object | yes | Filters to apply to the export |
| format | string | – | Export format (default: json). Currently only JSON is supported. |
No output schema declared.
No examples provided.
find_similar_moments ~559
Find historically similar audience moments across the screen network using embedding similarity search. Input a natural-language description of the target moment. Moment embeddings are 768-D vectors generated from multi-modal observation data (visual, audio, environmental, social) via the MomentEmbeddingService. This tool embeds your query text and finds the closest real-world moments via approximate nearest-neighbour (ANN) cosine similarity over a Lance IVF_PQ index. CONSISTENCY: results are APPROXIMATE and EVENTUALLY CONSISTENT. - Approximate: retrieval is ANN, not an exhaustive scan (measured recall ~0.96 against exact KNN), so an identical query may omit a borderline match. - Eventually consistent: the index is served from a replicated pool whose replicas refresh independently, so for up to 5 minutes after new moments are published, two identical calls may return slightly different result sets. The difference is confined to the VISIBILITY of newly-published moments; the relative ranking of already-visible ones does not change. Do not use this tool where a repeatable, exhaustive result set is required. WHEN TO USE: - Searching for historical moments similar to a target scenario - Finding "moments like this one" across different venues/times - Discovering when similar audience compositions or behaviors occurred - Planning ad placements based on past similar contexts RETURNS: - data: Array of matching observations with similarity scores - observation_id, observed_at, venue_type, device_id, screen_mongo_id - payload: full observation data - evidence_grade: quality of observation - similarity: cosine similarity score (0-1, higher = more similar) - metadata: { result_count, embedding_model, min_similarity_threshold } - suggested_next_queries: Follow-up queries EXAMPLE: User: "Find moments with high engagement in evening restaurants with families" find_similar_moments({ query: "evening restaurant venue with families present, high emotional engag…
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | Maximum results to return. Default: 10, max: 200. |
| min_similarity | number | – | Minimum cosine similarity threshold (0-1). Default: 0.7. Lower values return more but less relevant results. |
| query | string | yes | Natural-language description of the target moment. Be descriptive about venue, time, audience, behavior, and conditions. |
| venue_type | string | – | Filter results to a specific venue type. Optional. |
No output schema declared.
No examples provided.
get_adcp_capabilities ~143
[AdCP] Get the seller agent's AdCP capabilities and supported protocols. Returns the full capability declaration for this AdCP DOOH seller agent. This tool does NOT require authentication. WHEN TO USE: - Discovering what protocols the seller agent supports (Signals, Media Buy) - Understanding available audience signals and data methodology - Getting MCP endpoint and discovery URLs RETURNS: - supported_protocols: ['signals', 'media_buy'] - inventory: DOOH format details, network size - audience_data: signal list, methodology, refresh rate - pricing: model, currency, floor CPM - discovery: well_known_url, mcp_endpoint
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_analytics ~261
Get analytics data for the partner account. WHEN TO USE: - Viewing overall performance metrics - Analyzing device performance - Generating reports on impressions and earnings - Comparing performance over time periods RETURNS: - summary: Overall stats (impressions, earnings, active_devices) - time_series: Data points over time - top_devices: Best performing devices - breakdown: Data grouped by requested dimension EXAMPLE: User: "Show me last week's analytics by device" get_analytics({ start_date: "2026-01-01", end_date: "2026-01-07", group_by: "device" }) User: "Get monthly performance breakdown" get_analytics({ start_date: "2025-12-01", end_date: "2025-12-31", group_by: "day" })
| Name | Type | Req | Description |
|---|---|---|---|
| device_id | string | – | Filter to a specific device (optional) |
| end_date | string | – | End date in YYYY-MM-DD format (optional, defaults to today) |
| group_by | string | – | How to group the analytics data |
| start_date | string | – | Start date in YYYY-MM-DD format (optional, defaults to 30 days ago) |
No output schema declared.
No examples provided.
get_attention_metrics ~205
Get edge AI attention metrics for a campaign (FEIN-powered). This is what makes DOOH attribution better than digital: Trillboards MEASURES viewability via FEIN edge AI instead of estimating it. WHEN TO USE: - Measuring actual human attention to ads (not just impressions) - Comparing attention-adjusted CPM (aCPM) vs standard CPM - Getting face count, dwell time, and emotion engagement data RETURNS: - impressions: total, uniqueDevices - attention: avgScore (0-1), medianScore, p90Score, avgDwellSeconds, avgFaceCount, qualifiedPct - economics: standardCpm, attentionCpm (aCPM), costPerAttentiveReach - emotion: avgEngagement (0-1), positiveEmotionPct aCPM = total_media_cost / (SUM(attention_score * face_count) / 1000)
| Name | Type | Req | Description |
|---|---|---|---|
| campaign_id | string | yes | Campaign identifier |
No output schema declared.
No examples provided.
get_attribution_timeseries ~197
Get daily attribution timeseries for a campaign. WHEN TO USE: - Tracking attribution trends over time - Identifying which days had the strongest lift - Building attribution dashboards with daily granularity RETURNS: Array of daily data points, each with: - date, uniqueDevices, totalExposures, avgFrequency - exposedVisitors, controlVisitors, liftPct, incrementalVisits - costPerVisit, totalMediaCost, isSignificant EXAMPLE: get_attribution_timeseries({ campaign_id: "camp_abc123", start_date: "2026-03-01", end_date: "2026-03-10" })
| Name | Type | Req | Description |
|---|---|---|---|
| campaign_id | string | yes | Campaign identifier |
| end_date | string | – | End date (YYYY-MM-DD). Optional, defaults to today. |
| start_date | string | – | Start date (YYYY-MM-DD). Optional, defaults to campaign start. |
No output schema declared.
No examples provided.
get_audience_forecast ~274
Predict what the audience will look like at a screen at a specific time. WHEN TO USE: - Planning campaigns for specific time slots - Estimating audience composition before buying - Comparing audience at different times of day Uses historical audience data to predict typical audience patterns. RETURNS: - predicted_face_count: Expected number of viewers - predicted_attention: Expected attention score - typical_income: Most common income level at that time - typical_lifestyle: Most common lifestyle segment at that time - confidence: Prediction confidence (0-1, based on sample count) - sample_count: Number of historical data points used EXAMPLE: User: "What's the typical audience at this screen on Monday at 3pm?" get_audience_forecast({ screen_id: "507f1f77bcf86cd799439011", hour: 15, day: 1, lookback_days: 30 })
| Name | Type | Req | Description |
|---|---|---|---|
| day | integer | yes | Day of week (0=Sunday, 1=Monday, ..., 6=Saturday) |
| hour | integer | yes | Hour of day (0-23) |
| lookback_days | integer | – | Days of historical data to use (default: 30) |
| screen_id | string | yes | Screen ID to forecast |
No output schema declared.
No examples provided.
get_audience_lookalike ~255
Find screens with similar audience profiles using pgvector similarity. Uses 64-dimensional audience vectors with HNSW cosine similarity index to find screens whose audience demographics, attention, and behavioral patterns match a target screen. WHEN TO USE: - Expanding campaign reach to screens with similar audiences - Finding new inventory that matches a high-performing screen - Building lookalike audience segments for targeting RETURNS: Array of similar screens ranked by cosine similarity, each with: - screen_id, similarity (0-1), metadata (face_count, attention, income, lifestyle), last_seen EXAMPLE: get_audience_lookalike({ screen_id: "scr_abc123", limit: 10, min_similarity: 0.8 })
| Name | Type | Req | Description |
|---|---|---|---|
| country | string | – | Filter by country (optional) |
| limit | integer | – | Maximum number of results (default: 20, max: 100) |
| min_similarity | number | – | Minimum cosine similarity threshold 0-1 (default: 0.7) |
| screen_id | string | yes | Source screen ID to find lookalikes for |
| venue_type | string | – | Filter by venue type (optional) |
No output schema declared.
No examples provided.
get_billing_status ~48
Check current billing status including whether billing is set up, credit balance, Stripe customer ID, and payment method status. Use this to determine if billing setup is needed before making paid API calls.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_campaign_attribution ~167
Get comprehensive attribution summary for a DOOH campaign. WHEN TO USE: - Measuring overall campaign effectiveness (reach, footfall, sales lift) - Getting a high-level view of campaign attribution metrics - Checking statistical significance of attribution results RETURNS: - reach: uniqueDevices, totalImpressions, avgFrequency - footfall: exposedVisitors, controlVisitors, incrementalLiftPct, incrementalVisits - cost: totalMediaCost, costPerUniqueReach, costPerIncrementalVisit - quality: avgMatchConfidence, statisticalSignificance, isSignificant - dataFreshness: latestOutcomeAt, provisionalCount, finalizedCount Returns null if no attribution data exists for the campaign.
| Name | Type | Req | Description |
|---|---|---|---|
| campaign_id | string | yes | Campaign identifier (UUID or string ID from create_campaign) |
No output schema declared.
No examples provided.
get_campaign_heatmap ~129
Get geographic exposure heatmap data for a campaign. Returns lat/lng clusters with exposure counts and device reach, useful for visualizing where ads were shown on a map. WHEN TO USE: - Visualizing campaign geographic coverage - Identifying hotspots of ad exposure - Analyzing geographic distribution of attributed foot traffic RETURNS: Array of geographic clusters (max 500), each with: - lat, lng (rounded to 3 decimal places) - uniqueDevices, totalExposures - avgConfidence (match confidence score)
| Name | Type | Req | Description |
|---|---|---|---|
| campaign_id | string | yes | Campaign identifier |
No output schema declared.
No examples provided.
get_campaign_performance ~148
Get detailed performance metrics for a campaign. WHEN TO USE: - Monitoring active campaign performance - Reviewing completed campaign results - Getting per-screen impression breakdowns RETURNS: - campaign_id, name, status, budget, dates - performance: impressions, spend_estimate_usd, avg_cpm, unique_screens, avg_latency_ms - screen_breakdown: per-screen impressions and CPM EXAMPLE: User: "How is my NYC retail campaign performing?" get_campaign_performance({ campaign_id: "550e8400-e29b-41d4-a716-446655440000" })
| Name | Type | Req | Description |
|---|---|---|---|
| campaign_id | string | yes | Campaign UUID returned from create_campaign |
No output schema declared.
No examples provided.
get_content_performance ~330
Get performance metrics for a video across the Trillboards DOOH network. WHEN TO USE: - Checking how a specific video performs across screens (plays, attention, audience size) - Analyzing which venue types and dayparts a video resonates best in - Finding the top-performing screens for a piece of content - Comparing content performance over different time windows RETURNS: - videoId, title, totalPlays, uniqueScreens - avgAttention (0-1), avgAudienceSize, avgDwellMs - venueDistribution: Array of { venue_type, plays } - daypartDistribution: Array of { daypart, plays } - topScreens: Top 10 screens by play count with attention scores - period: { start, end } date range EXAMPLE: User: "How is video dQw4w9WgXcQ performing on retail screens?" get_content_performance({ video_id: "dQw4w9WgXcQ", venue_type: "retail", days: 30 }) User: "Show me the last 7 days of performance for this video" get_content_performance({ video_id: "abc123xyz", days: 7 })
| Name | Type | Req | Description |
|---|---|---|---|
| days | integer | – | Lookback window in days (default: 30, max: 90) |
| venue_type | string | – | Optional venue type filter (e.g., "retail", "transit", "bar") |
| video_id | string | yes | YouTube video ID to query performance for |
No output schema declared.
No examples provided.
get_content_recommendations ~307
Get best-performing content recommendations for a venue type and optional time context. WHEN TO USE: - Deciding what content to schedule at a specific venue type - Finding content that drives the highest audience engagement at a location - Optimizing content rotation by daypart (morning, afternoon, evening, overnight) - Content programming decisions based on performance data RETURNS: - data: Array of recommended content ranked by performance score - videoId, title, contentCategory, durationSeconds - totalPlays, uniqueScreens - avgAttention (0-1), avgDwellMs - performanceScore (composite of attention, replay density, dwell time) - meta: { count, venue_type, daypart, limit } Performance score formula: attention(40%) + replay_density(30%) + dwell_time(30%) EXAMPLE: User: "What content works best in bars during the evening?" get_content_recommendations({ venue_type: "bar", daypart: "evening", limit: 10 }) User: "Best performing content for transit screens" get_content_recommendations({ venue_type: "transit", limit: 20 })
| Name | Type | Req | Description |
|---|---|---|---|
| daypart | string | – | Optional daypart filter |
| limit | integer | – | Maximum recommendations to return (default: 10, max: 100) |
| venue_type | string | yes | Venue type to get recommendations for (required) |
No output schema declared.
No examples provided.
get_creative_attention ~124
Get per-creative attention breakdown for a campaign. WHEN TO USE: - A/B testing creative variants by attention score - Identifying which creative drives the most engagement - Comparing aCPM across creative assets RETURNS: Array of creatives ranked by attention score, each with: - creativeId, totalImpressions, uniqueDevices - avgAttentionScore (0-1), avgDwellSeconds, avgFaceCount - attentionCpm, avgEmotionEngagement, positiveEmotionPct, attentionQualifiedPct
| Name | Type | Req | Description |
|---|---|---|---|
| campaign_id | string | yes | Campaign identifier |
No output schema declared.
No examples provided.
get_creative_attribution ~167
Get attribution performance by individual creative variant. Links creative execution to attribution outcomes: which creative variant drove the most store visits? WHEN TO USE: - Comparing creative A/B/C test performance on attribution outcomes - Finding the optimal creative x venue_type x daypart x weather combination - Identifying the creative with the highest visit rate RETURNS: Array of creatives ranked by store visits, each with: - creativeId, variant, totalVisits, avgVisitRate - attention: avgScore, avgDwell, avgEmotion, dominantEmotion - avgLiftPct, avgCostPerVisit - bestContext: { venueType, daypart, weather } - dateRange: { first, last, daysMeasured }
| Name | Type | Req | Description |
|---|---|---|---|
| campaign_id | string | yes | Campaign identifier |
No output schema declared.
No examples provided.
get_cross_channel_journey ~120
Get cross-channel customer journey data (Sankey flow) for a campaign. Shows how users flow between channels: DOOH -> mobile -> web -> store. WHEN TO USE: - Visualizing the customer journey across DOOH and digital channels - Understanding channel transition patterns - Building Sankey diagrams of marketing funnels RETURNS: - flows: Array of { source, target, count } transitions between channels - channels: Array of { channel, touchpoints, uniqueDevices } distribution
| Name | Type | Req | Description |
|---|---|---|---|
| campaign_id | string | yes | Campaign identifier |
No output schema declared.
No examples provided.
get_dataset_stats ~231
Get statistics about available causal training data: total tuples, unique creatives, venue diversity, date range. Queries observation_stream for rows that have both a creative ID and a VAS outcome recorded, giving a picture of how much training data is available for the causal prediction engine. WHEN TO USE: - Checking if enough data exists for reliable causal predictions - Understanding the diversity of training data (creatives, venues, time range) - Monitoring causal dataset health and growth - Planning data collection strategies RETURNS: - data: Dataset statistics - total_tuples: number of context-action-outcome records - unique_creatives: number of distinct creatives with VAS data - unique_venue_types: number of distinct venue types represented - date_range: { start, end } of available data - observations_per_creative: { min, max, mean, median } distribution - metadata: { query_window_days } - suggested_next_queries: Follow-up queries EXAMPLE: User: "How much causal training data do we have?" get_dataset_stats({})
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_device ~154
Get detailed information about a specific device. WHEN TO USE: - Checking status of a single device - Getting device configuration details - Debugging device issues RETURNS: - device_id: Your internal device ID - trillboards_device_id: Internal Trillboards ID - fingerprint: Device fingerprint - name: Device name - status: online/offline - last_seen: Last heartbeat timestamp - location: Location details - specs: Device specifications - stats: Impression and earnings stats EXAMPLE: User: "Get details for vending machine 001" get_device({ device_id: "vending-001-nyc" })
| Name | Type | Req | Description |
|---|---|---|---|
| device_id | string | yes | Your internal device identifier |
No output schema declared.
No examples provided.
get_device_ads ~124
Get current ads scheduled for a device (for testing). WHEN TO USE: - Testing device ad delivery - Debugging which ads are being shown - Verifying ad targeting is working RETURNS: - ads: Array of advertisement objects - default_stream: Default content when no ads - schedule: Current ad schedule EXAMPLE: User: "What ads are showing on device P_abc123?" get_device_ads({ fingerprint: "P_abc123" })
| Name | Type | Req | Description |
|---|---|---|---|
| fingerprint | string | yes | Device fingerprint (e.g., "P_abc123") |
No output schema declared.
No examples provided.
get_incrementality ~173
Get incrementality/lift test results for a campaign. Uses Bayesian (Beta-Binomial with 10K Monte Carlo samples) and frequentist (chi-square with Yates correction) methods for causal measurement. WHEN TO USE: - Proving causal DOOH advertising effectiveness - Getting both Bayesian and frequentist significance measures - Seeing treatment vs control group visit rates and lift RETURNS: Array of experiments, each with: - experimentId, type (geo_holdout/ghost_ads/psm), status - treatmentDmas, controlDmas - latestResult: treatment/control rates, lift%, incrementalVisits, pValue, posteriorProbPositive, expectedUplift, credibleInterval Returns empty array if no experiments exist for this campaign.
| Name | Type | Req | Description |
|---|---|---|---|
| campaign_id | string | yes | Campaign identifier |
No output schema declared.
No examples provided.
get_live_audience ~269
Get real-time audience data for a specific screen. WHEN TO USE: - Checking current audience at a screen before buying - Monitoring audience during a live campaign - Getting detailed audience signals (attention, mood, purchase intent, demographics) RETURNS real-time data from edge AI sensors (refreshed every 10 seconds): - face_count: Number of people currently viewing - attention_score: How attentively the audience is watching (0-1) - income_level: Estimated income bracket (from Gemini Vision) - mood: Current audience mood - lifestyle: Primary lifestyle segment - purchase_intent: Purchase intent level - crowd_density: Estimated venue occupancy - ad_receptivity: How receptive the audience is to ads (0-1) - emotional_engagement: Emotional engagement score (0-1) - group_composition: Solo/couples/families/friends/work groups - signals_age_ms: How fresh the data is in milliseconds EXAMPLE: User: "What's the current audience at screen 507f1f77bcf86cd799439011?" get_live_audience({ screen_id: "507f1f77bcf86cd799439011" })
| Name | Type | Req | Description |
|---|---|---|---|
| screen_id | string | yes | Screen ID to get live audience for |
No output schema declared.
No examples provided.
get_media_buy_delivery ~193
[AdCP Media Buy] Get delivery/performance report for a media buy. Returns campaign performance with breakdowns by screen, venue, hour, and audience segment. WHEN TO USE: - Monitoring campaign delivery in real-time - Getting performance breakdowns for optimization - Reporting on campaign results RETURNS: - delivery: impressions, spend, avg_cpm, unique_screens, fill_rate - breakdowns: by_screen, by_venue, by_hour (top performers) EXAMPLE: get_media_buy_delivery({ media_buy_id: "mbuy_abc123" })
| Name | Type | Req | Description |
|---|---|---|---|
| breakdown_by | array | – | Dimensions to break down by (legacy, prefer dimensions). Same single supported value. |
| dimensions | array | – | Reporting dimensions to include. Only "screen" is supported; anything else is returned in dimensions_unsupported rather than silently dropped. |
| media_buy_id | string | yes | Media buy ID |
No output schema declared.
No examples provided.
get_media_buys ~348
[AdCP Media Buy] List media buys with status, budget, flight and optional delivery snapshots. Status, budget and flight are read from the advertisements + placements spine the buy actually books on — not from a stored display string. A buy that its flight ended, or that the pacing cron completed on goal, reports the truth here even though nothing rewrote it. WHEN TO USE: - Polling the buys you have open on this account - Confirming a buy left pending_creatives after sync_creatives - Getting a near-real-time delivery snapshot without a full delivery report RETURNS: - media_buys: each with media_buy_id, status, currency, total_budget, confirmed_at, revision and packages[]. status is the AdCP media-buy-status enum; the accepted values are listed on the status_filter parameter below. - pagination: cursor-based EXAMPLE: get_media_buys({ status_filter: ["active", "pending_creatives"], include_snapshot: true }) get_media_buys({ media_buy_ids: ["mbuy_1750000000000_ab12cd34"] })
| Name | Type | Req | Description |
|---|---|---|---|
| context | object | – | – |
| include_snapshot | boolean | – | Include a delivery snapshot per package (impressions, spend, pacing_index). Read live off placements, so staleness_seconds is 0. |
| media_buy_ids | array | – | Specific media buy IDs. When omitted, returns a paginated set matching status_filter. |
| pagination | object | – | – |
| status_filter | – | – | Single status or array of statuses. Defaults to ['active'] when media_buy_ids is omitted; no implicit filter when ids are given. |
No output schema declared.
No examples provided.
get_multi_touch_attribution ~177
Get multi-touch attribution model results for a campaign. Supported models: time_decay, position_based, attention_weighted. WHEN TO USE: - Understanding how DOOH fits into the full marketing funnel - Seeing credit allocation across DOOH, mobile, web, and store channels - Quantifying DOOH's contribution to conversions RETURNS: - totalChains: number of multi-touch journeys found - avgTouchpoints: average touchpoints per chain - channelAttribution: { dooh, mobile, web, store } (each 0-1, sums to 1) - conversions: total conversion events - totalConversionValue: sum of conversion values (cents) - avgConfidence: average match confidence across chains Returns null if no multi-touch chains exist.
| Name | Type | Req | Description |
|---|---|---|---|
| campaign_id | string | yes | Campaign identifier |
No output schema declared.
No examples provided.
get_network_stats ~126
Get network-wide statistics across all partner screens. WHEN TO USE: - Getting a high-level overview of network performance - Checking how many screens are online - Reviewing total impressions and revenue estimates RETURNS: - total_screens, online_screens - impressions, total_auctions - revenue_estimate_usd, avg_cpm, fill_rate EXAMPLE: User: "How is my network performing this week?" get_network_stats({ time_range: "7d" })
| Name | Type | Req | Description |
|---|---|---|---|
| time_range | string | – | Time range for stats (default: 7d) |
No output schema declared.
No examples provided.
get_partner_info ~113
Get information about the authenticated partner account. WHEN TO USE: - Checking current partner status and stats - Verifying API key is working - Getting partner account details RETURNS: - partner_id: Partner identifier - company_name: Registered company name - status: Account status (active, suspended, etc.) - device_count: Number of registered devices - total_impressions: Lifetime impression count - earnings: Earnings summary EXAMPLE: User: "What's my partner account status?" get_partner_info({})
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_pricing ~85
Get machine-readable pricing for all Trillboards products. Returns graduated usage-based pricing, free tier thresholds, and committed-use discount tiers. No authentication required — use this to evaluate costs before integrating.
| Name | Type | Req | Description |
|---|---|---|---|
| product | string | – | Optional: filter to a specific product (data_api, proof_of_play, attribution, data_marketplace, partner_platform, programmatic, fein_edge_ai) |
No output schema declared.
No examples provided.
get_products ~396
[AdCP Media Buy] Get available DOOH advertising products and packages. NO AUTHENTICATION REQUIRED. Discovery is open — read the catalogue first, get a key when you want to transact. Send a natural-language `brief` and it is answered from what the screens actually observed: each product's `description` reports the hours people are really in frame (in the screens' own local time), how long they dwell, the mood / movement / gaze the on-device sensors reported, what the speech layer heard people shopping for — and, explicitly, which of your words we cannot evidence. Products are ordered by that evidence. WHEN TO USE: - Browsing available inventory before creating a campaign - Comparing pricing across venue types and locations - Understanding what's available in a specific market, at a specific time of day RETURNS: - products: Array of product packages with pricing, reach, and observed audience - Each product includes: name, description (free text answering your brief), venue_type, screen_count, pricing_options, and `observed` — the numbers behind the prose, present only where we measured something - brief_interpretation: how we read your brief, so you can see if we read it right EXAMPLE: User: "commuters who are bored and hungry around lunchtime" get_products({ brief: "commuters who are bored and hungry around lunchtime" })
| Name | Type | Req | Description |
|---|---|---|---|
| audience_profile | object | – | Target audience characteristics |
| brief | string | – | Natural language campaign brief for AI-driven inventory matching |
| buying_mode | string | – | AdCP buying mode (default: brief) |
| filters | object | – | Structured filters for wholesale/refine modes |
| market | string | – | Market/city to get products for |
| pagination | object | – | – |
| venue_types | array | – | Filter by venue types (legacy, prefer filters.venue_types) |
No output schema declared.
No examples provided.
get_roas ~196
Get Return on Ad Spend (ROAS) with transaction attribution data. Closes the ROAS loop: matches purchase events to DOOH exposures with time-decay weighting, and computes attributed revenue and incremental ROAS. WHEN TO USE: - Measuring revenue directly attributable to DOOH advertising - Getting ROAS and incremental ROAS (iROAS) figures - Seeing sales lift between exposed and control groups RETURNS: - transactions: total, uniquePurchasers, totalRevenueCents, avgBasketCents - attribution: attributedTransactions, attributedRevenueCents, totalMediaCostCents, roas, iroas - salesLift: exposedPurchasers, controlPurchasers, incrementalTransactions, incrementalRevenueCents, salesLiftPct, posteriorProbPositive - timing: avgHoursToPurchase, medianHoursToPurchase Returns null if no transaction data exists.
| Name | Type | Req | Description |
|---|---|---|---|
| campaign_id | string | yes | Campaign identifier |
No output schema declared.
No examples provided.
get_signals ~276
[AdCP Signals] Get real-time audience signals from DOOH screens. This is an AdCP (Ad Context Protocol) compliant tool. It returns deterministic audience signals captured by edge AI (vision + audio + speech) on available screens. WHEN TO USE: - Discovering available audience signals before buying inventory - Evaluating audience composition at specific venues or locations - Building targeting segments based on real-time audience data Unlike probabilistic data, these signals are DETERMINISTIC — captured by on-device cameras and microphones, analyzed by ML Kit and Gemini Vision. RETURNS: - signals: Array of per-screen signal objects with demographics, venue, behavior, geo - metadata: total_screens, matching_screens, screens_with_live_data EXAMPLE (AdCP form — natural language): User: "What audience signals are available at retail locations?" get_signals({ signal_spec: "shoppers in retail venues, demographics and behavior" }) EXAMPLE (structured form): get_signals({ signal_spec: { signal_types: ["demographics", "behavior"], filters: { venue_type: "retail" } } })
| Name | Type | Req | Description |
|---|---|---|---|
| pagination | object | – | – |
| signal_spec | – | – | Natural language description of the desired signals (AdCP form), or a structured Trillboards signal specification. |
No output schema declared.
No examples provided.
get_social_attention ~486
Query social attention contagion metrics from the observation stream. Returns windows where attention propagated between viewers (social amplification factor > 1). Social attention data is produced by the AttentionGraphBuilder running on CTV edge devices, which models viewer attention as a directed graph and detects when one viewer looking at the screen triggers nearby viewers to also look (attention contagion / social amplification). WHEN TO USE: - Finding moments where social proof drove collective engagement - Identifying which venues or dayparts exhibit highest attention contagion - Understanding cascading attention patterns (cascade depth) - Correlating social amplification with ad effectiveness (VAS) RETURNS: - data: Array of observation_stream rows with socialAttention payload - payload.socialAttention.socialAmplificationFactor (SAF): ratio of actual-to-expected group attention (>1 = contagion detected) - payload.socialAttention.cascadeDepth: max depth of attention propagation chain - payload.socialAttention.viralAttentionScore: composite metric combining SAF and cascade depth - payload.socialAttention.contagionWindowMs: time window over which cascade occurred - payload.socialAttention.triggerViewerIndex: which viewer initiated the cascade - metadata: { result_count, time_range, min_saf_filter } - suggested_next_queries: Follow-up queries EXAMPLE: User: "Show me moments where attention went viral in bar venues" get_social_attention({ min_saf: 2.0, venue_type: "bar" }) User: "Find the strongest social amplification events this week" get_social_attention({ min_saf: 3.0, time_range: { start: "2026-03-09T00:00:00Z", end: "2026-03-16T00:00:00Z" } })
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | Maximum results to return. Default: 20, max: 200. |
| min_saf | number | – | Minimum social amplification factor threshold. Default: 1.5. Higher values return only stronger contagion events. |
| screen_id | string | – | Filter by screen MongoDB ID. Optional. |
| time_range | object | – | Time range filter. Defaults to last 24 hours. |
| venue_type | string | – | Filter by venue type (e.g., "bar", "restaurant_qsr", "transit"). Optional. |
No output schema declared.
No examples provided.
get_social_contagion_summary ~357
Aggregate social attention metrics across screens and time periods. Shows which venues and dayparts have the highest social amplification. Queries observation_stream for social attention data and aggregates by the requested dimension (venue, daypart, or screen), computing average SAF, average cascade depth, average viral attention score, and event count. WHEN TO USE: - Understanding which venues generate the most social amplification - Comparing daypart effectiveness for social contagion - Identifying top-performing screens for attention cascading - Planning campaigns that leverage social proof RETURNS: - data: Array of aggregated rows, sorted by avg SAF descending - group_key: the dimension value (venue type, daypart, or screen ID) - avg_saf: average social amplification factor - avg_cascade_depth: average attention cascade depth - avg_viral_attention_score: average viral attention score - event_count: number of social attention events in the group - metadata: { group_by, time_range, total_events } - suggested_next_queries: Follow-up queries EXAMPLE: User: "Which venues have the highest social amplification this week?" get_social_contagion_summary({ group_by: "venue", time_range: { start: "2026-03-09", end: "2026-03-16" } }) User: "Show me social attention by daypart over the last 7 days" get_social_contagion_summary({ group_by: "daypart" })
| Name | Type | Req | Description |
|---|---|---|---|
| group_by | string | – | Dimension to group by: "venue", "daypart", or "screen". Default: "venue". |
| time_range | object | – | Time range filter. Defaults to last 7 days. |
No output schema declared.
No examples provided.
get_task_status ~355
[AdCP Protocol] Get the status of a previously issued AdCP task. Every AdCP task Trillboards serves for an AUTHENTICATED caller is recorded and returned a `task_id`. Poll that id here to read the task's terminal state and, with `include_result: true`, its completion payload. Trillboards answers every AdCP task in-process, so a task is already `completed` by the time you hold its id — this tool exists so a buyer that polls does not hang, and so an async arm has somewhere to report from when one lands. TASK SCOPE: tasks are visible only to the account that created them. An id belonging to another account, an id we never issued, or a poll with no credential all answer identically — "Task <id> not found" — so the surface cannot be used to probe which ids exist. NOT RECORDED: read-only protocol and catalogue calls that AdCP does not model as tasks (get_adcp_capabilities, list_creative_formats, get_media_buys, list_accounts), and any anonymous call, which has no account to scope to.
| Name | Type | Req | Description |
|---|---|---|---|
| account | object | – | – |
| context | object | – | – |
| include_history | boolean | – | Include conversation history. Trillboards tasks complete in-process and hold no multi-turn history, so this is accepted and has no effect. |
| include_result | boolean | – | Include the task's result payload when status is completed. Defaults to false for lightweight status-only polls. |
| task_id | string | yes | Unique identifier of the task to retrieve, as issued in the `task_id` field of the originating task response. |
No output schema declared.
No examples provided.
get_usage_summary ~35
Get your current billing period usage summary with per-product breakdown and costs. Shows free tier consumption, paid usage, and total cost.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
What is the Trillboards DOOH Advertising MCP server?
Trillboards DOOH Advertising is an MCP server listed in the public MCP registry as io.github.snehdhruv/trillboards-dooh. DOOH advertising via AI agents. 5,000+ screens with edge AI audience intelligence. This page covers its hosted endpoint (https://api.trillboards.com/mcp).
Is the Trillboards DOOH Advertising MCP server safe to use?
Trillboards DOOH Advertising scores 79 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Trillboards DOOH Advertising MCP server expose?
Trillboards DOOH Advertising exposes 83 tools: register_partner, get_partner_info, register_device, list_devices, get_device, and 78 more. Their descriptions and schemas cost roughly 21,774 tokens of context every time the server is loaded.
Does the Trillboards DOOH Advertising MCP server require authentication?
No. We connected to Trillboards DOOH Advertising without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the Trillboards DOOH Advertising MCP server still maintained?
Trillboards DOOH Advertising is still listed as active in the MCP registry. We last reached this channel on 24 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.