Skip to main content
Glama
davide-cik

seomcp

by davide-cik

Bing Webmaster: performance per pagina

bing_page_stats
Read-only

Retrieve Bing Webmaster Tools impressions, clicks, and average position per page URL. Filter by site, date range, or text to analyze page performance.

Instructions

Impressioni, clic e posizione media per pagina su Bing. Il campo key è l'URL.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
endDateNoFiltra fino alla data indicata (YYYY-MM-DD).
siteUrlNoSito come registrato in Bing Webmaster Tools, es. "https://www.esempio.it/". Se omesso usa quello predefinito.
containsNoSolo le righe che contengono questo testo (case-insensitive).
aggregateNotrue: una riga per query/pagina con i totali del periodo. false: le righe per data così come le restituisce Bing.
startDateNoFiltra dalla data indicata (YYYY-MM-DD).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.21

TDQS

B3.1/5.0
Behavior2/5

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

The annotation already declares readOnlyHint=true, so the safety profile is covered. The description adds no behavioral context beyond that — nothing about which site is used by default, how the aggregate flag affects the response, or pagination/limit behavior.

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?

Two short sentences with no filler, and the core purpose is front-loaded. It is tight, though the second sentence is purely schema-related rather than the most decision-relevant fact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter tool with date filtering, an aggregation toggle, containment filtering and a default-site fallback, plus no output schema, the description is thin. It covers the identity of the result key but leaves the date-range and aggregate semantics entirely to the schema.

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 83%, so the baseline is 3, and the description goes slightly beyond it by clarifying that the `key` field holds the URL — a field that does not even appear in the input schema properties, so this is genuinely additive information.

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?

Names the specific resource (page-level performance on Bing) and the metrics returned (impressions, clicks, average position). The word 'per pagina' implicitly separates it from bing_query_stats and bing_keyword_stats, but it never explicitly names those siblings, so an agent must infer the distinction.

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 when-to-use guidance, no prerequisites, and no reference to the sibling tools bing_query_stats or bing_keyword_stats. An agent must guess whether to pick this or the query/keyword variants from the tool name alone.

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