Skip to main content
Glama
Seey215

Google Analytics MCP Server

by Seey215
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Google Analytics MCP Server

A Model Context Protocol (MCP) server that provides seamless access to Google Analytics 4 data through standard MCP interfaces. This tool allows LLM applications to easily query and analyze Google Analytics data without directly dealing with the complexities of the Google Analytics Data API.

Features

  • Real-time Data Access: Get real-time analytics data for current active users and activity

  • Custom Reports: Create comprehensive reports with custom dimensions and metrics

  • Quick Insights: Predefined analytics insights for common use cases

  • Metadata Discovery: Get available dimensions and metrics for your Google Analytics property

  • Smart Error Handling: Detailed error messages with actionable solutions for permission issues

  • Standard MCP Interface: Works with any MCP-compatible client

Related MCP server: Google Analytics MCP Server

Installation

npm install @toolsdk.ai/google-analytics-mcp

Prerequisites

  • Node.js >= 18.0.0

  • Google Analytics 4 property

  • Google Cloud service account with appropriate permissions

Setup

1. Google Cloud Service Account Setup

  1. Create a Google Cloud service account with the "Viewer" role for your Google Analytics property

  2. Download the service account key as JSON

  3. Add the service account to your Google Analytics property with Viewer access:

    • Go to Google Analytics (analytics.google.com)

    • Navigate to Admin > Property Access Management

    • Add your service account email with Viewer access

2. Environment Configuration

Create a .env file in your project root with the following content:

GOOGLE_CREDENTIALS='{"type":"service_account","project_id":"your-project-id","private_key_id":"your-private-key-id","private_key":"-----BEGIN PRIVATE KEY-----\nYOUR_PRIVATE_KEY\n-----END PRIVATE KEY-----\n","client_email":"your-service-account@your-project.iam.gserviceaccount.com","client_id":"your-client-id","auth_uri":"https://accounts.google.com/o/oauth2/auth","token_uri":"https://oauth2.googleapis.com/token","auth_provider_x509_cert_url":"https://www.googleapis.com/oauth2/v1/certs","client_x509_cert_url":"https://www.googleapis.com/robot/v1/metadata/x509/your-service-account%40your-project.iam.gserviceaccount.com"}'

Note: Make sure to properly format the private key with \n for newlines.

Usage

Use ToolSDK.ai

import { ToolSDKApiClient } from 'toolsdk/api';
const toolSDK = new ToolSDKApiClient();
// Get Tools
const GoogleAnalyticsMCP = await toolSDK.package('@toolsdk.ai/google-analytics-mcp', {
  GOOGLE_CREDENTIALS: process.env.GOOGLE_CREDENTIALS,
});

Use Claude

{
  "mcpServers": {
    "google-analytics-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@toolsdk.ai/google-analytics-mcp"
      ],
      "env": {
        "GOOGLE_CREDENTIALS": "Your Google Credentials JSON String"
      }
    }
  }
}

Available Tools

analytics_report

Get comprehensive Google Analytics data with custom dimensions and metrics. Can create any type of report.

Parameters:

  • propertyId (string, required): Google Analytics property ID

  • startDate (string, required): Start date (YYYY-MM-DD)

  • endDate (string, required): End date (YYYY-MM-DD)

  • dimensions (array, optional): Dimensions to query

  • metrics (array, required): Metrics to query

  • dimensionFilter (object, optional): Filter by dimension values

  • metricFilter (object, optional): Filter by metric values

  • orderBy (object, optional): Sort results by dimension or metric

  • limit (number, optional): Limit number of results (default: 100)

realtime_data

Get real-time analytics data for current active users and activity.

Parameters:

  • propertyId (string, required): Google Analytics property ID

  • dimensions (array, optional): Dimensions for real-time data

  • metrics (array, optional): Real-time metrics (default: ['activeUsers'])

  • limit (number, optional): Limit number of results (default: 50)

quick_insights

Get predefined analytics insights for common use cases.

Parameters:

  • propertyId (string, required): Google Analytics property ID

  • startDate (string, required): Start date (YYYY-MM-DD)

  • endDate (string, required): End date (YYYY-MM-DD)

  • reportType (string, required): Type of quick insight report (overview, top_pages, traffic_sources, etc.)

  • limit (number, optional): Limit number of results (default: 20)

get_metadata

Get available dimensions and metrics for Google Analytics property.

Parameters:

  • propertyId (string, required): Google Analytics property ID

  • type (string, optional): Type of metadata to retrieve (dimensions, metrics, both)

search_metadata

Search for specific dimensions or metrics by name or category.

Parameters:

  • propertyId (string, required): Google Analytics property ID

  • query (string, required): Search term to find dimensions/metrics

  • type (string, optional): Type of metadata to search (dimensions, metrics, both)

  • category (string, optional): Filter by category

