What an MCP server exposes, and what it should not
An MCP server wired to Google Ads exposes tools, read campaigns, query metrics, change a bid, pause an ad. The model chooses which to call and with what arguments.
The first decision, before any code, is to strictly separate read from write. A read-only server already enables the essentials, analysis, diagnosis, recommendations, with no risk of damage. It is the sensible starting point in almost every case.
Write tools, if any, must be granular. A generic tool accepting an arbitrary query hands the model unlimited power over the account. A tool that does one precise thing, with bounded arguments, is verifiable.
Tool naming and descriptions matter as much as their code: that is what the model decides on. An ambiguous description produces calls at the wrong moment, the leading cause of incidents, and it is editorial, not technical.
The guardrails that must live in code
Dry-run first. Every mutating action must be runnable in simulation, reporting what it would have done. Without it, you cannot evaluate the system's behaviour before exposing it to a real budget.
Hard ceilings. Maximum bid change, maximum amount committed, actions per run. These belong to the executing code, never to the instruction given to the model: a natural-language directive is not a security mechanism, it can be overridden by context.
Human validation on the irreversible. Pausing an active campaign or changing a monthly budget deserves explicit confirmation. Time saved never offsets a mistake on a live account.
Respecting the learning phase. An agent modifying a campaign still in learning extends that learning and degrades performance. This constraint must be encoded as a blocking rule, not left to the model's judgement.
Full logging. Every call, every argument, every result. Without a trail, aberrant behaviour cannot be explained afterwards, and therefore cannot be fixed.
Token cost, consistently underestimated
Advertising data is bulky. A query returning three hundred rows of metrics puts those three hundred rows into the model's context, and that context is re-billed on every subsequent turn.
This is the structural trap of any agent: cost does not grow linearly with step count. An analysis taking ten tool calls costs far more than ten times one call, because the tenth carries the whole history of the previous nine.
The concrete levers: aggregate server-side rather than returning raw rows, always cap result counts, return identifiers rather than full objects when detail is unnecessary, and limit iterations per run.
A server returning verbose responses produces an invoice you only notice at month end.
The mistakes that cost most
Granting admin access "to keep it simple". The server's access scope becomes the scope of possible damage. A dedicated service account with minimal rights costs ten minutes of setup and prevents the major incident.
Going to write before validating read. First verify, over time, that the analyses produced are correct. A system that gets it wrong on read will get it wrong on write, but with consequences.
Forgetting returned data is untrusted content. A campaign name or ad text can contain instructions the model reads as orders. That is indirect prompt injection, and an ad account is an entry surface like any other.
Not supervising the supervisor. An agent that goes down does not announce it. Without a regular heartbeat, absence of alerts becomes indistinguishable from everything working.
Frequently asked questions
MCP server or a classic API integration?
If the sequence of actions is known in advance, a classic integration is faster, cheaper and more reliable. MCP earns its place when deciding to act requires judgement, assessing a situation then choosing what to do, not when the action is mechanical.
Can an agent change budgets on its own?
Technically yes, sensibly no without hard ceilings and human validation on the irreversible. The pattern that survives production: the agent analyses and proposes, mutating actions are bounded, logged and reversible.
What does it cost to run in tokens?
Mostly it depends on the volume of data tools return, since it is re-billed every turn. Aggregating server-side and capping results changes the order of magnitude of the bill far more than the choice of model.
What rights should the service account have?
The minimum for the task, and read-only until the write phase is validated. Access scope defines exactly how much damage unexpected behaviour can do.