Skip to main content
Glama
MoonEyes

google-ecommerce-mcp

GA4 properties

ga4_properties
Read-onlyIdempotent

Retrieve GA4 properties accessible to the authorized Google account to find property IDs for reporting. Provide property details and configured ID for ga4_report or ga4_realtime.

Instructions

GA4 accounts and properties the authorized Google account can read (Admin API accountSummaries), so the assistant can find a property id itself and pass it as property_id to ga4_report or ga4_realtime. Returns {"properties": [{property_id, property_name, property_type, account_id, account_name, configured}], "configured_property_id"}. Needs the Google Analytics Admin API enabled; no extra OAuth scope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_pagesNoPages of 200 accounts to read at most

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, open-world, non-destructive. The description adds genuinely new operational context: it requires the Google Analytics Admin API to be enabled but needs no extra OAuth scope, and it documents the response shape and configured_property_id. Missing only rate-limit/pagination-limit behavior.

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?

A single dense but well-ordered paragraph: capability, then handoff to siblings, then return shape, then prerequisites. Front-loaded and largely waste-free, though packed tightly.

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

Completeness4/5

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

With no output schema, the description usefully enumerates return fields and the configured_property_id, plus the API prerequisite. It stops short of explaining the pagination/truncation ceiling implied by max_pages or what 'configured' means for the agent.

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

Parameters3/5

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

Schema description coverage is 100% and max_pages is fully documented in the schema (pages of 200 accounts, max 20). The description adds nothing about the parameter, so baseline 3 is correct.

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?

States a specific verb+resource (read GA4 accounts/properties via Admin API accountSummaries) and even names the exact data source. It distinguishes itself from siblings by explaining it produces the property_id that ga4_report and ga4_realtime consume.

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

Usage Guidelines5/5

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

Explicitly says when to use it and what to do with the result ('find a property id itself and pass it as property_id to ga4_report or ga4_realtime'), naming the two sibling tools. The dispatching intent is unambiguous.

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