Skip to main content
Glama
MoonEyes

google-ecommerce-mcp

by MoonEyes
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

GA4 properties

ga4_properties
Read-onlyIdempotent

Lists Google Analytics 4 accounts and properties the authorized account can read, so assistants can find the correct property_id for report or realtime queries.

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. With a client registry each property also says whether it belongs to the client ("owned"): only those can be queried.

Input Schema

NameRequiredDescriptionDefault
client_idNoClient id from clients_list. Required when several clients are registered; empty uses the only client (or the environment variables when there is no client registry)
max_pagesNoPages of 200 accounts to read at most

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • addedInput schema / properties / client_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Client id from clients_list. Required when several clients are registered; empty uses the only client (or the environment variables when there is no client registry)",
+  "title": "Client Id"
+}
  2. Addedv0.3.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly/idempotent/non-destructive), and the description adds real behavioral context on top: the Admin API must be enabled, no extra OAuth scope is needed, pagination is bounded, and under a client registry only 'owned' properties are queryable.

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-loads purpose and the return shape, then prerequisites and the registry caveat. Information-dense and mostly waste-free, though the run-on sentence packing return schema, auth, and ownership rules is slightly heavy.

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?

No output schema exists, so the description carries the return-value burden and does so explicitly (properties array fields plus configured_property_id). Combined with precondition and ownership guidance, an agent has everything needed to invoke and interpret it.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents client_id and max_pages, setting a baseline of 3. The description adds meaning by tying client_id behavior to the client-registry concept and the 'owned' queryability rule, going beyond the schema text.

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 and resource: reading GA4 accounts and properties via the Admin API accountSummaries, so the agent can discover a property_id. It explicitly distinguishes its role from siblings by naming ga4_report and ga4_realtime as downstream consumers of the id it returns.

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?

Clear routing: use this to find a property id when you need to pass property_id to ga4_report or ga4_realtime. It also names the ga4_report/ga4_realtime alternatives, though it stops short of stating an explicit 'do not use this when' exclusion.

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

Deploy Server

Other Tools