MCP server for Bing Webmaster Tools on Cloudflare Workers
Strong tool naming (all verb-first, clear actions) and comprehensive descriptions (avg 180 chars, well above 34-char baseline). All 24 tools have explicit schemas with typed parameters and descriptions. Good risk classification (READ_ONLY, WRITE, DESTRUCTIVE). Key gaps: no output schemas documented, no pagination support despite tools returning lists, no error recovery guidance, and confirmation-only pattern (confirm boolean) lacks pre-execution dry-run. Composition is clean, each tool has one responsibility. Security: no secrets in params (good), but no audit logging or permission gates visible.
Adds a site to Bing Webmaster Tools. The site still needs verifying afterwards before any data is available.
Asks Bing to fetch a URL as its crawler would, so you can see what Bing sees. Results appear via get_fetched_urls.
Remaining allowance for submitting page content directly, as opposed to URLs.
Problems Bing hit while crawling: 404s, server errors, pages blocked by robots.txt, malware flags and DNS failures. Start here when indexing looks wrong.
The crawl rate settings configured for this site.
How often Bing has crawled the site, how many pages it fetched, and how many were indexed or returned errors, as a daily series.
No output schemas documented. Tools return JSON but LLMs cannot plan downstream calls without knowing response structure (e.g., what fields does get_query_stats return? Is there pagination?). This forces agents to guess or make exploratory calls.
No pagination support visible. Tools like get_query_stats, get_page_stats, get_crawl_issues likely return lists but lack limit/offset/page parameters and total_count in responses. Large result sets will blow context windows.
Confirmation pattern uses boolean flag only (confirm=true). No dry-run or preview before destructive operations (remove_site, remove_sitemap, submit_url_batch). LLMs may pass confirm=true without understanding consequences.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Lists the sitemaps and RSS or Atom feeds Bing knows about for this site, with their status.
Lists URLs previously fetched via fetch_url, with their status.
The queries driving traffic to one specific page. Use this to find what a given page actually ranks for.
Traffic statistics for the site's top pages: impressions, clicks and average position per page.
The pages that rank for one specific query. The mirror image of get_page_query_stats, for finding which page Bing chose for a term.
Search queries bringing impressions and clicks to the site, with average position. This is the closest equivalent to Search Console's performance report. Bing returns a rolling recent window rather than a range you choose.
Site-wide impressions and clicks over time, as a daily series. Use this for trend questions before drilling into queries or pages.
Lists the users who have access to this site in Bing Webmaster Tools, and their roles.
Index status for one URL: whether Bing has it, when it was last crawled, and any problems with it. The equivalent of Search Console's URL inspection.
Remaining daily and monthly URL submission allowance for the site. Check this before submitting, since the quota is finite and spending it cannot be undone.
Traffic detail for a single URL.
Lists every site this API key can access, with its verification status. Call this first if you are unsure of the exact site_url to use, since Bing requires an exact match.
Removes a site from Bing Webmaster Tools, along with its history in the tool. Requires confirm to be true.
Removes a sitemap or feed from Bing's list for this site.
Submits a sitemap or feed URL to Bing.
Submits one URL to Bing for indexing. Consumes daily quota, which cannot be reclaimed, so check get_url_submission_quota first and only submit URLs that have genuinely changed.
Submits several URLs at once. Each URL consumes quota. Requires confirm to be true, because a large batch can exhaust a day's allowance in one call.
Asks Bing to check ownership verification for a site. The verification file, meta tag or DNS record must already be in place.
No error recovery guidance. Tool descriptions lack hints like 'If site not found, call list_sites() first' or 'Quota exhausted, check get_url_submission_quota before retrying.' Agents cannot self-correct on failures.
No audit logging or permission gates visible in code. Tools accept site_url from allowlist but no logging of who called what, when, or with what result. Compliance and incident response will be difficult.