Skip to main content
Glama
thenavidm

Google Search Console MCP

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Search analytics by any dimension

query_search_analytics
Read-onlyIdempotent

Retrieve clicks, impressions, CTR and average position from Google Search Console, grouped by query, page, country, device or date.

Instructions

The core report: clicks, impressions, CTR and average position from Google Search, grouped by any combination of query, page, country, device, searchAppearance, date or hour. This is the full-control tool. For the questions people actually ask, top_queries, top_pages, striking_distance and compare_periods are one call instead of a hand-assembled body. Two things to know before reading a result as bad news. Data finalises on a two to three day lag, so a window ending today is short at the end. And Google withholds rare queries for privacy, which is why the query breakdown reliably sums to fewer clicks than the site total.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteYesThe Search Console property. Either a URL-prefix property ("https://navid.me/", trailing slash included) or a domain property ("sc-domain:navid.me"). A bare hostname is read as a domain property. Call list_sites for the exact strings this account owns, because the two shapes are different properties and mixing them up returns a 403.
typeNoWhich surface to report on. Defaults to web. "discover" and "googleNews" carry no query or device dimension at all, so asking for one returns an error rather than empty rows.
accountNoWhich signed-in Google account to act as, by email. Omit to use the default. Call list_accounts to see what is signed in.
filtersNoCombined with AND.
end_dateYesYYYY-MM-DD, in PST.
row_limitNoDefault 1000, max 25000.
start_rowNoZero-based offset, for paging past row_limit.
data_stateNo"all" includes the most recent partial days, which is the only way to see the last two or three at all. Defaults to final.
dimensionsNoGroup-by columns, e.g. ["query"] or ["page","device"]. Omit for site totals.
start_dateYesYYYY-MM-DD, in PST. About 16 months of history is available.
aggregation_typeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.0
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / properties / start_row / maximum
      Removed value: -9007199254740991
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: a two-to-three day finalisation lag that makes a window ending today look short, and Google's privacy withholding of rare queries that makes the query breakdown sum to fewer clicks than the site total. It stops short of rate limits or per-account auth caveats, so it is strong but not exhaustive.

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?

Four sentences, each load-bearing: capability, routing, then two caveats framed as 'things to know before reading a result as bad news'. The most decision-relevant content is front-loaded and nothing is padding.

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 names the returned metrics and grouping, and covers the two traps that would cause misreading of results. For an 11-parameter tool it is close to complete, though it says nothing about pagination behaviour or response envelope shape, which an agent may need when paging past row_limit.

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 91%, so the schema already documents site shapes, type surfaces, data_state, row_limit and dimensions, including the discover/googleNews caveat. The description's dimension list largely restates the enum rather than adding syntax or format detail, so the baseline 3 for schema-driven params applies.

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?

Opens with a specific verb+resource and enumerates exactly what is returned (clicks, impressions, CTR, average position) and the group-by dimensions available. It also explicitly positions itself against named siblings, so an agent can distinguish it from top_queries, top_pages, striking_distance and compare_periods without opening any schema.

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?

States this is the 'full-control tool' and then routes the agent by name: for the common questions, top_queries, top_pages, striking_distance and compare_periods are one call instead of a hand-assembled body. That is explicit when-to-use-this vs when-to-use-alternatives guidance.

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