Which integrations are available for this server?

Allows querying Google Analytics 4 data, including reports, traffic sources, demographics, page performance, conversion data, and custom reports.

How do I use GA4 Automation MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GA4 Automation MCP Server Show me the top 5 pages by views this week." 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.

GA4 Automation MCP Server

by mattwilkerson1121

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Local

GA4 Automation MCP Server

This project is a Google Analytics 4 (GA4) automation server implemented as a Model Context Protocol (MCP) tool. It lets AI agents query GA4 data (reports, traffic sources, demographics, etc.) and also includes a simple connection test script.

Related MCP server: google-analytics-mcp

1. Prerequisites

Node.js (recommended: a recent LTS, e.g. via nvm)
npm (comes with Node)
A GA4 property you have access to
A Google Cloud service account with:
- The Analytics Data API enabled
- Access to your GA4 property (Viewer or higher)

2. Clone the project and install dependencies

cd /<path-to-your-projects>/ga4-automation
git clone https://github.com/mattwilkerson1121/ga-ai-mcp-server/ # or copy the folder another way
cd ga4-automation

npm install

(If the repo is already on disk, just cd /<path-to-your-project>/ga4-automation and run npm install.)

3. Create your GA4 service account key

Go to Google Cloud Console → IAM & Admin → Service Accounts.
Create or select a service account.
Under Keys, create a new JSON key and download it.
Save the JSON key file into the project root as:

/<path-to-project-folder>/ga4-automation/credentials.json

In GA4, grant this service account email access to your property:
- Admin → Property Access Management → Add user → paste the service account email → give at least Viewer.

4. Configure environment and test script

The test script (test-connection.js) uses environment variables (and .env) to locate credentials and GA4 properties.

Create a .env file in the project root:

cd /<path-to-project-folder>/ga4-automation
cat > .env << 'EOF'
GOOGLE_APPLICATION_CREDENTIALS=/<path-to-project-folder>/ga4-automation/credentials.json
GA_PROPERTY_ID=<your-ga4-property-id>   # for multiple properties use comma‑separated list of your GA4 property IDs
EOF

Key variables:

GOOGLE_APPLICATION_CREDENTIALS: absolute path to your service account JSON.
GA_PROPERTY_ID: one or more GA4 property IDs, separated by commas.

Run the GA4 connection test

From the project root:

cd /<path-to-project-folder>/ga4-automation
npm run test:connection

Expected behavior:

For each property ID you configured, it will:
- Run a small GA4 report
- Print metrics like activeUsers, sessions, screenPageViews, newUsers
- Show any permission or configuration errors with helpful hints

If you see a message like:

Credentials file not found → check GOOGLE_APPLICATION_CREDENTIALS and file path.
PERMISSION_DENIED → ensure the service account has access to the GA4 property.
NOT_FOUND → the property ID is probably incorrect.

5. MCP server overview (`src/index.js`)

The main GA4 automation server is implemented in src/index.js as an MCP server over stdio (not an HTTP server).

It:
- Reads the credentials file at credentials.json in the project root.
- Creates a GoogleAuth and BetaAnalyticsDataClient.
- Exposes several tools such as:
  - query_analytics
  - get_realtime_data
  - get_traffic_sources
  - get_user_demographics
  - get_page_performance
  - get_conversion_data
  - get_custom_report
- Connects to an MCP client via stdin/stdout (StdioServerTransport).

You don’t hit this server via a browser or curl; instead, an MCP‑aware client (like Claude Desktop) launches and talks to it.

6. Running the MCP server manually (for sanity checks)

From the project root:

cd /<path-to-project-folder>/ga4-automation

# Quick syntax check (no execution)
node --check src/index.js

# Start the server (will wait for MCP messages on stdin)
npm start

The npm start script is defined in package.json as:

NODE_OPTIONS='--no-deprecation' node src/index.js

If you run npm start in a normal terminal, it will just wait because no MCP client is connected to its stdin/stdout. That’s expected.

7. Using the server from Claude (MCP)

This project already includes an example Claude MCP configuration. You will need to update the contents with the appropriate paths and then copy the json and add it to your Claude Desktop Configuration file (you can find the path to the file in the Claude AI Desktop App by going to settings > developer > and clicking the edit config button):

claude-config.json:

{
  "mcpServers": {
    "ga4-analytics": {
      "command": "/Users/<your-user-name>/.nvm/versions/node/<your-node-version>/bin/node",
      "args": [
        "/<path-to-project-folder>/ga4-automation/src/index.js"
      ],
      "env": {
        "GOOGLE_APPLICATION_CREDENTIALS": "/<path-to-project-folder>/ga4-automation/credentials.json",
        "GA4_PROPERTY_ID": "<your-ga4-property-id>",
        "NODE_OPTIONS": "--no-deprecation"
      }
    }
  }
}

