DV360 MCP server: Display & Video 360 from Claude or Codex
DV360 is where an MCP server's engineering shows. Its reporting is asynchronous and slow enough that a tool written for a synchronous API simply times out, and the platform is usually absent from community MCP servers for exactly that reason.
What already exists for this platform
Google has not shipped a platform-official DV360 MCP server at the time of writing (September 2026), and DV360 is frequently missing even from multi-platform community servers.
- No official server, and thin community coverage.
- Bid Manager reports are asynchronous — request, poll, collect. A poll can run the better part of a minute.
- That latency has consequences beyond one call: anything evaluating many rules in sequence under a shared time budget can be starved by two slow DV360 reports.
What a full MCP server adds
| Typical option today | Agent Planners MCP | |
|---|---|---|
| DV360 tools | Usually absent | 6 reads, 4 writes |
| Async report handling | Rarely implemented | Polled, with a per-fetch timeout |
| Line item / IO changes | Rare | Available, approval-gated |
| Threshold alerts | No | Yes, with slow platforms evaluated last |
| CM360 in the same session | No | Yes |
How to configure it
- 1Create a key in API & MCP. `tools:read` for questions; add `tools:write` if the agent should be able to change things. Tools mode needs a paid plan and fails closed.
- 2Connect DV360 under Integrations — that OAuth step is why the MCP key never carries platform credentials.
- 3Add the server to Claude Code, Claude Desktop or Codex using the snippet below.
- 4Have the agent call `describe_permissions` first — it reports the key's mode, scopes, plan entitlement and connected accounts.
- 5Call `list_accounts` for the account ids, and scope each call with one. Resolution is exact or it refuses, naming the candidates.
claude mcp add --transport http agentplanners https://www.agentplanners.com/api/mcp \
--header "Authorization: Bearer ap_live_…"Claude Desktop and Codex
Claude Desktop takes the same endpoint as JSON:
{
"mcpServers": {
"agentplanners": {
"url": "https://www.agentplanners.com/api/mcp",
"headers": {
"Authorization": "Bearer ap_live_…"
}
}
}
}The latency problem, and why the fix belongs to the loop
A Bid Manager report can poll for around 54 seconds; a CM360 report up to roughly 110. For a single question that is merely slow. For a system evaluating alert rules one after another under one shared budget with no per-rule timeout, it is a starvation bug: two slow reports delay every rule queued behind them.
The instinct is to exclude the slow platforms. The better fix is to bound each fetch and evaluate the slow, report-based platforms last — because a hung read on any platform is the same hazard, and fixing the loop makes the two platforms safe to include rather than an exception to argue about.
Use cases
- Reach and frequency planning alongside the Google Ads and Meta accounts buying the same audience.
- Line item performance review with the changes proposed and approved.
- Cross-platform budget comparison where DV360 is one option among several, which is the decision it cannot make about itself.
- Threshold alerts on DV360 metrics, now that the loop can carry a slow platform without starving the fast ones.
Frequently asked questions
- Is there an official DV360 MCP server?
- Not from Google at the time of writing (September 2026), and DV360 is often missing from multi-platform community servers too — largely because its reporting is asynchronous and awkward to wrap.
- Why are DV360 reports slow over MCP?
- Bid Manager reporting is asynchronous: the report is requested, then polled, and a poll can run around 54 seconds. A tool written for a synchronous API times out rather than waiting correctly.
- Can I set alerts on DV360 metrics?
- Yes. That required bounding each alert fetch with its own timeout and evaluating report-based platforms last, so a slow DV360 report can only delay other slow reports.