TL;DR
| Question | Answer |
|---|---|
| What is the risk? | Write tools loaded without anyone noticing. |
| Where does it hide? | Tool lists nobody reads, flags nobody questions. |
| Who has thought hardest? | PPC practitioners, because their agents spend money. |
| The consensus | Read everywhere. Write nowhere without approval. |
| The pattern that works | Dry run, human review, then execute. |
| First action | List your loaded tools and read the names. |
Ask your AI client to list the tools it currently has available. Most people have never done this, and the list is usually longer than they expect.
Somewhere in there, depending on which servers you connected, are tools that do not read anything. They pause campaigns, adjust budgets, update records, or send messages. They loaded at the same moment the read tools did, with the same single authorization.
The marketing side of the MCP ecosystem has quietly shipped a lot of write capability. Almost nobody audits it.
What write access means in an MCP context
An MCP server exposes a set of tools to an AI client. Each tool is a function the model can call. Read tools fetch data. Write tools change something in the connected system.
The protocol does not enforce a separation. A single server can expose both, and your client loads whatever the server offers. If you authorized the connection, you authorized every tool in it.
That is the gap. People evaluate MCP servers on what they can answer. The install grants what they can do. For the fundamentals of how these connections work, see what MCP is.
The PPC community got here first
Nobody thinks about this harder than people whose agents can spend a client's money.
The most-engaged thread we found on the subject, with 80 points and 80 comments, was a practitioner describing how they use Claude Code and Codex to manage Google and Meta Ads rather than just report on them.
The top comment drew the line in seven words. "Claude should be used as an analyst, not as a buyer role."
A practitioner running more than 110 accounts gave the most operational version of the same rule. "Write access is where the boring engineering matters. Read everywhere, write nowhere without the staged approval."
Their follow-up identified where the real friction sits, and it is not technical. "Most of the friction isn't technical, it's getting alignment between the client, their CRM, and their legal team on what data can actually flow back to Ads."
Another commenter added a platform risk most teams have not considered. Sustained programmatic mutation patterns "can escalate into temporary account restrictions." The failure is not only a bad edit. It is the account itself getting flagged.
![]()
Why analysis is the safe half
The same thread's author was candid about accuracy in a way most vendor content is not. "Big minus: hallucinations. If you just ask it 'what happened in this account?' it will 100% invent the answer. The only way I trust it is when it runs scripts and saves outputs."
Read that alongside the write question. If a confident wrong answer is a known failure mode, an agent that can act on its own confident wrong answer is a different category of problem.
A read-only mistake costs you a bad slide. A write mistake costs you a campaign, and possibly a client. We covered why the wrong answers are hard to spot in why your GA4 MCP server returns confident, wrong numbers.
Another commenter summarized where the category actually is. "The real bottleneck isn't analysis anymore, it's trust and guardrails."
The dry run pattern
The pattern practitioners keep independently arriving at already exists in every ad platform. Bulk editors have shown you a preview before applying changes for years.
In a thread on using the Ads API with Claude Code or Codex with 30 points, the advice was explicit. "Write operations need more care. I'd recommend always building a dry-run/preview step before any mutation goes live."
The same commenter noted a useful safety rail that already exists on Google's side. New API access starts at a restricted level that permits production calls under daily operation limits, which caps the blast radius while you learn.
In a separate thread on what people have built for PPC with AI, the 110-account practitioner repeated the rule in its shortest form. "Most important part is human review before any gets pushed into an account."
Three stages, in order.
| Stage | What happens | Who acts |
|---|---|---|
| Propose | Agent produces the intended change set | Agent |
| Review | Change set is inspected in readable form | Human |
| Execute | Approved changes only are applied | System |
The value of separating these is that the agent still does the analysis and the drafting. You only insert a human at the moment of consequence.
How to audit what you have connected
This takes about ten minutes and most teams have never done it.
- List your loaded tools. Ask your client to enumerate every available tool with its description. Do this per project or profile, because configurations drift.
- Sort by verb. Anything named create, update, delete, pause, send, adjust, or set is a write operation. Anything named get, list, query, search, or report is not.
- Check for flags. Some community servers gate destructive operations behind an environment variable. Read your configuration and confirm which state you are in, rather than which state you assume.
- Read the scopes you granted. The OAuth consent screen listed them. Most people click through. Go back and check whether you granted write scope to a source you only ever read from.
- Count your servers. Every connected server is surface area. If you are not using one, disconnect it. This also improves answer quality, for reasons we covered in what 30 Reddit threads reveal about connecting marketing data to AI.
- Decide per source, not globally. Read on Search Console is a different risk from write on Meta Ads. Treat them differently.
If you manage client accounts, do this before your next audit rather than after.
Read-only is a design decision, not a limitation
There is a version of this argument that treats read-only as training wheels. It is not.
Almost every question marketing teams actually want answered is a read. Which pages lost impressions. Which campaign drove qualified pipeline. Where did CAC move and why. None of these require the ability to change anything.
Execution is a separate product decision with a separate risk profile, and bundling the two by default serves the vendor more than the user.
An analyst in an r/GoogleAnalytics thread framed the underlying preference well. "I'd rather data analysis be right and be auditable as being right." Auditability, not autonomy, is what practitioners keep asking for.
![]()
The client data question sits alongside this
Write access is one half of the trust problem. Where your data goes is the other.
When someone posted a GA4 analysis tool to r/GoogleAnalytics, the objection was not about capability. "There's absolutely no way I could grant third party access to work data unless they were contracted and legally bound to confidentiality and security rules. I'm guessing I could be fired for it and if I'm honest, I think I'd probably deserve it."
For agencies, both questions get asked in the same meeting. What can it change, and where does the data go. A tool that answers only one of them does not clear the bar. Our position on both is in MCP security and governance and how to securely connect your data to AI agents.
How Sequel handles this
Sequel is read-only by default across every connected source. It reads from your databases, warehouses, and SaaS tools and returns results as conversation context. An agent investigating an ad account or a property cannot alter it.
Every query and API call is shown before execution, so you review the operation rather than trusting the summary. That is the same auditability principle the threads above keep asking for, applied to reads rather than writes.
Sources connect once into a workspace, and adding another AI tool is a permission grant rather than a new set of credentials handed to a new server. Team workspaces mean access is managed centrally instead of per person, which matters when someone leaves.
For the setup path, see how to query your database with AI using MCP or the Sequel MCP server guide. For the wider category argument, AI agents for marketing analytics covers where this fits.
Go list your tools
You probably have more capability connected than you intended, and finding out takes ten minutes.
Run the audit above, disconnect what you are not using, and decide write access deliberately rather than by default. Get started free if you would rather start from read-only and add from there.
