gtm-ga4-mcp

by kb223

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.2
Disambiguation4/5
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.
Naming Consistency3/5
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.
Tool Count4/5
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.
Completeness4/5
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.
Average 4.1/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![gtm-ga4-mcp MCP server](https://glama.ai/mcp/servers/kb223/gtm-ga4-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kb223/gtm-ga4-mcp)

Score Badge

Copy to your README.md:

[![gtm-ga4-mcp MCP server](https://glama.ai/mcp/servers/kb223/gtm-ga4-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kb223/gtm-ga4-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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