bing_connected_pages

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

Annotations already carry readOnly/idempotent/non-destructive/openWorld=false, but the description adds behavior the annotations cannot express: an empty result arrives as an empty_response label meaning silence rather than a measurement, with an explicit prohibition on reporting it as 'no problems found', plus a prompt-injection warning about untrusted fields. That is exactly the extra context this dimension rewards.

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

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

Four short sentences, each earning its place: purpose, positive trigger, negative trigger with alternative, then return-value and safety semantics. The purpose is front-loaded and there is no filler.

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

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

There is no output schema, so the description takes on return-value explanation itself and does so by defining the empty_response label and its interpretation. Combined with the sibling routing and untrusted-field warning, an agent has everything needed to call and correctly report this tool.

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

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

Schema description coverage is 0% for the single required parameter site_url, and the description only implies scope via 'for one site'. It never states the expected format (bare domain vs. full URL) or whether it must be a verified site, so it partially but not fully compensates for the empty schema documentation.

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

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

The description opens with a specific verb and resource ('List the connected-page relationships Bing has for one site') and explicitly names the sibling it is not (bing_url_links for ordinary inbound links). An agent can distinguish this from bing_link_counts, bing_url_links and the plan tools 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.

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

It gives an explicit positive trigger ('when the user asks which master URLs are connected to the site') and an explicit exclusion with the alternative to call instead ('Do not use this for ordinary inbound links; call bing_url_links'). Both when-to-use and when-not-to-use are stated, not inferred.

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