Steps to use with Claude Desktop

Copy claude-config.json into (or merge it with) Claude’s MCP config file location (varies by OS; see Claude documentation).
Adjust all absolute paths to match your environment:
- command (your Node binary path)
- args[0] (path to src/index.js)
- GOOGLE_APPLICATION_CREDENTIALS
- GA4_PROPERTY_ID value(s)
Restart Claude Desktop so it picks up the new MCP server.
In Claude, ask something like:
- “Use the ga4-analytics tool to get page performance data for the last 7 days.”
- "Query Analytics and show me the number of new users for 01/01/2025 to 01/31/2025"
- "Create a table with columns containing the metric name in the header and show me the number of sessions, new users, and the percentage of new users vs total users for the last 30 days in a row corresponding to the correct columns."

Claude will:

Spawn the Node MCP server using the command/args from claude-desktop-config.json.
Call the tools you defined (get_page_performance, etc.) to run GA4 reports.

8. Example tool payloads (conceptual)

These examples show the shape of the tool inputs the MCP server expects. The actual wiring is handled by the MCP client (Claude); you normally do not send this JSON manually, but this should give you an idea on how to structure your prompts in the Claude UI.

Example: `query_analytics`

{
  "propertyId": "<your-ga4-property-id>",
  "startDate": "2025-01-01",
  "endDate": "2025-01-31",
  "dimensions": ["country", "city"],
  "metrics": ["sessions", "activeUsers"]
}

Example: `get_page_performance`

{
  "propertyId": "<your-ga4-property-id>",
  "startDate": "2025-01-01",
  "endDate": "2025-01-31",
  "limit": 50
}

The responses are normalized into a JSON structure containing:

rows: an array of objects (dimension/metric name → value)
rowCount: number of rows
totals: any totals provided by GA4

9. Troubleshooting

node: command not found
- Install Node (e.g. brew install node or nvm install --lts) and open a new terminal.
ENOENT: no such file or directory, open 'credentials.json'
- Ensure a valid JSON key exists at:
  - /<path-to-project-folder>/ga4-automation/credentials.json, or
  - Update src/index.js to point at credentials.json.
PERMISSION_DENIED when running npm run test:connection
- Confirm the service account has access to the GA4 property in GA4 Admin.
NOT_FOUND: Property ID
- Check for typos in GA_PROPERTY_ID / GA4_PROPERTY_ID.

If you hit an error that isn’t covered here, capture the full stack trace and logs from npm run test:connection or the MCP client and adjust credentials, env vars, or GA4 access as needed.

If you continually run into errors you may need to clear the cache for the Claude Desktop App.

Available Tools

7 tools

get_conversion_dataC

Get conversion and event data including conversion events and e-commerce metrics

ParametersJSON Schema

Name	Required	Description
`propertyId`	Yes	GA4 property ID
`startDate`	Yes	Start date in YYYY-MM-DD format
`endDate`	Yes	End date in YYYY-MM-DD format

TDQS

C2.6/5.0

Behavior2/5

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

No annotations provided, and description only says 'Get' without disclosing any behavioral traits (e.g., read-only, potential for large data, required permissions, pagination). An agent has no indication of side effects or constraints.

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, 12 words. No fluff, but sacrifices informativeness for brevity. Could include more details without being wordy.

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?

No output schema, so description should provide hints about return format, metrics available, or pagination. Lacks context for a tool with 3 required params and multiple siblings. Incomplete for accurate agent use.

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 clear descriptions. The description adds no additional semantic value beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

States it gets conversion and event data, but vague on specifics. Does not differentiate from siblings like get_custom_report or query_analytics. A more specific resource (e.g., GA4 conversion report) would improve clarity.

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 vs alternatives. Agent cannot determine if this is the right tool for conversion data compared to other analytics tools. No mention of prerequisites or context.

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

get_custom_reportC

Get a custom report with specified dimensions, metrics, date ranges, and filters

ParametersJSON Schema

Name	Required	Description
`propertyId`	Yes	GA4 property ID
`startDate`	Yes	Start date in YYYY-MM-DD format
`endDate`	Yes	End date in YYYY-MM-DD format
`dimensions`	No	Array of dimension names
`metrics`	Yes	Array of metric names
`dimensionFilter`	No	Optional dimension filter object
`metricFilter`	No	Optional metric filter object
`limit`	No	Maximum number of rows to return
`offset`	No	Row offset for pagination

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 should disclose behavioral traits. It does not mention rate limits, authentication, data freshness, pagination limits, or error handling.

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 sentence with no extraneous text. It is concise, but could be structured with more useful details 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 9 parameters, no output schema, and no annotations, the description is insufficient. It does not cover output format, error responses, or data source specifics.

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 descriptions cover all 9 parameters (100%), so baseline is 3. The description adds no extra meaning beyond listing parameter categories, not explaining valid values or filter structures.

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 a custom report with configurable dimensions, metrics, date ranges, and filters. However, it does not explicitly differentiate from sibling specialized report tools.

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 get_conversion_data or get_page_performance. The description lacks any usage context.

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

