MCP GTM B2 TECH

Model Context Protocol · Google Tag Manager API v2

Comande o Tag Manager
direto pelo Claude.

Um servidor MCP que liga o Claude aos seus containers GTM — leia, audite, crie, versione e publique tags, triggers e variáveis sem abrir a UI do Tag Manager. Login OAuth embutido. Status: LIVE.

27 tools · OAuth embutido · multi-tenant · grátis

Workspace → versão → publish Arquitetura hexagonal preview=true dry-run confirm=true em destrutivos Fingerprint anti-conflito Multi-tenant na Vercel OAuth 2.1 Authorization Server Workspace → versão → publish Arquitetura hexagonal preview=true dry-run confirm=true em destrutivos Fingerprint anti-conflito Multi-tenant na Vercel OAuth 2.1 Authorization Server
O que é

Seu GTM, operado em linguagem natural

O MCP GTM B2 TECH é um servidor Model Context Protocol que dá ao Claude acesso real aos seus containers — não um chatbot que adivinha, mas chamadas tipadas na Google Tag Manager API v2.

Conexão real

Claude fala com o seu container

Instale ou audite um Meta Pixel, uma tag de conversão do Google Ads ou o GA4; crie triggers de clique, formulário e scroll; publique uma versão nova — tudo conversando com o Claude. O login do Google é OAuth2, embutido no fluxo.

Modelo mental

GTM funciona como git

Account → Container → Workspace (branch) → create_version (commit) → publish (deploy). Toda edição acontece num workspace; concorrência otimista via fingerprint de cada entidade.

Status

LIVE em produção

Deploy multi-tenant em mcp-gtm.vercel.app — tokens cifrados no Supabase, cache no Upstash, e nós somos o OAuth 2.1 Authorization Server. Mesmo stack dos MCPs de Meta Ads, Google Ads, Instagram e Cloudflare.

O que ele já faz

O catálogo completo de ferramentas

27 tools agrupadas por função — da autenticação ao publish, do snippet de instalação à edição de tags, triggers e variáveis. Tudo abaixo já está implementado e no ar.

Autenticação

4 tools
  • gtm_loginConecta uma conta Google (consentimento no browser); guarda o refresh token.
  • gtm_submit_callbackFinaliza o login submetendo a URL de callback redirecionada.
  • gtm_token_statusDiz se a credencial guardada é válida, seus escopos e expiração.
  • gtm_refresh_tokenGera um access token novo a partir do refresh token guardado.

Contas & containers

7 tools
  • list_accountsLista as contas GTM que a credencial acessa.
  • get_accountDetalha uma conta GTM.
  • list_containersLista os containers de uma conta.
  • get_containerDetalha um container (publicId, contexto de uso).
  • create_containerCria um container web/server/amp/iOS/Android e devolve o publicId (GTM-XXXX).
  • get_container_snippetMonta o snippet de instalação head/noscript localmente — determinístico, sem gastar quota.
  • get_live_versionMostra a versão publicada — o que está no ar agora.

Workspaces

3 tools
  • list_workspacesLista os workspaces (rascunhos) de um container.
  • get_workspace_statusMostra as mudanças pendentes em relação à versão base.
  • create_workspaceAbre um workspace novo — o "branch" onde as edições acontecem.

Elementos — tags, triggers & variáveis

6 tools
  • list_elementsLista tags, triggers ou variáveis de um workspace (kind ∈ tag/trigger/variable).
  • get_elementDetalha um elemento, incluindo o fingerprint.
  • create_elementCria tag, trigger ou variável — aceita o array parameter cru + escape hatch extra.
  • update_elementEdita um elemento (concorrência otimista via fingerprint).
  • delete_elementRemove um elemento (destrutivo, precisa de confirm).
  • list_builtin_variablesLista as built-in variables habilitadas no workspace.

Built-in variables

2 tools
  • enable_builtin_variablesHabilita built-ins (Click Classes, Page URL, Scroll Depth etc.).
  • disable_builtin_variablesDesabilita built-ins (destrutivo, precisa de confirm).

Versões & publish

5 · confirm=true
  • list_version_headersLista o histórico de versões do container.
  • get_versionDetalha uma versão imutável do container.
  • list_environmentsLista os environments (Live, Latest, customizados).
  • create_versionO "commit": congela o workspace numa versão imutável.
  • publish_versionO "deploy": coloca a versão no ar no site (destrutivo, precisa de confirm).

Do zero ao publicado numa conversa: create_containerget_container_snippet → tags e triggers → create_versionpublish_version.

Modelo de segurança dos writes

O Claude não publica nada sozinho

Publicar um container muda o site em produção. Por isso cada write passa por barreiras explícitas — você está sempre no controle do que vai pro ar.

Edições ficam no workspace

Todo write acontece num rascunho. O site só muda quando você congela uma versão e publica — nunca antes.

Destrutivos exigem confirm=true

