Audit your container, stage the fix, publish it yourself

What your assistant can read and stage

Connected, your assistant works in your Tag Manager containers under your own Google sign-in. AdCopilot's Tag Manager tools number 18 once Tag Manager is connected, 9 that read and 9 that write, as of v2.46.2. They fall into two groups.

• Reads. The accounts your login can reach, the containers in each, a container's workspaces, its saved versions, and in a workspace its tags, triggers, variables, folders and the built-in variables that are switched on.
• Staged writes. It adds or changes a tag, a trigger, a variable or a folder, and it switches on a built-in variable. Every one of them lands in a single workspace named AdCopilot, which it makes inside the container if there is none.

What an audit looks at

An audit here is your assistant reading a workspace and answering for what it finds. The reads return the whole workspace, so these are questions it can answer from the container itself rather than from memory:

• Which tags fire on every page, and which of them should not.
• Which triggers no tag uses, and which tags have no trigger to fire on.
• Which variables a tag reads, and whether the built-in variable it needs is switched on.
• How many tags, triggers and variables each saved version holds, and what each is named.

What comes back is the finding, then the fix staged in the AdCopilot workspace with what it changed and why. You check it in Tag Manager's own workspace view.

Stage a change, then publish it yourself

The line this connector holds is the one Tag Manager draws itself: a workspace holds changes, and a version carries them live. AdCopilot works on the first and has no tool for the second.

1. You ask. AdCopilot proposes the change first, and your AI client asks before it runs if it is set to ask before AdCopilot's write tools, and you allow it.
2. It stages. The tag, trigger, variable or folder appears in the AdCopilot workspace. No write takes a workspace as an input, so it cannot be aimed at your default workspace.
3. You review. Open the workspace in Tag Manager and read its changes, as you would for anyone's.
4. You publish. Create the version and publish it in Tag Manager. Your assistant can list the container's saved versions, with their names and how many tags, triggers and variables each holds. Open Tag Manager's version history for what went live and when.

Pair it with Google Ads conversions

The common job is a conversion that has an action in Google Ads and no tag on the site. With Google Ads and Tag Manager both connected, your assistant creates the conversion action, which returns the ID and label the tag needs, then stages a Google Ads conversion tracking tag with them on the trigger you choose. You publish the version. Nothing is counted until the tag is on the page.

The Analytics side of measurement, key events and the link to Google Ads, is on the GA4 page.

Prompts to try

These only read:

• “List the tags in my main container and the triggers each one fires on.”
• “Which tags fire on every page, and which triggers does no tag use?”
• “What variables does this container define, and which built-in variables are switched on?”
• “List the saved versions of this container and how many tags each has.”

These stage a change, so AdCopilot proposes each one first, your AI client asks before it runs if it is set to ask before AdCopilot's write tools, and nothing goes live until you publish:

• “Set up the Google Ads conversion tag for my thank-you page.”
• “Stage a trigger that fires on the form_submit event.”
• “Add a variable that reads the order value from the data layer.”
• “Create a folder called Conversions in the staged workspace.”

What a hosted Tag Manager MCP server cannot do

A hosted Tag Manager MCP server is a service your assistant calls, so there is nothing to install. Its limits are the point of it:

• Publish. No tool publishes a workspace, and none creates a version. Nothing it does reaches your site until you publish.
• Delete. No tool deletes a tag, a trigger, a variable, a folder or a workspace, and a built-in variable can be switched on but not off.
• Write outside its workspace. Your default workspace and every workspace but AdCopilot's can be read and never written.
• Create an account or a container. It works in containers that already exist.
• Reach what your login cannot open. It runs as you.

How approval works

Nothing changes until you allow it in your AI client — approval is your client's own tool-permission prompt. If you tell your client to always allow a tool, it will run that tool without asking again — which is why the limits that hold either way are server-side: it cannot delete, it cannot publish a container, it will not switch on the campaign it built, and it asks for your budget before it builds.

So for a hard stop, set your AI client to ask before AdCopilot's write tools: Needs approval in Claude; in Cursor, set the run mode to Allowlist and keep them off the allowlist (Cursor's cloud agents never ask). Staging is a second line behind it, not a replacement: a change you allowed still has to be published by you before it counts.

Connect it

Add the connector once, in Claude, ChatGPT or any MCP client, and sign in with Google. Tag Manager is its own consent beside Google Ads, granted in Google products. Connect it with read-only access and your assistant reads but stages nothing until you press Enable editing.

The short overview is on the Tag Manager page, and the tool reference is in the docs.

Google's own documentation

What the staging and publishing steps are built on, in Google's words:

• Introduction to Tag Manager. What a container, a tag, a trigger and a variable are.
• Publishing, versions, and approvals. How a workspace becomes a version and a version goes live: the step that stays yours.
• Custom event trigger. How a trigger listens for an event your site pushes to the data layer.
• Tag Manager API overview. The API behind every read and every staged change above.
• Tag Manager API: workspaces. The resource a staged change lands in.