SEO GSC Wizard MCP

Bing queries for a page

get_bing_page_queries

Read-only

Use this when the user asks which Bing searches lead to one page. The Bing search queries that led to ONE landing page (clicks, impressions, CTR as a 0-100 percentage, over 100 if Bing logs more clicks than impressions, and impression-weighted average position per query): Bing's per-page keyword view, and the drill-down after get_bing_page_stats. Bing reports only the page's top queries, dated by week, so they sum to at most its get_bing_page_stats row. Not for Google: use query_search_analytics filtered to the page. Rows are sorted by clicks, then impressions, highest first. Returns notConfigured: true when no Bing Webmaster API key is set up for the property.

Input Schema

Name	Required	Description
`page`	Yes	The landing page URL to break down, exactly as get_bing_page_stats returns it (e.g. https://example.com/blog/post/). Bing matches the full URL, not a prefix.
`limit`	No	Max queries to return, ranked by clicks then impressions (default 100, uncapped).
`endDate`	No	Optional. Window end as YYYY-MM-DD (e.g. 2026-05-31). Omit BOTH startDate and endDate to return everything Bing has (about 16 months of search data, 6 of crawl data). Never pass null or the string "null".
`siteUrl`	Yes
`startDate`	No	Optional. Window start as YYYY-MM-DD (e.g. 2026-01-01). Omit BOTH startDate and endDate to return everything Bing has (about 16 months of search data, 6 of crawl data). Never pass null or the string "null".

Output Schema

Name	Required	Description
`hint`	No
`page`	No
`range`	No
`thenBy`	No
`listKey`	No	Name of the top-level field that holds the rows sortedBy describes.
`queries`	No
`siteUrl`	No
`warning`	No
`nextStep`	No
`ordering`	No
`rowCount`	No
`sortedBy`	No
`dateBasis`	No
`sortOrder`	No
`thenOrder`	No
`dataSource`	No
`bingSiteUrl`	No
`partialDays`	No	Requested days among Bing's newest (provisional) or after latestDataDate (missing, not zero), up to today.
`completeness`	No
`emptyBecause`	No
`methodLimits`	No
`notConfigured`	No
`latestDataDate`	No	Newest date with a row in everything Bing sent for this call, before the window filter.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 28, 2026

addedOutput schema / properties / completeness

Added value: +{
+  "$ref": "#/properties/siteUrl"
+}

addedOutput schema / properties / dateBasis

Added value: +{
+  "$ref": "#/properties/siteUrl"
+}

addedOutput schema / properties / latestDataDate

Added value: +{
+  "$ref": "#/properties/siteUrl",
+  "description": "Newest date with a row in everything Bing sent for this call, before the window filter."
+}

addedOutput schema / properties / listKey

Added value: +{
+  "$ref": "#/properties/siteUrl",
+  "description": "Name of the top-level field that holds the rows sortedBy describes."
+}

addedOutput schema / properties / partialDays

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Requested days among Bing's newest (provisional) or after latestDataDate (missing, not zero), up to today."
+}

addedOutput schema / properties / warning

Added value: +{
+  "$ref": "#/properties/siteUrl"
+}

Changed13 schema fields changedOct 18, 2026

changedInput schema / properties / endDate / description

Previous value: -"Optional. Window end as YYYY-MM-DD (e.g. 2026-05-31). Omit BOTH startDate and endDate to return everything Bing has (roughly the last 6 months). Never pass null or the string \"null\"."New value: +"Optional. Window end as YYYY-MM-DD (e.g. 2026-05-31). Omit BOTH startDate and endDate to return everything Bing has (about 16 months of search data, 6 of crawl data). Never pass null or the string \"null\"."

changedInput schema / properties / startDate / description

Previous value: -"Optional. Window start as YYYY-MM-DD (e.g. 2026-01-01). Omit BOTH startDate and endDate to return everything Bing has (roughly the last 6 months). Never pass null or the string \"null\"."New value: +"Optional. Window start as YYYY-MM-DD (e.g. 2026-01-01). Omit BOTH startDate and endDate to return everything Bing has (about 16 months of search data, 6 of crawl data). Never pass null or the string \"null\"."

changedOutput schema / additionalProperties
```
Previous value: -falseNew value: +true
```

addedOutput schema / properties / emptyBecause

Added value: +{
+  "$ref": "#/properties/siteUrl"
+}

addedOutput schema / properties / methodLimits

Added value: +{
+  "$ref": "#/properties/siteUrl"
+}

addedOutput schema / properties / nextStep

Added value: +{
+  "$ref": "#/properties/siteUrl"
+}

addedOutput schema / properties / ordering

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "additionalProperties": true,
+        "properties": {
+          "sortOrder": {
+            "$ref": "#/properties/siteUrl"
+          },
+          "sortedBy": {
+            "$ref": "#/properties/siteUrl"
+          },
+          "thenBy": {
+            "$ref": "#/properties/siteUrl"
+          },
+          "thenOrder": {
+            "$ref": "#/properties/siteUrl"
+          }
+        },
+        "type": "object"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

changedOutput schema / properties / queries / items / additionalProperties
```
Previous value: -falseNew value: +true
```

changedOutput schema / properties / range / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "days": {
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "endDate": {
-        "$ref": "#/properties/siteUrl"
-      },
-      "startDate": {
-        "$ref": "#/properties/siteUrl"
-      }
-    },
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "properties": {
+      "days": {
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "endDate": {
+        "$ref": "#/properties/siteUrl"
+      },
+      "startDate": {
+        "$ref": "#/properties/siteUrl"
+      }
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

addedOutput schema / properties / sortOrder

Added value: +{
+  "$ref": "#/properties/siteUrl"
+}

addedOutput schema / properties / sortedBy

Added value: +{
+  "$ref": "#/properties/siteUrl"
+}

addedOutput schema / properties / thenBy

Added value: +{
+  "$ref": "#/properties/siteUrl"
+}

addedOutput schema / properties / thenOrder

Added value: +{
+  "$ref": "#/properties/siteUrl"
+}

First observedOct 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover the read-only/open-world safety profile, but the description adds substantial context: data is limited to the page's top queries, dated by week, and sums to at most the get_bing_page_stats row; rows are sorted by clicks then impressions; and it returns notConfigured: true when no Bing Webmaster API key exists. That is genuine failure-mode and data-completeness disclosure an agent could not infer elsewhere.

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 use case is front-loaded in the first sentence and every subsequent sentence carries real information. The middle sentence is a dense run-on with a long parenthetical about CTR and position, which slows parsing slightly but does not waste words.

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 5-parameter read tool with an output schema, the description covers everything extra an agent needs: data retention (~16 months), top-query truncation, weekly granularity, sort order, and the notConfigured failure state. Return values need not be explained further given the output schema.

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 coverage is 80% and already documents page, limit, startDate and endDate thoroughly, so the baseline is 3. The description adds one useful semantic detail ('dated by week') that affects how date windows behave, and explains the CTR/position computation, but it never mentions siteUrl — the one parameter with no schema description — leaving that gap unfilled.

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 ('The Bing search queries that led to ONE landing page') and opens with the exact user question it answers. It explicitly distinguishes itself from get_bing_page_stats (this is the drill-down) and from query_search_analytics (the Google equivalent), so an agent can route correctly without opening a 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?

Gives a positive trigger ('when the user asks which Bing searches lead to one page'), a workflow position ('drill-down after get_bing_page_stats'), and a named exclusion with the alternative ('Not for Google: use query_search_analytics filtered to the page'). Both when and when-not are covered.

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

All SEO GSC Wizard MCP 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.

Resources

Need Help?