get_page_performanceB

Get page performance metrics including page views, bounce rate, and time on page

ParametersJSON Schema

Name	Required	Description
`propertyId`	Yes	GA4 property ID
`startDate`	Yes	Start date in YYYY-MM-DD format
`endDate`	Yes	End date in YYYY-MM-DD format
`limit`	No	Maximum number of pages to return

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only lists three metrics. It does not disclose ordering, pagination behavior, date range interpretation, data freshness, or what happens with missing data. Critical behavioral traits for a data retrieval tool are omitted.

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, clear sentence that efficiently communicates the tool's purpose without superfluous words. Every part serves a function.

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 describe the response structure. It only mentions metrics but not that the result is a list of pages (implied by limit parameter) or how pages are identified. Missing output details reduce completeness for an agent.

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 baseline is 3. The description adds value by specifying the exact metrics returned (page views, bounce rate, time on page), which the schema does not include. This helps the agent understand what data to expect beyond parameter types.

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 specifies the verb 'Get' and the resource 'page performance metrics', listing key metrics (page views, bounce rate, time on page). It is distinct from sibling tools like get_traffic_sources or get_conversion_data, which focus on different analytics dimensions.

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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or preferred scenarios. The agent is left to infer usage solely from the tool name and sibling list.

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

get_realtime_dataB

Get real-time analytics data from GA4

ParametersJSON Schema

Name	Required	Description
`propertyId`	Yes	GA4 property ID
`dimensions`	No	Optional array of dimension names
`metrics`	Yes	Array of metric names for real-time data

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries full burden to disclose traits like read-only behavior, auth needs, or rate limits. It only states the function, offering no behavioral details.

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 sentence with no wasted words. It is appropriately concise for a simple tool.

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 and no annotations, the description is insufficient. It does not explain return format, usage context, or how it differs from siblings, making it incomplete.

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 all parameters described (propertyId, dimensions, metrics). The description adds no additional meaning beyond the schema, meeting the baseline for high coverage.

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 'Get' and the specific resource 'real-time analytics data from GA4', distinguishing it from sibling tools that likely provide other analytics data types. The verb+resource is 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.

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 get_conversion_data or query_analytics. It also lacks any context on prerequisites or scenarios.

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

get_traffic_sourcesB

Get traffic source data including channels, sources, and mediums

ParametersJSON Schema

Name	Required	Description
`propertyId`	Yes	GA4 property ID
`startDate`	Yes	Start date in YYYY-MM-DD format
`endDate`	Yes	End date in YYYY-MM-DD format

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It does not mention whether this is a read-only operation, any required permissions, rate limits, or data freshness, leaving significant gaps for an agent.

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 sentence that immediately states the action and key contents. It is front-loaded and contains no unnecessary words.

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?

Given the tool has no output schema and no annotations, the description is minimally adequate. It hints at the return structure but omits details like aggregation, time granularity, or pagination, leaving gaps for a complete understanding.

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% description coverage, so baseline is 3. The description adds minimal extra meaning beyond listing the returned dimensions (channels, sources, mediums), which is useful but does not compensate for the lack of parameter details already present in the schema.

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 'Get' with the resource 'traffic source data' and explicitly lists what it includes (channels, sources, mediums), making the purpose clear and distinct from sibling tools like get_page_performance or get_conversion_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. There is no mention of context, prerequisites, or exclusions, leaving the agent without direction.

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

get_user_demographicsB

Get user demographic data including age, gender, and interests

ParametersJSON Schema

Name	Required	Description
`propertyId`	Yes	GA4 property ID
`startDate`	Yes	Start date in YYYY-MM-DD format
`endDate`	Yes	End date in YYYY-MM-DD format

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, and the description only states what data is retrieved without mentioning permissions, rate limits, data freshness, or aggregation behavior. For a read operation, it lacks important 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.

Conciseness5/5

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

Single sentence, front-loaded with the action and resource, no unnecessary words. Efficient and to the point.

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?

No output schema, and the description does not explain the return structure or data format. It also lacks notes on date range implications or data aggregation, making it incomplete for a data retrieval tool.

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 covers all 3 parameters with descriptions (100% coverage). Description adds value by mentioning the specific data items (age, gender, interests) not in the schema, but lacks additional format or constraint details.

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?

