Skip to main content
Glama
MoonEyes

google-ecommerce-mcp

by MoonEyes
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Search Console performance

gsc_performance
Read-onlyIdempotent

Analyze Google Search Console performance for a property: retrieve clicks, impressions, CTR, and average position split by query, page, country, device, or date, with top rows and period totals.

Instructions

Google Search Console search performance for the configured property: clicks, impressions, CTR and average position, split by query, page, country, device or date. Returns the top rows, "totals" for the whole period (same filter, no split), "truncated", the unit and definition of each metric under "metrics", and a "date_range" in Pacific Time (Search Console's timezone) with "data_complete".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum rows returned (1 to 1000); totals always cover the whole property
end_dateNoYYYY-MM-DD; empty means 2 days ago (Search Console data lag)
dimensionsNoHow to split the results
start_dateNoYYYY-MM-DD; empty means 30 days ago (Pacific Time)
page_containsNoOptional: keep only pages whose URL contains this text

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.0
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum rows returned (1 to 1000)"New value: +"Maximum rows returned (1 to 1000); totals always cover the whole property"
    • changedInput schema / properties / start_date / description
      Previous value: -"YYYY-MM-DD; empty means 30 days ago"New value: +"YYYY-MM-DD; empty means 30 days ago (Pacific Time)"
  2. Changed8 schema fields changedv0.1.2
    • addedInput schema / properties / dimensions / description
      Added value: +"How to split the results"
    • addedInput schema / properties / dimensions / items / enum
      Added value: +[
+  "query",
+  "page",
+  "country",
+  "device",
+  "date",
+  "searchAppearance"
+]
    • addedInput schema / properties / end_date / description
      Added value: +"YYYY-MM-DD; empty means 2 days ago (Search Console data lag)"
    • addedInput schema / properties / limit / description
      Added value: +"Maximum rows returned (1 to 1000)"
    • addedInput schema / properties / limit / maximum
      Added value: +1000
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • addedInput schema / properties / page_contains / description
      Added value: +"Optional: keep only pages whose URL contains this text"
    • addedInput schema / properties / start_date / description
      Added value: +"YYYY-MM-DD; empty means 30 days ago"
  3. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent safety, but the description adds genuinely useful behavior: top-rows truncation with a "truncated" flag, "totals" computed over the whole period regardless of the requested split, Pacific Time date range, and a "data_complete" indicator. It stops short of describing rate limits or pagination mechanics.

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

Conciseness5/5

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

Two sentences, fully front-loaded: metrics first, then returned structure. No filler wording, and the key behavioral caveats (totals, truncated, timezone) are packed into the second sentence efficiently.

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 compensates well by enumerating the response keys (rows, totals, truncated, metrics, date_range, data_complete). A read-only tool with full annotation coverage needs little more; only finer details like sort order or error conditions are absent.

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%, so the schema already carries parameter meaning and a 3 is the baseline. The description restates the split dimensions (query, page, country, device, date) and notes that totals ignore the split, but omits searchAppearance and adds no format detail beyond the schema.

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?

The description names a specific resource (Search Console search performance for the configured property) and enumerates the exact metrics (clicks, impressions, CTR, average position) and split dimensions. It is clear what the tool does, though it never explicitly positions itself against siblings like ga4_report or gsc_inspect_url.

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?

There is no guidance on when to use this tool versus alternatives such as ga4_report or gsc_inspect_url. Defaults for date range are implied only indirectly via the schema, not the description, so the agent must infer usage context.

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