For most teams evaluating ad-account MCP, read-only is the right starting point. It lets an AI retrieve and explain live performance while limiting the blast radius of a bad query, compromised credential, or misunderstood instruction. Write access can be useful in a controlled workflow, but it adds the ability to pause delivery, alter budgets, change targeting, or publish other account mutations. The protocol does not make those actions safe by itself. Google's official Google Ads MCP documentation is a useful concrete example of a read-only platform surface.
A read-only server can discover active workspace integrations reachable through current workspace memberships and enabled per-platform Read permission and retrieve bounded campaign, ad-set, ad, and metric data. An AI can answer questions such as:
“Compare the selected Google Ads and Meta Ads accounts for the last complete month. Keep platform, account, currency, attribution, and date range visible, and list evidence before recommendations.”
That is valuable because the model reasons over current API responses rather than inventing account metrics. Read-only does not mean risk-free: performance, audience, creative, and account metadata can be sensitive, and a leaked token can expose data. But the permission boundary prevents the connection from directly changing campaign state.
Adstudio's public MCP is read-only today and supports Google Ads and Meta Ads. One personal connection can reach every workspace its user belongs to, subject to role-bounded per-platform Read permission; its claim is horizontal understanding across explicitly selected workspace, platform, and account contexts, with provenance—not campaign mutation. The wider product may have separate action workflows, but those must not be attributed to the public MCP tools.
Write-enabled tools can turn “recommend pausing Campaign A” into an API mutation. Depending on the server, that might include pausing or enabling entities, editing budgets and bids, changing keywords, or modifying creative. Those operations can spend money or disrupt delivery before a person notices.
Ask four questions before considering writes:
A “confirm” message in natural language is weaker than a product-level approval gate tied to the exact mutation. If a server cannot show what will change, do not grant write access.
Use a staged workflow:
Stage one: observe. Keep workspace membership and per-platform Read permission role-appropriate, then run list_accounts discovery. Each later call selects its workspace, platform, and account. Ask for source, account ID, date range, currency, and raw fields. Validate the result in the native platform.
Stage two: recommend. Let the AI rank issues, but require it to separate facts from hypotheses. For example:
“Find campaigns with spend and zero conversions in the selected period. Return the rows and thresholds used. Suggest possible actions, but do not call any write tool.”
Stage three: propose. If a controlled write workflow exists, require a structured proposal:
“For the selected account, draft—but do not execute—a proposal to change the daily budget from the current value to the requested value. Include account ID, campaign ID, current state, new state, reason, and validation checks.”
Stage four: approve and verify. A human reviews the exact proposal, approves it in a dedicated control, and checks the platform afterward. Keep logs and record who approved it.
This sequence also exposes data-quality problems before they become action problems.
Before connecting any server, document the OAuth scopes, token storage, retention policy, encryption, tenant isolation, subprocess or hosting model, and revocation process. Confirm whether account selection is explicit and whether the server prevents cross-tenant access. Treat ad names, search terms, comments, and creative text as untrusted third-party input that must not override the user's instructions.
Use a test or low-risk account where possible, set platform-level budget controls, and monitor the first sessions. Keep workspace membership and per-platform Read permission role-appropriate rather than broader than the work requires. For agencies, separate client workspaces or identities where appropriate so one membership change does not expose another client's context.
Read-only access does not reconcile unlike platform definitions. Google and Meta may differ in attribution, freshness, currency, and conversion events. It also does not add support for providers that are not explicitly listed. Adstudio's public MCP currently supports Google Ads and Meta Ads only; do not infer TikTok Ads or other product integrations from the existence of a public connection.
See MCP security, the Google Ads MCP guide, and the Meta Ads MCP guide. If you are setting up a client, use the ChatGPT or Claude workflow.
Read-only MCP covers the highest-confidence use case: asking an AI to inspect and compare live advertising evidence. Write MCP may shorten an action loop, but it demands narrow scopes, structured proposals, human approval, auditability, and post-action verification. If those controls are not clear, stay read-only.