Description clearly states the verb 'Get' and resource 'user demographic data', listing specific fields (age, gender, interests). It distinguishes from sibling tools like get_conversion_data which focus on different 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 on when to use this tool versus alternatives, nor any context on prerequisites or typical use cases. The description is purely declarative.

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

query_analyticsC

Query Google Analytics 4 data with custom dimensions, metrics, and date ranges

ParametersJSON Schema

Name	Required	Description
`propertyId`	Yes	325253028
`startDate`	Yes	Start date in YYYY-MM-DD format
`endDate`	Yes	End date in YYYY-MM-DD format
`dimensions`	No	Array of dimension names (e.g., ["country", "city"])
`metrics`	Yes	Array of metric names (e.g., ["sessions", "users"])

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, and description does not disclose read-only nature, rate limits, or side effects. Minimal transparency for a data query 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 that clearly communicates the tool's function. Efficient and to the point, though it lacks any structure beyond one line.

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?

No output schema, no annotations, and no behavioral context. For a GA4 query tool with 5 parameters, more detail on return values and query limits is expected.

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 all 5 parameters with descriptions, but propertyId description is an example ('325253028') rather than a semantic explanation. The description adds 'custom dimensions, metrics, and date ranges' which reinforces schema but does not add new meaning.

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 it queries Google Analytics 4 data with custom dimensions, metrics, and date ranges, which is clear. However, it does not differentiate from siblings like get_conversion_data, but the verb 'query' and mention of 'custom' imply flexibility.

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 vs alternatives like get_custom_report or get_traffic_sources. Missing context such as prerequisites or authorization requirements.

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.

7 tool updatesv1.0.0Jun 12, 2026
- First observedget_conversion_data
- First observedget_custom_report
- First observedget_page_performance
- First observedget_realtime_data
- First observedget_traffic_sources
- First observedget_user_demographics
- First observedquery_analytics

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Scored 2026-06-12 11:35 across 7 tools

Disambiguation3/5

Most tools target distinct analytics areas, but 'get_custom_report' and 'query_analytics' have nearly identical descriptions, creating ambiguity. 'get_conversion_data' and 'get_page_performance' also overlap with the general query tool.

Naming Consistency3/5

Six tools follow the 'get_<noun>_data' or 'get_<adjective>_data' pattern, but 'get_custom_report' breaks the 'data' suffix and 'query_analytics' uses a different verb, resulting in mixed conventions.

Tool Count5/5

Seven tools cover the core retrieval needs for GA4 analytics without being excessive or too sparse, each serving a clear purpose.

Completeness4/5

The tool set covers major analytics dimensions (conversion, page performance, real-time, traffic, demographics) and includes a general query tool for custom needs, though some specific areas like events or retention are missing but can be handled via query_analytics.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

climbpast
io.github.archievi
Read and edit GA4, Search Console and Google Tag Manager from any MCP client. 29 tools.
Marketing Search Data Platforms
1
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
LeadFoxConnectOAuth
io.github.LeadFox-Shay
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
Marketing CRM
2
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24

Related MCP Servers

mcp-server-google-analytics
Monitoring Data Platforms Observability
ruchernchong
A
license
B
quality
F
maintenance
An MCP server implementation for accessing Google Analytics 4 (GA4) data, built using the Model Context Protocol TypeScript SDK.
Updated a year ago (2025-09-12 19:00 UTC)
5
498
71
MIT
google-analytics-mcp
Marketing Search Cloud Platforms
pkidwell22
A
license
Not graded
quality
D
maintenance
A powerful Model Context Protocol (MCP) server that provides comprehensive Google Analytics 4 (GA4), Google Search Console (GSC), and Google Merchant Center (GMC) integration for Claude Desktop and other MCP clients.
Updated a year ago (2025-10-01 00:02 UTC)
Apache 2.0
Google Ads MCP Server
Marketing Agent Orchestration
anegash
A
license
C
quality
D
maintenance
A comprehensive Google Ads API integration for AI assistants through the Model Context Protocol. This server enables Claude AI and other MCP-compatible clients to manage Google Ads campaigns, analyze performance, and execute GAQL queries with natural language commands.
Updated a year ago (2025-09-14 05:48 UTC)
76
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.
Updated 7 months ago (2026-02-09 08:54 UTC)
5
24
MIT

GA4 Automation MCP Server

1. Prerequisites

2. Clone the project and install dependencies

3. Create your GA4 service account key

4. Configure environment and test script

Run the GA4 connection test

5. MCP server overview (src/index.js)

6. Running the MCP server manually (for sanity checks)

7. Using the server from Claude (MCP)

Steps to use with Claude Desktop

8. Example tool payloads (conceptual)

Example: query_analytics

Example: get_page_performance

9. Troubleshooting

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

5. MCP server overview (`src/index.js`)

Example: `query_analytics`

Example: `get_page_performance`