delete_element, disable_builtin_variables e publish_version. Sem confirm, a tool devolve um preview e não executa nada.

preview=true = dry-run

Devolve o payload exato que seria enviado, sem chamar a API. Cheque antes de executar de verdade.

fingerprint anti-conflito

Concorrência otimista: um fingerprint desatualizado retorna erro de conflito (409) mandando reler — ninguém sobrescreve mudança alheia sem saber.

Tenant nunca é argumento

Localmente é a credencial única guardada; em produção o tenant é derivado do access token do Authorization Server embutido. Nenhuma tool aceita "de qual cliente".

Tokens cifrados em repouso

Refresh tokens com AES-256-GCM no Supabase, RLS default-deny e service key só no servidor. O gtm_token_status mostra exatamente quais escopos estão ativos.

Como conectar

Em pé em poucos minutos

Dois caminhos: o hospedado (recomendado, zero setup) e o local stdio (para devs single-tenant). Os dois terminam no mesmo lugar — o Claude operando sua conta.

Recomendado

Hospedado — mcp-gtm.vercel.app

Adicione o servidor MCP como connector no Claude e faça login. Nada para instalar; nós cuidamos do OAuth e dos tokens.

  1. Adicione o connector. No Claude.ai → Configurações → Conectores → Adicionar conector personalizado, cole https://mcp-gtm.vercel.app/api/mcp. No Claude Code, use o comando abaixo.
    # Claude Code
    claude mcp add --transport http \
      gtm https://mcp-gtm.vercel.app/api/mcp
  2. Faça login no Google. O handshake OAuth (nosso Authorization Server → login Google) roda automaticamente ao conectar; no Claude Code, complete via /mcp.
  3. Confirme. Rode gtm_token_status para validar a credencial e list_accounts para ver suas contas GTM. Pronto para operar.
Avançado

Local stdio — single-tenant

Rode o servidor na sua máquina. O refresh token fica num arquivo 0600 local; você usa seu próprio OAuth client do GCP.

  1. Instale. Crie o ambiente e instale as dependências.
    python -m venv venv
    venv/bin/pip install -e ".[dev]"
    cp .env.example .env.local
  2. Configure as credenciais. Preencha .env.local: GOOGLE_OAUTH_CLIENT_ID, GOOGLE_OAUTH_CLIENT_SECRET e NGROK_URL (o redirect URI é ${NGROK_URL}/oauth/callback no client OAuth do GCP).
  3. Rode e logue. Suba o servidor e conecte sua conta.
    PYTHONPATH=src venv/bin/python \
      -m mcp_gtm
    # no Claude: gtm_login → gtm_submit_callback

Perguntas frequentes

Ficou alguma dúvida? Escreva para bruno@b2tech.io.

Quanto custa?
O MCP GTM é grátis. Você só precisa de uma conta Google com acesso ao Google Tag Manager.
É seguro? O Claude pode quebrar meu site?
Nada vai pro ar sem você. Todas as edições acontecem num workspace (rascunho); o site só muda quando publish_version roda com confirm=true. Ações destrutivas sem confirm devolvem apenas um preview, e preview=true retorna o payload exato sem chamar a API.
Como funciona o modelo de workspace e versão?
O GTM funciona como git: Account → Container → Workspace (branch) → create_version (commit) → publish (deploy). Você edita num workspace, congela numa versão imutável e só então publica.
O que é o fingerprint?
É o mecanismo de concorrência otimista da API do GTM: cada entidade tem um fingerprint, e um fingerprint desatualizado retorna um erro de conflito estilo 409 mandando reler antes de escrever — ninguém sobrescreve mudança alheia sem saber.
Multi-tenant — onde ficam meus tokens?
No deploy hospedado, os refresh tokens ficam cifrados com AES-256-GCM no Supabase (RLS default-deny) e o cache no Upstash; nós somos o OAuth 2.1 Authorization Server. No modo local, o refresh token fica num arquivo 0600 na sua máquina (single-tenant).
Existe limite de uso?
A Tag Manager API permite ~0.25 QPS por projeto GCP (25 requests/100s) e 10.000 chamadas/dia. Um setup completo de container (~15 chamadas sequenciais) cabe tranquilo; automação pesada pede pacing ou aumento de quota no console GCP.
Local ou hospedado — qual escolher?
Hospedado (mcp-gtm.vercel.app) é o caminho rápido: zero setup, é só adicionar como connector no Claude e logar. Local stdio é single-tenant, para devs que querem rodar tudo na própria máquina com o refresh token num arquivo 0600.
Comece agora

Pare de clicar na UI do GTM.
Peça ao Claude e ele instala, versiona e publica.

Tags, triggers, variáveis, versões e environments — do zero ao container publicado, com OAuth embutido e publish só com confirm=true. Grátis e no ar.

27 tools · OAuth2 embutido · multi-tenant na Vercel