Google Analytics (unofficial)
Server Details
Connect Google Analytics to ChatGPT. Query GA4 data in plain English and get instant insights.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: catalog for schema discovery, sources for listing connected accounts, report for data retrieval, funnel for conversion analysis, and manage_surface for configuration. No overlap that would confuse an agent.
All tools use a consistent 'marketing_<verb>_<noun>' pattern, with 'get' for retrieval and 'manage' for updates. Nouns are descriptive and uniform.
Five tools is well-scoped for a marketing analytics server, covering metadata, source listing, data reporting, funnel analysis, and configuration without being overwhelming or sparse.
The tool surface covers core workflows (discovery, reporting, funnel analysis, configuration) but lacks tools for source management (add/remove) or connection testing, which are minor gaps.
Available Tools
5 toolsmarketing_get_catalogList supported marketing reporting sources, metrics, and dimensionsARead-onlyInspect
Use this when the user wants to discover the canonical marketing reporting graph, available sources, supported metrics, supported dimensions, or which connectors are live today. Each source also reports a passthrough field describing whether native fields beyond the curated list are accepted (GA4 accepts any native dimension/metric; Search Console accepts any native dimension; Bing is limited to the curated fields). Do not use this for GA4 account discovery or data retrieval.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| metrics | Yes | |
| sources | Yes | |
| version | Yes | |
| dimensions | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare `readOnlyHint: true` and `destructiveHint: false`. The description adds valuable behavioral context beyond annotations by detailing that each source reports a `passthrough` field describing whether native fields beyond the curated list are accepted, and specifies the behavior for GA4, Search Console, and Bing. No contradictions with 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?
The description is three sentences long, each earning its place. The first sentence gives the primary use case, the second adds key behavioral nuance about passthrough, and the third provides an exclusion. It is front-loaded and concise with no wasted words.
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 tool has one optional parameter, an output schema (though not shown), and annotations providing safety context, the description covers all necessary aspects: purpose, usage, behavioral nuances, and exclusions. It is complete for an agent to correctly select and invoke this 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 one optional parameter `source` with only `minLength: 1` and no description. Schema description coverage is 0%. The description compensates fully by implying that the parameter filters the catalog to a specific source, and provides important context about `passthrough` behavior per source. This adds significant meaning beyond the bare schema.
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 that the tool discovers the canonical marketing reporting graph, available sources, metrics, dimensions, and connector status. It distinguishes itself from siblings by explicitly saying 'Do not use this for GA4 account discovery or data retrieval.' The verb 'discover' and resource 'catalog' are specific and unambiguous.
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 says 'Use this when the user wants to discover...' and provides a negative usage condition: 'Do not use this for GA4 account discovery or data retrieval.' It also explains the `passthrough` field behavior for different sources, helping the agent decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
marketing_get_funnelGet marketing funnel dataARead-onlyInspect
Use for ordered conversion-step analysis: GA4 ordered_steps step funnels (e.g. session_start → add_to_cart → purchase) and cross-source holistic_bundle landing-page funnels joining GA4, Google Search Console, and Bing Webmaster. Covers funnel drop-off between steps (e.g. from landing on the site to adding to cart to purchasing), conversion paths, and acquisition-to-conversion context. Pass one date range for a single window or two date ranges for period-over-period comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| app | No | Optional app or web stream selector. Use this when the user identifies the GA4 source by stream ID, measurement ID, Firebase app ID, or stream name. | |
| type | Yes | ||
| limit | No | ||
| funnel | No | Multi-step funnel definition. Use this only for ordered step analysis, not for general website analytics reporting. | |
| property | No | Google Analytics property identifier. Accepts a numeric GA4 property ID like 481373915 or a resource name like properties/481373915. | |
| surfaceId | No | default | |
| dateRanges | Yes | One or more GA4 date ranges. Use two date ranges for period-over-period comparisons or significance checks. | |
| propertyId | No | Numeric GA4 property ID for the funnel report. | |
| appStreamId | No | Optional data stream ID when the funnel should run against a specific app or website stream. | |
| bingSiteUrl | No | ||
| ga4PropertyId | No | Google Analytics property identifier. Accepts a numeric GA4 property ID like 481373915 or a resource name like properties/481373915. | |
| funnelBreakdown | No | ||
| funnelNextAction | No | ||
| returnPropertyQuota | No | ||
| searchConsoleSiteUrl | No | ||
| funnelVisualizationType | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | No | |
| chart | No | |
| scope | No | |
| warnings | No | |
| comparison | No | |
| sourceState | No | |
| reportSummary | No | |
| analyticsLinks | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true), the description adds value by explaining the tool handles two funnel types, drop-off analysis, conversion paths, and cross-source joining. No contradictions with 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?
The description is two sentences plus a date range note, front-loaded with the main use case, and contains no fluff. Efficient and well-structured.
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 tool's complexity (16 parameters, nested objects) and the existence of an output schema, the description covers core use cases, types, and date range guidance. It doesn't explain every parameter but is sufficient for an agent to understand primary functionality.
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 44% (low), so the description must compensate. It explains the 'type' parameter (ordered_steps vs holistic_bundle) and date ranges, but provides minimal detail on the complex nested 'funnel' parameter (steps, filters, etc.) which is critical for usage. Add some value but insufficient for complexity.
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 is for ordered conversion-step analysis, names two specific types (ordered_steps and holistic_bundle), provides examples (session_start to add_to_cart to purchase), and distinguishes from sibling tools like marketing_get_report by focusing on funnels.
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?
Explicitly states when to use ('Use for ordered conversion-step analysis') and provides guidance on date ranges ('Pass one date range for a single window or two date ranges for period-over-period comparison'). It lacks explicit alternative tools or when-not-to-use scenarios but is clear enough for informed selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
marketing_get_reportGet holistic marketing report dataARead-onlyInspect
Primary reporting tool for a given GA4 property or site. Use for totals, trends, and breakdowns by dimension across GA4 website traffic and app analytics, Google Search Console site traffic, and Bing Webmaster — including last-30-days summaries, revenue, leads, sessions, users, engagement/time-on-page (average_session_duration, user_engagement_duration), and period-over-period comparisons. Drill deep: GA4 supports up to 9 grouped dimensions (date/hour, geo, device/browser/OS, source/medium/channel, landing_page/page_path, etc.). Defaults to all mapped connected sources merged into one standardized view, aligned on the shared grain (typically landing_page) so a page row blends GA4 sessions+engagement with Search Console/Bing clicks/impressions/CTR/position; per-source detail (e.g. full query lists) stays in sourceSections. Note GA4 has no query dimension and Search Console/Bing have no sessions/engagement, so those cannot share one row — query is a Search Console/Bing breakdown. Narrow with sources or sourceMode='single'. Any GA4 dimension/metric name not in the catalog is passed through to the GA4 API automatically; metricMode='source_native' forces a pure GA4-native report. Pass one date range for a single window or two date ranges for period-over-period comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| app | No | Optional app or web stream selector. Use this when the user identifies the GA4 source by stream ID, measurement ID, Firebase app ID, or stream name. | |
| site | No | ||
| limit | No | ||
| offset | No | ||
| source | No | ||
| maxRows | No | ||
| metrics | Yes | GA4 metric API names such as sessions, activeUsers, conversions, eventCount, totalRevenue, or engagedSessions. Include explicit numerator and denominator metrics when requesting significance context. | |
| siteUrl | No | ||
| sources | No | ||
| orderBys | No | Optional sort order. Each entry requires fieldName (a GA4 API name like sessions or date) and optional desc (true for descending). Example: [{ fieldName: "sessions", desc: true }]. | |
| pageSize | No | ||
| property | No | Google Analytics property identifier. Accepts a numeric GA4 property ID like 481373915 or a resource name like properties/481373915. | |
| surfaceId | No | Optional analysis surface ID. When omitted, the default surface is used if no explicit selector is provided. | |
| dateRanges | Yes | One or more GA4 date ranges. Use two date ranges for period-over-period comparisons or significance checks. | |
| dimensions | No | Optional GA4 dimensions such as date, country, deviceCategory, landingPagePlusQueryString, or dateRange. Omit entirely for aggregate totals (renders as KPI widget). Only include when the user asks for a breakdown or trend. | |
| metricMode | No | canonical | |
| propertyId | No | Numeric Google Analytics 4 property ID for website analytics or app analytics. Use this when the user references a GA4 property directly. | |
| sourceMode | No | auto | |
| appStreamId | No | GA4 app or web data stream ID when the request targets a specific app stream or website stream. | |
| significance | No | Optional significance context for GA4 rate comparisons. Use this only when the user asks whether a change is statistically significant or meaningful. | |
| keepEmptyRows | No | ||
| metricFilters | No | ||
| returnAllRows | No | ||
| sourceOptions | No | ||
| dimensionFilters | No | ||
| metricFilterExpression | No | ||
| dimensionFilterExpression | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | No | |
| chart | No | |
| scope | No | |
| lineage | No | |
| metrics | No | |
| warnings | No | |
| comparison | No | |
| confidence | No | |
| sourceState | No | |
| significance | No | |
| reportSummary | No | |
| analyticsLinks | No | |
| resolvedEntities | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, and non-destructive behavior. The description adds behavioral context such as how data sources are merged, alignment on landing_page, limitations of GA4 vs Search Console dimensions, and the pass-through of unknown GA4 metrics, which are not covered by 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?
The description is lengthy but well-structured, front-loading the primary purpose and gradually adding details. Each sentence contributes meaningful information without redundancy, though some minor trimming could improve conciseness.
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 tool's complexity (27 parameters, low schema coverage) and the existence of an output schema, the description covers major aspects: data merging, dimension limitations, pagination, ordering, significance testing, and source-specific options. It is complete enough for an agent to correctly select and invoke the tool in most scenarios.
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?
With only 37% schema coverage, the description compensates by explaining key parameters like dateRanges, sources, metricMode, sourceMode, dimensions, and significance. It clarifies how these parameters affect behavior, such as using two date ranges for period-over-period comparison, which the schema alone does not convey.
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 identifies this tool as the primary reporting tool for GA4 properties/sites, specifying its use for totals, trends, and breakdowns across multiple sources. It distinguishes the tool from siblings like marketing_get_catalog and marketing_get_funnel by focusing on holistic report generation.
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 provides explicit guidance on when to use dimensions, date ranges, and source modes, and explains how to narrow reports using 'sources' or 'sourceMode'. It implicitly differentiates from siblings by naming alternatives like 'marketing_get_funnel', but does not explicitly state when to avoid this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
marketing_get_sourcesDiscover marketing data sourcesARead-onlyInspect
Lists connected and missing GA4, Google Analytics properties, property IDs, web streams, app streams, measurement IDs, Firebase app IDs, Google Search Console sites, Bing Webmaster sites, and current analysis surface mappings. Use this before reporting when property/site selectors are unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| sources | No | ||
| surfaceId | No | default |
Output Schema
| Name | Required | Description |
|---|---|---|
| sources | Yes | |
| surface | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns by stating 'Lists'. It adds behavioral detail beyond annotations by specifying it returns both connected and missing sources, and enumerates specific data types (properties, streams, IDs, sites). No contradiction with 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?
The description is one concise sentence with an additional usage instruction. It is front-loaded with the action and content, and every phrase adds value without repetition or fluff.
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 presence of an output schema (true), the description does not need to document return values. It covers the essential information: what the tool lists and when to use it. The only gap is incomplete parameter semantics, which is captured in that dimension.
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 0%, so the description must compensate for missing parameter explanations. It lists source types (GA4, Search Console, Bing) that map to the 'sources' parameter's enum values, but does not mention the 'surfaceId' parameter at all, leaving its purpose unclear.
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 lists various marketing data sources (GA4, Search Console, Bing) using a specific verb 'Lists'. It distinguishes from sibling tools like 'marketing_get_catalog' which likely lists different entities, and 'marketing_manage_surface' for management operations.
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?
Provides explicit when-to-use context: 'Use this before reporting when property/site selectors are unknown.' It does not explicitly state when not to use it or mention alternatives, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
marketing_manage_surfaceGet or update analysis surface mappingsAInspect
Gets or updates persisted selectors for a website/app analysis surface. Use action='get' to inspect mappings and action='update' to persist GA4, Search Console, or Bing Webmaster selectors.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| action | Yes | ||
| selectors | No | ||
| surfaceId | No | default | |
| mainDomain | No | ||
| selectorSets | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| applied | No | |
| surface | No | |
| sourceState | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-write but not destructive. The description adds context by naming the specific selectors that can be persisted (GA4, Search Console, Bing Webmaster), but does not disclose whether updates are additive or replace, or any permission requirements. Given the annotations, the description adds some value but not full transparency.
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 sentences, front-loaded with the tool's purpose and action parameter guidance. Every sentence contributes meaning without redundancy.
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 covers the basic purpose and two actions, but with 6 parameters including nested objects (selectors, selectorSets), it lacks depth. It does not explain optional parameters or the difference between selectors and selectorSets. An output schema exists, so return values are covered, but the description remains incomplete for complex usage.
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 0%, so the description must compensate. It only mentions the selector types (ga4, search_console, bing_webmaster) but does not explain the meaning or usage of parameters like surfaceId, mainDomain, selectors vs selectorSets, or their relationships. The description adds minimal value beyond the schema.
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 title and description clearly state the tool gets or updates analysis surface mappings. It specifies the two actions (get/update) and the types of selectors (GA4, Search Console, Bing Webmaster). This distinguishes it from sibling tools that focus on catalog, funnel, report, or sources.
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 when to use 'get' versus 'update' by stating the action parameter. It provides clear usage context but does not explicitly mention when not to use this tool or alternatives beyond the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!