Skip to main content
Glama
Sign In

Variafy

by com.variafy
OverviewDiscussionsAdmin

Read Google Analytics data

google_analytics_read
Read-onlyIdempotent

Reads connected Google Analytics (GA4) properties: traffic, engagement and key events by source, campaign and landing page. action "list_tools" lists every operation of this router with its field names (get_tool_schema returns the input schema); it does not call Google and is free. action "execute" runs one read: {"action":"execute","tool_name":"ga4_report","arguments":{}}. Reads:

  • ga4_report: A Google Analytics (GA4) report of the connected property: chosen dimensions and metrics over a period, with totals and an optional comparison with the period before.

  • ga4_attribution_check: Checks where GA4 loses the source of traffic and key events: sessions with no channel, sessions without a source, key events piling up in Direct, your own domains and payment services as referrals, and Facebook or Instagram clicks without UTM tags.

  • ga4_landing_pages: Landing pages of the connected GA4 property: sessions, engagement and key events per page against the average, for all traffic or one channel or source / medium — which pages lose the traffic you pay for and which convert best.

  • ga4_google_ads_check: Compares Google Ads with GA4 campaign by campaign: paid clicks against GA4 sessions from google / cpc, and Google Ads conversions against GA4 key events — where the tracking between them loses traffic or conversions.

  • ga4_meta_ads_check: Compares Meta ads with GA4 campaign by campaign: link clicks and landing page views against GA4 sessions from Meta, and Meta results against GA4 key events — where UTM tags, visits or leads get lost between Meta and the site.

  • ga4_list_signals: What the watchdog found about this site and has not seen fixed: a missing Meta pixel, a key event that never fires, lost attribution.

  • ga4_property_setup: The setup of the connected GA4 property: time zone and currency, data streams, key events and how many of each were recorded in the last 30 days, links to Google Ads accounts and how long event data is kept — with what to fix. Read-only and free: changes nothing and does not count toward the monthly change limit. Google Analytics and Search Console have their own request quotas; they do not use this server’s Google Ads API quota.

Input Schema

NameRequiredDescriptionDefault
actionYeslist_tools: every operation with its field names, flags and router. execute: run the read named by tool_name.
argumentsNoFor execute: the fields of the operation, plus "connection" when several Google Analytics properties are connected. Omit or {} when it has none.
tool_nameNoFor execute: the operation name from list_tools, e.g. ga4_report.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuinely new context beyond them: list_tools 'does not call Google and is free', and GA4/Search Console use their own request quotas rather than the server's Google Ads API quota. It does not describe pagination or result-size behavior, so it stops short of a 5.

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

Conciseness4/5

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

Front-loaded with purpose, then router mechanics, then a bulleted operation list — good structure for a seven-operation router. It is long, and the operation catalogue partially duplicates what action 'list_tools' returns at runtime, which is mild redundancy, but each bullet does help an agent decide whether this tool covers its question.

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

Completeness5/5

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

For a router with three parameters, full schema coverage and no output schema, the description covers everything an agent needs: what each operation returns in substance, how to discover operations, how to invoke one, and the quota/cost model. Nothing material is left undocumented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description earns the extra point by clarifying semantics the schema cannot: that list_tools is a free non-calling discovery step, that arguments carries the operation's fields plus an optional 'connection' key, and by showing a literal execute payload. It still does not enumerate the per-operation field names, deferring that to list_tools.

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

Purpose5/5

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

The description opens with a specific verb and resource — 'Reads connected Google Analytics (GA4) properties: traffic, engagement and key events by source, campaign and landing page' — and then enumerates the seven concrete read operations available through the router. An agent can immediately distinguish this from google_ads_read, meta_ads_read and search_console_read by the data domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly explains the router contract (list_tools to discover operations, execute to run one) and gives per-operation conditions of use, e.g. ga4_attribution_check is for finding 'where GA4 loses the source of traffic' and ga4_google_ads_check for comparing Ads against GA4 sessions. What is missing is explicit cross-sibling routing — nothing says when to prefer this over search_console_read or performance_dashboard for overlapping questions.

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

All Variafy toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources