Skip to main content
Glama
Bing Webmaster MCP Server

Bing Webmaster MCP Server

bing_plan_add_connected_page

Records a plan to connect a master URL to a site in Bing Webmaster for human review. Does not apply changes; returns a plan ID and CLI apply command.

Instructions

Record a plan to connect a master URL to the site in Bing Webmaster. Use when the user wants a master page connected and a person must review it first. Do not use this to list pages already connected; call bing_connected_pages. This sends no change to Bing and only records intent; it may read your quota. Do not tell the user the change was applied; return the plan id and the CLI apply command.

Input Schema

NameRequiredDescriptionDefault
site_urlYes
master_urlYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare openWorldHint, non-idempotent, non-destructive, but the description adds the genuinely non-obvious facts: it sends no change to Bing and only records intent, it may consume quota, and the agent must not claim the change was applied. It even prescribes the correct post-call behavior (return plan id and CLI apply command). This is context the annotations cannot carry.

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

Conciseness5/5

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

Four sentences, each earning its place: purpose, positive usage, exclusion/alternative, and behavioral/output guidance. Front-loaded with the core action and zero filler.

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

Completeness5/5

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

No output schema exists, so the description correctly explains the return values ('return the plan id and the CLI apply command') and frames the plan-then-apply workflow. For a 2-param intent-recording tool, nothing an agent needs to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 0% for both params, so the description carries the burden. It implies meaning ('connect a master URL to the site') mapping loosely to master_url and site_url, but adds no format or validation detail (e.g. full URL vs path). Partial compensation only.

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

Purpose5/5

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

States a specific verb and resource -- 'Record a plan to connect a master URL to the site in Bing Webmaster' -- and distinguishes itself from the sibling it is not (bing_connected_pages). An agent can tell it apart from the many plan_* siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-to-use condition ('user wants a master page connected and a person must review it first') and an explicit when-not-to-use with the alternative named ('Do not use this to list pages already connected; call bing_connected_pages'). Nothing is left to inference.

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

Deploy Server

Other Tools