Connect
Google Tag Manager: connect a container, draft changes, read versions
TL;DR
Tag Manager connects with Google sign-in, one row per container. The agent reads the container — tags, triggers, variables, versions, environments, server-side clients and templates — and drafts changes in a workspace draft. By default each draft change waits for your approval. Publishing, custom code and Community Template Gallery imports always wait for a person, and every write is bound to the container you connected.
Connect
- 1On Integrations, press Connect on the Tag Manager card and sign in with a Google account that can see the containers.
- 2Each container becomes a row you can pick in the context picker. A server-side container is its own row.
- 3Ask, for example: "What fires on the checkout page, and on what trigger?" or "What would a publish ship right now?"
The connection asks for
tagmanager.readonly and tagmanager.edit.containers. Publishing and the compile check need Tag Manager's container-versions permission, which Google is still verifying; today it is offered only to preview workspaces, and without it those tools answer what is missing.Read
| Tool | What it reads |
|---|---|
| list_containers, get_container | The containers the sign-in reaches; whether one is a server container and where a web container sends its server-side traffic |
| list_workspaces, list_tags, list_triggers, list_variables | A workspace draft's tags, triggers and variables with their parameters and firing triggers |
| get_live_version | The published version — what actually runs on the site |
| list_versions | Every version, newest first, with its counts and which one is live |
| list_environments | Live, Latest, staging or QA environments and the version each serves |
| get_workspace_status | The draft's pending changes against its base version — what a publish would ship, code changes first |
| list_clients, list_templates, list_transformations | Server-side clients, custom templates (with Gallery provenance) and transformations |
| get_gallery_template | A Community Template Gallery template's name, where it runs (web or server) and the permissions it asks for, before any import |
| preview_workspace | Whether the draft compiles; creates no version and publishes nothing |
Draft
- Tags, triggers and variables: create and update in the workspace draft. An update reads the item first and shows before and after; a trigger's conditions merge by variable unless you ask to replace them.
- Built-in variables: turn on {{Click URL}}, {{Form ID}} and the others; turning one off is refused while something still references it.
- Server-side: clients and templates, on a server container only — a client write on a web container is refused before any call.
- Sync and undo: bring a draft up to the latest version (merge conflicts are reported, never resolved for you), or undo one pending draft change.
- Gallery import: a template from the Community Template Gallery goes into the draft pinned to the version you were shown.
Nothing in the draft runs on your site until the workspace is published.
What always waits for a person
- Publishing a workspace. Auto-approve does not cover it, it never rides a bulk approval, and over MCP it is held in the approval queue with an email to an admin or editor.
- Code: a Custom HTML tag, a Custom JavaScript variable, a custom template and a Gallery import. The approval card shows the code or the template's permissions with an advisory scan; a scan that finds nothing is not a safety verdict.
- Raw API writes that carry code or publish are refused; the typed tools above are the way in.
Every other draft change follows your approval setting: by default it waits for your approval card; auto-approve is opt-in per task, schedule or project.
Bound to your container
One Google sign-in usually reaches several containers. A workspace or item path that belongs to another container is refused before Tag Manager is called, publish included, so a write can only change the container you picked.
What Tag Manager's API does not offer here yet
- Folder, zone and environment writes, merging containers and publishing an older version are not built; do them in Tag Manager.
- A container's user permissions are not managed by the agent.
Platform overview: Google Tag Manager · From an MCP client: Tag Manager MCP guide · Walkthrough: an AI agent for Google Tag Manager.
Frequently asked questions
- Can the agent publish my Tag Manager container?
- Not on its own. A publish always waits for a person, and it needs a Tag Manager permission Google is still verifying, so today only preview workspaces can publish through Agent Planners.
- Does the agent work on the live container?
- No. It changes a workspace draft. Nothing in the draft runs on your site until a person publishes the workspace.
- Can it check what a publish would change?
- Yes. get_workspace_status lists the draft's pending changes against its base version, code changes first, and list_versions shows which version is live.