Bing Webmaster Tools MCP Server

Overview Schema Source Related Servers Discussions Admin

get_fetched_url_details

Retrieve detailed information about a previously fetched URL from Bing Webmaster Tools, including crawl and indexing details.

Instructions

Get detailed information about a fetched URL.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site_url": "<site_url>",
      "url": "<url>"
    },
    "name": "get_fetched_url_details"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes
`site_url`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 2, 2026

TDQS

D1.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'get', which weakly implies a read operation, but it does not state whether the URL must have been fetched previously, whether this is read-only, what form the details take, or what happens on error.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short and front-loaded, but it is under-specified rather than concise. The single sentence merely restates the tool name and earns no additional informative value.

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

Completeness2/5

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

With more than 30 sibling tools and two undocumented required parameters, a one-sentence tautological description is not enough. Even though an output schema exists, the agent still lacks the criteria to choose this tool and the semantics needed to populate the parameters correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%: both site_url and url are bare strings with no schema documentation. The description does not define either parameter or explain their relationship, so an agent has no information about what values to provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get detailed information about a fetched URL' essentially restates the tool name: 'detailed information' mirrors 'details' and 'fetched URL' is identical to the name. It gives no scope or distinguishing features, so an agent cannot tell this apart from siblings like get_url_info or get_url_traffic_info.

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 guidance about when to use this tool versus alternatives such as get_fetched_urls, get_url_info, or get_children_url_info. No context, exclusions, or routing signals are provided, leaving the selection entirely to inference.

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