Google Analytics MCP Server
OfficialThe Google Analytics MCP Server enables LLMs to interact with Google Analytics APIs through the Model Context Protocol. Key capabilities include:
Account and property management: Retrieve account summaries, get detailed property information, and list Google Ads links
Core reporting: Execute standard Google Analytics reports with custom date ranges, dimensions, metrics, filters, and sorting options
Real-time analytics: Access live data through real-time reports with specific dimensions and metrics
Custom configurations: Retrieve and utilize custom dimensions and metrics defined for tailored reporting
The server provides comprehensive access to Google Analytics data for analysis and reporting through structured API interactions.
Allows retrieval of Google Ads account links associated with Google Analytics properties.
Provides tools for interacting with Google Analytics Admin and Data APIs, enabling retrieval of account and property information, running core and realtime reports, and managing custom dimensions and metrics.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Google Analytics MCP Servershow me yesterday's top 5 pages by pageviews"
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.
Google Analytics MCP Server (Experimental)
This repo contains the source code for running a local MCP server that interacts with APIs for Google Analytics.
Join the discussion and ask questions in the 🤖-analytics-mcp channel on Discord.
Tools 🛠️
The server uses the Google Analytics Admin API and Google Analytics Data API to provide several Tools for use with LLMs.
Retrieve account and property information 🟠
get_account_summaries: Retrieves information about the user's Google Analytics accounts and properties.get_property_details: Returns details about a property.list_google_ads_links: Returns a list of links to Google Ads accounts for a property.
Run core reports 📙
run_report: Runs a Google Analytics report using the Data API.run_funnel_report: Runs a Google Analytics funnel report using the Data API.get_custom_dimensions_and_metrics: Retrieves the custom dimensions and metrics for a specific property.
Run realtime reports ⏳
run_realtime_report: Runs a Google Analytics realtime report using the Data API.
Related MCP server: GitHub MCP Server
Setup instructions 🔧
✨ Watch the Google Analytics MCP Setup Tutorial on YouTube for a step-by-step walkthrough of these instructions.

