Trillboards DOOH Advertising

create_media_buy

[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" })

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_media_buy"
  }
}

Input Schema

Name	Required	Description
`name`	No	Media buy name
`brand`	No	Brand reference
`context`	No
`buy_spec`	No	Buy specification (legacy)
`creative`	No
`end_time`	No	ISO 8601 end time
`packages`	No	AdCP product packages to buy
`buyer_ref`	No	External reference ID from the buyer/agency
`start_time`	No	ISO 8601 start time
`total_budget`	No
`idempotency_key`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 30, 2026
- addedInput schema / properties / creative / properties / height
```
Added value: +{
+  "exclusiveMinimum": 0,
+  "type": "number"
+}
```
- addedInput schema / properties / creative / properties / width
```
Added value: +{
+  "exclusiveMinimum": 0,
+  "type": "number"
+}
```
First observedOct 20, 2026

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden: it discloses the returned identifiers and creative_deadline, which is useful. However, for a spend-creating mutation it omits permission/auth requirements, what happens to budget on failure, whether the operation is retried/idempotent (an idempotency_key exists but is never explained), and reversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-organized and front-loaded with a clear purpose sentence, then WHEN TO USE, RETURNS, and EXAMPLE headers, so an agent can scan it quickly. The example is long but demonstrates actual invocation, so it largely earns its space; a touch verbose but not wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter nested tool with no annotations and no output schema, the description compensates well by enumerating return fields and walking through a full example. The remaining gaps are the legacy-vs-packages buying path and idempotency/permission behavior, which an agent would still need.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 64% and the example adds real meaning for the buy_spec/creative path (venue_types, geo, budget, schedule, creative type). But it never explains the relationship between buy_spec (marked legacy in the schema) and packages, nor idempotency_key, brand, or total_budget, leaving several parameters undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: creates a media buy (campaign) from an AdCP buy specification targeting DOOH screens, and returns a media_buy_id. This distinguishes it from update_media_buy, but it does not address the sibling create_campaign or explain how the two create paths differ, leaving some ambiguity for an agent choosing between them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The explicit WHEN TO USE section names three concrete scenarios (executing a programmatic DOOH buy, DSP trading desk agents, automated buying workflows), which is strong positive guidance. There is no when-not-to-use or explicit routing away from create_campaign/create_experiment, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Trillboards DOOH Advertising tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?