Interact with Google Analytics 4 properties, including account summaries, property configuration, custom dimensions and metrics, data streams, key events, and running standard or realtime reports.
Manage Google Tag Manager entities such as accounts, containers, workspaces, tags, triggers, variables, templates, versions, environments, and permissions, with read, write, and destructive capabilities.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gtm-ga4-mcp List all GTM accounts and containers, then show yesterday's GA4 traffic by source."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for Google Tag Manager + Google Analytics 4 with tiered safety controls.
Existing servers cover slices of this surface: Google's official GA4 server is read-only, and GTM servers expose the API without a safety model. gtm-ga4-mcp is built for the full surface — read, write, and admin operations — with safeguards you opt into deliberately.
Every tool belongs to a tier. Higher tiers are off by default and enforced twice:
Tier | Examples | Default | Enable with |
Read | list, get, reports, metadata | ✅ on | — |
Write | create/update tags, triggers, custom dimensions | ❌ off |
|
Destructive | delete, publish, user permissions | ❌ off |
|
Registration gate — tools above your tier are never registered, so they're invisible to the model (not just erroring at call time).
Token gate — the OAuth scopes requested from Google are derived from the same tier. A read-only process asks for tagmanager.readonly + analytics.readonly and holds a token that cannot mutate anything, even if the application code misbehaves.
Individual tools can also be disabled by name: --deny gtm_get (repeatable) or GTM_GA4_MCP_DENY=tool_a,tool_b.
Beyond the two gates, mutations carry their own guards:
Write tools default to dry-run — they echo the exact API request without sending it; execution requires an explicit dry_run: false.
Destructive tools are two-phase — the first call changes nothing and returns a one-time confirm_token plus a plain-language summary; only a second call with that token executes. Tokens are fingerprinted to the exact operation (a confirmation for deleting tag X can never authorize deleting tag Y), single-use, and expire in 10 minutes. This follows the Multi Round-Trip Requests pattern from MCP spec 2026-07-28 and works on every client.
Blast-radius exclusions — accounts, containers, and GA4 properties can never be deleted through this server, by design.
Related MCP server: Google Tag Manager MCP Server
Read tier (always on):
Tool | What it does |
| List GTM entities level by level (accounts → containers → workspaces → tags/triggers/variables/templates/permissions/…), trimmed summaries |
| Full JSON for one GTM entity by path (including container versions) |
| Every GA4 account + property you can access — the entry point |
| One property's full configuration |
| Data streams, key events, custom dimensions/metrics, Ads/Firebase links |
| GA4 report over a date range, rows as clean dicts |
| Last-30-minutes activity (verify events are firing) |
| Discover dimension/metric API names (standard + custom), searchable |
Write tier (--allow-write), all dry-run by default:
Tool | What it does |
| Create tags, triggers, variables, folders, templates, clients, transformations, zones, workspaces, environments |
| Replace a GTM entity (full-body update with optional optimistic-lock fingerprint) |
| Create custom dimensions/metrics, key events, data streams |
| Patch GA4 entities or property settings (partial update via update mask) |
Destructive tier (--allow-destructive), all two-phase confirmed:
Tool | What it does |
| Delete workspace entities, workspaces, versions, environments (never accounts/containers) |
| Compile a workspace into a version and publish it LIVE (aborts on compile errors) |
| Grant / update / revoke GTM account access |
| Archive custom dimensions/metrics, delete key events/data streams (never properties) |
Design choices worth knowing: ~8 consolidated tools instead of ~120 endpoint wrappers (smaller agent context, deterministic alphabetical ordering for prompt caching), list results are trimmed summaries with gtm_get for deep dives, and all GTM calls flow through a rate limiter tuned to the GTM API's ~15 requests/minute default quota with backoff on 429/5xx.
1. Enable APIs in a Google Cloud project: Tag Manager API, Analytics Admin API, Analytics Data API.
2. Authenticate with Application Default Credentials. Log in with the scopes matching the tier you run — this is the token-level gate, so a read-only login is a hard guarantee:
Read-only (default):
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/tagmanager.readonly,https://www.googleapis.com/auth/analytics.readonly,https://www.googleapis.com/auth/cloud-platformEverything, for a full read/write/destructive session:
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/tagmanager.readonly,https://www.googleapis.com/auth/analytics.readonly,https://www.googleapis.com/auth/tagmanager.edit.containers,https://www.googleapis.com/auth/tagmanager.edit.containerversions,https://www.googleapis.com/auth/analytics.edit,https://www.googleapis.com/auth/tagmanager.delete.containers,https://www.googleapis.com/auth/tagmanager.publish,https://www.googleapis.com/auth/tagmanager.manage.users,https://www.googleapis.com/auth/cloud-platform3. Add the server. Claude Code (read-only):
claude mcp add gtm-ga4 -- uvx --from git+https://github.com/kb223/gtm-ga4-mcp gtm-ga4-mcpAppend --allow-write or --allow-destructive to that command to enable higher tiers.
Or any MCP client via .mcp.json / Claude Desktop config:
{
"mcpServers": {
"gtm-ga4": {
"command": "uvx",
"args": ["--from", "git+https://github.com/kb223/gtm-ga4-mcp", "gtm-ga4-mcp"]
}
}
}PyPI package coming with v1.0 (uvx gtm-ga4-mcp).
Google blocks Tag Manager / Analytics scopes on gcloud's shared default OAuth client, so the plain gcloud auth application-default login above may fail with "This app tried to access sensitive info in your Google Account." The fix — same as Google documents for their own analytics-mcp — is a two-minute OAuth client of your own:
In a Google Cloud project with the three APIs enabled, open APIs & Services → OAuth consent screen: user type External, publishing status Testing, and add your own Google account as a test user.
APIs & Services → Credentials → Create Credentials → OAuth client ID → Desktop app, then download the client JSON.
Re-run the login with your client:
gcloud auth application-default login --client-id-file=path/to/client_secret.json --scopes=<same scopes as above>Heads-up: while the consent screen is in Testing mode, Google expires the refresh token after ~7 days, so expect to re-run the login weekly (or publish the app and click through the unverified-app warning).
Ask your agent things like:
"List my GTM accounts, then show me every tag in the main container's default workspace."
"Which GA4 properties do I have access to, and what custom dimensions does property 123456 define?"
"Run a report on sessions and conversions by default channel group for the last 28 days."
"Is the purchase event firing right now?"
(write tier) "Create a lead_type event-scoped custom dimension on property 123456." — you'll see the dry-run payload first
(destructive tier) "Delete the paused tag called Old Pixel." — you'll get a summary + confirmation token before anything happens
uv sync
uv run pytest
uv run ruff check .
npx @modelcontextprotocol/inspector uv run gtm-ga4-mcp # interactive testingCI runs the test suite plus an MCP Inspector CLI smoke test (tools/list over stdio, no credentials needed).
v0.2 — write tier ✅ shipped
v0.3 — destructive tier ✅ shipped
v1.0: PyPI, MCP registry listing, MCPB bundle
MIT
List every GA4 account and property the authenticated user can access.
This is the entry point for all GA4 work — it returns the property IDs the other ga4_* tools need.
| Name | Required | Description | Default |
|---|---|---|---|
| page_token | No | Pagination token from a previous response. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds value by explaining what it returns (property IDs) and why that matters (for other tools), which is beyond the structured data. It doesn't mention pagination behavior, but with annotations covering safety and a simple list operation, the added context is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no redundancy. The primary action is front-loaded, and the second sentence explains the tool's role in the broader toolset. Every word earns its place; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with a single optional parameter and a rich output schema (not described but available), the description covers the essential purpose and return-value significance. It does not explain pagination mechanics, but the schema covers the parameter and the description explicitly mentions returning all accessible accounts and properties. Minor gap: no mention of how many results or limits, but not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter page_token has 100% schema description coverage, so the schema fully documents it. The description does not add any parameter-specific detail, which is fine given the schema already explains the pagination token. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List'), the resource ('every GA4 account and property'), and the access scope ('the authenticated user can access'). The second sentence explicitly frames it as the entry point for all GA4 work, which distinguishes it from sibling tools that operate on existing properties. This is very clear and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool: as the starting point for any GA4 workflow, returning property IDs needed by other ga4_* tools. While it doesn't explicitly mention alternatives or when not to use it, the entry-point framing is so strong that an agent can infer it should be called first. It lacks explicit exclusions but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a GA4 property's sub-entities.
Covers data streams, key events, custom dimensions/metrics, Google Ads links, and Firebase links.
| Name | Required | Description | Default |
|---|---|---|---|
| page_token | No | Pagination token from a previous response. | |
| entity_type | Yes | Which property sub-entity to list. | |
| property_id | Yes | GA4 property ID, e.g. '123456' or 'properties/123456'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful scope information by naming the entity types, but it does not add deeper behavioral details such as pagination behavior or response characteristics, though the output schema may cover those.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the primary action front-loaded and the supported entity types summarized in a compact list. There is no filler or redundant restating of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations, complete parameter descriptions, and presence of an output schema, the description is fully adequate. It clearly communicates the tool's scope, and the schema covers the remaining invocation details such as property ID format and pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for entity_type, property_id, and page_token. The description's listing of entity types adds a helpful summary but does not provide additional parameter semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource, 'a GA4 property's sub-entities', and immediately enumerates the covered entity types. This makes the tool's role clear and distinguishes it from siblings like ga4_property_get, which retrieves the property itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by specifying exactly which kinds of sub-entities the tool covers, so an agent can infer when to use it. It does not explicitly name sibling tools or state when not to use it, but no exclusions are needed given the focused scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the dimension/metric API names available on a property (standard + custom).
Use this before ga4_run_report to find exact API names.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Optional case-insensitive filter on API/UI names, e.g. 'revenue'. | |
| property_id | Yes | GA4 property ID, e.g. '123456' or 'properties/123456'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful scope ('standard + custom') but no behavioral details beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the tool's purpose, and the second provides the critical usage context (use before ga4_run_report). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple metadata listing tool with a rich output schema, full parameter documentation, and strong annotations, the description is complete. It tells the agent what the tool returns and when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameter meanings are fully documented in the schema. The description does not need to add parameter detail; the mention of 'API names' and 'property' aligns with the parameters without duplicating their documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') and resource ('dimension/metric API names available on a property'), including the scope 'standard + custom'. This is unambiguous and distinct from sibling report-running tools like ga4_run_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: 'Use this before ga4_run_report to find exact API names.' This is clear and actionable, though it does not name alternative tools or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one GA4 property's full configuration (timezone, currency, industry, service level).
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes | GA4 property ID, e.g. '123456' or 'properties/123456'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and side-effect expectations. The description's 'Fetch' aligns with this. However, it adds no additional behavioral context (e.g., error handling, data freshness), so it stays at the baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundancy or filler. It directly states the action and the data returned, making it concise and effectively formatted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple read operation: it specifies the resource and the kind of data ('full configuration'), which is sufficient given the absence of an output schema. It does not address potential edge cases (e.g., what happens if the property doesn't exist), but that is not critical for this straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'property_id', with a clear description including examples. Since the schema fully explains the parameter, the description needs to add no extra semantics; the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Fetch'), a specific resource ('one GA4 property'), and enumerates the configuration fields (timezone, currency, industry, service level). This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus its siblings (e.g., ga4_account_summaries, ga4_admin_list). It lacks explicit conditions or alternatives, which would help an agent decide between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a GA4 realtime report (last 30 minutes) — e.g. to verify events are firing now.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows to return. | |
| metrics | Yes | Realtime metric API names, e.g. ['activeUsers', 'eventCount']. | |
| dimensions | No | Realtime dimension API names, e.g. ['eventName', 'country']. | |
| property_id | Yes | GA4 property ID, e.g. '123456' or 'properties/123456'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive, lowering the burden on the description. The description adds the useful behavioral constraint that only the trailing 30 minutes are queried and frames the result as live event activity. No contradictions with annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the operation and time window, then adds a concrete use case. Every phrase earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only report tool with a complete input schema, an output schema, and safety annotations, the description covers the core operation and the real-time limitation. It could optionally reference ga4_run_report for historical reporting or warn about realtime API metric/dimension restrictions, but those are enhancements, not prerequisites for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents all four parameters with examples and defaults. The description adds no parameter-level detail, so it stays at the baseline score rather than compensating or repeating schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource ('GA4 realtime report'), specifies the 30-minute window, and gives a concrete use case ('verify events are firing now'). This clearly distinguishes it from the sibling ga4_run_report, which targets standard historical reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The example 'to verify events are firing now' clearly signals the immediate-verification context. It does not explicitly name ga4_run_report as the alternative for historical queries, but the 'last 30 minutes' qualifier strongly implies the boundary between realtime and standard reporting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a GA4 report over a date range and return one dict per row.
Rows are keyed by the requested dimension/metric API names. row_count is
the total available on the server; raise limit or refine dimensions if
rows were truncated.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows to return. | |
| metrics | Yes | Metric API names, e.g. ['sessions', 'conversions', 'totalRevenue']. Discover names via ga4_metadata. | |
| end_date | No | End date: 'YYYY-MM-DD', 'NdaysAgo', 'yesterday', or 'today'. | today |
| dimensions | No | Dimension API names, e.g. ['date', 'sessionDefaultChannelGroup']. | |
| start_date | No | Start date: 'YYYY-MM-DD', 'NdaysAgo', 'yesterday', or 'today'. | 28daysAgo |
| property_id | Yes | GA4 property ID, e.g. '123456' or 'properties/123456'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate read-only, idempotent, non-destructive behavior. The description adds useful runtime behavior by explaining that rows are keyed by requested API names, that row_count reflects server-side availability, and that truncation can be handled by raising limit or refining dimensions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, informative, and front-loaded with the core purpose. Every sentence earns its place, and the truncation guidance is practical without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Between the full input schema, annotations, and output schema, the description provides enough context for correct invocation. It lacks explicit sibling routing, but the combination of schema details and behavioral notes is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with 100% coverage, so the baseline is 3. The description adds extra value by explicitly linking the return shape to the requested dimension/metric API names and by advising to raise limit or refine dimensions when rows are truncated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: run a GA4 report over a date range and return a dict per row. It is specific about the resource and output, but it does not explicitly distinguish itself from the sibling ga4_run_realtime_report beyond the date-range wording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The date-range phrasing implies this is for historical GA4 reporting rather than realtime, but no when-to-use or when-not-to-use guidance is given. There is no explicit mention of alternatives such as ga4_run_realtime_report, so the agent must infer usage from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one GTM entity's complete JSON by its path (tag, trigger, variable, version, ...).
Note: fetching a version returns the entire published container (large).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Full GTM entity path from a gtm_list result, e.g. 'accounts/123/containers/456/workspaces/7/tags/8' or 'accounts/123/containers/456/versions/42'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds a useful disclosure beyond those: requesting a version path returns the entire published container, which may be large. That is relevant operational context an agent cannot infer from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: the first states the core operation with examples, the second calls out an important size caveat. Every sentence earns its place and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter GET-style tool with rich annotations and an output schema, the description covers what the tool does, the path provenance, and the one major behavioral caveat. Nothing needed to select and invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the path format and examples. The description adds value by framing the path as selecting one complete entity and by warning that a version path yields a large published-container payload, a parameter-specific semantic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the action ('Fetch'), the object ('one GTM entity's complete JSON'), and the selection mechanism ('by its path'), and it lists the entity types (tag, trigger, variable, version). This clearly differentiates it from gtm_list, which would enumerate entities rather than fetch a single one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It conveys that this tool is for retrieving a specific entity when the full path is already known, and the schema reinforces that the path comes from a gtm_list result. It does not explicitly name gtm_list as the alternative for discovering paths, so it stops short of a full when-to-use/when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Google Tag Manager entities one hierarchy level at a time.
Returns trimmed summaries (path, name, type, IDs) to keep context small;
each item's path feeds gtm_get (full detail) or a deeper gtm_list call.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | Return complete entity JSON instead of trimmed summaries. Prefer gtm_get for a single entity. | |
| parent | No | Parent path from a previous result, e.g. '' for accounts, 'accounts/123' for containers, 'accounts/123/containers/456' for workspaces/versions/environments, 'accounts/123/containers/456/workspaces/7' for tags/triggers/variables. | |
| page_token | No | Pagination token from a previous response. | |
| entity_type | Yes | Which GTM entity to list. Walk the hierarchy: accounts -> containers -> workspaces -> tags/triggers/variables/... |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral context: results are intentionally trimmed summaries to keep context small, and the returned `path` is the linking mechanism to subsequent calls. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The main purpose is front-loaded, and the secondary note about `path` feeding subsequent calls earns its place by clarifying the tool's role in the broader workflow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The combination of the description, rich input schema with explicit hierarchy walk, annotations, and output schema fully equips an agent to invoke this tool correctly. The description communicates the essential workflow (list -> navigate deeper or fetch full detail) without needing to restate structured field meanings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with parameter descriptions already explaining `entity_type`, `parent`, `full`, and `page_token`. The description adds context about path reuse but does not need to; the schema carries the parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List Google Tag Manager entities') and the key scoping constraint ('one hierarchy level at a time'). It also distinguishes itself from gtm_get by positioning the list output as trimmed summaries that feed into full-detail retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent that each item's `path` can be used either for a deeper gtm_list call or for gtm_get full detail, which is strong routing guidance. It does not explicitly say 'do not use this for full entity details,' but the contrast with gtm_get and the 'trimmed summaries' wording make the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The GA4 and GTM tools are clearly separated by prefix and purpose. Within GA4, account discovery, property config, metadata, admin listing, and reporting are mostly distinct; the only slight overlap is between ga4_metadata and ga4_admin_list for custom dimensions/metrics.
All names use snake_case and share the ga4_/gtm_ prefixes, but the verb-noun pattern is inconsistent: some are noun phrases like ga4_account_summaries and ga4_metadata, while others are verb-led like ga4_run_report and gtm_get. This is readable but not a single predictable convention.
Eight tools is a reasonable size for a combined GA4+GTM server, and each tool covers a distinct read/query operation. The GTM side is slightly thin at only two tools, but the overall count is not excessive.
The GA4 surface covers discovery, property configuration, admin entity listing, metadata, standard reporting, and realtime reporting, which supports common analytics workflows. GTM is limited to get/list operations, so deeper management features are missing, but the server appears intentionally read-query oriented.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Let AI manage your Google Tag Manager containers — tags, triggers, variables, and more.
Read and edit GA4, Search Console and Google Tag Manager from any MCP client. 29 tools.
Run Google Ads, Meta Ads, GA4 and Search Console from chat: read, audit and launch campaigns.
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kb223/gtm-ga4-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
