BlogSEO

Query Search Console

query_search_console

Read-onlyIdempotent

Queries Google Search Console live for the website: clicks, impressions, click-through rate and average position over any period of the last 16 months, grouped by query, page, country, device, date or search appearance, with filters on any of them (contains, equals, regex). It reads everything Search Console has at the moment of the call, where get_keyword_rankings and get_keyword_trends only cover the tracked keywords synced once a day. It also works on a website that has no plan yet, as soon as Search Console is connected for it. Examples: the queries of one page (dimensions ["query"], filter page equals its URL); queries ranking 5 to 15 with the most impressions (position_min 5, position_max 15, sort impressions); brand versus non-brand (filter query includingRegex or excludingRegex); daily clicks (dimensions ["date"]); pages losing traffic (call it for two periods and compare). Rows come back ordered by clicks, or by date when grouping by date only, unless sort is set. min_clicks, min_impressions, position_min, position_max and sort are applied to the top 25000 rows by clicks, and the result says when the property had more. Returns at most 500 rows per call (page with start_row). Search Console data lags 2 to 3 days. Limited to 200 calls per hour per website. When Search Console is not connected, the error gives the page where an admin connects it. Pass website_id when the account has several websites (see get_account).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`sort`	No	position: best first; clicks, impressions or ctr: highest first. Omit to keep Search Console's order.
`filters`	No	Conditions a row must all satisfy.
`end_date`	No	Last day, YYYY-MM-DD. Defaults to 3 days ago, the latest day with complete data.
`row_limit`	No	How many rows to return.
`start_row`	No	Zero-based offset, to page through the rows.
`data_state`	No	final: only complete days. all: also the last days whose numbers may still change.	final
`dimensions`	No	How rows are grouped. Pass an empty array for the totals of the period.
`min_clicks`	No	Only rows with at least this many clicks.
`start_date`	No	First day, YYYY-MM-DD. Defaults to 27 days before end_date.
`website_id`	No	Website id from get_account. Optional when the account has a single website.
`search_type`	No	Which Google surface: web search (default), image, video, news, discover or googleNews.	web
`position_max`	No	Only rows whose average position is at most this value; must be >= position_min.
`position_min`	No	Only rows whose average position is at least this value.
`min_impressions`	No	Only rows with at least this many impressions.

Output Schema

TableJSON Schema

Name	Required	Description
`rows`	Yes
`end_date`	Yes
`has_more`	Yes	True when more rows exist: call again with start_row increased by row_count.
`site_url`	Yes	Search Console property the rows come from.
`row_count`	Yes
`start_row`	Yes
`dimensions`	Yes
`start_date`	Yes
`website_id`	Yes	Website the result belongs to.
`search_type`	Yes
`scanned_rows`	No	Rows read from Search Console before the metric filters and sort were applied; absent without them.
`scan_truncated`	No	True when the property has more rows than the scan read, so low-click rows may be missing.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, but the description adds substantial behavioral context beyond them: a 2-3 day data lag, a 200 calls/hour/website rate limit, a 500-row cap per call, that filters/sort apply only to the top 25000 rows by clicks, and that a 'more rows' signal is returned. It also explains the error content when Search Console isn't connected.

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-loaded with purpose and sibling differentiation, then constraints and examples. It is dense and long, but each sentence carries distinct information (limits, lag, row caps, examples, error behavior) rather than filler, so the length is largely earned though slightly overstuffed.

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?

For a 14-parameter read tool with a full output schema and rich annotations, the description covers everything an agent needs: purpose, alternatives, examples, rate limits, data lag, pagination, ordering, and the row-cap semantics. Return-value explanation is unnecessary given the output schema exists.

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 baseline is 3, but the description adds meaning not in the schema: the ordering rules (by clicks, or by date when grouping by date only, unless sort is set) and the critical scoping note that min_clicks/min_impressions/position_min/position_max/sort operate only on the top 25000 rows. It also frames website_id via get_account and pagination via start_row.

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 (queries Google Search Console live) and names the exact metrics returned (clicks, impressions, CTR, average position) plus the supported groupings. It explicitly distinguishes itself from siblings get_keyword_rankings and get_keyword_trends by noting those only cover daily-synced tracked keywords while this reads live data.

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?

Names the alternatives and the condition that selects this tool over them, and supplies concrete when-to-use examples (one page's queries, positions 5-15 by impressions, brand vs non-brand, daily clicks, traffic-loss comparison across periods). It also notes it works on a website with no plan as long as Search Console is connected.

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

All BlogSEO tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.