Error Handling

The server provides detailed error messages with actionable solutions:

  • Permission Errors: Clear instructions on how to grant access to your service account

  • Configuration Errors: Guidance on setting up environment variables correctly

  • API Errors: Detailed information about what went wrong with the Google Analytics API

License

MIT

Available Tools

5 tools
analytics_reportAnalytics ReportC

Get comprehensive Google Analytics data with custom dimensions and metrics. Can create any type of report.

ParametersJSON Schema
NameRequiredDescriptionDefault
propertyIdYesGoogle Analytics property ID (e.g., 123456789). Required for all queries.
startDateYesStart date (YYYY-MM-DD)
endDateYesEnd date (YYYY-MM-DD)
dimensionsNoDimensions to query (e.g., country, pagePath, sessionSource)
metricsYesMetrics to query (e.g., activeUsers, sessions, screenPageViews)
dimensionFilterNoFilter by dimension values
metricFilterNoFilter by metric values
orderByNoSort results by dimension or metric
limitNoLimit number of results

TDQS

C2.9/5.0
Behavior2/5

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

No annotations exist, so the description must disclose behavior. It does not mention read-only nature, rate limits, authentication needs, or data freshness. Only states it 'gets data', but lacks behavioral context.

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

Conciseness4/5

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

Two sentences, no fluff. However, the second sentence adds little value and could be merged or improved. Overall concise but not maximally informative.

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

Completeness2/5

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

With 9 parameters, 4 required, nested objects, and no output schema, the description is insufficient. It lacks guidance on constructing reports, response format, and limitations.

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 baseline is 3. The description adds 'custom dimensions and metrics' but does not enhance understanding beyond the schema's parameter descriptions.

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 it fetches Google Analytics data with custom dimensions and metrics, distinguishing it from sibling tools like realtime_data and quick_insights. However, the claim 'any type of report' is vague and lacks specificity.

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?

No guidance on when to use this tool versus alternatives. The description implies it is for comprehensive custom reports but does not mention exclusions or when to choose sibling tools.

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

get_metadataGet Analytics MetadataA

Get available dimensions and metrics for Google Analytics property

ParametersJSON Schema
NameRequiredDescriptionDefault
propertyIdYesGoogle Analytics property ID (e.g., 123456789). Required for all queries.
typeNoType of metadata to retrieveboth

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description alone must disclose behavioral traits. It fails to mention that the tool is read-only or any permissions needed, leaving the agent without assurance of side effects.

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 concise sentence with no wasted words, front-loaded with the key action and resource.

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

Completeness3/5

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

For a simple retrieval tool with two parameters, the description is adequate but not complete. It does not indicate the return format or mention that no output schema exists, which could help the agent plan subsequent steps.

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 the schema already explains both parameters. The description adds no additional meaning beyond what the schema provides, meeting the baseline.

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 'Get available dimensions and metrics for Google Analytics property' clearly states the verb ('Get') and the resource ('available dimensions and metrics'), which is specific and distinguishes it from sibling tools like 'realtime_data' and 'analytics_report'.

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 description does not provide explicit guidance on when to use this tool versus alternatives, such as 'search_metadata'. The purpose is implied but no 'when not to use' or context is given.

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

quick_insightsQuick InsightsC

Get predefined analytics insights for common use cases

ParametersJSON Schema
NameRequiredDescriptionDefault
propertyIdYesGoogle Analytics property ID (e.g., 123456789). Required for all queries.
startDateYesStart date (YYYY-MM-DD)
endDateYesEnd date (YYYY-MM-DD)
reportTypeYesType of quick insight report
limitNoLimit number of results

TDQS

C2.9/5.0
Behavior2/5

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

No annotations provided, so description must disclose behavioral traits. It indicates read-only analytics, but lacks details on data freshness, caching, permissions, or side effects. The description is insufficient for a mutation-free tool.

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

Conciseness4/5

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

Single sentence is concise and front-loaded. However, it could include more actionable information without becoming verbose.

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

Completeness2/5

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

With 5 parameters and no output schema, the description should detail return values or pagination. It does not explain what the insights contain, how 'limit' works, or date formats, leaving the agent underinformed.

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 covers 100% of parameters with descriptions, so the tool's description adds no extra meaning. However, it does not harm. Baseline 3 is appropriate as description doesn't compensate but is not needed.

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?

Description states verb 'Get' and resource 'predefined analytics insights', implying a read operation for common use cases. It distinguishes from siblings like 'realtime_data' and 'analytics_report' by focusing on predefined reports, but could be more specific about the types of insights.

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?

