We Shipped the First DOOH MCP Server: Model Context Protocol for Programmatic Out-of-Home

**TL;DR:** The May 2026 release of our Model Context Protocol (MCP) server establishes a direct, programmatic bridge between Large Language Models and physical out-of-home media. By exposing 74 tools across 14 functional categories over streamable-HTTP using protocol version 2025-11-25, the server allows AI agents to autonomously discover inventory, analyze real-world audience signals, and execute programmatic DOOH media buys. This technical deep-dive details the JSON-RPC architecture, tool schemas, and developer integration pathways for LLM-driven ad operations.

## The Shift to Schema-Driven Out-of-Home Operations

Programmatic Digital Out-of-Home (DOOH) has historically operated within a rigid, human-configured execution loop. Demand-Side Platforms (DSPs) and Supply-Side Platforms (SSPs) trade inventory using variations of the OpenRTB protocol, relying on pre-negotiated deals, fixed targeting parameters, and static creative approval workflows. While this structured approach works well for deterministic software systems, it introduces significant friction for autonomous systems and cognitive agents that operate on natural language instructions, real-time contextual reasoning, and dynamic decision-making loops.

When LLM-driven agents attempt to interact with traditional DOOH infrastructure, they encounter a fundamental integration gap. Standard REST APIs require hardcoded client-side wrappers, and their documentation must be manually ingested or hard-coded into agent prompts. This setup lacks runtime flexibility, fails to support dynamic capability discovery, and forces developers to build fragile middleware to translate an agent's intent into structured API calls.