Setup involves the following steps:
Configure Python.
Configure credentials for Google Analytics.
Configure Gemini.
Configure Python 🐍
Enable APIs in your project ✅
Follow the instructions to enable the following APIs in your Google Cloud project:
Configure credentials 🔑
Configure your Application Default Credentials (ADC). Make sure the credentials are for a user with access to your Google Analytics accounts or properties.
Credentials must include the Google Analytics read-only scope:
https://www.googleapis.com/auth/analytics.readonlyCheck out Manage OAuth Clients for how to create an OAuth client.
Here are some sample gcloud commands you might find useful:
Set up ADC using user credentials and an OAuth desktop or web client after downloading the client JSON to
YOUR_CLIENT_JSON_FILE.gcloud auth application-default login \ --scopes https://www.googleapis.com/auth/analytics.readonly,https://www.googleapis.com/auth/cloud-platform \ --client-id-file=YOUR_CLIENT_JSON_FILESet up ADC using service account impersonation.
gcloud auth application-default login \ --impersonate-service-account=SERVICE_ACCOUNT_EMAIL \ --scopes=https://www.googleapis.com/auth/analytics.readonly,https://www.googleapis.com/auth/cloud-platform
When the gcloud auth application-default command completes, copy the
PATH_TO_CREDENTIALS_JSON file location printed to the console in the
following message. You'll need this for the next step!
Credentials saved to file: [PATH_TO_CREDENTIALS_JSON]Configure Gemini
Install Gemini CLI or Gemini Code Assist.
Create or edit the file at
~/.gemini/settings.json, adding your server to themcpServerslist.Replace
PATH_TO_CREDENTIALS_JSONwith the path you copied in the previous step.We also recommend that you add a
GOOGLE_CLOUD_PROJECTattribute to theenvobject. ReplaceYOUR_PROJECT_IDin the following example with the project ID of your Google Cloud project.{ "mcpServers": { "analytics-mcp": { "command": "pipx", "args": ["run", "analytics-mcp"], "env": { "GOOGLE_APPLICATION_CREDENTIALS": "PATH_TO_CREDENTIALS_JSON", "GOOGLE_PROJECT_ID": "YOUR_PROJECT_ID" } } } }
Configure Claude Code
Add the MCP server with the following command:
Replace
PATH_TO_CREDENTIALS_JSONwith the path you copied in the previous step, and replaceYOUR_PROJECT_IDwith the project ID of your Google Cloud project.claude mcp add analytics-mcp \ --scope user \ -e "GOOGLE_APPLICATION_CREDENTIALS=PATH_TO_CREDENTIALS_JSON" \ -e "GOOGLE_PROJECT_ID=YOUR_PROJECT_ID" \ -- pipx run analytics-mcp
Try it out 🥼
Launch Gemini Code Assist or Gemini CLI and type /mcp. You should see
analytics-mcp listed in the results.
Here are some sample prompts to get you started:
Ask what the server can do:
what can the analytics-mcp server do?Ask about a Google Analytics property
Give me details about my Google Analytics property with 'xyz' in the namePrompt for analysis:
what are the most popular events in my Google Analytics property in the last 180 days?Ask about signed-in users:
were most of my users in the last 6 months logged in?Ask about property configuration:
what are the custom dimensions and custom metrics in my property?
Contributing ✨
Contributions welcome! See the Contributing Guide.
Available Tools
9 toolsget_account_summariesB
Retrieves information about the user's Google Analytics accounts and properties.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states that information is retrieved, which implies a read operation. However, with no annotations, it fails to disclose potential behavioral traits like authentication requirements, rate limits, or error cases (e.g., empty account list).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource. It contains no unnecessary words or redundancy, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, the description is adequate but minimal. It lacks details about the output structure, potential limitations, or what constitutes 'summaries.' Given the absence of an output schema and annotations, more context would improve completeness.
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 zero parameters, so the description does not need to elaborate on parameter semantics. It correctly implies that the tool requires no input, which is consistent with a summary retrieval operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Retrieves' and specifies the resource as 'information about the user's Google Analytics accounts and properties.' This clearly communicates the core function and distinguishes it from sibling tools like get_property_details or run_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_property_details or list_google_ads_links. There are no exclusions or context cues to help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_custom_dimensions_and_metricsA
Returns the property's custom dimensions and metrics.
Args: property_id: The Google Analytics property ID. Accepted formats are: - A number - A string consisting of 'properties/' followed by a number
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits disclosed beyond being a read operation. With no annotations, the description fails to mention any side effects, permissions, rate limits, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The main purpose is front-loaded, and the parameter clarification follows efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool, the description explains the parameter format but omits return structure details. Given no output schema, more context on expected response would improve completeness.
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 description adds format guidance for property_id (number or 'properties/' prefix), which the schema lacks. This compensates for 0% schema coverage, though only one parameter is detailed.
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 it 'Returns the property's custom dimensions and metrics.' This is a specific verb+resource combination that distinguishes it from sibling tools like get_account_summaries or run_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description only states what it does without providing context about typical use cases or when to prefer it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_property_detailsB
Returns details about a property. Args: property_id: The Google Analytics property ID. Accepted formats are: - A number - A string consisting of 'properties/' followed by a number
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Returns details,' with no mention of read-only nature, auth requirements, or side effects. This is minimal.
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 parameter note, with no wasted words. It is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate but lacks details on what 'details' are returned. Given the context of sibling tools, more completeness on output would help.
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 description adds value beyond the schema by specifying accepted formats for property_id (number or 'properties/' string). Schema coverage is 0%, so this explanation helps agents use the parameter correctly.
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 states 'Returns details about a property,' which gives a clear verb and resource. It does not explicitly differentiate from siblings like 'get_account_summaries' or 'list_property_annotations,' but the tool name provides distinction.
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 no guidance on when to use this tool versus alternatives. No exclusions or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_google_ads_linksA
Returns a list of links to Google Ads accounts for a property.
Args: property_id: The Google Analytics property ID. Accepted formats are: - A number - A string consisting of 'properties/' followed by a number
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes a read operation (returns a list) but does not mention side effects, authentication requirements, rate limits, pagination behavior, or any limitation on the number of links returned.
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 extremely concise with two sentences. The first sentence immediately states the purpose, and the second addresses the parameter format. No redundant or filler content.
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 parameter format adequately, but fails to describe the return value structure (e.g., what fields are in each link object) or any pagination/limits. Given no output schema, the description should provide more to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only type info (integer or string) for property_id with 0% coverage. The description adds crucial format details: accepted formats are a number or a string 'properties/' followed by a number. This adds meaningful guidance 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 description clearly states 'Returns a list of links to Google Ads accounts for a property' which specifies the verb (returns), object (list of links), and resource (Google Ads accounts for a property). It distinguishes this tool from siblings like get_account_summaries and run_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_account_summaries or other list tools. It does not mention prerequisites, connected Google Ads accounts, or cases where the tool is applicable or inapplicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_property_annotationsA
Returns annotations for a property.
Annotations are a feature that allows you to leave notes on GA4 for specific dates or periods. They are typically used to record service releases, marketing campaign launches or changes, and rapid traffic increases or decreases due to external factors.
Args: property_id: The Google Analytics property ID. Accepted formats are: - A number - A string consisting of 'properties/' followed by a number
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits beyond returning annotations. Missing details on pagination, permissions, or side effects. The description minimally adds 'returns annotations' without depth.
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?
Description is five sentences, front-loaded with core purpose. Could be slightly more concise, but no unnecessary content. Structured with a clear separation between purpose, usage context, and parameter details.
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?
No output schema provided, but the description does not explain what the returned annotations contain (e.g., fields, pagination). Only states 'returns annotations', leaving the response structure undefined. Insufficient for an agent to fully understand the tool's output.
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%, but the description adds meaning to the single parameter 'property_id' by specifying accepted formats (number or string with 'properties/' prefix). This compensates for the schema's lack of description.
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?
Clearly states 'Returns annotations for a property' and explains what annotations are used for. Differentiates from sibling tools like get_property_details or run_report which serve different purposes.
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 context about when annotations are typically used (recording service releases, marketing campaigns, etc.), implying its use case. Does not explicitly state when not to use or alternatives, but the tool is the only one for annotations, making selection straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_conversions_reportA
Runs a Google Analytics Data API conversions report.
USE THIS TOOL INSTEAD OF `run_report` WHEN:
- You need to report specifically on conversions, ad performance, return on ad spend (ROAS), or attribution.
- You need to query specific conversion metrics (e.g., advertiserAdCost, returnOnAdSpendByInteractionDate, allConversionsByConversionDate, etc.).
- You need to apply a specific attribution model (e.g., DATA_DRIVEN or LAST_CLICK) to your data.
- The user's query explicitly asks about conversions, ad clicks, ad costs, or campaigns related to conversions.
See the conversions report guide at
https://developers.google.com/analytics/devguides/reporting/data/v1/conversions-api-basics
for details and examples.
Args:
property_id: The Google Analytics property ID. Accepted formats are:
- A number
- A string consisting of 'properties/' followed by a number
date_ranges: A list of date ranges
(https://developers.google.com/analytics/devguides/reporting/data/v1/rest/v1alpha/DateRange)
to include in the report.
dimensions: A list of dimensions to include in the report.
metrics: A list of metrics to include in the report.
conversion_spec: The specification for conversions reporting.
Should include 'conversion_actions' (list of resource names) and
'attribution_model'.
dimension_filter: A Data API FilterExpression
(https://developers.google.com/analytics/devguides/reporting/data/v1/rest/v1alpha/FilterExpression)
to apply to the dimensions.
metric_filter: A Data API FilterExpression
(https://developers.google.com/analytics/devguides/reporting/data/v1/rest/v1alpha/FilterExpression)
to apply to the metrics.
order_bys: A list of Data API OrderBy
(https://developers.google.com/analytics/devguides/reporting/data/v1/rest/v1alpha/OrderBy)
objects to apply to the dimensions and metrics.
limit: The maximum number of rows to return in each response. Value must
be a positive integer <= 250,000.
offset: The row count of the start row. The first row is counted as row 0.
currency_code: The currency code to use for currency values.
return_property_quota: Whether to return property quota in the response.
## Hints for arguments
Here are some hints that outline the expected format and requirements
for arguments.
### Hints for `dimensions`
The `dimensions` list must consist solely of the following allowed standard dimensions:
- campaignName
- continent
- country
- defaultChannelGroup
- deviceCategory
- medium
- platform
- primaryChannelGroup
- source
- sourceMedium
- sourcePlatform
- subcontinent
### Hints for `metrics`
The `metrics` list must consist solely of the following allowed standard metrics:
- advertiserAdClicks
- advertiserAdCost
- advertiserAdCostPerAllConversionsByConversionDate
- advertiserAdCostPerAllConversionsByInteractionDate
- advertiserAdCostPerClick
- advertiserAdImpressions
- allConversionsByConversionDate
- allConversionsByInteractionDate
- returnOnAdSpendByConversionDate
- returnOnAdSpendByInteractionDate
- totalRevenueByConversionDate
- totalRevenueByInteractionDate
### Hints for `conversion_spec`
The `conversion_spec` argument is required for conversions reporting.
You can pass an empty list for `conversion_actions` if you want all conversion events.
Example:
{
"conversion_actions": ["conversionActions/12345"], # Or [] for all actions
"attribution_model": "DATA_DRIVEN" # Or "LAST_CLICK"
}
### Hints for `date_ranges`:
Example date_range arguments:
1. A single date range:
[ {"start_date": "2025-01-01", "end_date": "2025-01-31", "name": "Jan2025"} ]
2. A relative date range using 'yesterday' and 'today':
[ {"start_date": "yesterday", "end_date": "today", "name": "YesterdayAndToday"} ]
3. A relative date range using 'NdaysAgo' and 'today':
[ {"start_date": "30daysAgo", "end_date": "yesterday", "name": "Previous30Days"}]
4. Multiple date ranges:
[ {"start_date": "2025-01-01", "end_date": "2025-01-31", "name": "Jan2025"}, {"start_date": "2025-02-01", "end_date": "2025-02-28", "name": "Feb2025"} ]
### Hints for `dimension_filter`:
Example dimension_filter arguments:
1. A simple filter:
{"filter": {"field_name": "eventName", "string_filter": {"match_type": 2, "value": "add", "case_sensitive": false}}}
2. A NOT filter:
{"not_expression": {"filter": {"field_name": "eventName", "string_filter": {"match_type": 2, "value": "add", "case_sensitive": false}}}}
3. An empty value filter:
{"filter": {"field_name": "source", "empty_filter": {}}}
4. An AND group filter:
{"and_group": {"expressions": [{"filter": {"field_name": "sourceMedium", "string_filter": {"match_type": 1, "value": "google / cpc", "case_sensitive": false}}}, {"filter": {"field_name": "eventName", "in_list_filter": {"values": ["first_visit", "purchase", "add_to_cart"], "case_sensitive": true}}}]}}
5. An OR group filter:
{"or_group": {"expressions": [{"filter": {"field_name": "sourceMedium", "string_filter": {"match_type": 1, "value": "google / cpc", "case_sensitive": false}}}, {"filter": {"field_name": "eventName", "in_list_filter": {"values": ["first_visit", "purchase", "add_to_cart"], "case_sensitive": true}}}]}} Notes:
The API applies the dimension_filter and metric_filter
independently. As a result, some complex combinations of dimension and
metric filters are not possible in a single report request.
For example, you can't create a `dimension_filter` and `metric_filter`
combination for the following condition:
(
(eventName = "page_view" AND eventCount > 100)
OR
(eventName = "join_group" AND eventCount < 50)
)
This isn't possible because there's no way to apply the condition
"eventCount > 100" only to the data with eventName of "page_view", and
the condition "eventCount < 50" only to the data with eventName of
"join_group".
More generally, you can't define a `dimension_filter` and `metric_filter`
for:
(
((dimension condition D1) AND (metric condition M1))
OR
((dimension condition D2) AND (metric condition M2))
)
If you have complex conditions like this, either:
a) Run a single report that applies a subset of the conditions that
the API supports as well as the data needed to perform filtering of the
API response on the client side. For example, for the condition:
(
(eventName = "page_view" AND eventCount > 100)
OR
(eventName = "join_group" AND eventCount < 50)
)
You could run a report that filters only on:
eventName one of "page_view" or "join_group"
and include the eventCount metric, then filter the API response on the
client side to apply the different metric filters for the different
events.
or
b) Run a separate report for each combination of dimension condition and
metric condition. For the example above, you'd run one report for the
combination of (D1 AND M1), and another report for the combination of
(D2 AND M2).
Try to run fewer reports (option a) if possible. However, if running
fewer reports results in excessive quota usage for the API, use option
b. More information on quota usage is at
https://developers.google.com/analytics/blog/2023/data-api-quota-management.
### Hints for `metric_filter`:
Example metric_filter arguments:
1. A simple filter:
{"filter": {"field_name": "eventCount", "numeric_filter": {"operation": 4, "value": {"int64_value": "10"}}}}
2. A NOT filter:
{"not_expression": {"filter": {"field_name": "eventCount", "numeric_filter": {"operation": 4, "value": {"int64_value": "10"}}}}}
3. An empty value filter:
{"filter": {"field_name": "purchaseRevenue", "empty_filter": {}}}
4. An AND group filter:
{"and_group": {"expressions": [{"filter": {"field_name": "eventCount", "numeric_filter": {"operation": 4, "value": {"int64_value": "10"}}}}, {"filter": {"field_name": "purchaseRevenue", "between_filter": {"from_value": {"double_value": 10.0}, "to_value": {"double_value": 25.0}}}}]}}
5. An OR group filter:
{"or_group": {"expressions": [{"filter": {"field_name": "eventCount", "numeric_filter": {"operation": 4, "value": {"int64_value": "10"}}}}, {"filter": {"field_name": "purchaseRevenue", "between_filter": {"from_value": {"double_value": 10.0}, "to_value": {"double_value": 25.0}}}}]}} Notes:
The API applies the dimension_filter and metric_filter
independently. As a result, some complex combinations of dimension and
metric filters are not possible in a single report request.
For example, you can't create a `dimension_filter` and `metric_filter`
combination for the following condition:
(
(eventName = "page_view" AND eventCount > 100)
OR
(eventName = "join_group" AND eventCount < 50)
)
This isn't possible because there's no way to apply the condition
"eventCount > 100" only to the data with eventName of "page_view", and
the condition "eventCount < 50" only to the data with eventName of
"join_group".
More generally, you can't define a `dimension_filter` and `metric_filter`
for:
(
((dimension condition D1) AND (metric condition M1))
OR
((dimension condition D2) AND (metric condition M2))
)
If you have complex conditions like this, either:
a) Run a single report that applies a subset of the conditions that
the API supports as well as the data needed to perform filtering of the
API response on the client side. For example, for the condition:
(
(eventName = "page_view" AND eventCount > 100)
OR
(eventName = "join_group" AND eventCount < 50)
)
You could run a report that filters only on:
eventName one of "page_view" or "join_group"
and include the eventCount metric, then filter the API response on the
client side to apply the different metric filters for the different
events.
or
b) Run a separate report for each combination of dimension condition and
metric condition. For the example above, you'd run one report for the
combination of (D1 AND M1), and another report for the combination of
(D2 AND M2).
Try to run fewer reports (option a) if possible. However, if running
fewer reports results in excessive quota usage for the API, use option
b. More information on quota usage is at
https://developers.google.com/analytics/blog/2023/data-api-quota-management.
### Hints for `order_bys`:
Example order_bys arguments:
1. Order by ascending 'eventName':
[ {"dimension": {"dimension_name": "eventName", "order_type": 1}, "desc": false} ]
2. Order by descending 'eventName', ignoring case:
[ {"dimension": {"dimension_name": "campaignName", "order_type": 2}, "desc": true} ]
3. Order by ascending 'audienceId':
[ {"dimension": {"dimension_name": "audienceId", "order_type": 3}, "desc": false} ]
4. Order by descending 'eventCount':
[ {"metric": {"metric_name": "eventValue"}, "desc": true} ]
5. Order by ascending 'eventCount':
[ {"metric": {"metric_name": "eventCount"}, "desc": false} ]
6. Combination of dimension and metric order bys:
[
{"dimension": {"dimension_name": "eventName", "order_type": 1}, "desc": false},
{"metric": {"metric_name": "eventValue"}, "desc": true},
]
7. Order by multiple dimensions and metrics:
[
{"dimension": {"dimension_name": "eventName", "order_type": 1}, "desc": false},
{"dimension": {"dimension_name": "audienceId", "order_type": 3}, "desc": false},
{"metric": {"metric_name": "eventValue"}, "desc": true},
]
The dimensions and metrics in order_bys must also be present in the report
request's "dimensions" and "metrics" arguments, respectively.| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| metrics | Yes | ||
| order_bys | No | ||
| dimensions | Yes | ||
| date_ranges | Yes | ||
| property_id | Yes | ||
| currency_code | No | ||
| metric_filter | No | ||
| conversion_spec | Yes | ||
| dimension_filter | No | ||
| return_property_quota | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses API behavior: dimension and metric filters are applied independently, and explains limitations and workarounds for complex filter combinations. Also mentions quota management.
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 long but well-structured: purpose sentence, usage guidelines, args, hints with examples. Front-loaded with key info. Slightly verbose but justified by tool complexity.
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 12 parameters, nested objects, no output schema, and no annotations, the description covers all major aspects: allowed values, filter limitations, workarounds, quota advice, and documentation links. Thoroughly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description compensates fully with detailed hints for each parameter: allowed dimensions/metrics lists, conversion_spec format, date range examples, filter and order by examples. Adds significant semantic meaning beyond schema names.
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 it runs a Google Analytics Data API conversions report. It explicitly distinguishes from sibling tool 'run_report' by listing specific use cases like conversions, ad performance, ROAS, and attribution.
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 conditions and names the alternative tool 'run_report'. Includes extensive hints, examples, and workarounds for complex filters, making it clear when and how 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.
run_funnel_reportA
Run a Google Analytics Data API funnel report.
See the funnel report guide at
https://developers.google.com/analytics/devguides/reporting/data/v1/funnels
for details and examples.
Args:
property_id: The Google Analytics property ID. Accepted formats are:
- A number
- A string consisting of 'properties/' followed by a number
funnel_steps: A list of funnel steps. Each step should be a dictionary
containing:
- 'name': (str) Display name for the step
- 'filter_expression': (Dict) Complete filter expression for the step
OR for simple event-based steps:
- 'name': (str) Display name for the step
- 'event': (str) Event name to filter on
date_ranges: A list of date ranges
(https://developers.google.com/analytics/devguides/reporting/data/v1/rest/v1beta/DateRange)
to include in the report.
funnel_breakdown: Optional breakdown dimension to segment the funnel.
This creates separate funnel results for each value of the dimension.
Example: {"breakdown_dimension": "deviceCategory"}
funnel_next_action: Optional next action analysis configuration.
This analyzes what users do after completing or dropping off from
the funnel.
Example: {"next_action_dimension": "eventName", "limit": 5}
segments: Optional list of segments to apply to the funnel.
return_property_quota: Whether to return current property quota
information.
Returns:
Dict containing the funnel report response with funnel results
including:
- funnel_table: Table showing progression through funnel steps
- funnel_visualization: Data for visualizing the funnel
- property_quota: (if requested) Current quota usage information
Raises:
ValueError: If funnel_steps is empty or contains invalid configurations
Exception: If the API request fails
## Hints for arguments
Here are some hints that outline the expected format and requirements
for arguments.
### Hints for `funnel_breakdown`
The `funnel_breakdown` parameter allows you to segment funnel results by a dimension:
```json
{
"breakdown_dimension": "deviceCategory"
}
```
Common breakdown dimensions include:
- `deviceCategory` - Desktop, Mobile, Tablet
- `country` - User's country
- `operatingSystem` - User's operating system
- `browser` - User's browser
### Hints for `funnel_next_action`
The `funnel_next_action` parameter analyzes what users do after completing or dropping off from the funnel:
```json
{
"next_action_dimension": "eventName",
"limit": 5
}
```
Common next action dimensions include:
- `eventName` - Next events users trigger
- `pagePath` - Next pages users visit
### Hints for `segments`
The `segments` parameter allows you to segment funnel results by user criteria.
Each segment is a dictionary passed directly to `data_v1alpha.Segment()`.
See https://developers.google.com/analytics/devguides/reporting/data/v1/funnels#segments
for details and examples.
### Hints for `date_ranges`:
Example date_range arguments:
1. A single date range:
[ {"start_date": "2025-01-01", "end_date": "2025-01-31", "name": "Jan2025"} ]
2. A relative date range using 'yesterday' and 'today':
[ {"start_date": "yesterday", "end_date": "today", "name": "YesterdayAndToday"} ]
3. A relative date range using 'NdaysAgo' and 'today':
[ {"start_date": "30daysAgo", "end_date": "yesterday", "name": "Previous30Days"}]
4. Multiple date ranges:
[ {"start_date": "2025-01-01", "end_date": "2025-01-31", "name": "Jan2025"}, {"start_date": "2025-02-01", "end_date": "2025-02-28", "name": "Feb2025"} ]
### Hints for `funnel_steps`
Example funnel_steps configurations:
1. Simple event-based step (first open/visit):
{"name": "First open/visit", "filter_expression": {"or_group": {"expressions": [{"funnel_event_filter": {"event_name": "first_open"}}, {"funnel_event_filter": {"event_name": "first_visit"}}]}}, "is_directly_followed_by": false}
2. Field filter for organic traffic:
{"name": "Organic visitors", "filter_expression": {"funnel_field_filter": {"field_name": "firstUserMedium", "string_filter": {"match_type": 4, "value": "organic", "case_sensitive": false}}}, "is_directly_followed_by": false}
3. Simple event filter:
{"name": "Session start", "filter_expression": {"funnel_event_filter": {"event_name": "session_start"}}, "is_directly_followed_by": false}
4. Multiple events with OR condition:
{"name": "Screen/Page view", "filter_expression": {"or_group": {"expressions": [{"funnel_event_filter": {"event_name": "screen_view"}}, {"funnel_event_filter": {"event_name": "page_view"}}]}}, "is_directly_followed_by": false}
5. Purchase events (multiple event types):
{"name": "Purchase", "filter_expression": {"or_group": {"expressions": [{"funnel_event_filter": {"event_name": "purchase"}}, {"funnel_event_filter": {"event_name": "in_app_purchase"}}]}}, "is_directly_followed_by": false}
6. Event with parameter filter (value > 50):
{"name": "Add to cart (value > 50)", "filter_expression": {"funnel_event_filter": {"event_name": "add_to_cart", "funnel_parameter_filter_expression": {"funnel_parameter_filter": {"event_parameter_name": "value", "numeric_filter": {"operation": 4, "value": {"double_value": 50.0}}}}}}, "is_directly_followed_by": false}
7. Complex AND condition (page view + specific path):
{"name": "Home page view", "filter_expression": {"and_group": {"expressions": [{"funnel_event_filter": {"event_name": "page_view"}}, {"funnel_field_filter": {"field_name": "pageLocation", "string_filter": {"match_type": 4, "value": "/", "case_sensitive": false}}}]}}, "is_directly_followed_by": false}
## Complete Funnel Example
A typical e-commerce funnel with 5 steps:
[
{"name": "First open/visit", "filter_expression": {"or_group": {"expressions": [{"funnel_event_filter": {"event_name": "first_open"}}, {"funnel_event_filter": {"event_name": "first_visit"}}]}}, "is_directly_followed_by": false},
{"name": "Organic visitors", "filter_expression": {"funnel_field_filter": {"field_name": "firstUserMedium", "string_filter": {"match_type": 4, "value": "organic", "case_sensitive": false}}}, "is_directly_followed_by": false},
{"name": "Session start", "filter_expression": {"funnel_event_filter": {"event_name": "session_start"}}, "is_directly_followed_by": false},
{"name": "Screen/Page view", "filter_expression": {"or_group": {"expressions": [{"funnel_event_filter": {"event_name": "screen_view"}}, {"funnel_event_filter": {"event_name": "page_view"}}]}}, "is_directly_followed_by": false},
{"name": "Purchase", "filter_expression": {"or_group": {"expressions": [{"funnel_event_filter": {"event_name": "purchase"}}, {"funnel_event_filter": {"event_name": "in_app_purchase"}}]}}, "is_directly_followed_by": false}
]| Name | Required | Description | Default |
|---|---|---|---|
| segments | No | ||
| date_ranges | No | ||
| property_id | Yes | ||
| funnel_steps | Yes | ||
| funnel_breakdown | No | ||
| funnel_next_action | No | ||
| return_property_quota | No |
TDQS
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 discloses potential exceptions (ValueError, Exception), return structure, and parameter behaviors. It does not mention authentication requirements or rate limits, but it provides substantial behavioral context beyond the schema.
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 long but well-structured with clear sections for each parameter, examples, and external links. Every section adds value, but could be slightly more concise. It is front-loaded with the purpose and then organizes hints logically.
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?
Despite 7 parameters, no output schema, and nested objects, the description is highly complete. It covers all parameters with detailed examples, explains return values (funnel_table, funnel_visualization, property_quota), and includes links to external guides. It fully compensates for missing schema descriptions and annotations.
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%, but the description adds extensive meaning for all 7 parameters with examples, formatting hints, and links. For instance, it explains 'funnel_steps' as lists of dictionaries with required keys, 'date_ranges' with multiple example formats, and 'funnel_breakdown' with JSON structure.
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 it runs a Google Analytics Data API funnel report, with specific verb and resource. It distinguishes from sibling tools like 'run_report' and 'run_conversions_report' by focusing on funnel analysis and providing extensive details on funnel-specific parameters such as funnel_steps, funnel_breakdown, and funnel_next_action.
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 implicitly distinguishes when to use this tool (funnel reports) versus siblings like 'run_report' (standard reports), but does not explicitly state when not to use it or provide alternatives. It gives clear context and examples for parameter usage, including links to external documentation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_realtime_reportA
Runs a Google Analytics Data API realtime report.
See
https://developers.google.com/analytics/devguides/reporting/data/v1/realtime-basics
for more information.
Args:
property_id: The Google Analytics property ID. Accepted formats are:
- A number
- A string consisting of 'properties/' followed by a number
dimensions: A list of dimensions to include in the report. Dimensions must be realtime dimensions.
metrics: A list of metrics to include in the report. Metrics must be realtime metrics.
dimension_filter: A Data API FilterExpression
(https://developers.google.com/analytics/devguides/reporting/data/v1/rest/v1beta/FilterExpression)
to apply to the dimensions. Don't use this for filtering metrics. Use
metric_filter instead. The `field_name` in a `dimension_filter` must
be a dimension, as defined in the `get_standard_dimensions` and
`get_dimensions` tools.
For more information about the expected format of this argument, see
the `run_report_dimension_filter_hints` tool.
metric_filter: A Data API FilterExpression
(https://developers.google.com/analytics/devguides/reporting/data/v1/rest/v1beta/FilterExpression)
to apply to the metrics. Don't use this for filtering dimensions. Use
dimension_filter instead. The `field_name` in a `metric_filter` must
be a metric, as defined in the `get_standard_metrics` and
`get_metrics` tools.
For more information about the expected format of this argument, see
the `run_report_metric_filter_hints` tool.
order_bys: A list of Data API OrderBy
(https://developers.google.com/analytics/devguides/reporting/data/v1/rest/v1beta/OrderBy)
objects to apply to the dimensions and metrics.
For more information about the expected format of this argument, see
the `run_report_order_bys_hints` tool.
limit: The maximum number of rows to return in each response. Value must
be a positive integer <= 250,000. Used to paginate through large
reports, following the guide at
https://developers.google.com/analytics/devguides/reporting/data/v1/basics#pagination.
offset: The row count of the start row. The first row is counted as row
0. Used to paginate through large
reports, following the guide at
https://developers.google.com/analytics/devguides/reporting/data/v1/basics#pagination.
return_property_quota: Whether to return realtime property quota in the response.
## Hints for arguments
Here are some hints that outline the expected format and requirements
for arguments.
### Hints for `dimensions`
The `dimensions` list must consist solely of either of the following:
1. Realtime standard dimensions defined in the HTML table at
https://developers.google.com/analytics/devguides/reporting/data/v1/realtime-api-schema#dimensions.
These dimensions are available to *every* property.
2. User-scoped custom dimensions for the `property_id`. Use the
`get_custom_dimensions_and_metrics` tool to retrieve the list of
custom dimensions for a property, and look for the custom
dimensions with an `apiName` that begins with "customUser:".
### Hints for `metrics`
The `metrics` list must consist solely of the Realtime standard
metrics defined in the HTML table at
https://developers.google.com/analytics/devguides/reporting/data/v1/realtime-api-schema#metrics.
These metrics are available to *every* property.
Realtime reports can't use custom metrics.
### Hints for `date_ranges`:
Example date_range arguments:
1. A single date range:
[ {"start_date": "2025-01-01", "end_date": "2025-01-31", "name": "Jan2025"} ]
2. A relative date range using 'yesterday' and 'today':
[ {"start_date": "yesterday", "end_date": "today", "name": "YesterdayAndToday"} ]
3. A relative date range using 'NdaysAgo' and 'today':
[ {"start_date": "30daysAgo", "end_date": "yesterday", "name": "Previous30Days"}]
4. Multiple date ranges:
[ {"start_date": "2025-01-01", "end_date": "2025-01-31", "name": "Jan2025"}, {"start_date": "2025-02-01", "end_date": "2025-02-28", "name": "Feb2025"} ]
### Hints for `dimension_filter`:
Example dimension_filter arguments:
1. A simple filter:
{"filter": {"field_name": "eventName", "string_filter": {"match_type": 2, "value": "add", "case_sensitive": false}}}
2. A NOT filter:
{"not_expression": {"filter": {"field_name": "eventName", "string_filter": {"match_type": 2, "value": "add", "case_sensitive": false}}}}
3. An empty value filter:
{"filter": {"field_name": "source", "empty_filter": {}}}
4. An AND group filter:
{"and_group": {"expressions": [{"filter": {"field_name": "sourceMedium", "string_filter": {"match_type": 1, "value": "google / cpc", "case_sensitive": false}}}, {"filter": {"field_name": "eventName", "in_list_filter": {"values": ["first_visit", "purchase", "add_to_cart"], "case_sensitive": true}}}]}}
5. An OR group filter:
{"or_group": {"expressions": [{"filter": {"field_name": "sourceMedium", "string_filter": {"match_type": 1, "value": "google / cpc", "case_sensitive": false}}}, {"filter": {"field_name": "eventName", "in_list_filter": {"values": ["first_visit", "purchase", "add_to_cart"], "case_sensitive": true}}}]}} Notes:
The API applies the dimension_filter and metric_filter
independently. As a result, some complex combinations of dimension and
metric filters are not possible in a single report request.
For example, you can't create a `dimension_filter` and `metric_filter`
combination for the following condition:
(
(eventName = "page_view" AND eventCount > 100)
OR
(eventName = "join_group" AND eventCount < 50)
)
This isn't possible because there's no way to apply the condition
"eventCount > 100" only to the data with eventName of "page_view", and
the condition "eventCount < 50" only to the data with eventName of
"join_group".
More generally, you can't define a `dimension_filter` and `metric_filter`
for:
(
((dimension condition D1) AND (metric condition M1))
OR
((dimension condition D2) AND (metric condition M2))
)
If you have complex conditions like this, either:
a) Run a single report that applies a subset of the conditions that
the API supports as well as the data needed to perform filtering of the
API response on the client side. For example, for the condition:
(
(eventName = "page_view" AND eventCount > 100)
OR
(eventName = "join_group" AND eventCount < 50)
)
You could run a report that filters only on:
eventName one of "page_view" or "join_group"
and include the eventCount metric, then filter the API response on the
client side to apply the different metric filters for the different
events.
or
b) Run a separate report for each combination of dimension condition and
metric condition. For the example above, you'd run one report for the
combination of (D1 AND M1), and another report for the combination of
(D2 AND M2).
Try to run fewer reports (option a) if possible. However, if running
fewer reports results in excessive quota usage for the API, use option
b. More information on quota usage is at
https://developers.google.com/analytics/blog/2023/data-api-quota-management.
### Hints for `metric_filter`:
Example metric_filter arguments:
1. A simple filter:
{"filter": {"field_name": "eventCount", "numeric_filter": {"operation": 4, "value": {"int64_value": "10"}}}}
2. A NOT filter:
{"not_expression": {"filter": {"field_name": "eventCount", "numeric_filter": {"operation": 4, "value": {"int64_value": "10"}}}}}
3. An empty value filter:
{"filter": {"field_name": "purchaseRevenue", "empty_filter": {}}}
4. An AND group filter:
{"and_group": {"expressions": [{"filter": {"field_name": "eventCount", "numeric_filter": {"operation": 4, "value": {"int64_value": "10"}}}}, {"filter": {"field_name": "purchaseRevenue", "between_filter": {"from_value": {"double_value": 10.0}, "to_value": {"double_value": 25.0}}}}]}}
5. An OR group filter:
{"or_group": {"expressions": [{"filter": {"field_name": "eventCount", "numeric_filter": {"operation": 4, "value": {"int64_value": "10"}}}}, {"filter": {"field_name": "purchaseRevenue", "between_filter": {"from_value": {"double_value": 10.0}, "to_value": {"double_value": 25.0}}}}]}} Notes:
The API applies the dimension_filter and metric_filter
independently. As a result, some complex combinations of dimension and
metric filters are not possible in a single report request.
For example, you can't create a `dimension_filter` and `metric_filter`
combination for the following condition:
(
(eventName = "page_view" AND eventCount > 100)
OR
(eventName = "join_group" AND eventCount < 50)
)
This isn't possible because there's no way to apply the condition
"eventCount > 100" only to the data with eventName of "page_view", and
the condition "eventCount < 50" only to the data with eventName of
"join_group".
More generally, you can't define a `dimension_filter` and `metric_filter`
for:
(
((dimension condition D1) AND (metric condition M1))
OR
((dimension condition D2) AND (metric condition M2))
)
If you have complex conditions like this, either:
a) Run a single report that applies a subset of the conditions that
the API supports as well as the data needed to perform filtering of the
API response on the client side. For example, for the condition:
(
(eventName = "page_view" AND eventCount > 100)
OR
(eventName = "join_group" AND eventCount < 50)
)
You could run a report that filters only on:
eventName one of "page_view" or "join_group"
and include the eventCount metric, then filter the API response on the
client side to apply the different metric filters for the different
events.
or
b) Run a separate report for each combination of dimension condition and
metric condition. For the example above, you'd run one report for the
combination of (D1 AND M1), and another report for the combination of
(D2 AND M2).
Try to run fewer reports (option a) if possible. However, if running
fewer reports results in excessive quota usage for the API, use option
b. More information on quota usage is at
https://developers.google.com/analytics/blog/2023/data-api-quota-management.
### Hints for `order_bys`:
Example order_bys arguments:
1. Order by ascending 'eventName':
[ {"dimension": {"dimension_name": "eventName", "order_type": 1}, "desc": false} ]
2. Order by descending 'eventName', ignoring case:
[ {"dimension": {"dimension_name": "campaignName", "order_type": 2}, "desc": true} ]
3. Order by ascending 'audienceId':
[ {"dimension": {"dimension_name": "audienceId", "order_type": 3}, "desc": false} ]
4. Order by descending 'eventCount':
[ {"metric": {"metric_name": "eventValue"}, "desc": true} ]
5. Order by ascending 'eventCount':
[ {"metric": {"metric_name": "eventCount"}, "desc": false} ]
6. Combination of dimension and metric order bys:
[
{"dimension": {"dimension_name": "eventName", "order_type": 1}, "desc": false},
{"metric": {"metric_name": "eventValue"}, "desc": true},
]
7. Order by multiple dimensions and metrics:
[
{"dimension": {"dimension_name": "eventName", "order_type": 1}, "desc": false},
{"dimension": {"dimension_name": "audienceId", "order_type": 3}, "desc": false},
{"metric": {"metric_name": "eventValue"}, "desc": true},
]
The dimensions and metrics in order_bys must also be present in the report
request's "dimensions" and "metrics" arguments, respectively.| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| metrics | Yes | ||
| order_bys | No | ||
| dimensions | Yes | ||
| property_id | Yes | ||
| metric_filter | No | ||
| dimension_filter | No | ||
| return_property_quota | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description shoulders the full burden of behavioral disclosure. It meticulously covers parameter formats, constraints (e.g., dimensions must be realtime, no custom metrics), pagination via limit/offset, and complex interactions between dimension and metric filters (including limitations and workarounds). This fully informs the agent of tool behavior.
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 well-structured with sections, bullet points, and code blocks, making it navigable. The one-line summary at the top provides immediate purpose. However, it is verbose, with repeated notes on filter independence appearing twice. Some conciseness could be gained without losing content.
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 (9 parameters, no output schema, no annotations), the description is remarkably complete. It covers all parameter details, provides examples for complex objects, explains limitations, and advises on workarounds for unsupported filter combinations. The agent has sufficient information to use the tool correctly.
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%, requiring the description to explain parameters. It does so thoroughly: each parameter has format info, constraints, and often examples (e.g., dimension_filter, metric_filter, order_bys with 5-7 concrete examples each). It also provides hints for dimensions and metrics, linking to external schemas and custom dimension retrieval. This adds rich semantics 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 opening sentence clearly states 'Runs a Google Analytics Data API realtime report,' specifying the verb, resource, and context. It distinguishes from siblings by focusing on 'realtime' reports, which are separate from the standard 'run_report' tool. The description also references a distinct API endpoint URL.
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 lacks explicit guidance on when to use this tool over siblings like 'run_report' or 'run_conversions_report'. It does not mention that realtime reports are for current data with limited lookback, nor does it direct users to other tools for historical data. The usage context is implied but not directly compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_reportB
Runs a Google Analytics Data API report.
Note that the reference docs at
https://developers.google.com/analytics/devguides/reporting/data/v1/rest/v1beta
all use camelCase field names, but field names passed to this method should
be in snake_case since the tool is using the protocol buffers (protobuf)
format. The protocol buffers for the Data API are available at
https://github.com/googleapis/googleapis/tree/master/google/analytics/data/v1beta.
Args:
property_id: The Google Analytics property ID. Accepted formats are:
- A number
- A string consisting of 'properties/' followed by a number
date_ranges: A list of date ranges
(https://developers.google.com/analytics/devguides/reporting/data/v1/rest/v1beta/DateRange)
to include in the report.
dimensions: A list of dimensions to include in the report.
metrics: A list of metrics to include in the report.
dimension_filter: A Data API FilterExpression
(https://developers.google.com/analytics/devguides/reporting/data/v1/rest/v1beta/FilterExpression)
to apply to the dimensions. Don't use this for filtering metrics. Use
metric_filter instead. The `field_name` in a `dimension_filter` must
be a dimension, as defined in the `get_standard_dimensions` and
`get_dimensions` tools.
metric_filter: A Data API FilterExpression
(https://developers.google.com/analytics/devguides/reporting/data/v1/rest/v1beta/FilterExpression)
to apply to the metrics. Don't use this for filtering dimensions. Use
dimension_filter instead. The `field_name` in a `metric_filter` must
be a metric, as defined in the `get_standard_metrics` and
`get_metrics` tools.
order_bys: A list of Data API OrderBy
(https://developers.google.com/analytics/devguides/reporting/data/v1/rest/v1beta/OrderBy)
objects to apply to the dimensions and metrics.
limit: The maximum number of rows to return in each response. Value must
be a positive integer <= 250,000. Used to paginate through large
reports, following the guide at
https://developers.google.com/analytics/devguides/reporting/data/v1/basics#pagination.
offset: The row count of the start row. The first row is counted as row
0. Used to paginate through large
reports, following the guide at
https://developers.google.com/analytics/devguides/reporting/data/v1/basics#pagination.
currency_code: The currency code to use for currency values. Must be in
ISO4217 format, such as "AED", "USD", "JPY". If the field is empty, the
report uses the property's default currency.
return_property_quota: Whether to return property quota in the response.
## Hints for arguments
Here are some hints that outline the expected format and requirements
for arguments.
### Hints for `dimensions`
The `dimensions` list must consist solely of either of the following:
1. Standard dimensions defined in the HTML table at
https://developers.google.com/analytics/devguides/reporting/data/v1/api-schema#dimensions.
These dimensions are available to *every* property.
2. Custom dimensions for the `property_id`. Use the
`get_custom_dimensions_and_metrics` tool to retrieve the list of
custom dimensions for a property.
### Hints for `metrics`
The `metrics` list must consist solely of either of the following:
1. Standard metrics defined in the HTML table at
https://developers.google.com/analytics/devguides/reporting/data/v1/api-schema#metrics.
These metrics are available to *every* property.
2. Custom metrics for the `property_id`. Use the
`get_custom_dimensions_and_metrics` tool to retrieve the list of
custom metrics for a property.
### Hints for `date_ranges`:
Example date_range arguments:
1. A single date range:
[ {"start_date": "2025-01-01", "end_date": "2025-01-31", "name": "Jan2025"} ]
2. A relative date range using 'yesterday' and 'today':
[ {"start_date": "yesterday", "end_date": "today", "name": "YesterdayAndToday"} ]
3. A relative date range using 'NdaysAgo' and 'today':
[ {"start_date": "30daysAgo", "end_date": "yesterday", "name": "Previous30Days"}]
4. Multiple date ranges:
[ {"start_date": "2025-01-01", "end_date": "2025-01-31", "name": "Jan2025"}, {"start_date": "2025-02-01", "end_date": "2025-02-28", "name": "Feb2025"} ]
### Hints for `dimension_filter`:
Example dimension_filter arguments:
1. A simple filter:
{"filter": {"field_name": "eventName", "string_filter": {"match_type": 2, "value": "add", "case_sensitive": false}}}
2. A NOT filter:
{"not_expression": {"filter": {"field_name": "eventName", "string_filter": {"match_type": 2, "value": "add", "case_sensitive": false}}}}
3. An empty value filter:
{"filter": {"field_name": "source", "empty_filter": {}}}
4. An AND group filter:
{"and_group": {"expressions": [{"filter": {"field_name": "sourceMedium", "string_filter": {"match_type": 1, "value": "google / cpc", "case_sensitive": false}}}, {"filter": {"field_name": "eventName", "in_list_filter": {"values": ["first_visit", "purchase", "add_to_cart"], "case_sensitive": true}}}]}}
5. An OR group filter:
{"or_group": {"expressions": [{"filter": {"field_name": "sourceMedium", "string_filter": {"match_type": 1, "value": "google / cpc", "case_sensitive": false}}}, {"filter": {"field_name": "eventName", "in_list_filter": {"values": ["first_visit", "purchase", "add_to_cart"], "case_sensitive": true}}}]}} Notes:
The API applies the dimension_filter and metric_filter
independently. As a result, some complex combinations of dimension and
metric filters are not possible in a single report request.
For example, you can't create a `dimension_filter` and `metric_filter`
combination for the following condition:
(
(eventName = "page_view" AND eventCount > 100)
OR
(eventName = "join_group" AND eventCount < 50)
)
This isn't possible because there's no way to apply the condition
"eventCount > 100" only to the data with eventName of "page_view", and
the condition "eventCount < 50" only to the data with eventName of
"join_group".
More generally, you can't define a `dimension_filter` and `metric_filter`
for:
(
((dimension condition D1) AND (metric condition M1))
OR
((dimension condition D2) AND (metric condition M2))
)
If you have complex conditions like this, either:
a) Run a single report that applies a subset of the conditions that
the API supports as well as the data needed to perform filtering of the
API response on the client side. For example, for the condition:
(
(eventName = "page_view" AND eventCount > 100)
OR
(eventName = "join_group" AND eventCount < 50)
)
You could run a report that filters only on:
eventName one of "page_view" or "join_group"
and include the eventCount metric, then filter the API response on the
client side to apply the different metric filters for the different
events.
or
b) Run a separate report for each combination of dimension condition and
metric condition. For the example above, you'd run one report for the
combination of (D1 AND M1), and another report for the combination of
(D2 AND M2).
Try to run fewer reports (option a) if possible. However, if running
fewer reports results in excessive quota usage for the API, use option
b. More information on quota usage is at
https://developers.google.com/analytics/blog/2023/data-api-quota-management.
### Hints for `metric_filter`:
Example metric_filter arguments:
1. A simple filter:
{"filter": {"field_name": "eventCount", "numeric_filter": {"operation": 4, "value": {"int64_value": "10"}}}}
2. A NOT filter:
{"not_expression": {"filter": {"field_name": "eventCount", "numeric_filter": {"operation": 4, "value": {"int64_value": "10"}}}}}
3. An empty value filter:
{"filter": {"field_name": "purchaseRevenue", "empty_filter": {}}}
4. An AND group filter:
{"and_group": {"expressions": [{"filter": {"field_name": "eventCount", "numeric_filter": {"operation": 4, "value": {"int64_value": "10"}}}}, {"filter": {"field_name": "purchaseRevenue", "between_filter": {"from_value": {"double_value": 10.0}, "to_value": {"double_value": 25.0}}}}]}}
5. An OR group filter:
{"or_group": {"expressions": [{"filter": {"field_name": "eventCount", "numeric_filter": {"operation": 4, "value": {"int64_value": "10"}}}}, {"filter": {"field_name": "purchaseRevenue", "between_filter": {"from_value": {"double_value": 10.0}, "to_value": {"double_value": 25.0}}}}]}} Notes:
The API applies the dimension_filter and metric_filter
independently. As a result, some complex combinations of dimension and
metric filters are not possible in a single report request.
For example, you can't create a `dimension_filter` and `metric_filter`
combination for the following condition:
(
(eventName = "page_view" AND eventCount > 100)
OR
(eventName = "join_group" AND eventCount < 50)
)
This isn't possible because there's no way to apply the condition
"eventCount > 100" only to the data with eventName of "page_view", and
the condition "eventCount < 50" only to the data with eventName of
"join_group".
More generally, you can't define a `dimension_filter` and `metric_filter`
for:
(
((dimension condition D1) AND (metric condition M1))
OR
((dimension condition D2) AND (metric condition M2))
)
If you have complex conditions like this, either:
a) Run a single report that applies a subset of the conditions that
the API supports as well as the data needed to perform filtering of the
API response on the client side. For example, for the condition:
(
(eventName = "page_view" AND eventCount > 100)
OR
(eventName = "join_group" AND eventCount < 50)
)
You could run a report that filters only on:
eventName one of "page_view" or "join_group"
and include the eventCount metric, then filter the API response on the
client side to apply the different metric filters for the different
events.
or
b) Run a separate report for each combination of dimension condition and
metric condition. For the example above, you'd run one report for the
combination of (D1 AND M1), and another report for the combination of
(D2 AND M2).
Try to run fewer reports (option a) if possible. However, if running
fewer reports results in excessive quota usage for the API, use option
b. More information on quota usage is at
https://developers.google.com/analytics/blog/2023/data-api-quota-management.
### Hints for `order_bys`:
Example order_bys arguments:
1. Order by ascending 'eventName':
[ {"dimension": {"dimension_name": "eventName", "order_type": 1}, "desc": false} ]
2. Order by descending 'eventName', ignoring case:
[ {"dimension": {"dimension_name": "campaignName", "order_type": 2}, "desc": true} ]
3. Order by ascending 'audienceId':
[ {"dimension": {"dimension_name": "audienceId", "order_type": 3}, "desc": false} ]
4. Order by descending 'eventCount':
[ {"metric": {"metric_name": "eventValue"}, "desc": true} ]
5. Order by ascending 'eventCount':
[ {"metric": {"metric_name": "eventCount"}, "desc": false} ]
6. Combination of dimension and metric order bys:
[
{"dimension": {"dimension_name": "eventName", "order_type": 1}, "desc": false},
{"metric": {"metric_name": "eventValue"}, "desc": true},
]
7. Order by multiple dimensions and metrics:
[
{"dimension": {"dimension_name": "eventName", "order_type": 1}, "desc": false},
{"dimension": {"dimension_name": "audienceId", "order_type": 3}, "desc": false},
{"metric": {"metric_name": "eventValue"}, "desc": true},
]
The dimensions and metrics in order_bys must also be present in the report
request's "dimensions" and "metrics" arguments, respectively.| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| metrics | Yes | ||
| order_bys | No | ||
| dimensions | Yes | ||
| date_ranges | Yes | ||
| property_id | Yes | ||
| currency_code | No | ||
| metric_filter | No | ||
| dimension_filter | No | ||
| return_property_quota | No |
TDQS
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 discloses snake_case requirement, independent filter application, pagination details, and complex filter limitations. However, it does not explicitly state that the tool is read-only or discuss quota/rate limits beyond a mention.
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 overly long and contains redundant sections (e.g., the same complex filter notes appear twice). While well-organized with hints, the verbosity harms 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 complexity (11 parameters, no output schema), the description covers all parameters, provides examples, explains filter limitations, and offers pagination guidance. Missing return value description and error handling, but overall thorough.
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 0% description coverage, but the tool description provides extensive, clear explanations for each parameter, including types, constraints, examples, and links. This adds significant value beyond the raw 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 it runs a Google Analytics Data API report, with specific verb and resource. However, it does not explicitly distinguish from sibling tools like run_funnel_report or run_realtime_report, leaving room for ambiguity.
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?
No explicit guidance on when to use this tool versus alternatives. The description focuses on parameter details and examples but does not provide selection criteria 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. Dates show when Glama detected each change.
9 tool updates
v0.6.0- Added
get_account_summaries - Added
get_custom_dimensions_and_metrics - Added
get_property_details - Added
list_google_ads_links - Added
list_property_annotations - Added
run_conversions_report - Added
run_funnel_report - Added
run_realtime_report - Added
run_report
8 tool updates
v0.5.0- Removed
get_account_summaries - Removed
get_custom_dimensions_and_metrics - Removed
get_property_details - Removed
list_google_ads_links - Removed
list_property_annotations - Removed
run_funnel_report - Removed
run_realtime_report - Removed
run_report
8 tool updates
v0.3.0- Changed
get_account_summaries2 fields changed- removed
Input schema / titleRemoved value: -"get_account_summariesArguments" - changed
Output schema / (root)Previous value: -{ - "properties": { - "result": { - "items": { - "additionalProperties": true, - "type": "object" - }, - "title": "Result", - "type": "array" - } - }, - "required": [ - "result" - ], - "title": "get_account_summariesOutput", - "type": "object" -}New value: +null
- Changed
get_custom_dimensions_and_metrics3 fields changed- removed
Input schema / properties / property_id / titleRemoved value: -"Property Id" - removed
Input schema / titleRemoved value: -"get_custom_dimensions_and_metricsArguments" - changed
Output schema / (root)Previous value: -{ - "properties": { - "result": { - "additionalProperties": { - "items": { - "additionalProperties": true, - "type": "object" - }, - "type": "array" - }, - "title": "Result", - "type": "object" - } - }, - "required": [ - "result" - ], - "title": "get_custom_dimensions_and_metricsOutput", - "type": "object" -}New value: +null
- Changed
get_property_details3 fields changed- removed
Input schema / properties / property_id / titleRemoved value: -"Property Id" - removed
Input schema / titleRemoved value: -"get_property_detailsArguments" - changed
Output schema / (root)Previous value: -{ - "properties": { - "result": { - "additionalProperties": true, - "title": "Result", - "type": "object" - } - }, - "required": [ - "result" - ], - "title": "get_property_detailsOutput", - "type": "object" -}New value: +null
- Changed
list_google_ads_links3 fields changed- removed
Input schema / properties / property_id / titleRemoved value: -"Property Id" - removed
Input schema / titleRemoved value: -"list_google_ads_linksArguments" - changed
Output schema / (root)Previous value: -{ - "properties": { - "result": { - "items": { - "additionalProperties": true, - "type": "object" - }, - "title": "Result", - "type": "array" - } - }, - "required": [ - "result" - ], - "title": "list_google_ads_linksOutput", - "type": "object" -}New value: +null
- Changed
list_property_annotations3 fields changed- removed
Input schema / properties / property_id / titleRemoved value: -"Property Id" - removed
Input schema / titleRemoved value: -"list_property_annotationsArguments" - changed
Output schema / (root)Previous value: -{ - "properties": { - "result": { - "items": { - "additionalProperties": true, - "type": "object" - }, - "title": "Result", - "type": "array" - } - }, - "required": [ - "result" - ], - "title": "list_property_annotationsOutput", - "type": "object" -}New value: +null
- Added
run_funnel_report - Changed
run_realtime_report24 fields changed- removed
Input schema / properties / dimension_filter / additionalPropertiesRemoved value: -true - removed
Input schema / properties / dimension_filter / defaultRemoved value: -null - added
Input schema / properties / dimension_filter / nullableAdded value: +true - removed
Input schema / properties / dimension_filter / titleRemoved value: -"Dimension Filter" - removed
Input schema / properties / dimensions / titleRemoved value: -"Dimensions" - removed
Input schema / properties / limit / defaultRemoved value: -null - added
Input schema / properties / limit / nullableAdded value: +true - removed
Input schema / properties / limit / titleRemoved value: -"Limit" - removed
Input schema / properties / metric_filter / additionalPropertiesRemoved value: -true - removed
Input schema / properties / metric_filter / defaultRemoved value: -null - added
Input schema / properties / metric_filter / nullableAdded value: +true - removed
Input schema / properties / metric_filter / titleRemoved value: -"Metric Filter" - removed
Input schema / properties / metrics / titleRemoved value: -"Metrics" - removed
Input schema / properties / offset / defaultRemoved value: -null - added
Input schema / properties / offset / nullableAdded value: +true - removed
Input schema / properties / offset / titleRemoved value: -"Offset" - removed
Input schema / properties / order_bys / defaultRemoved value: -null - removed
Input schema / properties / order_bys / items / additionalPropertiesRemoved value: -true - added
Input schema / properties / order_bys / nullableAdded value: +true - removed
Input schema / properties / order_bys / titleRemoved value: -"Order Bys" - removed
Input schema / properties / property_id / titleRemoved value: -"Property Id" - removed
Input schema / properties / return_property_quota / titleRemoved value: -"Return Property Quota" - removed
Input schema / titleRemoved value: -"run_realtime_reportArguments" - changed
Output schema / (root)Previous value: -{ - "properties": { - "result": { - "additionalProperties": true, - "title": "Result", - "type": "object" - } - }, - "required": [ - "result" - ], - "title": "run_realtime_reportOutput", - "type": "object" -}New value: +null
- Changed
run_report29 fields changed- removed
Input schema / properties / currency_code / defaultRemoved value: -null - added
Input schema / properties / currency_code / nullableAdded value: +true - removed
Input schema / properties / currency_code / titleRemoved value: -"Currency Code" - removed
Input schema / properties / date_ranges / items / additionalPropertiesRemoved value: -{ - "type": "string" -} - removed
Input schema / properties / date_ranges / titleRemoved value: -"Date Ranges" - removed
Input schema / properties / dimension_filter / additionalPropertiesRemoved value: -true - removed
Input schema / properties / dimension_filter / defaultRemoved value: -null - added
Input schema / properties / dimension_filter / nullableAdded value: +true - removed
Input schema / properties / dimension_filter / titleRemoved value: -"Dimension Filter" - removed
Input schema / properties / dimensions / titleRemoved value: -"Dimensions" - removed
Input schema / properties / limit / defaultRemoved value: -null - added
Input schema / properties / limit / nullableAdded value: +true - removed
Input schema / properties / limit / titleRemoved value: -"Limit" - removed
Input schema / properties / metric_filter / additionalPropertiesRemoved value: -true - removed
Input schema / properties / metric_filter / defaultRemoved value: -null - added
Input schema / properties / metric_filter / nullableAdded value: +true - removed
Input schema / properties / metric_filter / titleRemoved value: -"Metric Filter" - removed
Input schema / properties / metrics / titleRemoved value: -"Metrics" - removed
Input schema / properties / offset / defaultRemoved value: -null - added
Input schema / properties / offset / nullableAdded value: +true - removed
Input schema / properties / offset / titleRemoved value: -"Offset" - removed
Input schema / properties / order_bys / defaultRemoved value: -null - removed
Input schema / properties / order_bys / items / additionalPropertiesRemoved value: -true - added
Input schema / properties / order_bys / nullableAdded value: +true - removed
Input schema / properties / order_bys / titleRemoved value: -"Order Bys" - removed
Input schema / properties / property_id / titleRemoved value: -"Property Id" - removed
Input schema / properties / return_property_quota / titleRemoved value: -"Return Property Quota" - removed
Input schema / titleRemoved value: -"run_reportArguments" - changed
Output schema / (root)Previous value: -{ - "properties": { - "result": { - "additionalProperties": true, - "title": "Result", - "type": "object" - } - }, - "required": [ - "result" - ], - "title": "run_reportOutput", - "type": "object" -}New value: +null
1 tool update
v1.0.0- Added
list_property_annotations
6 tool updates
- First observed
get_account_summaries - First observed
get_custom_dimensions_and_metrics - First observed
get_property_details - First observed
list_google_ads_links - First observed
run_realtime_report - First observed
run_report
TDQS
Each tool targets a distinct aspect of Google Analytics: account summaries, custom dimensions, property details, ads links, annotations, and four distinct report types (standard, conversions, funnel, realtime). There is no overlap in functionality.
All tools follow a consistent verb_noun snake_case pattern: get_*, list_*, run_*. This makes the tool set predictable and easy to navigate for both agents and humans.
With 9 tools, the set is well-scoped for a Google Analytics server. It covers account info, property configuration, and various reporting needs without being overwhelming or too sparse.
The set is read-only for analytics data and lacks CRUD operations for resources like annotations or custom dimensions. While it covers multiple report types, the absence of management tools and dynamic schema discovery (though hints exist) creates notable gaps.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Official MCP server for Certifier to issue, manage, and track certificates and badges.
- LovableOAuthdev.lovable
Official MCP server for Lovable, the AI-powered full-stack app builder.
Related MCP Servers
- AlicenseNot gradedqualityFmaintenanceMCP server to interact with Google produts.489MIT
- MIT
- -licenseNot gradedqualityNot gradedmaintenanceAn experimental MCP server that enables interaction with Google Analytics APIs, allowing users to retrieve account information, run core reports, and access realtime analytics data through natural language queries.-
- AlicenseNot gradedqualityCmaintenanceMCP server for querying Google Analytics accounts, properties, reports, and realtime data using the Data API and Admin API.Apache 2.0
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/googleanalytics/google-analytics-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server