No guidance on when to use this tool versus siblings or alternatives. Does not mention prerequisites, limitations, or comparison to 'analytics_report' for custom reports.

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

realtime_dataReal-time DataC

Get real-time analytics data for current active users and activity

ParametersJSON Schema
NameRequiredDescriptionDefault
propertyIdYesGoogle Analytics property ID (e.g., 123456789). Required for all queries.
dimensionsNoDimensions for real-time data (e.g., country, city, pagePath)
metricsNoReal-time metrics (default: activeUsers)
limitNoLimit number of results

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are present, so the description must fully disclose behavioral traits. It only states the tool retrieves data, omitting whether it is read-only, any required authentication, rate limits, or limitations (e.g., data freshness). This is insufficient for safe invocation.

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

Conciseness4/5

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

The description is a single, clear sentence with no wasted words. It is front-loaded and efficient, though it could be slightly expanded to cover key context without losing conciseness.

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

Completeness2/5

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

Given no output schema, the description should explain what data is returned (structure, fields, pagination). It only vaguely mentions 'real-time analytics data for current active users and activity', leaving significant gaps for an agent to understand the output.

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?

With 100% schema description coverage, the schema already documents all parameters. The description adds no further meaning beyond the schema, so the baseline score of 3 applies. No enrichment is provided.

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 tool retrieves real-time analytics data for current active users and activity, using the verb 'Get' and specifying the resource. However, it could be more precise about the data source (Google Analytics) and slightly differentiates from siblings like 'analytics_report' which likely covers historical data.

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?

No guidance is provided on when to use this tool versus alternatives like 'analytics_report' or 'quick_insights'. The description does not mention context, prerequisites, or exclusions, leaving the agent to infer usage.

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

search_metadataSearch Analytics MetadataC

Search for specific dimensions or metrics by name or category

ParametersJSON Schema
NameRequiredDescriptionDefault
propertyIdYesGoogle Analytics property ID (e.g., 123456789). Required for all queries.
queryYesSearch term to find dimensions/metrics
typeNoType of metadata to searchboth
categoryNoFilter by category (e.g., "USER", "SESSION", "PAGE", "EVENT")

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as read-only nature, authorization needs, or side effects. The search behavior is implied but not explicitly stated.

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

Conciseness4/5

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

The description is extremely concise—one sentence that is front-loaded. It could benefit from slightly more detail, but it is not verbose.

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

Completeness2/5

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

With no output schema and 4 parameters, the description is too brief. It does not explain return values, pagination, or any behavioral specifics, leaving gaps for the agent.

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 baseline is 3. The description does not add meaning beyond the schema; it simply restates the search purpose. No additional parameter context provided.

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 it searches for dimensions or metrics by name or category. It uses a specific verb and resource, but doesn't distinguish from the sibling 'get_metadata' tool.

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?

No guidance on when to use this tool versus alternatives like 'get_metadata'. The description only states the purpose, not the context or exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv1.0.5
    • First observedanalytics_report
    • First observedget_metadata
    • First observedquick_insights
    • First observedrealtime_data
    • First observedsearch_metadata
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored across 5 tools

Disambiguation5/5

Each tool targets a distinct aspect of Google Analytics: general-report, metadata, predefined insights, real-time data, and metadata search. There is no overlap, and even the general reporting tool is clearly separated from the predefined insights.

Naming Consistency3/5

Tool names mix imperative verbs ('get_', 'search_') with descriptive noun phrases ('analytics_report', 'quick_insights', 'realtime_data'). This inconsistency makes the set less predictable, though all names are still readable.

Tool Count5/5

With 5 tools, the server is well-scoped for providing core analytics data access: metadata discovery, predefined insights, real-time tracking, and a flexible custom report generator. The number feels neither too few nor excessive.

Completeness4/5

The tool surface covers the main data retrieval use cases (custom reports, real-time, insights, metadata). A minor gap is the lack of a tool to list or select Google Analytics properties, which may require prior knowledge of property IDs.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Google Analytics MCP Server

    rinaldofesta
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables querying Google Analytics 4 data using natural language through MCP clients like Claude and Cursor, supporting 200+ dimensions and metrics for traffic, user behavior, and e-commerce analysis.
    MIT

  • Delmain GA4 MCP

    aline-delmain
    A
    license
    A
    quality
    D
    maintenance
    Enables querying Google Analytics 4 properties using natural language through MCP clients. Supports customizable reports with any dimensions and metrics, listing properties, and real-time data.
    4
    MIT

  • Google Analytics MCP Server

    kwp-lab
    A
    license
    A
    quality
    D
    maintenance
    Enables LLM applications to query and analyze Google Analytics 4 data through standard MCP interfaces, supporting service account and OAuth2 authentication.
    5
    14 npm
    MIT