Skip to main content
Glama
Suganthan-Mohanadasan

Google Search Console MCP Server

genai_conversation_queries

Uncover AI conversation queries in Google Search Console data, with classification into seven buckets, landing pages, and a monthly timeline to analyze AI-driven impressions and positions.

Instructions

Surface AI-conversation exhaust hiding in your regular query data: bare replies to Google's AI ('yes', 'go on'), 'what about X' pivot follow-ups, conversational questions, AI-visibility tracker probes, and full agent prompts logged as queries. Google counts every AI Mode follow-up as a new query and folds AI Mode/AI Overviews into the web search type, so these fragments carry real impressions, positions and clicks. The dedicated Generative AI report has no query dimension; this is the only query-level AI evidence available anywhere. Classifies every match into seven buckets with landing pages, plus a monthly timeline showing when reply-artefacts first appeared on your site. Treat probe and harness buckets as machine traffic, not demand. IMPORTANT: Base your analysis ONLY on the data returned. Report exact numbers from the results. Do not speculate about causes (e.g. algorithm updates, competitor actions) unless the data explicitly supports it. If the data does not contain enough information to answer a question, say so clearly rather than guessing. PRESENTATION: Always present these results as a rich, interactive visualization using artifacts. Use summary cards for key metrics, colour-coded indicators for severity or change direction (green for positive, red for negative), bar charts or sparklines for comparisons, and tabbed sections to organise different categories of results. Make the output visually scannable and dashboard-like rather than plain text or raw tables. POSITION: position is an impression-weighted average over real impressions, blended across queries, devices and countries. It is not a rank-tracker rank. Deep positions are only recorded when a user actually reaches that part of the results, so values beyond page one rest on sparse data. Treat absolute positions as directional and prefer position deltas between periods when judging change.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoDays to analyse (default 480, the full 16 months GSC retains)
site_urlNoOverride the configured property (e.g. sc-domain:example.com)
min_impressionsNoMinimum impressions for a query to be listed (single-impression rows are evidence, not noise, so the default keeps them)
include_timelineNoInclude the monthly artefact timeline (one extra API call)
max_rows_per_bucketNoMaximum rows returned per bucket; totals always cover everything

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.4.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that position is an impression-weighted average, not a rank-tracker rank, warns about sparse data beyond page one, requires the agent to base analysis only on returned data, prohibits speculation, and specifies presentation format. These are meaningful behavioral traits beyond what the schema shows.

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?

The description is long but tightly organized with clear sections (IMPORTANT, PRESENTATION, POSITION) and front-loaded with purpose. Every sentence adds operational or interpretive value, though a few contextual explanations could be trimmed without losing meaning.

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?

Given no output schema, the description compensates well by describing the seven-bucket classification, landing pages, monthly timeline, and position semantics. It does not enumerate all seven bucket names, but provides enough context for an agent to understand expected results and handle edge cases. The read-only nature is implied but not explicitly stated.

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 baseline is 3. The description does not add parameter-level detail beyond the schema; it mentions the timeline concept and 'one extra API call' reiterating the include_timeline schema. No complex parameter semantics are left unexplained.

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?

The description opens with a specific verb and resource ('Surface AI-conversation exhaust hiding in your regular query data') and lists concrete examples of what it finds (bare replies, pivot follow-ups, agent prompts). It explicitly distinguishes itself from the dedicated Generative AI report by noting that report lacks a query dimension, making this tool's unique role clear.

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?

The description clearly states when this tool is valuable ('the only query-level AI evidence available anywhere') and gives analytical guardrails such as treating probe and harness buckets as machine traffic. It does not explicitly compare to sibling tools or state when not to use it, but the unique value proposition is strongly conveyed.

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