MCP Permissions: Read-Only vs Read-Write for Ads and Stores

To scope MCP permissions safely, connect every ad account and store read-only first, grant only the narrowest access the platform allows, and add write access later for one specific task. That sounds simple, but the details differ by platform. Some servers are read-only because of how they are built, others because of what you approve at sign-in, and a few are not read-only at all.

This guide is for merchants and agencies using MCP (Model Context Protocol), the open protocol that lets AI assistants such as Claude connect to external tools and data. It explains the layers where permissions are set, how to apply least privilege step by step, and what can go wrong.

What is the difference between read-only and read-write MCP access?

Read-only MCP access lets an assistant look at data: campaign reports, product catalogs, order lists. It cannot change anything. Read-write access also lets it act: create or edit campaigns, change budgets, update products, adjust inventory.

The difference matters because an AI assistant can misread a request, follow instructions hidden in data it reads (called prompt injection), or simply act on a wrong assumption. With read-only access, the worst outcome is a bad answer. With write access, the worst outcome is a changed budget or a live ad you did not intend.

Read-only MCP is the right default for audits, reporting and analysis, which is most of what teams do first.

Where are MCP permissions actually set?

There is no single permission switch. Access is limited at three separate layers, and you should know which one you are relying on.

1. The sign-in scope. When you connect, you sign in with OAuth (the standard "sign in with your account" flow) and approve a set of permissions, called scopes. The credential is then limited to those scopes.
2. The server's tools. An MCP server exposes a list of tools. If it offers no tool that edits data, the assistant cannot edit data through it, even if the credential could.
3. The client's approval prompts. Apps like Claude can ask you to confirm tool calls. This is a useful safety net, but it depends on a person paying attention and is not a security boundary on its own.

The strongest setup restricts the credential itself. A tool-level restriction is weaker, because the same credential could be used elsewhere, for example with the platform's API directly.

What do MCP OAuth scopes look like in practice?

The MCP specification requires servers that protect data to use OAuth 2.1 and to tell the client which authorization server to use and which scopes are supported. The specification does not define scope names. Each vendor decides. Generic tutorials show coarse examples such as mcp:tools, which say nothing about reading versus writing.

So you cannot assume a "read" scope exists. You have to check what each platform offers. The Cloud Security Alliance's draft guidance recommends defining scopes per tool, not per server, following least privilege. That is a recommendation for server builders, not something you can count on from every server.

The draft authorization text also describes servers asking for extra scopes only when needed, so a connection can start read-only and step up later. Because that text was from the draft specification, confirm it against the current released version at modelcontextprotocol.io before relying on it.

Platform	Official MCP server	Write ability	Where read-only comes from
Google Ads	Open-source, self-hosted	Read-only reporting in the current release	Tool design. Reportedly one OAuth scope (adwords) covers reads and changes, so the credential is not limited
Meta Ads	Hosted, open beta	Reported to include write access	Sign-in choices. A third-party guide describes read-only, read and write, and financial tiers
Shopify Storefront MCP	Per-store endpoint	Read-oriented, with cart operations	Limited to storefront functions
Shopify Dev MCP	Developer tool	None, no live store data	Covers documentation and API references only

Treat the Google and Meta details as things to verify. Several come from secondary sources, and both products have changed during their beta periods.

How to set up least privilege MCP access, step by step

Prerequisites: admin or equivalent access to the account, a list of the tasks you actually want the assistant to do, and a separate login or user role you can revoke without affecting anyone else.

1. Write down the job. For example: "Pull last 30 days of campaign spend and flag wasted spend." If the job is reporting, no write access is needed.
2. Create a dedicated user or app. Do not connect with the owner login. Use a separate user, system user or custom app with a clear name, so you can see its activity and remove it quickly.
3. Set the narrowest role in the platform. In Google Ads or Meta Business settings, give that user read-only or analyst-level access to only the accounts needed. A role limit applies even if the MCP scope is broad. Check each platform's help pages for current role names.
4. Choose the lowest scope at sign-in. On Meta, if the sign-in dialog offers a read-only tier, pick it. Confirm the options in Meta's Business Help Center, since the tier names we found came from a third party. On Shopify, create a custom app and select only the read access scopes you need, such as products or orders, as listed in the Admin API documentation at shopify.dev.
5. Review what the server exposes. Open the tool list in your client. If you see tools for creating, updating or deleting, and you do not want them, use a different server or a different scope.
6. Test with a harmless question. Ask for a report, then ask the assistant to change something trivial and confirm it fails or asks for approval. Do this on a test account where possible.
7. Keep approval prompts on. Do not enable "always allow" for any tool that writes.
8. Review and rotate. Check connected apps monthly and remove those no longer used.

How does this apply to Google Ads?

Google's official server is read-only in its current release, built around reporting queries. That is useful as a safe starting point. The catch, reported by a secondary source and worth verifying in Google's OAuth documentation and the server's code, is that Google's OAuth lists a single Ads scope that covers both reports and changes. If that is right, the server is read-only because it offers no write tools, not because the credential is restricted.

In practice: use a user with read-only access to the account in Google Ads itself, and store the credentials carefully, because anyone holding them could use the API directly. Our guide on connecting Claude to Google Ads covers setup in more detail.

How does this apply to Meta Ads?

Meta's official connector is different. Meta's permissions reference describes the ads_mcp_management permission as covering creating and managing campaigns, retrieving insights, and managing catalogs, ad accounts and pixels. A related permission, ads_management, allows reading and managing an ad account.

One reported guardrail is that created campaigns, ad sets and ads arrive paused. A tester noted that the documentation does not limit the update tool to paused ads, so editing a live ad may not be covered by that guardrail. Do not assume a pause will protect a running campaign.

Agencies managing other businesses' accounts reportedly need App Review and Advanced Access for ads_mcp_management. Confirm current requirements in Meta's Business Help Center and developer documentation. Our article on Meta Ads MCP walks through the connection itself.

How does this apply to a Shopify store?

Shopify's scopes are the boundary. Admin API access is granted per resource, with separate read and write variants, so a custom app can be set to read products and orders without any write scope. Check the current scope list at shopify.dev.

The official Storefront MCP is aimed at shoppers' tasks like product search, cart and policy questions, and the Dev MCP covers documentation, not live store data. Access to orders, customers and inventory has been reported to come mainly from community servers. Review any such server's code and maintainers before giving it credentials. See Connect Claude to Shopify: The Complete Step-by-Step Guide for details.

What can go wrong with MCP permissions?

• Assuming "read-only" is enforced by the credential. It may only be a feature of the server. Use platform roles as a second layer.
• Connecting with an owner or admin login. The assistant inherits everything that login can do.
• Granting write access "just in case." Scopes tend to stay in place long after the task ends.
• Trusting approval prompts alone. People click through repetitive prompts. Combine them with restricted scopes.
• Forgetting financial access. On ad platforms, billing and spend changes deserve the strictest rule: no access for assistants.
• Third-party hosted connectors. They may offer write access but also mean a third party holds your tokens. Review their terms and security.
• Stale information. MCP servers and their scopes are changing quickly. Re-check vendor documentation before each new connection.

When is read-write MCP access reasonable?

Consider write access when the task is repetitive, the change is easy to reverse, and a person reviews the result. Examples include drafting paused campaigns, updating product descriptions in a test collection, or adding negative keywords from a reviewed list.

Keep a human in the loop for budgets, bids, live ad edits, price changes, refunds and anything affecting customers. Grant write access for a defined period, then switch back to read-only. For a broader checklist, see MCP Security: Is MCP Safe for Your Store? A Merchant Checklist.