Skip to main content
Glama
kLOsk

AdLoop: Google Ads, Reddit Ads & GA4

by kLOsk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Draft publishing a Tag Manager workspace

draft_publish_gtm_workspace
Destructive

Draft a live publish of a Tag Manager workspace and return a preview of all pending changes. Refuses if conflicts, errors, or post-preview changes occur.

Instructions

Draft publishing a Tag Manager workspace LIVE — returns a PREVIEW.

Every pending change in the workspace goes live, including changes other people made in the GTM UI; the preview lists them all. Apply refuses when the workspace changed after the preview, has merge conflicts, or reports compiler errors in a quick preview, and it refuses a Custom HTML tag being added or changed while gtm.allow_custom_html is off. Refused unless gtm.write_enabled is set. Returns the pending changes, the version that is live now (for a one-step rollback), the version name that would be created and a plan_id. That gate matches the tag type html; a Custom JavaScript variable or a custom template tag (cvt_…), which can inject a script, is not covered and needs review in the GTM UI.

Tag Manager API: https://developers.google.com/tag-platform/tag-manager/api/v2

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
version_nameNoName of the container version created by the publish. Empty uses "AdLoop publish <UTC timestamp>".
workspace_idNoWorkspace to publish (see list_gtm_workspaces). Empty uses the Default Workspace, or the only workspace there is.
version_notesNoNotes stored on the created version. Empty leaves them out.
gtm_account_idNoNumeric GTM account ID (see list_gtm_accounts). Empty uses gtm.account_id from the config.
gtm_container_idNoNumeric GTM container ID (see list_gtm_containers). Empty uses gtm.container_id from the config.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.27.1

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Well beyond the annotations, it enumerates refusal conditions, the gtm.write_enabled prerequisite, the allow_custom_html gate, and critically discloses the coverage gap (cvt_ custom templates and Custom JavaScript variables are not covered and need UI review). It also names the returned values — pending changes, current live version, prospective version name, plan_id — including the rollback affordance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the key fact (preview, not apply) and dense with substantive constraints rather than filler. Slightly long and the trailing API URL plus the inline 'LIVE — returns a PREVIEW' phrasing add mild reading friction, but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world publish-preview tool with an output schema, this covers prerequisites, refusal semantics, return contents, and the one known blind spot. Nothing an agent needs to call it safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters (including workspace_id, version_name, version_notes, account/container IDs) are already documented in the schema. The description adds no parameter-level meaning on top of it, which is the expected baseline when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening states a specific verb and resource ('Draft publishing a Tag Manager workspace') and immediately pins the output ('returns a PREVIEW'), so the agent knows this is the preview half of a two-phase flow. It also names the counterpart step ('Apply'), letting it be distinguished from confirm_and_apply without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The preview-then-Apply workflow and the conditions under which Apply refuses (changed workspace, merge conflicts, compiler errors, custom HTML gate) give clear context for when this call is used. However, it never explicitly tells the agent to call this before confirm_and_apply, nor does it exclude any alternative, so routing is inferred rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools