mowteng is a remote MCP server that runs on Cloudflare Workers. It talks to three search consoles: Google Search Console, Bing Webmaster Tools and Yandex Webmaster. Google and Yandex worked from the Worker on the first try. Bing did not.
The symptom
Calls to the Bing Webmaster API from the Worker came back with ErrorCode 17 and the message ThrottleIP, even when mowteng had barely called Bing at all.
The name suggests rate limiting, so the first instinct is to back off and retry. That did not help. The same OAuth token and the same request worked once they left from a server outside Cloudflare's network. So the problem was not the request but where it came from. My best explanation: Workers send outbound requests from IP ranges shared by a very large number of other Workers, and Bing throttles those ranges as if they were one busy client.
The fix: a small relay
Moving the whole server off Workers was not worth it for one API. Instead, only Bing calls take a detour through a single Vercel function:
- The Worker builds the call as it would for Bing: the method name, the query parameters and the body, plus the user's Bing OAuth token.
- It POSTs that to the relay with a shared secret in a header. Without the secret the relay answers 401, so it is not an open proxy.
- The relay calls Bing from Vercel's network and returns Bing's answer unchanged, status code included.
Two details mattered more than I expected:
- Site URLs travel in the POST body, never in the request path. Platforms log request URLs. A relay that took
/relay?siteUrl=https://client-site.comwould leave every user's sites in someone's logs. The body is not logged. - The relay has its own timeout, shorter than the function limit. A hung Bing call ends with an answer the Worker can turn into a clear message ("Bing did not answer in time") instead of a platform error.
The relay is about 50 lines. It stores nothing; it never sees Google or Yandex traffic; and it only accepts method names made of letters, so it cannot be pointed at another host.
What I would check first next time
If you run a server on Workers, or any platform with shared outbound IPs, and one upstream API fails while the others work, try the same request from your own machine before you debug your code. An error that names the IP is the strongest hint, but some APIs just time out or return a generic 403.
And if you build the same fix, keep the relay narrow: one upstream host, a shared secret, no user data in URLs, and nothing stored.
Where this leaves Bing in mowteng
Bing Webmaster Tools works in mowteng today through this relay, next to Google Search Console, Yandex Webmaster and IndexNow, from one MCP URL. Bing support is still marked experimental. If you see a Bing error that this does not explain, I would like to hear about it at hi@milowda.com.