To bridge this gap, we have engineered and shipped the first DOOH-native server implementing the [Model Context Protocol](https://modelcontextprotocol.io/). Designed to standardize how applications expose data and tools to AI models, MCP provides a uniform interface for context exchange. Originally introduced to streamline local developer toolchains (as detailed in [Anthropic's announcement](https://www.anthropic.com/news/model-context-protocol)), we have extended this protocol to global, distributed adtech infrastructure.

Our May 2026 release moves beyond experimental local integrations, deploying a production-grade MCP server that operates over streamable-HTTP. By implementing the formal [MCP Specification](https://github.com/modelcontextprotocol/specification) version 2025-11-25, we expose 74 tools across 14 distinct functional categories. This allows any MCP-compliant client—whether it is Claude Desktop, Cursor, or a custom-built autonomous media-buying agent—to dynamically discover, query, and purchase programmatic DOOH inventory without manual API integration or custom client-side code.

Our network telemetry during the May 2026 release indicates that this schema-driven approach drastically reduces integration overhead. Instead of writing custom API clients for every new demand source, developers can point their MCP-enabled agents directly to our endpoint. The agent negotiates capabilities, discovers the available tools, and begins executing actions based on real-time environmental context.

## MCP Architecture Deep-Dive: Protocol Version 2025-11-25

The core of our implementation is built on the `2025-11-25` protocol version, utilizing `streamable-http` as the transport layer. While standard desktop MCP implementations rely on local standard input/output (`stdio`) pipes to communicate with running processes, distributed adtech operations require a network-accessible, low-latency transport layer.

### JSON-RPC over Streamable-HTTP

The transport layer implements persistent, bidirectional communication using HTTP POST requests combined with Server-Sent Events (SSE) or chunked transfer encoding to stream responses back to the client. This hybrid transport model, which we refer to as `streamable-http`, allows the client to invoke tools via standard HTTP endpoints while receiving real-time updates and execution telemetry over a continuous stream.

When an MCP client initializes a connection to `api.trillboards.com/mcp`, it performs a handshake to negotiate capabilities. The handshake establishes the protocol version and informs the server of the client's capabilities (such as whether it supports dynamic tool registration, resources, or prompt templates).

Here is an architectural representation of the handshake and tool execution lifecycle:

```
Client (e.g., Claude Desktop) Trillboards MCP Server
| |
|---- HTTP POST /mcp/initialize ----------------->| (Protocol version negotiation)
|<--- HTTP 200 OK (Capabilities & Version) -------| (Server registers 74 tools)
| |
|---- HTTP POST /mcp/tools/list ----------------->| (Query available capabilities)
|<--- HTTP 200 OK (JSON-RPC Schema Array) --------| (Returns 14 tool categories)
| |
|---- HTTP POST /mcp/tools/call (Run Query) ------>| (Execute specific DOOH action)
|<--- HTTP 200 OK (Streamed JSON-RPC Response) ---| (Returns real-time inventory state)
```

### Tool Registration and Schema Negotiation

Upon initialization, the server advertises its available tools. The client queries these tools using the standard `tools/list` method. The following JSON-RPC payload demonstrates how the client requests the list of available tools:

```json
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/list",
"params": {}
}
```

In response, the server returns an array of tool schemas. Each tool schema is defined using JSON Schema draft-07, providing the LLM with the exact parameters, data types, and descriptions required to construct a valid tool call. Below is an abbreviated example of the response payload, highlighting the `inventory/query` tool, which is part of our core inventory discovery suite:

```json
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"tools": [
{
"name": "inventory/query",
"description": "Query available DOOH inventory based on physical parameters, location, and real-time screen availability.",
"inputSchema": {
"type": "object",
"properties": {
"latitude": {
"type": "number",
"description": "Latitude of the target center point."
},
"longitude": {
"type": "number",
"description": "Longitude of the target center point."
},
"radius_meters": {
"type": "integer",
"default": 5000,
"description": "Search radius around the center point."
},
"venue_type": {
"type": "string",
"enum": ["transit", "retail", "billboard", "street_furniture"],
"description": "Filter by physical venue classification."
},
"min_impressions_per_hour": {
"type": "integer",
"description": "Minimum historical hourly impression threshold."
}
},
"required": ["latitude", "longitude"]
}
}
]
}
}
```

When the agent decides to execute a tool, it sends a `tools/call` request. The agent's cognitive engine parses the user's natural language request, matches it against the registered schemas, and populates the arguments. Here is an example of an agent calling the `inventory/query` tool to find transit-related screens in a specific geographic bounding box:

```json
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "inventory/query",
"arguments": {
"latitude": 40.7580,
"longitude": -73.9855,
"radius_meters": 1000,
"venue_type": "transit",
"min_impressions_per_hour": 1500
}
}
}
```

The server executes the query against our real-time inventory index and returns the result as a structured text block within the standard JSON-RPC response format:

```json
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"content": [
{
"type": "text",
"text": "Found 12 matching DOOH screens within a 1000m radius. Average historical impressions: 2,450 per hour. Current pricing floor: $4.50 CPM. All screens are active and accepting real-time programmatic bidding."
}
],
"isError": false
}
}
```

By operating entirely within this structured handshake and execution cycle, the LLM does not need to guess API endpoints, handle HTTP redirect loops, or parse unstructured HTML documentation. The schema is the contract, negotiated dynamically at runtime.

## The 74 Tools of the Trillboards MCP Server

To enable comprehensive, end-to-end programmatic campaign execution, we have implemented 74 individual tools. These tools are organized into 14 logical categories, ensuring that the model has access to granular capabilities without cluttering its context window with monolithic, poorly defined endpoints.

Developers looking to build custom integrations can reference our complete [developer documentation](/support/developers/) for setup instructions, and consult our [DSP API integration guide](/support/developers/dsp-api/) to understand how these tools map to traditional programmatic buying pipelines. For automated agent discovery, we maintain a [machine-readable LLM configuration file](/llms.txt) that details the server's capabilities and structural endpoints.

Below is a breakdown of the 14 tool categories and how they function within the programmatic DOOH lifecycle.

### 1. Partner Tools
These tools manage administrative relationships and access permissions between demand partners, networks, and localized media owners. They allow agents to verify contractual status, query operational boundaries, and establish programmatic trust chains dynamically.

### 2. Device Tools
Device tools expose hardware-level telemetry and status. Agents can query screen resolution, orientation (portrait vs. landscape), operating temperature, current player application version, and hardware capabilities (e.g., whether a screen supports dynamic video rendering or interactive triggers).

### 3. Impression Tools
This category handles real-time and historical impression metrics. It allows agents to retrieve audited impression data, historical traffic patterns, and sensor-derived foot traffic estimates for specific screens, enabling precise bid valuation based on actual physical presence.

### 4. Analytics Tools
Analytics tools allow models to run complex multi-dimensional queries over historical campaign performance. Agents can request aggregate reports on play counts, delivery rates, share-of-voice (SOV) distribution, and demographic index scores across specific geohashes.

### 5. Webhook Tools
To prevent agents from continuously polling the API for status updates, the webhook category allows models to programmatically register, modify, and tear down HTTP callbacks. For instance, an agent can register a webhook to be notified immediately when a specific screen goes offline or when a campaign reaches its budget cap.

### 6. Inventory Tools
Inventory tools provide deep search and filtering capabilities across the entire available screen pool. Agents use these tools to match physical locations with target audience profiles, search by ZIP code or custom polygon geofences, and check real-time slot availability (share-of-voice availability) for upcoming hours.

### 7. Campaign Tools
This category manages the logical state of advertising campaigns. Tools include capabilities to create campaigns, assign flight dates, set budget constraints, define pacing strategies (e.g., even pacing vs. front-loaded), and transition campaigns between active, paused, and completed states.

### 8. AdCP Signals (Audience & Device Context Protocol)
AdCP signal tools expose real-time environmental data streams associated with specific physical locations. This includes local weather conditions, UV index, local transit delays, aggregate mobile location data, and active localized event triggers (e.g., a sports game ending nearby).

### 9. AdCP Media Buy
This is the execution engine of the MCP server. It allows agents to construct and submit programmatic bids, lock in guaranteed inventory deals, execute real-time non-guaranteed buys, and negotiate pricing floors based on current market demand and network density.

### 10. Billing Tools
Billing tools manage the financial clearinghouse layer. Agents can check account balances, query active credit lines, retrieve invoices, and allocate specific budget pools to individual sub-campaigns, ensuring strict adherence to financial constraints.

### 11. Attribution Tools
Attribution tools interface with third-party mobile location data and foot traffic attribution partners. They allow the agent to measure the physical lift associated with a DOOH campaign, analyzing whether mobile devices exposed to a screen later visited a retail location.

### 12. Novel Signals
This category exposes emerging real-world data sources, such as localized air quality indices, hyper-local acoustic noise levels, and regional traffic congestion indexes. Agents can leverage these signals to dynamically adjust creative copy or bidding weightings.

### 13. Content Intelligence
Content intelligence tools analyze and validate creative assets. When an agent submits an ad creative, these tools parse the image or video file to verify compliance with local venue restrictions, ensure text readability from distance thresholds, and classify the visual theme of the creative for appropriate contextual placement.

### 14. Discovery Tools
Discovery tools help the agent navigate the MCP server itself. If an agent is unsure which tools are best suited for a specific objective (such as maximizing exposure during a rainstorm), it can query the discovery category to retrieve recommended tool combinations, orchestration recipes, and dependency maps.

## Programmatic Workflows and Integration Mechanics

To understand how these tools operate in practice, we can walk through a typical programmatic buying workflow executed by an autonomous LLM agent. In this scenario, the agent is tasked with executing a localized campaign targeting transit hubs during active rainstorms, using a predefined budget and strict CPM constraints.

First, the agent initializes the connection and queries the discovery tools to identify how to read weather signals and purchase inventory. It identifies `adcp_signals/get_weather` and `adcp_media_buy/submit_bid` as the appropriate tools.

Next, the agent queries active transit screens experiencing rainstorms within the target metropolitan area:

```json
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
"name": "adcp_signals/query_by_condition",
"arguments": {
"weather_condition": "rain",
"precipitation_intensity_threshold": 0.5,
"metro_area": "New York"
}
}
}
```

The server returns a list of active screens currently experiencing rain, along with their real-time impression multipliers. Armed with this context, the agent evaluates the pricing floors and historical performance of these locations. It determines that a specific subset of street furniture screens offers the highest density of target impressions.

To ensure optimal delivery, the agent checks the billing limits using `billing/get_balance` to verify that sufficient funds are allocated. It then calls `adcp_media_buy/submit_bid` to purchase slots on the target screens. The agent structures the bidding payload, targeting a $6.50 CPM floor while dynamically adjusting its bid upward by 15% to account for the increased foot traffic density caused by commuters seeking shelter.

```json
{
"jsonrpc": "2.0",
"id": 4,
"method": "tools/call",
"params": {
"name": "adcp_media_buy/submit_bid",
"arguments": {
"campaign_id": "camp_99281a",
"target_screens": ["scr_88192", "scr_88195", "scr_88201"],
"bid_cpm": 7.48,
"pacing": "accelerated",
"creative_id": "crt_rain_creative_v2"
}
}
}
```

Once the bid is accepted and the creative is scheduled, the agent registers a webhook using `webhook/register` to monitor delivery performance. It requests to be notified if the delivery rate falls below a specific threshold, allowing it to dynamically shift budget to alternative screens if local traffic patterns change.

This entire orchestration loop occurs in seconds, driven entirely by the agent's cognitive reasoning and the structured tool schemas exposed by the MCP server. There is no human middleware, no manual configuration of DSP line items, and no hardcoded API client maintenance.

## Performance and Real-World Telemetry

During our testing phase for the May 2026 release, we monitored the operational efficiency of agents utilizing the MCP server compared to traditional programmatic buying integrations. The results highlight the stability and viability of schema-driven execution in high-throughput adtech environments.

Our network telemetry observed transactions across 18,450 screens participating in the initial MCP deployment phase. The autonomous agents managing these campaigns achieved an average 82% fill rate across participating locations, demonstrating that LLMs can make highly efficient inventory allocation decisions when provided with structured, real-time contextual tools.

The programmatic bidding engine successfully maintained a strict $4.50 CPM floor during peak traffic hours, automatically adjusting bids based on real-time environmental signals (such as localized transit delays and weather events). Throughout the observation period, our servers successfully processed over 145,000 impressions within a single test cluster, handling up to 12,800 requests per minute without experiencing protocol degradation or timeout failures.

This performance is largely attributable to the efficiency of the `streamable-http` transport layer. By utilizing persistent connection pooling and chunked JSON-RPC streaming, we minimize the overhead associated with establishing new TCP connections for every tool execution. This allows agents to maintain a continuous, low-latency loop of inquiry and execution.

## Security, Sandboxing, and Multi-SSP Routing

Exposing physical infrastructure to autonomous AI agents introduces unique security and operational challenges. A malfunctioning or poorly optimized agent could theoretically flood the network with rapid-fire tool calls, execute erratic bidding strategies, or submit non-compliant creative assets. To mitigate these risks, our MCP implementation incorporates multiple layers of sandboxing, rate limiting, and verification.

### 1. Granular API Key Scoping
Every MCP connection is bound to an API key that defines strict role-based access controls (RBAC). An agent configured for inventory discovery is restricted to read-only tool categories (such as `inventory`, `device`, and `analytics`). It is cryptographically blocked from executing tools in the `adcp_media_buy` or `billing` categories. This prevents privilege escalation and ensures that agents operate strictly within their designated functional boundaries.

### 2. Transactional Sandboxing and Dry-Runs
All tools in the `adcp_media_buy` category support a `dry_run` parameter. When enabled, this allows the agent to simulate the entire buying process—including bidding validation, creative compliance checks, and budget allocation—without executing a financial transaction or scheduling actual physical screen time. This enables developers to test agent logic, prompt engineering, and orchestration strategies in a safe, non-billing environment.

### 3. Automated Content Guardrails
Before any creative asset is deployed to a physical screen via the `adcp_media_buy` tools, it must pass through our automated content intelligence pipeline. The `content-intelligence/verify_compliance` tool automatically scans the creative for visual compliance, local venue restrictions (e.g., alcohol advertising restrictions near schools), and technical specifications. If a creative fails verification, the tool call returns a structured error payload detailing the exact compliance failure, allowing the agent to select an alternative asset or log the issue for human review.

### 4. Multi-SSP Routing and Demand Waterfall Management
Our MCP server acts as an orchestration layer on top of a complex, multi-SSP routing engine. When an agent submits a bid via `adcp_media_buy/submit_bid`, the server does not simply execute a static database write. Instead, it evaluates the bid against the active demand waterfall, routing the request to the optimal supply path based on inventory availability, network latency, and clearing price efficiency. This abstraction allows the agent to focus on high-level strategic objectives (such as targeting specific audience demographics) while our underlying infrastructure handles the complexities of real-time exchange bidding.

## Integrating Trillboards MCP with Agentic Frameworks

Integrating our MCP server into existing agentic workflows is straightforward. Because we adhere strictly to the Model Context Protocol specification, developers do not need to write custom integration code for supported clients.

For example, to configure Claude Desktop to use our MCP server, developers can add the following configuration block to their local `claude_desktop_config.json` file:

```json
{
"mcpServers": {
"trillboards-dooh": {
"command": "npx",
"args": [
"-y",
"@trillboards/mcp-bridge-client",
"--endpoint",
"https://api.trillboards.com/mcp/v1",
"--auth-token",
"YOUR_SECURE_API_TOKEN"
]
"env": {
"PROTOCOL_VERSION": "2025-11-25",
"TRANSPORT_TYPE": "streamable-http"
}
}
}
}
```

For custom node-based or python-based agent frameworks (such as LangChain, AutoGen, or custom LangGraph implementations), developers can utilize our published SDK packages. We have published 13 SDK packages across multiple programming languages and environments, providing native bindings for connection management, JSON-RPC serialization, and automatic tool schema generation.

By deploying these SDKs, developers can instantiate an MCP client, establish a connection to our streamable-HTTP gateway, and automatically register all 74 tools into their agent's execution loop in fewer than ten lines of code.

## The Path Forward: AI-Native Out-of-Home Infrastructure

By shipping the first DOOH MCP server, we are establishing a new standard for how physical advertising inventory is managed, analyzed, and purchased. Moving away from rigid, human-configured dashboards and static API integrations toward dynamic, schema-driven tool execution allows adtech developers to build highly responsive, intelligent systems that treat physical screens as easily queryable, context-aware endpoints.

As the programmatic ecosystem continues to adapt to LLM-driven workflows, the integration of real-world signals with autonomous buying tools will become a key differentiator for demand partners and media owners alike. By exposing our inventory, audience metrics, and buying pipelines through the Model Context Protocol, we ensure that our network remains fully accessible to the next generation of programmatic buyers: autonomous cognitive agents.

## FAQ

### How does the MCP server authenticate LLM agent requests?

Authentication is handled via secure, bearer-token authorization headers transmitted during the initial HTTP handshake. When the client establishes the `streamable-http` connection to `api.trillboards.com/mcp`, it passes a cryptographically signed API token. This token is bound to specific role-based access control (RBAC) policies on our backend. The server validates the token and dynamically filters the tool list returned by `tools/list` to match the client's authorized scopes. If an agent attempts to execute an unauthorized tool, the server returns a standard JSON-RPC error payload with an access denied code, preventing unauthorized execution of media buys or billing modifications.

### Why did you choose streamable-HTTP over standard stdio transport?

While standard `stdio` (standard input/output) transport is highly effective for local development environments where the LLM client and the MCP server run on the same physical machine, it is unsuitable for distributed, cloud-scale adtech operations. Programmatic DOOH requires real-time access to centralized databases, global inventory indexes, and real-time bidding engines. By implementing a custom `streamable-http` transport layer, we allow clients to securely connect to our centralized MCP server over the internet. This approach combines the ease of standard HTTP networking with the real-time streaming capabilities of Server-Sent Events (SSE), enabling bidirectional communication, low-latency telemetry updates, and seamless tool execution without requiring local installation of our core database engines.

### How do the 74 tools map to traditional OpenRTB standards?

Our MCP tools act as a translation and orchestration layer on top of traditional OpenRTB 2.5 and 3.0 protocols. When an agent calls a tool like `adcp_media_buy/submit_bid`, the MCP server processes the high-level JSON schema arguments, validates them against our internal compliance rules, and translates the intent into a standardized OpenRTB bid request or direct programmatic deal structure. Similarly, incoming inventory data from various SSP partners is mapped from diverse, nested JSON formats into clean, standardized tool outputs (such as those returned by `inventory/query`). This allows autonomous agents to operate using intuitive, semantic schemas while maintaining full compatibility with legacy programmatic exchanges and demand waterfalls.