AdRails vs trakkr: two ChatGPT Ads MCP servers

Running both is a legitimate configuration: trakkr's hosted endpoint answers reporting questions read-only while AdRails holds the credentials that are allowed to write. See the section below on running both.

• Twenty-seven tools in eight groups. Account, campaigns, ad groups, ads (including creative upload), insights, audiences (including geo search), conversions (manage and send), and workflows — build_campaign, draft_context_hints and bulk_ab_test_hints. vendor page, read 2026-11-06
• Many ways in. npx, uvx, Docker, Claude Desktop, Cursor, Codex and the MCP Registry, plus a hosted Streamable HTTP endpoint that is read-only, and a local package where write tools are opt-in. vendor page, read 2026-11-06
• Read-only by flag. Setting OPENAI_ADS_MCP_READONLY=1 hides the write tools entirely, which makes it usable as a pure reporting client. vendor page, read 2026-11-06
• Creates start paused. New campaigns, ad groups and ads are created paused, so a bad agent draft does not start serving on its own. vendor page, read 2026-11-06
• A budget ceiling you configure. OPENAI_ADS_BUDGET_CEILING_USD defaults to $100 and budget tools reject values above it "unless confirm_budget is true". vendor page, read 2026-11-06
• Key handling as documented. API keys can be supplied per request or through the environment, and the page states it "does not store or log API keys". vendor page, read 2026-11-06
• Approvals, validation, audit, lifetime caps, scheduled guard. Not stated on its page as of 6 Nov 2026; instead the page advises reviewing your MCP client's approval settings. Treat that as a gap in documentation, not proof of absence. vendor page, read 2026-11-06

For a first ChatGPT Ads experiment, trakkr's coverage is hard to beat: you can inspect insights, upload creative, manage audiences and stand up a campaign from a single chat session, with paused creates and a dollar ceiling as the two brakes. The brakes are real, but they are configuration-level — a ceiling value and a client approval prompt — not a governance layer with a signed approval trail.

• Caps in a policy file tools cannot write. Maximum daily and lifetime budget, maximum bid, allowed destination domains, required UTM tags, and no archiving unless allowed. claims ledger O5
• Cumulative spend caps. A cap per campaign and optionally per account, checked alongside the daily budget so a month cannot quietly run past the number you approved. claims ledger O6
• A human approves activation. Activation needs a single-use approval block bound to that campaign, plus a fresh guard heartbeat. An agent can stage everything; it cannot switch delivery on by itself. claims ledger O7, O8
• Room-under-cap maths that assumes 2x delivery. The check assumes the platform may deliver up to twice the daily budget, so normal overdelivery does not silently breach the cap. claims ledger O9
• A pause-only guard. adsops_openai_guard pauses when lifetime spend reaches the pause point (cap minus 2x-overdelivery headroom), when today's spend is anomalous, or when live budgets and bids exceed policy. It never activates or raises anything, also pauses budget raises and uncapped bids made outside AdRails, pauses orphaned campaigns, and fails closed when spend cannot be read. claims ledger O10, O11, O12, O13
• Idempotent creates. Every create carries an Idempotency-Key, so a retry cannot duplicate a campaign or ad. claims ledger O4
• Everything is born paused. New campaigns, ad groups and ads are created paused and stay that way until the approval path clears. claims ledger O3
• Conversion plumbing you can test first. conversions_setup ensures a web pixel and a lead_created event setting exist, and test_event sends one validate-only event, so you can confirm the wire is live before you spend into it. claims ledger O15
• Key hygiene. The API key never appears in tool outputs, the audit chain or the usage meter. claims ledger O16
• Creative and campaign checks before submit. ad_check enforces chat_card limits (title 3-50 characters, body up to 100, https URL up to 2048, 1 or 4-6 images), policy domains, required UTM tags and duplicates; draft_campaign turns a brief into a paused, capped desired state; ab_report gives 95% intervals with Bonferroni-corrected comparisons and recommends pausing only significantly worse ads; send_conversions and audience hash emails, phones and names locally. selftest: qa_openai_ads 160/0

Live verification, exact wording (claim O17): "read paths, live spend reads, the guard and validation ran against a real OpenAI Ads account in read-only mode on 2026-11-06; that live run found and fixed an insights rule the offline mock missed. Creates, image upload, activation and the conversion/audience commits are tested offline but have NOT yet run against a live account."

• Your daily budget is not the ceiling. Platforms can deliver up to twice the daily budget. AdRails' cap check assumes exactly 2x (O9); if your own maths assumes 1x, you are budgeting for a day that will not happen.
• Conversion setup decides what the system learns. If the pixel and the lead_created event are missing or duplicated, spend optimises toward a signal you never verified. AdRails ships a setup step and a validate-only test event for that (O15).
• Activation is the moment money starts moving. In AdRails, activation requires a single-use approval block bound to the campaign and a fresh guard heartbeat (O7, O8) — a staging agent cannot flip the switch, and a stale guard blocks the commit rather than waving it through.
• The guard has to work when the API is unhappy. A guard that shrugs when spend cannot be read is decoration. AdRails' guard fails closed (O13) and pauses budget raises and uncapped bids that were made outside AdRails (O11), including orphaned campaigns (O12).

trakkr covers the two basics that catch most accidents: creates are paused by default, and a budget ceiling rejects explicit values above it unless you override. That is a sensible floor. AdRails is aimed at the layer above it — approvals, cumulative caps and a pause-only guard that keeps working when the agent is not the one calling it.

The two servers do not fight over the account as long as you decide which one writes. A workable split: point reporting and exploration at trakkr, ideally through its hosted read-only endpoint or with OPENAI_ADS_MCP_READONLY=1 set locally, and point the agent that makes changes at AdRails, where every write is a plan with a single-use plan_id and an approval gate for activation.

• Reporting on one side. trakkr's breadth — insights, audiences, conversion tooling, workflow helpers — makes it a good reader and a good drafter. vendor page, read 2026-11-06
• Writes on the other. AdRails holds the key that may change budgets and statuses, with policy caps and a guard that pauses rather than enables. claims ledger O5, O10
• No licence conflict. trakkr is MIT, AdRails is Apache-2.0, and both run locally or as you prefer. vendor page, read 2026-11-06; AdRails release notes

If you only want one server today and you need to do everything — audiences, creative upload, A/B context hints — start with trakkr. If you only want one server and the account has a real budget on it, start with AdRails and accept narrower coverage while keeping a hard stop on spend. Background on the platform itself is at the ChatGPT Ads hub, and the same governance argument for Google's ecosystem is at Google Ads MCP safety.

Both statements come from AdRails' published limits: the 2x delivery assumption is baked into the cap check (claim O9), and the same-OS-user bypass is the open privilege-boundary item in the threat model. Full comparison set at the compare index.