Bing Webmaster AI CLI MCP server

bing-webmaster-ai-cli-mcp

<!-- mcp-name: io.github.stufently/bing-webmaster-ai-cli-mcp -->

bing-webmaster-ai-cli-mcp gives an AI agent read access to what Bing knows about your sites — traffic, indexing, crawl issues, inbound links, keywords — and a write path you choose: reviewed plan-and-apply by default, or direct writes when you opt in.

It ships a Python 3.12+ CLI and MCP server for the JSON Bing Webmaster Tools API, plus protocol-correct IndexNow submission. SOAP and POX are deliberately absent.

Choosing a write path

Read tools always execute immediately. For everything that changes Bing state, one setting picks between two paths:

export BING_WM_ALLOW_WRITES=false   # default: writes are planned and applied by a human
export BING_WM_ALLOW_WRITES=true    # opt in: writes go straight through

Read-only toward Bing is the default. Without BINGWMALLOW_WRITES=true the server lists no tool that changes Bing, and the CLI refuses one-step writes. Here is the reason. An agent using this server also reads pages, anchor text, crawl issues and search queries written by strangers. A confirmation an agent can send is a confirmation prompt injection can send, so as long as the agent can write, a poisoned string in someone else's anchor text can reach your Bing account. With the default, nothing an agent does changes Bing until you have read the plan and run bing-wm plan apply yourself. Opt in only for an agent you trust with your Bing account.

Direct writes (BINGWMALLOW_WRITES=true)

The MCP server advertises one-step bing_ tools, and the CLI accepts:

$ bing-wm submit-url example.com https://example.com/new-page --json
{"applied": true, "plan_id": "…", "operation": "submit_url", "result": null}

A direct write is not idempotent: retrying one records a new plan and sends the change again. If a response is lost, read audit.jsonl or bing-wm plan list before repeating the call.

Reviewed writes (default, BINGWMALLOW_WRITES=false)

The server advertises bingplan instead. Those tools send nothing:

$ bing-wm plan submit-url example.com https://example.com/new-page --json
{
  "plan_id": "…",
  "summary": "submit url https://example.com/new-page for https://example.com",
  "apply_with": "bing-wm plan apply …"
}
$ bing-wm plan apply PLAN_ID
Apply this plan? [y/N]: y

No MCP tool takes a plan ID, in either mode: a plan recorded for review is applied or rejected only at the CLI, by you. A direct write applies the plan it creates in the same call and never touches one somebody else recorded. The plan path stays available while direct writes are on, so an agent can still propose a change for review.

What both paths share

A direct write is the same code with the human step removed: it records the same durable plan and goes through the same apply boundary. A readable plan record, an append-only audit trail, one-shot application, expiry, Bing's own submission quota, a site denylist (BINGWMDENIEDSITES) and restart-persistent local limits (BINGWMMAXWRITESPERDAY) apply to both.

If the applying process is killed and leaves a lock behind, the command bing-wm plan unlock PLANID verifies that the recorded PID is gone before recovering it. An unfinished plan becomes unknownoutcome and cannot be applied again; the recovery is audited.

Install

BING_WM_ALLOW_WRITES=false uvx bing-webmaster-ai-cli-mcp

That one command starts the stdio MCP server. Every client block below runs the same uvx command. Create an API key in Bing Webmaster Tools under Settings → API Access and pass it as BINGWMAPIKEY. Writes are planned for review unless you also set BINGWMALLOWWRITES=true — see Choosing a write path.

Shortened. The full README is on GitHub.