DV360 MCP server: Display & Video 360 from Claude or Codex

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#

How to configure it#

1. 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.
2. 2Connect DV360 under Integrations — that OAuth step is why the MCP key never carries platform credentials.
3. 3Add the server to Claude Code, Claude Desktop or Codex using the snippet below.
4. 4Have the agent call describe_permissions first — it reports the key's mode, scopes, plan entitlement and connected accounts.
5. 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 agent-plannershttps://www.agentplanners.com/api/mcp \
  --header "Authorization: Bearer ap_live_…"

Claude Desktop and Codex#

Claude Desktop takes the same endpoint as JSON:

{
  "mcpServers": {
    "agent-planners": {
      "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.