Skip to content
T1KTheOneKit

ad-network-mcp-write-safety

Ad-Network / API MCP Writes — Money-Risk Guardrail

Section titled “Ad-Network / API MCP Writes — Money-Risk Guardrail”

Auto-loaded for marketing work. Any mutating call through an MCP server or external API that touches a live ad network, monetization platform, MMP, or paid service can move real money — change spend, pause revenue, or alter bids/budgets. A wrong write here is not a code bug you can revert; it can burn ad budget or stop a live campaign’s income. Treat every such write as high-risk.

Applies to AdMob, AppLovin MAX, IronSource/LevelPlay, Mintegral, Unity Ads, Meta Audience Network, ad MMPs, and any billing/ads/payments API — via MCP tools or direct HTTP.

Rule

Section titled “Rule”
  1. Default to READ-ONLY. Prefer list_* / get_* / *_report tools. Reach for a write ONLY because the user explicitly asked for that exact change.
  2. Never fire a mutating tool without specific, explicit user confirmation that names: the operation, the target (account / campaign / offer / placement), and the before → after values. A generic “go ahead” is not enough for a spend-affecting change.
  3. Confirm the account/environment first. Verify the credentials point to the intended account and that it’s production vs. a designated test account BEFORE any write.
  4. One change at a time. No bulk or looped mutations without explicit batch approval (see preview-first-batch.md). A loop over a write tool can multiply a mistake across an entire account.
  5. Respect guarded-write gates. If an MCP exposes a confirmation/guard step (the ads-mcp servers do), never bypass it.
  6. Uncertain about spend impact? STOP and ask. If you can’t state how a parameter affects budget/bid/spend, do not send it — errors over silent fallbacks.
  7. Never blindly retry a failed write. A timeout/error may have partially applied; re-read state before retrying.

How to apply

Section titled “How to apply”
  1. Classify the tool. list_/get_/report → safe (read). create/update/set_bid/set_budget/pause/enable/delete → money-risk (write).
  2. For a write, restate to the user and get explicit go-ahead: operation + account + entity + old→new value + expected money impact.
  3. Verify the target account/credentials.
  4. Execute one op, capture the response, and report exactly what changed.

Exceptions

Section titled “Exceptions”
  • Pure read/report tools — proceed normally, no extra confirmation.
  • A sandbox/test account the user has explicitly designated as safe for writes.
Section titled “Related”
  • ai-driven-design.md — § “Side-effects with safety constraints” (writes gated behind explicit approval)
  • preview-first-batch.md — smoke-test + confirm before any bulk operation
  • development-principles.md — § “Errors Over Silent Fallbacks”
  • Skill t1k-marketing-monetization-mintegral — its planned phase-2 tools (pause_offer, update_bid) are exactly this risk class