Skip to main content
Glama
surendranb

Google Analytics MCP Server

by surendranb

list_properties

Read-onlyIdempotent

Lists all GA4 properties linked to a Google Analytics account, so you can identify available properties for queries and reporting.

Instructions

List all GA4 properties associated with an account.

Input Schema

NameRequiredDescriptionDefault
account_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.11.7

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds that results are 'all' properties for an account (no filtering), which is useful, but it is silent on what an empty/omitted account_id does — a real behavioral question given the schema default is "".

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?

One front-loaded sentence with no filler or redundancy. It is efficient, though the terseness borders on under-specification given the undocumented parameter behavior.

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

Completeness3/5

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

A simple one-parameter read tool with annotations and no output schema, so the bar is modest. Still, the description does not indicate what a returned property looks like (IDs needed to call get_ga4_data next), leaving a gap in the discovery workflow.

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

Parameters2/5

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

Schema description coverage is 0% for the single parameter, so the description carries the burden. It implies account_id scopes the listing but never explains the default empty-string case (list across all accounts?) or the expected ID format. This is a meaningful gap for a discovery tool.

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

Purpose4/5

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

States a specific verb and resource: list all GA4 properties scoped to an account. That is enough to separate it from siblings like get_property_schema or setup_ga4_access, though the description never names those siblings or states the relationship to them.

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

Usage Guidelines2/5

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

No guidance on when to call this versus alternatives such as setup_ga4_access or get_property_schema, and no stated prerequisite (e.g. that GA4 access must already be configured). The agent must infer the discovery-then-fetch workflow from sibling names alone.

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