What is an MCP server, and what does it do for an ad account?

What is an MCP server?

An MCP server is a program that offers tools to an AI assistant through the Model Context Protocol, an open standard Anthropic published in November 2024. The assistant is the client. It asks the server which tools exist, reads each tool’s description and arguments, and calls the ones that answer your question. The server does the work and sends back the result.

Before MCP, every assistant needed its own plugin format for every system it talked to. With MCP, one server works in every client that speaks the protocol: Claude, ChatGPT, Cursor, VS Code, Codex, Gemini and a growing list of others. Write the connector once and any of them can use it.

What does an MCP server do for an ad account?

It turns the ad platform’s API into tools an assistant can pick from by reading their descriptions. You ask “which search terms spent money last month and never converted?”. The assistant finds the tool that pulls search terms, calls it with your account id and the date range, and reads the rows back to you as an answer.

A server for advertising usually carries three kinds of tool:

• Reads. Performance by campaign, ad group, keyword or ad; search terms; audience breakdowns; account structure. They change nothing.
• Lookups. They turn free text into the ids a platform accepts: a city name into a location id, “marketing directors” into a job-title id, an interest into an audience id.
• Writes. Create a campaign, change a budget, add negative keywords, pause an ad. These are the tools that can cost money, and they are where servers differ most.

How is an MCP server different from an API or a script?

All three reach the same platform API. They differ in who decides what to call, and when.

The last cell is the one that matters. A script does exactly what its code says. An assistant decides at run time, so the safety of a write depends on what the server allows, not on how carefully the assistant was asked.

Local and remote MCP servers

A local server runs on your computer as a process the assistant starts, and it usually holds your platform credentials in a config file. A remote server runs on the web and the assistant connects to a URL over Streamable HTTP, signing in with OAuth. Remote servers work in chat apps such as Claude and ChatGPT, which cannot start a process on your machine; local servers only work in desktop and terminal clients.

For an ad account, the practical difference is where the platform token lives. On a local server it is on your disk. On a remote one it is on the provider’s side, and the question becomes whether it ever travels to the assistant.

Eight checks before you connect one to an ad account

These hold for any server, whoever wrote it. Each one is something you can confirm from the documentation or from a single test call on a small account.

1. Does a write show you what will change before it runs? You want the exact fields, the old and new values, and the account they belong to. “Updating budget” is not a preview.
2. Who approves it? Your click, or the model deciding you meant yes. The assistant’s own permission prompt is a start, but it shows tool arguments, not consequences.
3. Are new campaigns created paused? A create that goes live on approval can spend before you have looked at it in the platform.
4. Can it delete? Pausing can be undone and deleting cannot. A server that maps “stop this campaign” to delete will one day delete the wrong one.
5. What unit is money in? Google Ads stores budgets in micros, a millionth of the currency unit. A tool that takes micros and a model that writes dollars is a budget a million times too large. The tool boundary should take the number you would type yourself.
6. Does it run a write exactly once? Assistants retry when a call times out. If the first attempt succeeded, a retry without an idempotency key creates a second campaign.
7. Does it read the result back? Platforms silently round, clamp and default values. A server that reports what it sent, not what the platform stored, tells you what you asked for.
8. Where does the platform token go? It should stay on the server, encrypted, and never appear in a tool result, a log or the conversation.

What to ask first

Start with reads. They cost nothing, change nothing, and show you quickly whether the server returns numbers you recognise. Three questions cover most accounts:

• How did each campaign do in the last 30 days, against the 30 before?
• Which search terms spent money and never converted?
• Which ads have the highest frequency and the worst cost per result?

Compare the answers with the platform’s own reports for the same dates. If the figures match, move on to a small write.

Where Adako fits

Adako is a remote MCP server for Google Ads, Meta Ads, ChatGPT Ads and LinkedIn Ads, built around the checklist above. Every write comes back as a proposal with a field-level diff and waits for your approval. New campaigns are created paused. No tool deletes a campaign. Money is a decimal in the account currency, each approved change runs once, and Adako reads the object back from the platform afterwards. Platform tokens stay encrypted on the server and never reach the assistant. Reads are free on every plan.

See which assistants and ad platforms it connects, or start with the Google Ads page if that is where your budget goes.

The short version

• An MCP server offers tools to an AI assistant through an open protocol.
• For ads, those tools are reads, lookups and writes. The writes are where servers differ.
• Before connecting one, check for previews, your own approval, paused creates, no deletes, money in the account currency, single execution, read-back and token handling.
• Start with reads on a small account and compare them with the platform’s reports.