Allows creating Google Analytics 4 audiences that can be shared to Google Ads for remarketing campaigns.
Provides read and write access to Google Analytics 4 properties, including running reports, managing custom dimensions, metrics, key events, audiences, and sending events via the Measurement Protocol.
Click on "Deploy 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., "@ga4-mcp-server create an audience of users who fired generate_lead in the last 30 days"
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.
A Model Context Protocol (MCP) server for Google Analytics 4 with both read and write access. Connect it to Claude (or any MCP client) and pull reports, manage configuration, build remarketing audiences, and send server-side events — in natural language, using your own Google credentials. No third-party service, no subscription.
Most GA4 MCP servers are read-only. This one also writes: it can create custom dimensions and metrics, mark conversions, create audiences (for remarketing lists you can share to Google Ads), and manage/use the Measurement Protocol.
Read
List accounts and properties, property details, and data streams
Run GA4 reports (run_report) and realtime reports (run_realtime_report)
List custom dimensions, custom metrics, key events (conversions), and audiences
Write
Create and archive custom dimensions
Create custom metrics
Create key events (conversions)
Create and archive audiences (e.g. everyone who fired generate_lead in the last 30 days)
Create / list / delete Measurement Protocol API secrets
Send events into a property via the Measurement Protocol (with a validate=True mode that checks the payload without ingesting it)
Related MCP server: MCP Google Suite
Python 3.10+ (the MCP SDK requires it)
A Google Cloud project and a service account with a JSON key
The service account granted access on your GA4 account/property (Viewer/Analyst for reads, Editor for writes)
In the Google Cloud Console, create (or pick) a project.
Enable the Google Analytics Data API and the Google Analytics Admin API for that project.
Create a service account and download a JSON key for it.
In Google Analytics → Admin → Account (or Property) access management, add the service account's email (...@your-project.iam.gserviceaccount.com) as a user — Editor if you want write access.
That's it — no OAuth consent screen, no token refresh. The service account authenticates directly.
Using uv (recommended — it manages an isolated Python for you):
git clone https://github.com/burhan29ee/ga4-mcp-server.git
cd ga4-mcp-server
uv venv --python 3.12 .venv
uv pip install --python .venv/bin/python -e .Or with pip:
python3 -m venv .venv && source .venv/bin/activate
pip install -e .Point the server at your service-account key with the GOOGLE_APPLICATION_CREDENTIALS environment variable, then add it to your client. For Claude Desktop, edit claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json; Windows: %APPDATA%\Claude\claude_desktop_config.json):
{
"mcpServers": {
"ga4": {
"command": "/absolute/path/to/ga4-mcp-server/.venv/bin/python",
"args": ["-m", "ga4_mcp_server.server"],
"env": {
"GOOGLE_APPLICATION_CREDENTIALS": "/absolute/path/to/service-account-key.json"
}
}
}
}Restart the client. You should be able to ask things like "list my GA4 properties," "pull last 28 days of users and conversions by channel," or "create a remarketing audience of everyone who registered for a webinar in the last 60 days."
Tool | Type | What it does |
| read | List accounts and their properties |
| read | Property name, time zone, currency, industry |
| read | Web/app streams and their measurement IDs |
| read | GA4 report by metrics/dimensions/date range |
| read | Realtime report (last ~30 min) |
| read | Custom dimensions on a property |
| write | Create a custom dimension |
| write | Archive a custom dimension |
| read | Custom metrics on a property |
| write | Create a custom metric |
| read | Key events (conversions) |
| write | Mark an event as a conversion |
| read | Audiences on a property |
| write | Create an audience of users who fired an event |
| write | Archive an audience |
| read | MP API secrets for a stream |
| write | Create an MP API secret |
| write | Delete an MP API secret |
| write | Send an event via the Measurement Protocol |
pip install -e ".[dev]"
ruff check .
pytest -qSee CONTRIBUTING.md for the full workflow.
The service-account key is a credential — treat it like a password. Never commit it (the .gitignore blocks key files), grant the service account the least access it needs, and rotate the key if it's ever exposed. See SECURITY.md for details and how to report a vulnerability.
The mcp dependency is pinned to >=1.2,<2. The 2.0 SDK reorganized its API and removed mcp.server.fastmcp, which this server uses.
Audiences use the GA4 Admin v1alpha API; the rest use the stable v1beta and Data APIs.
This is an independent open-source project and is not affiliated with or endorsed by Google.
Archive a GA4 audience. audience_id may be the numeric id or the full 'properties/NNN/audiences/MMM' name.
| Name | Required | Description | Default |
|---|---|---|---|
| audience_id | Yes | ||
| property_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description bears full responsibility for disclosing behavior. It only mentions the audience_id format; it does not state whether archiving is reversible, what side effects occur (e.g., affects reporting), or required permissions. This leaves significant behavioral uncertainty.
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, front-loaded sentence that efficiently conveys the action and a key parameter clarification. Every word adds value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an incomplete parameter description (property_id unspecified), the description lacks essential context for a mutation tool. It does not explain the consequences of archiving or what happens after the call, leaving the agent under-informed.
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 descriptions are absent (0% coverage), but the description adds valuable detail for audience_id, noting it may be a numeric id or full resource name. However, property_id is left entirely undefined, so the compensation is only partial for a two-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive') and the resource ('GA4 audience'), making the tool's purpose unambiguous. It also distinguishes from siblings like list_audiences and create_event_audience by using a distinct verb and target.
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 conveys a clear use case: when you need to archive an audience. It doesn't explicitly mention alternatives or exclusions, but no competing sibling exists (archive_custom_dimension is for a different resource). Thus, the context is clear enough without explicit 'when-to-use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Archive (delete) a custom dimension. custom_dimension_id may be the numeric id or the full 'properties/NNN/customDimensions/MMM' name.
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes | ||
| custom_dimension_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Archive (delete)', which indicates a destructive operation, but does not mention whether the action is reversible, what side effects occur (e.g., on reports or metrics), or any permission requirements. This is a significant gap for a deletion tool.
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 with no redundant wording. It front-loads the action and immediately addresses a likely parameter confusion. This 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter destructive tool with no output schema and no annotations, the description provides the core action and an important parameter detail, but it omits consequences (e.g., permanence, permission needs) and return behavior. It is minimally complete but leaves the agent guessing about the full impact.
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 useful semantics for custom_dimension_id by clarifying it can be a numeric id or full resource name, which is beyond the bare schema. However, property_id lacks any explanation, and with 0% schema description coverage, the description only partially compensates for the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Archive (delete)' and the resource 'custom dimension', making the tool's purpose obvious. It does not explicitly differentiate from sibling tools like archive_audience, but the resource specificity is sufficient. A score of 5 would require explicit mention of alternatives or scope exclusions.
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, nor does it list any prerequisites or exclusions. Usage is only implied by the action itself, which is insufficient for a tool with many siblings like create_custom_dimension and list_custom_dimensions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a custom dimension. parameter_name is the event parameter / user property key; scope is 'EVENT', 'USER' or 'ITEM'. display_name may contain only letters, numbers, underscores and spaces.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | EVENT | |
| description | No | ||
| property_id | Yes | ||
| display_name | Yes | ||
| parameter_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full transparency burden. It discloses validation rules (scope values, display_name charset) but not return behavior, idempotency, or propagation delays. The verb 'Create' makes the mutating nature obvious, avoiding contradiction.
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 concise sentences, front-loaded with the action, every clause adds operational detail. No redundant filler or unnecessary commentary.
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 5-parameter create operation with no annotations or output schema, the description is too thin. It fails to explain the required property_id, return/response behavior, or how the created dimension appears in list_custom_dimensions. This leaves the agent to infer important invocation details.
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 the description must compensate. It explains parameter_name and scope values, and display_name constraints, but omits property_id (a required parameter) and description. This is useful but incomplete.
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?
Description uses specific action 'Create' and resource 'custom dimension', making it clear it creates a GA4 custom dimension. It also distinguishes from siblings like list_custom_dimensions, archive_custom_dimension, and create_custom_metric.
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 given on when to use this tool versus alternatives such as create_custom_metric, or how it relates to archive_custom_dimension. No prerequisites or decision context are provided beyond the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a custom metric. measurement_unit is one of STANDARD, CURRENCY, FEET, METERS, KILOMETERS, MILES, MILLISECONDS, SECONDS, MINUTES, HOURS.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | EVENT | |
| description | No | ||
| property_id | Yes | ||
| display_name | Yes | ||
| parameter_name | Yes | ||
| measurement_unit | No | STANDARD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full responsibility for behavioral disclosure. It only states the creation action and enum values, without explaining side effects, required permissions, idempotency, or what the result of creation entails. This is a significant gap for a mutation tool.
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 concise, consisting of two short sentences, with no wasted words. The measurement_unit enumeration is a useful addition, though the structure could be improved by including required parameters or usage context.
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 tool has six parameters with no schema descriptions, no annotations, and no output schema. The description covers only the creation action and one parameter's enum values, leaving the purpose and semantics of the other parameters and the operational behavior unexplained. This is insufficient for effective tool selection and invocation.
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 meaningful enumeration for the measurement_unit parameter, which is absent from the schema. However, the other five parameters (scope, description, property_id, display_name, parameter_name) receive no semantic explanation, and schema description coverage is 0%, so the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create' and the resource 'a custom metric', which is specific and distinguishes it from sibling tools like create_custom_dimension or list_custom_metrics. The verb+resource construction is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_custom_dimension or list_custom_metrics. There is no mention of prerequisites, exclusions, or alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a GA4 audience of users who triggered a given event (e.g. 'purchase', 'generate_lead') — useful for remarketing lists that can be shared to Google Ads. membership_duration_days is how long a user stays in the audience (max 540).
| Name | Required | Description | Default |
|---|---|---|---|
| event_name | Yes | ||
| description | No | ||
| property_id | Yes | ||
| display_name | Yes | ||
| membership_duration_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details itself. It only mentions membership duration and its maximum, but omits side effects such as whether duplicate names are allowed, permission requirements, reversibility, or what the response contains. This leaves significant behavioral uncertainty for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and includes a concrete use case and a key parameter constraint without extraneous words. Every sentence adds value, making it highly efficient.
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 tool has 5 parameters, no annotations, and no output schema, so the description must cover more ground. It explains the business use case and one parameter detail, but does not describe required parameters beyond examples, nor return values or error conditions. It is minimally viable but leaves notable gaps.
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 meaning for two parameters: event_name via concrete examples and membership_duration_days via the max 540 constraint. However, the other three parameters (property_id, display_name, description) remain unexplained beyond the schema, and schema coverage is reported at 0%, so the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a GA4 audience based on an event trigger, with specific examples ('purchase', 'generate_lead'). It differentiates from sibling tools like list_audiences or archive_audience by describing the creation action and its purpose for remarketing to Google Ads.
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 clear context on when to use it ('useful for remarketing lists that can be shared to Google Ads'). While it does not explicitly list exclusions or alternatives, no other sibling tool offers audience creation, so the guidance is adequate for the available toolset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark an event as a key event (conversion). counting_method is 'ONCE_PER_EVENT' or 'ONCE_PER_SESSION'.
| Name | Required | Description | Default |
|---|---|---|---|
| event_name | Yes | ||
| property_id | Yes | ||
| counting_method | No | ONCE_PER_EVENT |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions valid counting_method values, but does not describe side effects, permission requirements, idempotency, error behavior, or what happens if the event is already a key event.
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 front-loads the purpose and includes essential parameter information. No redundant words or filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with no output schema, the description covers the core action and a key parameter, but omits details like return value, error handling, and permissions. Additional context would be beneficial for complete understanding.
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 coverage is 0%, and the description adds value by enumerating allowed values for counting_method. The other parameters (property_id, event_name) are self-explanatory from their names and required status, but no additional semantics are given for them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark an event as a key event') and the resource ('key event'), with 'conversion' providing context. It distinguishes itself from sibling tools like list_key_events by indicating a creation/marking operation.
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 implies use for marking conversion events, but does not explicitly state when to use this tool versus alternatives, nor any exclusions or prerequisites. The 'conversion' hint gives some context, but lacks clear 'use when' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Measurement Protocol API secret on a data stream. Returns the secret_value (api_secret) needed by send_ga4_event. Treat it as sensitive.
| Name | Required | Description | Default |
|---|---|---|---|
| stream_id | Yes | ||
| property_id | Yes | ||
| display_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states that the tool returns a secret_value (api_secret) and warns to treat it as sensitive. This adds value beyond the basic create action, though it doesn't discuss other side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and includes essential return-value and security notes. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, return value, and sensitivity, but lacks parameter explanations and return format details beyond the secret_value field. Given no output schema and no annotations, it is only partially complete for a create operation with three required parameters.
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 3 parameters with 0% description coverage, so the description must compensate. It does not explain what property_id, stream_id, or display_name mean, nor their relationships. The phrase 'on a data stream' indirectly relates to stream_id, but no concrete parameter guidance is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a Measurement Protocol API secret on a data stream') with a specific verb and resource, and distinguishes this from sibling tools like list_measurement_protocol_secrets and delete_measurement_protocol_secret. It also mentions the connection to send_ga4_event, further clarifying its unique role.
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 implies the use case: creating a secret needed by send_ga4_event. It provides context about when to use it (before sending GA4 events) but does not explicitly mention alternatives or when not to use it. The mention of send_ga4_event gives practical usage guidance beyond just 'create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Measurement Protocol API secret. secret_id may be the numeric id or the full resource name.
| Name | Required | Description | Default |
|---|---|---|---|
| secret_id | Yes | ||
| stream_id | Yes | ||
| property_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It only states 'Delete' and mentions secret_id formats, but does not mention irreversibility, required permissions, or side effects. This is minimal transparency for a destructive operation.
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 with no fluff. It includes the essential action and a valuable detail about secret_id, earning every word.
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 tool is simple (3 required parameters, no output schema), and the description covers the basic action. However, it lacks explicit statements about the destructive nature and any prerequisites, making it minimally viable rather than 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 description coverage is 0%, so the description must compensate. It provides some meaning for secret_id (numeric id or full resource name) but leaves property_id and stream_id completely unexplained. This is partial compensation, insufficient for a 3-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete a Measurement Protocol API secret.' This uses a specific verb and resource, and distinguishes it from sibling tools like list and create. The additional note about secret_id formats further clarifies the target.
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, nor are any prerequisites or context given. The description only states what it does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get configuration details for one GA4 property (name, time zone, currency, industry, create time).
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently lists the returned fields, which is a behavioral disclosure, and 'Get' implies a safe read operation. However, it does not mention error behavior, permissions, or any limitations, leaving some behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the action and resource, then a parenthetical list of fields. Every word earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with one parameter and no output schema, the description adequately covers the purpose and return contents. It lacks some edge-case details like property_id format or error handling, but the core information is present and understandable in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It tells the parameter is the identifier for 'one GA4 property', adding meaning beyond the raw name 'property_id'. However, it does not specify the format or provide examples, leaving some ambiguity for the agent.
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 a specific verb 'Get' with a clear resource 'configuration details for one GA4 property' and enumerates the included fields (name, time zone, currency, industry, create time). This distinguishes it from siblings like list_data_streams or list_account_summaries, which target different resources or scopes.
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 implies usage when you need configuration details for a single GA4 property, but it does not explicitly state when not to use it or mention alternatives. Sibling tools like list_data_streams and run_report serve different purposes, so the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every GA4 account and its properties the service account can see. Returns account name/id plus each property's display name and numeric id. Call this first to discover property ids for the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the scope ('the service account can see') and the output structure (account name/id, property display name and numeric id), which is more than the tool name alone. However, it does not mention potential limitations like pagination or rate limits for listing all data, which keeps it from a perfect score.
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?
Three concise sentences each serve a distinct purpose: action, return value, and usage timing. No words are wasted, and the most important information is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema is present, the description fully covers what the tool does, what it returns, and when to call it. It is a complete and self-contained description for this simple discovery tool, leaving no significant gaps in understanding.
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 tool has zero parameters, so by the scoring rule the baseline is 4. The description clarifies that it takes no input and simply lists everything visible to the service account, which fully compensates for the empty 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 the tool's function with a specific verb ('List every GA4 account and its properties the service account can see') and distinguishes it from siblings by positioning it as the first-step discovery tool. It also specifies the return content (account name/id, property display name and numeric id), leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Call this first to discover property ids for the other tools,' providing clear when-to-use guidance and positioning it as the prerequisite for all other GA4 tools. This makes the tool's role in the workflow unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List audiences defined on a GA4 property.
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the core action and does not mention read-only behavior, pagination, required permissions, or any other operational details beyond the literal listing.
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, front-loaded sentence with no filler. It efficiently conveys the action and resource, making every word count.
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 tool is simple with one parameter and an output schema, so a brief description is partially justified. However, it omits usage context and parameter clarification, which could lead to ambiguity among the many sibling list tools.
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% and the description does not mention the property_id parameter at all. The description adds no meaning to help the agent construct valid arguments, leaving the parameter semantics entirely undefined.
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 specific verb 'List' and identifies the resource as 'audiences defined on a GA4 property,' which clearly states the tool's function and distinguishes it from sibling tools like list_data_streams or list_custom_dimensions.
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 implies usage by naming the resource, but it does not provide explicit guidance on when to use this tool versus alternatives such as create_event_audience or archive_audience. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List custom dimensions defined on a GA4 property.
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. The verb 'List' clearly indicates a read-only operation, but it does not disclose whether archived dimensions are included, pagination behavior, or any required permissions. This leaves some behavioral aspects undefined.
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, front-loaded sentence with no redundant words. It efficiently conveys the tool's core purpose in eight words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter), the presence of an output schema, and no annotations, the description adequately covers the essential purpose and scope. However, it omits potential behavioral nuances like whether archived custom dimensions are returned, leaving minor ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that property_id refers to a GA4 property, adding context beyond the schema's bare 'Property Id', but it does not explain expected formats or additional constraints for the parameter.
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 a specific verb ('List'), identifies the resource ('custom dimensions'), and scopes it to 'a GA4 property', distinguishing it from sibling tools like list_custom_metrics. This clearly conveys what the tool does without 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 is given on when to use this tool versus alternatives like list_custom_metrics or how it relates to create_custom_dimension and archive_custom_dimension. The purpose implies usage when retrieval of custom dimensions is needed, but this is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List custom metrics defined on a GA4 property.
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, but it only states 'List custom metrics defined on a GA4 property.' It does not mention pagination, whether archived metrics are excluded, required permissions, or other 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the core purpose.
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 tool is simple and has an output schema, so return values are covered. However, the description omits behavioral context like pagination and whether archived metrics are included, making it minimally 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 coverage is 0% and the description does not explain the property_id parameter beyond its name and the context of 'GA4 property.' The agent must infer the format and provenance of property_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (custom metrics on a GA4 property), distinguishing it from sibling tools like list_custom_dimensions or list_data_streams.
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?
Usage is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the data streams (web/app) on a GA4 property. The stream id (last path segment of 'name') is needed by the Measurement Protocol secret tools.
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action (list) and scope (web/app) but does not mention permissions, pagination, rate limits, or output format. The read-only nature is implied but not explicitly confirmed, and no safety characteristics are disclosed.
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: the first states the core functionality, the second provides a practical note about the stream id. Every sentence earns its place with no wasted words, and the structure is front-loaded.
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 tool is simple, but the missing guidance on property_id format (e.g., 'properties/123' vs '123') and the lack of any safety annotations make it only partially complete. The downstream use case adds useful context, but a format example or explicit read-only hint would be needed for a higher score.
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 has one parameter, property_id, with no description at 0% coverage. The description does not mention property_id at all, leaving the agent to infer its meaning solely from the name. This is a significant gap that the description fails to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists data streams (web/app) on a GA4 property, using the specific verb 'List' and resource 'data streams'. It distinguishes from siblings like list_measurement_protocol_secrets by explicitly noting the stream id's role, making its purpose unmistakable.
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 implies usage when a stream id is needed for Measurement Protocol secret tools, providing clear context on when to use this tool. It does not explicitly compare with alternative list tools or state exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List key events (conversions) on a GA4 property.
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the function. No mention of whether results are paginated, filtered, or limited, nor any details about authentication, ordering, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that communicates the core functionality with zero unnecessary words. It is appropriately sized for a simple list operation.
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 is minimally viable for a simple list operation, and an output schema exists to document return values. However, it lacks any context about when to use the tool vs. alternatives and does not elaborate on the required property_id parameter, leaving the agent with only the bare function statement.
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 coverage is 0% and the parameter property_id has no description. The phrase 'on a GA4 property' hints that the parameter identifies the property, but it does not explain the expected format, how to obtain it, or whether it's a numeric ID or a string. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing key events (conversions) on a GA4 property. The verb 'list' and resource 'key events' are specific and distinguish it from sibling tools like create_key_event and list_audiences.
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 about when to use this tool versus alternatives. While sibling tools such as create_key_event imply complementary use, the description does not mention any exclusions, prerequisites, or alternative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Measurement Protocol API secrets for a data stream. stream_id is the numeric id from list_data_streams.
| Name | Required | Description | Default |
|---|---|---|---|
| stream_id | Yes | ||
| property_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. The verb 'List' implies a read-only operation, and the note about stream_id being a numeric id from list_data_streams adds a useful constraint. However, it does not describe output behavior, potential errors, or whether secrets are returned in full.
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 with no fluff: the first states the primary purpose, the second delivers a crucial parameter hint. Every word earns its place.
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 tool is a simple list operation with an output schema, so return values are covered externally. However, the description omits property_id explanation and does not mention when to use this versus create/delete. While adequate, it leaves gaps that could confuse an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains stream_id (numeric id from list_data_streams) but leaves property_id entirely undocumented. This partial compensation is insufficient for two required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Measurement Protocol API secrets for a data stream, using a specific verb and resource. It distinguishes itself from sibling tools like create_measurement_protocol_secret and delete_measurement_protocol_secret by focusing on listing.
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 actionable context by noting that stream_id comes from list_data_streams, establishing a prerequisite workflow. It implies this tool is for retrieving existing secrets but does not explicitly exclude create/delete alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a GA4 realtime report (last ~30 minutes). Example: metrics ['activeUsers'], dimensions ['country','unifiedScreenName'].
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| metrics | Yes | ||
| dimensions | No | ||
| property_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the time window and gives an example, but does not state that the operation is read-only, describe the return format, or mention pagination/error behavior. Some behavioral context is provided, but significant gaps remain.
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, front-loaded with the core action, and the example provides high value with no wasted words. Properly structured for quick scanning.
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 gives the essential purpose and an example, but without an output schema or annotations, it omits return value details and explicit guidance on when to prefer this over run_report. It is adequate but incomplete for a tool with four parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It provides example values for metrics and dimensions, demonstrating array syntax and valid names. However, limit and property_id are not elaborated, relying solely on the schema titles for their purpose.
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 a specific verb ('Run') and resource ('GA4 realtime report') with a time window ('last ~30 minutes'), clearly distinguishing it from the sibling tool run_report. The example further clarifies the intended use.
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 time window 'last ~30 minutes' clearly implies usage for recent data, but the description does not explicitly state when not to use it or name alternatives such as run_report for historical data. The context is clear, but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a GA4 report. metrics/dimensions are GA4 API names (e.g. metrics ['activeUsers','conversions'], dimensions ['date','sessionDefaultChannelGroup']). Dates accept YYYY-MM-DD or relative forms like '28daysAgo' / 'today'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| metrics | Yes | ||
| end_date | No | today | |
| dimensions | No | ||
| start_date | No | 28daysAgo | |
| property_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that metrics/dimensions use GA4 API names and that dates accept relative forms, which is useful. However, it does not disclose whether the operation is read-only, what the response format is, or any side effects, making the tool's behavior largely opaque.
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 concise and well-structured: the first sentence states the purpose, and the second provides concrete parameter examples. It avoids filler and front-loads the most critical information, making it easy for an agent to quickly grasp the tool's function.
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 absence of annotations and output schema, the description fails to cover essential context such as the response structure, pagination behavior, or any limitations. It also does not clarify the difference from 'run_realtime_report', leaving a gap in contextual understanding for tool selection.
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 important meaning for metrics, dimensions, and date formats by specifying GA4 API naming conventions and relative date syntax. However, it does not explain 'property_id' (beyond the schema title) or provide details about the 'limit' parameter. With 0% schema description coverage, the compensation is partial.
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 GA4 report with a specific verb and resource. It provides concrete examples of metrics and dimensions, clarifying the scope. However, it does not explicitly distinguish itself from the sibling tool 'run_realtime_report', so there is some ambiguity about whether this is for historical or realtime data.
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 is given on when to use this tool versus alternatives. The description implies it is for GA4 reporting but does not mention when to use 'run_realtime_report' or other sibling tools. There are no prerequisites, exclusions, or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an event into a GA4 property via the Measurement Protocol. measurement_id is the stream's 'G-XXXXXXX'; api_secret comes from a Measurement Protocol secret; client_id identifies the user/device. Set validate=True to hit GA4's debug/validation endpoint (checks the payload WITHOUT ingesting it) — recommended before real sends.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | ||
| validate | No | ||
| client_id | Yes | ||
| api_secret | Yes | ||
| event_name | Yes | ||
| measurement_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the validate=True behavior (hits debug endpoint, checks WITHOUT ingesting) and clarifies the source of api_secret and measurement_id. This goes beyond a simple 'send' statement, though it does not detail success/failure responses or permissions.
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 only two sentences long, front-loaded with the primary action. Every sentence earns its place: the first states the core behavior, the second adds essential validation guidance without verbosity.
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 send/action tool with no output schema and no annotations, the description covers the key workflow and parameter sources. It lacks a note on return values or errors, but for a fire-and-forget send operation, the guidance provided is largely sufficient. The unexplained event_name and params are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains measurement_id, api_secret, client_id, and validate, but omits event_name and params. However, the explained parameters include format and source details (e.g., 'G-XXXXXXX', 'from a Measurement Protocol secret'), adding meaningful semantics 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 the verb ('Send') and resource ('an event into a GA4 property') via the Measurement Protocol. It is specific enough to distinguish this tool from sibling tools, which focus on listings, reports, or GTM operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for using the tool and provides practical guidance on the validate flag, recommending it for testing before real sends. It does not explicitly list alternatives or exclusions, but the context is sufficient given the uniqueness of the tool among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0archive_audiencearchive_custom_dimensioncreate_custom_dimensioncreate_custom_metriccreate_event_audiencecreate_key_eventcreate_measurement_protocol_secretdelete_measurement_protocol_secretget_property_detailslist_account_summarieslist_audienceslist_custom_dimensionslist_custom_metricslist_data_streamslist_key_eventslist_measurement_protocol_secretsrun_realtime_reportrun_reportsend_ga4_eventScored across 19 tools
Each tool targets a distinct resource and action—accounts, properties, streams, reports, custom dimensions/metrics, key events, audiences, secrets, and event sending. No two tools overlap in purpose; even similar operations (archive vs. delete) are clearly differentiated by resource type.
All tool names follow a consistent verb_noun snake_case pattern (list_*, create_*, get_*, run_*, archive_*, delete_*, send_*). The use of 'archive' for some resources and 'delete' for others reflects GA4 API conventions rather than inconsistency.
At 19 tools, the set is on the heavier side but still well-scoped for GA4 management, covering configuration, reporting, audience creation, and Measurement Protocol. Each tool serves a distinct purpose, though some trimming could be possible.
The surface covers core workflows but has notable gaps: no update/archive for custom metrics, no update for audiences, no delete for key events, and no tools for user properties or property management. These omissions could force workarounds but don't break the primary use cases.
The BigQuery remote MCP server is a fully managed service that uses the Model Context Protocol to connect AI applications and LLMs to BigQuery data sources. It provides secure, standardized tools for AI agents to list datasets and tables, retrieve schemas, generate and execute SQL queries through natural language, and analyze data—enabling direct access to enterprise analytics data without requiring manual SQL coding.
Read and edit GA4, Search Console and Google Tag Manager from any MCP client. 29 tools.
The Google GKE MCP server is a managed Model Context Protocol server that provides AI applications with tools to manage Google Kubernetes Engine (GKE) clusters and Kubernetes resources. It exposes a structured, discoverable interface that allows AI agents to interact with GKE and Kubernetes APIs, enabling them to inspect cluster configurations, retrieve Kubernetes resource YAMLs, monitor operations like cluster upgrades, diagnose issues, and optimize costs—all without needing to parse text output or use complex kubectl commands.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…